Date: Tue, 13 Aug 2013 06:23:34 -0600 From: Chris Torek <chris.torek@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: AN <andy@neu.net>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Panic - ffs_valloc: dup alloc Message-ID: <CAPx1GvcssOm9zUOB4hxz-KVoX0m3NHgmu9Xdk5h=j83vPu5gAQ@mail.gmail.com> In-Reply-To: <CAJ-Vmo=OABuguXTpvv2FLEF2XSd%2BB3kmrP%2BKuZuX9eBReJe5Lg@mail.gmail.com> References: <mailman.21649.1376161585.8319.freebsd-current@freebsd.org> <alpine.BSF.2.00.1308102110090.43258@mail.neu.net> <CAJ-Vmo=OABuguXTpvv2FLEF2XSd%2BB3kmrP%2BKuZuX9eBReJe5Lg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
For what (little :-) ) it's worth, I got bit by this too. Ultimately it boils down to the problem that once the on-disk file system is sufficiently broken, the journal doesn't have enough information for fsck to even detect the problem, much less fix it. (In my case the problem most likely was created by a bad bit in RAM. That particular hardware has no ECC.) It seems to me that certain UFS panics (including "dup alloc", which was the one getting me too if I remember right) should poison the journal to force a full fsck. This won't necessarily solve everything, but it would at least carry the problem detection forward from the kernel into fsck... Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPx1GvcssOm9zUOB4hxz-KVoX0m3NHgmu9Xdk5h=j83vPu5gAQ>