From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhZj8-0007Te-Ul for qemu-devel@nongnu.org; Mon, 13 Apr 2015 04:28:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YhZj6-0000zq-7y for qemu-devel@nongnu.org; Mon, 13 Apr 2015 04:28:18 -0400 Received: from oxalide-out.extra.cea.fr ([132.168.224.8]:58021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhZj5-0000xy-Sy for qemu-devel@nongnu.org; Mon, 13 Apr 2015 04:28:16 -0400 Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t3D8S9WT004557 for ; Mon, 13 Apr 2015 10:28:09 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 42FC820B87F for ; Mon, 13 Apr 2015 10:29:20 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3706C20B87B for ; Mon, 13 Apr 2015 10:29:20 +0200 (CEST) Received: from zia.cdc.esteban.ctsi (out.dam.intra.cea.fr [132.165.76.10]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with SMTP id t3D8S8El004713 for ; Mon, 13 Apr 2015 10:28:08 +0200 Date: Mon, 13 Apr 2015 10:27:53 +0200 From: Dominique Martinet Message-ID: <20150413082753.GA15891@u-blusson> References: <20140702135258.23882.15100.malonedeb@soybean.canonical.com> <20150410123059.26540.1036.malone@gac.canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [V9fs-developer] [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Van Hensbergen Cc: Linux FS Devel , Bug 1336794 <1336794@bugs.launchpad.net>, qemu-devel , V9FS Developers Hi, for what it's worth, the sample code given works with nfs-ganesha server, so I'm not sure what's not working here. Here's the server traces: TATTACH: tag=1 fid=0 afid=-1 uname='nobody' aname='/export' n_uname=-1 RATTACH: tag=1 fid=0 qid=(type=128,version=0,path=1) TGETATTR: tag=1 fid=0 request_mask=0x7ff RGETATTR: tag=1 valid=0x7ff qid=(type=128,version=0,path=1) mode=040755 uid=0 gid=0 nlink=3 rdev=192 size=4096 blksize=4096 blocks=8 atime=(1428909387,0) mtime=(1428909389,0) ctime=(1428909389,0) btime=(0,0) gen=0, data_version=0 TATTACH: tag=1 fid=1 afid=-1 uname='' aname='/export' n_uname=0 RATTACH: tag=1 fid=1 qid=(type=128,version=0,path=1) TGETATTR: tag=1 fid=1 request_mask=0x3fff RGETATTR: tag=1 valid=0x7ff qid=(type=128,version=0,path=1) mode=040755 uid=0 gid=0 nlink=3 rdev=192 size=4096 blksize=4096 blocks=8 atime=(1428909387,0) mtime=(1428909389,0) ctime=(1428909389,0) btime=(0,0) gen=0, data_version=0 TWALK: tag=1 fid=1 newfid=2 nwname=1 (component 1/1 :test.txt) RERROR(_9P_TWALK) tag=1 err=(2|No such file or directory) TWALK: tag=1 fid=1 newfid=2 nwname=0 RWALK: tag=1 fid=1 newfid=2 nwqid=0 fileid=1 pentry=0x8278c0 refcount=4 TLCREATE: tag=1 fid=2 name=test.txt flags=0100102 mode=0100644 gid=0 RLCREATE: tag=1 fid=2 name=test.txt qid=(type=0,version=0,path=144115205255725065) iounit=0 pentry=0x7fffc0000d00 TWALK: tag=1 fid=1 newfid=3 nwname=1 (component 1/1 :test.txt) RWALK: tag=1 fid=1 newfid=3 nwqid=1 fileid=144115205255725065 pentry=0x7fffc0000d00 refcount=3 TGETATTR: tag=1 fid=3 request_mask=0x17ff RGETATTR: tag=1 valid=0x7ff qid=(type=0,version=0,path=144115205255725065) mode=0100644 uid=0 gid=0 nlink=1 rdev=192 size=0 blksize=4096 blocks=0 atime=(1428909674,0) mtime=(1428909674,0) ctime=(1428909674,0) btime=(0,0) gen=0, data_version=0 TWRITE: tag=1 fid=2 offset=0 count=6 RWRITE: tag=1 fid=2 offset=0 input count=6 output count=6 TUNLINKAT: tag=1 dfid=1 name=test.txt TUNLINKAT: tag=1 dfid=1 name=test.txt TGETATTR: tag=1 fid=3 request_mask=0x3fff RGETATTR: tag=1 valid=0x7ff qid=(type=0,version=0,path=144115205255725065) mode=0100644 uid=0 gid=0 nlink=0 rdev=192 size=6 blksize=4096 blocks=0 atime=(1428909674,0) mtime=(1428909674,0) ctime=(1428909674,0) btime=(0,0) gen=0, data_version=0 TCLUNK: tag=1 fid=2 RCLUNK: tag=1 fid=2 TCLUNK: tag=1 fid=3 RCLUNK: tag=1 fid=3 (if you're not familiar with 9P, ATTACH = mount, WALK = create a new 'fid' either clone of current file (nwname = 0) or lookup, CLUNK ~= close. Rest is obvious enough) There's no lookup between the unlink and the getattr, so what I think is missing is that both qemu and diod do not understand that fids 2 and 3 refer to the same open file ? It's a bit of a weird behavior that the client will open a new fid through lookup walk for a first stat, but I'm mounting with cache=none here so you should be having the same. -- Dominique