From: "Theodore Ts'o" <tytso@mit.edu>
To: Takashi Sato <sho@bsd.tnes.nec.co.jp>
Cc: cmm@us.ibm.com, linux-kernel@vger.kernel.org,
ext2-devel@lists.sourceforge.net
Subject: Re: [Ext2-devel] [PATCH 1/2] ext2/3: Support 2^32-1 blocks(Kernel)
Date: Thu, 16 Mar 2006 08:53:41 -0500 [thread overview]
Message-ID: <20060316135341.GB24013@thunk.org> (raw)
In-Reply-To: <02bc01c648f2$bd35e830$4168010a@bsd.tnes.nec.co.jp>
On Thu, Mar 16, 2006 at 09:11:17PM +0900, Takashi Sato wrote:
> >You changed most of the affected variables from "int" to "unsigned int",
> >that seems allow block number to address 2^32. It probably a good thing
> >to consider change the variables to sector_t type, so when the time we
> >want to support for 64 bit block number, we don't have to re-do the
> >similar work again. Laurent did very similar work on this before.
>
> sector_t is 8bytes on normal configuration and there are many
> variables for blocks on ext2/3. I thought extending variables may
> influence on performance, so I didn't change.
It would be interesting to do a CPU overhead benchmark to see how much
of the overhead is actually measurable on an x86 system. If it's only
a small percent, it might be acceptable given that x86_64 machines are
going to be gradually taking over, and sector_t only exists if
CONFIG_LBD is enabled. So for smaller systems where LBD isn't
enabled, we won't see performance overhead since sector_t won't exist
and so the code is going to have to use a typedef for ext2_blk_t which
is either __u32 or sector_t as necessary.
> >- The superblock format currently stores the number of block groups as a
> >16-bit integer, and because (on a 4 KB blocksize filesystem) the maximum
> >number of blocks in a block group is 32,768 , a combination of these
> >constraints limits the maximum size of the filesystem to 8 TB
>
> Is it s_block_group_nr in ext3_super_block?
> mke2fs sets 65535 to the field if the number of block groups is greater
> than 65535. Current kernel ignores the field and re-calculate from
> other fields. findsuper command is the only user of it and it simply prints
> the value. So, it does not limit the maximum size of the filesystem to 8
> TB.
s_block_group_nr is *not* the number of block groups in the
filesystem. As Takashi-san properly pointed out, the kernel
calculates the number of block groups by dividing the number of blocks
by the blocks_per_group fields. s_block_group_nr is used to identify
the block group of a particular backup supeblock.
So for the backup superblock located at block group #3,
s_block_group_nr 3, and for the backup superblock located at block
group #5, s_block_group_nr 5, and so on. It is used only as a hint so
that prorams like findsuper and gpart can be more intelligent about
finding the start of filesystem, when trying to recover from a smashed
partition table.
- Ted
next prev parent reply other threads:[~2006-03-16 13:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-15 12:39 [PATCH 1/2] ext2/3: Support 2^32-1 blocks(Kernel) Takashi Sato
2006-03-15 12:56 ` [Ext2-devel] " Laurent Vivier
2006-03-16 2:19 ` Mingming Cao
2006-03-16 12:11 ` Takashi Sato
2006-03-16 13:53 ` Theodore Ts'o [this message]
2006-03-16 18:35 ` Andreas Dilger
2006-03-16 21:26 ` Theodore Ts'o
2006-03-16 22:59 ` Andreas Dilger
2006-03-18 17:07 ` Theodore Ts'o
2006-03-20 6:36 ` Andreas Dilger
2006-03-20 22:38 ` Stephen C. Tweedie
2006-03-20 23:48 ` Andreas Dilger
2006-03-21 17:05 ` Stephen C. Tweedie
2006-03-21 18:38 ` Theodore Ts'o
2006-03-21 19:47 ` Stephen C. Tweedie
2006-03-21 20:40 ` Andreas Dilger
2006-03-21 20:16 ` Alfred M. Szmidt
2006-03-21 23:05 ` Olivier Galibert
2006-03-21 23:35 ` Alfred M. Szmidt
2006-03-25 14:51 ` cascardo
2006-03-26 16:27 ` Andreas Dilger
2006-03-27 19:59 ` Stephen C. Tweedie
2006-03-27 20:36 ` Alfred M. Szmidt
2006-03-27 19:55 ` Stephen C. Tweedie
2006-03-27 20:05 ` Alfred M. Szmidt
2006-03-27 20:40 ` Stephen C. Tweedie
2006-03-28 0:14 ` cascardo
2006-03-21 20:26 ` Andreas Dilger
2006-03-21 4:03 ` Theodore Ts'o
2006-03-17 9:35 ` Laurent Vivier
2006-03-19 2:20 ` Theodore Ts'o
2006-03-20 10:11 ` Takashi Sato
2006-03-26 3:01 ` Theodore Ts'o
-- strict thread matches above, loose matches on Subject: below --
2006-03-26 22:15 Chuck Ebbert
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=20060316135341.GB24013@thunk.org \
--to=tytso@mit.edu \
--cc=cmm@us.ibm.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sho@bsd.tnes.nec.co.jp \
/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.