On Fri, 12 Feb 2010 23:47:36 +0100, Christine Tran <christine.t...@gmail.com> 

> Hi, I'm sorry to bug the OpenSolaris for a question that pertains to
> S10U8, but I am really stuck.
> I am doing a zoneadm clone -m copy, and I do not want a new ZFS
> dataset even though my zonepath is on a ZFS filesystem, for
> performance reasons particular to how I am using my zones.
> Unfortunately, zoneadm clone just ignores the "-m copy", and makes me
> a new ZFS filesystem anyway; and by the speed with which it finished,
> it certainly is a snapshot operation underneath.
> I have tested with making the source zone on a separate UFS, have
> pre-made a dirname under my ZFS filesystem as the zonepath, nothing
> works.  I always get a new ZFS filesystem.  I see that zoneadm install
> has an -x nodataset switch, I need this for zone clone as well.  I
> have not seen this filed as a bug against S10, is there a work-around
> to get the behavior I want?
> This is sort of a big deal for our application.  We use labeled zones,
> a file move within a filesystem has a different performance profile
> than a move from one filesystem to another filesystem, even within one
> ZFS pool.  We are doing tens of thousands of move per minute.


the '-m copy' option to 'clone' does not imply that no new zfs dataset
is created. 

     clone [-m copy] [-s zfs_snapshot] source_zone

         Install a zone by copying an  existing  installed  zone.
         This  subcommand  is  an  alternative way to install the

         -m copy

             Force the clone to be a copy, even if a "ZFS  clone"
             is possible.
<snip end>

it changes the method of clone to use 'find/cpio'


instead of doing it with a zfs snapshot:


however, it does as well always create a new zfs dataset, this is intended.


a '-x nodataset' option for 'clone' like in 'install' is unlikely going to 
happen, in
fact I will remove the '-x nodataset' option for 'install' completely soon in 
OSOL build 135

PSARC 2010/008 Remove zoneadm install sub-option "-x nodataset"

your ZFS problem is with 'move' ie. rename a file from one dataset to another
while both datasets are still in the same pool ending up as a copy of the file
because it crosses dataset ie. file system boundaries. there's a ZFS RFE
open to improve that:

6483179 Provide an efficient way to rename a file to another dataset in same 

6650426 RFE: support link(2) between ZFS filesystems

zones-discuss mailing list

Reply via email to