linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
To: Steve French <smfrench@gmail.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -V7 4/9] vfs: Add open by file handle support
Date: Sun, 16 May 2010 12:54:43 +0530	[thread overview]
Message-ID: <87eihccnr8.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <AANLkTim6lwu7Vt72PYSQ7r2swXkEIIYXYeo9z22PKJcz@mail.gmail.com>

On Fri, 14 May 2010 14:56:08 -0500, Steve French <smfrench@gmail.com> wrote:
> I think open by handle will turn out to be useful, but in discussing
> various "duplicate inode number" checks that we are having to add to
> cifs, it reminded me that we probably need a "generation number" or
> some equivalent (birth time is probably good enough as well) to be
> able to tell the case where a file is deleted and new file is created
> reusing the same inode number (eventually Samba needs to return this
> to posix clients if inode numbers are to be useful - and I don't know
> how to tell Samba how to get birth time or generation numbers out of
> stat in userspace)
>

The file handle already have generation number encoded. The patches
describe file handle as 

struct file_handle {
	int handle_size;
	int handle_type;
	/* File system identifier */
	struct uuid fsid;
	/* file identifier */
	unsigned char f_handle[0];
};

The file identifier which is stored in f_handle and of size handle_size
is obtained via exportfs_encode_fh (default to export_encode_fh). File 
system can hook a super_block->export_operations there. The default one
export_encode_fh actually use inode number and generation number as a
part of handle. So we shoud be having different file identifier on the
client side for these files which happened to have duplicate inode
number due to inode number reuse. But being able to determine generation
number in the userspace would be nice.


-aneesh

  reply	other threads:[~2010-05-16  7:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-14 19:56 [PATCH -V7 4/9] vfs: Add open by file handle support Steve French
2010-05-16  7:24 ` Aneesh Kumar K. V [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-05-12 15:50 [PATCH -V7 0/8] Generic name to handle and open by handle syscalls Aneesh Kumar K.V
2010-05-12 15:50 ` [PATCH -V7 4/9] vfs: Add open by file handle support Aneesh Kumar K.V
2010-05-12 23:44   ` Neil Brown
2010-05-13  6:09     ` Dave Chinner
2010-05-13  6:37       ` Aneesh Kumar K. V
2010-05-14 10:41         ` Dave Chinner

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=87eihccnr8.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smfrench@gmail.com \
    /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).