© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
I suppose I should change that message to be "programming bug in e2fsck, checking a live file system, dodgy hardware/RAID array out of sync".
In this case, I'm going to put my money on the last one, and specifically, that you have a hardware problem. The errors that showed up in the second fsck run are localized to a specific inode table block that holds inodes 2330067, 2330069, 23300074, and 2330076. In the first fsck run, fsck complained about a programming error or that the file system was mounted read-write. Basically, that happens when the value that fsck had cached changed out from under it. This normally happens when the file system is mount and it's being modified while fsck runs, but it can also happen when the hardware is dodgy and returns one set of values at one time, and another set of values at another. (One cause of this is a RAID1 array which is out of sync, so you get the value from one side of the mirror, and then later you get the value on the other side of the mirror.)
In this case, we specifically modified the inode table block containing 23300074 during the first check, only to have a different set of complains on the second pass. That indicates to me that the disk is dodgy, and the contents which we wrote during the first pass was different from the set of problems you had on the second pass.