Date: Wed, 20 Feb 2002 02:18:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org Subject: Re: vnode issues & shared lock patch Message-ID: <3C7377EE.5E151D84@mindspring.com> References: <20020219202000.M38875-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C7377EE.5E151D84>