On Tue, 9 May 2006, Matthew Ahrens wrote:
> FYI folks, I have implemented "clone promotion", also known as "clone
> swap" or "clone pivot", as described in this bug report:
>
> 6276916 support for "clone swap"
>
> Look for it in an upcoming release...
>
> Here is a copy of PSARC case which is currently under review.
>
> 1. Introduction
> 1.1. Project/Component Working Name:
> ZFS Clone Promotion
> 1.2. Name of Document Author/Supplier:
> Author: Matt Ahrens
> 1.3 Date of This Document:
> 06 May, 2006
> 4. Technical Description
> ZFS provides the ability to create read-only snapshots of any filesystem,
> and to create writeable clones of any snapshot. Suppose that F is a
> filesystem, S is a snapshot of F, and C is a clone of S. Topologically,
> F and C are peers: that is, S is a common origin point from which F and C
> diverge. F and C differ only in how their space is accounted and where
> they appear in the namespace.
>
> After using a clone to explore some alternate reality (e.g. to test a patch),
> it's often desirable to 'promote' the clone to 'main' filesystem status --
> that is, to swap F and C in the namespace. This is what 'zfs promote' does.
>
> Here are man page changes:
>
> in the SYNOPSIS section (after 'zfs clone'):
> > zfs promote <clone filesystem>
>
> in the DESCRIPTION - Clones section (only last paragraph is added):
> Clones
> A clone is a writable volume or file system whose initial
> contents are the same as another dataset. As with snapshots,
> creating a clone is nearly instantaneous, and initially con-
> sumes no additional space.
>
> Clones can only be created from a snapshot. When a snapshot
> is cloned, it creates an implicit dependency between the
> parent and child. Even though the clone is created somewhere
> else in the dataset hierarchy, the original snapshot cannot
> be destroyed as long as a clone exists. The "origin" pro-
> perty exposes this dependency, and the destroy command lists
> any such dependencies, if they exist.
>
> > The clone parent-child dependency relationship can be reversed by
> > using the _promote_ subcommand. This causes the "origin"
> > filesystem to become a clone of the specified filesystem, which
> > makes it possible to destroy the filesystem that the clone was
> > created from.
>
> in the SUBCOMMANDS section (after 'zfs clone'):
> > zfs promote <clone filesystem>
> >
> > Promotes a clone filesystem to no longer be dependent on its
> > "origin" snapshot. This makes it possible to destroy the
> > filesystem that the clone was created from. The dependency
> > relationship is reversed, so that the "origin" filesystem
> > becomes a clone of the specified filesystem.
> >
> > The snaphot that was cloned, and any snapshots previous to this
> > snapshot will now be owned by the promoted clone. The space
> > they use will move from the "origin" filesystem to the promoted
> > clone, so is must have enough space available to accommodate
> > these snapshots. Note: no new space is consumed by this
> > operation, but the space accounting is adjusted. Also note that
> > the promoted clone must not have any conflicting snapshot names
> > of its own. The _rename_ subcommand can be used to rename any
> > conflicting snapshots.
>
> in the EXAMPLES section (after 'Example 8: Creating a clone'):
> > Example 9: Promoting a Clone
> >
> > The following commands illustrate how to test out changes to a
> > filesystem, and then replace the original filesystem with the
> > changed one, using clones, clone promotion, and renaming.
> >
> > # zfs create pool/project/production
> > <populate /pool/project/production with data>
> > # zfs snapshot pool/project/[EMAIL PROTECTED]
> > # zfs clone pool/project/[EMAIL PROTECTED] pool/project/beta
> > <make changes to /pool/project/beta and test them>
> > # zfs promote pool/project/beta
> > # zfs rename pool/project/production pool/project/legacy
> > # zfs rename pool/project/beta pool/project/production
> > <once the legacy version is no longer needed, it can be
> > destroyed>
> > # zfs destroy pool/project/legacy
>
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
> 6.4.1. Consolidation C-team Name:
> ON
> 6.5. ARC review type: FastTrack
>
> ----- End forwarded message -----
Un-Bloody-Believable! Awesome work Matt!
ZFS (achievements) read like a work of pure fiction if read by someone who
came from Solaris 10 Update 1 (which is not that long ago) and then read
this post!
Regards,
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
