From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mikael Davranche Subject: [PATCH 0/3] NLM: Proposal for a timeout setting on blocking locks Date: Tue, 11 Mar 2008 13:14:25 +0100 Message-ID: <1205237665.47d677a143941@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT To: Trond Myklebust , Trond Myklebust , linux-fsdevel Return-path: Received: from postfix1-g20.free.fr ([212.27.60.42]:49421 "EHLO postfix1-g20.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753323AbYCKMQK (ORCPT ); Tue, 11 Mar 2008 08:16:10 -0400 Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-g20.free.fr (Postfix) with ESMTP id CBF7623C47B1 for ; Tue, 11 Mar 2008 13:16:09 +0100 (CET) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, When a lock blocks, the server sends us a BLOCKED message. When it releases, it may sends us an NLM callback. When it does not (it depends on NLM implementations), the client waits for 30 seconds before attempting to reclaim the lock again. The 30 seconds time is hard-coded on fs/lockd/clntproc.c: #define NLMCLNT_POLL_TIMEOUT (30*HZ) 30 seconds is generally suitable, but in some cases, it is too much and it may be set to less than that. I have this problem in my production env ironment when an e-mail box receives more than 1 e-mail every 30 seconds. In that particular case, the nlm_blocked list grows up and never reduce s. Setting this time to less than 30 seconds resolves the problem. This short series of patches enables the set of this timeout, setting a new /proc entry named nlm_clnt_poll_timeout (this name is based on the NL MCLNT_POLL_TIMEOUT define). Patches are based on the 2.6.24.3 version (is that a problem? may I base them on the 2.6.25-rc5 one?). What do you think about this? Any comments are very welcome. Cheers, Mikael -- Mikael Davranche System Engineer Atos Worldline, France