Skip to main content

Re: Bug 15809921 on a pool *without* l2arc?

  • From: Victor Latushkin < >
  • To:
  • Subject: Re: Bug 15809921 on a pool *without* l2arc?
  • Date: Fri, 26 Jul 2013 08:04:11 -0600

On 7/26/13 7:59 AM, Robin P. Blanchard wrote:

On Jul 24, 2013, at 16:50 PM, Victor Latushkin wrote:

On 7/24/13 2:43 PM, Robin P. Blanchard wrote:

On Jul 24, 2013, at 16:32 PM, Robin P. Blanchard wrote:


On Jul 24, 2013, at 15:50 PM, Victor Latushkin wrote:

On 7/24/13 1:41 PM, Robin P. Blanchard wrote:
We have just discovered (on 11.0 SRU 13.4 + idr357) that we have seemingly 
tripped 15809921 / SUNBT7191375 on a pool that did *not* have l2arc devices. 
The pool, as indicated below in its trimmed zpool history, did at one time 
have a cache device enabled.

Being unable to schedule a complete maintenance window back in March (when we 
first tripped this same bug on a different system, *with* l2arc), the 
customer elected to remove the l2arc device to mitigate the risk. It would 
seem, however, that said bug can be tripped *without* l2arc present. Or is it 
possible that the metadata became corrupted while there was l2arc present and 
-- despite the device's removal -- only now was the bug triggered? The latter 
scenario is quite troubling....

Thoughts?

Since L2ARC device was present in the config at one time in the past, it 
could damage this pool. It is only detected when corresponding space map is 
loaded.

Victor


Thanks for the quick reply, Victor.

I'm trying to get the full implications of your answer. Does this mean that any pool 
that had had l2arc at any point prior to 11.1 SRU 3.4 could have this sleeping bug? We 
were under the impression that the removal of cache devices would mitigate this bug (as 
stated back on 19 December 2012 to this list " Solaris 11 System Reboots 
Continuously Because of a ZFS-Related Panic (7191375)"). Any help/suggestions you 
can provide would be most appreciated.

Does this also imply that the damage could be done, the cache removed, the 
system patched to post 11.1 SRU 3.4 and the bug still strike?

Damage can strike, not the bug.



more questions: what operations can "tickle" the (dormant) corruption? As we 
attempt to formulate a mitigation plan, we need to determine the safest method by which 
to isolate pools to individual nodes (so as to avoid impact on other co-existing pools)

if dormant corruption exists:
01) does zpool export trigger panic?

It depends

02) can we safely zfs snap, send and receive without triggering a panic?

It depends

03) is it safe to run zdb -emm on an read/write imported pool? (will this 
only trigger a core-dump if spacemap corruption is detected? or a panic?)

It is safe in a sense that it will not trigger the panic if corruption is there, but it cannot provide reliable results

04) if a pool (that once had l2arc) has been since successfully scrubbed, does that 
indicate the pool is "safe"?

No


--
Robin P. Blanchard
Coraid CTAC
support.coraid.com
+1 650.730.5140








Bug 15809921 on a pool *without* l2arc?

Robin P. Blanchard 07/24/2013

Re: Bug 15809921 on a pool *without* l2arc?

Victor Latushkin 07/24/2013

Re: Bug 15809921 on a pool *without* l2arc?

Robin P. Blanchard 07/24/2013

Re: Bug 15809921 on a pool *without* l2arc?

Victor Latushkin 07/24/2013

Re: Bug 15809921 on a pool *without* l2arc?

Robin P. Blanchard 07/24/2013

Re: Bug 15809921 on a pool *without* l2arc?

Victor Latushkin 07/24/2013

Re: Bug 15809921 on a pool *without* l2arc?

Robin P. Blanchard 07/26/2013

Re: Bug 15809921 on a pool *without* l2arc?

Victor Latushkin 07/26/2013

Re: Bug 15809921 on a pool *without* l2arc?

Robin P. Blanchard 07/26/2013
 
 
Close
loading
Please Confirm
Close