Re: [PATCH 1/2] handling 64bit values for st_ino]

[Steve French]

Al Viro wrote:
>*However*, there's an area where we have a problem: stat64() and
>getdents64() _could_ return 64bit st_ino/d_ino just fine, if not for having
>too narrow field in kstat and argument of filldir_t. As it is, we have
>->getattr() fill struct kstat and the syscall proper copy the contents of
>that struct kstat into user buffer.  stat64 has 64bit st_ino; kstat
>field used to set it is only unsigned long.
> Note that it's not just a theory - there are filesystems that
> want 64bit values in st_ino (AFS, for one).  There are consumers of
> these values ready to deal with 64bit values - aside of aforementioned
> syscalls, e.g. NFSv3 and NFSv4 are happy with those

The SMB/CIFS networking protocol also returns 64 bit "UniqueIDs" which 
are similar to inode numbers and thus CIFS client (and presumably Samba
server) would benefit slightly .   This is not just the case for use of 
the core CIFS protocol which Windows and various NAS appliances support but 
also for mounts to Samba, HP etc. and servers which support the SNIA CIFS 
Unix Extensions  (struct FILE_UMIX_BASIC_INFO defines the inode number
returned over the wire as 64 bit).

The only problem with cifs using such numbers (instead of locally generated
but unique transient inode numbers) is that servers are allowed
to export above the top of a local mount - therefore it is hard, although
I believe possible, for the client to detect when it is crossing between 
two different partitions on the server as it traverses a directory tree
and thus possible that one export could report two inodes with the same
inode number, although different devices, if the server administrator chose
to configure their exports (shares) that way).  Support for DFS (transparent
referrals from one directory to one or more UNC names) on more clients
such as cifs would make it easier for server administrators because there
would be less need to export shares that high up in the server's directory tree.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/