Re: Request For Opinions: what to do about the synthetic statfvs "tweak"?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed 21 Mar, 2018, 3:57 PM Csaba Henk, <chenk@xxxxxxxxxx> wrote:
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]

I prefer the above. It makes libgfapi and fuse consistent. 


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
      demand

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

Users:
- 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!

Regards,
Csaba

[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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux