From owner-freebsd-questions@FreeBSD.ORG Fri Mar 19 13:19:29 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2792B1065675; Fri, 19 Mar 2010 13:19:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ECA4B8FC14; Fri, 19 Mar 2010 13:19:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9A84246B1A; Fri, 19 Mar 2010 09:19:28 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D91F28A025; Fri, 19 Mar 2010 09:19:27 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Fri, 19 Mar 2010 08:31:00 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BA3613F.4070606@comcast.net> In-Reply-To: <4BA3613F.4070606@comcast.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003190831.00950.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 19 Mar 2010 09:19:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Steve Polyack , bseklecki@noc.cfi.pgh.pa.us, User Questions Subject: Re: FreeBSD NFS client goes into infinite retry loop X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 13:19:29 -0000 On Friday 19 March 2010 7:34:23 am Steve Polyack wrote: > Hi, we use a FreeBSD 8-STABLE (from shortly after release) system as an > NFS server to provide user home directories which get mounted across a > few machines (all 6.3-RELEASE). For the past few weeks we have been > running into problems where one particular client will go into an > infinite loop where it is repeatedly trying to write data which causes > the NFS server to return "reply ok 40 write ERROR: Input/output error > PRE: POST:". This retry loop can cause between 20mbps and 500mbps of > constant traffic on our network, depending on the size of the data > associated with the failed write. > > We spent some time on the issue and determined that something on one of > the clients is deleting a file as it is being written to by another NFS > client. We were able to enable the NFS lockmgr and use lockf(1) to fix > most of these conditions, and the frequency of this problem has dropped > from once a night to once a week. However, it's still a problem and we > can't necessarily force all of our users to "play nice" and use lockf/flock. > > Has anyone seen this before? No errors are being logged on the NFS > server itself, but the "Server Ret-Failed" counter begins to increase > rapidly whenever a client gets stuck in this infinite retry loop: > Server Ret-Failed > 224768961 > > I have a feeling that using NFS in such a matter may simply be prone to > such problems, but what confuses me is why the NFS client system is > infinitely retrying the write operation and causing itself so much grief. Yes, your feeling is correct. This sort of race is inherent to NFS if you do not use some sort of locking protocol to resolve the race. The infinite retries sound like a client-side issue. Have you been able to try a newer OS version on a client to see if it still causes the same behavior? -- John Baldwin