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

[Raghavendra Talur]

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>