kern/106030: panic while rebooting with a dead disk

[mjacob at freebsd.org]

On Wed, 29 Nov 2006, Remko Lodder wrote:
> > I had a mounted ufs disk that went away. I rebooted so as to avoid a panic. Too bad. Geom paniced
> > on me anyway:
> >
> > Syncing disks, vnodes remaining...2 (da8:isp1:0:6:2): Invalidating pack
> > g_vfs_done():da8a[WRITE(offset=81920, length=4096)]error = 6
>
> Well, it wants to synchronise the data in the caches to the
> disk and cannot find it.. I think a panic is the best thing
> to do to prevent any weird things happening.  What else

A panic should be the last resort. If I/O is returned indicating the 
device has gone, a binval on all cached data and a forced close of the 
file table entry and notification of all user processes is the 
reasonable thing to do. Most real Unix'es that were hardened from the 
orginal v7 product learned to do this. FreeBSD hasn't.

> should be done when the disk it once had mounted goes away?
> you have different problems already when that happends..

As I've repeatedly said, mostly to deaf ears in FreeBSD, a device error 
should never be the cause for panic *unless* there is absolutely no way 
to notify user processes of the error *and* data corruption may have 
silently occurred. Inconvenience to an existing design is not really a 
good argument.

A read error to a device that has disappeared shouldn't cause a panic, 
even with a filesystem mounted. A write error to same shouldn't cause a 
panic - the error propagates back up the stack to the actual I/O 
invocation. If it was writebehind or dirty paging activity that can no 
longer be associated with any thread, then a panic is a policy decision 
that only the invoker of the I/O can make. Not the device driver. Not 
the volume manager (which is what GEOM is).