On Sun, 2007-12-30 at 20:18 +0100, Andi Kleen wrote: > > The only problem I can see from an NFS perspective is with NFSv2/v3 > > locking: unfortunately the protocol provides no way for the server to > > notify that a lock may not be granted after the client has been told to > > block. You would therefore have to bend the protocol rules by simply > > delaying replying to the client until the deadlock timeout occurred > > instead of telling it to block. I'm not sure that all clients would be > > able to cope... > > If the delay is short enough (let's say < 2 jiffies) that should be surely no > problem? > If they couldn't deal with that they couldn't deal with a congested network > either. > > Otherwise lockd could just force a 0 timeout.
A short timeout should be OK, but that would presumably defeat the purpose of the delay (2 jiffies is not a long time if you have a lot of processes contending for the cpu). Otherwise, I agree: we could just default to the current scheme for the special case of lockd. Cheers Trond - 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
