On Fri, 14 May 2010 14:56:08 -0500, Steve French <smfrench@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
