From owner-freebsd-hackers Mon Mar 9 15:28:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA28525 for freebsd-hackers-outgoing; Mon, 9 Mar 1998 15:28:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fddi.Simon-Shapiro.ORG [206.190.148.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA28391 for ; Mon, 9 Mar 1998 15:27:49 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 29852 invoked by uid 1000); 9 Mar 1998 23:29:05 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-030698 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199803092301.QAA04865@usr08.primenet.com> Date: Mon, 09 Mar 1998 15:29:05 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Terry Lambert Subject: Re: SCSI Bus redundancy... Cc: lada@ws2301.gud.siemens.co.at, hackers@FreeBSD.ORG, julian@whistle.com, wilko@yedi.iaf.nl, dmlb@ragnet.demon.co.uk, lada@ws2301.gud.siemens.at Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Mar-98 Terry Lambert wrote: ... > This is a salient point. The ISP's who are interested in the HA > aspects of such servers are more interested because of interruption > of service issues, more than they are concerned with data-vaulting. Sure. Clustering correctly, around a resilient and independant disk array will accomplish both. Each takes out of it what they want (service non-interruption, data integrity, or both) > I'm personally more concerned with being able to lock down the gears > into a known-to-the-OS state, at all times. I can deal with rolling > incomplete transactions back seperately, if I need transactions. Please elaborate (your metaphore brings images of broken gears in my lathe :-) > The disk write cache is problematic. Most modern disks, when they lose > DC, do *not* flush the dirty portion of their write cache. Because the > cache is permitted to reorder operations without regard to their OS > dependency order, this means that a write cache that's not written > completely potentially damages dependency ordered data that the OS > believes has been written. a. A good controller will allow you to selectively tune the cache, to the disk's abilities. b. A good controller will force caches on the attacjed drives to flush before it ACKs the shutdown command from the O/S. b. A UPS that will keep the disks running long enough for that. Any descent disk cabinet/shelf/bay has redundant power supplies, either 2N, or N+1. > Dependency ordered data like that created by DOW or Soft Updates > technologies. This becomes even more important when considering clustering filesystems. >From data resilence point of view, it is not as important. See above. > With disk write caching turned on, I still need a UPS to be able to > do this reliably, since I have to (1) not add more work to the write > cache which might potentially push out already delayed writes, and > (2) cause the disk to flush it's write cache. A reasonable UPS for a pc, is less than $100.00. > High availability can also mean "comes back up quickly, and is robust > in the face of deleterious conditions". True. To some it means ``I have backup on tape someplace in the drawer'', to others it means ``I never loose an e-mail message'', while some say ``I cannot lose service for more than N seconds''. I think we should try and serve them all. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message