The two sides of reflink()

Posted May 6, 2009 9:02 UTC (Wed) by epa (subscriber, #39769)
In reply to: The two sides of reflink() by amw
Parent article: The two sides of reflink()

Because if you make a reflink to a file, and your quota is unaffected, you might later find that when simply changing the contents of the reflink (without making it any larger) your quota is exhausted. Userspace really doesn't expect that a seemingly harmless operation like changing one byte in the middle of a file could suddenly exhaust quota or free disk space.

That said, it makes no sense to account disk quota conservatively while lying about the amount of free space really available. The two should be treated the same, so if reflinking a large file has no effect on the reported free space, it shouldn't cost quota either.

The two sides of reflink()

Posted May 6, 2009 9:22 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Any userspace that does not expect write() in the middle of a file to
potentially fail with -ENOSPC is broken. Such write()s can fail even now
thanks to sparse files. It is true that currently userspace can rely on
the second write() in a ftell()/write()/fseek()/write() sequence not
failing, but this seems a rather thin thing to rely on, to me.

The two sides of reflink()

Posted May 6, 2009 10:42 UTC (Wed) by epa (subscriber, #39769) [Link]

Thanks for pointing this out. So if currently, creating a 10 gigabyte sparse file does not subtract 10 gigs from your quota nor from the free space report, giving the possibility that writing to the middle of an existing file can run out of space, then making a reflink to a 10 gig file should be treated the same way. There is precedent.

The two sides of reflink()

Posted May 6, 2009 12:33 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

Even worse, if I reflink() a file of yours, and yout then change it (or delete it, whatever) suddenly my quota goes up without any action on my part.