<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed 21 Mar, 2018, 3:57 PM Csaba Henk, <<a href="mailto:chenk@redhat.com">chenk@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi list,<br>
<br>
We have an ancient hack that fuse not<br>
just passes on the statvfs data it's getting<br>
from the storage, but tweaks it by setting<br>
f_bsize / f_frsize to values of its own<br>
preference. [1]<br>
<br>
The supposed advantage is that f_bsize<br>
serves as a hint to applications for the<br>
preferred io size. (And regarding f_frsize --<br>
in Linux it's a historical workaround for<br>
certain bugs in userspace[2] that f_bsize<br>
and f_frsize are being kept equal.)<br>
<br>
However, this has the side effect of<br>
getting slightly different values for total<br>
and used/free space of a volume when<br>
accessed through libgfapi and when through<br>
fuse -- because these values are multiples<br>
of f_frsize, and libgfapi uses the native f_frsize<br>
of the backend (typically 4k), while fuse provides<br>
its synthetic f_frsize (typically 128k). So the<br>
libfgapi provided sizes are more granular.<br>
<br>
OTOH, I couldn't find any program in<br>
standard Unix userspace where the<br>
implementation commonly used in GNU/Linux<br>
would rely on the f_bsize hint. It does not<br>
mean there is none -- and then there is of course<br>
the vast space of non-standard userland.<br>
<br>
Possibiliities are:<br>
<br>
1) retire the whole tweak and just pass on<br>
what we get from storage [3]<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I prefer the above. It makes libgfapi and fuse consistent. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) keep the f_bsize tweak, but drop the<br>
of f_frsize == f_bsize legacy workaround<br>
and take f_frsize from storage<br>
3) keep everything as is, and put up with the<br>
fs stat divergence between transports<br>
+1) make behaviors of 1) to 3) tunable --<br>
but I would not like to go this way in<br>
the spirit of KISS, unless absolutely a<br>
demand<br>
<br>
Developers: do you know of any scenario where<br>
we benefit from the f_bsize tweak?<br>
<br>
Users:<br>
- do you have any application that relies on f_bsize<br>
and benefits from its custom value?<br>
- do you have any legacy application/stack<br>
where the f_frsize == f_bsize workaround is<br>
still needed (but GlusterFS / RHGS is being kept<br>
up to date, so a change in this regard would hit<br>
your setup)?<br>
<br>
Thanks for your thoughts!<br>
<br>
Regards,<br>
Csaba<br>
<br>
[1]: <a href="https://github.com/gluster/glusterfs/blob/v4.0.0/xlators/mount/fuse/src/fuse-bridge.c#L3177-L3189" rel="noreferrer noreferrer" target="_blank">https://github.com/gluster/glusterfs/blob/v4.0.0/xlators/mount/fuse/src/fuse-bridge.c#L3177-L3189</a><br>
[2]: <a href="https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11406" rel="noreferrer noreferrer" target="_blank">https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11406</a><br>
[3] practically this will also imply f_frsize == f_bsize, because<br>
Linux filesystems usually adhere to this convention<br>
</blockquote></div></div></div>