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
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
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
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 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-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 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
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 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
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 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
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
> 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
--- 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
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
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
16 matches
Mail list logo
