On Mon, Sep 12, 2016 at 12:45 PM Gregor Kopka < [email protected]> wrote:
> 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. > I'd be fine with a PR to add a new flag to "zfs rollback" for rolling back descendant filesystems. I'd be fine with a PR to add new flags to "zfs rollback" that are (less confusing) aliases for -r/-R. I'd be fine with a PR to add some instructive output to "zfs rollback -r/-R" to help users understand what it does, and inform them of the new flag for rolling back descendant filesystems. --matt ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Tfde1efecbc479881-M26fed7eae60ebcadfab3204b Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
