Re: [PATCH 0/6] Extended file stat system call

["Myklebust, Trond" <Trond Myklebust netapp com>]

On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:
> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
> <Trond Myklebust netapp com> wrote:
> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells redhat com> wrote:
> >> > Steve French <smfrench gmail com> wrote:
> >> >
> >> >> Would it be better to make the stable vs volatile inode number an attribute
> >> >> of the volume  or something returned by the proposed xstat?
> >> >
> >> > I'm not sure what you mean by a stable vs a volatile inode number.
> >>
> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent
> >> unique identifier, but in the case of CIFS some old servers don't support the
> >> calls which return inode numbers (or don't return them for all file system
> >> types, Windows FAT?) so in these cases cifs has to create inode
> >> numbers on the fly
> >> on the client.   inode numbers created on the client are not "stable" they
> >> can change on unmount/remount (which can cause problems for backup
> >> applications).
> >>
> >> Similarly NFSv4 does not require that servers always return stable inode numbers
> >> (that will never change) and introduced a concept of "volatile file handle."
> >> We have run into this in two cases (there are probably more) -
> >> Specialized NFS servers
> >> for HPC which deal with lots of transient inodes, and second those for servers
> >> which base there inode number on path (Windows NFS?).  See
> >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html
> >> or the NFSv4 RFC.
> >>
> >> Basically the question is whether it is worth reporting a flag on the
> >> call which returns
> >> the inode number to indicate that the inode number is "stable" (would not change
> >> on reboot or reconnection) or "volatile."    Since the majority of NFS
> >> and SMB2 servers
> >> can return stable inode numbers, I don't feel strongly about the need
> >> for an indicator
> >> of "stable" vs. "volatile" but I mention it because backup and
> >> migration applications
> >> mention this (if inode numbers are volatile, they may have to check
> >> for hardlinks differently
> >> for example)
> >
> > I don't understand. If the filesystem doesn't support real inode
> > numbers, then why report them at all? What use would an application have
> > for an inode number that can't be used to identify hard linked files?
> 
> Well ... you have to have an inode number on the Linux client side even if
> the server doesn't report them (or has a bug and reports duplicates).
> If you can't tell hardlinked files apart fix the server (but in the
> cases where the file systems has this problem the server doesn't usually
> support hardlinks either).
> 
> If the server's file system internal structures don't support real inode
> numbers (such as FAT or a ramdisk) then it either has to make them
> up based on something like path name or some other attribute of the
> file on disk.
> 
> Servers like NetApp is where this gets interesting - for cifs e.g. level 1009
> query file info is used to query_file_internal_info (the inode number) but
> what if the server can not report inode numbers (due to a bug) in
> all cases.

Right, but none of this explains why we need to report these bogus inode
numbers to the application in the xstat() reply.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond Myklebust netapp com
www.netapp.com