Вопросы истории: UNIX, Linux, BSD и другие
Шрифт:
Затем это безобразие пытались побороть, включив в XFS по умолчанию опцию write barriers, от сей напасти избавляющую. Что, однако, привело к падению быстродействия на некоторых операциях. В частности, удаление большого количества маленьких файлов (а в работе с маленькими файлами XFS не блистала и без этой опции) стало происходить просто удручающе медленно.
При этом проблема потери данных при сбоях до конца решена не была, хотя и не стояла так остро. Однако, с учётом и старых вопспоминаний, отношение к XFS местами было настороженным. Хотя эта система уже давно предлагается по умолчанию в инсталляторах некоторых дистрибутивов, причём отнюдь не самых «мультимедийных» или «промышленных», таких как Zenwalk или Salix.
В итоге, однако,
Отступление. Интересно, что это перекликается с позицией 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. В частности, вследствие многоуровневости всех этих решений. И очевидно, что удлинение «цепочки» уровней в любом случае приводит к снижению надежности: чем больше в ней звеньев, тем вероятней отказ всей цепи.
И тут-то и возникает вопрос: а нельзя ли уменьшить количество уровней, сделать систему более «плоской»? Попыткой ответа на этот вопрос и стали интеригрированные системы размещения данных.
Из
Не в интересах правды, а истины ради нужно заметить, что комплексные системы размещения данных – отнюдь не порождение мира FOSS, их корни лежат в недрах проприетаризма. И первой из них была, видимо, файловая система Veritas (или VxFS), разработанная фирмой Veritas Software и представленная миру в 1991 году. Она же претендует на звание первой в истории мироздания журналируемой файловой системы. Хотя, как говорилось в предыдущем разделе мне известно, JFS – эпоним всех журналируемых ФС – в своей реализации для AIX появилась в 1990 году, так что вопрос приоритета в отношении журналирования остаётся не вполне ясным.
VxFS является основной файловой системой в HP UX, работает также во всех ныне живущих проприетарных UNIX’ах и теоретически может применяться и в Linux’е. Однако о практических примерах такого применения, по крайней мере в не очень промышленной обстановке, я не слышал: VxFS является системой проприетарной и весьма дорогой.
VxFS тесно интегрирована с менеджером логических томов – VxVM. Благодаря чему в ней возможно изменение (в любую сторону) размера файловой системы «на лету», включение различных режимов использования томов – стриппинг данных, их зеркалирование, а также комбинации того и другого, создание избыточных массивов по типу RAID Level 5, изменение внутренней организации данных без остановки работы. Всё это позволяет VxFS (в сочетании с VxVM) претендовать на звание комплексной системы размещения данных.
Впрочем, не меньше к тому оснований было и у AdvFS – файловой системы, разработанной к 1993 году фирмой DEC для своего проприетарного варианта UNIX, именовавшегося сначала OSF/1, затем Digital UNIX, и завершившего свою жизнь под именем Tru64 UNIX. Судьба её была печальной. Снискав заслуженное признание на своей родной платформе DEC Alpha под управлением указанной ОС, она после покупки DEC фирмой Compaq оказалась в загоне. А после того, как Compaq, в свою очередь, был поглощён фирмой Hewlett Packard, использовавшей для своего UNIX’а на платформах HP PA и Itanium только что упомянутую VxFS, AdvFS оказалась совсем не при делах.
В результате HP сделала щедрый дар сообществу свободного софта вообще и Linux-сообществу в особенности: в середине 2008 года исходники файловой системы AdvFS были открыты под лицензией GPv2 – ради максимальной совместимости с ядром Linux. С предложением использовать их в этой ОС если не в качестве системной целостности, то как богатую технологическую базу. Правда, оговорка, что сама HP не заинтересована в дальнейшем развитии AdvFS, заставляла опять вспомнить народную присказку: «Возьми, боже, что мне не гоже».
Да и предложение несколько запоздало: как мы скоро увидим, к тому времени интенсивно развивались и ZFS, и Hammer, и btrfs.
Однако, помимо исходников, HP предоставила также доступ ко всей документации – благодаря чему об AdvFS при желании можно узнать больше, чем о любой другой проприетарной файловой системе для UNIX-подобных операционок. Это избавляет меня от необходимости описания её особенностей. Замечу только, что среди них мы увидим все черты развитой комплексной системы размещения данных. Те самые, которые мы наблюдаем при рассмотреннии устройства, например, ZFS. К обзору истории которой и пора перейти.
Начало истории ZFS
Разработчики ZFS поставили себе честолюбивую цель: создать систему хранения данных, которая отвечала бы всем трем критериям сформулированного ранее идеала. Разработка её проводилась в компании Sun Microsystems, командой под руководством Джеффа Бонвика (Jeff Bonwick) и Мэттью Аренса (Matthew Ahrens). Первоначально название ZFS рассматривалось как аббревиатура от Zettabyte File System, но быстро стало просто условным именованием. Его можно интерпретировать как последнюю точку в развитии файловых систем вообще. И в последующем мы увидим: это недалеко от истины.