Gluster users - Mar 2018 - Request For Opinions: what to do about the synthetic statfvs "tweak"?

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
      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

On Wed 21 Mar, 2018, 3:57 PM Csaba Henk, <chenk at redhat.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20180328/174fc6fc/attachment.html>