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 --------------------------------------------------------------- [EMAIL PROTECTED] http://www.kiwi-computer.com/ _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
