From: Eric Sandeen <sandeen@sandeen.net>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@osdl.org
Subject: Re: [PATCH 1/3] new_inode_autonum: add per-sb lastino counter and add new_inode_autonum function that guarantees i_ino uniqueness
Date: Thu, 09 Nov 2006 11:12:50 -0600 [thread overview]
Message-ID: <45536192.1050501@sandeen.net> (raw)
In-Reply-To: <1163085879.21469.45.camel@dantu.rdu.redhat.com>
Jeff Layton wrote:
> - add a new per superblock s_nextino counter and change iunique to use it
> instead of its global inode counter
> - make the size of the counter conditional on CONFIG_COMPAT. This is to try
> prevent userspace EOVERFLOWs when 32-bit programs not compiled with large
> offsets are run on 64-bit kernels
> - add new_inode_autonum which guarantees that i_ino is assigned a unique val
> on the filesystem.
> - Change new_inode to assign i_ino to 0 to catch filesystems that use it and
> don't reset it to a unique value.
I like the general approach. A few tidbits...
- the comment for __new_inode isn't accurate, there is no @autonum
parameter added.
- I'm not sure what the point of wrapping __new_inode() in new_inode()
is. Why not just remove the i_ino setting from new_inode, (or
initialize it to 0*), and let new_inode_autonum() call new_inode();
iunique() ? Less indirection IMHO....
- *does setting the new i_ino to 0 really help catch anything? And if
it does, perhaps just setting it in alloc_inode() with all the other
field initializations would be more consistent.
- the comment for the s_nextino field is a bit misleading, it is
actually not used in new_inode(), only in iunique().
-Eric
next prev parent reply other threads:[~2006-11-09 17:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-09 15:24 [PATCH 1/3] new_inode_autonum: add per-sb lastino counter and add new_inode_autonum function that guarantees i_ino uniqueness Jeff Layton
2006-11-09 17:12 ` Eric Sandeen [this message]
2006-11-09 17:33 ` Christoph Hellwig
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=45536192.1050501@sandeen.net \
--to=sandeen@sandeen.net \
--cc=akpm@osdl.org \
--cc=jlayton@redhat.com \
--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.