Yes, I agree and that all sounds great (including "zfs set refreservation=auto" to get back to the originally-computed refreservation). A shame that we didn't catch this when implementing "zfs clone" back in the day.
I assume that refreservation will continue to be a non-inheritable property, and that "refreservation=auto" is just a shortcut for "refreservation=123GB" (or whatever the right number is). So if you set it to "auto", "zfs get" will show "123GB". And changing the volsize will do whatever it does today. I assume for filesystems, "refreservation=auto" will not reserve any space. --matt On Thu, Mar 15, 2018 at 12:32 PM, Mike Gerdts <[email protected]> wrote: > As described in Feature #9826, the handling of refreservation is rather > inconsistent across "zfs create" and "zfs clone". > > https://www.illumos.org/issues/9286 > > If we were in the design phase of "zfs clone", I think that it would be > clear that when cloning a volume the new volume should get the same > refreservation as the source volume. Since we are well past that, it seems > like the right approach is to make this more explicit. > > As such, I'm planning to implement: > > zfs clone <volsnap> <newvol> > - newvol is always sparse (no change from today) > > zfs clone -o refreservation=auto <volsnap> <newvol> > - newvol has refreservation that is a bit larger than that of the > snapshotted volume > > Does that sound reasonable? > > TIA, > Mike > *openzfs <https://openzfs.topicbox.com/latest>* / openzfs-developer > <https://openzfs.topicbox.com/groups/developer/members> / Permalink > <https://openzfs.topicbox.com/groups/developer/discussions/Te3d593ba00521b6d-M72264a5b0b3b107fd05021ba> > Delivery > options <https://openzfs.topicbox.com/groups> > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/Te3d593ba00521b6d-M76ca92ff1ad2d1d228c6fdb3 Delivery options: https://openzfs.topicbox.com/groups
