Hi--
From your pre-promotion output, both fs1-patch and snap1 are
referencing the same 16.4 GB, which makes sense. I don't see how fs1
could be a
clone of fs1-patch because it should be REFER'ing 16.4 GB as well in
your pre-promotion zfs list.
If you snapshot, clone, and promote, then the
Hello,
# /usr/sbin/zfs list -r rgd3
NAME USEDAVAIL REFER MOUNTPOINT
rgd3 16.5G23.4G20K
/rgd3
rgd3/fs1 19K 23.4G21K
/app/fs1
rgd3/fs1-patch
Hi Tester,
It is difficult for me to see all that is going on here. Can you provide
the steps and the complete output?
I tried to reproduce this on latest Nevada bits and I can't. The
snapshot sizing looks correct to me after a snapshot/clone promotion.
Thanks,
Cindy
# zfs create
Hello,
Immediately after a promote, the snapshot of the promoted clone has 1.25G used.
NAME USED AVAIL REFER
q2/fs1 4.01G 9.86G 8.54G
q2/f...@test1 [b]1.25G[/b] - 5.78G -
prior to the promote the snapshot of the origin file system
Ed,
zfs destroy [-r] -p sounds great.
I'm not a big fan of the -t template. Do you have conflicting snapshot
names due to the way your (zones) software works, or are you concerned about
sysadmins creating these conflicting snapshots? If it's the former, would
it be possible to change the
On Thu, Apr 23, 2009 at 09:59:33AM -0600, Matthew Ahrens wrote:
zfs destroy [-r] -p sounds great.
I'm not a big fan of the -t template. Do you have conflicting snapshot
names due to the way your (zones) software works, or are you concerned
about sysadmins creating these conflicting
On Thu, Apr 23, 2009 at 11:31:07AM -0500, Nicolas Williams wrote:
On Thu, Apr 23, 2009 at 09:59:33AM -0600, Matthew Ahrens wrote:
zfs destroy [-r] -p sounds great.
I'm not a big fan of the -t template. Do you have conflicting snapshot
names due to the way your (zones) software works, or
On Thu, Apr 23, 2009 at 09:59:33AM -0600, Matthew Ahrens wrote:
Ed,
zfs destroy [-r] -p sounds great.
I'm not a big fan of the -t template. Do you have conflicting snapshot
names due to the way your (zones) software works, or are you concerned
about sysadmins creating these conflicting
On Thu, Apr 23, 2009 at 11:25:54AM -0700, Edward Pilatowicz wrote:
an interesting idea. i can file an RFE on this as well, but there are a
couple side effects to consider with this approach.
setting this property would break zfs snapshot -r if there are
multiple snapshots and clones of a
hey all,
in both nevada and opensolaris, the zones infrastructure tries to
leverage zfs where ever possible. we take advantage of snapshotting and
cloning for things like zone cloning and zone be management. because of
this, we've recently run into multiple scenarios where a zoneadm
uninstall
Hi, Mike,
It's like 6452872, it need enough space for 'zfs promote'
- Regards,
Mike Gerdts wrote:
I needed to free up some space to be able to create and populate a new
upgrade. I was caught off guard by the amount of free space required
by zfs promote.
bash-3.2# uname -a
SunOS indy2
On Wed, Jun 11, 2008 at 12:58 AM, Robin Guo [EMAIL PROTECTED] wrote:
Hi, Mike,
It's like 6452872, it need enough space for 'zfs promote'
Not really - in 6452872 a file system is at its quota before the
promote is issued. I expect that a promote may cause several KB of
metadata changes that
I needed to free up some space to be able to create and populate a new
upgrade. I was caught off guard by the amount of free space required
by zfs promote.
bash-3.2# uname -a
SunOS indy2 5.11 snv_86 i86pc i386 i86pc
bash-3.2# zfs list
NAME USED AVAIL REFER
13 matches
Mail list logo
