В общем, добавил к тестированию BTRFS, тормозная страшно, если сравнивать с другими.
Да, про проверку при загрузке я, конечно, ступил выше. В fstab во флагах должно стоять 0 2, почему-то все, кроме JFS это игнорировали и проверялись.
Что сделал - 100М файл одновременно и параллельно копировал на точки монтирования с разными файловыми системами 50 раз в разные файлы, потом читал их в /dev/null, потом стирал, писал название файловой системы, потом копировал этот же файл в 100 разных файлов. В момент, когда все потоки успевали вывести название файловой системы, т.е. переходили в длинный этап, с небольшой задержкой рубил питание, делая Force reset виртуалке. Тест повторял несколько раз, каждый раз очищая оставшиеся от предыдущего теста файлы.
Сделал для себя неожиданные открытия. Во-первых, понятно, в ext4 все файлы не влезали (каждая точка монтирования была 10Гб и 100 файлов, соответственно, влезали только при набивании под завязку), поскольку там резерв, но они не влезали и в btrfs... Причем, даже со сжатием. Совершенно не понял прикола с тем, что если cp не могла записать файл по нехватке места, он создавался нулевого размера. И на ext4, и на btrfs. Во-вторых, когда добавил удаление и чтение, самой медленной системой стала ext4. Внезапно. Причем, тормозить стала так, что отставать от остальных систем стала настолько, что те успевали записать другие файлы длинного этапа. Это синоним слову "чудовищно". В лидеры вышла... тадам-м-м, XFS. Но это по скорости. Что мне крайне не понравилось, это то, что сравнивая файлы по размеру, я на XFS один раз увидел поврежденный файл, например, 85, т.е. 84 и 86 были по 100Мб, 87 и далее - нулевого размера, а 85, например, 70Мб. Видимо, сработала параллельная запись данных, точнее, один поток не успел записать что-то. Т.е. надо понимать, что повреждение может быть не только последнего файла. Хотя именно такое поведение предсказывали для JFS, JFS как раз за таким замечена не была.
Во время монтирования поврежденных файловых систем дольше всего проверялась JFS, но это "дольше" длилось секунды три. Остальные вообще незаметно отрабатывали. За время опытов ни одна система не развалилась совсем. Лечились и были готовы работать дальше.
Попробовал ext4 c data=journal, думал, тут она вообще неубиваемой станет. Ну... Как сказать... Нулевые файлы пропали, да. Работать стала просто адски долго. Т.е. перехода к длинному этапу я вообще едва дождался. Остальные все отработали. Те файлы, что записались полностью, были на месте. Файл, на котором дернул питание - огрызком. Собственно, у большинства систем результат почти такой же, только с некоторым отставанием. Т.е. последние несколько файлов были пустыми, а до них файл-огрызок. Учитывая скорость работы ext4 в таком режиме, сомнительное преимущество.
Если дергал питание в скором времени после того, как все потоки отработали, на всех файловых системах файлы были целыми.
В целом, если часто дергают питание, рекомендую поставить UPS :) если защищаться от сбоев, то, у меня складывается мнение, что юзерам я буду ставить JFS (себе на ноут при следующем смене системы, например). Пишет она быстрее и с меньшими потерями при неожиданном выключении. У жены, кстати, на ноуте, живет и несколько нештатных выключений уже пережила. На сервере и для хранилок, судя по всему, лучше XFS нет файловой системы. JFS тут проигрывает по скорости чтения и удаления, а еще червоточинкой сидит какое-то исследование 2005 года, настаивающее, что из-за способа записи метаданных файлы могут пропадать неограниченно по времени записи. Не очень понимаю такую формулировку но боюсь :)