Re: [PATCH][RFC] Rearranging files to improve disk performanc

[Phillip Susi <psusi@cfl.rr.com>]

This ability is already available at least for ext2/3 in the old defrag 
package, which can take a list of files and priorities to assign to 
them, and it will pack them in the order given at the start of the disk.

As for your idea, if there is going to be online defrag support in the 
kernel ( and yes, this is a form of defragmenting ) I'd rather see the 
ability to move files around deterministically rather than just give a 
hint and pray, similar to how windows handles online defragmenting.

Török Edvin wrote:
> Hello,
> 
> I am trying to implement a feature in the kernel to allow rearranging
> files on the disk in order to improve performance.
> The purpose is to reduce seeks. Before you say:"we don't need
> defragmenting", note that this is _not_ defragmenting.
> 
> This is what I want to accomplish:
> - a userspace program determines in what order are files accessed
> (during boot, startup, etc.), and generates a list of files that are
> always accessed
> in a certain order
> - rearranging these files to be one-after-another will improve disk
> performance (it won't have to seek forward/backward)
> 
> This is how I suggest to implement it:
> - a userspace program gives a 'hint' to the kernel where  certain
> files should be placed
> [it opens the file, sends the kernel a hint, copies the file to a temp
> storage, truncates, and rewrites file: thus the file will end up in a
> new location]
> - when the kernel allocates space for inodes, it first verifies if
> there is a 'hint' for that inode, if there is, it tries to honor it
> - there has to be a way to communicate between kernel/userspace the
> following: userspace->kernel: which file should be placed where,
> kernel->userspace: if it managed to honor userspace hints or not
> 
> 
> The following questions came up while developing this:
> - what exactly should the 'hint' contain (I chose: inode, device, disk
> location, size)
> - how should the userspace program communicate with the kernel? (I
> chose sysfs for now)
> - if sysfs is going to be used, in which directory should files be put?
> - should the kernel also preallocate space when receiving a hint
> - how should errors be reported? (sysfs?)
> - where is the appropriate place to put this stuff? (fs/relayout.c?)
> - how can the implementation be as generic as possible (have as much
> fs-independent code as possible)
> - what can we do if there isn't enough contigous free disk space
> available for moving the file (risk fragmenting the file?)
> - is somebody else currently trying to implement a similar feature?
> 
> The patch below also contains a sample of how the relayout functions
> could be used, in this case for reiserfs. (I intend to have support
> for at least
> ext3, and xfs too, but of course ideal would be if all fs-s would 
> support this)
> 
> 
> I am sending this patch (a draft), and waiting for your feedback on it
> (and on my questions above), before going any further.
> 
<snip>