10.04.2012 16:05, Jeff Layton пишет:
On Tue, 10 Apr 2012 15:44:42 +0400
Stanislav Kinsbursky<skinsbursky@xxxxxxxxxxxxx> wrote:
03.04.2012 16:14, Jeff Layton пишет:
The main reason for the grace period is to prevent the server from
allowing an operation that might otherwise be denied once the client has
reclaimed all of its stateful objects.
Currently, the grace period handling in the nfsd/lockd server code is
very simple. When the lock managers start, they stick an entry on a list
and set a timer. When the timers pop, then they remove the entry from
the list. The locks_in_grace check just looks to see if the list is
empty. If it is, then the grace period is considered to be over.
This is insufficient for a clustered filesystem that is being served
from multiple nodes at the same time. In such a configuration, the grace
period must be coordinated in some fashion, or else one node might hand
out stateful objects that conflict with those that have not yet been
reclaimed.
This patch paves the way for fixing this by adding a new export
operation called locks_in_grace that takes a superblock argument. The
existing locks_in_grace function is renamed to generic_locks_in_grace,
and a new locks_in_grace function that takes a superblock arg is added.
If a filesystem does not have a locks_in_grace export operation then the
generic version will be used.
Care has also been taken to reorder calls such that locks_in_grace is
called last in compound conditional statements. Handling this for
clustered filesystems may involve upcalls, so we don't want to call it
unnecessarily.
For now, this patch is just an RFC as I do not yet have any code that
overrides this function and am still specing out what that code should
look like.
Oops, I've noticed your patch after I replied in "Grace period" thread.
This patch looks good, but doesn't explain, how this per-filesystem logic will
work in case of sharing non-nested subdirectories with the same superblock.
This is a valid situation. But how to handle grace period in this case?
It's a valid situation but one that's discouraged.
But it looks like common case. In future we are going to get rid of using one
mounted file system for more than one virtual environment, but currently in
OpenVZ we do exactly this.
And it looks like LXC uses chroot for containers as well...
--
Best regards,
Stanislav Kinsbursky
--
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
