* [fuse] Why is readahead=0 limiting read size?
@ 2020-03-21 13:39 Nikolaus Rath
2020-03-26 10:38 ` Miklos Szeredi
0 siblings, 1 reply; 2+ messages in thread
From: Nikolaus Rath @ 2020-03-21 13:39 UTC (permalink / raw)
To: linux-fsdevel, fuse-devel
Hello,
When issuing a 16 kB read request from userspace and the default FUSE
readahead settings, data is read in batches of 32k:
$ example/passthrough_ll -d mnt
FUSE library version: 3.9.1
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.27
flags=0x003ffffb
max_readahead=0x00020000
INIT: 7.31
flags=0x0000f439
max_readahead=0x00020000
max_write=0x00020000
max_background=0
congestion_threshold=0
time_gran=1
unique: 1, success, outsize: 80
unique: 2, opcode: LOOKUP (1), nodeid: 1, insize: 44, pid: 20822
lo_lookup(parent=1, name=bin)
1/bin -> 140290677541808
unique: 2, success, outsize: 144
unique: 3, opcode: LOOKUP (1), nodeid: 140290677541808, insize: 45, pid: 20822
lo_lookup(parent=140290677541808, name=bash)
140290677541808/bash -> 140290677542048
unique: 3, success, outsize: 144
unique: 4, opcode: OPEN (14), nodeid: 140290677542048, insize: 48, pid: 20822
lo_open(ino=140290677542048, flags=32768)
unique: 4, success, outsize: 32
unique: 5, opcode: FLUSH (25), nodeid: 140290677542048, insize: 64, pid: 20822
unique: 5, success, outsize: 16
unique: 6, opcode: READ (15), nodeid: 140290677542048, insize: 80, pid: 20822
lo_read(ino=140290677542048, size=32768, off=0)
unique: 6, success, outsize: 32784
unique: 7, opcode: FLUSH (25), nodeid: 140290677542048, insize: 64, pid: 20822
unique: 7, success, outsize: 16
unique: 8, opcode: RELEASE (18), nodeid: 140290677542048, insize: 64, pid: 0
unique: 8, success, outsize: 16
However, when disabling readahead, the read size decreases to 4k:
$ example/passthrough_ll -d mnt
FUSE library version: 3.9.1
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.27
flags=0x003ffffb
max_readahead=0x00020000
INIT: 7.31
flags=0x0000f439
max_readahead=0x00000000
max_write=0x00020000
max_background=0
congestion_threshold=0
time_gran=1
unique: 1, success, outsize: 80
unique: 2, opcode: LOOKUP (1), nodeid: 1, insize: 44, pid: 20911
lo_lookup(parent=1, name=bin)
1/bin -> 140509922200528
unique: 2, success, outsize: 144
unique: 3, opcode: LOOKUP (1), nodeid: 140509922200528, insize: 45, pid: 20911
lo_lookup(parent=140509922200528, name=bash)
140509922200528/bash -> 140510056418784
unique: 3, success, outsize: 144
unique: 4, opcode: OPEN (14), nodeid: 140510056418784, insize: 48, pid: 20911
lo_open(ino=140510056418784, flags=32768)
unique: 4, success, outsize: 32
unique: 5, opcode: FLUSH (25), nodeid: 140510056418784, insize: 64, pid: 20911
unique: 5, success, outsize: 16
unique: 6, opcode: READ (15), nodeid: 140510056418784, insize: 80, pid: 20911
lo_read(ino=140510056418784, size=4096, off=0)
unique: 6, success, outsize: 4112
unique: 7, opcode: READ (15), nodeid: 140510056418784, insize: 80, pid: 20911
lo_read(ino=140510056418784, size=4096, off=4096)
unique: 7, success, outsize: 4112
unique: 8, opcode: READ (15), nodeid: 140510056418784, insize: 80, pid: 20911
lo_read(ino=140510056418784, size=4096, off=8192)
unique: 8, success, outsize: 4112
unique: 9, opcode: READ (15), nodeid: 140510056418784, insize: 80, pid: 20911
lo_read(ino=140510056418784, size=4096, off=12288)
unique: 9, success, outsize: 4112
unique: 10, opcode: FLUSH (25), nodeid: 140510056418784, insize: 64, pid: 20911
unique: 10, success, outsize: 16
unique: 11, opcode: RELEASE (18), nodeid: 140510056418784, insize: 64, pid: 0
unique: 11, success, outsize: 16
Is that intentional? If so, why?
Is there any way to get larger read requests without also enabling
readahead?
(I am generating the userspace request with
$ dd if=<mountpoint>/bin/bash of=/dev/null bs=16k count=1)
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [fuse] Why is readahead=0 limiting read size?
2020-03-21 13:39 [fuse] Why is readahead=0 limiting read size? Nikolaus Rath
@ 2020-03-26 10:38 ` Miklos Szeredi
0 siblings, 0 replies; 2+ messages in thread
From: Miklos Szeredi @ 2020-03-26 10:38 UTC (permalink / raw)
To: linux-fsdevel, fuse-devel
On Sat, Mar 21, 2020 at 2:40 PM Nikolaus Rath <Nikolaus@rath.org> wrote:
>
> Hello,
>
> When issuing a 16 kB read request from userspace and the default FUSE
> readahead settings, data is read in batches of 32k:
>
> $ example/passthrough_ll -d mnt
> FUSE library version: 3.9.1
> unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
> INIT: 7.27
> flags=0x003ffffb
> max_readahead=0x00020000
> INIT: 7.31
> flags=0x0000f439
> max_readahead=0x00020000
> max_write=0x00020000
> max_background=0
> congestion_threshold=0
> time_gran=1
> unique: 1, success, outsize: 80
> unique: 2, opcode: LOOKUP (1), nodeid: 1, insize: 44, pid: 20822
> lo_lookup(parent=1, name=bin)
> 1/bin -> 140290677541808
> unique: 2, success, outsize: 144
> unique: 3, opcode: LOOKUP (1), nodeid: 140290677541808, insize: 45, pid: 20822
> lo_lookup(parent=140290677541808, name=bash)
> 140290677541808/bash -> 140290677542048
> unique: 3, success, outsize: 144
> unique: 4, opcode: OPEN (14), nodeid: 140290677542048, insize: 48, pid: 20822
> lo_open(ino=140290677542048, flags=32768)
> unique: 4, success, outsize: 32
> unique: 5, opcode: FLUSH (25), nodeid: 140290677542048, insize: 64, pid: 20822
> unique: 5, success, outsize: 16
> unique: 6, opcode: READ (15), nodeid: 140290677542048, insize: 80, pid: 20822
> lo_read(ino=140290677542048, size=32768, off=0)
> unique: 6, success, outsize: 32784
> unique: 7, opcode: FLUSH (25), nodeid: 140290677542048, insize: 64, pid: 20822
> unique: 7, success, outsize: 16
> unique: 8, opcode: RELEASE (18), nodeid: 140290677542048, insize: 64, pid: 0
> unique: 8, success, outsize: 16
>
>
> However, when disabling readahead, the read size decreases to 4k:
>
>
> $ example/passthrough_ll -d mnt
> FUSE library version: 3.9.1
> unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
> INIT: 7.27
> flags=0x003ffffb
> max_readahead=0x00020000
> INIT: 7.31
> flags=0x0000f439
> max_readahead=0x00000000
> max_write=0x00020000
> max_background=0
> congestion_threshold=0
> time_gran=1
> unique: 1, success, outsize: 80
> unique: 2, opcode: LOOKUP (1), nodeid: 1, insize: 44, pid: 20911
> lo_lookup(parent=1, name=bin)
> 1/bin -> 140509922200528
> unique: 2, success, outsize: 144
> unique: 3, opcode: LOOKUP (1), nodeid: 140509922200528, insize: 45, pid: 20911
> lo_lookup(parent=140509922200528, name=bash)
> 140509922200528/bash -> 140510056418784
> unique: 3, success, outsize: 144
> unique: 4, opcode: OPEN (14), nodeid: 140510056418784, insize: 48, pid: 20911
> lo_open(ino=140510056418784, flags=32768)
> unique: 4, success, outsize: 32
> unique: 5, opcode: FLUSH (25), nodeid: 140510056418784, insize: 64, pid: 20911
> unique: 5, success, outsize: 16
> unique: 6, opcode: READ (15), nodeid: 140510056418784, insize: 80, pid: 20911
> lo_read(ino=140510056418784, size=4096, off=0)
> unique: 6, success, outsize: 4112
> unique: 7, opcode: READ (15), nodeid: 140510056418784, insize: 80, pid: 20911
> lo_read(ino=140510056418784, size=4096, off=4096)
> unique: 7, success, outsize: 4112
> unique: 8, opcode: READ (15), nodeid: 140510056418784, insize: 80, pid: 20911
> lo_read(ino=140510056418784, size=4096, off=8192)
> unique: 8, success, outsize: 4112
> unique: 9, opcode: READ (15), nodeid: 140510056418784, insize: 80, pid: 20911
> lo_read(ino=140510056418784, size=4096, off=12288)
> unique: 9, success, outsize: 4112
> unique: 10, opcode: FLUSH (25), nodeid: 140510056418784, insize: 64, pid: 20911
> unique: 10, success, outsize: 16
> unique: 11, opcode: RELEASE (18), nodeid: 140510056418784, insize: 64, pid: 0
> unique: 11, success, outsize: 16
>
>
>
> Is that intentional? If so, why?
There are two cached read methods that linux filesystems can
implement: readpage (mandatory) and readpages (optional). The second
one is called by the readahead code, and that's the one which can
generate multi page read requests. The first one is called in all
other cases, so that's the one that will be called with readahead
disabled.
>
> Is there any way to get larger read requests without also enabling
> readahead?
Only using direct I/O.
Thanks,
Miklos
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-03-26 10:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-21 13:39 [fuse] Why is readahead=0 limiting read size? Nikolaus Rath
2020-03-26 10:38 ` Miklos Szeredi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).