Re: bug#6331: [sshfs] df reports wrong disk space usage on solaris

[Jim Meyering]

Miklos Szeredi wrote:
> On Wed, 16 Jun 2010, Jim Meyering wrote:
>> Miklos Szeredi wrote:
>> > On Thu, 03 Jun 2010, Miklos Szeredi wrote:
>> >> Hmm, actually "struct statfs" on linux does have f_frsize, only the
>> >> manpage doesn't document it.  So correct thing would be to use that,
>> >> no?
>> >
>> > Here's a patch that allows df(1) to correctly calculate the disk usage
>> > and displays f_frsize in stat(1).
>>
>> Hi Miklos,
>>
>> [Cc'ing bug-gnulib, since all but src/stat.c are from gnulib]
>>
>> Thank you for the patch.
>> However, I'm not sure it's portable enough.
>> Do you know when the f_frsize member began to be useful?
>
> It was introduced in the linux-2.5 timeframe, so from linux-2.6.0 on
> it contains useful information.  In 2.4.* and earlier it was part of
> the f_spare array and was zeroed out by the kernel.
>
> Checking f_spare value for zero and using f_bsize instead works fine
> for 2.4 and earlier kernels.

That sounds sufficient.
Can you confirm that this works on a 2.4.x kernel?
If so, I'll apply your changes to gnulib and coreutils.

>> Without knowing that, I cannot judge whether this introduces
>> a portability problem on older glibc, kernels or file systems.
>
> statfs() is (and probably always was) a straight syscall wrapper in
> glibc.  There's also statfs64 (used in case of _FILE_OFFSET_BITS=64)
> which is not necessarily a straight syscall, but has the same spare
> fields at the end of the structure.
>
>> Even merely knowing that is probably not enough.
>>
>> Given the lack of documentation for that member, I suspect
>> that any safe change would involve a run-time check to verify
>> that infrastructure is new enough that the member is usable.
>
> Already talked with the man pages maintainer about lack of
> documentation, and this will be fixed in new versions of the manual.
>
> In the end it's your call, but based on the level of backward
> compatibility built into the statfs structure I'd say such a change is
> perfectly safe.  And there's a real bug that needs to be fixed or
> worked around that boils down to df(1) using the wrong field for
> blocksize on linux.

Thanks.