From: Andreas Dilger <adilger@clusterfs.com>
To: Valerie Clement <valerie.clement@bull.net>
Cc: Theodore Tso <tytso@mit.edu>,
ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [RFC][PATCH 8/11][take 2] 48-bit extents in e2fsprogs
Date: Thu, 21 Jun 2007 15:17:32 -0600 [thread overview]
Message-ID: <20070621211732.GB5181@schatzie.adilger.int> (raw)
In-Reply-To: <467A99EB.7090600@bull.net>
On Jun 21, 2007 17:31 +0200, Valerie Clement wrote:
> +#define EXT4_EE_START(s, e) \
> + ((e)->ee_start + \
> + (((s)->s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT) && \
> + (EXT2_BLOCKS_COUNT(s) > ((unsigned) 1 << 31)) ? \
> + (__u64)(e)->ee_start_hi << 32 : 0))
Isn't the INCOMPAT_64BIT check already part of EXT2_BLOCKS_COUNT()?
It should be impossible to have the "> (1 << 31)" check be true for
a non-64-bit filesystem in that case. Also, why check for > (1 << 31)
instead of >= (1 << 32)?
> +#define EXT4_EE_START_SET(s,e,blk) \
> + do { \
> + (e)->ee_start = (blk); \
> + if ((s)->s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT \
> + && EXT2_BLOCKS_COUNT(s) > ((unsigned) 1 << 31)) \
> + (e)->ee_start_hi = (__u64)(blk) >> 32; \
Here you should always set ee_start_hi = 0, so there is no need for
a conditional here. It is only needed for the read because initial versions
of the extents code didn't clear ee_start_hi, so it deserves making a comment
to that effect above EXT4_EE_START() and EXT4_EI_LEAF(). One day we may
want to remove that hack and assume *_hi == 0 for all filesystems.
> +#define EXT4_EI_LEAF_SET(s,e,blk) \
> + do { \
> + (ix)->ei_leaf = (blk); \
> + if ((s)->s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT \
> + && EXT2_BLOCKS_COUNT(s) > ((unsigned) 1 << 31)) \
> + (ix)->ei_leaf_hi = (__u64)(blk) >> 32; \
> + } while(0)
Same as above.
> @@ -1604,6 +1604,10 @@ static int e2fsck_ext_block_verify(struc
> e2fsck_t ctx = p->ctx;
> struct problem_context *pctx = p->pctx;
> int i, problem = 0;
> + int flag_64bit;
> +
> + flag_64bit = p->ctx->fs->super->s_feature_incompat &
> + EXT4_FEATURE_INCOMPAT_64BIT;
Presumably we have verified INCOMPAT_64BIT is set for filesystems with
more than 2^32 blocks in the superblock and the device size?
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
prev parent reply other threads:[~2007-06-21 21:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-21 15:31 [RFC][PATCH 8/11][take 2] 48-bit extents in e2fsprogs Valerie Clement
2007-06-21 21:17 ` Andreas Dilger [this message]
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=20070621211732.GB5181@schatzie.adilger.int \
--to=adilger@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=valerie.clement@bull.net \
/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