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. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
