Date: Sat, 20 Feb 1999 22:42:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday Message-ID: <199902202242.PAA19576@usr08.primenet.com> In-Reply-To: <199902202056.MAA11068@apollo.backplane.com> from "Matthew Dillon" at Feb 20, 99 12:56:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> There isn't much we can do except to try to fix the lock cascade that > occurs in namei and lookup. The problem is that the lower level vnode > is locked before the parent vnode is released. That's on purpose. > What if we simply bumped the vnode's v_holdcnt or v_usecount in lookup > instead of lock it, and then have the parent namei unlock the parent vnode > prior to gaining a lock on the new vnode in its loop? This would open the race window the lock order is designed to prevent. You really need to look at the relookup code for the rename case to see why doing this is a really bad idea. > This would limit the locking cascade to one vnode worst case. We would > have to allow the bumping up and down of v_usecount by independant > processes while an exclusive lock is held on it. If you have access to a Solaris box, look in vnode.h, specifically at the HOLD and RELE macros. I don't think a hold is enough. I think the way to "fix" this is to have two queue insertion points, and insert directory writes as far forward as you can (some pigs are more equal than others). This would ensure short duration for directory operations. The second insertion point would be tracking the back-most directory write operation; typically, this would be the head of the queue, or serveral directory writes back from the head of the queue. Basically, you still do async, but vnode spanning operations get to "butt in line". I think you should include cross directory rename of files or directories, and simple renaming of directories in this list, as well as subdirectory deletions. You might also find an interaction with vfs.ffs.doasyncfree under pessimal conditions, on non-async mounted disks, FWIW. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902202242.PAA19576>