From owner-freebsd-hackers Wed Jan 21 17:03:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA20745 for hackers-outgoing; Wed, 21 Jan 1998 17:03:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA20734 for ; Wed, 21 Jan 1998 17:03:35 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id BAA05291; Thu, 22 Jan 1998 01:02:14 GMT Date: Thu, 22 Jan 1998 10:02:14 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: grog@lemis.com, FreeBSD Hackers Subject: Re: Locking on disk slice I/O--yes, no or how? In-Reply-To: <199801212329.QAA12160@usr09.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk On Wed, 21 Jan 1998, Terry Lambert wrote: > Only if you have an intention collision would you resort to a TSM > call to resolve the collision. For the most part, it's non-blocking. TSM doesn't necessarily mean it's non-blocking. It just means that a vnode you're about to modify won't suddenly become a mbuf. Intent locking seems similar in this respect. Maybe I'm being a smartass, but since John said TSM instead of NBS it leaves it open to speculation a wee bit. Things sure are getting interesting in current! Regards, Mike -- michaelh@cet.co.jp http://www.cet.co.jp CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku, Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766