out of curiousity, how are properties handled? for example if you have a fs with compression disabled, you snapshot it, you clone it, and you enable compression on the clone, and then you promote the clone. will compressions be enabled on the new parent? and what about other clones that have properties that are inherited from the parent? will they all now have compression enabled as well?
ed On Tue, May 09, 2006 at 01:09:46PM -0700, 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 ----- > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
