Re: Why we need delayed allocation!

well, I have very alpha delayed allocation. current implementation
uses extents, but this can be changed without big problems.
probably only serious thing to be implemented yet is reservation.

>>>>> Theodore Ts'o (TT) writes:

 TT> As those of you who have been following the BK repository of e2fsprogs
 TT> (or use Debian unstable, where I have been inflicting the Debian
 TT> unstable users with prerelease snapshots --- I should probably look into
 TT> doing the same with Fedora) might have noticed, I recently have included
 TT> into the distribution a program which uses the FIBMAP ioctl to analyze
 TT> files to determine how fragmented they are, as a tool to see how well
 TT> (or poorly) the file fragmentation avoidance algorithms in ext2 have
 TT> been working out.

 TT> When I ran the program on itself, I have surprised to find that it was
 TT> much more badly fragmented than I had expected:

 TT> # ./filefrag -v filefrag
 TT> Checking filefrag
 TT> Filesystem type is: ef53
 TT> Filesystem cylinder groups is approximately 15080
 TT> Blocksize of file filefrag is 4096
 TT> File size of filefrag is 34365 (9 blocks)
 TT> Discontinuity: Block 1 is at 1217290 (was 1217288)
 TT> Discontinuity: Block 2 is at 1217293 (was 1217290)
 TT> Discontinuity: Block 4 is at 1217291 (was 1217294)
 TT> Discontinuity: Block 6 is at 1217295 (was 1217292)
 TT> Discontinuity: Block 7 is at 1217289 (was 1217295)
 TT> Discontinuity: Block 8 is at 1217296 (was 1217289)
 TT> filefrag: 7 extents found, perfection would be 1 extent

 TT> This was true even when the block group in question had plenty of
 TT> contiguous free space.  A look at the inode via debugfs makes it very
 TT> clear what is going on:

 TT> Inode: 607065   Type: regular    Mode:  0755   Flags: 0x0   Generation: 
3543024981
 TT> User: 15806   Group: 15806   Size: 34365
 TT> File ACL: 0    Directory ACL: 0
 TT> Links: 1   Blockcount: 72
 TT> Fragment:  Address: 0    Number: 0    Size: 0
 TT> ctime: 0x3feaf8a0 -- Thu Dec 25 09:48:00 2003
 TT> atime: 0x3feaf8a8 -- Thu Dec 25 09:48:08 2003
 TT> mtime: 0x3feaf8a0 -- Thu Dec 25 09:48:00 2003
 TT> BLOCKS:
 TT> (0):1217288, (1):1217290, (2-3):1217293-1217294, (4-5):1217291-1217292, 
(6):1217295, (7):1217289, (8):1217296
 TT> TOTAL: 9

 TT> The problem is that when the linker is writing out the ELF executable,
 TT> it is doing so via apparently random seeks, probably because it is
 TT> writing out the various ELF sections in some order which is most
 TT> convenient for itself.  In particular, it appears than it wrote out the
 TT> 9 4k blocks that comprise the filefrag executable in the following order:

 TT>    Blocks 0, 7, 1, 4, 5, 2, 3, 6, 8

 TT> So the filefrag executable is using 9 contiguous blocks starting at
 TT> 1217288, but the order of those 9 blocks reflects the above write order.

 TT> Preallocation would have solved this problem somewhat, but it isn't a
 TT> perfect solution given much larger executables (such as Mozilla or
 TT> Evolution).  Something that would work much better would be to use
 TT> delayed allocation, where we don't actually try to determine the
 TT> placement of the blocks of a file until we are asked to write the page
 TT> from the page cache.  XFS in Irix does this, and it would probably
 TT> worthwhile for us to see if we can do something similar.

 TT> Comments?

 TT>                                            - Ted


 TT> -------------------------------------------------------
 TT> This SF.net email is sponsored by: IBM Linux Tutorials.
 TT> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
 TT> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
 TT> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
 TT> _______________________________________________
 TT> Ext2-devel mailing list
 TT> Ext2-devel@xxxxxxxxxxxxxxxxxxxxx
 TT> https://lists.sourceforge.net/lists/listinfo/ext2-devel



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click