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?Also, don't we need to prevent of exporting the same file system parts but different servers always, but not only for grace period?
-- 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