All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank van Maarseveen <frankvm@frankvm.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Neil Brown <neilb@suse.de>,
	nfs@lists.sourceforge.net,
	Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: Use of delayed request information in nlmsvc_lookup_host
Date: Thu, 15 Nov 2007 17:00:36 +0100	[thread overview]
Message-ID: <20071115160036.GA18544@janus> (raw)
In-Reply-To: <473C4FE2.1090402@oracle.com>

On Thu, Nov 15, 2007 at 08:55:46AM -0500, Chuck Lever wrote:
> Neil Brown wrote:
> >On Wednesday November 14, chuck.lever@oracle.com wrote:
> >>Trond Myklebust wrote:
> >>>On Wed, 2007-11-14 at 14:00 -0500, Chuck Lever wrote:
> >>>>That's correct.  I'm just trying to understand why, historically, 
> >>>>rq_daddr was just the 32-bit address and not a full sockaddr to begin 
> >>>>with.  There may be something we're missing, like "we didn't want to 
> >>>>add another large field to this structure due to memory alignment or 
> >>>>allocation efficiency concerns".  :-)
> >>>Actually, rq_daddr by definition pretty much has to be of the same
> >>>address family as rq_addr, since they are the two endpoints for the same
> >>>socket. 
> >>>
> >>>However I can't see where rq_addr is being initialised for UDP sockets.
> >>>That is sort of worrying given that it is used among other things by the
> >>>nfsd duplicate reply cache...
> >>That's the other half of my question.  Why isn't nlmsvc_lookup_host 
> >>using rq_addr (without the d)?
> >
> >Git is your friend.
> >
> >commit c98451bdb2f3e6d6cc1e03adad641e9497512b49
> >Author: Frank van Maarseveen <frankvm@frankvm.com>
> >Date:   Mon Jul 9 22:25:29 2007 +0200
> >
> >    NLM: fix source address of callback to client
> >    
> >    Use the destination address of the original NLM request as the
> >    source address in callbacks to the client.
> >    
> >    Signed-off-by: Frank van Maarseveen <frankvm@frankvm.com>
> >    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> 
> Silly me.  I had assumed that it had always been that way, and thus git 
> would not be helpful (git's history truncates at 2.6.12).
> 
> Unfortunately Frank's patch description doesn't explain *why* this 
> change was made.  I assume this fixes a bug with multi-homed servers?

Almost: Multiple NICs are probably not a problem (kernel should fill in
correct src address depending on outgoing interface) but for multiple
IP addresses on the same interface it definately is a problem.

When NFS clients A and B are contending for a lock the server needs
to do a callback to client B when the lock is released by client
A. Without above fix the kernel would pick an arbitrary source address
for callbacks. And (at least) the linux NFS client verifies the source
address of an NLM callback, see nlmclnt_grant().

IP aliases are very useful for virtualizing NFS servers (we run about
70 of them on 4 physical machines).

> What do you think of changing the rq_daddr field to be a sockaddr_storage?

One thing which still worries me is the sockaddr_storage size: this thing
is a bit large due to AF_UNIX support. AF_UNIX isn't used for NFS AFAIK.
Anyway, changing that is a separate issue.

-- 
Frank

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

      parent reply	other threads:[~2007-11-15 16:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-14 18:23 Use of delayed request information in nlmsvc_lookup_host Chuck Lever
2007-11-14 18:43 ` Trond Myklebust
2007-11-14 19:00   ` Chuck Lever
2007-11-14 19:32     ` J. Bruce Fields
2007-11-14 19:41     ` Trond Myklebust
2007-11-14 19:50       ` Trond Myklebust
2007-11-14 19:54       ` Chuck Lever
2007-11-15  1:41         ` Neil Brown
2007-11-15 13:55           ` Chuck Lever
2007-11-15 15:54             ` Trond Myklebust
2007-11-15 16:26               ` Chuck Lever
2007-11-15 17:00                 ` Chuck Lever
2007-11-15 17:23               ` Chuck Lever
2007-11-15 17:37                 ` Trond Myklebust
2007-11-15 18:02                   ` Chuck Lever
2007-11-15 16:00             ` Frank van Maarseveen [this message]

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=20071115160036.GA18544@janus \
    --to=frankvm@frankvm.com \
    --cc=chuck.lever@oracle.com \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    /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.