inode recovery and differences between UFS1/2 & soft updates

[Rick C. Petty]

Hello.  I posted a message to ports yesterday regarding the status of
sysutils/ffsrecov, which won't compile with UFS2 headers.  I'm in dire need
of reconnecting or dumping inodes (well the associated files) because of a
pair of crashes causing fsck to fail due to "unreferenced files".

A few years back I did a bunch of work with UFS1/FFS including a few
personal utilities to dump unconnected files, etc.  I know the UFS1
implementation pretty well, but that was prior to the use of soft updates
or the new UFS2.  I'd like to pull the valuable data off this drive before
I fsck it clean and thus modify the file system.  My question(s) concern
the differences between UFS1 & UFS2 and the use of soft updates.

AFAICT, soft-updates affects the in-memory copy and does not affect the
structures on the FS itself, just the order in which those structures are
updated to improve performance.  I therefore assume that the FS structure
is similar to the original UFS1/FFS and could use my old utilities to dump
the files without modification.  The concern is that possibly soft updates
was interrupted during a metadata write and maybe the inode or something
else became corrupt; I can't imagine how, I just wanted to verify that this
wouldn't happen.

It seems to me that the basic differences between UFS1 & UFS2 are the new  
ACLs and extended attributes, both of which don't change the underlying    
format of the file system.  It is my guess that I should be able to repair
this and even recompile ffsrecov using the old UFS headers.  I'm also
guessing that I should be able to throw the drives into an older freebsd
system (w/o UFS2) and recover it that way.  Please let me know if I'm way
off base here.

On a related note, the soft-updates document,
http://www.usenix.org/publications/library/proceedings/usenix99/mckusick.html
implies that the unconnected inodes I'm seeing with fsck are files that
were deleted when the system was previously up, whose metadata was written
but whose inodes' link counts weren't decremented yet.  In such a case,
these "unreferenced files" should be unimportant.  I still wish to dump the
inodes because one of my drives had a low-level failure (hence why the
system crashed twice in a row) and after fsck-ing some important files did
disappear without a trace (I have a list of inodes and the FS was only
mounted read-only to verify the file integrity).

I'm running 5.1-RELEASE with UFS2 on both drives and softupdates enabled.
They are ATA/133 and ATA/100 respectfully (although the ATA/100 workes
better at udma66-- otherwise I get a bunch of ICRC errors and often it'll
drop to PIO mode).  Any help on this topic would be appreciated.  Some of
the data is vital and I need it quickly.  Thanks in advance,

-- Rick C. Petty        Senior Software Engineer, KIWI Computer
---------------------------------------------------------------
rick at kiwi-computer.com            http://www.kiwi-computer.com/