Re: [zfs-discuss] Re: Re: zfs clones

2006-09-19 Thread Jan Hendrik Mangold
Hey Mattwere you able to reproduce this? I am using the straight S10U2 bits. I can give you access to the system, if you want. One last piece of information should be that my pools are created of files, due to lack of disks for experimenting.On Sep 18, 2006, at 10:04 PM, Matthew Ahrens wrote:Jan Hendrik Mangold wrote: I didn't ask the original question, but I have a scenario where Iwant to use clone as well and encounter a (designed?) behaviour I amtrying to understand.I create a filesystem A with ZFS and modify it to a point where Icreate a snapshot [EMAIL PROTECTED] Then I clone that snapshot to create a newfilesystem B. I seem to have two filesystem "entities" I can makeindependant modifications and snapshots with/on/from.The problem I am running into is that when modifying A and wanting torollback to the snapshot [EMAIL PROTECTED] I can't do that as long as the clone Bis mounted.Is this a case where I would benefit from the ability to sperate theclone? Or is this something not possible with ZFS? Hmm, actually this is unexpected; you shouldn't have to unmount the clone to do the rollback on the origin filesystem.  I think that our command-line tool is simply being a bit overzealous.  I've filed bug 6472202 to track this issue; it should be pretty straightforward to fix.Thanks for bringing this to our attention!--matt  --Jan Hendrik Mangold Sun Microsystems650-585-5484 (x81371)"idle hands are the developers workshop" 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


[zfs-discuss] Re: Re: zfs clones

2006-09-18 Thread Jan Hendrik Mangold
  The initial idea was to make a dataset/snapshot and
 clone (fast) and then separate the clone from its
 snapshot. The clone could be then used as a new
 independant dataset. 
  
  The send/receive subcommands are probably the only
 way to duplicate a dataset.
 
 I'm still not sure I understand what about clones makes you not want to 
 use them.  What do you mean by separate the clone from its snapshot? 
 Is it that you want to destroy the filesystem that
 the clone was created  from?  To do that you can use 'zfs promote'.  Is it
 that you want to guarantee space availability to overwrite it?  To do
 that you can use  'zfs set reservation'.
 
 --matt

I didn't ask the original question, but I have a scenario where I want to use 
clone as well and encounter a (designed?) behaviour I am trying to understand.

I create a filesystem A with ZFS and modify it to a point where I create a 
snapshot [EMAIL PROTECTED] Then I clone that snapshot to create a new 
filesystem B. I seem to have two filesystem entities I can make independant 
modifications and snapshots with/on/from.

The problem I am running into is that when modifying A and wanting to rollback 
to the snapshot [EMAIL PROTECTED] I can't do that as long as the clone B is 
mounted.

Is this a case where I would benefit from the ability to sperate the clone? Or 
is this something not possible with ZFS?

Thanks for any answers
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] Re: Re: zfs clones

2006-09-18 Thread Matthew Ahrens

Jan Hendrik Mangold wrote:

I didn't ask the original question, but I have a scenario where I
want to use clone as well and encounter a (designed?) behaviour I am
trying to understand.

I create a filesystem A with ZFS and modify it to a point where I
create a snapshot [EMAIL PROTECTED] Then I clone that snapshot to create a new
filesystem B. I seem to have two filesystem entities I can make
independant modifications and snapshots with/on/from.

The problem I am running into is that when modifying A and wanting to
rollback to the snapshot [EMAIL PROTECTED] I can't do that as long as the clone 
B
is mounted.

Is this a case where I would benefit from the ability to sperate the
clone? Or is this something not possible with ZFS?


Hmm, actually this is unexpected; you shouldn't have to unmount the 
clone to do the rollback on the origin filesystem.  I think that our 
command-line tool is simply being a bit overzealous.  I've filed bug 
6472202 to track this issue; it should be pretty straightforward to fix.


Thanks for bringing this to our attention!
--matt
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss