On Tue, Apr 26, 2022 at 09:39:46PM -0700, Shradha Gupta wrote: > I think I may have run into an issue where my ext4 OS disk shows > multiple corruptions and the issue is reproducible after multiple > reboots. > > Please help me understand this corruption better as I am new to ext4 layouts. > > The “fsck -n <device>” command output was as follows: > > e2fsck 1.45.5 (07-Jan-2020) > ext2fs_open2: Superblock checksum does not match superblock > fsck.ext4: Superblock invalid, trying backup blocks... > Superblock needs_recovery flag is clear, but journal has data. > Recovery flag not set in backup superblock, so running journal anyway. You need to give more information; what kernel version are you using? What is the hardware or cloud VM configuration that you are using? How are you rebooting the machine? Are you doing a clean shutdown, or are you just kicking the plug out of the wall, or killing the VM without giving a chance for the system to shut down cleanly? Ext4 should handle an unclean shutdown cleanly, assuming that the hardware (or emulated disk, in the case of a cloud system) properly handles CACHE FLUSH requests. Given the vaguely suggested label on your file system... > cloudimg-rootfs was not cleanly unmounted, check forced. Is there anything special going on --- in particular, is this part of creating a cloud image? If so, are you doing anything "interesting", such as updating the Label or UUID using tune2fs racing with, say, an online resize, or an uncerimonious VM shutdown? If it is reproducible, can you give us the reproduction recipe? Thanks, - Ted
