mkfs -O ^64bit,^metadata_csum -t ext4 in 2019

Thomas Krenn recommends creating ext4 partitions like:

https://www.thomas-krenn.com/de/wiki/FSCK_Best_Practices

mkfs -O ^64bit,^metadata_csum -t ext4

what does this mean?

does this have anything to do with the y2038 problem?

https://en.wikipedia.org/wiki/Year_2038_problem

"A user should be able to turn on this feature at mke2fs time simply by specifying -O metadata_csum. Because the 64bit feature allows arbitrarily large block group descriptors that are large enough to enable crc32c for the bitmaps, mke2fs should warn the user if the feature set is metadata_csum,^64bit when it becomes the case that the 64bit feature has been tested thoroughly."

https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums

what is recommended? move to btrfs?

thanks!

This is an excerpt from the kernel documentation for metadata_csum and 64bit:

Starting in early 2012, metadata checksums were added to all major ext4 and jbd2 data structures. The associated feature flag is metadata_csum.
The desired checksum algorithm is indicated in the superblock, though as of October 2012 the only supported algorithm is crc32c. Some data structures did not have space to fit a full 32-bit checksum, so only the lower 16 bits are stored. Enabling the 64bit feature increases the data structure size so that full 32-bit checksums can be stored for many data structures. However, existing 32-bit filesystems cannot be extended to enable 64bit mode, at least not without the experimental resize2fs patches to do so. Existing filesystems can have checksumming added by running tune2fs -O metadata_csum against the underlying device. If tune2fs encounters directory blocks that lack sufficient empty space to add a checksum, it will request that you run e2fsck -D to have the directories rebuilt with checksums. This has the added benefit of removing slack space from the directory files and rebalancing the htree indexes. If you ignore this step, your directories will not be protected by a checksum!

what does this mean?

simple what you may run into compatibility troubles by using this features now (and they are the defaults for modern mkfs setup), so it's better to keep them off until explicitly requested https://askubuntu.com/questions/747656/ext4-broken-file-system-on-ubuntu-14-04-4 - good example (the author was naive enough to blindly follow some others instruction, not knowing what the commands do - so he seems lost all his disk instead of fixing it ;-)

does this have anything to do with the y2038 problem?

nay, just turns off questionable additional features - one is not well-tested, second is depended of first but not enforces it (so kernel may crash someday), both breaks fsck on older platforms.

as for btrfs - you better try it yourself. Sometimes it fits well, sometimes redhat-enforced configurations with xfs+lvm suits better, sometimes it just doesn't worth the time - ext4 still "just works" for most common uses.