Colin Walters wrote:
>>I'm almost positive it requires kernel changes to do this
the right way;
>>one naive idea is to have a userspace daemon, capturing what blocks are
>>read when (kernel tells this daemon using the kernel events layer). This
>>would run in the first three minutes on each and every boot. When the
>>system is idle (and only when running on AC power!) another daemon
>>rearranges blocks on the disk. What blocks to rearrange could be the
>>result of a computation involving several three-minute result sets.
>>
>>
>Rearranging sounds complex and dangerous, since it requires deep
>integration with the filesystem. The online resizing took quite a long
>time to appear and that is conceptually much simpler. Why not do it on
>the block device layer (without knowledge of the filesystem) and just
>copy those blocks to a reserved area of the block device? Disks are
>big, duplicating say 100MB for this purpose wouldn't be bad.
>
>
Doing the rearranging at the block level has several advantages:
- We don't need to have this thread again (and don't need to apply
another hack) when people realizes that OpenOffice *also* needs
disk rearranging to start faster.
- It is a general speedup across the system
- If the disk blocks are generally arranged in such a way that
blocks accessed together are close together, then readahead
in the kernel becomes a matter of just reading further ahead
*on the disk* instead of as now reading further ahead in the file.
- when a set of blocks are read in, the VM system knows that
those blocks are likely to be needed soon, so it can consider
it a bad idea to throw those pages away.
Søren