Frank Hofmann wrote:
> On Wed, 29 Aug 2007, Chris Kirby wrote:
> 
> [ ... ]
> 
>> None of {ZFS,QFS,UFS} even bother to grab a lock in their statvfs
>> handlers, so as Boyd Adamson correctly pointed out, all of the statvfs
>> values are rumors at best anyway.
> 
> 
> That is not correct for UFS. This piece:
> 
>         /*
>          * Adjust the numbers based on things waiting to be deleted.
>          * modifies f_bfree and f_ffree.  Afterwards, everything we
>          * come up with will be self-consistent.  By definition, this
>          * is a point-in-time snapshot, so the fact that the delete
>          * thread's probably already invalidated the results is not a
>          * problem.  Note that if the delete thread is ever extended to
>          * non-logging ufs, this adjustment must always be made.
>          */
>         if (TRANS_ISTRANS(ufsvfsp))
>                 ufs_delete_adjust_stats(ufsvfsp, sp);
> 
> in ufs_statvfs() is grabbing locks. And it was introduced because some 
> "nitpickers" claimed guaranteed point-in-time consistency of statvfs() 
> is mandated by the standards, and arguing that "the values are out of 
> date as soon as the syscall returns no matter what" wouldn't matter in 
> that context. 

Ouch, that's expensive.

I still can't find a reference showing that the standards
actually require that sort of behavior.  In fact, there doesn't
seem to be a lot of information about what *is* required of statvfs
by the standards.

One interesting quote is from Apple's statvfs(3) man page:

STANDARDS
The statvfs() and fstatvfs() functions conform to IEEE Std 1003.1-2001
(``POSIX.1'').  As standardized, portable applications cannot depend on
these functions returning any valid information at all.  This
implementation attempts to provide as much useful information as is
provided by the underlying file system, subject to the limitations of
the specified data types.


Another is from the Open Group page on statvfs:
http://www.opengroup.org/onlinepubs/000095399/functions/statvfs.html

"It is unspecified whether all members of the statvfs structure have
meaningful values on all file systems."


I suspect that the conformance tests for statvfs are a bit
overzealous in their expectations.

-Chris


Reply via email to