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= clone
#zfs set share=name= clone
#zfs set sharenfs=on clone
The origin filesystem is no longer shared (the clone is s
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 rep
--- On Mon, 9/24/12, Richard Elling 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", this->ds->ds_dir->dd_m
> 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 f
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 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 dtrace
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, bu
On Sep 25, 2012, at 12:30 PM, Jim Klimov 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 wrong,
> b
On Sep 25, 2012, at 11:17 AM, Jason Usher 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 incur
> ram/cpu c
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 i
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
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 any
On Sep 25, 2012, at 1:32 PM, Jim Klimov 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 automagically
On Sep 25, 2012, at 1:46 PM, Jim Klimov 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 numbers
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
