7.1-RELEASE growfs/fsck_ffs woes

[Matthias Andree]

Greetings,

I have a hard time with file system access.

Here's the story: I'd been unhappy about GEOM_JOURNAL within the same
provider as my /usr and /var partitions (used JOURNAL on a fresh
install), it would occasionally give up on fsync() for lock messups
(FreeBSD 7.1-RELEASE-p2). Several weeks ago, I reverted my -o async
journalled /var to softupdates without journal, with no ill effects.
AFAIR, I installed with gjournal label with just one provider, and then
newfs UFS2 with journal.

Earlier today, I disabled the journal on /usr (shutdown to single user
mode, dismount, gjournal sync, gjournal stop, gjournal clear, tunefs -J
disable, kldunload geom_journal, fsck) - that worked, and fsck preen
considered the FS clean.

I tried to resize the partition to its full size with growfs; and it
warned about being unable to allocate some 58,000 blocks, but performed
the operation (i. e. I got a list of superblocks) - apparently it
completed. A subsequent fsck -f however turned up with a gazillion of
"DUP" blocks, in random places. I have no explanation for that; am
currently running fsck -y. Accidentally, I ran growfs twice, but the
second run didn't seem to do a lot - it just warned it couldn't allocate
58,600+ sectors and quit.

I've also found that fsck_ffs's pass 1b is EXTREMELY slow, and from a
cursory glance at pass1b.c, some none-scalable (as in O(n^2) or worse)
effects seem to be at play. I'm currently away from the machine, but any
insights on the growfs corruption and/or pass1b.c accelerators are
welcome - ext2fsck is a lot faster when doing deep searches for
duplicate blocks (pass 1b and pass 1c), but I haven't checked the code.
The partition slice is several GB in size with default newfs settings,
but not overly huge (<< 100 GB), and last time I checked, it had taken
around 30 min for scanning 7 out of 78 (IIRC) cylinder groups. I hope
fsck doesn't do more damage... ;-)

This is an Athlon XP 2500+ (later "Barton" version with 512 kB L2 cache)
with 1 GB of RAM and a reasonably fast Maxtor 250 GB SATA drive, with a
reasonably fast fsck if pass1b isn't needed (perhaps two or three
minutes). I've recompiled fsck_ffs with -O3 -march=athlon-xp to peep
cycles, but compiler optimization cannot fix slow algorithms.

Thanks in advance,
Matthias