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
