Re: Why we need delayed allocation!

On Fri, Dec 26, 2003 at 09:03:20AM -0800, Zachary Peterson wrote:
> So this may seem like an obvious question, but does fragmentation 
> always mean poorer performance?  The blocks are clearly "close" 
> together, but are they "close enough" such that the track cache and 
> read-ahead on the disk drive obviates the need for pure contiguity?  
> Clearly, the number of requests are greater, but you don't perform IO 
> for any, but the first one.  It was my understanding, that the design 
> of the block group, like FFS's cylinder groups, was designed to fit in 
> a disk track.  Most modern drives read entire tracks, and not the 
> requested block ranges inside a track.

In this case, it clearly won't matter.  The 36k of filefrag executable
will certainly comfortably fit within most track caches, and as Arjan
pointed out, when you execute an ELF executable (which is way more
important than how much time it takes to *copy* an ELF executable) the
access tends to be random, and possibly in an order which is more
likely similar to the one used by the BFD library used by ld to create
the file in the first place.

The main concern here is primarily aesthetic, and that it gives us
false positives about how badly fragmented a filesystem really might
be.  In particular, I now suspect that some complaints about
filesystem fragmentation being very high after doing an GNOME, KDE, or
libc build, was probably because the .o files were also getting
written in a random order, which will spoof the very simple-minded
algorithm used by fsck to determine the number of "non-contiguous"
files are on the filesystem.

It might be interesting to see if this does make a difference for very
large executables, such as evolution or mozilla, which will not fit
inside a track cache.  If it is even more badly fragmented as a result
of the linking process, that might impact its performance if you were
to execute that executable out of the build directory.  Arguably,
though, this may very well not be a case we care very much about,
since most of the time executables get copied from the build directory
during the install process (or during the packaging process).

One of the reasons why I created the filefrag program is that I'm
interested in seeing if how bad the filesystem fragmentation problem
really is under ext2/3, and to see what the causes might be.  The
linker/BFD library just happened to be the first one I found.  The
$64,000 question is whether there might be some other more common-case
scenarios where the userspace write ordering may be impacting
filesystem performance in a measurable and significant way.

                                                - Ted


-------------------------------------------------------
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