From owner-freebsd-scsi Thu Sep 21 12:38: 9 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-115.dsl.snfc21.pacbell.net [63.202.177.115]) by hub.freebsd.org (Postfix) with ESMTP id A247137B43C for ; Thu, 21 Sep 2000 12:38:06 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id MAA01391; Thu, 21 Sep 2000 12:38:52 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009211938.MAA01391@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-reply-to: Your message of "Thu, 21 Sep 2000 11:31:51 MDT." <200009211730.LAA42240@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 2000 12:38:52 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> > That's the price of having a recoverable file system. See Seltzer, Ganger, > >> > >> Not necessarily. > > > > Er, you're being both contrary and plain wrong. It's a fundamental > > assumption of the softupdates implementation that it is possible to issue > > an ordered write and have it complete in an ordered fashion. > > Softupdates guarantees write ordering by batching writes that have the > same ordering dependency and postponing the writes that depend on queued > writes until those writes complete. This is not the same as relying on > the ability to queue writes in a particular order. The assumption that > softupdates does make, however, is that a write that completes is committed > to media. That's correct, and it's an implementation bug, albeit one that is difficult to work around. (Consider the case where you have a storage device that reorders requests, has a large buffer and performs write-back caching.) I tend to concur with Kirk's opinion that if you want to perform this sort of decoupling, either you make it nonvolatile or you accept that shooting between your feet gives you a nonzero chance of taking off a toe every now and then. 8) > >> Actually, performance-wise, you'd probably want to know the real geometry, > >> given all the stuff FFS does to exploit it. > > > > Since a) drives don't have 'real' geometries, and haven't for the last > > half of the last decade at least, and b) we intentionally disable most of > > these optimisations because they're founded on assumptions that stopped > > being relevant a good five years before *that*... no, you don't care > > about the drive's geometry at all. > > There was a talk (I don't think it was a full blown paper) at a USENIX > a few years ago that showed that you could approximate the behavior > of modern disks using a liniar model. The speaker also showed some > simulated performance improvements by using the model. Can I assume you mean "linear" here, ie. that you can model a disk's performance based on a more or less linear progression from "slow" at one extreme to "fast" at the other? (I can see how some of the fixed delays eg. settling time, rotational latency, etc. factor out, so this makes sense.) Thanks. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message