We'd like an asynchronous posix locking interface so that we can provide NFS clients with cluster-coherent locking without blocking lockd while the filesystem goes off and talks to other nodes. So, here's one attempt. It also includes an draft implementation of the filesystem side for GFS2, which may well be wrong--it's not even tested yet--but hopefully gives some idea what would be necessary. A few points, among others, that I'm unsure of: - We added a new ->lock() export operation, figuring this was a feature that only lockd and nfsd care about for now, and that we'd rather not muck about with common locking code. But the export operation is pretty much identical to the file ->lock() operation; would it make more sense to use that? - The filesystem returns the lock results to lockd using the ->fl_notify() callback. We add a few arguments to fl_notify() to pass the results, and add a return value so the filesystem can recognize the case where the callback comes after lockd has given up waiting and returned an error to the user. Presumably the filesystem needs to have a way to cancel the lock in this case. (Our GFS code ignores this problem for now.) Maybe it would be better to just poke lockd when the result is ready and let it discover what happened by retrying the original ->lock() call? Or maybe we should use a separate callback? - We're ignoring the blocking lock case for now under the assumption it's always OK for lockd to return an immediate "denied" in that case, then use the granted callback, even in cases where it doesn't know for sure that there's a conflicting lock. Thoughts? Better ideas? --b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
