I've noticed on a Solaris 11 system that when I clone a filesystem and
change the share property:
#zfs clone -p -o atime=off filesystem@snapshot clone
#zfs set -c share=name=old share clone
#zfs set share=name=new NFS share clone
#zfs set sharenfs=on clone
The origin filesystem is no longer
Thank you for the link!
Turns out that, even though I bought the WD20EARS and ST32000542AS
expecting a 4096 physical blocksize, they report 512.
The new drive I bought correctly identifies as 4096 byte blocksize!
So...OI doesn't like it merging with the existing pool.
Note: ST2000VX000-9YW1
--- On Mon, 9/24/12, Richard Elling richard.ell...@gmail.com wrote:
I'm hoping the answer is yes - I've been looking but do not see it ...
none can hide from dtrace!# dtrace -qn 'dsl_dataset_stats:entry {this-ds =
(dsl_dataset_t *)arg0;printf(%s\tcompressed size = %d\tuncompressed
size=%d\n,
I'm hoping the answer is yes - I've been looking but do not see it
...
Well, he is telling you to run the dtrace program as root in one
window, and run the zfs get all command on a dataset in your pool
in another window, to trigger the dataset_stats variable to be filled.
none can hide from
Hello all,
With original old ZFS iSCSI implementation there was
a shareiscsi property for the zvols to be shared out,
and I believe all configuration pertinent to the iSCSI
server was stored in the pool options (I may be wrong,
but I'd expect that given that ZFS-attribute-based
configs were
--- On Tue, 9/25/12, Volker A. Brandt v...@bb-c.de wrote:
Well, he is telling you to run the dtrace program as root in
one
window, and run the zfs get all command on a dataset in
your pool
in another window, to trigger the dataset_stats variable to
be filled.
none can hide from
2012-09-11 16:29, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Dan Swartzendruber
My first thought was everything is
hitting in ARC, but that is clearly not the case, since it
On 9/25/2012 3:38 PM, Jim Klimov wrote:
2012-09-11 16:29, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Dan Swartzendruber
My first thought was everything is
hitting in ARC,
On Sep 25, 2012, at 12:30 PM, Jim Klimov jimkli...@cos.ru wrote:
Hello all,
With original old ZFS iSCSI implementation there was
a shareiscsi property for the zvols to be shared out,
and I believe all configuration pertinent to the iSCSI
server was stored in the pool options (I may be
On Sep 25, 2012, at 11:17 AM, Jason Usher jushe...@yahoo.com wrote:
Ok - but from a performance point of view, I am only using
ram/cpu resources for the deduping of just the individual
filesystems I enabled dedupe on, right ? I hope that
turning on dedupe for just one filesystem did not
2012-09-26 0:21, Richard Elling пишет:
Does this mean that importing a pool with iSCSI zvols
on a fresh host (LiveCD instance on the same box, or
via failover of shared storage to a different host)
will not be able to automagically share the iSCSI
targets the same way as they were known in the
On 09/25/2012 09:38 PM, Jim Klimov wrote:
2012-09-11 16:29, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Dan Swartzendruber
My first thought was everything is
hitting in
2012-09-24 21:08, Jason Usher wrote:
Ok, thank you. The problem with this is, the
compressratio only goes to two significant digits, which
means if I do the math, I'm only getting an
approximation. Since we may use these numbers to
compute billing, it is important to get it right.
Is there
On Sep 25, 2012, at 1:32 PM, Jim Klimov jimkli...@cos.ru wrote:
2012-09-26 0:21, Richard Elling пишет:
Does this mean that importing a pool with iSCSI zvols
on a fresh host (LiveCD instance on the same box, or
via failover of shared storage to a different host)
will not be able to
On Sep 25, 2012, at 1:46 PM, Jim Klimov jimkli...@cos.ru wrote:
2012-09-24 21:08, Jason Usher wrote:
Ok, thank you. The problem with this is, the
compressratio only goes to two significant digits, which
means if I do the math, I'm only getting an
approximation. Since we may use these
2012-09-26 2:52, Richard Elling wrote:
I am not sure if there is a simple way to get exact
byte-counts instead of roundings like 422M...
zfs get -p
-- richard
Thanks to all who corrected me, never too old to learn ;)
# zfs get referenced rpool/export/home
NAME PROPERTY
16 matches
Mail list logo
