Paul,

As far as I know there is not a white paper on BAD UFID's or their cause.
Most of the time if the cause is not obvious (such as a broken disc drive)
it may be impossible to figure what caused it in the first place!

A UFID is simply a pointer, a unique file descriptor which points to the
location of a file's label.  When you try to access a file, the file system
first finds the file's entry in the directory.  A directory entry for a file
is pretty simple, in fact most of the words in the entry are taken up by the
5-word UFID.

From  this 5-word UFID pointer found in the directory the file system can
determine the exact location of the label of the file and on what disc drive
the label resides.  From the label, of course, we move to extents and then
into the data.

So whenever you see a BAD UFID message at the console, what has happened is
that the UFID in the directory for a particular file no longer actually
points to the file itself.  You do a LISTF,2 and find the directory entry,
but then when the OS goes to where the UFID points, it can not retrieve the
file info because the file isn't there or the UFID points to a different
file than expect, etc.

Thus, the cause of a BAD UFID can be anything which gets in the way of the
directory entry and its file.

The easiest cause is a bad disc drive which has corrupted either the
directory or the label table.  If either has been trashed by a bad drive you
are most likely in for an INSTALL and RESTORE unless the damage is slight
and you can repair it with FSCHECK.

Another cause could be that the directory, residing on ldev 1 (or a MASTER
volume) is intact but the target label is on a drive which has spun down.
If the system has not already hung in this case, you may get a BAD UFID when
the UFID can not find its target.

Aside from hardware reasons for corruption, that only leaves software and,
unfortunately, the directory and/or label tables can get stomped on by OS or
other PM code.

Recovery from BAD UFIDS is not always easy but once you know what is going
on it at least makes it easier to understand.  I usually use FSCHECK (with
IGNORE) to determine the scope of the corruption. If not too serious then
see if FSCHECK can clear it.  If you've got hundreds of files involved then
you'd better prepare for a rebuild.

It's a good idea before embarking on a major file system cleanup with
FSCHECK to run the problem past the response center.

Bob Denham
----- Original Message -----
From: Paul Courry <[log in to unmask]>
To: <[log in to unmask]>
Sent: Saturday, July 08, 2000 10:08
Subject: [HP3000-L] Causes of BAD UFID


> HP is unable to supply me with a white paper of the subject of the known
causes of BAD UFID's.
>
> In the interest of knowledge, does anyone have such a document or a
private stash of knowledge that
> could be shared other than the usual bad hardware, bad patch variety?
>
> Paul Courry
>