zfs discuss - May 2006 - fwd: ZFS Clone Promotion [PSARC/2006/303 Timeout:05/12/2006]

Is there some benefit to me (err, the administrator) to maintaining the
parent/child relationship between a snap and its clone?  

To my twisted little mind, by virtue of the fact that I created a clone
I have severed the relationship between a snap and a clone.  They are
immediately at least one bit different (the writable ''bit''),
which means
that they no longer are consistent, which means they are distinct.   In
fact, I oughta be able to create multiple clones without penalty.  

Clone has a distinct, generic meaning that does not imply a fixed or
lasting relationship to the parent, but rather an inheritance.  Just ask
Dolly. ;-) 

So what is the benefit?

Thx,
-PWM
 

-----Original Message-----
From: zfs-discuss-bounces at opensolaris.org
[mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Matthew Ahrens
Sent: Tuesday, May 09, 2006 2:10 PM
To: zfs-discuss at opensolaris.org
Subject: [zfs-discuss] fwd: ZFS Clone Promotion [PSARC/2006/303
Timeout:05/12/2006]

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/production at today
>       # zfs clone pool/project/production at today 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 at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Wed, May 10, 2006 at 12:12:16PM -0600, Morreale, Peter W
wrote:
> 
> Is there some benefit to me (err, the administrator) to maintaining the
> parent/child relationship between a snap and its clone?  
> 
> To my twisted little mind, by virtue of the fact that I created a clone
> I have severed the relationship between a snap and a clone.  They are
> immediately at least one bit different (the writable
''bit''), which means
> that they no longer are consistent, which means they are distinct.   In
> fact, I oughta be able to create multiple clones without penalty.  
Yes, you can create multiple clones of a single snapshot, without
penalty.
> Clone has a distinct, generic meaning that does not imply a fixed or
> lasting relationship to the parent, but rather an inheritance.  Just ask
> Dolly. ;-) 
> 
> So what is the benefit?
The clone and snapshot "share" space.  This relationship must be
maintained for internal accounting purposes, but also for the
administrator to know which clones are sharing space with the original
snapshot.  We tried for a while to allow a means to destroy the original
filesystem (thereby ''divorcing'' the clone from its snapshot),
but it''s
just not doable, both from an implementation perspective and a space
accounting perspective.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

On Wed, May 10, 2006 at 12:12:16PM -0600, Morreale, Peter W
wrote:
> 
> Is there some benefit to me (err, the administrator) to maintaining the
> parent/child relationship between a snap and its clone?  
If I remember correctly, it''s mainly an issue of accounting;  where
does
the space for the base snapshot''s disk usage get accounted for if it
can
be deleted?
> To my twisted little mind, by virtue of the fact that I created a clone
> I have severed the relationship between a snap and a clone.  They are
> immediately at least one bit different (the writable
''bit''), which means
> that they no longer are consistent, which means they are distinct.   In
> fact, I oughta be able to create multiple clones without penalty.  
You can.  The issue is that having a clone of a snapshot *prevents that
snapshot from being deleted*.  The whole point of clone promotion is to
allow the "ownership" of the snapshot to move from the filesystem that
was
originally snapshotted to one of the snapshot''s clones.  This allows
that
original filesystem to be destroyed, and possibly the snapshot itself.

Cheers,
- jonathan
> Clone has a distinct, generic meaning that does not imply a fixed or
> lasting relationship to the parent, but rather an inheritance.  Just ask
> Dolly. ;-) 
> 
> So what is the benefit?
> 
> Thx,
> -PWM
>  
> 
> -----Original Message-----
> From: zfs-discuss-bounces at opensolaris.org
> [mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Matthew Ahrens
> Sent: Tuesday, May 09, 2006 2:10 PM
> To: zfs-discuss at opensolaris.org
> Subject: [zfs-discuss] fwd: ZFS Clone Promotion [PSARC/2006/303
> Timeout:05/12/2006]
> 
> 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/production at today
> >       # zfs clone pool/project/production at today 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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
-- 
Jonathan Adams, Solaris Kernel Development

> -----Original Message-----
> From: Eric Schrock [mailto:eric.schrock at sun.com] 
> 
> The clone and snapshot "share" space.  This relationship must 
> be maintained for internal accounting purposes, but also for 
> the administrator to know which clones are sharing space with 
> the original snapshot.  We tried for a while to allow a means 
> to destroy the original filesystem (thereby ''divorcing''
the
> clone from its snapshot), but it''s just not doable, both from 
> an implementation perspective and a space accounting perspective.
> 
They share _some_ space, right?  I mean, writing on the clone
necessarily implies allocation of blocks to the clone.   (at least
figuratively...)

I do not understand the last sentence, isn''t that what
''promotion'' is
all about?  severing the link?

-PWM