linux-ext4 - Re: [EXT] Re: how to disable readahead

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: <20180912151303.GA32355@quack2.suse.cz>
Date:   Wed, 12 Sep 2018 17:13:03 +0200
From:   Jan Kara <jack@...e.cz>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     "Bean Huo (beanhuo)" <beanhuo@...ron.com>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "beanhuo.linux@...gle.com" <beanhuo.linux@...gle.com>
Subject: Re: [EXT] Re: how to disable readahead

On Thu 02-08-18 12:58:04, Theodore Y. Ts'o wrote:
> On Thu, Aug 02, 2018 at 01:56:41PM +0000, Bean Huo (beanhuo) wrote:
> > 
> > I am newbie on ext4, I tried the above method to disable readahead,
> > echo 0 > /sys/block/<dev>/queue/read_ahead_kb Then I read by 128kB
> > chunk size, ext4 will read the file by 4KB chunk size each
> > time. that means ext4 splits 128KB into 32 4KB to read.  That's not
> > my expectation.  Do you know how to still keep and let ext4 read by
> > 128KB in case of disable readahead?
> 
> Hmm... that's not my expectation as well, but I've replicated your
> results.  More interestingly, I tried the same experiment using XFS,
> and it does the same thing.  I used as my test workload:
> 
> dd if=/mnt/test bs=128k count=32 | sum
> 
> Used strace to verify that dd was in fact issuing 128k reads:
> 
> read(0, "\377\253a)\307\10\230\6\360,,:\226Rq\204\343\2522&44\307\341\372\271\271/\224#?\346"..., 131072) = 131072
> write(1, "\377\253a)\307\10\230\6\360,,:\226Rq\204\343\2522&44\307\341\372\271\271/\224#?\346"..., 131072) = 131072
> 
> And then used btrace to monitor the I/O requests sent to the device:
> 
> 252,4    0      413     0.077274997 14645  Q   R 4408 + 8 [dd]
> 252,4    2       77     0.077355648  5529  C   R 4408 + 8 [0]
> 252,4    0      414     0.077393725 14645  Q   R 4416 + 8 [dd]
> 252,4    2       78     0.077630722  5529  C   R 4416 + 8 [0]
> 	...
> 
> ... and indeed, the reads are being sent to the device in 4k chunks.
> That's indeed surprising.  I'd have to do some debugging with
> tracepoints to see what requests are being issued from the
> mm/filemap.c to the file system.

And this is in fact expected. There are two basic ways how data can appear
in page cache: ->readpage and ->readpages filesystem callbacks. The second
one is what readahead (and only readahead) uses, the first one is used as a
fallback when readahead fails for some reason. So if you disable readahead,
you're left only with ->readpage call which does only one-page (4k) reads.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR