All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wendy Cheng <wcheng@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: [NFS] [PATCH 3/4 Revised] NLM - kernel lockd-statd changes
Date: Tue, 17 Apr 2007 11:09:41 -0400	[thread overview]
Message-ID: <4624E335.7050907@redhat.com> (raw)
In-Reply-To: <200704171651.36497.okir@lst.de>

Olaf Kirch wrote:
> On Tuesday 17 April 2007 15:24, Wendy Cheng wrote:
>   
>>> I think in term of correctness, it's better to send an SM_NOTIFY
>>> for each IP associated with such a set, anyway.
>>>   
>>>       
>> That's exactly what we have been proposing... :) .. We'll rely heavily 
>> on HA callout program to tell us which client uses which (server) 
>> floating IP. 
>>     
>
> Correct me if I'm wrong, but it seems your patch records every IP
> used by the client, rather than the *all* the IPs related to the set of
> file systems being moved. So if there are several IPs for this set, you
> will end up sending notifications only from those the client happened
> to have talked to.
>   

Yes. Then why should we SM_NOTIFY the clients that do not have the 
associated locks (and introducing more possible reclaiming delay) ? Be 
aware that failover normally has timing constraints - it needs to get 
finished within a sensible time interval.

-- Wendy
> My point was, you move a set of file systems A, B and C, with
> IPs X, Y, Z. You know what the addresses are, so from a
> robustness point of view your best bet is to send SM_NOTIFY
> messages from IPs X, Y, Z, regardless of whether the client has
> been talking to all of them, or just one.
>
> Olaf
>   



WARNING: multiple messages have this Message-ID (diff)
From: Wendy Cheng <wcheng@redhat.com>
To: Olaf Kirch <okir@lst.de>
Cc: Neil Brown <neilb@suse.de>,
	cluster-devel@redhat.com, Lon Hohberger <lhh@redhat.com>,
	nfs@lists.sourceforge.net
Subject: Re: [PATCH 3/4 Revised] NLM - kernel lockd-statd changes
Date: Tue, 17 Apr 2007 11:09:41 -0400	[thread overview]
Message-ID: <4624E335.7050907@redhat.com> (raw)
In-Reply-To: <200704171651.36497.okir@lst.de>

Olaf Kirch wrote:
> On Tuesday 17 April 2007 15:24, Wendy Cheng wrote:
>   
>>> I think in term of correctness, it's better to send an SM_NOTIFY
>>> for each IP associated with such a set, anyway.
>>>   
>>>       
>> That's exactly what we have been proposing... :) .. We'll rely heavily 
>> on HA callout program to tell us which client uses which (server) 
>> floating IP. 
>>     
>
> Correct me if I'm wrong, but it seems your patch records every IP
> used by the client, rather than the *all* the IPs related to the set of
> file systems being moved. So if there are several IPs for this set, you
> will end up sending notifications only from those the client happened
> to have talked to.
>   

Yes. Then why should we SM_NOTIFY the clients that do not have the 
associated locks (and introducing more possible reclaiming delay) ? Be 
aware that failover normally has timing constraints - it needs to get 
finished within a sensible time interval.

-- Wendy
> My point was, you move a set of file systems A, B and C, with
> IPs X, Y, Z. You know what the addresses are, so from a
> robustness point of view your best bet is to send SM_NOTIFY
> messages from IPs X, Y, Z, regardless of whether the client has
> been talking to all of them, or just one.
>
> Olaf
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-04-17 15:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05 21:52 [Cluster-devel] [PATCH 3/4 Revised] NLM - kernel lockd-statd changes Wendy Cheng
2007-04-05 21:52 ` Wendy Cheng
2007-04-10  9:09 ` Olaf Kirch
2007-04-10  9:10   ` [Cluster-devel] Re: [NFS] " Olaf Kirch
2007-04-10 14:41   ` Lon Hohberger
2007-04-10 14:41     ` Lon Hohberger
2007-04-10 15:00   ` [Cluster-devel] Re: [NFS] " Wendy Cheng
2007-04-10 15:00     ` Wendy Cheng
2007-04-10 18:16   ` [Cluster-devel] Re: [NFS] " Wendy Cheng
2007-04-10 18:16     ` Wendy Cheng
     [not found]   ` <message from Olaf Kirch on Tuesday April 10>
2007-04-11  4:50     ` [Cluster-devel] Re: [NFS] " Neil Brown
2007-04-11  4:50       ` Neil Brown
2007-04-13 19:16       ` [Cluster-devel] Re: [NFS] " Lon Hohberger
2007-04-13 19:16         ` Lon Hohberger
2007-04-13 19:31         ` [Cluster-devel] Re: [NFS] " Wendy Cheng
2007-04-13 19:31           ` Wendy Cheng
2007-04-17 11:52         ` [Cluster-devel] Re: [NFS] " Olaf Kirch
2007-04-17 11:52           ` Olaf Kirch
2007-04-17 13:24           ` [Cluster-devel] Re: [NFS] " Wendy Cheng
2007-04-17 13:24             ` Wendy Cheng
2007-04-17 14:51             ` [Cluster-devel] Re: [NFS] " Olaf Kirch
2007-04-17 14:51               ` Olaf Kirch
2007-04-17 15:09               ` Wendy Cheng [this message]
2007-04-17 15:09                 ` Wendy Cheng

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=4624E335.7050907@redhat.com \
    --to=wcheng@redhat.com \
    /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.