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