James Carlson wrote: > Lin Ling writes: >> This is to make it consistent with the existing zfs version setting: >> >> zfs set version=n <dataset> >> zfs upgrade -V n <dataset> >> >> 'zpool upgrade' does more than just setting the version, > > Sure; understood. > >> it provides mechanism for listing pool versions as well. >> Having 2 ways to set the version seems reasonable to me. > > That's the question I'm asking. Why is that reasonable? It seems > odd.
Since we're exposing the both zfs and zpool "version" as a property, it makes sense to be able to change it with "zfs set". Since we've established the precedent of "zpool upgrade" (and it has additional capabilities, eg. "zpool upgrade -a" and "zfs upgrade -r"), it makes sense to have that as well. Granted, if we could redo the interface from scratch, it would probably be better to only change the version with "zfs/zpool set version"[*], and only get version information with "zfs/zpool upgrade" (or some more appropriately named subcommand). However, given that we can't change the existing "zpool upgrade" interface, this seems like the most self-consistent choice. --matt [*] The "set" subcommands would require some enhancements, eg since we don't have "zfs set -r" but we want "zfs upgrade -r" functionality. So this isn't quite as straightforward as it might first appear.
