From: Wendy Cheng <wcheng@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: [NFS] [PATCH 2/4 Revised] NLM - set per fsid grace period
Date: Tue, 10 Apr 2007 10:37:48 -0400 [thread overview]
Message-ID: <461BA13C.3080408@redhat.com> (raw)
In-Reply-To: <200704101057.24105.okir@lst.de>
Olaf Kirch wrote:
> On Thursday 05 April 2007 23:52, Wendy Cheng wrote:
>
>> This change enables per NFS-export entry lockd grace period. The
>> implementation is based on a double linked list fo_fsid_list that
>> contains entries of fsid info. It is expected this would not be a
>> frequent event. The fo_fsid_list is short and the entries expire within
>> a maximum of 50 seconds. The grace period setting follows the existing
>> NLM grace period handling logic and is triggered via echoing the NFS
>> export filesystem id into nfsd procfs entry as:
>>
>
> Your patch creates a new per-export structure that is private to lockd.
> It may be easier to put the grace period value into the export entry,
> and check for that in nlm_fopen. It feels more natural than adding
> a whole new shadow export table just for the benefit of lockd.
> (Especially when you consider future extensions like being able
> to search the list by dev_t or uuid or whatever)
>
I'm traveling so may not be able to do intelligent responses until next
Monday.
However, I should have made it clear that these patches are minimum
changes to keep NFS V3 failover going due to large amount of existing
installations and users. The real efforts and future enhancements should
be placed on NFS V4. That's the reason most of the code in this patch
set are stand-alone addition and I have been trying not to mingle the
changes with main-line nfsd-lockd code.
Ideally we would like to avoid this grace period eventually if we can
(by transferring the locks from one server to another server without NFS
clients' involvement).
-- Wendy
WARNING: multiple messages have this Message-ID (diff)
From: Wendy Cheng <wcheng@redhat.com>
To: Olaf Kirch <okir@lst.de>
Cc: cluster-devel@redhat.com, Lon Hohberger <lhh@redhat.com>,
nfs@lists.sourceforge.net
Subject: Re: [PATCH 2/4 Revised] NLM - set per fsid grace period
Date: Tue, 10 Apr 2007 10:37:48 -0400 [thread overview]
Message-ID: <461BA13C.3080408@redhat.com> (raw)
In-Reply-To: <200704101057.24105.okir@lst.de>
Olaf Kirch wrote:
> On Thursday 05 April 2007 23:52, Wendy Cheng wrote:
>
>> This change enables per NFS-export entry lockd grace period. The
>> implementation is based on a double linked list fo_fsid_list that
>> contains entries of fsid info. It is expected this would not be a
>> frequent event. The fo_fsid_list is short and the entries expire within
>> a maximum of 50 seconds. The grace period setting follows the existing
>> NLM grace period handling logic and is triggered via echoing the NFS
>> export filesystem id into nfsd procfs entry as:
>>
>
> Your patch creates a new per-export structure that is private to lockd.
> It may be easier to put the grace period value into the export entry,
> and check for that in nlm_fopen. It feels more natural than adding
> a whole new shadow export table just for the benefit of lockd.
> (Especially when you consider future extensions like being able
> to search the list by dev_t or uuid or whatever)
>
I'm traveling so may not be able to do intelligent responses until next
Monday.
However, I should have made it clear that these patches are minimum
changes to keep NFS V3 failover going due to large amount of existing
installations and users. The real efforts and future enhancements should
be placed on NFS V4. That's the reason most of the code in this patch
set are stand-alone addition and I have been trying not to mingle the
changes with main-line nfsd-lockd code.
Ideally we would like to avoid this grace period eventually if we can
(by transferring the locks from one server to another server without NFS
clients' involvement).
-- Wendy
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-04-10 14:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-05 21:52 [Cluster-devel] [PATCH 2/4 Revised] NLM - set per fsid grace period Wendy Cheng
2007-04-05 21:52 ` Wendy Cheng
2007-04-10 8:57 ` Olaf Kirch
2007-04-10 8:57 ` [Cluster-devel] Re: [NFS] " Olaf Kirch
2007-04-10 14:37 ` Wendy Cheng [this message]
2007-04-10 14:37 ` 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=461BA13C.3080408@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.