On Mon, 2006-06-12 at 09:45 -0500, Stanley, Jon wrote: > > > -----Original Message----- > > From: linux-cluster-bounces@xxxxxxxxxx > > [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of Wendy Cheng > > Sent: Monday, June 12, 2006 12:26 AM > > To: nfs@xxxxxxxxxxxxxxxxxxxxx > > Cc: linux-cluster@xxxxxxxxxx > > Subject: [RFC] NLM lock failover admin interface Jon, Thank you for review this - it helps ! -- Wendy > > > > 1. /proc interface, say writing the fsid into a /proc directory entry > > would end up dropping all NLM locks associated with the NFS > > export that > > has fsid in its /etc/exports file. > > This would defintely have it's advantages for people who know what > they're doing - they could drop all locks without unexporting the > filesystem. However, it also gives people the opportunity to shoot > themselves in the foot - by eliminating locks that are needed. After > weighing the pros and cons, I really don't think that any method > accessible via /proc is a good idea. > > > > > 2. Adding a new flag into "exportfs" command, say "h", such that > > > > "exportfs -uh *:/export_path" > > > > would un-export the entry and drop the NLM locks associated with the > > entry. > > > > This is the best of the three, IMHO. Gives you the safety of *knowing* > that the filesystem was unexported before dropping the locks, and > preventing folks from shooting themselves in the foot. > > The other option that was mentioned, a separate lockd for each fs, is > also a good idea - but would require a lot of coding no doubt, and > introduce more instability into what I already preceive as an unstable > NFS subsystem in Linux (I *refuse* to use Linux as an NFS server and > instead go with Solaris - I've had *really* bad experiences with Linux > NFS under load - but that's getting OT). > > > _______________________________________________ > NFS maillist - NFS@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/nfs -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
