Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Feb 2019 23:10:24 +0000
From:      bugzilla-noreply@freebsd.org
To:        fs@FreeBSD.org
Subject:   [Bug 230260] [FUSE] [PERFORMANCE]: Performance issue (I/O block size)
Message-ID:  <bug-230260-3630-ryUtP4RQH1@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-230260-3630@https.bugs.freebsd.org/bugzilla/>
References:  <bug-230260-3630@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230260

--- Comment #12 from Conrad Meyer <cem@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 bran=
ch?

It looks like fuse_write_biobackend directly uses f_iosize:

625         const int biosize =3D fuse_iosize(vp);

but fuse_read_biobackend clamps the buf block len to MAXBSIZE:

191         const int biosize =3D fuse_iosize(vp);
...
201         bcount =3D MIN(MAXBSIZE, biosize);

Which is defined as 64kB on CURRENT (i.e., the block size is not truncated =
on
bio read when DFLTPHYS <=3D 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 >=3D 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 trunca=
ted
block.  (I would guess either getblk() returning NULL on 2nd block, or getb=
lk
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 =3D DF=
LTPHYS
with f_iosize =3D MAXBSIZE or maxbcachebuf; or increasing MAXBSIZE to match
DFLTPHYS.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230260-3630-ryUtP4RQH1>