Rick C. Petty wrote this message on Sun, Sep 14, 2003 at 12:52 -0500:
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.
Sorry, must of missed that. I'm the author of ffsrecov, and I haven't
updated mainly because I haven't had a system w/ UFS2 to really test
on. I might be able to get to it in the next week or two, but I assume
that you need it sooner.
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.
I would recommend if you can is to dump it to another filesystem or
to tape.. then you can reinstall and recover the data at a more
leisurely pace.. I had to do this when I originally wrote ffsrecov.
Part of the reason you couldn't recover direct from device in the early
versions.
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.
Most IDE disks have write caching enabled, and if the system powers off
before the data is writen to disk, softupdates will think that the write
hit the disk when infact it hadn't yet.
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.
Another really big difference is that the size of the blocks are
different.. There is also a different way of listing blocks relating
to the file. This was changed to a more dynamic approch and so it looks
more like extents while keeping the advantages of the old way. (Thanks
for your presentation at BSDcon, Kirk!)
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).
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
