On Fri, 2018-11-02 at 18:07 -0400, Matt Benjamin wrote: > It sounds like a pretty good one, that goes to the heart of what a > specification is > While admittedly it is (still) Dia de los Muertos today, I would think that someone who resurrected a part of the NFSv3 spec that has been unused for the full 23 years of its existence might have some explanation for why they did so? IOW: not being of a particularly religious persuasion, I usually want to understand why features are needed rather than having blind faith in the person who wrote the spec. > Matt > > On Fri, Nov 2, 2018 at 4:26 PM, Trond Myklebust < > trondmy@xxxxxxxxxxxxxxx> wrote: > > On Fri, 2018-11-02 at 21:24 +0530, Malahal Naineni wrote: > > > Ben, NFSv3 RFC1813.txt states: "If two file handles from the same > > > server are equal, they must refer to the same file, but if > > > they are > > > not equal, no conclusions can be drawn." Ganesha does return same > > > fileid here (inode). > > > > > > In NFSv4, they have introduced "unique_handles" attribute. I > > > don't > > > see > > > Linux NFS client using this at all though. > > > > Why does your server need to have multiple filehandles refer to the > > same file, and why do you expect clients to support this? > > > > Yes, the spec allows it, but that's not a sufficient reason. > > > > > Regards, Malahal. > > > On Fri, Nov 2, 2018 at 4:35 PM Benjamin Coddington < > > > bcodding@xxxxxxxxxx> wrote: > > > > On 2 Nov 2018, at 1:26, Malahal Naineni wrote: > > > > > > > > > Hi All, we are using NFS-Ganesha with Linux NFS clients. The > > > > > client's > > > > > shell reports the following. Based on lsof, the directory is > > > > > marked > > > > > deleted. "cd to ROOT and cd to the same home directory fixes > > > > > the > > > > > issue. The client behaves as though the directory is deleted > > > > > and > > > > > recreated! Our NFS-Ganesha server implementation uses > > > > > multiple > > > > > file > > > > > handles that point to the same object. NFS spec says this > > > > > should > > > > > be > > > > > fine, but Linux NFS seems to be broken in this regard. > > > > > tcpdump > > > > > does > > > > > indicate file handle change (note that all file handles are > > > > > permanent, > > > > > meaning they are valid at the server any time) around this > > > > > issue > > > > > time. > > > > > > > > > > "shell-init: error retrieving current directory: getcwd: > > > > > cannot > > > > > access > > > > > parent directories: No such file or directory" > > > > > sh 112544 malahal cwd DIR > > > > > 0,67 > > > > > 65536 45605209 /home/malahal (deleted) > > > > > (10.120.154.42:/nfs/malahal-export/) > > > > > > > > > > Function nfs_prime_dcache() seems to invalidate the dcache > > > > > entry > > > > > if > > > > > nfs_same_file() returns false. nfs_same_file() does seem to > > > > > return > > > > > false with the following change, if I read it correctly, if > > > > > there > > > > > is a > > > > > file handle change. Can this be the source of my issue? It > > > > > seems > > > > > that > > > > > the client should do this only if the file handle is NOT > > > > > valid > > > > > (e.g. > > > > > if it gets ESTALE), right? > > > > > > > > > > The following commit seems to assume that the objects are > > > > > different if > > > > > they have different file handles! > > > > > commit 7dc72d5f7a0ec97a53e126c46e2cbd2560757955 > > > > > Author: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > > > > > Date: Thu Sep 22 13:38:52 2016 -0400 > > > > > > > > > > NFS: Fix inode corruption in nfs_prime_dcache() > > > > > > > > My understanding is that for NFSv3 we have to assume that > > > > distinct > > > > filehandles are distinct objects, but maybe I'm wrong about > > > > this. > > > > > > > > For NFSv4.x, we can follow the guidance in RFCs 5661 or 7530 > > > > section 10.3.4 > > > > to determine if the differing filehandles are the same object, > > > > specifically > > > > the fileid recommended attribute needs to be implemented. Is > > > > Ganesha > > > > returning the same fileid for both filehandles? > > > > > > > > Ben > > -- > > Trond Myklebust > > CTO, Hammerspace Inc > > 4300 El Camino Real, Suite 105 > > Los Altos, CA 94022 > > www.hammer.space > > > > > > -- Trond Myklebust CTO, Hammerspace Inc 4300 El Camino Real, Suite 105 Los Altos, CA 94022 www.hammer.space
