All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Eric Sandeen <sandeen@sandeen.net>,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/6] xfs: verify extent size hint is valid in inode verifier
Date: Wed, 22 Aug 2018 10:41:14 +1000	[thread overview]
Message-ID: <20180822004113.GQ31495@dastard> (raw)
In-Reply-To: <20180821105645.GA14228@bfoster>

On Tue, Aug 21, 2018 at 06:56:45AM -0400, Brian Foster wrote:
> On Tue, Aug 21, 2018 at 08:15:06AM +1000, Dave Chinner wrote:
> > We should clear them on free now, so that we can draw a line in the
> > sand for when we can have verifiers check it. e.g. when the next
> > feature bit gets introduced, filesystems with that feature bit set
> > can also verify the extent size hints are zero on freed inodes
> > because we know that kernels supporting that feature always zero
> > them on free....
> > 
> 
> That seems fine (and harmless) to me if the goal is ultimately to have
> this content clear on-disk. It keeps things consistent for verifiers,
> scrub, repair, etc. to not have some bits with required initialized
> values and others where we need to accommodate stale data.

*nod*

One of my original goals for all the online repair work was to
ensure that everything on disk was clean, sanitised and not
ambiguous in any way. The verifiers are a mechanism that helps us
identify things that aren't clean or sanitised, and working out how
to verify those things identifies ambiguities we need to fix. Such
as this one with freed inodes.

As I said to Eric on #xfs:

<dchinner_> We're well beyond the point where we trust a single field
	    in an on-disk structure to be the One True Source of Truth
<dchinner_> we want everything on disk to be correct and clean
<dchinner_> so we can make decisions like this correctly via
	    multi-field verifications


-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-08-22  4:03 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05  6:24 [PATCH 0/6 V2] xfs: more verifications! Dave Chinner
2018-06-05  6:24 ` [PATCH 1/6] xfs: catch bad stripe alignment configurations Dave Chinner
2018-06-05  9:27   ` Carlos Maiolino
2018-06-05  6:24 ` [PATCH 2/6] xfs: verify extent size hint is valid in inode verifier Dave Chinner
2018-06-05  9:53   ` Carlos Maiolino
2018-06-05 22:56     ` Dave Chinner
2018-06-05 17:10   ` Darrick J. Wong
2018-06-07 16:16     ` Darrick J. Wong
2018-06-08  1:10       ` Dave Chinner
2018-06-08  1:23         ` Darrick J. Wong
2018-06-08  2:23           ` Eric Sandeen
2018-07-24  6:39   ` Eric Sandeen
2018-07-24 16:43     ` Darrick J. Wong
2018-08-20 15:06       ` Brian Foster
2018-08-20 15:27         ` Eric Sandeen
2018-08-20 15:36           ` Darrick J. Wong
2018-08-20 15:59             ` Brian Foster
2018-08-20 22:15               ` Dave Chinner
2018-08-21 10:56                 ` Brian Foster
2018-08-22  0:41                   ` Dave Chinner [this message]
2018-06-05  6:24 ` [PATCH 3/6] xfs: verify COW " Dave Chinner
2018-06-05 10:00   ` Carlos Maiolino
2018-06-05 17:09   ` Darrick J. Wong
2018-06-05  6:24 ` [PATCH 4/6] xfs: validate btree records on retreival Dave Chinner
2018-06-05  6:40   ` [PATCH 4/6 v2] " Dave Chinner
2018-06-05 10:42     ` Carlos Maiolino
2018-06-05 23:00       ` Dave Chinner
2018-06-05 17:47     ` Darrick J. Wong
2018-06-05 23:02       ` Dave Chinner
2018-06-06  1:21     ` [PATCH 4/6 v3] " Dave Chinner
2018-06-05  6:24 ` [PATCH 5/6] xfs: verify root inode more thoroughly Dave Chinner
2018-06-05 10:50   ` Carlos Maiolino
2018-06-05 17:10   ` Darrick J. Wong
2018-06-05  6:24 ` [PATCH 6/6] xfs: push corruption -> ESTALE conversion to xfs_nfs_get_inode() Dave Chinner
2018-06-05 11:12   ` Carlos Maiolino
2018-06-05 17:11   ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180822004113.GQ31495@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.