Matthew Mondor wrote:

>On Tue, 15 Nov 2005 20:10:02 +0100
>Manuel Bouyer <bouyer@antioche.eu.org> wrote:
>
>  
>
>>>such that "Capacity" would always be 100% (except again where an option is
>>>used to specify the maximum allowed size)?
>>>
>>>If the number of bytes/blocks in use can be accounted by the FS, wouldn't
>>>it be simple to do it this way?
>>>      
>>>
>>This may break softwares that tries to see if they have enouth space before
>>writing a file.
>>    
>>
>
>I thought that tmpfs would mostly be used for /tmp, /dev or other
>similar filesystems on which this would not have been an important
>feature...
>  
>
/tmp is fairly general purpose.  I can see situations where programs
might want to check this before creating a *temporary* file.  (For
example, to provide an early indication of an out-of-disk condition
rather than waiting until write(2) fails.)

Of course, there is an uncloseable race here between statfs and write,
but I don't think we can argue that this makes statfs useless, either.

>If it's also used for more multipurpose use on a specific mountpoint, I
>thought at first that it would make sense for the admin to specify an
>upper limit there, and thus obtain proper df results, but this has
>problems, since we don't want to reserve that memory at mount time.
>
>An allowed upper bound would need to not exceed system constraints, and
>those unfortunately dynamically change at runtime.  After reflection I
>guess we have no choice but to somehow dynamically use actual remaining
>resources to evaluate remaining space at runtime like some others have
>suggested
>  
>
I think this is the case.  Also, I'll point out that this design doesn't
take place in a vacuum.  There are lots of other systems with tmpfs-like
filesystems on /tmp, and I don't think it is a good idea to start
breaking the semantics that folks have gotten used to.  Even if not 100%
accurate, df of /tmp should *try* to provide a rough estimate.

-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134