Date: Thu, 21 Sep 2000 06:40:24 -0700 From: Stephen Byan <Stephen.Byan@quantum.com> To: "'Marius Bendiksen'" <mbendiks@eunet.no>, Stephen Byan <Stephen.Byan@quantum.com> Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG, "'freeBSD-scsi@freeBSD.org'" <freeBSD-scsi@FreeBSD.ORG> Subject: RE: disable write caching with softupdates? Message-ID: <8133266FE373D11190CD00805FA768BF055BD1D4@shrcmsg1.tdh.qntm.com>
next in thread | raw e-mail | index | archive | help
Marius Bendiksen [mailto:mbendiks@eunet.no] wrote: > > Wouldn't it be acceptable to mark the meta-data writes as > non-cacheable > > (i.e. write though to the media before signalling > completion), and let the > > remaining writes (user data writes) be cacheable? I think > this would improve > > the performance of the file system. > > Actually, performance-wise, you'd probably want to know the > real geometry, > given all the stuff FFS does to exploit it. I think this is a separate issue, but: The problem with exposing the disk geometry is that FFS makes assumptions about the geometry that are false. 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. 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. So it's hard to envision a standard way of expressing the actual drive geometry and access time model to the file system. > > SCSI has supported this for years, in the form of the FUA > bit in the CDB for > > the write command. Somewhat similar behavior can be had in > the newer flavors > > 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. > > of ATA by issuing a "flush cache" command after each > meta-data write, and > > waiting until the flush command completes before signalling > the completion > > of the non-cacheable write. > > This has the potential for degrading performance even > further. I think you > would prefer to disable cache over this. I agree, flushing the write cache could be painful. I don't see how it could be much worse than disabling the cache, since the disk's write cache is not lazily written, and so does not usually have much dirty data. Without write caching, you pay one disk rotation for each sequential write. In workloads with a moderate to high sequential write component, this is an extreme penalty. Also, with caching enabled, the disk does a fair amount of reordering to optimize the total seek and rotational cost of the writes. You give this up when disabling the write cache. Regards, -Steve Steve Byan <stephen.byan@quantum.com> Design Engineer MS 1-3/E23 333 South Street Shrewsbury, MA 01545 (508)770-3414 fax: (508)770-2604 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?8133266FE373D11190CD00805FA768BF055BD1D4>