Date: Thu, 21 Sep 2000 18:05:30 +0200 (CEST) From: Marius Bendiksen <mbendiks@eunet.no> To: 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: <Pine.BSF.4.05.10009211758070.39384-100000@login-1.eunet.no> In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D4@shrcmsg1.tdh.qntm.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. I agree on this. But I think people would step forth to fix these assumptions in FFS, in time, if disks started reporting real geometry. In either case, I think you would still be likely to get _some_ boost. Layout logic should either be entirely in the FS or entirely in the disk. > 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. Many of these parameters can be adapted to in software, if the firmware will expose the required data. > 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. Okay. In this case, my information has been incorrect, and I apologize. > 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. I agree that minimizing rotational cost by caching a single track is good, if the drive can guarantee the integrity of the data, possibly by providing an NVRAM buffer for the track. Marius 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?Pine.BSF.4.05.10009211758070.39384-100000>