ahrens commented on this pull request.
> Consequently, writes to a sparse volume can fail with
.Er ENOSPC
when the pool is low on space.
For a sparse volume, changes to
.Sy volsize
are not reflected in the reservation.
+A volume that is not sparse is said to be
+.Qq thick provisioned .
+A sparse volume can become thick provisioned
+by setting the reservation to
I think this should say `refreservation`. You'd only use the reservation on
ancient-version pools (as you noted elsewhere).
> + }
+
+ props = fnvlist_alloc();
+
+ fnvlist_add_uint64(props, zfs_prop_to_name(ZFS_PROP_VOLBLOCKSIZE),
+ zfs_prop_get_int(zhp, ZFS_PROP_VOLBLOCKSIZE));
+
+ if (nvlist_lookup_uint64(nvl, zfs_prop_to_name(ZFS_PROP_VOLSIZE),
+ &volsize) != 0) {
+ volsize = zfs_prop_get_int(zhp, ZFS_PROP_VOLSIZE);
+ }
+
+ resvsize = zvol_volsize_to_reservation(volsize, props);
+ fnvlist_free(props);
+
+ if (nvlist_add_uint64(nvl, zfs_prop_to_name(prop), resvsize) != 0) {
This assumes that the `nvl` is `NV_UNIQUE_*`. Which it probably is, but it
still might be a good idea to explicitly remove the existing entry.
> @@ -1250,6 +1252,33 @@ zprop_parse_value(libzfs_handle_t *hdl, nvpair_t
> *elem, int prop,
prop == ZFS_PROP_SNAPSHOT_LIMIT)) {
*ivalp = UINT64_MAX;
}
+
+ /*
+ * Special handling for setting 'reservation' and
+ * 'refreservation' to 'auto'. Use UINT64_MAX to tell the
`reservation=auto` sets it to an amount that's intended to be volsize+metadata,
thus preventing a write from failing. But if there are snapshots, they will
consume the reservation and then the write could fail. So I wonder if we really
want to support `reservation=auto`. I don't think there's a valid use case
aside from version<9 pools which don't support refreservation, and at this
point I think it's reasonable to expect folks to upgrade to version 9 or later
if they want the latest features. I think we risk confusion / accidental
misuse if we make it easy to set a reservation that probably doesn't do what
they want.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/592#pullrequestreview-105057776
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/discussions/Tcf29132d758782be-Md187be0ca4744181a7a7f80c
Delivery options: https://openzfs.topicbox.com/groups