From owner-freebsd-fs Thu Sep 21 9: 5:38 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 488DF37B422; Thu, 21 Sep 2000 09:05:33 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id SAA25878; Thu, 21 Sep 2000 18:05:31 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id SAA39435; Thu, 21 Sep 2000 18:05:31 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 21 Sep 2000 18:05:30 +0200 (CEST) From: Marius Bendiksen To: Stephen Byan Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG, "'freeBSD-scsi@freeBSD.org'" Subject: RE: disable write caching with softupdates? In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1D4@shrcmsg1.tdh.qntm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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