linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dominique Martinet <dominique.martinet@cea.fr>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Bug 1336794 <1336794@bugs.launchpad.net>,
	qemu-devel <qemu-devel@nongnu.org>,
	V9FS Developers <v9fs-developer@lists.sourceforge.net>
Subject: Re: [V9fs-developer] [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files
Date: Mon, 13 Apr 2015 10:27:53 +0200	[thread overview]
Message-ID: <20150413082753.GA15891@u-blusson> (raw)
In-Reply-To: <CAFkjPTm1gbHiRJqvWj74=T1Bs0KfiEb2xiN9F69EVHkHA8vn=g@mail.gmail.com>

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

  reply	other threads:[~2015-04-13  8:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140702135258.23882.15100.malonedeb@soybean.canonical.com>
     [not found] ` <20150410123059.26540.1036.malone@gac.canonical.com>
2015-04-12 12:42   ` [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files Eric Van Hensbergen
2015-04-13  8:27     ` Dominique Martinet [this message]
2015-04-13 16:05       ` [V9fs-developer] " Eric Van Hensbergen
2015-04-14 16:07         ` [Qemu-devel] " Al Viro
2015-04-14 16:19           ` Eric Van Hensbergen
2015-04-14 21:44             ` [Qemu-devel] " Al Viro
2015-04-15 11:28         ` Dominique Martinet
2015-04-15 14:17           ` Eric Van Hensbergen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150413082753.GA15891@u-blusson \
    --to=dominique.martinet@cea.fr \
    --cc=1336794@bugs.launchpad.net \
    --cc=ericvh@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).