How to: determine if it's ext3 or ext2 mounted as ext4?
Hello.
I'm performing conversion from ext3 to ext4 currently, on several nodes. The current plan is to remount them as ext4 first, next use tune2fs to update list of filesystem features, next to remount them again in order to actually turn the features on.
The question is: what's the way to determine if the actual features used corresponds to ext3 or ext4? Or, in other words, if the last step in the above sequence has been completed or not?
The filesystem superblock at this time will show ext4 already (since ext4-specific features are turned on), but actual features used will be ext3.
Is there a way to determine if a remount is still needed?
Besides, when I first use tune2fs (on a ext3-mounted fs) and next remount it, the filesystem wants an fsck pass, which finds checksum errors on all newly written files, and these errors can't be corrected automatically at boot if -y fsck flag is NOT used (default on Debian). So I had to remount them first and convert second.
Thanks!
/mjt
Quoted 10 lines · Michael Tokarev
I'm performing conversion from ext3 to ext4 currently, on several nodes. The current plan is to remount them as ext4 first, next use tune2fs to update list of filesystem features, next to remount them again in order to actually turn the features on.
The question is: what's the way to determine if the actual features used corresponds to ext3 or ext4? Or, in other words, if the last step in the above sequence has been completed or not?
Actually, there are very few ext2/3/4 features that need to be enabled at mount time. The journal (and journal-related mount options) is perhaps the main one. But I can't think of any of the new file system features which are unique to ext4 that require a remount.
For example, if you mount an ext3 file system using ext4, and then set the extent feature flag using tune2fs, future files which you create should be created using extents (which you can verify using lsattr).
Quoted 5 lines
Besides, when I first use tune2fs (on a ext3-mounted fs) and next remount it, the filesystem wants an fsck pass, which finds checksum errors on all newly written files, and these errors can't be corrected automatically at boot if -y fsck flag is NOT used (default on Debian).
That's the uninit_bg feature, which also happens to include the group descriptor checksums. It's not checksum errors on "newly written files"; it's caused by the fact that the version of tune2fs you are using can't update the checksums when updating the feature which says, "checksums are present". If you upgrade to e2fsprogs 1.41.14, tune2fs no longer requires an fsck run after setting the uninit_bg feature.
- Ted