[Bug 230260] [FUSE] [PERFORMANCE]: Performance issue (I/O block size)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230260

--- Comment #4 from Conrad Meyer <cem at freebsd.org> ---
Doh, I totally missed some other hardcoded 4096 in the FUSE kernel support
code.  I see two instances:

1. fuse_internal_init_callback: if the fuse_init_out version is below 7.5, we
explicitly limit max_write to 4k.  Otherwise we take max_write from the fiio.

2. FUSE_DEFAULT_BLOCKSIZE , FUSE_DEFAULT_IOSIZE are both 4k.  Supposedly both
can be overridden per mount, but given they are macro defines, I don't see how
that is possible.


DEFAULT_IOSIZE is used to limit the size of FUSE_READDIR requests.  It is also
a factor in limiting max_readahead (16x).

DEFAULT_BLOCKSIZE is seemingly unused, except to fake FUSE_STATFS responses
(f_bsize) if the user filesystem seems dead.

I don't see either plumbed into ordinary read/write IO, though.


PAGE_SIZE (also 4k) shows up a few times as well:

1. Internal caching of fuse file (vnode) attributes hardcodes va_blocksize as
PAGE_SIZE.  I don't know the ramifications of this, if any.

2. Something around FUSE_READLINK operations restricts length to PAGE_SIZE. 
This doesn't seem like a problem.

3. fuse_vfsop_mount (VFS = operations on a filesystem, rather than on a
specific file (vnode)) hardcodes mnt_stat.f_iosize as PAGE_SIZE.  This may
matter.  It is the output of the fuse_iosize() function.

4. fuse_vnop_getpages walks through pages as part of the mmap interface.  I
don't think this is a problem.  Ditto fuse_vnop_putpages.


So yeah, (3) looks like it.  fuse_iosize() is used as a direct limit in
fuse_{read,write}_biobackend as well as fuse_io_strategy, and f_iosize is
widely used throughout the generic kernel code.

(It's also worth exploring bumping up the max READDIR size.  That's probably
not the problem you reported, but 4k is still anemic there.)

-- 
You are receiving this mail because:
You are the assignee for the bug.