On Fri, Nov 02 2018, Marc Eshel wrote: > One reason to have different FHs for the same file is that a file can be > linked from multiple directories. This has some based when considering filehandles for non-directories. However the original problem was with filehandles for 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. > ....and directories have a ".." link, obviating the need to store parent information in the filehandle. NeilBrown > 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 >> >>
Attachment:
signature.asc
Description: PGP signature
