| 1 |
On Fri, 11 May 2007 01:36:03 +0400, Dan Farrell <dan@×××××××××.cx> wrote: |
| 2 |
|
| 3 |
> On Thu, 10 May 2007 11:34:46 +0100 |
| 4 |
> Neil Bothwick <neil@××××××××××.uk> wrote: |
| 5 |
> |
| 6 |
>> On Thu, 10 May 2007 12:11:34 +0200, Benno Schulenberg wrote: |
| 7 |
>> |
| 8 |
>> > > No idea, but I tried it when I encountered that page and portage |
| 9 |
>> > > operations were measurably faster. |
| 10 |
>> > |
| 11 |
>> > That might well be just the transfer effect: you went from an old |
| 12 |
>> > fragmented file system to a fresh unfragmented one. |
| 13 |
>> |
| 14 |
>> I allowed for that. I created a new filesystem for /usr/portage - I |
| 15 |
>> had been using a directory in /usr before. |
| 16 |
>> |
| 17 |
>> |
| 18 |
> Well, maybe it has to do with the efficiency of reading discontiguous |
| 19 |
> blocks from one file as opposed to a filesystem. Since it's a sparse |
| 20 |
> file, there might be a lot of 'space' that, if it were on an actual |
| 21 |
> disk, the heads would have to pass over; thus there may be a way in |
| 22 |
> which a sparse file is more efficient than a regular filesystem. |
| 23 |
> |
| 24 |
> Remeber that the files in portage are, except for distfiles, quite |
| 25 |
> small. By my calculation, the average size for files and directories |
| 26 |
> under $PORTDIR (excluding $DISTDIR of course) is only 62 bytes. What |
| 27 |
> would you bet that on a disk partition, the other 962 to 4034 bytes per |
| 28 |
> block (I couldn't have block sizes less than 1K on reiser for my |
| 29 |
> portage, and 4096 is the default for most FS's) are filled with |
| 30 |
> nothing, and the heads need to pass over them to read the next block. |
| 31 |
> On a sparse file that space is merely reserved, it needn't actually |
| 32 |
> exist. Hope that helps you conceptualize the difference. |
| 33 |
|
| 34 |
I guess the idea is correct, but the details are questionable. The heads |
| 35 |
do not move over empty tails, the spinning disk does. A head just moves to |
| 36 |
the track that contains the required sectors. The head movement and disk |
| 37 |
spinning do not influence performance directly since there are many levels |
| 38 |
of caching between a physical read and an application. |
| 39 |
|
| 40 |
It looks like it takes much less buffer space to cache lots of small files |
| 41 |
when they are joined into a sparse file than when they are in a real file |
| 42 |
system, making sparse file very efficient. |
| 43 |
|
| 44 |
-- |
| 45 |
Andrei Gerasimenko |
| 46 |
-- |
| 47 |
gentoo-user@g.o mailing list |
Archives