From: Michael Nishimoto <miken@agami.com>
To: David Chinner <dgc@sgi.com>
Cc: markgw@sgi.com, xfs-dev <xfs-dev@sgi.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: RFC: log record CRC validation
Date: Thu, 26 Jul 2007 18:24:51 -0700 [thread overview]
Message-ID: <46A94963.7000103@agami.com> (raw)
In-Reply-To: <20070726233129.GM12413810@sgi.com>
The log checksum code has not been used since the
development phase of xfs. It did work at one point because I
remember using it and then decided to disable it and use just
the current cycle stamping technique. The checksum code was
just advisory, so I could see if it ever occurred during
development.
When a CRC error is found, your suggestion is correct. Recovery
should backup and process only completely good log records. The code
backs up in this same fashion when it encounters a region of
missing sector updates because of the async nature of log
writes and disk caches.
At this point, I'm not convinced that xfs needs to do CRCs on
the xfs log because the size of an xfs log is relatively small.
Michael
> Date: Wed, 25 Jul 2007 19:24:45 +1000
> From: David Chinner <dgc@sgi.com>
> To: xfs-dev <xfs-dev@sgi.com>
> Cc: xfs-oss <xfs@oss.sgi.com>
> Subject: RFC: log record CRC validation
>
> Folks,
>
> I've just fixed up the never-used-debug log record checksumming
> code with an eye to permanently enabling it for production
> filesystems.
>
> Firstly, I updated the simple 32 bit wide XOR checksum to use the
> crc32c module. This places an new dependency on XFS - it will now
> depends on CONFIG_LIBCRC32C. I'm also not sure what the best
> method to use is - the little endian or big endian CRC algorithm
> so I just went for the default (crc32c()).
>
> This then resulted in recovery failing to verify the checksums,
> and it turns out that is because xfs_pack_data() gets passed a
> padded buffer and size to checksum (padded to 512 bytes), whereas
> the unpacking (recovery) only checksummed the unpadded record
> length. Hence this code probably never worked reliably if anyone
> ever enabled it.
>
> This does bring up a question - probably for Tim - do we only get
> rounded to BBs or do we get rounded to the log stripe unit when
> packing the log records before writeout? It seems froma quick test
> that it is only BBs, but confirmation would be good....
>
> The next question is the hard one. What do we do when we detect
> a log record CRC error? Right now it just warns and sets a flag
> in the log. I think it should probably prevent log replay from
> replaying past this point (i.e. trim the head back to the last
> good log record) but I'm not sure what the best thing to do here.
>
> Comments?
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> Principal Engineer
> SGI Australian Software Group
>
next prev parent reply other threads:[~2007-07-27 1:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070725092445.GT12413810@sgi.com>
2007-07-25 10:14 ` RFC: log record CRC validation Mark Goodwin
2007-07-26 5:55 ` David Chinner
2007-07-26 23:01 ` Andi Kleen
2007-07-26 23:50 ` David Chinner
2007-07-26 17:53 ` Michael Nishimoto
2007-07-26 23:31 ` David Chinner
2007-07-27 1:24 ` Michael Nishimoto [this message]
2007-07-27 6:59 ` David Chinner
2007-08-01 0:49 ` Michael Nishimoto
2007-08-01 2:24 ` David Chinner
2007-08-01 2:36 ` Barry Naujok
2007-08-01 2:43 ` David Chinner
2007-08-01 12:11 ` Andi Kleen
2007-07-28 2:00 ` William J. Earl
2007-07-28 14:03 ` Andi Kleen
2007-07-31 5:30 ` David Chinner
2007-08-01 1:32 ` William J. Earl
2007-08-01 10:02 ` David 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=46A94963.7000103@agami.com \
--to=miken@agami.com \
--cc=dgc@sgi.com \
--cc=markgw@sgi.com \
--cc=xfs-dev@sgi.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