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

[Frank van Maarseveen]

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

I'm quite interested in _any_ patch which would allow me to drop
the locks obtained by NFS clients on a specific export, either by (1)
"exportfs -uh" or by (2) "echo /some/path > /proc/fs/nfsd/nlm_drop_lock"
as Neil mentioned.
I want to migrate virtual(*) NFS servers _including_ the locks without
having to tear down the whole machine. In my case "migration" is a sort
of scheduled failover: no HA or clusters involved.

At first, the "exportfs -uh" proposal (maybe fsid driven) seems "the
right thing" because after unexporting there's no valid case to preserve
the locks AFAICS. Unexport implies EACCES for subsequent NFS accesses
anyway and unexporting /cdrom for example is _required_ in order to be
able to umount and eject the thing. As it stands today, unexporting is
not even enough to be able to unmount it and that's not good. (the need
to having to unexport a /cdrom before being able to eject it is actually
a problem on its own -- a separate issue).

So why not drop the locks always upon unexport? Stupid question of course
because exporting anything will not send out any sm notifications so
that would break symmetry.


I'd prefer (2) "echo /some/path > /proc/fs/nfsd/nlm_drop_lock" because:

- Tying the -h (drop locks) option to -u (unexport) is too restrictive IMO.
  For one thing, there's a bug in the linux NFS client locking code (I
  reported this earlier) which results in locks not being removed from
  the server. It was not too difficult to reproduce and programs on the
  client will wait forever due to this. To handle these kind of situations
  I need (2) on the server.

- (2) may be useful for other NFS server setups: it is inherently more
  flexible.

- (2) does not depend on nfs-utils. It's simpler.


(*) virtual in this case means a UUID or IP based fsid= option and an
additional IP address on eth0 per export entry, such, that it becomes
possible to move an export entry + disk partition + local mount to
different hardware without needing to remount it on all <large number>
NFS clients.

-- 
Frank