From: Theodore Tso <tytso@valinux.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: tytso@valinux.com, linux-kernel@vger.kernel.org,
Andreas Dilger <adilger@turbolinux.com>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Ext2 development mailing list <ext2-devel@lists.sourceforge.net>
Subject: Re: [Ext2-devel] ext2 inode size (on-disk)
Date: Fri, 20 Apr 2001 02:35:28 -0400 [thread overview]
Message-ID: <20010420023528.D5417@think> (raw)
In-Reply-To: <20010419161003.E17837@snap.thunk.org> <Pine.GSO.4.21.0104192213060.19860-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0104192213060.19860-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Thu, Apr 19, 2001 at 10:23:39PM -0400
On Thu, Apr 19, 2001 at 10:23:39PM -0400, Alexander Viro wrote:
>
> I'm somewhat concerned about the following: last block of inode table
> fragment may have less inodes than the rest. Reason: number of inodes
> per group should be a multiple of 8 and with inodes bigger than 128
> bytes it may give such effect. Comments?
Yup, that's right. That shouldn't be too bad, though, since we
already calculate things by dividing by INODES_PER_BLOCK_GROUP. So
the fact that the last block of the inode table may have some unused
space shouldn't be a problem.
> I would really, really like to end up with accurate description of
> inode table layout somewhere in Documentation/filesystems. Heck, I
> volunteer to write it down and submit into the tree ;-)
The "design and implementation of ext2" paper has a pretty good
explanation of the inode table, but of course it assumed a convenient
inode size of 128, and didn't really go into the issues of what might
happen if the inode size were larger, or not a power of two.
So yeah, getting something which explains how things work now that
things have gotten a bit more complicated would be a good thing.
- Ted
prev parent reply other threads:[~2001-04-20 6:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20001202014045.F2272@parcelfarce.linux.theplanet.co.uk>
2001-04-19 11:55 ` ext2 inode size (on-disk) Alexander Viro
2001-04-19 17:41 ` Andreas Dilger
2001-04-19 18:02 ` Alexander Viro
2001-04-19 19:24 ` Andreas Dilger
2001-04-20 2:12 ` Alexander Viro
2001-04-19 20:10 ` [Ext2-devel] " tytso
2001-04-19 20:29 ` Jeff Garzik
2001-04-20 6:30 ` Theodore Tso
2001-04-20 2:23 ` Alexander Viro
2001-04-20 5:35 ` Andreas Dilger
2001-04-20 6:37 ` Theodore Tso
2001-04-20 6:35 ` Theodore Tso [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=20010420023528.D5417@think \
--to=tytso@valinux.com \
--cc=adilger@turbolinux.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@math.psu.edu \
/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.