[Gluster-users] Request For Opinions: what to do about the synthetic statfvs "tweak"?
rtalur at redhat.com
Wed Mar 28 01:54:34 UTC 2018
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. 
> 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 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 
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
> 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!
> : https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11406
>  practically this will also imply f_frsize == f_bsize, because
> Linux filesystems usually adhere to this convention
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users