From owner-freebsd-current Sat Sep 19 12:55:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA14505 for freebsd-current-outgoing; Sat, 19 Sep 1998 12:55:36 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA14499 for ; Sat, 19 Sep 1998 12:55:33 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id MAA15860; Sat, 19 Sep 1998 12:55:06 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd015842; Sat Sep 19 12:55:01 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id MAA11587; Sat, 19 Sep 1998 12:54:57 -0700 (MST) From: Terry Lambert Message-Id: <199809191954.MAA11587@usr02.primenet.com> Subject: Re: softupdates & fsck To: eivind@yes.no (Eivind Eklund) Date: Sat, 19 Sep 1998 19:54:57 +0000 (GMT) Cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, current@FreeBSD.ORG In-Reply-To: <19980919202409.40703@follo.net> from "Eivind Eklund" at Sep 19, 98 08:24:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > They do if you set their options correctly and insure a holdup > > time after power failure, during which you will not engage in > > scheduling new writes. > > Eh? Without an UPS, I can't do that. You only need a little notification. Like the time between AC fail and DC fail. > The problem is drives that don't honour the immediate-write flag, > returning before data is committed to disk anyway (done to get better > benchmarks). I think there also is some problems with drives that > will re-order requests no matter what constraints you give it :-( I don't think this is the case. The problem was only recently reported, and it's only misconfigured or crappy (IDE) drives that do this (if a SCSI drive does this, it should be fixable in mode page 2, I think). > BTW: I didn't mean that this applied in this particular case, just > that this may become a problem when soft updates become fsck-less. It's a serious problem, as serious as running your FS's mounted async. Oh... here's a thought -- is someone trying to combine "async" with "soft updates"? Soft updates had this problem originally because the sync(2) call didn't do the right thing (tick the sync soft clock wheel until it was empty) in the first pass at the soft updates code. Fixing this took a long time, and it *was* fixed. Unordered writes of async queued events are equivalent to async writes, and you know how I hate those. 8-(. 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-current" in the body of the message