Hi! Its a md-raid6 of about 10 TiB. The disks have no bad sectors, long smart-test completetd without errors and raid check does not have any mismatched blocks. The e2image is still running. Dont know how it big it will grow. The e2fsck messages: > e2fsck 1.43-WIP (4-Feb-2014) > /dev/md5: recovering journal > JBD: Invalid checksum recovering block 1152 in log > JBD: Invalid checksum recovering block 1152 in log > … > JBD: Invalid checksum recovering block 1152 in log > Killed (needed to kill -9 the process) => e2fsck/recovery.c:594 > debugfs 1.43-WIP (4-Feb-2014) > /dev/md5: Block bitmap checksum does not match bitmap while reading block > bitmap The filesystem was not loaded. Catastrophic mode does work. Or what "exact error messages" do you mean? metadata_csum is enabled, correct. Thanks, Markus PS: Yes that is the correct lkml message. Darrick J. Wong wroteat 04.04.2014: > On Fri, Apr 04, 2014 at 12:35:45PM +0200, Markus wrote: > > Hi! > > > > I have a dirty ext4 volume. The system just hangs at startup. After removing that volume from fstab the system starts. > > > > Mount and e2fsck just flood with "Invalid checksum recovering block 1152 in log" messages. > > > > (Mounting with ro,noload let me access most files.) > > > > I also tried the e2fsck from current git. > > > > debugfs just fails with "Block bitmap checksum does not match bitmap while reading block bitmap". (catastrophic mode does work) > > > > Three points: > > - e2fsck should not get into an endless loop, blocking the system. > > - mount should not get into an endless loop, blocking the system and flooding the system log. > > - At least e2fsck should fix the filesystem. > > > > > > Any help or hints? > > Hmm, that's probably a bug in the journal replay code. :( > > Can you send me the output of "e2image -r /dev/sdXX - | bzip2 > hd.e2i.bz2" if > it's not too huge? The exact error messages (if you can capture/photograph > them) would also be useful. > > I'm guessing you have metadata_csum enabled... > > PS: lkml.org is dead; I'm assuming the URL referenced the discussion "Ext4 > Recovery: Invalid checksum recovering block # in log" but it's hard to tell > since there was no subject line provided with that URL. > > --D > > > > > > Thanks, > > Markus > > > > > > PS: Original lkml-mail: > > https://lkml.org/lkml/2014/4/1/467 -- 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
