From owner-freebsd-hackers Mon Aug 23 17:59:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from m4.c2.telstra-mm.net.au (m4.c2.telstra-mm.net.au [24.192.3.19]) by hub.freebsd.org (Postfix) with ESMTP id CE9B51500C for ; Mon, 23 Aug 1999 17:59:44 -0700 (PDT) (envelope-from a.reilly@lake.com.au) Received: from m5.c2.telstra-mm.net.au (m5.c2.telstra-mm.net.au [24.192.3.20]) by m4.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA28450 for ; Tue, 24 Aug 1999 10:59:36 +1000 (EST) X-BPC-Relay-Envelope-From: a.reilly@lake.com.au X-BPC-Relay-Envelope-To: X-BPC-Relay-Sender-Host: m5.c2.telstra-mm.net.au [24.192.3.20] X-BPC-Relay-Info: Message delivered directly. Received: from areilly.bpc-users.org (CPE-24-192-49-170.nsw.bigpond.net.au [24.192.49.170]) by m5.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA00583 for ; Tue, 24 Aug 1999 10:59:34 +1000 (EST) Received: (qmail 84417 invoked by uid 1000); 24 Aug 1999 00:59:34 -0000 From: "Andrew Reilly" Date: Tue, 24 Aug 1999 10:59:34 +1000 To: Greg Lehey Cc: Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? Message-ID: <19990824105934.A82973@gurney.reilly.home> References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990823174345.J83273@freebie.lemis.com>; from Greg Lehey on Mon, Aug 23, 1999 at 05:43:45PM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Greg, hackers list, I don't want to express an opinion about the need or otherwise for mandatory locking, but I would appreciate a teensy clarification of the problem domain: On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: > To write a block to a RAID-5 device, you need to: > > 1. Read the old data into a temporary buffer. > 2. Read the old parity data corresponding to the data into a > temporary buffer. > 3. XOR the two, storing the result in one of the temporary buffers. > 4. XOR the result with the data which is to be written. > 5. Write the data block. > 6. Write the parity block. Are you suggesting that random user processes have to do all of this every time that they access a vinum drive? I thought that access was mediated by a driver or server process. Isn't this process in a position to ensure the integrity of the transaction without any help from locking mechanisms? If some major maintenance utility needs to run on the raw device, during which time the state is inconsistent as far as user processes are concerned, isn't it sufficient to remove their read priveliges? Sorry if these are dumb questions. I have had no experience at file system or data-base applications, but I do want to learn as much about them as I can. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message