[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [NFS] [Cluster-devel] [PATCH 0/4 Revised] NLM - lock failover

On Friday April 27, bfields fieldses org wrote:
> On Fri, Apr 27, 2007 at 11:36:16AM -0400, Wendy Cheng wrote:
> > J. Bruce Fields wrote:
> > >On Fri, Apr 27, 2007 at 03:17:10PM +0100, Christoph Hellwig wrote:
> > >  
> > >>In fact couldn't this be treated as a reexport with a NFSEXP_ flag
> > >>meaning drop all locks to avoid creating new interfaces?
> > >>    
> > >
> > >Off hand, I can't see any reason why that wouldn't work.  The code to
> > >handle it would probably go in fs/nfsd/export.c:svc_export_parse().
> > >
> > >  
> > Sign :( ... folks, we go back to the loop again. That *was* my first 
> > proposal ...

Yes, I grinned when I saw it too.
Your first proposal was actually a flag to  "unexport", where as
Christoph seems to be a flag to "export".  So there is at least a
subtle difference.

A flag to unexport cannot work because we don't call unexport - we
just flush a kernel cache.

A flag to export is just .... weird.  All the other export flags are
state flags.  This would be an action flag.  They are quite different
things.   Setting a state flag again is a no-op.  Setting an action
flag again has a very real effect.

Also, each filesystem is potentially exported multiple times for
different sets of clients.  If such a flag (whether on 'export' or
'unexport') just said "remove locks from this set of clients" it
wouldn't meet the needs, and if it said "remove all locks" it would be
a very irregular interface.

> So you're talking about this and followups?:
> 	http://marc.info/?l=linux-nfs&m=115009204513790&w=2
> I just took a look and couldn't find any complaints about that
> approach.  Were they elsewhere?


Is where I said that I don't like the unexport flag.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]