>Местами там обозреватель заговаривается. Например, XFS - известнейший тормоз, Местами анонимы - знатные ламера.Кондовые такие, деревянненькие.Иначе бы наш анонимный позорник знал бы что XFS быстр, но только:
1) XFS быстр при работе с БОЛЬШИМИ ФАЙЛАМИ.Порой здорово делая на этом поприще остальных.
2) XFS использует специальную архитектуру которая хорошо размазывается на многодисковые конфигурации.Если у вас что-то типа raid - XFS при правильном подходе сможет выюзать преимущества оного на всю катушку за счет разнесения записей на параллельные, попадающие на разные диски.
2.1) Следствие: работа с большими файлами в параллельном режиме - это то что XFS любит и уважает.Разрывая большую часть конкурентов на этом поле как тузик грелку.
3) В некоторых случаях дефолтные настройки XFS не очень оптимальны.Иногда ему требуется твикинг.
4) В XFS тормозное удаление файлов.Вот тут он тормоз.Да.И средненькая работа с множеством мелких файлов.
Отсюда вывод: если у вас тормозит XFS, значит вы лопухнулись с выбором ФС под задачу или дефолтные настройки под задачу плохо подходят.Это нормально, у любой ФС есть сильные и слабые места.Идеальных файловых систем не бывает - бывают унылые середнячки которые сносно работают на разных типах нагрузок но на "тематических" поприщах сильно сливают более специализированным ФС которым определенный тип нагрузки удобнее чем иные типы нагрузок.Скажем если XFS не ахти для установки на него системы и может даже слить EXT3 (с обычным журналингом), то вот при работе с большими (iso-sized или более) файлами XFS шутя порвет того же EXT3 на британский флаг по скорости чтения\записи файлов например.А уж если параллельный доступ к такому файлу, тут и вовсе EXT3 стушуется и будет натужно хрустеть диском гоняя головы HDD туда-сюда а XFS будет чуть ли не в разы лучше за счет своей архитектуры с несколькими allocation groups.
