[systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE
nefelim4ag at gmail.com
Thu Aug 14 12:47:58 PDT 2014
>> Just completed TODO:
>> * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
>> ioctl, with START_IO
> Hmm, the patch is line broken...
> But this patch only replaces one ioctl with another right? It doesn't
> actually improve anything effectively, does it?
> I am not really convinced that we should make this change, maybe we
> should remove readahead from the the package instead...
On my machine it not get my any speed up (btrfs, hdd/ssd, latest arch).
But i already talk with ext4 developers, and one of devs try to port
e4rat functionally to ext progs and mainline kernel.
And as i think on ext4, we can port to readahead functional from ext
progs and defrag files what reading while boot, to one line on hdd.
But it function must be part of systemd?
2014-08-14 20:29 GMT+03:00 Lennart Poettering <lennart at poettering.net>:
> On Mon, 21.07.14 15:02, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
>> On Mon, Jul 21, 2014 at 09:38:57AM +0300, Timofey Titovets wrote:
>> > Just completed TODO:
>> > * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
>> This is still not an explanation. What is the difference between the
> The idea really was to just defrag the bits of files that we really
> needed instead of all of them...
On btrfs with compress mount option, we can't determine file
fragmented or not, i'm didn't deep read of btrfs progs while porting
BTRFS_IOC_DEFRAG_RANGE, but as i understand btrfs self defrag files
and BTRFS_IOC_DEFRAG_RANGE just add aditional filters to this
operation, but i can be wrong.
> Lennart Poettering, Red Hat
More information about the systemd-devel