hey all, in both nevada and opensolaris, the zones infrastructure tries to leverage zfs where ever possible. we take advantage of snapshotting and cloning for things like zone cloning and zone be management. because of this, we''ve recently run into multiple scenarios where a zoneadm uninstall fails. 6787557 zoneadm uninstall fails when zone has zfs clones http://bugs.opensolaris.org/view_bug.do?bug_id=6787557 7491 problems destroying zones with cloned dependents http://defect.opensolaris.org/bz/show_bug.cgi?id=7491 these failures occur when we try to destroy the zfs filesystem associated with a zone, but that filesystem has been snapshotted and cloned. the way we''re fixing these problems is by doing a promotion before the destroy. jerry has fixed 6787557 for nevada in zoneadm, but now i''m looking at having to re-implement a similar fix for opensolaris in the ipkg brand for 7491. hence, i''m wondering if it would make more sense just to add this functionality directly into zfs(1m)/libzfs. this would involve enhancements to the zfs promote and destroy subcommands. here''s what i''m thinking. the first component would be a new "-t <template>" option to zfs promote. this option would instruct zfs promote to check for snapshot naming collisions between the origin and promotion target filesystems, and to rename any origin filesystem snapshots with conflicting names before attempting the promotion. the conflicting snapshots will be renamed to <template>XXX, where XXX is an integer used to make the snapshot name unique. today users have to do this renaming manually if they want the promotion to succeed. to illustrate how this new functionality would work, say i have the following filesystems/snapshots: tank/zones/zone1 tank/zones/zone1 at SUNWzone1 tank/zones/zone1 at user1 tank/zones/zone2 (clone of tank/zones/zone1 at SUNWzone1) tank/zones/zone2 at SUNWzone1 if i do a "zfs promote -t SUNWzone tank/zones/zone2", then this would involved a rename of zone1 at SUNWzone1 to zone1 at SUNWzone2, and a promotion of tank/zones/zone2. the @user1 snapshot would not be renamed because there was no naming conflict with the filesystem being promoted. hence i would end up with: tank/zones/zone2 tank/zones/zone2 at SUNWzone1 tank/zones/zone2 at SUNWzone2 tank/zones/zone2 at user1 tank/zones/zone1 (clone of tank/zones/zone2 at SUNWzone2) if i did a "zfs promote -t user tank/zones/zone2", then this would this involved a rename of zone1 at SUNWzone1 to zone1 at user2, and then a promotion of tank/zones/zone2. hence i would end up with: tank/zones/zone2 tank/zones/zone2 at SUNWzone1 tank/zones/zone2 at user1 tank/zones/zone2 at user2 tank/zones/zone1 (clone of tank/zones/zone2 at user2) the second component would be two new flags to zfs destroy: zfs destroy [-p [-t <template>]] the -p would instruct zfs destroy to try to promote the oldest clone of the youngest snapshot of the filesystem being destroyed before doing the destroy. if the youngest filesystem doesn''t have a clone, the command will fail unless -r was specified. if -r was specified we will continue to look through snapshot from youngest to oldest looking for the first one with a clone. if a snapshot with a clone is found, the oldest clone will be promoted before the destroy. if a template was specified via -t, this will be passed through to the promote operation. thoughts? ed
Ed, "zfs destroy [-r] -p" sounds great. I''m not a big fan of the "-t template". Do you have conflicting snapshot names due to the way your (zones) software works, or are you concerned about sysadmins creating these conflicting snapshots? If it''s the former, would it be possible to change the zones software to avoid it? But overall, this sounds pretty reasonable. Could you file an RFE? --matt Edward Pilatowicz wrote:> hey all, > > in both nevada and opensolaris, the zones infrastructure tries to > leverage zfs where ever possible. we take advantage of snapshotting and > cloning for things like zone cloning and zone be management. because of > this, we''ve recently run into multiple scenarios where a zoneadm > uninstall fails. > > 6787557 zoneadm uninstall fails when zone has zfs clones > http://bugs.opensolaris.org/view_bug.do?bug_id=6787557 > > 7491 problems destroying zones with cloned dependents > http://defect.opensolaris.org/bz/show_bug.cgi?id=7491 > > these failures occur when we try to destroy the zfs filesystem > associated with a zone, but that filesystem has been snapshotted and > cloned. the way we''re fixing these problems is by doing a promotion > before the destroy. jerry has fixed 6787557 for nevada in zoneadm, but > now i''m looking at having to re-implement a similar fix for opensolaris > in the ipkg brand for 7491. > > hence, i''m wondering if it would make more sense just to add this > functionality directly into zfs(1m)/libzfs. this would involve > enhancements to the zfs promote and destroy subcommands. here''s what > i''m thinking. > > the first component would be a new "-t <template>" option to zfs > promote. this option would instruct zfs promote to check for snapshot > naming collisions between the origin and promotion target filesystems, > and to rename any origin filesystem snapshots with conflicting names > before attempting the promotion. the conflicting snapshots will be > renamed to <template>XXX, where XXX is an integer used to make the > snapshot name unique. today users have to do this renaming manually if > they want the promotion to succeed. > > to illustrate how this new functionality would work, say i have the > following filesystems/snapshots: > > tank/zones/zone1 > tank/zones/zone1 at SUNWzone1 > tank/zones/zone1 at user1 > tank/zones/zone2 (clone of tank/zones/zone1 at SUNWzone1) > tank/zones/zone2 at SUNWzone1 > > if i do a "zfs promote -t SUNWzone tank/zones/zone2", then this would > involved a rename of zone1 at SUNWzone1 to zone1 at SUNWzone2, and a promotion > of tank/zones/zone2. the @user1 snapshot would not be renamed because > there was no naming conflict with the filesystem being promoted. hence > i would end up with: > > tank/zones/zone2 > tank/zones/zone2 at SUNWzone1 > tank/zones/zone2 at SUNWzone2 > tank/zones/zone2 at user1 > tank/zones/zone1 (clone of tank/zones/zone2 at SUNWzone2) > > if i did a "zfs promote -t user tank/zones/zone2", then this would this > involved a rename of zone1 at SUNWzone1 to zone1 at user2, and then a > promotion of tank/zones/zone2. hence i would end up with: > > tank/zones/zone2 > tank/zones/zone2 at SUNWzone1 > tank/zones/zone2 at user1 > tank/zones/zone2 at user2 > tank/zones/zone1 (clone of tank/zones/zone2 at user2) > > > the second component would be two new flags to zfs destroy: > zfs destroy [-p [-t <template>]] > > the -p would instruct zfs destroy to try to promote the oldest clone of > the youngest snapshot of the filesystem being destroyed before doing the > destroy. if the youngest filesystem doesn''t have a clone, the command > will fail unless -r was specified. if -r was specified we will continue > to look through snapshot from youngest to oldest looking for the first > one with a clone. if a snapshot with a clone is found, the oldest clone > will be promoted before the destroy. if a template was specified via > -t, this will be passed through to the promote operation. > > thoughts? > ed > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Thu, Apr 23, 2009 at 09:59:33AM -0600, Matthew Ahrens wrote:> "zfs destroy [-r] -p" sounds great. > > I''m not a big fan of the "-t template". Do you have conflicting snapshot > names due to the way your (zones) software works, or are you concerned > about sysadmins creating these conflicting snapshots? If it''s the former, > would it be possible to change the zones software to avoid it?I think the -t option -- automatic snapshot name conflict resolution -- makes a lot of sense in the context of snapshots and clones mostly managed by a system component (zonedm, beadm) but where users can also create snapshots (e.g., for time slider, backups): you don''t want the users to create snapshot names that will later prevent zoneadm/beadm destroy. Making the users responsible for resolving such conflicts seems not user-friendly to me. However, if we could just avoid the conflicts in the first place then we''d not need an option for automatic snapshot name conflict resolution. Conflicts could be avoided by requiring that all snapshot names of a dataset and of clones of snapshots of that dataset, and so on, be unique. Snapshot name uniqueness could be a property of the root dataset of a snapshot/clone tree. Nico --
On Thu, Apr 23, 2009 at 11:31:07AM -0500, Nicolas Williams wrote:> On Thu, Apr 23, 2009 at 09:59:33AM -0600, Matthew Ahrens wrote: > > "zfs destroy [-r] -p" sounds great. > > > > I''m not a big fan of the "-t template". Do you have conflicting snapshot > > names due to the way your (zones) software works, or are you concerned > > about sysadmins creating these conflicting snapshots? If it''s the former, > > would it be possible to change the zones software to avoid it? > > I think the -t option -- automatic snapshot name conflict resolution -- > makes a lot of sense in the context of snapshots and clones mostly > managed by a system component (zonedm, beadm) but where users can also > create snapshots (e.g., for time slider, backups): you don''t want the > users to create snapshot names that will later prevent zoneadm/beadm > destroy. Making the users responsible for resolving such conflicts > seems not user-friendly to me. > > However, if we could just avoid the conflicts in the first place then > we''d not need an option for automatic snapshot name conflict resolution. > Conflicts could be avoided by requiring that all snapshot names of a > dataset and of clones of snapshots of that dataset, and so on, be > unique. Snapshot name uniqueness could be a property of the root > dataset of a snapshot/clone tree. >an interesting idea. i can file an RFE on this as well, but there are a couple side effects to consider with this approach. setting this property would break "zfs snapshot -r" if there are multiple snapshots and clones of a single filesystem. callers that creates snapshots (ie zones) usually have a simple naming schemes. they look at what snapshots are there and pick a new name that isn''t used yet. with this approach, picking a new name becomes harder because iterating over the existing snapshot namespace just became harder. (i guess that callers could adopt a policy of creating snaoshots with incrementing names until they get some return code other than EEXIST.) ed
On Thu, Apr 23, 2009 at 09:59:33AM -0600, Matthew Ahrens wrote:> Ed, > > "zfs destroy [-r] -p" sounds great. > > I''m not a big fan of the "-t template". Do you have conflicting snapshot > names due to the way your (zones) software works, or are you concerned > about sysadmins creating these conflicting snapshots? If it''s the > former, would it be possible to change the zones software to avoid it? >conflicting names are pretty common for zones. the zones infrastructure uses SUNWzoneXXX for zone cloning and zbe-XXX for zone BE management. i guess we could switch to using timestamps... ed
On Thu, Apr 23, 2009 at 11:25:54AM -0700, Edward Pilatowicz wrote:> an interesting idea. i can file an RFE on this as well, but there are a > couple side effects to consider with this approach. > > setting this property would break "zfs snapshot -r" if there are > multiple snapshots and clones of a single filesystem.I agree. You''d want to make snapshot -r compute new snapshot names in some manner, so you''re back to something like "templates," which is why I really like your proposal. Nico --