From: "Theodore Ts'o" <tytso@mit.edu>
To: "Henning P. Schmiedehausen" <hps@intermeta.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] Add extended attributes to ext2/3
Date: Wed, 16 Oct 2002 12:16:20 -0400 [thread overview]
Message-ID: <20021016161620.GC8210@think.thunk.org> (raw)
In-Reply-To: <aojc1q$l37$1@forge.intermeta.de>
On Wed, Oct 16, 2002 at 09:38:02AM +0000, Henning P. Schmiedehausen wrote:
> tytso@mit.edu writes:
>
> >+ int ea_blocks = EXT3_I(inode)->i_file_acl ?
> >+ (inode->i_sb->s_blocksize >> 9) : 0;
>
> Sometimes I wonder if we shouldn't have the block size (512) and the
> bit shift (9) as defines somewhere and gradually shift away from hard
> coded values...
>
> If we ever decide to change the block size of ext2/ext3, we're in for
> a "looking for nines"... :-)
We already have different block sizes for ext2/3; we support 1k, 2k,
and 4k block sizes. The bit shift is only there because the
superblock stores the blocksize shifted by 9 for "historical reasons".
(i.e., I probably wouldn't have bothered with it, but Remy Card did it
that way, and it doesn't hurt, so make everyone suffer with an
incompatible format change?)
We do have one place where the 512 byte sector count is used, and
that's in inode->i_blocks, which is stored as 512 byte sectors,
regardless of the blocksize. *That's* due to st_blocks in the stat
structure being returned in 512 byte sectors, and for no other good
reason. As a result of this particular bit of history, ext2
filesystems are limited to 2TB, even when using a 4k blocksize.
Without this bit of "design history", we'd be able to support 16TB
filesystems with 2.6's CONFIG_LBD support, without needing to going to
a 64-bit block numbers. Making this change is actually pretty easy,
and I may try to get that change to Linus before 2.6 closes.
- Ted
next prev parent reply other threads:[~2002-10-16 16:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-15 22:20 [PATCH 2/3] Add extended attributes to ext2/3 tytso
2002-10-16 9:38 ` Henning P. Schmiedehausen
2002-10-16 16:16 ` Theodore Ts'o [this message]
2002-10-16 17:05 ` Andreas Dilger
2002-10-16 19:30 ` Theodore Ts'o
2002-10-19 18:36 ` Jan Kara
2002-10-16 17:50 ` Lorenzo Allegrucci
2002-10-16 18:32 ` Andreas Dilger
[not found] ` <200210161336.27935.agruen@suse.de>
[not found] ` <3DAD8D5E.31E177BA@digeo.com>
2002-10-16 20:32 ` [PATCH] linux-2.5.43-mm1: Further xattr/acl cleanups Andreas Gruenbacher
2002-10-16 21:15 ` Andreas Gruenbacher
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=20021016161620.GC8210@think.thunk.org \
--to=tytso@mit.edu \
--cc=hps@intermeta.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox