Quota on tmpfs

[Thor Lancelot Simon]

On Wed, Jul 18, 2012 at 08:44:33AM +0200, Francois Tigeot wrote:
> 
> As far as I remember, potential application breakages concerns didn't come
> up when the decision was made to not specially handle sparse files.
> 
> I may have to it if the first implementation really causes problems in
> practice.
> 
> > Again, I am very curious whether you really have consensus from the
> > other Dragonfly developers in favor of this choice.
> 
> There was no consensus, but no strong opposition either.
> 
> Adding kernel@ to the discussion.

The other important point that came up yesterday, I think - perhaps
more important than mine - is that counting file length rather than
allocated blocks allows behaviors that can evade the quota system
and fill up the disk.  As Michael pointed out, filesystems have a
minimum allocation size.  For simplicity, let's talk about a FFS
filesystem with an 8K block and a 1K fragment.  If I open a file
and write one byte, under your scheme I am charged for only one
byte; but I actually consume 1K of disk space.  Do it 1,000
times, and I consume 1MB of space but am charged for only 1K.

So both because you can count too much (and break applications
that suddenly get impermissible errors from lseek) and count
too little (and charge applications for a byte instead of a
minimum allocation unit) this seems dubious indeed.

Thor