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