[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877ibl97jy.fsf@frosties.localdomain>
Date: Wed, 16 Jul 2008 17:23:45 +0200
From: Goswin von Brederlow <goswin-v-b@....de>
To: "Jose R. Santos" <jrs@...ibm.com>
Cc: Goswin von Brederlow <goswin-v-b@....de>,
"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup
"Jose R. Santos" <jrs@...ibm.com> writes:
> On Wed, 16 Jul 2008 15:52:01 +0200
> Goswin von Brederlow <goswin-v-b@....de> wrote:
>> My test device is exactly 32 TiB large and gives the following:
>>
>> root@...-13:~# LD_LIBRARY_PATH=/tmpa/ext4 /tmpa/ext4/mke2fs -T ext4dev
>> -j -m0 /dev/mapper/ext4
>> mke2fs 1.41.0 (10-Jul-2008)
>> mke2fs: inode_size (256) * inodes_count (0) too big for a
>> filesystem with 0 blocks, specify higher inode_ratio (-i)
>> or lower inode count (-N).
>
> hehe, I put a FIXME-64 around this since I knew it was going to be a
> problem. I just wasn't sure what was the right approach for fixing.
> You'll have to specify an inode count for now.
>
> The "filesystem with 0 blocks" surprise me though. Looks like I missed
> something somewhere.
/*
* Set the fs block count
*/
void ext2fs_blocks_count_set(struct ext2_super_block *super, blk64_t blk)
{
super->s_blocks_count = blk;
if (super->s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT)
super->s_blocks_count_hi = (__u64) blk >> 32;
}
EXT4_FEATURE_INCOMPAT_64BIT is not set so the upper bits just get
ignored.
MfG
Goswin
PS: Should functions that chop off upper bits like that make sure they
are 0?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists