Date: Mon, 09 Mar 1998 22:52:10 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Terry Lambert <tlambert@primenet.com> Cc: hackers@FreeBSD.ORG Subject: RE: Fault tolerance issues Message-ID: <XFMail.980309225210.shimon@simon-shapiro.org> In-Reply-To: <199803100439.VAA27415@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-Mar-98 Terry Lambert wrote: >> > 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 >> :-) > > I want to make it so that if the power fails, if you have soft updates, > you don't need to clean your disk. > > If you shutdown normally, or panic, the uncommited writes get flushed > from the disk cache by the disk (because it doesn't know from reset > in the time it takes to panic or crash). There are hardware features in place today to take care of this problem during normal shutdown. Panics are no-man's land. A disk driver (ide, SCSI HBA, etc.) Should make an ``at_shutdown'' call which will make sure the driver is called when... the system shuts down. I belive Julian had something to do with this feature. I added it to the DPT driver; In addition to a megabyte or so on every disk, we can have 64MB of cache on the controller. Resetting at the wrong time gets very ugly very quickly, and soft update are of no use at all. Also, the current SCSI management code will ALLOW MEDIA RMOVAL on the last close on a device, which will force most descent HBAs to flush caches and arrange for the same with their disks. > Part of this would include implementing "soft read-only" to go with > the soft updates. > > In soft read-only, if there is nothing in the syncer queue when a > sync occurs, you mark the fs "soft read-only", set the clean flag > in the superblock, and write the superblock out. > > The marking tells you that you can write to the FS, but only after > you have unset the clean flag. > > Basically, if a BSD system is idle, you would be able to pull the > DOS-weenie trick of just turning it off, and no matter how large > the disk, the thing will come back clean. I always wondered why this is not so. Not even after sync(2). > This is incidently why the movement of the R/O handling code that > happened a while back was a bad thing. > > >> 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. > > The second 'b' is a 'c', right? 8-). Picky, picky... > The thing is that I don't want to use a UPS. I do not want to use hardware at all :-) The best computer is a cuamber in a shoe box; Simple, no moving parts, easy to replace, easy to tell if bad and good for the diet. Seriously, hardware can simplify life a lot. It is a matter of cost. Most people will accept that their $3,000 computer has to be protected by a $75 UPS. >> > 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. > > What if I were, say, building an appliance-type device? 8-) 8-). Sure. How much do you sell this apliance for? Better, how valuable is the integrity of this apliance? UPSs tend to protect computers from things sodtware does not (spikes, glitches, brown-outs, etc.). ... > Yes. I'm thinking of the middle ground, where there isn't a UPS, > and you want the OS to be happy in event of a sudden power loss, > whether it somes from the user flipping a switch, or it comes from > a line outage. You can advance this idea only so far. And for what cost? Software has bugs. What is the uptime ratio between these software modifications described here and a UPS? Even if YOU write ALL this code :-) I think that software solutions to problems like this are great, as long as they still allow for hardware solutions to augment/complement them. ---------- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980309225210.shimon>