Unix & Linux Asked by nickcrabtree on October 30, 2021
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.
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/resize2fs -s /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).
Answered by Artem S. Tashkinov on October 30, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP