Date: Sat, 5 May 2001 22:51:23 -0600 (MDT) From: Doug Russell <drussell@saturn-tech.com> To: freebsd-stable <freebsd-stable@FreeBSD.ORG> Subject: Re: soft update should be default Message-ID: <Pine.BSF.4.21.0105052233360.96450-100000@beastie.saturn-tech.com> In-Reply-To: <00b601c0d5bd$42ba1340$0901a8c0@haym.transactionsite.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 May 2001, Jan Mikkelsen wrote: > Good write speed is possible without using write cache by using tagged > command queueing. Have you measured tagged command queueing vs. write cache > for write speed on your SCSI drives? I get about the same (~23MB/sec) on an > IBM DLTA-307030 Ultra ATA drive (tags/no WC vs. no tags/WC). With neither > option, it is terrible, of course. I've found that the performance depends mainly on the overall design of the drive itself. (Well, duh, right? :) ) On many applications, performance shouldn't be significantly faster with the cache enabled. For example, out of my 4GB UW drives, one might think from quick testing that the two stupid Micropolis Tomahawks I have are reasonably quick drives. This may well be because they always do some kind of bogus write caching, even when supposedly disabled, as these drives are great examples of ones that don't actually support the FORMAT UNIT `command. They just accept the command, wait about 45 seconds with the light on, then return the command as completed without error. However, if you start comparison testing at all, you realize how surprisingly dumb they really are. I rarely WCE any of my Seagate ST15150Ws, and I don't ever recall seeing a significant increase in speed on any application I've used them for. I've enabled the WCE when doing some video editing, etc. but I've always actually been constrained by some other bottleneck, not the actual speed the data was blasting to the platters. (Besides, on applications like this a write cache won't help much... Multiple heavy access, maybe, but if the OS is doing reasonable buffering, it should be able to do as good (if not better) a job of getting the data to the drive in the correct (desired) order. At least with a SCSI drive, anyway.... Consider block X, which the OS is waiting to write. Block X is then modified again. If block X were written to the drive right away, WCE or not, we still have to send that block all the way to the disk, then write it again. If the first block X was still dirty in the cache when the second write came, hopefully the drive is smart enough just to update what should be written to block X (if WCE is enabled), but not necessarily. On the other hand, if the OS only writes block X out once, because it knew it had changed before it decided it should be written to disk (hopefully because it was passing by anyway). IDE disks will show a larger performance boost with WCE because they usually can't write a continuous stream of data to the disk without wasting at least part of a rotation due to the small maximum transfer sizes and huge cylinders. They attempt to interleave these drives correctly, but with such a huge variety of possible applications these days, I have a feeling it doesn't really work very well. I'd still argue that your data is basically just as unsafe all the time on one of these drives, when not battery backed, regardless of whether softupdates is enabled. Of course, I also do nasty things to my IDE disks like unmount them, turn the power off via the key on a cheap-o removable chassis, then yank them out, swap them around, etc. FreeBSD isn't supposed to have hot-swap IDE support, but if a drive was detected at boot, it works. :) Soren's ATA driver is much more well behaved than the old WD driver about such things, also. :) Warning! Warning! Not a recommended procedure! Know what you are doing if you try anything like this, and disable the W/C. Warning! Warning! Not a recommended procedure! See? I must be crazy. :) > The question is how much performance the write ordering constraints in the > softupdates protocol removes. I have no idea, and I'm sure it would depend > on all sorts of stuff. Hopefully, aggregate throughput would be high, even > if individual operations were slow. The problem is that all of this depends on all sorts of stuff. I just wish more people knew what was really going on in their system. :) sync && sync && sync && sync..... <Doug> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0105052233360.96450-100000>