Am 08.09.2016 um 19:21 schrieb Joshua M. Clulow: > On 8 September 2016 at 00:25, Gregor Kopka > <[email protected]> wrote: >> Tying that option name change to a system tuneable >> (zfs.rollback-recursive-syntax) which can be used to walk through the >> steps of the proposal >> (as-is|deprecate-r|deprecate-r-and-warn|remove-r|r-is-really-recursive-now) >> with a sane default (as-is|deprecate-r|deprecate-r-and-warn). >> >> Then someone who read the changelog/documentation can opt to set the >> tuneable to live in a better future while someone who dosn't want it >> (for whatever reason) can set it to freeze the option naming to an >> eternal past and the curious can set it to test if a system will bomb >> somewhere. And should, some day, the decision be made to 'officially' >> cure this interface inconsistency it can be done by changing the default >> (without breaking scripts for people who read the documentation). > People that read the documentation already have all of the information > they need with the options as they are today. If there's any argument > for changing an existing flag, I think it's that people who _don't_ > read the documentation might be less likely to get behaviour that they > don't expect. Rollback is such a nuanced operation, though, that I > don't really expect any usage without consulting the documentation > will entirely align with intuition. > > Having a tuneable that changes the behaviour of the flags means that > operators and tool builders will need to deal not _just_ with the > passage of time, or the release of new versions of operating systems, > but also with the dynamic configuration of every system at run time. > This is likely to cause much more pain than the relatively minor (and > arguably subjective) problem of a potentially unexpected choice of > flag. Tool builders would have to deal with it only once by switching from current -r/-R to (whatever function-identical is put up for them) and adding --recursive (if they want that).
Admins: as long as they stick to the default they would be good for the first 11 years (then their scripts fail because -r/-R vanishes), in case they change the default they would be where they want to be for eternity. Users: Since using ZFS I havn't encountered a use case to rollback one dataset while keeping the child datasets at their current state, so I don't have a clue if anyone would be impacted by it at all. >> Nevertheless, I still don't see the need for later generations (zfs = >> futureproof) encountering the fallout of a bad decision of someone >> (possibly) long dead by then, and though I would like to see the change >> sooner than later the 'reasonable time' I though about was more towards >> years to give time to adapt to the change. > At this point, the "-r" and "-R" flags to "zfs rollback" appear to > have been in the ZFS code since integration in 2005. If we were to > deprecate this flag -- which I don't think we should! -- we would > arguably need to wait at _least_ another 11 years before removing it, > to give people as much time to notice its passing as they had to > internalise its arrival. Then, similarly, another 11 years after that > before replacing it with some other functionality. It seems more > practical to accept that it is by now a committed interface and focus > on new flags and features. 22 years in total... I'm think good with that, it would be nice to see this inconsistency go away some weeks prior to my retirement (if there is any then) and it would be have been worth the wait. Question is: would a pull request for this functionality (irrelevant of if the default would get changed from current behaviour to something else at some point or not) would be accepted at all. Gregor ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
