From owner-freebsd-current@FreeBSD.ORG Thu May 22 08:19:51 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 B34E137B401; Thu, 22 May 2003 08:19:51 -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 DAAA343F75; Thu, 22 May 2003 08:19:48 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Irr9-0006kb-00; Thu, 22 May 2003 08:19:47 -0700 Message-ID: <3ECCEA4D.4EDFC38D@mindspring.com> Date: Thu, 22 May 2003 08:18:37 -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> <20030521163526.I30051@gamplex.bde.org> <20030521075709.GB4783@HAL9000.homeunix.com> <3ECB3650.84333A13@mindspring.com> <20030521083040.GA5053@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4c4c0cb33c22d259efdbbede18dd6c0a1667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c 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: Thu, 22 May 2003 15:19:52 -0000 David Schultz wrote: > On Wed, May 21, 2003, Terry Lambert wrote: > > David Schultz wrote: > > 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 > [...] > > Just in case you're not entirely kidding here, forcing a r/o > downgrade allows you to invalidate all the dirty buffers, so you > don't have to worry about causing the filesystem to become more > inconsistent than it already is. So does panic'ing, and it doesn't have the disadvantage of you continuing running with inconsistent data. 8-). Actually, you're wrong here: flushing the dirty buffers is what permits you to perform a read-only downgrade. > > 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. > > Media change detection is a separate issue for removable media. I > tend to regard it as somewhat less important than handling medium > errors, because anyone who changes disks out from under the > operating system deserves whatever he gets. ;-) It's not like these errors magically appeared on the disk while it was in operation, such that sector sparing could be invoked, if they were in the normal write path, or the read/write errors could be detected in the course of normal operations at the point that they occurred -- code which is prepared to handle a contingency like that, BTW -- rather than when the FS went to use the data. Anyone who uses a corrupt disk without fsck'ing it first also deserves what they get. Writing a working fsck for all the FS's supported by FreeBSD is left as an exercise for the student. 8-). -- Terry