From owner-cvs-src@FreeBSD.ORG Sat Jun 11 03:49:30 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C169516A41C; Sat, 11 Jun 2005 03:49:30 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9784943D48; Sat, 11 Jun 2005 03:49:30 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 722505C9A8; Fri, 10 Jun 2005 20:49:30 -0700 (PDT) Date: Fri, 10 Jun 2005 20:49:30 -0700 From: Alfred Perlstein To: Brian Feldman Message-ID: <20050611034930.GY17867@elvis.mu.org> References: <200506102350.j5ANofFM008212@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506102350.j5ANofFM008212@repoman.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/nfsclient nfs_bio.c nfs_vfsops.c nfsargs.h nfsmount.h src/sys/sys buf.h bufobj.h src/sys/kern vfs_bio.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 03:49:30 -0000 Returning EAGAIN from a disk IO seems bogus, are you sure it makes sense to do that when IO_NDELAY is set? Shouldn't it just be ignored like other FSes do? * Brian Feldman [050610 16:50] wrote: > green 2005-06-10 23:50:41 UTC > > FreeBSD src repository > > Modified files: > sys/nfsclient nfs_bio.c nfs_vfsops.c nfsargs.h > nfsmount.h > sys/sys buf.h bufobj.h > sys/kern vfs_bio.c > Log: > Fix a serious deadlock with the NFS client. Given a large enough > atomic write request, it can fill the buffer cache with the entirety > of that write in order to handle retries. However, it never drops > the vnode lock, or else it wouldn't be atomic, so it ends up waiting > indefinitely for more buf memory that cannot be gotten as it has it > all, and it waits in an uncancellable state. > > To fix this, hibufspace is exported and scaled to a reasonable > fraction. This is used as the limit of how much of an atomic write > request by the NFS client will be handled asynchronously. If the > request is larger than this, it will be turned into a synchronous > request which won't deadlock the system. It's possible this value is > far off from what is required by some, so it shall be tunable as soon > as mount_nfs(8) learns of the new field. > > The slowdown between an asynchronous and a synchronous write on NFS > appears to be on the order of 2x-4x. > > General nod by: gad > MFC after: 2 weeks > More testing: wes > PR: kern/79208 > > Revision Changes Path > 1.489 +1 -1 src/sys/kern/vfs_bio.c > 1.151 +65 -0 src/sys/nfsclient/nfs_bio.c > 1.177 +9 -0 src/sys/nfsclient/nfs_vfsops.c > 1.68 +2 -2 src/sys/nfsclient/nfsargs.h > 1.30 +1 -0 src/sys/nfsclient/nfsmount.h > 1.186 +1 -0 src/sys/sys/buf.h > 1.15 +2 -2 src/sys/sys/bufobj.h -- - Alfred Perlstein - email: bright@mu.org cell: 408-480-4684