On Thu, Dec 07, 2006 at 09:30:43AM -0600, David Teigland wrote: > Some posix locks would be trivial to cancel and others would be hard. If > gfs_controld has not yet read the op from the kernel's send_list, then we > just remove the op and it never "goes out". After gfs_controld has taken > it and sent it, then it's had its effect and, as you reminded me, is > unreversible without introducing new complexity (like the provisional > locks which sound unpleasant).
Something like that may be necessary in the end anyway. The background: NFSv4 doesn't have lock grant callbacks. It only has a single lock call. You can set a "blocking" bit in that call, but all this does is tell the server "I intend continue polling for this lock, so if it becomes available, could you hold it a little while to give me a chance at it before anyone else?" That's just a hint, not a requirement. But if we don't take the hint, locking between clients with different polling strategies, or between remote clients and local users, may be dramatically unfair. The client also isn't required to poll for the lock again--it may stop without notice at any time. So we'd like to have a way to hold a lock on behalf of a client, without losing the ability to cancel the lock if the client goes away. Hence the provisional locks. For now, maybe we could settle for a solution that at least handles exclusive whole-file locking (for which an unlock is an adequate cancel), and leaves open the possibility of a more complete solution later. --b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
