From owner-freebsd-current@FreeBSD.ORG Wed May 21 01:19:56 2003 Return-Path: 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 E8E6837B401; Wed, 21 May 2003 01:19:55 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51DAF43F3F; Wed, 21 May 2003 01:19:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfk26.dialup.mindspring.com ([165.247.208.70] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19IOpF-00007Q-00; Wed, 21 May 2003 01:19:54 -0700 Message-ID: <3ECB3650.84333A13@mindspring.com> Date: Wed, 21 May 2003 01:18:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Schultz References: <7m4r3onc7i.wl@black.imgsrc.co.jp> <20030521075709.GB4783@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4835a7c9a19507f6cf58bd51f11d2a191350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Jun Kuriyama cc: Current Subject: Re: panic: mount: lost mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 08:19:56 -0000 David Schultz wrote: > On Wed, May 21, 2003, Bruce Evans wrote: > > Unfortunately, this is fairly normal file system behaviour when a critical > > block is unreadable or damaged. Here vfs detects a problem that it knows > > it cannot handle, and panics. > > I've run into this as well while testing other properties of how > removable media is handled. Is there an easy way to get slightly > more graceful behavior, such as forcing a downgrade to r/o and > zapping the vnodes for any unrecoverable files a la 'umount -f'? Not if you have outstanding dirty buffers. The best you can do is demand they put the disk back and say dumb things like "Abort, Retry, Ignore?" on the console from a modal kernel prompt that kills all other processing on the box until you pay attention to it. And that only works on 3.5" floppies, not 5.25" floppies, because they didn't have the ability to sense the difference between bad media and no media. That assumes you can tell the difference between the disk that was there before, and the one that's there now. PC floppy hardware is generally really stupid; even when they have a media change line, they generally don't hook it up; or they're smart, and make the eject a software controlled function, rather than a mechanical one, but you can't buy one of these for a PC unless it's an Amiga or a Macintosh or a SPARC box. I'm also pretty sure that if you checked your data everywhere you would have to to catch things like media change events (as opposed to just media removal) or, as you suggest, out of range data, then you would be spending all your time validating your data, rather than doing real work. FWIW, most UNIX machines panic when you SPAM their FS out from under them; Solaris boxes all do the same thing, if you give them a corrupted MS-DOS disk to read (SunOS 4.x, SunOS 5.x). -- Terry