You asked for a reason and I gave you one, the client shouldn't care for the reason since the FH is opaque to the client. It is the server decision what to encode in the FH. The client should just follow the spec. Marc. linux-nfs-owner@xxxxxxxxxxxxxxx wrote on 11/02/2018 08:27:10 PM: > From: Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> > To: "eshel@xxxxxxxxxx" <eshel@xxxxxxxxxx> > Cc: "bcodding@xxxxxxxxxx" <bcodding@xxxxxxxxxx>, > "mbenjami@xxxxxxxxxx" <mbenjami@xxxxxxxxxx>, "linux-nfs- > owner@xxxxxxxxxxxxxxx" <linux-nfs-owner@xxxxxxxxxxxxxxx>, "linux- > nfs@xxxxxxxxxxxxxxx" <linux-nfs@xxxxxxxxxxxxxxx>, > "malahal@xxxxxxxxx" <malahal@xxxxxxxxx> > Date: 11/02/2018 08:27 PM > Subject: Re: "(deleted)" directories > Sent by: linux-nfs-owner@xxxxxxxxxxxxxxx > > On Fri, 2018-11-02 at 18:38 -0800, Marc Eshel wrote: > > One reason to have different FHs for the same file is that a file can > > be > > linked from multiple directories. > > Adding the parent inode to the FH help finding the the name of the > > file by > > looking for the file inode in > > the parent directoy. > > > > No... We've been there and done that. Encoding parent directories in > the filehandle breaks rename, unlink, and makes it a pain to recover > state. > There is no way in hell we're going to commit to support that model. > > > Marc. > > > > linux-nfs-owner@xxxxxxxxxxxxxxx wrote on 11/02/2018 05:15:42 PM: > > > > > From: Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> > > > To: "mbenjami@xxxxxxxxxx" <mbenjami@xxxxxxxxxx> > > > Cc: "bcodding@xxxxxxxxxx" <bcodding@xxxxxxxxxx>, "malahal@xxxxxxxxx > > > " > > > <malahal@xxxxxxxxx>, "linux-nfs@xxxxxxxxxxxxxxx" > > <linux-nfs@xxxxxxxxxxxxxxx> > > > Date: 11/02/2018 05:15 PM > > > Subject: Re: "(deleted)" directories > > > Sent by: linux-nfs-owner@xxxxxxxxxxxxxxx > > > > > > 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 > > > > > > > > > > > -- > Trond Myklebust > CTO, Hammerspace Inc > 4300 El Camino Real, Suite 105 > Los Altos, CA 94022 > www.hammer.space > >
