From: Mingming Cao <cmm@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/9] support >32 bit ext4 filesystem block type in kernel
Date: Thu, 10 Aug 2006 10:19:45 -0700 [thread overview]
Message-ID: <44DB6AB1.3010602@us.ibm.com> (raw)
In-Reply-To: <20060809234033.4681017b.akpm@osdl.org>
Andrew Morton wrote:
> On Wed, 09 Aug 2006 18:21:00 -0700
> Mingming Cao <cmm@us.ibm.com> wrote:
>
>
>>Redefine ext4 in-kernel filesystem block type (ext4_fsblk_t) from unsigned
>>long to sector_t, to allow kernel to handle >32 bit ext4 blocks.
>>
>
>
> I don't get it.
The intention is able to support 48bit ext4 on 64bit and 32bit arch
whenevern CONFIG_LBD is enabled (or when sector_t is actually 64 bit).
It just seems waste of memory to support 48bit in-kernel ext4 blks on 32
bit if CONFIG_LBD is disabled, since we won't support large device anyway.
ext3_fsblk_t was a unsigned long type before, which is always 32bit on
32bit arch. Thus we convert the ext3_fsblk_t to sector_t and depend on
CONFIG_LBD to decide whether we need 48bit in-kernel variables.(on-disk
block numbers are always 48 bit).
>
> Randomly-chosen snippet:
>
>
>>@@ -274,7 +274,8 @@ static int find_group_orlov(struct super
>> freei = percpu_counter_read_positive(&sbi->s_freeinodes_counter);
>> avefreei = freei / ngroups;
>> freeb = percpu_counter_read_positive(&sbi->s_freeblocks_counter);
>>- avefreeb = freeb / ngroups;
>>+ avefreeb = freeb;
>>+ sector_div(avefreeb, ngroups);
>> ndirs = percpu_counter_read_positive(&sbi->s_dirs_counter);
>>
>> if ((parent == sb->s_root->d_inode) ||
>
>
> Here, `avefreeb' is still a 32-bit type. Why feed it into sector_div()?
>
avefreeb is ext3_fsblk_t type(sector_t type), which is 64bit on 64bit
arch and 64bit on 32bit arch if CONFIG_LBD is enabled.
>
>>@@ -303,13 +304,15 @@ static int find_group_orlov(struct super
>> goto fallback;
>> }
>>
>>- blocks_per_dir = (le32_to_cpu(es->s_blocks_count) - freeb) / ndirs;
>>+ blocks_per_dir = le32_to_cpu(es->s_blocks_count) - freeb;
>>+ sector_div(blocks_per_dir, ndirs);
>
>
> And here le32_to_cpu() is very much a 32-bit type. Why sector_div()?
ah, sorry about the confusing, s_blocks_count (the number of blocks on
this fs, on-disk) should be always 48bit value, and should not use
le32_to_cpu() to read-in. That is being fixed in [patch 9/9] 64bit
metadata support, where we convert 32 bit s_blocks_count to sector_t,
and also use mixro EXT4_BLOCKS_COUN(es) to read in the blocks count:
@@ -304,7 +306,7 @@ static int find_group_orlov(struct super
goto fallback;
}
- blocks_per_dir = le32_to_cpu(es->s_blocks_count) - freeb;
+ blocks_per_dir = EXT4_BLOCKS_COUNT(es) - freeb;
This patch[3/9] is just fix the in-kernel blocks type...We trying to do
this incrementally: first, support in-kernel blocks type >32bit, then
change the on-disk blocks type to >32bit.
>
> And I agree with me: we want to get all the sector_t's out of this
> filesystem. unsigned long long, do_div()?
>
Thanks,Mingming
prev parent reply other threads:[~2006-08-10 17:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-10 1:21 [PATCH 3/9] support >32 bit ext4 filesystem block type in kernel Mingming Cao
2006-08-10 1:21 ` Mingming Cao
2006-08-10 6:40 ` Andrew Morton
2006-08-10 6:40 ` Andrew Morton
2006-08-10 17:19 ` Mingming Cao [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=44DB6AB1.3010602@us.ibm.com \
--to=cmm@us.ibm.com \
--cc=akpm@osdl.org \
--cc=ext2-devel@lists.sourceforge.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.