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/zo...@sunwzone1
tank/zones/zo...@user1
tank/zones/zone2 (clone of tank/zones/zo...@sunwzone1)
tank/zones/zo...@sunwzone1
if i do a "zfs promote -t SUNWzone tank/zones/zone2", then this would
involved a rename of zo...@sunwzone1 to zo...@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/zo...@sunwzone1
tank/zones/zo...@sunwzone2
tank/zones/zo...@user1
tank/zones/zone1 (clone of tank/zones/zo...@sunwzone2)
if i did a "zfs promote -t user tank/zones/zone2", then this would this
involved a rename of zo...@sunwzone1 to zo...@user2, and then a
promotion of tank/zones/zone2. hence i would end up with:
tank/zones/zone2
tank/zones/zo...@sunwzone1
tank/zones/zo...@user1
tank/zones/zo...@user2
tank/zones/zone1 (clone of tank/zones/zo...@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@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
