mkfs -O ^ 64bit, ^ metadata_csum -t ext4 в 2019 г.

Это отрывок из документации ядра для metadata_csum и 64bit:

С начала 2012 года контрольные суммы метаданных были добавлены ко всем основным структурам данных ext4 и jbd2. Соответствующий флаг функции - metadata_csum.
Требуемый алгоритм контрольной суммы указан в суперблоке, хотя по состоянию на октябрь 2012 года единственным поддерживаемым алгоритмом является crc32c. В некоторых структурах данных не было места для полной 32-битной контрольной суммы, поэтому сохраняются только младшие 16 бит. Включение 64-битной функции увеличивает размер структуры данных, так что для многих структур данных можно хранить полные 32-битные контрольные суммы. Однако существующие 32-битные файловые системы не могут быть расширены для включения 64-битного режима, по крайней мере, без экспериментальных патчей resize2fs для этого. В существующие файловые системы можно добавить контрольную сумму, запустив tune2fs -O metadata_csum против основного устройства. Если tune2fs обнаруживает блоки каталога, в которых не хватает свободного места для добавления контрольной суммы, он запросит запуск e2fsck -D чтобы каталоги перестраивались с контрольными суммами. Это дает дополнительное преимущество, заключающееся в удалении свободного места в файлах каталогов и перебалансировке индексов htree. если ты игнорировать на этом шаге ваши каталоги не будут защищены контрольной суммой!

что это значит?

просто, что вы можете столкнуться с проблемами совместимости, используя эти функции сейчас (и они являются значениями по умолчанию для современной настройки mkfs), поэтому лучше не включать их, пока не будет явно запрошен https://askubuntu.com/questions/747656/ext4-broken-file-system-on-ubuntu-14-04-4 - хороший пример (автор был достаточно наивен, чтобы слепо следовать каким-то другим инструкциям, не зная, что делают команды - так что он, кажется, потерял весь свой диск вместо того, чтобы починить его ;-)

это как-то связано с проблемой y2038?

нет, просто отключает сомнительные дополнительные функции - одна плохо протестирована, вторая зависит от первой, но не применяет ее (поэтому когда-нибудь может произойти сбой ядра), обе ломают fsck на старых платформах.

насчет btrfs - лучше попробуйте сами. Иногда он хорошо подходит, иногда конфигурации с усилением redhat с xfs + lvm подходят лучше, иногда это просто не стоит времени - ext4 по-прежнему «просто работает» для большинства распространенных применений.