LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andreas Dilger <adilger.kernel@dilger.ca>
To: Joel Becker <jlbec@evilplan.org>
Cc: "Darrick J. Wong" <djwong@us.ibm.com>,
Andreas Dilger <aedilger@gmail.com>,
Mingming Cao <cmm@us.ibm.com>, "Theodore Ts'o" <tytso@mit.edu>,
linux-ext4 <linux-ext4@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] Add inode checksum support to ext4
Date: Fri, 29 Jul 2011 03:48:45 -0600 [thread overview]
Message-ID: <0E795C1D-AD1E-4CC4-9426-2B58D98B14DC@dilger.ca> (raw)
In-Reply-To: <20110728220735.GA27253@noexit.corp.google.com>
On 2011-07-28, at 4:07 PM, Joel Becker wrote:
> On Thu, Jul 28, 2011 at 09:56:15AM -0700, Darrick J. Wong wrote:
>>> the block. There of course is no reason to put an extent tail inside the
>>> inode itself.
>>
>> Does anybody have any objection to using crc32c (which we can hardware
>> accelerate on new Intel boxen) over crc16? I think it'll be pretty easy to use
>
> We use ethernet crc32 in ocfs2. btrfs uses crc32c. Frankly, I
> could have used crc32c if I'd really thought about the hardware
> acceleration benefits. I think it's a good idea for ext4.
The problem with crc32[c] is that if you don't have hardware acceleration
it is terribly slow.
>> some of the reserved space in the group descriptor to store checksums of the
>> block and inode bitmaps. Adding tails to the extent tree blocks seems a bit
>> trickier than that, but not a big deal, though I guess I'll have to reshuffle
>> the extent tree to free up space at the end of the block.
>>
>> I was also wondering what people think of adding checksums to directory files?
>> I think that it's possible to put a checksum in each directory block -- for
>> blocks containing a linear array of actual directory entries, we could zero out
>> the space past the end of the array and put a checksum at the very end of the
>> block. For the dx_node/dx_root blocks, we could probably use the space
>> occupied by the last dx_entry to store the checksum. Obviously, we'd have to
>> move whatever's at the end of the block elsewhere, but then, we have to do that
>> for the extent tree too. Basically, the last 4 bytes become the checksum after
>> whatever's occupying the space is relocated. :)
>
> ocfs2 adds trailer entries to every dirblock for the checksum.
> We also do our dirindex free list there. Since ocfs2 dirblocks are ext3
> dirblocks, I bet you can rip off a lot of that code, including the
> feature compatibility stuff. See ocfs2_fs.h.
Yes, it makes sense to just put a "fake" dirent at the end of the leaf block,
or similar. I don't think it is necessary to modify existing directories or
extent blocks to add these structures in, if there is no room, but for new
blocks, or blocks with space it is enough.
>> It looks like there's sufficient unused space in ext4_xattr_header to add a
>> checksum.
>>
>> Also -- should I create separate rocompat feature flags for each metadata
>> object that I add checksums to? Or just have one flag that covers them all?
>
> I really think you should checksum every metadata block. A few
> things will take some effort to shoehorn it in, but it is worth it.
>
> Joel
>
> --
>
> Life's Little Instruction Book #173
>
> "Be kinder than necessary."
>
> http://www.jlbec.org/
> jlbec@evilplan.org
next prev parent reply other threads:[~2011-07-29 9:48 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-06 22:44 Darrick J. Wong
2011-04-06 22:45 ` [PATCH 1/2] ext4: Calculate and verify inode checksums Darrick J. Wong
2011-04-07 0:52 ` Sunil Mushran
2011-04-07 16:40 ` Darrick J. Wong
2011-04-07 17:10 ` Sunil Mushran
2011-04-08 18:50 ` Joel Becker
2011-04-08 19:30 ` Darrick J. Wong
2011-04-08 8:58 ` Andreas Dilger
2011-04-08 19:12 ` Darrick J. Wong
2011-04-08 22:49 ` Andreas Dilger
2011-04-06 22:47 ` [PATCH 2/2] e2fsprogs: Add support for toggling, verifying, and fixing " Darrick J. Wong
2011-04-08 9:14 ` Andreas Dilger
2011-04-08 19:25 ` Darrick J. Wong
2011-04-08 23:13 ` Andreas Dilger
2011-04-12 2:05 ` Darrick J. Wong
2011-04-08 19:27 ` [PATCH 0/2] Add inode checksum support to ext4 Mingming Cao
2011-04-08 20:17 ` Joel Becker
2011-07-27 8:27 ` Darrick J. Wong
2011-07-27 9:16 ` Andreas Dilger
2011-07-28 16:56 ` Darrick J. Wong
[not found] ` <CAOQ4uxiOpwX2-Nfh9wJ7wSmAnbj9bh1+d9C95-N5D-8saRr6ww@mail.gmail.com>
2011-07-28 18:57 ` Darrick J. Wong
2011-07-29 9:55 ` Andreas Dilger
2011-07-28 22:07 ` Joel Becker
2011-07-29 9:48 ` Andreas Dilger [this message]
2011-07-29 13:19 ` Joel Becker
2011-07-30 7:25 ` Coly Li
2011-07-31 7:08 ` Joel Becker
2011-07-31 23:52 ` Coly Li
2011-08-01 4:57 ` Joel Becker
2011-08-01 5:04 ` Joel Becker
2011-08-01 7:16 ` Coly Li
2011-04-20 17:40 ` Andi Kleen
2011-04-20 22:54 ` Darrick J. Wong
2011-04-21 0:25 ` Andreas Dilger
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=0E795C1D-AD1E-4CC4-9426-2B58D98B14DC@dilger.ca \
--to=adilger.kernel@dilger.ca \
--cc=aedilger@gmail.com \
--cc=cmm@us.ibm.com \
--cc=djwong@us.ibm.com \
--cc=jlbec@evilplan.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--subject='Re: [PATCH 0/2] Add inode checksum support to ext4' \
/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
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).