From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 12:48:51 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E51B16A4CE for ; Wed, 27 Oct 2004 12:48:51 +0000 (GMT) Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 6607D43D45 for ; Wed, 27 Oct 2004 12:48:51 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Message-ID: <20041027124851.9989.qmail@web41210.mail.yahoo.com> Received: from [83.129.244.117] by web41210.mail.yahoo.com via HTTP; Wed, 27 Oct 2004 05:48:51 PDT Date: Wed, 27 Oct 2004 05:48:51 -0700 (PDT) From: Arne "Wörner" To: freebsd-fs@freebsd.org In-Reply-To: <999608774.20041027154831@merdin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Re[6]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 12:48:51 -0000 > Why the file system cannot be repaired on the fly? Is it the > filesystem limitation? Why, say, NTFS can repair itself without a blue > screen or a disk check? > I have found some reports about NTFS to be buggy, too, when I searched for '+"turn off write cache" +ide +ata'... I think a fault free source code, that solves a problem like a file system, is quite difficult to produce, especially if someone chose not so common parameters... But I like the idea to track bugs down, where it seems to be reasonable (in some cases, if the source code looks too funny, it would not make so much sense, I think). I cannot really complain about FFS with soft-updates. I observed once, that after a halt with ACPI power-down _and_ with sync (as far as I recall it correctly) my file systems were un-clean (during the reboot the kernel panic'ed, because it felt something (a buf) was already free (as far as I can recall it)). But I was able to fix it by some fsck's in single user mode. Maybe I should mention, that I use three filesystems (root: 500MB, usr: 32GB, opt: 118GB) since several months and not so high avg. disc load (but with some peaks and concurrency) under FreeBSD 5.2-CURRENT-20040408. I think my problem with ACPI power-down happened due to this write cache thing (or is ACPI to wait for the cache flushing? Maybe I pressed the power or reset button... I do not know)? At least I turned off hw.ata.wc (by setting it to zero) today. Now it feels like writing from /dev/zero to a FFS device takes 5-6 times longer, but it feels safer, too... Does somebody know, if FFS works fine with modern hard discs (I do not know, but I could think of a little energy-buffer, that powers the drive until the cache is clean)? Is there a way to make this 2 minutes time window for meta data updates smaller (maybe 10 seconds or so)? I would be glad, if somebody could tell me, how to provoke a ffs-related panic, without choosing funny fs-parameters. Maybe then I could find a way to repeat the problem. Btw.: I cannot enlarge my filesystems... > BTW, newfs -g 375000 -h 8000 and mkdir dir1 after that on newly > created partition can cause panic as well :) > > -- > / Pavel Merdine > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail