On Wed, Jul 18, 2012 at 09:18:49AM +0200, Francois Tigeot wrote: > > > I would also guess that sparse files are very rarely used. But for > > > disk usage purposes you want to consider real disk usage including > > > overhead because the quotas are mostly used to partition the available > > > space. That doesn't work if your quotas allow you to write a few > > > thousand files of 1 byte length that account together as a single > > > single block when they really occupy a few thousand blocks. > > > > A scenario in which they're frequently used is block-based file system > > transfer protocols (especially distributed ones where blocks may > > download in random order, including bittorrent), also by download > > managers that support "download optimization" where multiple > > connections will be made to transfer multiple file sections at a time > > (i.e. the DownloadThemAll Firefox extension). > > > > Another common usage of sparse files is for live file system images. > > The cost of creation (open/creat + trunk/lseek + newfs) is small > > compared to writing a full image of zeros, then the blocks can be > > lazily allocated and written when needed. > > And this last usage is one good reason to only count seek sizes and not > holes in files. Disk quotas can fill up suddenly when data is written to > what appears to be a perfectly sized device. > The potential for disruption of virtualized systems is very high in this > situation and it was deemed best to count the full file size at creation > time and avoid bad surprises.
It seems like a better way to address that problem would be to provide a scheme to allocate all the blocks in the image files you're concerned about. -- David A. Holland dholl...@netbsd.org
