How a file is deleted in ufs2?
Eric Anderson
anderson at centtech.com
Tue Apr 11 02:37:27 UTC 2006
Rick C. Petty wrote:
> On Mon, Apr 10, 2006 at 08:20:38PM -0500, Eric Anderson wrote:
>> Hmm.. Can you explain then how a tool could recover rm'ed files (or just
>> point me to the code snippet)? There are a few tools that do this. I
>> was under the understanding that the direct/indirect/* lists got blasted
>> away, but parts of the inode were left over.
>
> Nope, the whole inode gets cleared. I thought this too and discovered the
> hard way. Maybe without softupdates, I'm not sure??
>
> There doesn't seem to be many tools that do this, at least with UFS2. I
> wrote my own program to try to recover a toasted drive. My program
> searches the free blocks on the disk looking for indirect blocks (i.e.
> blocks that have certain characteristics), validates those blocks, then
> pieces together the blocks into unnamed files (file names are stored in the
> directories, not in the inode or elsewhere). This gives you all but the
> first 12 blocks of the file, due to the on-disk structure of inodes. It
> tries some heuristics to guess at these blocks, but the success rate is
> very low. As long as fewer blocks have been allocated & written to the
> disk then are available on the disk, it works well (because the allocation
> algorithm is highly deterministic).
>
> Writing the program was a major headache, and it didn't work as well as I
> was hoping. However it did allow me to spend much time into our UFS/FFS
> code (where I did discover some potential bugs-- haven't had time to
> submit patches yet). I started this program because ffsrecov (still)
> doesn't work with UFS2.
>
> There is a utility (sysutils/tct) which does something similar. It makes a
> copy of all the free blocks and tries piecing them together, using file(1)
> to verify & classify the files. Unfortunately this tool wasn't useful to
> me. My program instead analyzes the disk as a whole and makes
> determinations based on the block numbers (i.e. it finds indirect blocks
> which point only to freed blocks).
>
> Inodes get scrubbed when the files are completely unlinked. "rm -r" is
> even more invasive, as the directories which get deleted tend to have junk
> pointers to freed blocks. The freed data blocks remain intact until the
> FFS block allocator decides to use the blocks again. It's messy to try to
> recover deleted files. I've learned (many times) the hard way that there's
> no substitute for periodic backups, archiving, and redundant mirroring!
Thanks! This is great.. I appreciate all your hard work you've done,
even if it is for nothing except for learning :).
Thanks again for the details and corrections!
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
More information about the freebsd-fs
mailing list