On Thu, Aug 13, 2015 at 12:00:50AM +0200, Johan Harvyl wrote: > >I'm not aware of any offline resize with 1.42.13, but it sounds like > >you were originally using mke2fs and resize2fs 1.42.10, which did have > >some bugs, and so the question is what sort of might it might have > >left things. > What kind of bugs are we talking about, mke2fs? resize2fs? e2fsck? Any > specific commits of interest? I suspect it was caused by a bug in resize2fs 1.42.10. The problem is that off-line resize2fs is much more powerful; it can handle moving file system metadata blocks around, so it can grow file systems in cases which aren't supported by online resize --- and it can shrink file systems when online resize doesn't support any kind of file system shrink. As such, the code is a lot more complicated, whereas the online resize code is much simpler, and ultimately, much more robust. > Can you think of why it would zero out the first thousands of > inodes, like the root inode, lost+found and so on? I am thinking > that would help me assess the potential damage to the files. Could I > perhaps expect the same kind of zeroed out blocks at regular > intervals all over the device? I didn't realize that the first thousands of inodes had been zeroed; either you didn't mention this earier or I had missed that from your e-mail. I suspect the resize inode before the resize was pretty terribly corrupted, but in a way that e2fsck didn't complain. I'll have to try to reproduce the problem based how you originally created and grew the file system and see if I can somehow reproduce the problem. Obviously e2fsck and resize2fs should be changed to make this operation much more robust. If you can tell me the exact original size (just under 16TB is probably good enough, but if you know the exact starting size, that might be helpful), and then steps by which the file system was grown, and which version of e2fsprogs was installed at the time, that would be quite helpful. Thanks, - Ted -- 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
