From owner-freebsd-fs Sun Mar 24 6:32:20 2002 Delivered-To: freebsd-fs@freebsd.org Received: from prometheus.vh.laserfence.net (prometheus.laserfence.net [196.44.73.116]) by hub.freebsd.org (Postfix) with ESMTP id 4FEF637B41A; Sun, 24 Mar 2002 06:32:07 -0800 (PST) Received: from phoenix.vh.laserfence.net ([192.168.0.10]) by prometheus.vh.laserfence.net with esmtp (Exim 3.34 #1) id 16p92C-00004e-00; Sun, 24 Mar 2002 16:31:48 +0200 Date: Sun, 24 Mar 2002 16:31:48 +0200 (SAST) From: Willie Viljoen X-X-Sender: will@phoenix.vh.laserfence.net To: Robert Watson Cc: Terry Lambert , , Subject: Re: Soft update instability with heavy IO and offboard IDE controller In-Reply-To: Message-ID: <20020324162943.L307-100000@phoenix.vh.laserfence.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well yes, there was a panic and reboot without power loss... the system first starts exhiting odd behavour, one of the error messages I've seen is similar to free inode /usr/197492 had 28 blocks After a while, the kernel panics and attempts to sync disks, and usually gives up on several buffers. This isn't normal, I think, but the problem seems to dissapear when I turn off write caching. Once I have the time (and some extra cash) to experiment, I might try a few different IDE controllers and see if the problem occurs with all of them. I know the drive is fine, since I have several of the same model drives on other machines which do not exhibit this behavour, but which run at ATA-66 because they all have oldish controllers. Will On Sun, 24 Mar 2002, Robert Watson wrote: > > On Sat, 23 Mar 2002, Terry Lambert wrote: > > > Robert Watson wrote: > > > On Sat, 23 Mar 2002, Terry Lambert wrote: > > > > Disable write caching on the drives. THis is a FAQ. > > > > > > Hmm. I thought the wc bit should only affect this sort of scenario in the > > > event that the system was actually powered off; otherwise, the hard disk > > > can still flush to disk gradually as it. From the description, it seems > > > the system panics, but power is never removed from the drives. That said, > > > I wouldn't be surprised if the problem goes away on the basis that this > > > will substantially change system behavior for performance reasons, hiding > > > whatever subtle bug it is :-). > > > > The drive lies about commiting data to stable storage. This blows away > > all the hard work soft updates does trying to ensure ordering. > > Yes, but that failure is only exposed to the operating system if the drive > fails to actually write the data, which to my understanding, occurs only > when there is a power loss to the drive. Otherwise, that inconsistency is > never exposed because the drive guarantees that the data eventually makes > it to the disk, and the version of the data exposed to the operating > system is consistent with the operating system's expectations. In the > submitted scenario, it sounded like there had been a panic and a reboot, > but that the power had never been shut down to the drive. In that > scenario, I would expect that the drive would present a consistent view to > the OS on start-up, suggesting that the software failure involved in the > panic might have been involved in generating the inconsistencies, or that > there is a softupdates bug (the suggestion of the submitter). I.e., I > don't think write caching is involved in this particular instance. > > I have to say that my answer on the ATA write caching is a UPS. :-) > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > > > -- Willie Viljoen Private IT Consultant 214 Paul Kruger Avenue Universitas Bloemfontein 9321 South Africa +27 51 522 15 60, a/h +27 51 522 44 36 +27 82 404 03 27 will@laserfence.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message