Subject: Re: free space (was /dev) on tmpfs problem
To: Matthew Mondor <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 11/15/2005 14:55:43
Matthew Mondor wrote:
>On Tue, 15 Nov 2005 20:10:02 +0100
>Manuel Bouyer <firstname.lastname@example.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
/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
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