1

I have a virtual disk that is 86T in size with only 41% used. Th I have an 86T second drive connected to my virtual machine(VM) as /dev/vdb1. The volume is fine, but when I attempt to mount the ext4 partition, the whole machine stops. I left it for more than 24 hours to see if it was just taking a while, but that produced no change. I can boot the VM from it's boot volume so long as I don't attempt any actions on the ext4 partition. I suspected a faulty journal, so I mounted the volume as -o ro,noload. I am able to read data from the drive and interact with the files on the drive.

I have attempted to remove the journal by using "e2fsck -O ^has_journal /dev/vdb1" and it responds with "Recovering Journal" and the machine locks up.

I have tried booting a gparted ISO, and as soon as any operation is attempted on the ext4 partition, the machine locks up.

I did "dumpe2fs /dev/vdb1 | grep -i superblock" it does list Primary and several backup superblocks. It also responds with "dumpe2fs: Block bitmap checksum does not match bitmap while trying to read '/dev/vdb1' bitmaps.

Does anyone know how to either remove the needs_recovery or prevent the disk utilities from attempting a journal recovery? Or, better yet, anyone have suggestions for what I can do to get this back online without having to restore massive amounts of data from a backup?

Improve this question
5
  • It seems to me e2fsck does not have options like -O ^has_journal. That option looks like it should be applicable to tune2fs instead.
    – telcoM
    Commented Jun 30 at 20:03
  • Is it running out of ram? Did you check dmesg? You can also try debugfs but it has many dangerous options.
    – frostschutz
    Commented Jul 1 at 10:19
  • I appreciate the answers. @telcoM, you are correct. it is tune2fs. My bad.
    – kentt
    Commented Jul 1 at 11:46
  • @frostschutz, are you saying that after resetting the VM, ram shouldn't be an issue. the VM has 220G of ram allocated to it. When the VM freezes, there is no spike in ram usage.
    – kentt
    Commented Jul 1 at 11:46
  • Update: In the overnight, I attempted to take a backup of the files after mounting the partition read only. There does appear to be inconsistencies. After several hours of backing up files, it will again lock up and I have to reset the VM. So I'm going to attempt several more times to get the remaining files before just wiping the partition out and starting over. I would be curious as to how I can bring the partition back online with read and write without replaying the journal. Then I could attempt further operations on the partition. As it sits, I can do nothing but attempt to read data.
    – kentt
    Commented Jul 1 at 11:50

1 Answer 1

Reset to default
0

You can use debugfs 'feature ^feature' command to manually clear features like 'has_journal' and 'needs_recovery'.

Always make sure you are running the latest version of e2fsck. Running old distro versions can be missing lots of fixes.

Improve this answer
2
  • Thanks for this great idea. I attempted what you suggested. The result is that debugfs refuses to open the file system and returns the following error. /dev/vdb1: Block bitmap checksum does not match bitmap while reading allocation bitmaps. While searching on the internet, all the suggestions are to run fsck agains the volume which puts me back to having to replay the journal. Any more suggestions?
    – kentt
    Commented Jul 3 at 11:52
  • I appreciate all the help from each of you. I was barking up the wrong tree with this one. The underlying storage was full so I couldn't replay the journal and I couldn't do anything except wipe the volume and start over. The original issue is still in play, but now that I understand what's going on I can take steps to mitigate till I solve the real cause of the trouble.
    – kentt
    Commented Jul 16 at 12:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .