1

I created an ext4 partition on Ubuntu 18.04.4 LTS in order to transfer a large amount of data to a production server. The server is running CentOS 6.10 with kernel 2.6.32. The Ext4 Howto states that "Ext4 was released as a functionally complete and stable filesystem in Linux 2.6.28" so I assumed I was going to be able to just mount the partition.

However when trying to mount the partition on the server I get the errors:

localhost kernel: EXT4-fs (sdd1): couldn't mount RDWR because of unsupported optional features (400)
localhost kernel: JBD: Unrecognised features on journal
localhost kernel: EXT4-fs (sdd1): error loading journal

I have full root access to the server, but I am unable to upgrade any of the operating system components due to compatibility issues with the running software.

Initial Googling suggested that the issue was due to the metadata checksum feature, so I downloaded and compiled the latest e2fsprogs (1.46-WIP (20-Mar-2020)) and used those to disable the feature:

sudo /home/user/bin/e2fsck -f /dev/sdd1
sudo /home/user/bin/tune2fs -O ^metadata_csum /dev/sdd1

However the partition still fails to mount, although I don't get the "unsupported optional features (400)" message any more:

$ sudo mount /dev/sdd1 /mnt/disk1
mount: wrong fs type, bad option, bad superblock on /dev/sdd1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

$ sudo tail /var/log/messages
Jul 20 08:01:21 localhost kernel: JBD: Unrecognised features on journal
Jul 20 08:01:21 localhost kernel: EXT4-fs (sdd1): error loading journal

Is there some way I can access the data on this partition without rebooting the server or changing any of the system software? There seem to be two options: either I use mount the partition as is (using FUSE, or compiling my own mount.ext4 binary), or I use tune2fs to remove the remaining incompatible features (how do I find out what they are?)

I should mention that due to COVID-19 lockdown measures, there's a two to three week wait for someone to physically unplug the drive from the server and plug it into a different machine. I need to find a solution which I can implement quicker than that.

1
  • Run a VM in it and use USB pass-through to access the disk in the VM directly? – muru Jul 20 '20 at 7:18
6

First try running

sudo e2fsck -f -v -C 0 -t /dev/sdd1

An e2fsck run may be required to complete the removal of the feature.

If it still doesn't help, try removing and recreating the journal:

sudo /home/user/bin/tune2fs -O '^has_journal,^64bit' /dev/sdd1
sudo /home/user/bin/tune2fs -j /dev/sdd1

Lastly if it's still unmountable, compare the flags being used for sudo dumpe2fs /dev/existing_parition and sudo dumpe2fs /dev/sdd1 and remove the ones which are not present for your already existing partitions.

For future reference, if you format the filesystem on the old system instead of on the new system, it should always be usable by the new kernel. If you need to format on the new system, you could use mke2fs -t ext4 -O '^metadata_csum,^64bit' to avoid some of the newer features (though this may be a moving target), or mke2fs -t ext3 (though this may be somewhat slower than ext4 as a result, but is very safe compatibility wise).

4
  • Extents as well, perhaps (after disabling 64-bit). tune2fs tries to be explicit when e2fsck and/or resize2fs are needed to complete feature changes (disabling 64-bit in particular typically needs both). – Stephen Kitt Jul 20 '20 at 11:29
  • I assume that should be a lower-case V in the e2fsck command line? Removing the journal was the solution (64 bit didn't help, nor did re-running e2fsck). It had not occurred to me that the easiest way to deal with unsupported features in the journal was just to remove the journal entirely! – nickcrabtree Jul 21 '20 at 5:12
  • Yes, it should have been lower case -v. I've corrected the answer. Sorry for the confusion. – Artem S. Tashkinov Jul 21 '20 at 6:08
  • The extents feature has always been part of ext4, so no need to disable that. I think once the journal has been removed (and recreated, I'll add that to the answer), it should be fine again. – LustreOne Jul 21 '20 at 8:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.