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: <20180802165804.GA26891@thunk.org>
Date:   Thu, 2 Aug 2018 12:58:04 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     "Bean Huo (beanhuo)" <beanhuo@...ron.com>
Cc:     "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, 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.

As others have suggested using O_DIRECT reads will certainly allow the
128k reads to be passed all the way down to the device:

% dd if=/mnt/test  bs=128k count=32 iflag=direct | sum

results in the btrace output:

252,4    2      373  2339.068546832 21436  Q   R 416 + 256 [dd]
252,4    2      374  2339.070683655 21436  Q   R 672 + 256 [dd]
252,4    2      375  2339.072539850 21436  Q   R 928 + 256 [dd]
252,4    2      376  2339.074531103 21436  Q   R 1184 + 256 [dd]
	...

						- Ted