Date: Thu, 22 May 2003 08:18:37 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Schultz <das@FreeBSD.ORG> Cc: Current <freebsd-current@FreeBSD.ORG> Subject: Re: panic: mount: lost mount Message-ID: <3ECCEA4D.4EDFC38D@mindspring.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ECCEA4D.4EDFC38D>