On Aug 2, 2012, at 5:40 PM, Nigel W wrote:
> 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
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
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 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
> 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
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 well. I believe ZEVO supports it so possibly
it'll be availab
2012-08-01 23:34, opensolarisisdeadlongliveopensolaris пишет:
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. Noi
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 minutes) you've got a lot of entries you need to
write. Those are all scattered about the pool... Even if you can find them
f
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
> 2012-08-01 22:07, opensolarisisdeadlongliveopensolaris пишет:
> > L2ARC is a read cache. Hence the "R" and "C" in "L2ARC."
>
> "R" is replacement, but what the hell ;)
>
> > T
> 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. Noise on the bus,
> media degradation, or any oth
On 01 August, 2012 - opensolarisisdeadlongliveopensolaris sent me these 1,8K
bytes:
> > From: Sa??o Kiselkov [mailto:skiselkov...@gmail.com]
> > Sent: Wednesday, August 01, 2012 9:56 AM
> >
> > On 08/01/2012 03:35 PM, opensolarisisdeadlongliveopensolaris wrote:
> > >> From: zfs-discuss-boun...@o
2012-08-01 22:07, opensolarisisdeadlongliveopensolaris пишет:
L2ARC is a read cache. Hence the "R" and "C" in "L2ARC."
"R" is replacement, but what the hell ;)
This means two major things:
#1 Writes don't benefit,
and
#2 There's no way to load the whole DDT into the cache anyway. So you'r
> From: opensolarisisdeadlongliveopensolaris
> Sent: Wednesday, August 01, 2012 2:08 PM
>
> L2ARC is a read cache. Hence the "R" and "C" in "L2ARC."
> This means two major things:
> #1 Writes don't benefit,
> and
> #2 There's no way to load the whole DDT into the cache anyway. So you're
> gua
> From: Sašo Kiselkov [mailto:skiselkov...@gmail.com]
> Sent: Wednesday, August 01, 2012 9:56 AM
>
> On 08/01/2012 03:35 PM, opensolarisisdeadlongliveopensolaris wrote:
> >> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> >> boun...@opensolaris.org] On Behalf Of Jim Klimov
> >>
>
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 plan on investigating implementing some tunable pol
On 08/01/2012 04:14 PM, Jim Klimov wrote:
> 2012-08-01 17:55, Sašo Kiselkov пишет:
>> On 08/01/2012 03:35 PM, opensolarisisdeadlongliveopensolaris wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Jim Klimov
Availability
2012-08-01 17:55, Sašo Kiselkov пишет:
On 08/01/2012 03:35 PM, opensolarisisdeadlongliveopensolaris wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Jim Klimov
Availability of the DDT is IMHO crucial to a deduped pool, so
I won't be sur
2012-08-01 17:35, opensolarisisdeadlongliveopensolaris пишет:
Personally, I've never been supportive of the whole "copies" idea. If you need more than
one redundant copy of some data, that's why you have pool redundancy. You're just hurting
performance by using "copies." And protecting again
On 08/01/2012 03:35 PM, opensolarisisdeadlongliveopensolaris wrote:
>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>> boun...@opensolaris.org] On Behalf Of Jim Klimov
>>
>> Availability of the DDT is IMHO crucial to a deduped pool, so
>> I won't be surprised to see it forced to
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
> Availability of the DDT is IMHO crucial to a deduped pool, so
> I won't be surprised to see it forced to triple copies.
Agreed, although, the DDT is also paramount to performa
2012-08-01 16:22, Sašo Kiselkov пишет:
On 08/01/2012 12:04 PM, Jim Klimov wrote:
Probably DDT is also stored with 2 or 3 copies of each block,
since it is metadata. It was not in the last ZFS on-disk spec
from 2006 that I found, for some apparent reason ;)
The idea of the pun was that the lat
On 08/01/2012 12:04 PM, Jim Klimov wrote:
> Probably DDT is also stored with 2 or 3 copies of each block,
> since it is metadata. It was not in the last ZFS on-disk spec
> from 2006 that I found, for some apparent reason ;)
That's probably because it's extremely big (dozens, hundreds or even
thous
2012-07-31 17:55, opensolarisisdeadlongliveopensolaris пишет:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Nico Williams
The copies thing is a really only for laptops, where the likelihood of
redundancy is very low
ZFS also stores multipl
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Nico Williams
>
> The copies thing is a really only for laptops, where the likelihood of
> redundancy is very low
ZFS also stores multiple copies of things that it considers "extra important.
The copies thing is a really only for laptops, where the likelihood of
redundancy is very low (there are some high-end laptops with multiple
drives, but those are relatively rare) and where this idea is better
than nothing. It's also nice that copies can be set on a per-dataset
manner (whereas RAI
On Mon, Jul 30, 2012 at 7:11 AM, GREGG WONDERLY wrote:
> I thought I understood that copies would not be on the same disk, I guess I
> need to go read up on this again.
ZFS attempts to put copies on separate devices, but there's no guarantee.
-B
--
Brandon High : bh...@freaks.com
On 07/29/12 14:52, Bob Friesenhahn wrote:
My opinion is that complete hard drive failure and block-level media
failure are two totally different things.
That would depend on the recovery behavior of the drive for
block-level media failure. A drive whose firmware does excessive
(reports of up
On Jul 29, 2012, at 3:12 PM, opensolarisisdeadlongliveopensolaris
wrote:
>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>> boun...@opensolaris.org] On Behalf Of Jim Klimov
>>
>> I wondered if the "copies" attribute can be considered sort
>> of equivalent to the number of p
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
>I wondered if the "copies" attribute can be considered sort
> of equivalent to the number of physical disks - limited to seek
> times though. Namely, for the same amount of st
On Sun, 29 Jul 2012, Jim Klimov wrote:
Would extra copies on larger disks actually provide the extra
reliability, or only add overheads and complicate/degrade the
situation?
My opinion is that complete hard drive failure and block-level media
failure are two totally different things. Comple
"copies" won't help much if the pool is unavailable. It may, however, help if,
say, you have a RAIDz2, and two drives die, and htere are errors on a third
drive, but not sufficiently bad for zfs to reject the pool
roy
- Opprinnelig melding -
> Hello all,
>
> Over the past few years th
Hello all,
Over the past few years there have been many posts suggesting
that for modern HDDs (several TB size, around 100-200MB/s best
speed) the rebuild times grow exponentially, so to build a well
protected pool with these disks one has to plan for about three
disk's worth of redundancy - th
34 matches
Mail list logo
