From owner-freebsd-current Mon Jun 28 13:38:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 25F9F15157 for ; Mon, 28 Jun 1999 13:38:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA24584; Mon, 28 Jun 1999 13:38:07 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 13:38:07 -0700 (PDT) From: Matthew Dillon Message-Id: <199906282038.NAA24584@apollo.backplane.com> To: Kirk McKusick Cc: Peter Wemm , Julian Elischer , Alan Cox , Mike Smith , "John S. Dyson" , dg@root.com, dyson@iquest.net, current@freebsd.org, Greg Lehey Subject: Re: Found the startup panic - ccd ( patch included ) References: <199906281559.IAA02733@flamingo.McKusick.COM> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :You are right that the buffer cache is very tricky. It is hard to :change it in ways that preserves functionality and performance. :The port of my buffer locking code from BSD/OS has caused problems :largely because of a different buffer cache implementation and :especially SMP models between the two systems (BSD/OS has no spl's :for example). However, this is not a half baked idea that I have :come up with and thrown in without thinking. Recursive locking is :*required* to get stacking filesystems like union and loopback :working reliably. As they currently stand they are full of code to :try and track locks at layers all up and down the stack. This code :is really nasty and in many cases broken (leading to deadlocks or :crashes). The snapshot code also is most easily implemented with :recursive locking, the alternative being to put lock monitoring :all through bmap and block allocation code. So yes, it would be :wonderful if the world could be simple, and I am not a huge fan of :the complexity of the buffer locking code. But, I have considered :the alternatives and they are worse. : : Kirk Wow! Timeout! Miscommunication. I am talking strictly about struct buf locking. I understand and agree completely that recursive locking is absolutely necessary for the VFS layering! I am not throwing your work out - precisely the opposite, I want to keep your work pretty much as is except for two things: (1) I want to replace lockmgr locks ( and I don't mind implementing recursive exclusive locking in the replacement, though I would rather avoid it! ), and (2) I want to find a better way to implement the BUF_KERNPROC() stuff... basically I want to try to find a way to localize the necessary effect in one place in the code rather then have the BUF_KERNPROC() macros strewn all over the code. Same effect, slightly different code organization, that's all. There must be a choke point somewhere where we can put the code. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message