Thus spake Terry Lambert ([EMAIL PROTECTED]): > 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
