Otto Moerbeek <o...@drijf.net> wrote: > On Fri, Mar 19, 2021 at 04:15:31PM +0000, Stuart Henderson wrote: > > > On 2021/03/19 17:05, Jan Klemkow wrote: > > > Hi, > > > > > > I had the same issue a few days ago a server hardware of mine. I just > > > ran 'cvs up'. So, it looks like a generic bug in FFS and not related to > > > vmm. > > > > This panic generally relates to filesystem corruption. If fsck doesn't > > help then recreating which filesystem is triggering it is usually needed. > > Yeah, once in a while we see reports of it. It seems to be some nasty > conspiracy between the generic filesystem code, ffs and fsck_ffs. > Maybe even the device (driver) itself is involved. A possible > underlying issue may be that some operation are re-ordered while they > should not.
Yes, it does hint at a reordering. > Now the strange thing is, fsck_ffs *should* be able to repair the > inconsistency, but it appears in some cases it is not, and some bits > on the disk remain to trigger it again. fsck_ffs can only repair one inconsistancy. There are a number of lockstep operations, I suppose we can call them acid-in-lowercase, which allow fsck to determine at which point the crashed system gave up the ghost. fsck then removes the partial operations, leaving a viable filesystem. But if the disk layer lands later writes but not earlier writes, fsck cannot handle it.
