From: Christoph Hellwig <hch@lst.de>
To: "J. R. Okajima" <hooanon05g@gmail.com>
Cc: dchinner@redhat.com, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] vfs: get_next_ino(), never inum=0
Date: Tue, 29 Apr 2014 19:53:42 +0200 [thread overview]
Message-ID: <20140429175342.GA26109@lst.de> (raw)
In-Reply-To: <18587.1398793322@jrobl>
On Wed, Apr 30, 2014 at 02:42:02AM +0900, J. R. Okajima wrote:
>
> > There is another unpleasant effect when get_next_ino() wraps
> > around. When there is a file whose inum=100 on tmpfs, a new file may get
> > inum=100. I am not sure what will happen when the duplicated inums exist
> > on tmpfs. ...
>
> Undeterministic behaviour when exporting via NFS?
If you care about really unique inode numbers you shouldn't use get_next_ino
but something like an idr allocator. The default i_ino assigned in
new_inode() from which get_next_ino was factored out was mostly intended
for small synthetic filesystems with few enough inodes that it wouldn't
wrap around.
And yes, file handle based lookups are screwed by duplicated inode numbers,
as are tools trying to do file level de-duplication, mostly in the backup or
achival space.
next prev parent reply other threads:[~2014-04-29 17:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 15:45 [PATCH] vfs: get_next_ino(), never inum=0 hooanon05g
2014-04-29 17:42 ` J. R. Okajima
2014-04-29 17:53 ` Christoph Hellwig [this message]
2014-04-30 4:08 ` J. R. Okajima
2014-04-30 22:56 ` Andreas Dilger
2014-05-10 3:18 ` J. R. Okajima
2014-08-18 18:21 ` [PATCH v2] " Carlos Maiolino
2014-08-19 0:58 ` J. R. Okajima
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=20140429175342.GA26109@lst.de \
--to=hch@lst.de \
--cc=dchinner@redhat.com \
--cc=hooanon05g@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).