Matthew Ahrens writes: > 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.
OK. It must just be me, then. I find the idea of "set version" to be a bit baffling. I'd expect that (if it did anything), setting the version would be forcing the system to lie about the current version number, rather than changing the on-disk version. It's sort of like seeing a variant on sysinfo(2) that can write to SI_RELEASE. I wouldn't expect that writing a number into there would cause the system to be upgraded. > 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. I see. I guess it doesn't bother me enough to complain more than that. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
