Date: Mon, 10 Apr 2006 21:04:12 -0500 From: "Rick C. Petty" <rick-freebsd@kiwi-computer.com> To: Eric Anderson <anderson@centtech.com> Cc: freebsd-fs@freebsd.org Subject: Re: How a file is deleted in ufs2? Message-ID: <20060411020412.GA44643@megan.kiwi-computer.com> In-Reply-To: <443B0466.6040508@centtech.com> References: <1144687418.11014.9.camel@diegows> <443AFB03.6060301@samsco.org> <443B0466.6040508@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060411020412.GA44643>