On Thu, Aug 2, 2012 at 3:39 PM, Richard Elling wrote:
> On Aug 1, 2012, at 8:30 AM, Nigel W wrote:
>
>
> Yes. +1
>
> The L2ARC as is it currently implemented is not terribly useful for
> storing the DDT in anyway because each DDT entry is 376 bytes but the
> L2ARC reference is 176 bytes, so best c
hi
can you post zpool history
regards
Sent from my iPad
On Aug 2, 2012, at 7:47, Suresh Kumar wrote:
> Hi Hung-sheng,
>
> It is not displaying any output, like the following.
>
> bash-3.2# zpool import -nF tXstpool
> bash-3.2#
>
>
> Thanks & Regards,
> Suresh.
>
>
_
My experience has always been that ZFS tries hard to keep you from doing
something wrong when devices are failing or otherwise unavailable. With
mirrors, it will import with a device missing from a mirror vdev. I don't use
cache or log devices in my mainly storage pools, so I've not seen a fa
On Jul 31, 2012, at 8:05 PM, opensolarisisdeadlongliveopensolaris wrote:
>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>> boun...@opensolaris.org] On Behalf Of Richard Elling
>>
>> I believe what you meant to say was "dedup with HDDs sux." If you had
>> used fast SSDs instead
On 2012-Aug-02 18:30:01 +0530, opensolarisisdeadlongliveopensolaris
wrote:
>Ok, so the point is, in some cases, somebody might want redundancy on
>a device that has no redundancy. They're willing to pay for it by
>halving their performance.
This isn't quite true - write performance will be at l
On Aug 1, 2012, at 12:21 AM, Suresh Kumar wrote:
> Dear ZFS-Users,
>
> I am using Solarisx86 10u10, All the devices which are belongs to my zpool
> are in available state .
> But I am unable to import the zpool.
>
> #zpool import tXstpool
> cannot import 'tXstpool': one or more devices is curr
On Aug 1, 2012, at 8:30 AM, Nigel W wrote:
> On Wed, Aug 1, 2012 at 8:33 AM, Sašo Kiselkov wrote:
>> On 08/01/2012 04:14 PM, Jim Klimov wrote:
>>> chances are that
>>> some blocks of userdata might be more popular than a DDT block and
>>> would push it out of L2ARC as well...
>>
>> Which is why I
On Aug 1, 2012, at 2:41 PM, Peter Jeremy wrote:
> On 2012-Aug-01 21:00:46 +0530, Nigel W wrote:
>> I think a fantastic idea for dealing with the DDT (and all other
>> metadata for that matter) would be an option to put (a copy of)
>> metadata exclusively on a SSD.
>
> This is on my wishlist as w
On 01/08/12 3:34 PM, opensolarisisdeadlongliveopensolaris wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Jim Klimov
Well, there is at least a couple of failure scenarios where
copies>1 are good:
1) A single-disk pool, as in a laptop.
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
> In some of my cases I was "lucky" enough to get a corrupted /sbin/init
> or something like that once, and the box had no other BE's yet, so the
> OS could not do anything reasona
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
> 2012-08-01 23:40, opensolarisisdeadlongliveopensolaris пишет:
>
> > Agreed, ARC/L2ARC help in finding the DDT, but whenever you've got a
> snapshot destroy (happens every 15 min
so zpool import -F ..
zpool import -f ...
all not working?
regards
Sent from my iPad
On Aug 2, 2012, at 7:47, Suresh Kumar wrote:
> Hi Hung-sheng,
>
> It is not displaying any output, like the following.
>
> bash-3.2# zpool import -nF tXstpool
> bash-3.2#
>
>
> Thanks & Regards,
> Sur
Hi Hung-sheng,
It is not displaying any output, like the following.
bash-3.2# zpool import -nF tXstpool
bash-3.2#
*Thanks & Regards,*
*Suresh.*
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-
http://docs.oracle.com/cd/E19963-01/html/821-1448/gbbwl.html
what is the output of
*zpool import -nF tXstpool*
On 8/2/2012 2:21 AM, Suresh Kumar wrote:
Hi Hung-sheng,
Thanks for your response.
I tried to import the zpool using *zpool import -nF tXstpool*
please consider the below output.
*bash-
14 matches
Mail list logo
