| 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:
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
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Preallocation and Ferris, Stephen Lord |
|---|---|
| Next by Date: | Re: [NEWS] Extended attributes interface changes, Nathan Scott |
| Previous by Thread: | Re: undelete - xfsrecover'ing deleted files in xfs, Andi Kleen |
| Next by Thread: | Re: TAKE - fix bitkeeper on xfs, Brian C. Huffman |
| Indexes: | [Date] [Thread] [Top] [All Lists] |