Date: Tue, 25 Mar 2003 17:16:31 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Alexander Langer <alex@big.endian.de> Cc: current@FreeBSD.org Subject: Re: several background fsck panics Message-ID: <3E80FF6F.8AE048EC@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> <20030325150407.GG1700@fump.kawo2.rwth-aachen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Langer wrote: > 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". Actually, you *do* care where the panic occurred. 8-). The issue with the repeating background fsck's is important. I suggest a counter that gets reset to zero each time the FS is marked clean by fsck, and incremented each time the background fsck process is started. When this counter reaches a predefined value (I sugest a command line option to background fsck, which defaults to "3", if left unspecified), then the fsck is automatically converted to a foreground fsck. This counter would be recorded in the superblock. > We claim background fsck as a "cool new" feature in the release notes, I don't. I'm convinced it's technically infeasible, and Kirk has validated my reasoning on this, previously. It is about as safe or unsafe as running with async mounts. Maybe worse, depending on the MTBF for your disk drives (i.e. ATA drives fail fairly often, if not catastrophically, in the presence of power failures; this can be mitigated by dual power supplies and UPS equipment). > 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. The explanation is that the very idea of a background fsck, without additional hardware support, is flawed. Rather than the problem occuring in the snapshot code, it could just as easily occured as a result of some process running before it had the opportunity to fsck at all. -- Terry 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?3E80FF6F.8AE048EC>