From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 13/13] repair: phase 1 does not handle superblock CRCs
Date: Fri, 7 Mar 2014 10:22:38 +1100 [thread overview]
Message-ID: <20140306232238.GN6851@dastard> (raw)
In-Reply-To: <20140306160155.GA11842@laptop.bfoster>
On Thu, Mar 06, 2014 at 11:01:55AM -0500, Brian Foster wrote:
> On Tue, Mar 04, 2014 at 07:51:57PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > Phase 1 of xfs_repair verifies and corrects the primary
> > superblock of the filesystem. It does not verify that the CRC of the
> > superblock that is found is correct, nor does it recalculate the CRC
> > of the superblock it rewrites.
> >
> > This happens because phase1 does not use the libxfs buffer cache -
> > it just uses pread/pwrite on a memory buffer, and works directly
> > from that buffer. Hence we need to add CRC verification to
> > verify_sb(), and CRC recalculation to write_primary_sb() so that it
> > works correctly.
> >
> > This also enables us to use get_sb() as the method of fetching the
> > superblock from disk after phase 1 without needing to use the libxfs
> > buffer cache and guessing at the sector size. This prevents a
> > verifier error because it attempts to CRC a superblock buffer that
> > is much longer than the usual sector sizes.
> >
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > ---
> > repair/agheader.c | 2 +-
> > repair/globals.h | 3 ++-
> > repair/phase1.c | 5 ++--
> > repair/protos.h | 3 ++-
> > repair/sb.c | 71 +++++++++++++++++++++++++++++------------------------
> > repair/xfs_repair.c | 26 +++++++++++---------
> > 6 files changed, 62 insertions(+), 48 deletions(-)
> >
> > diff --git a/repair/agheader.c b/repair/agheader.c
> > index 53e47b6..fc5dac9 100644
> > --- a/repair/agheader.c
> > +++ b/repair/agheader.c
> > @@ -472,7 +472,7 @@ verify_set_agheader(xfs_mount_t *mp, xfs_buf_t *sbuf, xfs_sb_t *sb,
> > int status = XR_OK;
> > int status_sb = XR_OK;
> >
> > - status = verify_sb(sb, (i == 0));
> > + status = verify_sb(sbuf->b_addr, sb, (i == 0));
> >
> > if (status != XR_OK) {
> > do_warn(_("bad on-disk superblock %d - %s\n"),
> > diff --git a/repair/globals.h b/repair/globals.h
> > index cbb2ce7..f6e0a22 100644
> > --- a/repair/globals.h
> > +++ b/repair/globals.h
> > @@ -49,7 +49,8 @@
> > #define XR_BAD_SB_UNIT 17 /* bad stripe unit */
> > #define XR_BAD_SB_WIDTH 18 /* bad stripe width */
> > #define XR_BAD_SVN 19 /* bad shared version number */
> > -#define XR_BAD_ERR_CODE 20 /* Bad error code */
> > +#define XR_BAD_CRC 20 /* Bad CRC */
> > +#define XR_BAD_ERR_CODE 21 /* Bad error code */
> >
> > /* XFS filesystem (il)legal values */
> >
> > diff --git a/repair/phase1.c b/repair/phase1.c
> > index 62de211..ec75ada 100644
> > --- a/repair/phase1.c
> > +++ b/repair/phase1.c
> > @@ -70,13 +70,14 @@ phase1(xfs_mount_t *mp)
> > ag_bp = alloc_ag_buf(MAX_SECTSIZE);
> > sb = (xfs_sb_t *) ag_bp;
> >
> > - if (get_sb(sb, 0LL, MAX_SECTSIZE, 0) == XR_EOF)
> > + rval = get_sb(sb, 0LL, MAX_SECTSIZE, 0);
> > + if (rval == XR_EOF)
> > do_error(_("error reading primary superblock\n"));
> >
> > /*
> > * is this really an sb, verify internal consistency
> > */
>
> This comment can probably go away now. Otherwise, looks good...
>
> Reviewed-by: Brian Foster <bfoster@redhat.com>
Ok, thanks. I'll kill the comment in a followup patch that touches
this code again...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-03-06 23:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 8:51 [PATCH 00/13] xfsprogs: initial EFSBADCRC support Dave Chinner
2014-03-04 8:51 ` [PATCH 01/13] libxfs: be more forgiving of a v4 secondary sb w/ junk in v5 fields Dave Chinner
2014-03-04 8:51 ` [PATCH 02/13] libxfs: sanitize sb_inopblock in xfs_mount_validate_sb Dave Chinner
2014-03-04 8:51 ` [PATCH 03/13] libxfs: xfs_sb_read_verify() doesn't flag bad crcs on primary sb Dave Chinner
2014-03-04 8:51 ` [PATCH 04/13] libxfs: skip verification on initial "guess" superblock read Dave Chinner
2014-03-04 8:51 ` [PATCH 05/13] libxfs: limit superblock corruption errors to actual corruption Dave Chinner
2014-03-04 8:51 ` [PATCH 06/13] libxfs: skip pointless CRC updates after verifier failures Dave Chinner
2014-03-04 8:51 ` [PATCH 07/13] libxfs: Use defines for CRC offsets in all cases Dave Chinner
2014-03-04 8:51 ` [PATCH 08/13] libxfs: add helper for verifying checksums on xfs_bufs Dave Chinner
2014-03-04 8:51 ` [PATCH 09/13] libxfs: add helper for updating " Dave Chinner
2014-03-04 8:51 ` [PATCH 10/13] libxfs: add xfs_verifier_error() Dave Chinner
2014-03-04 8:51 ` [PATCH 11/13] libxfs: modify verifiers to differentiate CRC from other errors Dave Chinner
2014-03-04 8:51 ` [PATCH 12/13] xfs_db: Use EFSBADCRC for CRC validity indication Dave Chinner
2014-03-05 0:12 ` Eric Sandeen
2014-03-04 8:51 ` [PATCH 13/13] repair: phase 1 does not handle superblock CRCs Dave Chinner
2014-03-06 16:01 ` Brian Foster
2014-03-06 23:22 ` Dave Chinner [this message]
2014-03-05 0:04 ` [PATCH 00/13] xfsprogs: initial EFSBADCRC support Eric Sandeen
2014-03-07 10:46 ` Christoph Hellwig
2014-03-07 22:50 ` Dave Chinner
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=20140306232238.GN6851@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=xfs@oss.sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox