On Wed, May 21, 2003, Terry Lambert wrote: > 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 [...] 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. > 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. ;-)Received on Tue May 20 2003 - 23:30:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:08 UTC