How a file is deleted in ufs2?

Rick C. Petty rick-freebsd at kiwi-computer.com
Tue Apr 11 02:04:15 UTC 2006


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!

-- Rick C. Petty


More information about the freebsd-fs mailing list