From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [RFC] Remove BKL from fs/locks.c Date: Sun, 30 Dec 2007 20:18:49 +0100 Message-ID: <20071230191849.GA2623@one.firstfloor.org> References: <20071230061615.GS11638@parisc-linux.org> <20071230130510.GA24756@infradead.org> <20071230145158.GU11638@parisc-linux.org> <1199040294.6962.21.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andi Kleen , Matthew Wilcox , Christoph Hellwig , linux-fsdevel@vger.kernel.org To: Trond Myklebust Return-path: Received: from one.firstfloor.org ([213.235.205.2]:54630 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752510AbXL3TRJ (ORCPT ); Sun, 30 Dec 2007 14:17:09 -0500 Content-Disposition: inline In-Reply-To: <1199040294.6962.21.camel@heimdal.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > 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. -Andi