All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Bruce Fields'" <bfields@fieldses.org>
Cc: "'Kernel NFS List'" <linux-nfs@vger.kernel.org>,
	"'Ganesha NFS List'" <nfs-ganesha-devel@lists.sourceforge.net>
Subject: RE: pynfs updates
Date: Tue, 1 Oct 2013 15:05:23 -0400	[thread overview]
Message-ID: <00b801cebed9$312b6030$93822090$@mindspring.com> (raw)
In-Reply-To: <20131001143051.GH26382@fieldses.org>

> One more problem: CSID10 is failing against the Linux server with
> NFS4ERR_TOO_MANY_OPS, because each of those lookups is actually a full
> lookup from PUTROOTFH to /, resulting in 17 ops on my setup.  Could we
> maybe work relative to the parent directory instead?

Ok, was able to fix this by doing a LOOKUP sequence in a separate compound
followed by GETFH then in the compound that tests SAVEFH/RESTOREFH, just do
PUTFH that saved FH.

Things could be a lot smoother as discussed on IRC if the initialization
stored away env.home_fh.

Then with some work, this test could be simplified to:

SEQUENCE, PUTFH(env.home_fh), OPEN, GETFH, SAVEFH, PUTFH(env.home_fh),
RESTOREFH, CLOSE

Note that that GETFH is not actually used by this test, but presumably
open_create_op() would produce:

PUTFH(env.home_fh), OPEN, GETFH

Instead of what it currently does:

PUTROOTFH, LOOKUP..., OPEN, GETFH

The new branch is here:

https://github.com/ffilz/pynfs/commits/master

Frank



  parent reply	other threads:[~2013-10-01 19:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-30 18:17 pynfs updates Frank Filz
2013-09-30 22:11 ` Bruce Fields
2013-09-30 23:54   ` Frank Filz
2013-10-01 14:26     ` 'Bruce Fields'
2013-10-01 14:30       ` 'Bruce Fields'
2013-10-01 15:42         ` Frank Filz
2013-10-01 19:05         ` Frank Filz [this message]
2013-10-02 11:36           ` 'Bruce Fields'
2013-10-02 15:58             ` Frank Filz
2013-10-01 18:21       ` Frank Filz
2013-10-01 18:45         ` 'Bruce Fields'

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='00b801cebed9$312b6030$93822090$@mindspring.com' \
    --to=ffilzlnx@mindspring.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfs-ganesha-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.