[Top] [All Lists]

Re: [PATCH 1/3] xfs: don't shutdown log recovery on validation errors

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 1/3] xfs: don't shutdown log recovery on validation errors
From: Ben Myers <bpm@xxxxxxx>
Date: Wed, 12 Jun 2013 20:04:41 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1371003548-4026-2-git-send-email-david@xxxxxxxxxxxxx>
References: <1371003548-4026-1-git-send-email-david@xxxxxxxxxxxxx> <1371003548-4026-2-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
Hey Dave,

On Wed, Jun 12, 2013 at 12:19:06PM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> Unfortunately, we cannot guarantee that items logged multiple times
> and replayed by log recovery do not take objects back in time. When
> theya re taken back in time, the go into an intermediate state which
> is corrupt, and hence verification that occurs on this intermediate
> state causes log recovery to abort with a corruption shutdown.
> Instead of causing a shutdown and unmountable filesystem, don't
> verify post-recovery items before they are written to disk. This is
> less than optimal, but there is no way to detect this issue for
> non-CRC filesystems If log recovery successfully completes, this
> will be undone and the object will be consistent by subsequent
> transactions that are replayed, so in most cases we don't need to
> take drastic action.
> For CRC enabled filesystems, leave the verifiers in place - we need
> to call them to recalculate the CRCs on the objects anyway. This
> recovery problem canbe solved for such filesystems - we have a LSN
> stamped in all metadata at writeback time that we can to determine
> whether the item should be replayed or not. This is a separate piece
> of work, so is not addressed by this patch.

Is there a test case for this one?  How are you reproducing this?


<Prev in Thread] Current Thread [Next in Thread>