On Wed, Jan 29, 2020 at 06:35:41AM +0200, Jaco Kroon wrote: > Hi, > > Inode 181716301 block 33554947 conflicts with critical metadata, > skipping block checks. > > So the critical block stuff I'm guessing can be expected since a bunch > of those tree structures probably got zeroed too. It's possible that this was caused by the tree structures getting written with garbage (33554947 is not zero, so it's not the extent tree structure getting zeroed, by definition). If metadata checksums are enabled, then the kernel would notice (and flag them with EXT4-fs error reports) if extent trees were not correctly set up. Another possibility is that hueristics you used for guessing how to recontrust the block group discripts were incorrectly. Note that if the file system has been grown, using on-line or off-line resize2fs, the results may not be identical to how the block groups laid out by mke2fs would have done things. So trying to use the existing pattern of block group descriptors to reconstruct missing ones is fraught with potential problems. If the file system has never been resized, and if you have exactly the same version of e2fsprogs used to initially create the file system, and if you have the exact same version of /etc/mke2fs.conf, and the exact same command-line options to mke2fs, you might be able to use "mke2fs -S" (see the mke2fs manpage) to rewrite the superblock and block group descriptors. But if any of the listed assumptions can't be assured, it's a dangerous thing to do. > Another idea is to use debugfs to mark inode 181716301 as deleted, but > I'm not sure that's safe at this stage? Well, you'll lose whatever was in that inode, but it's more likely that the problem is that if the block group descriptors are incorret, you'll cause even more damage. Did you make a full image backup of the good disks you can revert any experiments that you might try? Good look, - Ted P.S. For future reference, please take a look at the man page of e2image for how you can back up the ext4's critical metadata blocks.
