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
