From owner-freebsd-hackers Tue Mar 3 13:28:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10599 for freebsd-hackers-outgoing; Tue, 3 Mar 1998 13:28:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10458 for ; Tue, 3 Mar 1998 13:27:44 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id NAA17949; Tue, 3 Mar 1998 13:23:26 -0800 (PST) Message-Id: <199803032123.NAA17949@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Wilko Bulte , sbabkin@dcn.att.com, tlambert@primenet.com, jdn@acp.qiv.com, blkirk@float.eli.net, hackers@FreeBSD.ORG, grog@lemis.com (Greg Lehey) Subject: Re: SCSI Bus redundancy... In-reply-to: Your message of "Tue, 03 Mar 1998 12:14:51 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Mar 1998 13:23:24 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On 03-Mar-98 Wilko Bulte wrote: > ... > > > This is called the 'write hole' in the literature. The trick is to > > use battery backed cache not only for RAID5 (write)performance > > reasons, but also to keep the data until date AND parity have safely > > landed on the disks. > > I have seen an interesting solution some time ago; Instead of battery, the > spindle motor (on the disk) was used to generate the power needed to flush > the caches. then the motor leads will be clamped, and the spidle shut down > quickly (normal procedure nowdays). This was done on a 14" spindle that > had a bit more inertia than todays' disks. But the circuitry consumed more > power too. This is common practice on most modern disks; it dates from the days of autoparking stepper-motor units in that market. You don't get a guarantee that everything that you wrote to the cache on the disk will be flushed, just that the disk won't write half a block and trail off. Some do flush the cache, some will complete the current set of blocks, and some will process as much of the cache as they have power for. It seems to depend on the studliness of the firmware authors, and TBH given that most of this understanding comes from experimental rather than authoratative sources you are welcome to take your own interpretation. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message