linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: Girish Shilamkar <girish@clusterfs.com>,
	cmm@us.ibm.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [EXT4 set 8][PATCH 1/1]Add journal checksums
Date: Wed, 11 Jul 2007 10:29:17 -0700	[thread overview]
Message-ID: <20070711102917.88ef762a.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070711130108.GB6417@schatzie.adilger.int>

On Wed, 11 Jul 2007 07:01:08 -0600 Andreas Dilger <adilger@clusterfs.com> wrote:

> > > > -	/* AKPM: buglet - add `i' to tmp! */
> > > 
> > > Damn.  After, what, seven years, someone actually fixed it?
> > > 
> > > >  	for (i = 0; i < bh->b_size; i += 512) {
> > > > -		journal_header_t *tmp = (journal_header_t*)bh->b_data;
> > > > +		struct commit_header *tmp =
> > > > +			(struct commit_header *)(bh->b_data + i);
> > > >  		tmp->h_magic = cpu_to_be32(JBD2_MAGIC_NUMBER);
> > > >  		tmp->h_blocktype = cpu_to_be32(JBD2_COMMIT_BLOCK);
> > > >  		tmp->h_sequence = cpu_to_be32(commit_transaction->t_tid);
> > > > +
> > > > +		if (JBD2_HAS_COMPAT_FEATURE(journal,
> > > > +					    JBD2_FEATURE_COMPAT_CHECKSUM)) {
> > > > +			tmp->h_chksum_type 	= JBD2_CRC32_CHKSUM;
> > > > +			tmp->h_chksum_size 	= JBD2_CRC32_CHKSUM_SIZE;
> > > > +			tmp->h_chksum[0] 	= cpu_to_be32(crc32_sum);
> > > > +		}
> > > >  	}
> > > 
> > > And in doing so, changed the on-disk format of the journal commit blocks.
> > > 
> > > Surely this was worth a mention in the changelog, if not a standalone patch?
> > > 
> > > I don't think this is worth doing, really.  Why not just leave the format
> > > as it was, take the loop out and run this code once rather than eight
> > > times?
> 
> Well, we aren't using the rest of the commit block in any case.  I think
> the original intention was that we'd get 8 copies of the commit block so
> we would be sure to get a good one.
> 
> I don't know whether we'd rather have 8 copies of the commit block, or
> more potential to expand the commit block?  I don't personally have any
> preference, since the checksum should be a more robust way of checking
> validity than having multiple copies, so we may as well remove the loop
> and stick with a single copy for now.

We've never altered any commit block sectors apart from the zeroeth one
(eight times) due to the above bug.  So I'd suggest that we should formalise
the old bug and leave the format as-is.  That'll leave lots of space spare in
the commit block.

  reply	other threads:[~2007-07-11 17:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-01  7:38 [EXT4 set 8][PATCH 1/1]Add journal checksums Mingming Cao
2007-07-11  6:16 ` Andrew Morton
2007-07-11 11:46   ` Girish Shilamkar
2007-07-11 13:01     ` Andreas Dilger
2007-07-11 17:29       ` Andrew Morton [this message]
2007-08-01  7:04     ` Girish Shilamkar
2007-08-07  5:25       ` Mingming Cao

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=20070711102917.88ef762a.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=adilger@clusterfs.com \
    --cc=cmm@us.ibm.com \
    --cc=girish@clusterfs.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).