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>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
