I take your point Mike. Yes, this seems to be an inconsistency in accounting.
I have simply become accustomed to this (esp. when dealing with virtual disk
images), so I just don't think about it, but it *is* harder to balance accounts.
For instance, if my guest cleans up it's vdisk by writing zeroes over free
space, then I expect "used" in the backing dataset to shrink, but the
compressratio doesn't change very much. The new zero bytes effectively go to
"available".
This leads back to my larger question -- is it possible to understand more
about what pool space is doing, given the currently available properties? I
think a couple of additions might be helpful for the admin to visualize what's
going on.
In particular, there should enough information visible to apply a consistent
view of the pool (either diluted or concentrated) within the same listing.
IMHO the outermost view should consider all space, including the sparse file
holes.
To put it another way, I agree that there should be a way to see where the
zeroes went. I don't need to see every sparse-file hole, but some ratio or
value should allow me to better estimate how "available" will change the next
time I write.
--------
Inapt analogy follows:
This is like fueling your vehicle. You don't get perfect information on
quantity (fuel expands when it's hot out), and then you increase speed, climb a
hill, open a window, get stuck in traffic, &c. How far can you safely drive?
You don't know exactly when the warning light will come on, but you watch the
needle ("available") at intervals. This is easy for the average driver, and
most tend not to get stranded. even while observing only one relative property.
So my guess is that -- with the information currently available -- monitoring a
large zpool could become a bit less precise, and more along the lines of "is it
close to the big E yet? Okay then find a filling station, or a place to stop".
IMHO enhancements to these properties would help many admins more accurately
understanding what will happen next to the available space, so that they don't
exhaust the available space faster than they expected or intended. -c
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
