From owner-freebsd-current Tue Mar 25 17:17:55 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1343737B401 for ; Tue, 25 Mar 2003 17:17:52 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4760843F85 for ; Tue, 25 Mar 2003 17:17:51 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0212.cvx21-bradley.dialup.earthlink.net ([209.179.192.212] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18xzY3-00003c-00; Tue, 25 Mar 2003 17:17:48 -0800 Message-ID: <3E80FF6F.8AE048EC@mindspring.com> Date: Tue, 25 Mar 2003 17:16:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexander Langer Cc: current@FreeBSD.org Subject: Re: several background fsck panics 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f01b6f61b392a17c76e824de60ba1355350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Spam-Status: No, hits=-22.2 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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