Linux NFS development
 help / color / mirror / Atom feed
From: Olaf Kirch <okir@suse.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH] Fix nfsd rewrite performance
Date: Tue, 2 Aug 2005 11:49:50 +0200	[thread overview]
Message-ID: <20050802094950.GB29054@suse.de> (raw)
In-Reply-To: <20050801125832.GB8598@fieldses.org>

On Mon, Aug 01, 2005 at 08:58:32AM -0400, J. Bruce Fields wrote:
> There's a different problem, though, with the request deferral stuff.
> It waits for upcalls by aborting request processing, saving a copy of
> the raw request data, then processing it from scratch again when the
> upcall response comes.

I just looked at the code, and there are two types of deferrals.
One is for authentication stuff - this will actually use svc_defer and
svc_revisit, which goes back to look at the entire request.

The other type is what hte nfs4idmap stuff does, which uses its own
defer/revisit routines, which just make the nfsd thread wait.

So neither poses a problem to munging the iovec in nfsd_write: The
authentication stuff will happen when we parse the RPC header, which is
way before we decide to call nfsd_write.  The idmap stuff may be called
after processing a write call, but it will not go back to revisit the
entire request, it will just stall briefly while idmapd is doing its job.
Correct?

In general, I believe it does not make sense to call svc_defer once we've
started to process a request, because the request may not be idempotent.
It sounds like a reasonable assumption to me that deferring and revisiting
an entire requests is only done before we hit the RPC program handler.

Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-08-02  9:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-01 11:39 [PATCH] Fix nfsd rewrite performance Olaf Kirch
2005-08-01 11:53 ` J. Bruce Fields
2005-08-01 11:59   ` Olaf Kirch
2005-08-01 12:10     ` J. Bruce Fields
2005-08-01 12:14       ` Olaf Kirch
2005-08-01 12:58         ` J. Bruce Fields
2005-08-02  9:49           ` Olaf Kirch [this message]
2005-08-02 10:02             ` J. Bruce Fields
2005-08-02 10:49               ` Olaf Kirch
2005-08-02 12:07                 ` J. 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=20050802094950.GB29054@suse.de \
    --to=okir@suse.de \
    --cc=bfields@fieldses.org \
    --cc=nfs@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