Date: Fri, 25 May 2001 20:59:09 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: hackers@freebsd.org Subject: Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE Message-ID: <200105252059.NAA13350@usr06.primenet.com>
next in thread | raw e-mail | index | archive | help
] That mood is nice in theory, but doesn't seem to fit practice. My boxes ] are on UPSes, and I have trouble remembering the last time the power went ] out. On the other hand, I can clearly remember the last panic ] on my -current box which required a manual fsck to repair (yesterday). ] And yes, write caching was disabled on the box at the time. It seems to ] me that we're assuming hardware write caching is some evil villan which ] will steal our data without any evidence. At the same time, we're putting ] blind trust in filesystems to always DTRT. Software is provable. If the hardware were not trying to get marketing benchmarks, or if people were willing to live within the constraints that their hardware is subject to, instead of pushing it past the limits of safety, then it wouldn't be a problem. For example, SCSI drives do not have this serialization problem when write caching is disabled, since they support the idea of permitting multiple outstanding operations simultanemously (i.e. tagged command queuing). Apparently, some modern (IBM supplied) IDE drives appear to be capable of supporting this as well. It's nice that the IDE manufacturers have finally gotten around to conforming to their own design specification, after a decade. ] And stuck in the middle is a growing number of people who are seeing a ] noticeable slowdown with 4.3, and will start telling their friends that ] FreeBSD is slow. So add an option to sysinstall called: "Fast and at least as reliable as Linux" and let them find out for themselves that that means that it's really dangerous, and that after a crash for whatever reason (e.g. your panic crash, or a power failure for anyone without a UPS in California), they will have to manuall fsck, whereas without the write caching, it wouldn't have been a problem. NB: Write caching isn't a problem: it's the drive lying out its arse and telling us that the write was committed to stable storage, when in fact it was only cached, which is the problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200105252059.NAA13350>