Re: about NLM/NSM

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

 



J. Bruce Fields wrote:
On Mon, Oct 27, 2008 at 05:14:38PM -0400, Peter Staubach wrote:
J. Bruce Fields wrote:
On Mon, Oct 27, 2008 at 03:22:57PM -0400, Peter Staubach wrote:
J. Bruce Fields wrote:
On Mon, Oct 27, 2008 at 02:49:27PM +0800, hexf wrote:
We are using nfsv3. Now we meet a demand. If a client which hold a
lock crash, after it reboot, its statd daemon can notify the nfs
server to release the lock.  But if this client will not reboot for
some reason(or will reboot after a long time), then the lock it
holding will not be released.In nfsv3 and nlmv4,it seems there is no
time-out mechnism for this situation. How would we solve this
question? My colleague advise me to modify the code of NLM/NSM to meet
this demand,but is seems quite a complicated work.Can you give me some
advice?
It might be possible to modify the server so that it dropped all locks
from a client it hadn't heard from in a while.  However, nfsv2/v3
clients are not required to contact the server regularly while they hold
locks.  So you may end up revoking locks held by perfectly good
functioning clients.

As an ugly workaround, rebooting the server will clear the problem, as
it will notify clients to recover their locks on restart, and any dead
clients will fail to recover their locks.

Didn't Wendy Cheng submit some patches to implement a
"clearlocks" sort of functionality?  What happened with
them?
Yes, but that's motivated by the case of migrating all clients using one
export; so it'll drop all locks held on a single filesystem, or all
locks acquired using a single server (not client!) ip address.

So if we want some finer-grained interface then that's yet to be
designed.
Sorry, I guess that I was remembering incorrectly.  I was
thinking that she was looking for something like the clearlocks
functionality so that file systems could be migrated around
cleanly.

That's what she was working on (and we merged), yes.

But it doesn't help clear just the set of locks held by a single client.

It seems for this situation, we could use this sort of variation.

I'm losing track of what those two "this"'s refer to!

Sorry -- :-)

For the situation of needing to clear locks belonging to long
dead and not returning clients, we could use a variation of
Wendy's proposal which works using the client IP as the key.

It is a rope with a very large and suspicious looking knot on
the end though...

      ps
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux