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 referen
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 Tue, Jul 31, 2012 at 9:36 AM, Ray Arachelian wrote:
> On 07/31/2012 09:46 AM, opensolarisisdeadlongliveopensolaris wrote:
>> Dedup: First of all, I don't recommend using dedup under any
>> circumstance. Not that it's unstable or anything, just that the
>> performance is so horrible, it's never
On Mon, Jun 18, 2012 at 5:26 PM, Carson Gaspar wrote:
> What makes you think the Barracuda 7200.14 drives report 4k sectors? I gave
> up looking for 4kn drives, as everything I could find was 512e. I would
> _love_ to be wrong, as I have 8 4TB Hitachis on backorder that I would
> gladly replace wi
On Mon, May 28, 2012 at 6:13 PM, Daniel Carosone wrote:
> On Mon, May 28, 2012 at 09:23:25AM -0600, Nigel W wrote:
>> After a snafu
>> last week at $work where a 512 byte pool would not resilver with a 4K
>> drive plugged in, it appears that (keep in mind that these a
On Mon, May 28, 2012 at 6:48 AM, Nathan Kroenert wrote:
> Anyone offer up suggestions of either 3 or preferably 4TB drives that
> actually work well with ZFS out of the box? (And not perform like
> rubbish)...
With our NCP 3 boxes the WD drives seem to be working okay (this is
with consumer level
On Mon, Dec 5, 2011 at 17:46, Jim Klimov wrote:
> So, in contrast with Nigel's optimistic theory that
> metadata is anyway extra-redundant and should be
> easily fixable, it seems that I do still have the
> problem. It does not show itself in practice as of
> yet, but is found by scrub ;)
Hmm. In
On Fri, Dec 2, 2011 at 02:58, Jim Klimov wrote:
> My question still stands: is it possible to recover
> from this error or somehow safely ignore it? ;)
> I mean, without backing up data and recreating the
> pool?
>
> If the problem is in metadata but presumably the
> pool still works, then this pa