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