Re: undelete - xfsrecover'ing deleted files in xfs

[Steve Lord <lord@sgi.com>]

On Fri, 2002-02-01 at 12:33, Andi Kleen wrote:
> On Fri, Feb 01, 2002 at 07:01:38PM +0100, Seth Mos wrote:
> > When you delete a file the space that you freed is mostly contigous and 
> > thus easily reused for the next file you create.
> 
> If you have enough space left there is nothing that would force reuse
> of that same space directly afterwards. You could be lucky. 
> 
> When you can find the inode of the deleted file again and its extent btrees 
> are not destroyed it should be possible to reconnect it to a directory.

Unfortunately when we free an inode we also remove all the extents from
it. So even if those extents used to be in the inode, they are not there
now. The reason this happens is that deleting a file is an unbounded
operation in terms of how complex it is, so it has to be broken up into
lots of seperate transactions - and between each transaction the inode
needs to be 'correct' so that if we crash in the middle of removing a
file we can complete the remove during recovery. So when we unlink a
file there is a transaction to put it into a linked list of files to be
removed during recovery. Then when its reference count drops to zero
we do a sequence of transactions which remove 2 extents each, then
finally we do a last transaction to mark the inode free and remove
it from the list.

Since we never free the inode blocks at all, the inode is definitely
still there, there is just not very much in it anymore.

Steve


> XFS inodes are allocated in chunks of 64 so unless you free a lot of files
> it is not too unlikely that such a chunk is not completely freed because
> there is an inode left on it. With that information and some sanity checking
> it may be possible to write a lsdel function for xfs_db that lists 
> all free inodes in existing chunks that do not look like garbage. When they
> can be inserted into the inode btree again and xfs_repair is run they
> should should appear in lost+found. Of course this assumes that there
> hasn't been that much new IO on the new fs afterwards and doesn't cover
> all cases, but may be useful for some situations. 
> 
> Just an idea. I don't know how difficult it would be to write
> an "is this inode garbage" function or to teach xfs_db to insert into
> btrees (later is probably non trivial).
> 
> -Andi
-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@sgi.com