Re: [zfs-discuss] zfs clones
Matthew Ahrens wrote:
now wouldnt it be more natural way of usage when I intend to create a
clone, that by default
the zfs clone command will create the needed snapshot from the current
image internally as part
of taking the clone unless I explicitely specify that I do want to
take a clone of a specific snapshot ?
While that might be convenient, hiding what's really going on can result
in confusion.
So really, administrators need to be aware of the underlying snapshot.
Therefore, providing a clone a fs by taking a snapshot under the
covers feature would serve only as syntactic sugar. I believe that the
potential for confusion outweighs this benefit.
I agree with both of you.
I agree with Frank that there should be the ability to run a single ZFS
command to create a clone without the admin need to manually create a
snapshot first. This isn't a reduction from one command to two in
scripting but more like three or four commands because you would need to
calculate a snapshot name then snapshot with that then use it to clone.
I agree completely with Matt that we should never hide the fact from the
admin that for a clone you need a snapshot to first exist.
What I would like to see it that zfs clone when given an additional
argument creates the snapshot and the clone for you. This means we need
a way to name the snapshots to ensure they will never clash, I'd suggest
using the date and time in an ISO format eg:
$ zfs clone -s homes/template/user homes/bob
Would be equivalent to doing the following:
$ snapname=`date +%F:%T`
$ zfs snapshot homes/template/[EMAIL PROTECTED]
$ zfs clone homes/template/[EMAIL PROTECTED] homes/bob
In both cases running zfs list would show the snapshot.
Where this becomes really useful is if we also had '-r' for clones, for
example cloning a whole part os the namesoace might go something like this:
$ snapname=`date +%F:%T`
$ zfs snapshot -r [EMAIL PROTECTED]
$ for i in `zfs list -t snapshot -H -o name | sort | tail -1` ; do
zfs clone $i nhomes/${i%%$snapname}
done
If we had implicit snapshot with clones and a recursive capability
we could do this:
$ zfs clone -s -r homes nhomes
Its a easy of use thing in the UI, just like when running zpool to
create a new pool you get the top level filesystem without running zfs
create.
It could also be used when cloneing zones using zoneadm(1M), that
currently uses @SUNWzone as a prefix of the snapshot name.
Now I don't think this is particularly high priority, I'd much rather
see '-r' for zfs send/recv before I saw this.
--
Darren J Moffat
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs clones
Frank Batschulat wrote: it seems taking a clone always requires taking a snapshot first and provide this as a parameter to the zfs clone command. now wouldnt it be more natural way of usage when I intend to create a clone, that by default the zfs clone command will create the needed snapshot from the current image internally as part of taking the clone unless I explicitely specify that I do want to take a clone of a specific snapshot ? along the lines of I do want to take a clone yet - I dont care about snapshots. While that might be convenient, hiding what's really going on can result in confusion. For example, if you were to do: # zfs clone pool/fs pool/clone # rm -rf /pool/clone/* # rm -rf /pool/fs/* You would be surprised to find that the space is not actually freed up, despite the fact that your files are not accessible (to any means know to you). So really, administrators need to be aware of the underlying snapshot. Therefore, providing a clone a fs by taking a snapshot under the covers feature would serve only as syntactic sugar. I believe that the potential for confusion outweighs this benefit. --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs clones
it seems taking a clone always requires taking a snapshot first and provide this as a parameter to the zfs clone command. now wouldnt it be more natural way of usage when I intend to create a clone, that by default the zfs clone command will create the needed snapshot from the current image internally as part of taking the clone unless I explicitely specify that I do want to take a clone of a specific snapshot ? along the lines of I do want to take a clone yet - I dont care about snapshots. thanks --- frankB This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs clones
As I understand it, the snapshot of a set is used as a reference by the clone. So the clone is initially a set of pointers to the snapshot. That's why it is so fast to create. How can I separate it from the snapshot ? (so that df -k or zfs list will display for a 48G drive pool/fs1 4G 40G pool/clone 4G 40G instead of pool/fs1 4G 44G pool/clone 4G 44G ) I hope I am clear enough :/ Thanks Marlanne 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] zfs clones
Marlanne DeLaSource wrote: As I understand it, the snapshot of a set is used as a reference by the clone. So the clone is initially a set of pointers to the snapshot. That's why it is so fast to create. How can I separate it from the snapshot ? (so that df -k or zfs list will display for a 48G drive pool/fs1 4G 40G pool/clone 4G 40G instead of pool/fs1 4G 44G pool/clone 4G 44G ) I hope I am clear enough :/ There is no way to separate a clone from its origin snapshot. I think the numbers you're posting are: FS REFDAVAIL pool/fs14G 40G pool/clone 4G 40G So you want it to say that less space is available than really is? Perhaps what you want is to set a reservation on the clone for its initial size, so that you will be guaranteed to have enough space to overwrite its initial contents with new contents of the same size? --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs clones
On Fri, 2006-09-01 at 06:03 -0700, Marlanne DeLaSource wrote: As I understand it, the snapshot of a set is used as a reference by the clone. So the clone is initially a set of pointers to the snapshot. That's why it is so fast to create. How can I separate it from the snapshot ? (so that df -k or zfs list will display for a 48G drive pool/fs1 4G 40G pool/clone 4G 40G instead of pool/fs1 4G 44G pool/clone 4G 44G ) I hope I am clear enough You're quite clear about the end state you're looking for, but not about why you might want to do this... You could conceivably put another full copy of the data into the pool by using zfs send piped to zfs receive instead of zfs clone. You might also want to take a look at zfs promote, which allows the clone to take over primary ownership of the snapshot (and changing the snapshot's parent to be a clone). - Bill ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
