lkml.org 
[lkml]   [1999]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Long `rm` times.
Date
From


> I guess it's because of stupid design of ext2 indirect blocks. Indirect
> blocks are scattered over that 1G. Imagine how long it would take to read
> 4M of non-contignuous blocks in 1G file. When you delete it immediatelly,
> it's probably still in buffers.
>
> It would be much better to have pairs (position,length) instead of list of
> all blocks. This would
> - speed up bmap
> - save disk space
> - speed up delete & truncate
>
HPFS use position,length pairs. But its a tradeoff, not a clear win.

Consider the case of a huge file with lots of fragments. We want to
find block x in the last half of the file.

This is quick with ext2. No matter how fragmented, we calculate
one indirect block, read it, look up one direct block, read
it, and then we look up the disk block. The number of disk accesses
to find one particular block is fixed and low, fragmentation won't
matter.

We can do something similiar with pairs - the indirect block
would specify that the first direct block have pairs from 0 to x,
the next have pairs from x+1 to y and so on.

The amount of disk accesses would not increase with this scheme,
even with severe fragmentation. But it is more cpu intensive.
We must search the indirect
and direct blocks instead of doing a simple lookup.

Helge Hafting


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.066 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site