From: Ted Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
"Darrick J. Wong" <djwong@us.ibm.com>,
Amir Goldstein <amir73il@gmail.com>
Subject: Re: [PATCH 1/2] libext2fs: add metadata checksum and snapshot feature flags
Date: Thu, 15 Sep 2011 21:06:04 -0400 [thread overview]
Message-ID: <20110916010604.GM28181@thunk.org> (raw)
In-Reply-To: <F48B39D1-7E73-4F3B-AA41-3D419CB5EF61@dilger.ca>
On Thu, Sep 15, 2011 at 06:09:04PM -0600, Andreas Dilger wrote:
>
> If you are reading the structure (not modifying it) and trying to verify
> the checksum, it would be necessary to read-lock the structure, zero
> the field, compute the checksum, reset the field, unlock, and then
> compare checksums. Alternately, one would have to make a copy of the
> struct to zero out the field and compute the checksum on the copy. Both
> are more complex than just doing the checksum on two separate chunks.
You have to read-lock the structure before calculating the checksum in
any case, since otherwise when someone else is modifying the
structure, before they have a chance to update the checksum, you'll
calculate the checksum and discover that it is incorrect.
In practice we would probably be calculating the checksum when the
inode if first read into memory, before it it is visible to the rest
of the system, so this shouldn't be an issue. But if it is visible to
the rest of the system, even you put the checksum at the end, if
someone else can modify the data structure while you are calculating
it, the checksum will be wrong.
> No, because for group descriptors, the size is conditional on whether
> RO_COMPAT_GDT_CSUM is set, so it is just as easy to always compute the
> first 32-byte crc32 (excluding the bg_checksum field) and then only
> conditionally compute the second 32-byte checksum. The same is true
> of the inode checksum and s_inode_size, if the checksum is at the last
> field of struct ext2_inode.
But wouldn't it be faster to zero out the two fields, and then
caluclate a single 64-byte checksum? That way we avoid the setup
costs of the crc32, especially in the case of the crc32c-sby8-[lb]e
implementation.
- Ted
next prev parent reply other threads:[~2011-09-16 1:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 22:50 [PATCH 0/2] On disk format changes - V3 Theodore Ts'o
2011-09-15 22:50 ` [PATCH 1/2] libext2fs: add metadata checksum and snapshot feature flags Theodore Ts'o
2011-09-15 23:09 ` Andreas Dilger
2011-09-15 23:11 ` Ted Ts'o
2011-09-15 23:34 ` Andreas Dilger
2011-09-15 23:41 ` Ted Ts'o
2011-09-16 0:09 ` Andreas Dilger
2011-09-16 0:56 ` Darrick J. Wong
2011-09-16 4:03 ` Andreas Dilger
2011-09-16 1:06 ` Ted Ts'o [this message]
2011-09-16 3:57 ` Andreas Dilger
2011-09-16 14:28 ` Ted Ts'o
2011-09-19 18:58 ` Darrick J. Wong
2011-09-20 18:56 ` Darrick J. Wong
2011-09-21 8:03 ` Amir Goldstein
2011-09-21 20:40 ` Darrick J. Wong
2011-09-22 2:12 ` Amir Goldstein
2011-09-22 19:18 ` Darrick J. Wong
2011-09-23 5:57 ` Amir Goldstein
2011-09-15 22:50 ` [PATCH 2/2] debugfs: add 64-bit support to the set_field commands Theodore Ts'o
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=20110916010604.GM28181@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=amir73il@gmail.com \
--cc=djwong@us.ibm.com \
--cc=linux-ext4@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).