On Thu, Apr 26, 2012 at 12:06 PM, Myklebust, Trond <Trond.Myklebust@xxxxxxxxxx> wrote: > On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote: >> On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond >> <Trond.Myklebust@xxxxxxxxxx> wrote: >> > 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@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: >> >> >> > Steve French <smfrench@xxxxxxxxx> 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. >> >> the question is whether the application (backup) would need to know >> that the inode numbers are bogus and from my conversations with >> guys writing backup software it seems that such data is useful to them. > > You are still not explaining why they need to know the values at all? If > the values are bogus, then don't return them, and don't set the flag > that says they are being returned. I don't know, but assumed it was because it was an easy way to index them since the inode numbers even if they "change" on remount, are still unique. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
