From owner-freebsd-scsi Thu Sep 21 10: 9:22 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 05FFF37B423 for ; Thu, 21 Sep 2000 10:09:20 -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 KAA00784; Thu, 21 Sep 2000 10:10:06 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009211710.KAA00784@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Marius Bendiksen Cc: freeBSD-scsi@FreeBSD.ORG Subject: Re: disable write caching with softupdates? In-reply-to: Your message of "Thu, 21 Sep 2000 15:38:36 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Sep 2000 10:10:06 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > OK, I played a bit with that, the only info I can see I get from the > > > higher levels is the BIO_ORDERED bit, so I tried to flush the cache > > > each time I get one of those, _bad_ idea, 10% performance loss... > > > 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. > > Contrast this 10% performance hit versus what you get when you disable > > caching entirely. > > I think you will see that on some drives, this may have a greater > performance impact than not caching at all. I think that you should perform some objective research on this first. Note that the CAM subsystem already correctly honours BIO_ORDERED by using ordered tags. Also, in another message, you say: > 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. -- ... 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