On Wed, Dec 06, 2006 at 05:00:29PM -0500, J. Bruce Fields wrote: > On Wed, Dec 06, 2006 at 03:42:31PM -0600, David Teigland wrote: > > Oh yeah, that's painful, I knew it sounded too easy. > > Yeah. Well, we could try to teach GFS2 to reliably cancel posix locks. > I think that may turn out to be necessary some day anyway. 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). In practice, I don't know how likely we are to find ops that haven't been sent yet--the easy ones to cancel. > Or we could look at why we're timing out and figure out whether there's > something else we should be doing instead in that case. In what > situations is the GFS2 lock call likely to take overly long? Again, in practice, I really don't know how long a sent lock could be delayed. When everything is running normally the only delay is between sending the message (through the openais comms api) and receiving it back again (which is when we grant it). So, for us it's completely depedent on how long the delivery of messages could be delayed by openais due to openais dealing with configuration changes in the cluster. Dave - 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
