[Bug 230260] [FUSE] [PERFORMANCE]: Performance issue (I/O block size)
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Wed Feb 20 23:10:28 UTC 2019
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230260
--- Comment #12 from Conrad Meyer <cem at freebsd.org> ---
(In reply to Kenneth D. Merry from comment #11)
I think you're on to something. Are you on a recent head, or a stable branch?
It looks like fuse_write_biobackend directly uses f_iosize:
625 const int biosize = fuse_iosize(vp);
but fuse_read_biobackend clamps the buf block len to MAXBSIZE:
191 const int biosize = fuse_iosize(vp);
...
201 bcount = MIN(MAXBSIZE, biosize);
Which is defined as 64kB on CURRENT (i.e., the block size is not truncated on
bio read when DFLTPHYS <= MAXBSIZE).
fuse's directio read path doesn't care about the freebsd block size or phys
size and just issues maximal reads per the mount point. Ditto io_strategy,
directio & bio write.
So it's just the bio read path that is artificially truncating 512kB phys to
64kB MAXBSIZE. I think maxbcachebuf must be >= 512k on your system, too, or
else we'd trip this panic in getblk on write:
3883 if (size > maxbcachebuf)
3884 panic("getblk: size(%d) > maxbcachebuf(%d)\n", size,
3885 maxbcachebuf);
(But perhaps the writes are hitting the directio write path that avoids the
large getblk.)
Anyway, once the blocks are truncated, the LBNs used by the cached read path
are nonsensical relative to what was written, and we end up discarding the last
(DFLTPHYS - MAXBSIZE) bytes of every DFLTPHYS-sized block.
I'm not exactly sure why the bioread loop aborts after only a single truncated
block. (I would guess either getblk() returning NULL on 2nd block, or getblk
marking the 2nd block !CACHEd and fuse_io_strategy() producing an error for
some reason.)
I think we have a clear culprit here. Please try replacing f_iosize = DFLTPHYS
with f_iosize = MAXBSIZE or maxbcachebuf; or increasing MAXBSIZE to match
DFLTPHYS.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-fs
mailing list