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

[J. Bruce Fields <bfields@fieldses.org>]

On Sat, Apr 28, 2007 at 08:22:55AM +1000, Neil Brown wrote:
> 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.

In this case the second set shouldn't have any effect--whatever flag is
set should prevent further locks from being accepted, shouldn't it?  (If
it matters.)

> 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.

The same could be said of the "fsid=" option on exports.  It doesn't
make sense to provide different filehandle- or path- name spaces
depending on the IP address of a client.  If my laptop changes IP
address, then I can (grudgingly) accept the fact that the server may
have to deny me access that I had before--maybe it just can't trust the
network I moved to for whatever reason--but I'd really rather it didn't
suddenly start giving me paths, or different filehandles, or different
semantics (like sync vs. async).

So the export interface is already being used for stuff that's really
intended to be per-filesystem rather than per-(filesystem, client) pair.

> > 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?
> 
> https://www.redhat.com/archives/linux-cluster/2006-June/msg00101.html
> 
> Is where I said that I don't like the unexport flag.

Got it, thanks.

--b.