Linux:: EXT4-fs odds?!?

[0db]

One year ago I formatted a hard drive as Ext3, and installed Linux.

and I saw and ignored these weird messages

but I continuously see these messages

Code: [Select]

EXT4-fs (sda3): couldn't mount as ext3 due to feature incompatibilities
EXT4-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 Ext4

Code: [Select]

#tune2fs -O extents,uninit_bg,dir_index /dev/sda3

but I still see these messages

Code: [Select]

EXT4-fs (sda3): couldn't mount as ext3 due to feature incompatibilities
EXT4-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 me

Code: [Select]

#cat /etc/fstab | grep sda3
/dev/sda3       /               ext4            noatime         0 1


Code: [Select]

#cat /etc/fstab | grep sda3
/dev/sda3       /               ext4            noatime         0 1


Code: [Select]

#cat /etc/mtab
/dev/sda3 / ext4 rw 0 0
none /proc proc rw 0 0
none /sys sysfs rw 0 0
mpme /dev/pts devpts rw 0 0



but wait, see this

Code: [Select]

#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

[greenpossum]

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..

[0db]

Code: [Select]

# fsck.ext4 -f /dev/sda3

I 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.

[greenpossum]

In your tune2fs command you specified sda4. Is that a typo or is that copy and paste?

[0db]

In your tune2fs command you specified sda4. Is that a typo or is that copy and paste?

typo.

[0db]

Shouldn't "file -s /dev/sda3" report "Ext4" for an Ext3-converted-into-Ext4 ?
That's odd

[greenpossum]

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.

[0db]

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.

already checked: fsck.ext3 -f /dev/sda3 ---> no problem
already checked: fsck.ext4 -f /dev/sda3 ---> no problem

[greenpossum]

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.

[0db]

hence converting Ext3 into Ext4 is not a good idea. Let's backup and reformat it.

[greenpossum]

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.

[0db]

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.

before tune2fs, I checked it with fsck and it reported no problems.

[greenpossum]

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.

[0db]

I seriously think migrating from Ext3 to Ext4 was not good idea

I have a second computer with Ext4 here, it's a server and it crashed a couple of days ago. When checked it reported

Code: [Select]

fsck.ext4  -f /dev/hda6
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
Inode 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 ...

[0db]

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.

indeed too late
- badblock to check the integrity of the physical hard drive
- I will repartition it and reformat sdc3 into Xfs

[madires]

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.

[0db]

Best current practice is to back up data, reformat partition with ext4 and restore data. A direct migration won't create a complete ext4. It's a well known issue.

Lesson learned 

[greenpossum]

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.

The 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.

[madires]

From https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/ext4converting.html:

Whenever possible, create a new ext4 file system and migrate your data to it instead of converting from ext3 to ext4. This ensures a better metadata layout, allowing for the enhanced performance natively provided by ext4.

[greenpossum]

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.

To 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.