Kernel crash at "softdep_deallocate_dependencies"
Desai, Kashyap
Kashyap.Desai at lsi.com
Mon Apr 9 06:22:35 UTC 2012
Thanks for such wonderful technical discussion. Things are now clear and we are planning to do some experiment based on your feedback.
~ Kashyap
> -----Original Message-----
> From: Edward Tomasz Napierała [mailto:etnapierala at googlemail.com] On
> Behalf Of Edward Tomasz Napierala
> Sent: Saturday, April 07, 2012 1:11 AM
> To: Kirk McKusick
> Cc: Desai, Kashyap; freebsd-fs at freebsd.org; Kenneth D.Merry; Pawel Jakub
> Dawidek; McConnell, Stephen
> Subject: Re: Kernel crash at "softdep_deallocate_dependencies"
>
> On Fri, Apr 06, 2012 at 10:21:29AM -0700, Kirk McKusick wrote:
> > Following through on Pawel Jakub Dawidek's comments, there is no
> > way that the filesystem can recover when a large piece of its has
> > disappeared. The panic that you are getting is because the soft
> > updates system realizes that allowing writes to continue on the
> > filesystem will cause it to be corrupted in an unrepairable way.
> > As it has no way to cleanly downgrade it to read-only or unmount
> > it, its only choice is to panic.
>
> Actually, there is a third way, which is what UFS mounted without
> softupdates does: do nothing. This works, because when ENXIO gets
> returned, the device is already gone.
>
> > If you do not like this panic, you can disable soft updates using:
> >
> > tunefs -n disable <filesystem>
> >
> > Absent the soft updates integrity checking, the filesystem will
> > carry on a good bit longer (though after a reboot it will likely
> > be unrecoverable even if you have put the disk back into it).
>
> Apart of a situation where ENXIO would be returned, but the device
> would stay accessible, which doesn't happen, afaik, what will actually
> happen is that all the operations on a filesystem will return ENXIO,
> except for reads for which the data is still in cache. Nothing will
> get written, so no further damage will be done, and it will be possible
> to forcibly unmount the filesystem without panicing.
More information about the freebsd-fs
mailing list