On 29 August 2014 01:19, Liwei <xieliwei@xxxxxxxxx> wrote: > Hi Ted, > Thanks for the response! Responses in-line. > ====SNIP==== >> Finally, this error is one was caused by your using fsck -n: >> >>> Illegal triple indirect block (3637063325) in inode 1065. IGNORED. >>> Error while iterating over blocks in inode 1065: Illegal triply >>> indirect block found >> >> There was an illegal indirect bock in inode 1065, which wasn't fixed >> because of e2fsck -n. Unfortunately, this caused the scan to get >> aborted, because the unfixed error caused the inode iterator to fail. >> We could try to fix things up to make e2fsck -n recover more cleanly >> in the face of errors caused by not fixing previously found errors, >> but that hasn't been something that's been high priority. (If someone >> would like to improve e2fsck in this regard, please send patches.) > ====SNIP==== >> More generally, it looks like part of your inode table got smashed. > > That sounds bad. From my limited understanding of ext4's structure, > each block group has its own inode table, right? Or is the inode table > global? What are my chances of recovering from this? > I decided to make a snapshot and tried running fsck.ext4 -y. Currently, this just flew by my screen: Inode 117911, i_size is 10327091671466843186, should be 0. Fix? yes Inode 117911, i_blocks is 123836699223379, should be 0. Fix? yes Inode 117841 has a bad extended attribute block 3239803245. Clear? yes Inode 117841 has illegal block(s). Clear? yes Every single inode before that was erroneous. That means they're data somehow mistaken as inodes, aren't they? Liwei -- 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
