From owner-freebsd-fs  Mon Nov  9 00:22:27 1998
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id AAA27359
          for freebsd-fs-outgoing; Mon, 9 Nov 1998 00:22:27 -0800 (PST)
          (envelope-from owner-freebsd-fs@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA27354
          for <freebsd-fs@FreeBSD.ORG>; Mon, 9 Nov 1998 00:22:21 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id TAA12725;
	Mon, 9 Nov 1998 19:21:51 +1100
Date: Mon, 9 Nov 1998 19:21:51 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199811090821.TAA12725@godzilla.zeta.org.au>
To: bde@zeta.org.au, eivind@yes.no, freebsd-fs@FreeBSD.ORG,
        richard@jezebel.demon.co.uk
Subject: Re: Should a corrupt floppy disk cause a panic?
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>> Suitably damaged ffs file systems should also cause panics (as soon as
>> possible so that the damage doesn't grow).  fsck_foofs must be run
>> before mounting [possibly-]damaged foofs file systems.  This is not so
>> easy for msdosfs file systems since there is no fsck_msdosfs.
>
>Suitably damaged ffs file systems should block for further writes.  A
>panic() is not the only way of blocking for further writes, and for
>high-availability systems it is a bad way.  This should be tunable, of
>course, as an unattended system would probably be better off panic'ing
>and rebooting, to get the system to automatically come up again with
>the filesystem available.  However, for systems with many filesystems
>active, it might be much better to loose access to that single
>filesystem than to take down the entire machine for a reboot.

Yes, when a panic occurs (deep in a non-ffs routine, due to memory
corruption caused by using invalid data from the disk), it is easy
for the system to unwind the state to when the error occurred and
make ffs wait there ;-).

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message