http://bugzilla.kernel.org/show_bug.cgi?id=14354 --- Comment #173 from Eric Sandeen <sandeen@xxxxxxxxxx> 2009-11-03 14:32:26 --- (In reply to comment #172) > There's a lot more we need to understand --- including why we weren't seeing a > printk message indicating a journal checksum, and which commit was showing the > checksum failure, and why we ended up seeing a checksum failure in the first > place. If it was the last commit that was being written right before the > system crash, the commit block simply should have been missing due to the > barrier. But we can do this without having to worry about 2.6.32 being a QA > disaster for ext4. :-) I am looking for the checksum problem today. I agree, seeing an otherwise-valid commit block w/ a bad checksum is very troubling - barrier infrastructure problems? Or something else, will have to see. I know why we're not seeing a printk, already; it's under a RDONLY test, and the root fs is mounted readonly; I have a patch for that though I wonder what the right choice is when we encounter this corruption - I'm leaning towards treating it like any other corruption and going through ext4_error... ...anyway, still looking at all this today, even w/ the .32 qa disaster averted for now. :) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
