Date: Sun, 24 Mar 2002 16:31:48 +0200 (SAST) From: Willie Viljoen <will@laserfence.net> To: Robert Watson <rwatson@freebsd.org> Cc: Terry Lambert <tlambert2@mindspring.com>, <freebsd-fs@freebsd.org>, <freebsd-bugs@freebsd.org> Subject: Re: Soft update instability with heavy IO and offboard IDE controller Message-ID: <20020324162943.L307-100000@phoenix.vh.laserfence.net> In-Reply-To: <Pine.NEB.3.96L.1020324092025.47668V-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020324162943.L307-100000>