On Wed, Jan 27, 2010 at 09:57:08PM -0800, Bill Sommerfeld wrote: Hi Bill! :-)
> On 01/27/10 21:17, Daniel Carosone wrote: >> This is as expected. Not expected is that: >> >> usedbyrefreservation = refreservation >> >> I would expect this to be 0, since all the reserved space has been >> allocated. > > This would be the case if the volume had no snapshots. Hmm.... > The actual volume footprint is a bit less than half of the volume > size, but the refreservation ensures that there is enough free space > in the pool to allow me to overwrite every block of the zvol with > uncompressable data without any writes failing due to the pool being > out of space. Hmm.... this is new (to me) and undescribed (in the manpage) behaviour, but it does explain the observed behaviour. In other words, usedbyrefreservation includes blocks currently shared with snapshots, representing a reservation for potential future CoW of these blocks. Does this happen for filesystems, or only volumes? I hope it's both, but just more commonly encountered because refreserv is more commonly used with volumes. > If you were to disable time-based snapshots and then overwrite a measurable > fraction of the zvol you I'd expect "USEDBYREFRESERVATION" to shrink as > the reserved blocks were actually used. Right. If I repeat my quick test with snapshots, when the first snapshot is taken, I would see usedbyrefreservation jump back up to the full size of the volume. At that point the whole volume is shared with the snapshot. As data is overwritten, the space for the retained copy would be added to usedbysnapshots, and the space that's now unique to the dataset would come off usedbyrefreservation, with the used total staying constant - until another snapshot is taken. I'll do that for my own interest, but it now makes perfect sense and is quite reasonable. The trouble is the documentation doesn't point to this, so it's surprising and unexpected. There's text in the description of the refreservation property, about "snapshots will only be allowed if there's enough free space". What needs to be clear is that this is achieved by the behaviour of usedbyrefreservation, in part by additional text in the description of that property (that it includes space shared with snapshots), and partly by improving the wording about "free space" here. I'll see if I can knock together some better wording later. > If you want to allow for overcommit, you need to delete the refreservation. Of course, I just wasn't thinking of a taking a snapshot as having this cost, though of course it does. -- Dan.
pgphFn5Xr1E59.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
