From: Jeff Layton <jlayton@redhat.com>
To: Bodo Eggert <7eggert@gmx.de>
Cc: akpm@osdl.org, dev@sw.ru, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, torvalds@osdl.org
Subject: Re: [PATCH] pipefs unique inode numbers
Date: Tue, 30 Jan 2007 20:37:20 -0500 [thread overview]
Message-ID: <45BFF2D0.4050808@redhat.com> (raw)
In-Reply-To: <45BFEE85.30203@redhat.com>
Jeff Layton wrote:
> Bodo Eggert wrote:
> > change pipefs to use a unique inode number equal to the memory
> > address unless it would be truncated.
> >
> > Signed-Off-By: Bodo Eggert <7eggert@gmx.de>
> > ---
> > Tested on i386.
> >
> > --- 2.6.19/fs/pipe.c.ori 2007-01-30 22:02:46.000000000 +0100
> > +++ 2.6.19/fs/pipe.c 2007-01-30 23:22:27.000000000 +0100
> > @@ -864,6 +864,10 @@ static struct inode * get_pipe_inode(voi
> > inode->i_uid = current->fsuid;
> > inode->i_gid = current->fsgid;
> > inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
> > + /* The address of *inode is unique, so we'll get an unique inode
> number.
> > + * Off cause this will not work for 32 bit inodes on 64 bit
> systems. */
> > + if (sizeof(inode->i_ino) >= sizeof(struct inode*))
> > + inode->i_ino = (unsigned int) inode;
> >
> > return inode;
> >
>
> Also, that patch would break many 32-bit programs not compiled with large
> offsets when run in compatibility mode on a 64-bit kernel. If they were to
> do a stat on this inode, it would likely generate an EOVERFLOW error since
> the pointer address would probably not fit in a 32 bit field.
>
> That problem was the whole impetus for this set of patches.
>
Actually, sorry...I misread the patch. It wouldn't have that problem. My
mistake.
Still though, I considered an approach somewhat similar to this early on.
I was thinking of taking a bit-shifted inode address and hashing it to
give a unique value. If you do the math, you can discard the lower 9 bits
of the pointer, so you end up being able to use the lower 41 bits of the
pointer. So a scheme like that could work if you could guarantee that
all inode addresses wouldn't be > 2^41 apart.
The problem is, you can't guarantee that, especially in a NUMA situation.
See the thread entitled:
[RFC][PATCH] ensure i_ino uniqueness in filesystems without
permanent inode numbers (via pointer conversion)
in linux-fsdevel, ~Nov 17th for more info.
-- Jeff
prev parent reply other threads:[~2007-01-31 1:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-30 22:40 [PATCH] pipefs unique inode numbers Bodo Eggert
2007-01-30 22:55 ` Linus Torvalds
2007-01-31 0:12 ` Jeff Layton
2007-01-31 1:19 ` Jeff Layton
2007-01-31 1:28 ` Linus Torvalds
2007-01-31 2:02 ` Jeff Layton
2007-01-31 9:19 ` Kirill Korotaev
2007-01-31 1:37 ` Jeff Layton [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=45BFF2D0.4050808@redhat.com \
--to=jlayton@redhat.com \
--cc=7eggert@gmx.de \
--cc=akpm@osdl.org \
--cc=dev@sw.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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.