Re: panic: bad dir: mangled entry, fsck: missing dot/dotdot

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I'm getting two "Bad file descriptor" errors, one on a directory and
> another on a regular file, both in the same directory.  What do you
> suggest to do?

Hm.

What do you get those errors from?  find(1)?  I think the first thing
I'd try to do is provoke them deliberately by hand - eg, try using find
on a directory one or two levels up rather than the whole filesystem,
if possible - and try to capture the error with ktrace.  I'm wondering
what syscall is producing the error.

You say it's an FFSv2 filesystem; I don't know much about how FFSv2
differs from FFSv1, and it's v1 I know well.  So the rest of this will
be written for v1, in the hope it's similar enough to v2 for the
remarks to be useful.

I'd have a close look at the containing directory.  In particular, I'd
make sure the d_type values match the types of the pointed-to inodes.
(It wouldn't surprise me if two entries with different d_type values
but the same inumber could produce surprising results, for example.)
I'd also have an intensive look at the entries which produce errors,
and at the inodes named by them.  If you just want to repair it, rather
than figuring out what's going on, and you can afford to lose what's in
the file, I'd suggest clri on all three inodes (containing directory,
file, and contained directory), then fsck and fishing things out of
lost+found to clean up the damage.  (If any two of those inodes are the
same, something is definitely corrupt.)

I can't really give full instructions, since this would be an
exploratory sort of investigation, with most of it guided by what
earlier work found.

> I'll have a look at that.  I do have photographs of the fsck dealing
> with the first dot-lacking directory.

That would be interesting, though I'm not sure how informative it would
be; the thing of real interest is something fsck missed and thus
probably won't be mentioned in fsck's output.

>> meaning each one held whatever was last written to either of them,
>> something filesystems do not deal with well.
> With all due respect to FFS's stability, I would expect more havoc if
> that were the case.

Depends on what the blocks get used for.  If, for example, each of them
happened to be a block of inodes, nothing will happen until inodes that
happen to end up on the same piece of disk get used - and the defaults,
in my experience, provide _way_ more inodes than needed, so that could
be a rare event, and will strike only a handful of inodes in any case.
If they happen to be data blocks, nothing will happen except that file
contents will get corrupted.  It's when they're indirect blocks or
superblocks, or one's inodes and the other isn't, that I'd expect
serious havoc.

> Fortunately, the components are SAS discs.

>> reading quirk lists makes me think such a thing is depressingly
>> plausible.
> Even on SAS?

Well, I wouldn't totally rule it out - at this point there's very
little I'd totally rule out - but I'd definitely investigate other
possibilities first.

If you have the space - which you may well not, given how large the
filesystem is - I'd suggest capturing a snapshot of the filesystem for
investigation, then look at the live copy with an eye to optimizing for
time-to-repair, with understanding deferred to later investigations on
the copy.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B