Date: Thu, 21 Sep 2000 20:38:37 +0000 (GMT)
From: Terry Lambert <tlambert@primenet.com>
To: Stephen.Byan@quantum.com (Stephen Byan)
Cc: mbendiks@eunet.no ('Marius Bendiksen'), Stephen.Byan@quantum.com (Stephen Byan), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG ('freeBSD-scsi@freeBSD.org')
Subject: Re: disable write caching with softupdates?
Message-ID: <200009212038.NAA15997@usr08.primenet.com>
In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D4@shrcmsg1.tdh.qntm.com> from "Stephen Byan" at Sep 21, 2000 06:40:24 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> The problem with exposing the disk geometry is that FFS makes assumptions > about the geometry that are false. FFS is wrong, here. > Disks are zoned, so there aren't a constant number of sectors per track. Due > to defects, the number of sectors per zone varies from sample to sample. > It's possible that each surface in the drive has a different number of > cylinders. In future disk generations, the geometry may get warped in > unpredictable ways. Mode page 2. Yes, this will leave IDE drives out in the cold, but let them grow a mode page 2, or suffer the consequences. > Moreover, to take advantage of the geometry, the file system needs an > accurate access time model. The constants in this model may vary from sample > to sample of the same type of drive, and may vary due to environment > conditions like temperature and power supply voltage. (Many of the access > time optimization algorithms in the drives do in fact adapt to these > variations.) The characteristics of the model vary widely between different > designs of drives. Mostly, all it needs to know whether rotational latency is significantly lower than seek latency, which it is. > So it's hard to envision a standard way of expressing the actual drive > geometry and access time model to the file system. You don't need to be accurate, as much as you need to be correct, and in the ballpark on rotational vs. seek latencies. > > As I recall, and from what Eivind noted, this bit is > > routinely ignored in > > about 90% of all drives out there. > > If you are referring to the SCSI FUA bit, this is absolutely untrue. All > Quantum SCSI drives obey this bit. All currently-manufactured drives obey > this bit. I believe 99% of the drives that claim compliance with the SCSI > SBC spec do in fact obey the FUA bit on writes. There was a recent case > where one manufacturer appears to have cheated and ignored this bit, and > caught quite a bit of abuse for it. Like lost business from major OEMs. > > If you are referring to the flush cache command for ATA drives, you may have > a point. For ATA drives, earlier versions of the ATA spec did not specify a > way to flush the cache. The ATA driver in Windows NT appears to have > implemented one vendor's vendor-unique command to flush the cache, which is > not widely-supported and which has been superceded by a standard "flush > cache" command in the newer versions of the ATA specification. These guys were talking about ATA drives, which ignore the bit. Most SCSI drives, as you point out, do not. And this is a heck of a lot better approach than flushing the cache via an explicit instruction. The SCSI stuff can be handled with a "known rogues" list, but the ATA stuff is pretty much unhandleable at this point. 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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009212038.NAA15997>