Алексей Федорчук - Вопросы истории - UNIX, Linux, BSD и другие

Однако это было не единственной причиной распространения XFS: она (с некоторыми оговорками, о которых я скажу чуть позже) отличалась также впечатляющей производительностью и высокой надёжностью. Причём в полном блеске показывала своё быстродействие на многодисковых устройствах (multiple devices), то есть на аппаратных и программных RAID'ах, которые тоже получили широкое распространение в это время.

Однако, говоря ранее о быстродействии и надёжности XFS, я не случайно сделал оговорку. Дело в том, что это единственная файловая система, в которой теоретические ожидания (обратная корреляция между этими факторами) воплощается в действительность. В ранних версиях её Linux-реализации, которые действительно были завидно быстры, имело место так называемое «обнуление файлов» при сбое питания.

Затем это безобразие пытались побороть, включив в XFS по умолчанию опцию write barriers, от сей напасти избавляющую. Что, однако, привело к падению быстродействия на некоторых операциях. В частности, удаление большого количества маленьких файлов (а в работе с маленькими файлами XFS не блистала и без этой опции) стало происходить просто удручающе медленно.

При этом проблема потери данных при сбоях до конца решена не была, хотя и не стояла так остро. Однако, с учётом и старых вопспоминаний, отношение к XFS местами было настороженным. Хотя эта система уже давно предлагается по умолчанию в инсталляторах некоторых дистрибутивов, причём отнюдь не самых «мультимедийных» или «промышленных», таких как Zenwalk или Salix.

В итоге, однако, работа с мелкими файлами была оптимизирована за счёт заимствования из ext3 отложенного журналирования – хотя реальное воплощение этого ожидается только в светлом будущем ядра Linux версии от 3.3. Что же до потери данных – это решается ещё проще: разработчики предлагают больше внимания уделять состоянию аппаратуры, в частности, и приобретению источников бесперебойного питания, и поменьше слушать страшных баек об исчезнувших в результате сбоя непреходящих ценностей.

Отступление.Интересно, что это перекликается с позицией Google. Как-то в сеть просочилась информация, что на серверах этой компании используется исключительно ext4 – и в режиме без журналирования (without journal). Как я недавно говорил, теоретически это должно обеспечивать максимальную производительность. Что же до неизбежного в таком случае риска нарушения целостности файловой системы при сбоях – в Google предпочитают бороться с этим путём обеспечения качественного электропитания. Впрочем, надо заметить, что своё решение Google как панацею от всех бед отнюдь не пропагандируют. Видимо, опять таки помня, что водка, легко доступная министру, не всегда по карману не только бичу, но даже простому инженеру.

Изменение отношения к XFS совпали с изменением модели её развития. Фирма-создатель, ныне носящая имя SGI, постепенно отстранялась от дальнейшей её разработки – в последние годы она осуществлялась в основном силами программистов, по совместительству являющихся сотрудниками Red Hat. В конце концов SGI отказалась от поддержки XFS вообще, и ныне эта файловая система продвигается Red Hat'ом. В частности, она будет файловой системой по умолчанию в RHEL 7.

Рассказ о традиционных файловых системах уместно закончить упоминанием файловой системы Tux3. Это экспериментальная файловая система, развиваемая Дениэлем Филиппсом (Daniel Phillips) на протяжении уже пятнадцати лет, но так никогда и не анонсировавшаяся в качестве окончательного релиза. Отличительной её особенностью является версионная модель. То есть каждый файл в ней существует в виде нескольких разновременных вариантов, что в случае сбоев выполнять откат до последнего работоспособного.

Впрочем, когда мы эту файловую систему увидим – не ясно. Её разработчик лет пять назад в одном интервью высказался по сему поводу очень оптимистично: это случится раньше, нежели портирование на Linux файловой системы Hammer из DragonFly (о ней будет сказано позднее). Учитывая, что с тех пор никто вроде бы и не начинал работы по продвижению Hammer'а в Linux – времени у Дениэла ещё вдоволь.

Резюмирую затянувшийся базар о файловых системах. Можно видеть, что с точки зрения простоты использования ни в одну из файловых систем Linux’а бросить камень рука не подымется: создание и монтирование их никаких трудностей не сулит. Так что требование «партийности» для них выполняется, пожалуй, при любых соотношениях «ума» и «честности». Но эта ситуация сохраняется, пока мы не начинаем комбинировать «ум, честность и партийность» файловых систем с аналогичными качествами систем управления RAID’ами или с LVM. В частности, вследствие многоуровневости всех этих решений. И очевидно, что удлинение «цепочки» уровней в любом случае приводит к снижению надежности: чем больше в ней звеньев, тем вероятней отказ всей цепи.