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.
