Linux:: EXT4-fs odds?!? - Page 1
Forum section: electronics / general

author: 0db
author_rank: Frequent Contributor
timestamp: April 03, 2020, 10:40:32 am
content: One year ago I formatted a hard drive as Ext3, and installed Linux.and I saw and ignored these weird messagesbut I continuously see these messagesCode:EXT4-fs (sda3): couldn't mount as ext3 due to feature incompatibilitiesEXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)One year later I tried to convert it into Ext4Code:#tune2fs -O extents,uninit_bg,dir_index /dev/sda3but I still see these messagesCode:EXT4-fs (sda3): couldn't mount as ext3 due to feature incompatibilitiesEXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)EXT4-fs (sda3): re-mounted. Opts: (null)and it makes no sense for meCode:#cat /etc/fstab | grep sda3/dev/sda3 / ext4 noatime 0 1Code:#cat /etc/fstab | grep sda3/dev/sda3 / ext4 noatime 0 1Code:#cat /etc/mtab/dev/sda3 / ext4 rw 0 0none /proc proc rw 0 0none /sys sysfs rw 0 0mpme /dev/pts devpts rw 0 0but wait, see thisCode:#file -s /dev/sda3/dev/sda3: Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large files)I am a bit confused ...edit:typo fixed

author: greenpossum
author_rank: Frequent Contributor
timestamp: April 03, 2020, 10:47:34 am
content: You should do a repair as the last message says with fsck. All behaviour are suspect on an inconsistent filesystem. The tune2fs requires a clean filesystem if you follow the instructions..

author: 0db
author_rank: Frequent Contributor
timestamp: April 03, 2020, 12:08:41 pm
content: Code:# fsck.ext4 -f /dev/sda3I have already checked, and there is any problem reported by fsck. Besides, the above warning-messages were present even one year ago and they are the same warning-messages.

author: greenpossum
author_rank: Frequent Contributor
timestamp: April 03, 2020, 12:15:21 pm
content: In your tune2fs command you specified sda4. Is that a typo or is that copy and paste?

author: 0db
author_rank: Frequent Contributor
timestamp: April 03, 2020, 12:37:29 pm
content: Quote from: greenpossum on April 03, 2020, 12:15:21 pmtypo.

author: 0db
author_rank: Frequent Contributor
timestamp: April 03, 2020, 12:42:04 pm
content: Shouldn't "file -s /dev/sda3" report "Ext4" for an Ext3-converted-into-Ext4 ?That's odd

author: greenpossum
author_rank: Frequent Contributor
timestamp: April 03, 2020, 12:53:07 pm
content: I would say your conversion didn't succeed so I would treat it as ext3 until it's fixed. So use fsck.ext3 to fix any errors, then run tune2fs again before attempting to test it or mount it again.Or maybe it's neither here nor there and the only way out is to copy the data off it, then format it ext4 from the beginning, then restore the data.

author: 0db
author_rank: Frequent Contributor
timestamp: April 03, 2020, 01:00:51 pm
content: Quote from: greenpossum on April 03, 2020, 12:53:07 pmalready checked: fsck.ext3 -f /dev/sda3 ---> no problemalready checked: fsck.ext4 -f /dev/sda3 ---> no problem

author: greenpossum
author_rank: Frequent Contributor
timestamp: April 03, 2020, 01:23:29 pm
content: This for example is what file shows on an ext4 filesystem:/dev/md126: Linux rev 1.0 ext4 filesystem data, UUID=77bebd8b-beab-449e-9b77-f040a8508614 (extents) (large files) (huge files)I think your filesystem is stuffed.

author: 0db
author_rank: Frequent Contributor
timestamp: April 03, 2020, 01:33:02 pm
content: hence converting Ext3 into Ext4 is not a good idea. Let's backup and reformat it.

author: greenpossum
author_rank: Frequent Contributor
timestamp: April 04, 2020, 08:42:29 am
content: I think your original mistake was attempting the migration on an unclean ext3 filesystem. The full instructions require that you fix any inconsistencies with fsck.ext3 before running tune2fs. Perhaps that version of tune2fs didn't check for a consistent filesystem, recent versions may. As such you probably got a filesystem that was neither here nor there.I have done ext3 to ext4 migration many times without issues.

author: 0db
author_rank: Frequent Contributor
timestamp: April 04, 2020, 09:49:15 am
content: Quote from: greenpossum on April 04, 2020, 08:42:29 ambefore tune2fs, I checked it with fsck and it reported no problems.

author: greenpossum
author_rank: Frequent Contributor
timestamp: April 04, 2020, 09:53:18 am
content: Yet, file -s showed that the journal needed recovering. So if the problem didn't happen then it was caused by something else you did. Anyway too late now.

author: 0db
author_rank: Frequent Contributor
timestamp: April 04, 2020, 10:03:05 am
content: I seriously think migrating from Ext3 to Ext4 was not good ideaI have a second computer with Ext4 here, it's a server and it crashed a couple of days ago. When checked it reportedCode:fsck.ext4 -f /dev/hda6e2fsck 1.44.5 (15-Dec-2018)Pass 1: Checking inodes, blocks, and sizesInodes that were part of a corrupted orphan linked list found. Fix<y>? yesInode 53202 was part of the orphaned inode list. FIXED.Inode 53203 was part of the orphaned inode list. FIXED.Inode 53204 was part of the orphaned inode list. FIXED.Inode 53206 was part of the orphaned inode list. FIXED.Inode 53207 was part of the orphaned inode list. FIXED.Inode 70082 was part of the orphaned inode list. FIXED.Inode 70087 was part of the orphaned inode list. FIXED.Inode 70095 was part of the orphaned inode list. FIXED.Inode 70097 was part of the orphaned inode list. FIXED.Inode 70104 was part of the orphaned inode list. FIXED.Inode 70106 was part of the orphaned inode list. FIXED.Inode 74981 was part of the orphaned inode list. FIXED.Inode 160446 was part of the orphaned inode list. FIXED.e2fsck is v1.44.5 (15-Dec-2018) and it was able to check and identifies problems with Ext4 on the crashed server, but not able to report any problem on the computer migrated from Ext3 to Ext4.... perhaps, because the server is being Ext4 since the beginning ...

author: 0db
author_rank: Frequent Contributor
timestamp: April 04, 2020, 10:05:04 am
content: Quote from: greenpossum on April 04, 2020, 09:53:18 amindeed too late- badblock to check the integrity of the physical hard drive- I will repartition it and reformat sdc3 into Xfs

author: madires
author_rank: Super Contributor
timestamp: April 04, 2020, 10:10:09 am
content: Best current practice is to backup data, reformat partition with ext4 and restore data. A direct migration won't create a complete ext4. It's a well known issue.

author: 0db
author_rank: Frequent Contributor
timestamp: April 04, 2020, 10:11:07 am
content: Quote from: madires on April 04, 2020, 10:10:09 amLesson learned

author: greenpossum
author_rank: Frequent Contributor
timestamp: April 04, 2020, 10:43:26 am
content: Quote from: 0db on April 04, 2020, 10:03:05 amThe thing is it never went to ext4, the migration didn't succeed and you then mounted it as ext4. That would be a problem. One of the steps is to check that it really is ext4 before trying to mount it.Best practice is to do a backup of anything important. You can do the migration and if it succeeds you have saved a restore. Of course it's better if you start with ext4, but sometimes in real life you don't have the luxury because you have to do the change in place and hope that you won't need to activate plan B.

author: madires
author_rank: Super Contributor
timestamp: April 04, 2020, 02:25:02 pm
content: Fromhttps://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/ext4converting.html:Quote

author: greenpossum
author_rank: Frequent Contributor
timestamp: April 05, 2020, 04:09:14 am
content: Quote from: madires on April 04, 2020, 10:10:09 amTo be precise, what happens is that existing files do not use the new features such as extents so you don't get full performance on those, but files created afterwards will. That includes copies, so if you know that a file needs the performance, say a DB file, you could make a copy and rename to the original name. While it's not in use, of course. Hopefully that's what you mean by "complete". It is a valid ext4 filesystem after conversion.