bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Miklos Szeredi
Subject: Re: bug#6331: [sshfs] df reports wrong disk space usage on solaris
Date: Wed, 16 Jun 2010 11:35:35 +0200

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]