Date: Tue, 25 Mar 2003 16:04:07 +0100 From: Alexander Langer <alex@big.endian.de> To: Terry Lambert <tlambert2@mindspring.com> Cc: current@FreeBSD.org Subject: Re: several background fsck panics Message-ID: <20030325150407.GG1700@fump.kawo2.rwth-aachen.de> In-Reply-To: <3E804392.40844D63@mindspring.com> References: <20030324215712.GA844@fump.kawo2.rwth-aachen.de> <3E7FE3CE.ECD2775F@mindspring.com> <20030325110843.GF1700@fump.kawo2.rwth-aachen.de> <3E804392.40844D63@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Terry Lambert (tlambert2@mindspring.com): > A manual fsck can deal with corrupt data. [...] Yes, I recall the discussion about WC on ata vs. softupdates a few months back. I even have it disabled on more important machines than this one :-) > The panic was not, in fact, a result of the background fsck > itself: it was a result of an attempt to access FS structures > by the kernel through the FS, assuming -- incorrectly -- that > the FS structures were in a self-consistent state. Actually I don't care _where_ the panic happened. If I hadn't manually interupted the boot process, this kernel would have booted and paniced on that error for the next three years. I could fix that by simply doing a manual (background_fsck=NO), so something is "broken", for some definition of broken: If my system panics, I call that "broken". We claim background fsck as a "cool new" feature in the release notes, which is even the DEFAULT, including WC on ATA disks, which is ALSO the default. So , and if this is broken, there is a serious design flaw, which must be fixed. It doesn't help to explain why the error is there, the next user will have the same error, running a verbatim system. Ciao Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030325150407.GG1700>