lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <451836CC.2010003@cfl.rr.com>
Date:	Mon, 25 Sep 2006 16:06:36 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Török Edvin <edwintorok@...il.com>
CC:	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: [PATCH][RFC] Rearranging files to improve disk performanc

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ