On Tue, Oct 17, 2017 at 9:48 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > Unfortunately, if this is what happened, then the true damage was done > when the file system was remounted read/write, and because the > allocation bitmaps were incorrect, portions of the inode table were > overwritten with file data. (As I mentioned, with modern file systems > there is a safety check which is now enabled by default which will > notice when there is an attempt to allocate blocks that are part of > the inode table, and stop this Very Bad Thing from happening. It does > take a tiny bit of extra CPU overhead, but we ultimately decided It > Was Worth It. Unfortunately, it was not enabled by default in the > 3.10 kernel.) > > There's not really any recovery possible in that case, unfortunately. :-( Argh. Well, thanks for the explanation, at least I think I have a better understanding of how things unfolded, now. I'm glad that this safety check is enabled by default now, and I'm gonna keep repeating myself "never ever mount read-write when you have a doubt" while I'm waiting for the carving tools to scan my blocks. Thanks again! -- Kilian
