Файловые системы для desktop и флешки

Какую лучше файловую систему использовать для основного раздела Linux на desktop, чтобы добиться максимальной производительности? Во времена HDD пробовал ext3 (тогда еще ext4 не было), потом переходил на ReiserFS, и XFS, но невооруженным взглядом, без benchmarkов, особой разницы не заметил.
Потом был период, когда держал Linux на загрузочной флешке. Вот там различия между файловыми системами влияют значительно: ext4 и xfs работали достаточно тормознуто, а лучшие результаты показала nilfs. Но закончилось все печально: однажды, экспериментируя с энергосбережением, я наглухо повесил ноутбук, а после перезагрузки по hard reset файловая система разрушилась, и восстановить я ее так и не смог.
Через пару лет снова решил перейти на Linux. Поизучал benchmarks, и пришел к выводу, что различия в плане производительности между Reiserfs, xfs и ext4 не так уж и велики, поэтому поставил ext4 как наиболее универсальную. Но периодически возникают сомнения, а не было бы правильнее использовать что-то вроде brtfs?

Лично я планирую в будущем переходить на btrfs, но не знаю, какова её стабильность на текущий момент. Когда я разбирался с этой темой, я пришёл к выводу, что с ext4 будет меньше всего проблем по сравнению с другими ФС и решил пока остаться на ней.

Мой друг, который уже давно использует Debian, постоянно замечает большую нагрузку на процессор при копировании файлов с ext4 и на неё. Когда мы с ним тестировали Fedora, мы решили воспользоваться xfs для корневого раздела. И он обратил внимание, что уже нет той большой нагрузки на процессор при копировании файлов, которая наблюдалась с ext4. Хотелось бы выяснить, что вызывает эту нагрузку и как от неё избавиться.

Вообще, источников нагрузки на процессор может быть три. Во-первых, неэффективная работа алгоритма поиска свободного места или свободных inodes на принимающей системе (часто бывает, когда места остается мало или файлы в системе сильно фрагментированы). Во-вторых, может влиять режим работы журнала и затраты на обновление HTree-индекса списка файлов в каталоге. И в третьих, если дело происходило на старом «железе» (еще с IDE), то нужно проверить режим работы жестких дисков — не происходит ли работа в так называемом PIO-режиме вместо UDMA (это очень существенно просаживает производительность и грузит процессор).

А F2FS кто-нибудь пробовал? Нашёл тут на Phoronixе очередной Benchmark, там она один из лучших результатов показывает, особенно в плане времени старта приложений. Хочу попробовать флешку с ней сделать, посмотреть, что в итоге выйдет.

Провёл небольшой benchmark файловых систем на своём компьютере. Выделил 5Гб раздел в конце SSD-накопителя и тестировал с помощью утилиты fs_mark в двух режимах.
Режим 1 — создаётся 50 подкаталогов по 10000 файлов в каждом размером в 51200 байт. Подробнее:
# Version 3.3, 1 thread(s) starting at Mon Oct 10 17:19:47 2022
# Sync method: INBAND FSYNC: fsync() per file in write loop.
# Directories:  Round Robin between directories across 50 subdirectories with 10000 files per subdirectory.
# File names: 40 bytes long, (16 initial bytes of time stamp with 24 random bytes at end of name)
# Files info: size 51200 bytes, written with an IO size of 16384 bytes per write
# App overhead is time in microseconds spent in the test not doing file writing related system calls.

Режим 2 — создаётся 50 подкаталогов по 100 файлов в каждом размером в 768 тыс. байт. Подробнее:
# Version 3.3, 1 thread(s) starting at Mon Oct 10 17:22:20 2022
# Sync method: INBAND FSYNC: fsync() per file in write loop.
# Directories:  Round Robin between directories across 50 subdirectories with 100 files per subdirectory.
# File names: 40 bytes long, (16 initial bytes of time stamp with 24 random bytes at end of name)
# Files info: size 768000 bytes, written with an IO size of 16384 bytes per write
# App overhead is time in microseconds spent in the test not doing file writing related system calls.

Результаты получились следующие (измеряются в количестве записанных файлов в секунду):

Система Режим 1 Режим 2 ext4 458/456 213/209 btrfs 347 183 xfs 463 239 jfs 2350 370 f2fs 901 253

Диск, на котором проводились измерения: Samsung SSD 860 EVO 1TB.

Для ext4 измерения провёл дважды для надёжности
Для F2FS измерения не проводились — нет поддержки этой fs в ядре. Измерения для NILFS привели к очень долгому времени выполнения теста с зависанием при попытке его прервать. Полагаю, что дело в том, что процесс nilfs_cleaner съел всю доступную память.
Также для сравнения замерил показатели tmpfs — получилось 14213 файла/с в первом режиме.

В общем, jfs лидирует с огромным отрывом. И всерьёз подумываю о том, что если переустанавливать систему, то переходить на неё. Вопрос только в том, поддерживают ли её GRUB и нужные мне дистрибутивы… И ещё смущает, почему она не пользуется особо популярностью. Я даже не смог найти в Интернете чьи-либо сторонние benchmarks за 2021-2022 годы. В основном, тестируют только ext4, btrfs, xfs и f2fs.

Поставил сейчас на виртуальной машине Debian 11 на jfs, всё прошло без каких-либо проблем.

Не потому ли, что JFS не поддерживает журналирование блоков?

Вообще, ext4 по умолчанию тоже блоки данных не журналирует, только метаданные. Чтобы журналировала и данные, нужно соответствующий параметр при монтировании указать, что повлияет и на быстродействие тоже.

Если ты про has_journal, то он у меня изначально был включен. Разметка делалась из-под Debian 8.