xfs
[Top] [All Lists]

Re: undelete - xfsrecover'ing deleted files in xfs

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: undelete - xfsrecover'ing deleted files in xfs
From: Stephen Lord <lord@xxxxxxx>
Date: Sat, 02 Feb 2002 13:51:21 -0600
Cc: Seth Mos <knuffie@xxxxxxxxx>, King Kac <kacperw@xxxxxxxxx>, linux-xfs@xxxxxxxxxxx
References: <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <20020131210325.C966@comotion> <B87F3B30.17EF%gnydick@clubphoto.com> <4.3.2.7.2.20020201142828.037499a0@pop.xs4all.nl> <4.3.2.7.2.20020201185638.03660ee8@pop.xs4all.nl> <20020201193334.A24652@wotan.suse.de> <1012590178.26396.429.camel@jen.americas.sgi.com> <20020202051059.A32003@wotan.suse.de>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
Andi Kleen wrote:

On Fri, Feb 01, 2002 at 01:02:58PM -0600, Steve Lord wrote:

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


I see. The extents would be in a btree which would be likely rebalanced
on the extent freeing and that would destroy them because they're inline
in the btree. Is that correct?



Well, how deep do you want to go ;-)

For a file with a few extents the extents are held in the inode, we then move to a
single block, and then to a btree of blocks. There are also two forks - one for data
and one for extended attributes if you have them. Most files probably fit inside the
inode - default inode size is 256 bytes, there is room for about 8 extents in there
I think, each extent takes 16 bytes of space.


As the extents are freed they get removed from the inode and placed back into
the free space btrees of the allocation group in the filesystem they are located
in - insertion into this tree can mean they get merged with surrounding free
space. So the inode is generally stamped on as space is removed - various
memmove operations take place, and the free space is fare game for any
subsequent allocation for which it is a good match.


The memmoves as stuff is deleted probably really mess things up.

Steve



Thanks,
-Andi





<Prev in Thread] Current Thread [Next in Thread>