From owner-freebsd-fs Sat Aug 8 10:49:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA05842 for freebsd-fs-outgoing; Sat, 8 Aug 1998 10:49:05 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA05837 for ; Sat, 8 Aug 1998 10:49:04 -0700 (PDT) (envelope-from dillon@backplane.com) Received: (dillon@localhost) by apollo.backplane.com (8.8.8/8.6.5) id KAA19458; Sat, 8 Aug 1998 10:48:43 -0700 (PDT) Date: Sat, 8 Aug 1998 10:48:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199808081748.KAA19458@apollo.backplane.com> To: Terry Lambert Cc: wollman@khavrinen.lcs.mit.edu (Garrett Wollman), freebsd-fs@FreeBSD.ORG Subject: Re: Filesystem locking during lookups Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, I've seen cascade crashes where locks are held all the way to root, but ultimately it comes down to a deadlock on some deep file or directory. But, again, it's doubtful that namei has anything to do with it. It's more likely to be a deadlock in the filesystem vs VM code. I changed Diablo's feeder code on my test machine to avoid appending to the history file on each write (instead, it appends a large block of zero's and then allocates history records out of the block). nntp3.ba.best.com has been the most stable it's been yet... up 9 days now. However, I am still seeing significant VM/fs corruption where the mmaping of files being actively appended to (in this case, the spool files) can cause physical corruption of the file. -Matt :> :> In 30 seconds, my machine made 1475 calls to namei, of which 209 were :> root-relative. Even with these changes, my machine still deadlocked :> last night (although it lasted longer than it did the night before), :> so I would say that there is a fair amount of filesystem contention :> going on. : :Are you running soft updates? : :I have a *very* hard time believing that the lock is being held :all the way up to root, intentionally. There's simply no code :to actually reverse traverse freeing the locks. : :Perhaps locked vnodes are being cached with the lock held in some :way? : :Is your news spool mounted right off of root? : : :I'm also very interested in your root vs. relative path count; can you :say what the single largest culprit for this is? Is there a single :largest culprit responsible for absolute path lookup? : : : Terry Lambert : terry@lambert.org :--- :Any opinions in this posting are my own and not those of my present :or previous employers. : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message