All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wendy Cheng <wcheng@redhat.com>
To: "Stanley, Jon" <Jon.Stanley@savvis.net>
Cc: nfs@lists.sourceforge.net, linux clustering <linux-cluster@redhat.com>
Subject: Re: [Linux-cluster] [RFC] NLM lock failover admin interface
Date: Mon, 12 Jun 2006 23:39:31 -0400	[thread overview]
Message-ID: <1150169971.27203.1.camel@localhost.localdomain> (raw)
In-Reply-To: <9A6FE0FCC2B29846824C5CD81C6647B902207776@s228130hz1ew08.apptix-01.savvis.net>

On Mon, 2006-06-12 at 09:45 -0500, Stanley, Jon wrote:
>  
> > -----Original Message-----
> > From: linux-cluster-bounces@redhat.com 
> > [mailto:linux-cluster-bounces@redhat.com] On Behalf Of Wendy Cheng
> > Sent: Monday, June 12, 2006 12:26 AM
> > To: nfs@lists.sourceforge.net
> > Cc: linux-cluster@redhat.com
> > Subject: [Linux-cluster] [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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs



_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2006-06-13  3:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-12 14:45 [Linux-cluster] [RFC] NLM lock failover admin interface Stanley, Jon
2006-06-13  3:39 ` Wendy Cheng [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-06-12  5:25 Wendy Cheng
2006-06-12 15:00 ` [Linux-cluster] " J. Bruce Fields
2006-06-12 15:44   ` [NFS] " Wendy Cheng
2006-06-12 16:20     ` [Linux-cluster] " Madhan P
2006-06-12 16:58       ` Madhan P
2006-06-12 17:23     ` Steve Dickson

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=1150169971.27203.1.camel@localhost.localdomain \
    --to=wcheng@redhat.com \
    --cc=Jon.Stanley@savvis.net \
    --cc=linux-cluster@redhat.com \
    --cc=nfs@lists.sourceforge.net \
    /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.