On Fri, 11 May 2007 01:36:03 +0400, Dan Farrell <[EMAIL PROTECTED]> wrote:
On Thu, 10 May 2007 11:34:46 +0100
Neil Bothwick <[EMAIL PROTECTED]> wrote:
On Thu, 10 May 2007 12:11:34 +0200, Benno Schulenberg wrote:
> > No idea, but I tried it when I encountered that page and portage
> > operations were measurably faster.
>
> That might well be just the transfer effect: you went from an old
> fragmented file system to a fresh unfragmented one.
I allowed for that. I created a new filesystem for /usr/portage - I
had been using a directory in /usr before.
Well, maybe it has to do with the efficiency of reading discontiguous
blocks from one file as opposed to a filesystem. Since it's a sparse
file, there might be a lot of 'space' that, if it were on an actual
disk, the heads would have to pass over; thus there may be a way in
which a sparse file is more efficient than a regular filesystem.
Remeber that the files in portage are, except for distfiles, quite
small. By my calculation, the average size for files and directories
under $PORTDIR (excluding $DISTDIR of course) is only 62 bytes. What
would you bet that on a disk partition, the other 962 to 4034 bytes per
block (I couldn't have block sizes less than 1K on reiser for my
portage, and 4096 is the default for most FS's) are filled with
nothing, and the heads need to pass over them to read the next block.
On a sparse file that space is merely reserved, it needn't actually
exist. Hope that helps you conceptualize the difference.
I guess the idea is correct, but the details are questionable. The heads
do not move over empty tails, the spinning disk does. A head just moves to
the track that contains the required sectors. The head movement and disk
spinning do not influence performance directly since there are many levels
of caching between a physical read and an application.
It looks like it takes much less buffer space to cache lots of small files
when they are joined into a sparse file than when they are in a real file
system, making sparse file very efficient.
--
Andrei Gerasimenko
--
[EMAIL PROTECTED] mailing list
