From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Van Hensbergen Subject: Re: [V9fs-developer] [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files Date: Mon, 13 Apr 2015 16:05:28 +0000 Message-ID: References: <20140702135258.23882.15100.malonedeb@soybean.canonical.com> <20150410123059.26540.1036.malone@gac.canonical.com> <20150413082753.GA15891@u-blusson> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113cd87669ad0905139d4854 Cc: Linux FS Devel , Bug 1336794 <1336794@bugs.launchpad.net>, qemu-devel , V9FS Developers To: Dominique Martinet Return-path: In-Reply-To: <20150413082753.GA15891@u-blusson> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: linux-fsdevel.vger.kernel.org --001a113cd87669ad0905139d4854 Content-Type: text/plain; charset=UTF-8 Well, technically fid 3 isn't 'open', only fid 2 is open - at least according to the protocol. fid 3 and fid 2 are both clones of fid 1. However, thanks for the alternative workaround. If you get a chance, can you check that my change to the client to partially fix this for the other servers doesn't break nfs-ganesha: https://github.com/ericvh/linux/commit/fddc7721d6d19e4e6be4905f37ade5b0521f4ed5 On Mon, Apr 13, 2015 at 3:27 AM, Dominique Martinet < dominique.martinet@cea.fr> wrote: > 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 > --001a113cd87669ad0905139d4854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, technically fid 3 isn't 'open', only fid= 2 is open - at least according to the protocol. =C2=A0fid 3 and fid 2 are = both clones of fid 1. =C2=A0 However, thanks for the alternative workaround= .=C2=A0 If you get a chance, can you check that my change to the client to = partially fix this for the other servers doesn't break nfs-ganesha:=C2=A0 =C2=A0https://github.com/ericvh/linux/commit/fddc7= 721d6d19e4e6be4905f37ade5b0521f4ed5

<= div class=3D"gmail_quote">On Mon, Apr 13, 2015 at 3:27 AM, Dominique Martin= et <dominique.martinet@cea.fr> wrote:
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=3D1 fid=3D0 afid=3D-1 uname=3D'nobody' aname=3D'/e= xport' n_uname=3D-1
RATTACH: tag=3D1 fid=3D0 qid=3D(type=3D128,version=3D0,path=3D1)
TGETATTR: tag=3D1 fid=3D0 request_mask=3D0x7ff
RGETATTR: tag=3D1 valid=3D0x7ff qid=3D(type=3D128,version=3D0,path=3D1) mod= e=3D040755 uid=3D0 gid=3D0 nlink=3D3 rdev=3D192 size=3D4096 blksize=3D4096 = blocks=3D8 atime=3D(1428909387,0) mtime=3D(1428909389,0) ctime=3D(142890938= 9,0) btime=3D(0,0) gen=3D0, data_version=3D0
TATTACH: tag=3D1 fid=3D1 afid=3D-1 uname=3D'' aname=3D'/export&= #39; n_uname=3D0
RATTACH: tag=3D1 fid=3D1 qid=3D(type=3D128,version=3D0,path=3D1)
TGETATTR: tag=3D1 fid=3D1 request_mask=3D0x3fff
RGETATTR: tag=3D1 valid=3D0x7ff qid=3D(type=3D128,version=3D0,path=3D1) mod= e=3D040755 uid=3D0 gid=3D0 nlink=3D3 rdev=3D192 size=3D4096 blksize=3D4096 = blocks=3D8 atime=3D(1428909387,0) mtime=3D(1428909389,0) ctime=3D(142890938= 9,0) btime=3D(0,0) gen=3D0, data_version=3D0
TWALK: tag=3D1 fid=3D1 newfid=3D2 nwname=3D1 (component 1/1 :test.txt)
RERROR(_9P_TWALK) tag=3D1 err=3D(2|No such file or directory)
TWALK: tag=3D1 fid=3D1 newfid=3D2 nwname=3D0
RWALK: tag=3D1 fid=3D1 newfid=3D2 nwqid=3D0 fileid=3D1 pentry=3D0x8278c0 re= fcount=3D4
TLCREATE: tag=3D1 fid=3D2 name=3Dtest.txt flags=3D0100102 mode=3D0100644 gi= d=3D0
RLCREATE: tag=3D1 fid=3D2 name=3Dtest.txt qid=3D(type=3D0,version=3D0,path= =3D144115205255725065) iounit=3D0 pentry=3D0x7fffc0000d00
TWALK: tag=3D1 fid=3D1 newfid=3D3 nwname=3D1 (component 1/1 :test.txt)
RWALK: tag=3D1 fid=3D1 newfid=3D3 nwqid=3D1 fileid=3D144115205255725065 pen= try=3D0x7fffc0000d00 refcount=3D3
TGETATTR: tag=3D1 fid=3D3 request_mask=3D0x17ff
RGETATTR: tag=3D1 valid=3D0x7ff qid=3D(type=3D0,version=3D0,path=3D14411520= 5255725065) mode=3D0100644 uid=3D0 gid=3D0 nlink=3D1 rdev=3D192 size=3D0 bl= ksize=3D4096 blocks=3D0 atime=3D(1428909674,0) mtime=3D(1428909674,0) ctime= =3D(1428909674,0) btime=3D(0,0) gen=3D0, data_version=3D0
TWRITE: tag=3D1 fid=3D2 offset=3D0 count=3D6
RWRITE: tag=3D1 fid=3D2 offset=3D0 input count=3D6 output count=3D6
TUNLINKAT: tag=3D1 dfid=3D1 name=3Dtest.txt
TUNLINKAT: tag=3D1 dfid=3D1 name=3Dtest.txt
TGETATTR: tag=3D1 fid=3D3 request_mask=3D0x3fff
RGETATTR: tag=3D1 valid=3D0x7ff qid=3D(type=3D0,version=3D0,path=3D14411520= 5255725065) mode=3D0100644 uid=3D0 gid=3D0 nlink=3D0 rdev=3D192 size=3D6 bl= ksize=3D4096 blocks=3D0 atime=3D(1428909674,0) mtime=3D(1428909674,0) ctime= =3D(1428909674,0) btime=3D(0,0) gen=3D0, data_version=3D0
TCLUNK: tag=3D1 fid=3D2
RCLUNK: tag=3D1 fid=3D2
TCLUNK: tag=3D1 fid=3D3
RCLUNK: tag=3D1 fid=3D3

(if you're not familiar with 9P, ATTACH =3D mount, WALK =3D create a ne= w
'fid' either clone of current file (nwname =3D 0) or lookup, CLUNK = ~=3D
close. Rest is obvious enough)


There's no lookup between the unlink and the getattr, so what I think i= s
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=3Dnon= e
here so you should be having the same.

--
Dominique

--001a113cd87669ad0905139d4854-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yhgrh-00017a-OZ for qemu-devel@nongnu.org; Mon, 13 Apr 2015 12:05:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yhgra-0008DP-JQ for qemu-devel@nongnu.org; Mon, 13 Apr 2015 12:05:37 -0400 Received: from mail-oi0-x22b.google.com ([2607:f8b0:4003:c06::22b]:33969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yhgra-0008DB-Bb for qemu-devel@nongnu.org; Mon, 13 Apr 2015 12:05:30 -0400 Received: by oiko83 with SMTP id o83so8145370oik.1 for ; Mon, 13 Apr 2015 09:05:29 -0700 (PDT) MIME-Version: 1.0 References: <20140702135258.23882.15100.malonedeb@soybean.canonical.com> <20150410123059.26540.1036.malone@gac.canonical.com> <20150413082753.GA15891@u-blusson> In-Reply-To: <20150413082753.GA15891@u-blusson> From: Eric Van Hensbergen Date: Mon, 13 Apr 2015 16:05:28 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a113cd87669ad0905139d4854 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: Dominique Martinet Cc: Linux FS Devel , Bug 1336794 <1336794@bugs.launchpad.net>, qemu-devel , V9FS Developers --001a113cd87669ad0905139d4854 Content-Type: text/plain; charset=UTF-8 Well, technically fid 3 isn't 'open', only fid 2 is open - at least according to the protocol. fid 3 and fid 2 are both clones of fid 1. However, thanks for the alternative workaround. If you get a chance, can you check that my change to the client to partially fix this for the other servers doesn't break nfs-ganesha: https://github.com/ericvh/linux/commit/fddc7721d6d19e4e6be4905f37ade5b0521f4ed5 On Mon, Apr 13, 2015 at 3:27 AM, Dominique Martinet < dominique.martinet@cea.fr> wrote: > 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 > --001a113cd87669ad0905139d4854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, technically fid 3 isn't 'open', only fid= 2 is open - at least according to the protocol. =C2=A0fid 3 and fid 2 are = both clones of fid 1. =C2=A0 However, thanks for the alternative workaround= .=C2=A0 If you get a chance, can you check that my change to the client to = partially fix this for the other servers doesn't break nfs-ganesha:=C2=A0 =C2=A0https://github.com/ericvh/linux/commit/fddc7= 721d6d19e4e6be4905f37ade5b0521f4ed5

<= div class=3D"gmail_quote">On Mon, Apr 13, 2015 at 3:27 AM, Dominique Martin= et <dominique.martinet@cea.fr> wrote:
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=3D1 fid=3D0 afid=3D-1 uname=3D'nobody' aname=3D'/e= xport' n_uname=3D-1
RATTACH: tag=3D1 fid=3D0 qid=3D(type=3D128,version=3D0,path=3D1)
TGETATTR: tag=3D1 fid=3D0 request_mask=3D0x7ff
RGETATTR: tag=3D1 valid=3D0x7ff qid=3D(type=3D128,version=3D0,path=3D1) mod= e=3D040755 uid=3D0 gid=3D0 nlink=3D3 rdev=3D192 size=3D4096 blksize=3D4096 = blocks=3D8 atime=3D(1428909387,0) mtime=3D(1428909389,0) ctime=3D(142890938= 9,0) btime=3D(0,0) gen=3D0, data_version=3D0
TATTACH: tag=3D1 fid=3D1 afid=3D-1 uname=3D'' aname=3D'/export&= #39; n_uname=3D0
RATTACH: tag=3D1 fid=3D1 qid=3D(type=3D128,version=3D0,path=3D1)
TGETATTR: tag=3D1 fid=3D1 request_mask=3D0x3fff
RGETATTR: tag=3D1 valid=3D0x7ff qid=3D(type=3D128,version=3D0,path=3D1) mod= e=3D040755 uid=3D0 gid=3D0 nlink=3D3 rdev=3D192 size=3D4096 blksize=3D4096 = blocks=3D8 atime=3D(1428909387,0) mtime=3D(1428909389,0) ctime=3D(142890938= 9,0) btime=3D(0,0) gen=3D0, data_version=3D0
TWALK: tag=3D1 fid=3D1 newfid=3D2 nwname=3D1 (component 1/1 :test.txt)
RERROR(_9P_TWALK) tag=3D1 err=3D(2|No such file or directory)
TWALK: tag=3D1 fid=3D1 newfid=3D2 nwname=3D0
RWALK: tag=3D1 fid=3D1 newfid=3D2 nwqid=3D0 fileid=3D1 pentry=3D0x8278c0 re= fcount=3D4
TLCREATE: tag=3D1 fid=3D2 name=3Dtest.txt flags=3D0100102 mode=3D0100644 gi= d=3D0
RLCREATE: tag=3D1 fid=3D2 name=3Dtest.txt qid=3D(type=3D0,version=3D0,path= =3D144115205255725065) iounit=3D0 pentry=3D0x7fffc0000d00
TWALK: tag=3D1 fid=3D1 newfid=3D3 nwname=3D1 (component 1/1 :test.txt)
RWALK: tag=3D1 fid=3D1 newfid=3D3 nwqid=3D1 fileid=3D144115205255725065 pen= try=3D0x7fffc0000d00 refcount=3D3
TGETATTR: tag=3D1 fid=3D3 request_mask=3D0x17ff
RGETATTR: tag=3D1 valid=3D0x7ff qid=3D(type=3D0,version=3D0,path=3D14411520= 5255725065) mode=3D0100644 uid=3D0 gid=3D0 nlink=3D1 rdev=3D192 size=3D0 bl= ksize=3D4096 blocks=3D0 atime=3D(1428909674,0) mtime=3D(1428909674,0) ctime= =3D(1428909674,0) btime=3D(0,0) gen=3D0, data_version=3D0
TWRITE: tag=3D1 fid=3D2 offset=3D0 count=3D6
RWRITE: tag=3D1 fid=3D2 offset=3D0 input count=3D6 output count=3D6
TUNLINKAT: tag=3D1 dfid=3D1 name=3Dtest.txt
TUNLINKAT: tag=3D1 dfid=3D1 name=3Dtest.txt
TGETATTR: tag=3D1 fid=3D3 request_mask=3D0x3fff
RGETATTR: tag=3D1 valid=3D0x7ff qid=3D(type=3D0,version=3D0,path=3D14411520= 5255725065) mode=3D0100644 uid=3D0 gid=3D0 nlink=3D0 rdev=3D192 size=3D6 bl= ksize=3D4096 blocks=3D0 atime=3D(1428909674,0) mtime=3D(1428909674,0) ctime= =3D(1428909674,0) btime=3D(0,0) gen=3D0, data_version=3D0
TCLUNK: tag=3D1 fid=3D2
RCLUNK: tag=3D1 fid=3D2
TCLUNK: tag=3D1 fid=3D3
RCLUNK: tag=3D1 fid=3D3

(if you're not familiar with 9P, ATTACH =3D mount, WALK =3D create a ne= w
'fid' either clone of current file (nwname =3D 0) or lookup, CLUNK = ~=3D
close. Rest is obvious enough)


There's no lookup between the unlink and the getattr, so what I think i= s
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=3Dnon= e
here so you should be having the same.

--
Dominique

--001a113cd87669ad0905139d4854--