10/stable panic: softdep_deallocate_dependencies: dangling deps

Edward Tomasz Napierała trasz at FreeBSD.org
Tue Jul 1 18:47:55 UTC 2014


On 0701T1457, Dmitry Sivachenko wrote:
> 
> On 01 июля 2014 г., at 11:57, Ronald Klop <ronald-lists at klop.ws> wrote:
> 
> > On Mon, 30 Jun 2014 14:22:02 +0200, Dmitry Sivachenko <trtrmitya at gmail.com> wrote:
> > 
> >> Hello!
> >> 
> >> I have several machines with rather fresh FreeBSD-10/stable.
> >> 
> >> They all have 4 SATA drives, I have small gmirrored root+var and the rest of the drive space is mounted as /disk1, /disk2, etc (UFS2+SU).
> >> When a single disk fails, system panics with "softdep_deallocate_dependencies: dangling deps" message:
> >> http://people.freebsd.org/~demon/softdep.png
> >> 
> >> Since all vital data (root+var) are mirrored, I expect OS to stay alive.
> > 
> > Hi,
> > 
> > So /disk1, /disk2 are not (g)mirrored? In that case the system cannot handle write failure. Because writes are not synchronous (for speed) there is no possibility to return an error to the application.
> 
> 
> No, they are not (g)mirrored.
> I expect read/write errors, but not kernel panic.  Actually I encountered disk I/O errors since 2.2.5 and it is first time I faced kernel panic.

Soft updates cannot gracefully handle IO errors.  It _will_ panic.
You can either prevent errors from happening by using redundancy
(ie. mirroring), or disable soft updates.  That's how it works,
sorry.

In theory it would be possible to prevent this from happening;
panic here is actually to terminate the system before it corrupts
data, and in situations like this one, where the disk is no longer
accessible, it's not possible to corrupt anything.  IIRC I've
actually added a workaround for that a while ago, but, as you can
see, it's not enough, and I don't understand soft updates well
enough to fix it properly.



More information about the freebsd-stable mailing list