From owner-freebsd-hackers Tue Mar 3 16:03:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23226 for freebsd-hackers-outgoing; Tue, 3 Mar 1998 16:03:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA23139 for ; Tue, 3 Mar 1998 16:03:02 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 19957 invoked by uid 1000); 4 Mar 1998 00:09:52 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-021598 [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: <199803032144.WAA03955@yedi.iaf.nl> Date: Tue, 03 Mar 1998 16:09:52 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Wilko Bulte Subject: Re: SCSI Bus redundancy... Cc: hackers@FreeBSD.ORG, (Julian Elischer) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Mar-98 Wilko Bulte wrote: ... > Once Upon A Time, When Power Supplies Were Still Powersupplies there were > 2 signals available: AC_OK and DC_OK. Whenever your logic (disk) saw > AC_OK negate, it was time to cleanup. After some time, dependent on how > big your powersupply capacitors were, how loaded the PS was etc you saw > DC_OK negate. Unless it is a DC/DC power supply :-) Yes, you are right, but the cost of two extra wires, two gates, a transistor, etc. is really too much. ... > Drive write caches are Evil. Every write cache without good battery > backup > is Evil. Talk to a DBMS guy about enabling disk write caches. Put > sneakers > on and be prepared to run fast... Nah, we just smile at you and put your reume in the can... Actually, there are ways around that. I promised to make them available on FreeBSD and I will. Real Soon Now. I am waiting for hardware for testing... > But then again, with VM systems that have megabytes worth of unflushed > data the best way to loose your data is to pull the plug from your server > ;-) Top said, on last make world that there are 158MB of buffers in use. This is 5 times the total disk capacity on the first Unix port I tried to compile. Scary. Terry? Any thoughts on hot-starting a Unix based PC? We need to dump memory quickly, I think. No way to preserve DRAM across BIOS resets I know of. Assuming we have the ability to dump memory quickly (see below), can we just snap a state, dump it, leave a signature and resume at power up? We had that on VAXes with VMS (Not AT&T Unix, and I do not think BSD). Memory SNAP: If you write it into a DPT controller, and the controller has enough cache to hold it, it is pretty fast. I can sustain about 2us per transaction overhead and about 120MB/Sec. This gives us about a second or two. The new DPT's can retain the cache until power returns. Even a small UPS (with poer alarms will last long enough. ---------- 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