Greg Troxel <g...@lexort.com> writes: > I ran into a test failure with bup, where it was restoring a sparse file > and trying to validate the resulting disk usage. It turns out that on > zfs (NetBSD 10), when you write a file, it shows as using 1 block and > then some seconds later shows as using the right amount. > > So: > > - why is it happening? > - is this a bug? > - if we think it's a bug, is it feasible to fix? > > A simple program to create files, n empty megabytes followed by 1 real > megabyte, for n in 0..9. And then to 'du' the file, every 1s for 30s, > not worrying about precise timing. > > I have a big ssd which is mostly a zfs type partition, and a pool with > just that. Nothing fancy. >
[snip] I am not overly surprised by this.. I have observed lazy / deferred operations with ZFS. I don't know if other ZFS implementations do this for sparse files, but you can see nearly the same effect when you 'zfs destroy ...' a large fileset. The space is returned to the pool slowly over time and you can see this with df, for example if the fileset was large enough and you are quick enough with df. I don't know why it does this, exactly, but I believe I saw SmartOS / Triton / OpenSolaris do this in the 'zfs destroy ...' case too. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
