From owner-freebsd-fs Thu Sep 21 13:50:50 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id E131737B42C; Thu, 21 Sep 2000 13:50:41 -0700 (PDT) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id NAA14670; Thu, 21 Sep 2000 13:49:16 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAA04aayC; Thu Sep 21 13:49:00 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA16305; Thu, 21 Sep 2000 13:50:21 -0700 (MST) From: Terry Lambert Message-Id: <200009212050.NAA16305@usr08.primenet.com> Subject: Re: disable write caching with softupdates? To: mbendiks@eunet.no (Marius Bendiksen) Date: Thu, 21 Sep 2000 20:50:21 +0000 (GMT) Cc: Stephen.Byan@quantum.com (Stephen Byan), fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG ('freeBSD-scsi@freeBSD.org') In-Reply-To: from "Marius Bendiksen" at Sep 21, 2000 06:05:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. This is avaialble in the SCSI 2 standard, on all conforming drives. > 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. Most modern disks will always track-cache, since they write sectors in reverse order. For read operations, immediately following a seek, they start reading into cache at wherever the head is on the disk, and buffer that until they hit the requested data. The result is that sequential data is already loaded into the cache by the time that the next read goes to the drive. Right about now, someone should nudge Rod Grimes to get into this discussion, since he has played with some of this type of disk optimization. Now that it's under a microscope again, it might also be time to consider his spindle-sync work, as well as other stuff that's more hardware dependent. 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