From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Date: Mon, 14 Aug 2006 11:44:41 -0400 Subject: [Cluster-devel] Re: [NFS] [PATCH 2/5] NLM failover - per fs grace period In-Reply-To: <1155535221.3416.26.camel@localhost.localdomain> References: <1155535221.3416.26.camel@localhost.localdomain> Message-ID: <1155570281.5664.84.camel@localhost> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, 2006-08-14 at 02:00 -0400, Wendy Cheng wrote: > This change enables per NFS-export entry lockd grace period. The > implementation is based on a global single linked list nlm_servs that > contains entries of fsid info. It is expected this would not be a > frequent event. The nlm_servs list should be 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 /proc/fs/nfsd/nlm_set_igrace > file as: > > shell> echo 1234 > /proc/fs/nfsd/nlm_set_igrace I still don't find the above interface convincing. Firstly, as I already told you, the NSM protocol does not allow you to set only a single filesystem in grace. Clients get notified of server reboots, not filesystem reboots: if they try to reclaim locks and find out that some of filesystems they have mounted will not allow them to do so, then they _will_ get confused and start dropping locks that would otherwise be perfectly valid. Secondly, with the above interface, you have to export the filesystem first, and then set the grace period. Since that is not an atomic operation, it is perfectly possible for someone to mount the filesystem, after you exported it, then set a new lock before you have managed to declare it in grace. This makes reclaiming locks impossible. Cheers, Trond