zfs discuss - Mar 2006 - Some ideas for new zfs commands: split, join, rollfwd

While playing with ZFS on a couple of systems, some ideas for new zfs
commands occured to me that others might find useful:

* I sometimes need to split off a directory on a zfs filesystem into its
  own filesystem, e.g. to be able to snapshot and clone it separately.  A
  zfs split subcommand would come in handy to avoid having to move the
  directory aside, create the new filesystem, and restore the contents
  there.

* For symmetry (if possible), there should be the corresponding zfs join
  command to join a subsidiary filesystem with its parent.

* A current model for using snapshots to undo potentially dangerous
  operations is to take a snapshot, perform the dangerous activity, and
  rollback to the snapshot if e.g. testing revealed problems.  I can
  imagine some use for the opposite direction: zfs rollfwd.

  Consider the following scenario:

  I''d like to patch a bunch of diskless clients.  Instead of taking the
  snapshot, patching and rolling back if it fails to work properly, I''d
  rather take a snapshot, clone that, patch the clone, test that and, if
  successful, roll the filesystem forward to the clone, discarding the
  snapshot and separate clone.

Would any of the be feasible to implement, or is there even a roadmap for
such RFEs?

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

On Fri, Mar 17, 2006 at 09:54:09PM +0100, Rainer Orth
wrote:
> While playing with ZFS on a couple of systems, some ideas for new zfs
> commands occured to me that others might find useful:
> 
...
> * A current model for using snapshots to undo potentially dangerous
>   operations is to take a snapshot, perform the dangerous activity, and
>   rollback to the snapshot if e.g. testing revealed problems.  I can
>   imagine some use for the opposite direction: zfs rollfwd.
> 
>   Consider the following scenario:
> 
>   I''d like to patch a bunch of diskless clients.  Instead of
taking the
>   snapshot, patching and rolling back if it fails to work properly,
I''d
>   rather take a snapshot, clone that, patch the clone, test that and, if
>   successful, roll the filesystem forward to the clone, discarding the
>   snapshot and separate clone.
This is an existing RFE:

6276916 support for "clone swap"

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

Jonathan,
> This is an existing RFE:
> 
> 6276916 support for "clone swap"
great.  Anyone working on this?  The RFE mentions its use for LiveUpgrade,
so I''d imagine this could happen when LU starts to make use of ZFS
features.

	Rainer

On Fri, Mar 17, 2006 at 09:54:09PM +0100, Rainer Orth
wrote:
> While playing with ZFS on a couple of systems, some ideas for new zfs
> commands occured to me that others might find useful:
Thanks for playing with ZFS and taking the time to tell us your ideas.
> * I sometimes need to split off a directory on a zfs filesystem into its
>   own filesystem, e.g. to be able to snapshot and clone it separately.  A
>   zfs split subcommand would come in handy to avoid having to move the
>   directory aside, create the new filesystem, and restore the contents
>   there.
This is an RFE that we''ve talked about.  It might not seem too bad,
since you wouldn''t have to move around any data blocks, you''d
just have
to make a couple of ZAP updates for the directory you''re splitting off.
The only hard part here would be dealing with hard links and perhaps
snapshots.  Both issues would make this trickier than it might seem at
first.
> * For symmetry (if possible), there should be the corresponding zfs join
>   command to join a subsidiary filesystem with its parent.
This is much harder.  Since you''d be joining two filesystems, there is
no way you could deal with conflicting inode numbers.  If both
filesystems have object 37 allocated, which one wins?  Whichever one
loses would get a new inode assigned to it, which would be
application-visible and potentially cause problems.  Again, snapshots
introduce an interesting wrinkle into this.
> * A current model for using snapshots to undo potentially dangerous
>   operations is to take a snapshot, perform the dangerous activity, and
>   rollback to the snapshot if e.g. testing revealed problems.  I can
>   imagine some use for the opposite direction: zfs rollfwd.
This is actually another RFE that we''ve talked about for the near
future.  We''ve called the functionality "zfs pivot", due to
the way our
data structures would be affected.  Essentially, you want to exchange a
clone with the "live" or leaf dataset.  Both the clone and the current
live version of the filesystem share a clone at some point in their
past.  You want to pivot the two branches so that the clone and live
versions are swapped, at which point you have the option of deleting the
old live branch.

              - S - L                        - S - S - L  (old C)
             /                              /
    S - S - S                =>    S - S - S
             \                              \
              - S - S - C                    - S - C  (old L)

Let us know if this makes sense for your usage.  I think "rollfwd" as
a
subcommand might be a little more symmetrical than "pivot".  Either
way,
we could have an option to automatically remove the old live branch.


--Bill

On Fri, Mar 17, 2006 at 10:19:57PM +0100, Rainer Orth
wrote:
> Jonathan,
> 
> > This is an existing RFE:
> > 
> > 6276916 support for "clone swap"
> 
> great.  Anyone working on this?  The RFE mentions its use for LiveUpgrade,
> so I''d imagine this could happen when LU starts to make use of ZFS
> features.
I''ll probably be working on this after Solaris 10 Update 2 ships.

FYI, while "clone pivot" is needed for a clean solution, you can
always
kludge something together in the mean time, eg:

	# zfs snapshot pool/fs at a
	# zfs clone pool/fs at a pool/trial
	< modify pool/trial and see if it works >
	< now you''d like to do ''zfs cloneswap
pool/trial'', instead... >
	# zfs rename pool/fs pool/oldfs
	# zfs rename pool/trial pool/fs

The disadvantage is that you have to leave the oldfs lying around
because the clone depends on it, and the cloned fs doesn''t see the
snapshots from before the time it was created.

--matt

Bill,
> Thanks for playing with ZFS and taking the time to tell us your ideas.
it has been a great pleasure to work with ZFS and observe a revolution in
filesystems happening :-)  ZFS changes the way we work with filesystems in
a fundamental way and allows many operations that you could before only
dream of.
> > * I sometimes need to split off a directory on a zfs filesystem into
its
> >   own filesystem, e.g. to be able to snapshot and clone it separately.
A
> >   zfs split subcommand would come in handy to avoid having to move the
> >   directory aside, create the new filesystem, and restore the contents
> >   there.
> 
> This is an RFE that we''ve talked about.  It might not seem too
bad,
> since you wouldn''t have to move around any data blocks,
you''d just have
> to make a couple of ZAP updates for the directory you''re splitting
off.
> The only hard part here would be dealing with hard links and perhaps
> snapshots.  Both issues would make this trickier than it might seem at
> first.
Indeed, I hadn''t thought about those problems.  So this might make in
interesting community project when learning about ZFS.  Not for me, though,
since I''ve already too many things going on right now :-)  On the other
hand, it might be interesting to see if such projects are applicable for
some operating system project at a university.
> > * For symmetry (if possible), there should be the corresponding zfs
join
> >   command to join a subsidiary filesystem with its parent.
> 
> This is much harder.  Since you''d be joining two filesystems,
there is
> no way you could deal with conflicting inode numbers.  If both
> filesystems have object 37 allocated, which one wins?  Whichever one
True, that problem occured to me, too.  That''s why I wrote `if
possible''.
> loses would get a new inode assigned to it, which would be
> application-visible and potentially cause problems.  Again, snapshots
> introduce an interesting wrinkle into this.
Perhaps this would have to be an off-line (and potentially disruptive)
operation, though this would run contrary to the spirit of ZFS.
> > * A current model for using snapshots to undo potentially dangerous
> >   operations is to take a snapshot, perform the dangerous activity,
and
> >   rollback to the snapshot if e.g. testing revealed problems.  I can
> >   imagine some use for the opposite direction: zfs rollfwd.
> 
> This is actually another RFE that we''ve talked about for the near
> future.  We''ve called the functionality "zfs pivot", due
to the way our
> data structures would be affected.  Essentially, you want to exchange a
> clone with the "live" or leaf dataset.  Both the clone and the
current
> live version of the filesystem share a clone at some point in their
> past.  You want to pivot the two branches so that the clone and live
> versions are swapped, at which point you have the option of deleting the
> old live branch.
> 
>               - S - L                        - S - S - L  (old C)
>              /                              /
>     S - S - S                =>    S - S - S
>              \                              \
>               - S - S - C                    - S - C  (old L)
> 
> Let us know if this makes sense for your usage.  I think
"rollfwd" as a
> subcommand might be a little more symmetrical than "pivot". 
Either way,
> we could have an option to automatically remove the old live branch.
This is even better than what I initially contemplated, since it keeps the
old live branch as a snapshot instead of deleting it as I had thought
initially.  One might need a way to merge the changes between the branch
snapshot and old L, though (which makes ZFS turn into a version control
system :-).

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

On Fri, Mar 17, 2006 at 01:28:23PM -0800, Bill Moore
wrote:
> On Fri, Mar 17, 2006 at 09:54:09PM +0100, Rainer Orth wrote:
> > While playing with ZFS on a couple of systems, some ideas for new zfs
> > commands occured to me that others might find useful:
> 
> Thanks for playing with ZFS and taking the time to tell us your ideas.
> 
> > * I sometimes need to split off a directory on a zfs filesystem into
its
> >   own filesystem, e.g. to be able to snapshot and clone it separately.
A
> >   zfs split subcommand would come in handy to avoid having to move the
> >   directory aside, create the new filesystem, and restore the contents
> >   there.
> 
> This is an RFE that we''ve talked about.  It might not seem too
bad,
> since you wouldn''t have to move around any data blocks,
you''d just have
> to make a couple of ZAP updates for the directory you''re splitting
off.
> The only hard part here would be dealing with hard links and perhaps
> snapshots.  Both issues would make this trickier than it might seem at
> first.
Additionally, you''d have to deal with moving all the dnodes to the new
fs.  One possible solution would be to simply clone the fs, then
essentially ''rm -rf'' [*] the unwanted parts of each.  This
would be
pretty easy to implement, and if you can accept the requirement of
keeping the snapshot around, then I don''t think it''s possible
to do much
better.

I''ve filed the following RFE to track this request:

	6400399 want "zfs split"

--matt

[*] Given that you will have to keep the snapshot around, we can employ
some tricks to make the ''rm -rf'' take constant time and space,
at least
in the clone.

Bill Moore wrote:
>> * For symmetry (if possible), there should be the corresponding zfs
join
>>   command to join a subsidiary filesystem with its parent.
> 
> This is much harder.  Since you''d be joining two filesystems,
there is
> no way you could deal with conflicting inode numbers.  If both
> filesystems have object 37 allocated, which one wins?  Whichever one
> loses would get a new inode assigned to it, which would be
> application-visible and potentially cause problems.  Again, snapshots
> introduce an interesting wrinkle into this.
> 
I think this would solve that problem (not that there aren''t others...)

   1) The FS being ''added'' would need to be unmounted.
   2) the FS being ''added'' would be the one changed.

	-Kyle