lkml.org 
[lkml]   [2006]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [NFS] [PATCH 004 of 19] knfsd: lockd: introduce nsm_handle
    From
    Date
    On Fri, 2006-09-01 at 18:11 +0200, Olaf Kirch wrote:
    > This is all related to the reasons for introducing NSM notification
    > by name in the first place.
    >
    > On the client side, we may have mounted several volumes from a multi-homed
    > server, using different addresses, and you have several NLM client
    > handles, each with one of these addresses - and each in a different
    > nlm_host object.
    >
    > Or you have an NFS server in a HA configuration, listening on a virtual
    > address. As the server fails over, the alias moves to the backup
    > machine.
    >
    > Or (once we have IPv6) you may have a mix of v4 and v6 mounts.
    >
    > Now when the server reboots, it will send you one or more SM_NOTIFY
    > messages. You do not know which addresses it will use. In the multihomed
    > case, you will get one SM_NOTIFY for each server address if the server
    > is a Linux box. Other server OSs will send you just one SM_NOTIFY,
    > and the sender address will be more or less random. In the HA case
    > described above, the sender address will not match the address
    > you used at all (since the UDP packet will have the interface's
    > primary IP address, not the alias).
    >
    > This is the main motivation for introducing the nsm_handle, and this is
    > also the reason why there is potentially a 1-to-many relationship between
    > nsm_handles (representing a "host") and nlm_host, representing a tuple of
    > (NLM version, transport protocol, address).
    >
    > Maybe we should rename nlm_host to something less confusing.

    The local statd process is supposed to decode the notification from the
    remote client/server, and then notify the kernel. It already sends that
    notification on a per-nlm_host basis (i.e. it the call down to the
    kernel contains the <address,version,transport protocol>.

    If we need to mark more than one <address,version,transport protocol>
    tuple as rebooting when we get a notification from the remote
    client/server, then why not fix statd so that it does so. Why perform
    these extra mappings in the kernel, which doesn't have the benefit of
    reverse DNS lookups etc to help it out?

    Cheers,
    Trond

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-09-01 18:45    [W:4.112 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site