[Gluster-devel] Request For Opinions: what to do about the synthetic statfvs "tweak"?

Csaba Henk chenk at redhat.com
Wed Mar 21 10:27:24 UTC 2018

Hi list,

We have an ancient hack that fuse not
just passes on the statvfs data it's getting
from the storage, but tweaks it by setting
f_bsize / f_frsize to values of its own
preference. [1]

The supposed advantage is that f_bsize
serves as a hint to applications for the
preferred io size. (And regarding f_frsize --
in Linux it's a historical workaround for
certain bugs in userspace[2] that f_bsize
and f_frsize are being kept equal.)

However, this has the side effect of
getting slightly different values for total
and used/free space of a volume when
accessed through libgfapi and when through
fuse -- because these values are multiples
of f_frsize, and libgfapi uses the native f_frsize
of the backend (typically 4k), while fuse provides
its synthetic f_frsize (typically 128k). So the
libfgapi provided sizes are more granular.

OTOH, I couldn't find any program in
standard Unix userspace where the
implementation commonly used in GNU/Linux
would rely on the f_bsize hint. It does not
mean there is none -- and then there is of course
the vast space of non-standard userland.

Possibiliities are:

1) retire the whole tweak and just pass on
   what we get from storage [3]
2) keep the f_bsize tweak, but drop the
   of f_frsize == f_bsize legacy workaround
   and take f_frsize from storage
3) keep everything as is, and put up with the
   fs stat divergence between transports
+1) make behaviors of 1) to 3) tunable --
      but I would not like to go this way in
      the spirit of KISS, unless absolutely a

Developers: do you know of any scenario where
we benefit from the f_bsize tweak?

- do you have any application that relies on f_bsize
  and benefits from its custom value?
- do you have any legacy application/stack
  where the f_frsize == f_bsize workaround is
  still needed (but GlusterFS  / RHGS is being kept
  up to date, so a change in this regard would hit
  your setup)?

Thanks for your thoughts!


[1]: https://github.com/gluster/glusterfs/blob/v4.0.0/xlators/mount/fuse/src/fuse-bridge.c#L3177-L3189
[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11406
[3] practically this will also imply f_frsize == f_bsize, because
     Linux filesystems usually adhere to this convention

More information about the Gluster-devel mailing list