> Those bugs look like they are very separate in that they have nothing > to do with locking, but rather in e2fsck and the kernel not properly > dealing with certain types of inconsistencies on disk. On my list to > deal with. As a workaround, you can just clri the offending corrupted > inode from lost+found and then run e2fsck. Yes, that's fairly obvious, but I've avoided that for a few reasons: 1) I was holding on to the broken inodes in case you needed more information that I didn't include in the initial report, 2) I also thought they might be wanted to test an eventual fix, and 3) I was probably going to get a bit fancier to preserve the file names. My latest report is a bit confusing because debugfs() reads the directories without complaint, so I'm not sure it's a valid on-disk situation that the kernel is improperly rejecting, or an invaid situation that libext2fs is improperly accepting. Since I don't currently understand the on-disk format of inline data, (I need to RTFS), I can't figure that out or see if there's a way to do a repair in situ. Oh! Found it at https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inline_Data So I'm guessing the problem is that the required empty system.data attribute is missing (due to the preceding extra_isize changing mess), and if I just created it, everything would magically come back to life. Something like ea_set <inode> system.data "" -- 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
