From owner-freebsd-arch Wed Feb 20 2:18:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id AA72937B400 for ; Wed, 20 Feb 2002 02:18:33 -0800 (PST) Received: from pool0143.cvx22-bradley.dialup.earthlink.net ([209.179.198.143] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16dTpY-0003wv-00; Wed, 20 Feb 2002 02:18:32 -0800 Message-ID: <3C7377EE.5E151D84@mindspring.com> Date: Wed, 20 Feb 2002 02:18:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Roberson Cc: arch@freebsd.org Subject: Re: vnode issues & shared lock patch References: <20020219202000.M38875-100000@mail.chesapeake.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jeff Roberson wrote: > I also have a patch which allows users of the namei interface to request > shared locks on leafs. This has been running in all of our kernels for 6 > months without a deadlock. I have only modified stat and open to take > advantage of this capability. The problem we were having is that an > application would stat a file that had 60 seconds or so worth of IO > pending, and it would block until that IO was finished because namei > always grabs exclusive locks. > > The patch looks a little messy due to the inconsistencies in locking > around the system. I have to do extra checking since I do upgrades and > downgrades and the VOP calls don't always return vnodes in the advertised > lock state. This is a good example of the problems generalized above. It > is really a temporary fix for more serious problems that need to be > addressed. Other than some unnecessary whit space changes in namei.h, this looks like good code. My personal preference would be for SIX locks, which should be significantly more concurrent than SX locks in the create and delete cases, but signalling intent might be enough harder that it would take much more of an impact. This is probably the best compromise for testing purposes. I'm curious what happens if you are, for example, untar'ring a ports tree, and you rm -rf it a couple of times during the process. I would expect perhaps a panic in the cache code (does a name cache entry need to act as a shared reference?) -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message