good to know, thanks dominique. I gave it a sniff test with FSX and a few
other benchmarks, but I need to hit it with some multithreaded
regressions. Any pointers to reproducible failure cases would be
beneficial.
On Wed, Apr 15, 2015 at 6:28 AM Dominique Martinet
dominique.marti...@cea.fr
Eric Van Hensbergen wrote on Mon, Apr 13, 2015 at 04:05:28PM +:
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.
Right, they're clone fids, but nothing in the protocol says what should
happen to
On Mon, Apr 13, 2015 at 04:05:28PM +, Eric Van Hensbergen wrote:
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 patch looks fine by me. Happy to put it in the queue. Thanks Al.
On Tue, Apr 14, 2015 at 11:07 AM Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Apr 13, 2015 at 04:05:28PM +, Eric Van Hensbergen wrote:
Well, technically fid 3 isn't 'open', only fid 2 is open - at least
according
On Tue, Apr 14, 2015 at 04:19:41PM +, Eric Van Hensbergen wrote:
That patch looks fine by me. Happy to put it in the queue. Thanks Al.
OK... Here's one more:
9p: don't bother with __getname() in -follow_link()
We copy there a kmalloc'ed string and proceed to kfree that string
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
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
