Книга: Вопросы истории: UNIX, Linux, BSD и другие

Глава десятая. Из истории файловых систем

Файловые системы и, шире говоря, системы размещения данных вообще – неотъемлемая часть операционных систем. И потому их историю уместно рассказать в этой части книги. К тому же развитие ОС и их систем размещения данных – вещи, очень тесно связанные друг с другом.

Вводные слова

Одна из главнейших задач при работе на компьютере – манипулирование данными: создание, модификация, копирование, перемещение и так далее. И тут первое дело – это организация их размещения. Это понятие включает в себя широкий круг частных вопросов – схемы дисковой разметки, управления дисковыми массивами и логическими томами, файловые системы и их монтирование в файловую иерархию. Они тесно связаны между собой, но традиционно решаются каждая с помощью собственного инструментария.

Однако с некоторых пор в UNIX-подобных операционках получили распространение интегрированные системы размещения данных, объединяющие в себе и файловые системы, и задачи управления массивами и томами, и даже, частично, задачи разметки дисков. Такие системы, как мы скоро увидим, существовали очень давно – со времен доисторического UNIX’а, хотя и в проприетарном исполнении. Ныне среди них представлены и системы свободные, хотя и распространяемые под разными, не всегда совместимыми, лицензиями.

Вне зависимости от того, реализуется ли размещение данных путем отдельных инструментов или интегрированных систем, оно должно обеспечивать выполнение ряда требований. Которые были сформулированы ещё в старом советском анекдоте. Как известно еще с те, атеистических, времен, Господь Бог, создавая человека, хотел сделать его умным, честным и партийным. Но оказалось, что даже он, при всём своём всемогуществе, не смог ему дать больше двух качеств вместе.

Аналогично и с системами размещения данных: разработчики хотели бы видеть их быстрыми, надежными и простыми в обращении. Давайте посмотрим, удалось ли им превзойти Господа.

Дисковая разметка

Говорят, что во времена далекие, теперь почти былинные, файловых систем не было: информация на носители записывалась побитно, без всякой организации в именованные её наборы. Впрочем, такой способ записи данных применялся и много позднее – например, при резервном копировании на стриммерные ленты. Можно обходиться без файловых систем и при записи на стандартные блочные устройства – винчестеры, SSD, компакт-диски. Однако в большинстве случаев данные на носителях блочного типа организуются в виде файлов, а файлы объединяются в файловые системы – плоские, как в древнем DOS’е, древовидные, как во всех UNIX-подобных операционках, или, так сказать, «многодревные», как в Windows. Каковые могут быть созданы непосредственно на носителе как raw-устройстве, но обычно накладываются на дисковые разделы.

До недавнего времени в Linux’е применялась разметка в MS-DOS-стиле, предполагающая возможность разбиения диска на четыре раздела, называемых первичными [primary partitions]; один из них может быть определён как расширенный раздел [extended partition], внутри которого по «матрёшечному» принципу можно создать логические разделы, максимальным числом до 63.

Разметка в MS-DOS-стиле преобладает в дистрибутивах Linux’а и по сей день. Однако всё большее распространение получает разметка в GPT-стиле. Среди её преимуществ – возможность создания на диске до 128 абсолютно равноправных (то есть не разделяющихся на физические и логические) разделов. А в случае использования винчестеров «продвинутого» формата [Advanced Format] и SSD, размер блоков которых равен 4 КБ, она обеспечивает оптимальное выравнивание границ разделов.

Исторически сложилось так, что одному разделу соответствовала одна файловая система. Соответственно, и выходить за границы несущего их устройства файловые системы не могли. И если требовалось работать более чем с одной файловой системой на одном физическом накопителе (а в UNIX-подобных ОС это почти всегда так), то был необходим тщательный расчет дискового пространства для каждой из них: ошибки в расчетах влекли весьма неприятные последствия, вплоть до необходимости переразбиения диска и переустановки ОС вообще.

Правда, дисковые разделы могут не только разделяться, но и объединяться в программные массивы или в группы томов, о которых мы сейчас и поговорим.

Массивы и логические тома

Задача объединения носителей информации особенно актуальна при использовании нескольких физических накопителей, и особенно при их добавлении в работающую систему. В элементарном исполнении это делалось просто (по крайней мере, в UNIX-подобных ОС): второй (новый) накопитель просто размечался по соответствующей для данной ОС схеме, на нем создавалась новая файловая система определенного типа, которая монтировалась в общую файловомую иерархию. Однако выход за границы существующего раздела и диска для файловой системы был по-прежнему невозможен.

Для решения задачи объединения физических носителей в единое логическое устройство и «размазывания» по ним файловых систем традиционно используется два основных способа: RAID (Redundant Array of Independent Disks – избыточный массив независимых дисков) и LVM (Logical Volume Manager – менеджер логических томов).

RAID’ы существуют трёх видов – аппаратные, квази-аппаратные (так называемые Fake RAID) и чисто программные (Soft RAID). Первые дороги и на десктопах почти не встречаются; работа вторых под Linux’ом часто проблематична, так что речь пойдёт в основном о третьих. Впрочем, с точки зрения логики это роли почти не играет.

Логически в любом из RAID’ов несколько дисков (а в Soft RAID – и дисковых разделов) могут просто слиться воедино (Linear RAID), при записи на них может осуществляться расщепление данных [stripping], что приводит к ускорению дисковых операций (RAID Level 0); на объединенных разделах можно создать различные формы избыточности, обеспечивающей восстановление данных при отказах дисков. Из таких избыточных массивов чаще всего используется полное дублирование (RAID Level 1, он же mirror) или избыточность за счет контрольной суммы (RAID Level 5). Наконец, возможно и совмещение стриппинга с дублированием.

RAID любого типа и уровня может разбиваться (и обычно разбивается) на разделы, которые уже несут на себе файловые системы. И, таким образом, позволяют размещать их на нескольких физических устройствах. Однако они не решают второй проблемы размещения данных – необходимости расчета потребного для них дискового пространства и его перераспределения при необходимости.

Этим целям служит технология LVM, объединяющая физические носители в группы логических томов, разделяемых на собственно логические тома, которые, в свою очередь, разбиваются на экстенты – объединения физических блоков дисковых устройств. Логические тома предстают перед операционной системой как обычные разделы, каждый из которых может нести свою файловую систему. При этом технология LVM даёт возможность при необходимости перераспределять физическое пространство носителей между ними посредством добавления или отнятия экстентов на лету, не только без переразметки дисков, но и без перезапуска системы.

Технология LVM может обеспечить, как и RAID Level 0, стриппинг данных между физическими томами с целью повышения быстродействия файловых операций. А в сочетании с Soft RAID позволяет и создавать массивы с полной (зеркалирование) или частичной (за счёт контрольных сумм) избыточностью, повышающей надёжность. Таким образом, LVM выполняет оба поставленных условия: слияние дискового пространства, в том числе и вновь подключаемых накопителей, и возможность его перераспределения между существующими файловыми системами, да ещё и с бонусом в качестве повышения быстродействия. Комбинация же LVM и Soft RAID позволяет и повысить надёжность. Казалось бы, чего ещё не хватает для счастья?

Чтобы ответить на этот вопрос, следует вспомнить тезис Господа Бога об уме, честности и партийности. То есть в нашем случае – о быстроте, надежности и простоте использования. В соответствие с чем видим:

   • либо быстрое и простое решение на основе RAID Level 0, не блещущее надёжностью;

   • либо надёжное решение без ощутимой потери быстродействия на основе одного из RAID с избыточностью, не являющееся, однако, эталоном простоты; влекущее, кроме того, ещё и потерю дискового пространства вплоть до пятидесятипроцентной (в случае RAID Level 1);

   • либо, наконец, относительно надёжное и потенциально быстрое решение при использовании технологии LVM – однако о простоте здесь можно забыть сразу: если установить LVM позволяет инсталлятор почти любого современного дистрибутива, то управление логическими томами и по сей день задача не из самых тривиальных.

К тому же мы забыли о файловых системах. А они вносят свою, и немалу, лепту в соотношение «ума, честности и партийности».

Файловые системы

Изначальная файловая система Unix носила имя s5fs (то есть файловая система System V). По свидетельству современников, была она отменно медленной, да еще и не допускала имен файлов из более чем 14 символов. А поскольку в те времена в Университете Беркли также разрабатывалась версия Unix (именовавшаяся BSD Unix – предтеча всех современных BSD-систем), то берклианцы решили поправить дело. И создали в 1983 году файловую систему, названную FFS (Fast File System, где первое слово символизировало ее быстроту сравнительно с s5fs).

Поскольку FFS, как и прочие разработки берклианцев, была свободной, создатели проприетарных Unix'ов не погнушались включить поддержку FFS в очередную версию канонической System V. А уже от нее и произошло, прямо или косвенно, большинство современных файловых систем UNIX, как проприетарных, так и свободных. Хотя для нашего повествования имеет значение только UFS из FreeBSD.

Вообще говоря, UFS расшифровывается просто как файловая система Unix (Unix File System). И под этим именем известны и файловые системы других ОС этого семейства, отнюдь не идентичные UFS из FreeBSD (например, файловая система SunOS и Solaris). Так что некоторая неопределенность терминологии имеет место быть.

Однако нас интересует только собственно UFS из FreeBSD. Ибо именно в ней впервые появилось понятие группы цилиндров с собственной структурой. Они призваны были обеспечить минимизацию перемещения головк винчестера и, соответственно, быстродействие файловых операций.

Другим новшеством UFS, появившемся несколько позже, стал парадоксальный механизм Soft Updates, приводящий к росту одновременно и надёжности, и быстродействию файловой системы. Он, с одной стороны, выполнял контроль за последовательностью зависимых обновлений (тем самым способствуя целостности состояния файловой системы и, следовательно, её надёжности). С другой же стороны, при включенииSoft Updates происходила группировка нескольких обновлений в единую атомарную операцию синхронного обращения к диску. Что и вызывало рост быстродействия файловых операций.

И действительно, по производительности UFS+Soft Updates была вполне сопоставима с файловой системой Linux'а – ext2, хотя последняя по умолчанию работала в асинхронном режиме, а UFS – в частично синхронном (с немедленной записью метаданных и отложенной – блоков данных). А в отношении надёжности они были просто не сопоставимы: в те далёкие годы, да ещё и не иобильные с точки зрения бесперебойников, полный развал ext2 при «мёртвом» зависании или сбое питания был делом достаточно обычным, тогда как с UFS у меня такого не случалось ни разу.

В 5-й ветке FreeBSD на смену UFS пришла её усовершенствованная, 64-битная, модификация. Которая привнесла немало удобств (в частности, выполнение операции fsck в фоновом режиме на смонтированных файловых системах), однако ценой этого было быстродействие – точнее, его потеря. Не случайно именно тогда от FreeBSD отпочковалась DragonFly с её файловой системой Hammer, правда, находящейся тогда только в голове создателя, Мэтта Диллона.

В Linux'е же поначалу использовалась файловая система MINIX, созданная Эндрю Таненбаумом для своей одноимённой ОС на базе классической s5fs, без всякого влияния берклианских наработок. Она имела массу ограничений, в частности, на максимальный размер в 64 МБ (вследствие своей 16-битности), на длину имени файла (14 символов). Что и послужило причиной для её усовершенствования, выполненных Линусом Торвальдосм одновременной с работой над ядром. Что в итоге вылилось в файловую систему extfs (Extended File System), уже 32-битную, с обычными для этого класса поддержкой разделов до 2 ГБ и длины имён файлов до 256 символов. Хотя MINIX долгое время использовался в Linux'е для его загрузочных дискет, а поддерживается ядром чуть ли не по сей день.

Однако и на extfs творческая мысль разработчиков не остановилась. Для ликвидации некоторых присущих ей ограничений, например, в атрибутах файлов, в 1993 году Реми Кард (Remi Card) разработал улучшенную её модификацию, названную ext2. Именно она стала на долгие годы стандартной для ОС Linux. И используется по сей день, оставаясь эталоном быстродействия.

Думаю, каждого, кто начинал знакомство с Linux’ом во времена безраздельного господства файловой системы FAT в DOS/Windows, ext2fs поражала скоростью выполнения всех файловых операций. Что было обусловлено эффективностью их кэширования и полностью асинхронным режимом работы. За что, как уже только что было сказано, приходилось платить надёжностью – сбой системы по любой причине влёк за собой тяжкие последствия, вплоть до полного разрушения файловой структуры. Но и даже когда до полной катастрофы дело не доходило, отказы (например, по питанию) вызывали за собой долгую и нудную процедуру проверки целостности файловой системы.

Для решения проблемы надёжности файловой системы (они, хотя и в различной степени, касались всех UNIX'ов) предлагались различные механизмы – Soft Updates, о котором только что говорилось, был одним из них. Однако магистральная линия развития файловых систем пошла по пути так называемого журналирования. Суть его в том, что сведения о файловых операциях записываются в специальный файл журнала до того, как эти операции будут фактически выполнены. Это дает возможность после любого сбоя «откатить» файловую систему до последнего непротиворечивого состояния. Оборотной стороной чего, как обычно, яв.ляется снижение быстродействия – различное для отдельных файловых систем и видов файловых операций.

Эпонимом журналируемых файловых систем стала JFS, разработанная IBM для собственных RISC-станций и своего же варианта UNIX — AIX (1990-й год). Затем, в варианте JFS2, она была портирована сначала на серверную версию OS/2 (конец 90-х годов), бившуюся тогда в последней стадии агонии, а вслед за тем — и на Linux, разумеется. Где она и прижилась под именем просто JFS. И стала, кажется, первой «чужой, но породнившейся» файловой системой, поддержка которой была официально включена в каноническую версию ядра — точной даты не помню, но где-то аккурат рядом с рубежом тысячелетий.

Однако широкого признания Linux-реализация JFS не снискала – ни тогда, ни в последствии. В частности, и вследствие исключительной медлительности – в этом отношении она могла поспорить только с UFS2 из FreeBSD. Причина заключалась в том, что в Linux-версии разработчики отказались от собственного кеширования файловых операций (наличествовавшего в реализациях JFS для AIX и OS/2), положившись на то, что эта функция будет выполняться ядром.

Следующей журналируемой файловой системой в Linux стала ReiserFS, разрабатывавшаяся специально для этой ОС Хансом Рейзером (Hans Reiser) и сотрудниками его фирмы Namesys, начиная с конца 90-х годов. Официальную поддержку в каноническом ядре она обрела с выходом его версии 2.4.

Коньком ReiserFS (кроме собственно журналирования) была работа с очень большими массивами очень маленьких файлов – то есть файлами меньше логического блока файловой системы (обычно в диапазоне от 512 байт до 4 Кбайт). А таких в любой UNIX-системе действительно несчётное множество. Типичный пример – дерево портов FreeBSD или портежей Gentoo.

В большинстве файловых систем для таких мини-файлов существует как свой inode (информационный узел, содержащий метаинформацию о файле), так и блок данных, что приводит как к расходу дискового пространства, так и снижению быстродействия файловых операций. В частности, именно в этом причина катастрофической задумчивости файловой системы FreeBSD (как старой, UFS, так и новой, UFS2) при работе с собственной же системой портов.

В файловой системе ReiserFS в таких случаях отдельные блоки под данные не выделяются -- она умудряется запихать данные файла непосредственно в область его же inode. За счет этого и дисковое пространство экономится, и быстродействие возрастает -- буквально в несколько раз по сравнению со всеми прочими файловыми системами. Повторяю, речь идёт сейчас только об операциях с очень маленькими файлами – на всех прочих такого превосходства, разумеется, нет и близко.

Такое обращение с мелкими файлами ReiserFS послужило причиной возникновения легенды о ее ненадежности. Ибо при крахе файловой системы (то есть разрушении служебных областей) данные, размещенные совместно со своими inodes, вместе с ними же и пропадают -- причем безвозвратно. Тогда как в тех файловых системах, где inodes и блоки данных всегда разобщены в разных областях дискового пространства, данные теоретически можно восстановить. Так, для ext2/ext3 даже существуют средства, позволяющие это сделать.

Однако, как и всякая легенда, эта лишь производит впечатление достоверности. Во-первых, безвозвратная потеря данных относится лишь к очень маленьким файлам. Среди пользовательских таковых практически не бывает, а все прочие же легко восстанавливаются из дистрибутива.

Во-вторых, говоря о возможности восстановления данных из блоков, утративших привязку к своим inodes, я не случайно употребил определение «теоретическая». Потому что на практике это занятие чрезвычайно трудоемкое, не дающее гарантированного результата. Каждый, кому приходилось этим заниматься, согласится, что предаться ему можно только от полной безысходности. И это относится ко всем файловым системам Linux. Так что этим аспектом при выборе файловой системы можно пренебречь.

По суммарному быстродействию ReiserFS была однозначно быстрее всех остальных одновозрастных ей журналируемых файловых систем, а по некоторым показателям могла с успехом потягаться и с ext2, бывшей тогда эталоном быстродействия.

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

Главная же проблема ReiserFS была в другом – в совместимости. Сначала она «из коробки» поддерживалась очень малым количеством дистрибутивов, и совсем не поддерживалась никакими другими ОС, даже соплеменными BSD. Только в DragonFly довольно быстро реализовали модуль её поддержки в режиме «только для чтения» – но отношение этой операционки к другим файловым системам всегда было особым.

Проблема с совместимостью для ReiserFS возникла и в последние годы. Если раньше она «ещё не поддерживалась» многими дистрибутивами, то теперь один за зругим дистрибутивы её «уже не поддерживают». Видимо, скоро она исчезнет и из ядра Linux'а.

Чтобы более не возвращаться к этому вопросу, замечу, что на протяжении ряда лет Ханс Рейзер и фирма Namesis разрабатывали файловую систему Reiser4. Это не была очередная версия ReiserFS (развитие той остановилось на версии 3.6.X), а существенно новая разработка, в детали которой вдаваться сейчас не буду: до полной пригодности к практическому применению она доведена не была, и теперь уже, наверное, никогда не будет. О некоторых причинах можно догадаться, прочитав соответствующий раздел в книге Мир FOSS. Заметки гуманитария, имеющей место быть в Библиотеке Блогосайта.

Зато идеалом с точки зрения совместимости оказалась ext3fs – журналируемая модификация классической ext2: представленная на рубеже тысячелетий Стивеном Твиди (Stephen Tweedie), она, однако, получила поддержку в ядре Linux'а не сразу, а даже позже, чем ReiserFS. Однако после этого была включена практически во все дистрибутивы и, следовательно, могла быть прочитана почти на любой Linux-машине. Более того, она осталась полностью совместимой с ext2 по формату. То есть прародительница превращалась в ext3 лёгким движением руки – точнее, добавлением к ней журнала с помощью утилиты tune2fs не только без остановки машины, но даже без отмонтирования целевого носителя. Не менее проста была и обратная процедура – ext3 можно было просто перемонтировать без журналирования, и тогда она становилась самой обычной ext2. Утилиты для работы файловой системой (создания, проверки и так далее) для ext2 и ext3 также были одними и теми же.

В ext3 (и это была её особенность) предусматривалось три режима работы:

   1. журналирование с обратной записью (writeback), когда в файл журнала записываются только изменения метаданных файлов;

   2. последовательное, или обычное (ordered), задействуемое по умолчанию – также с журналированием только метаданных, но с группировкой связанных с ними данных в единую транзакцию;

   3. полное журналирование (journal), когда все изменения и метаданных, и блоков данных фиксируются в журнале, а только потом уже переносятся на диск.

Теоретически считается, что от первого режима к третьему возрастает надёжность файловой системы, но уменьшается быстродействие. В отношении быстродействия – вопрос спорный: Дениэл Роббинс (Daniel Robbins) приводи случаи, когда режим полного журналирования оказывался быстрее не только последовательного, но даже журналирования с обратной записью. По моим наблюдения, показатели быстродействия ext3 были вообще невоспроизводимы и от режима журналирования не зависели вовсе. И в любом случае уступали интегральной скорости работы в ReiserFS (не говоря уже о ext2), будучи сопоставимыми с UFS (не UFS2!) при включении Soft Updates.

Отступление для тех, кто не знает: Дениэл Роббинс был не только создателем дистрибутива Gentoo, но и автором большого количества технических статей, публиковавшихся на сайте IBM для разработчиков свободного софта. Среди этих статей (кстати, обладающих незаурядными литературными достоинствами) было Руководство по продвинутым файловым системам, известное в русском переводе Владимира Холманова. А размещались эти переводы первоначально на сайте линуксоидов города Ярославля, созданном в незапамятные времена Александром Благиным и существующем, как ни странно, до сих пор.

Что же до надёжности, то ext3 в режиме полного журналирования снискала репутацию абсолютно «непробиваемой» системы для использования на серверах, а в режиме последовательном считалась оптимальной для настольного применения.

Спорить на счёт устойчивости ext3 не буду. Но моё личное мнение по этому вопросу таково: устойчивость файловой системы вообще зависит от личного везения применителя. Особенно если речь идёт о сравнении ext3 и ReiserFS: жалоб на развал при аварийном завершении работы по поводу первой я слышал не меньше, чем относительно второй.

По собственному же опыту – банальное выключение питания в ходе обычной пользовательской работы, как правило, безболезненно переносят все журналируемые файловые системы, кроме, в некоторых случаях, XFS, о которой скоро пойдёт речь.

Тем не менее, как я уже сказал, репутация часто оказывается самым весомым фактором – и на протяжении долгого времени ext3 предлагалась по умолчанию инсталляторами большинства дистрибутивов.

Ныне, однако, ext3 почти вышла из употребления. Если ext2 всё ещё нередко применяется в ряде специальных случаев (например, для носителей небольшого объёма или там, где журналирование в принципе не имеет смысла), то в амплуа файловой системы общего назначения нынче выступает ext4. Она была разработана Эндрю Мортоном (Andrew Morton) в качестве экспериментальной в 2006 году, и в 2008 принята в ядро Linux'а как стабильная. С тех пор она развивается и поддерживается командой разработчиков, из которых наиболее известен Теодор Цо (Theodore Ts'o).

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

Однако я забежал вперёд – ext4 не стала ещё достоянием истории и, похоже, не собирается это делать в обозримом будущем. Потому что следующей журналируемой системой по очередности появления в Linux'е стала XFS. Хотя создана она была много раньше – в 1994 году, усилиями фирмы Silicon Graphics, для её собственного варианта UNIX'а – IRIX. И была одной из первых 64-разрядных файловых систем.

К весне 2001 года относится открытие исходников XFS под лицензией GPL и разработка Linux-реализации. Долгое время её поддержка ядром этой ОС обеспечивалась только сторонними патчами – официально она была включена в ядро только в 2004 году. Да и после этого какой-то период по умолчанию поддерживалась не всеми дистрибутивами.

Но постепенно XFS утвердилась в Linux'е в качестве стандартной, чему способствовали её особенности, хорошо вписавшиеся в изменившиеся реалии окружающего мира. Если ReiserFS лучше всего показывала себя в обращении с маленькими файлами, то «коронкой» XFS была работа с очень большими файлами на очень больших файловых системах. Что и не удивительно, если вспомнить о её происхождении: фирма Silicon Graphics (ныне SGI) издревле была ориентирована на профессиональные средства в области графики и мультимедии, данные которых требовали большого объёма дисковой памяти и организации её в виде больших файлов. К середине нулевых годов это оказалось востребованным и в Linux'е.

Однако это было не единственной причиной распространения 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. В частности, вследствие многоуровневости всех этих решений. И очевидно, что удлинение «цепочки» уровней в любом случае приводит к снижению надежности: чем больше в ней звеньев, тем вероятней отказ всей цепи.

И тут-то и возникает вопрос: а нельзя ли уменьшить количество уровней, сделать систему более «плоской»? Попыткой ответа на этот вопрос и стали интеригрированные системы размещения данных.

Из истории систем размещения

Не в интересах правды, а истины ради нужно заметить, что комплексные системы размещения данных – отнюдь не порождение мира 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, но быстро стало просто условным именованием. Его можно интерпретировать как последнюю точку в развитии файловых систем вообще. И в последующем мы увидим: это недалеко от истины.

Результаты работы над ZFS были представлены миру в августе 2004 года. А в 2006 году она была включена в штатный состав OS Solaris 10 (релиз 6/06). То есть, подобно своим предшественницам, она также была проприетарным продуктом. И пользователям свободных UNIX-подобных систем поначалу от ее существования было ни холодно, ни жарко. Однако период камерного существования ZFS продолжался недолго – уже в ноябре 2005 года, то есть до включения в Solaris, ее поддержка была интегрирована в открытый её вариант, OpenSolaris. Ибо она основывалась на том же ядре SunOS 5, что и коммерческий прототип.

Исходники ZFS распространяются, как и собственно OpenSolaris, под лицензией CDDL (Common Development and Distribution License). Эта лицензия, базирующаяся на Mozilla Public License (MPL), не влияет на общую лицензию проекта, в состав который включены CDDL-компоненты. И потому оказывается совместимой с большинством свободных лицензий. За исключением... какой? Правильно, GPL во всех её проявлениях.

Разумеется, ZFS была задействована в клонах openSolaris, таких, как BeleniX, SchilliX и, в первую голову, в Nexenta OS. Правда, последняя развивалась в направлении коммерческой системы хранения данных, а о числе пользователей остальных можно было только гадать.

Некоторое время ZFS была доступна пользователям Macintosh’а – в Mac OS X Leopard от осени 2007 года. Правда, ходившие перед её выходом слухи, что она будет там файловой системой по умолчанию, оказались несколько преувеличенными: поддержка ZFS оказалась опциональной и лишь в режиме «только для чтения». А в последующих версиях ОСей семейства кошачьих вообще исчезла и, видимо, уже не возродится.

Так что для широких народных масс ZFS по прежнему оставалась недоступной. Пока... пока ее не портировали под FreeBSD в 2007 году, и официально не включили её поддержку в 7-ю версию этой ОС, вышедшую в начале 2008 года. В чём, как и в дальнейшем её развитии, основная заслуга принадлежит Павлу-Якубу Давидеку (Pawel Jakub Dawidek) и Ивану Ворасу (Ivan Voras). Правда, до недавнего времени ZFS нельзя было задействовать при установке FreeBSD средствами её штатного инсталлятора и конфигуратора sysinstall. Однако это без труда можно было осуществить в дальнейшем руками. В том числе и разместить на ZFS корень файловой иерархии. А с выходом FreeBSD версии 10.0 она стала доступна применителям этой ОС, что называется, «из коробки».

С самого начала поддержки ZFS во FreeBSD появилась и возможность задействовать её, что называется, «искаропки», в десктоп-ориентированном клоне последней – PC-BSD. А с переходом FreeBSD, начиная с версии 9.0, на новую программу установки – BSDInstall, эта функция распространилась и на материнскую систему.

Успех ZFS во FreeBSD, где она стала если не главной файловой системой, то добилась равноправия с UFS2, послужил примером для других BSD-систем. Так, ныне ZFS поддерживается в NetBSD – эта работа была начата Оливером Голдом [Oliver Gould] летом 2007 года в рамках акции Google Summer of Code. А в 2009 году Адам Хамсик [Adam Hamsik] интегрировал её код в ядро NetBSD. Правда, насколько я понимаю, использование ZFS в этой операционке рекомендуется только в экспериментальных целях.

Наконец, одно время в списках рассылки DragonFlyBSD активно обсуждался вопрос о портировании ZFS и на эту операционку. Потом, правда, разговоры эти стихли – вероятно, в связи с активной разработкой файловой системы Hammer, обладающей во многом аналогичными возможностями. Однако, учитывая лёгкость адаптации к DragonFlyBSD любых сторонних файловых систем, можно не сомневаться, что поддержка ZFS на уровне обмена данными будет включена в неё тогда и если (или если тогда), когда (и если) это кому-то понадобится.

Таким образом, пользователям большинства BSD-систем ZFS или уже доступна как нативная, или может стать доступной в ближайшее время.

Из истории юриспруденции

А что же Linux, спросите вы меня? Как обстоит дело с поддержкой ZFS в самой массовой из свободных UNIX-подобных операционных систем нашего времени? А вот с Linux’ом все оказывается гораздо сложнее. Ибо не зря поминали мы выше лицензию CDDL. Которая сама по себе очень даже свободная, и не накладывает почти никаких ограничений на распространение защищаемых ею программ.

В частности, не запрещает CDDL и коммерческого распространения производных продуктов в виде бинарников, без открытия исходных текстов. Как известно, не накладывает такого ограничения и лицензия BSD, почему включение кода поддержки ZFS в любые BSD-системы и проходит юридически безболезненно, как мы только что видели на примере FreeBSD.

А вот с лицензией GPL обеих актуальных версий (v2 и v3) CDDL входит в диалектическое противоречие. Ибо любые продукты, производные от программ под GPL, вне зависимости от формы распространения, должны сопровождаться исходными текстами. Что делает юридически невозможным включение кода поддержки ZFS непосредственно в ядро Linux, распространяемое, как известно, на условиях GPLv2.

Кроме того, невозможность включения в ядро Linux кода поддержки ZFS объясняется тем, что GPL требует распространения всех основанных на ней продуктов под GPL же, тогда как CDDL – сохранения её для «своих» компонентов.

Правда, часть кода ZFS была открыта под GPL с тем, чтобы соответствующий патч можно было включить в загрузчик Grub. Это обеспечило возможность загрузки Open Solaris непосредственно с ZFS-раздела. Однако оказалось недостаточным для полноценной реализации этой системы, которую можно было бы распространять под данной лицензией.

Впрочем, не будучи юристом, ломать голову над лицензионными вопросами не буду, и моим читателям не советую, ибо понять это всё равно невозможно. А достаточно лишь запомнить, что всеми резонными и юридически подкованными людьми признано, что поддержки ZFS в ядре Linux быть не может.

Таким образом, сложилась абсурдная, с точки зрения здравого смысла, ситуация: два программных продукта под свободными лицензиями (обсуждать вопрос, какая из них «свободней другой», мы сейчас не будем), созданные друг для друга, как Huggies и... э-ээ... место пониже спины (дальнейшие события показали, что технических сложностей при портировании ZFS на Linux практически нет), невозможно было использовать в составе одного проекта. По крайней мере, для законопослушных граждан, чтущих... нет, не уголовный кодекс, а принципы свободного программного обеспечения.

И, разумеется, здравомыслящие люди попытались эту ситуацию разрешить. И первая такая попытка была предпринята ещё в 2006 году в рамках Google Summer of Code. Основывалась она на поддержке ZFS через FUSE (Filesystem in Userspace). Поскольку модуль FUSE работает как пользовательское приложение, необходимости во включение кода ZFS в ядро Linux нет, что снимает все юридические вопросы. Однако встают вопросы другие – производительности и устойчивости.

Проект ZFS-FUSE развивается по сей день, хотя и не очень быстрыми темпами. Правда, находясь в стадии хронической бета-версии, он до сих пор рассматривается как сугубо экспериментальный. Да и в любом случае в таком виде ZFS выполнять свои функции – быть надёжным хранилищем данных большого объёма – скорее всего, не сможет.

Так что ZFS-FUSE нельзя считать кардинальным решением вопроса с этой системой размещения данных в Linux. А на то, что в его ядро будет встроена собственная реализация ZFS, рассчитывать не приходится.

ZFS on Linux: технология против крючкотворства

И тем не менее, решение этой проблемы нашлось – и решение столь же изящное, сколь и очевидное. Его предложил весной 2010 года Брайан Белендорф (Brian Behlendorf), некогда один из основных разработчиков web-сервера Apache. Он создал модуль поддержки ZFS, который собирается и может распространяться отдельно от ядра, сохраняя прародительскую лицензию CDDL. А поскольку последняя, как уже говорилось, является лицензией «пофайловой», этим самым обходится антагонистическое противоречие – запрет на распространение продуктов, в которых смешан код, лицензируемый под CDDL и GPL.

На базе разработки Брайана возникло сразу два проекта. Первый осуществлялся индийской компанией KQ Infotech, которой уже в сентябре 2010 года удалось выпустить работоспособный, пригодный для тестирования патч Linux-ядра с реализацией файловой системы ZFS. А в январе следующего, 2011, года появилась финальная его версия, доступная тогда в исходниках и в виде двоичных пакетов для Fedora 14, RHEL6, Ubuntu 10.04 и 10.10.

Однако весной того же года KQ Infotech была куплена фирмой STEC, занимающейся производством SSD-накопителей, каковых, впрочем, в наших палестинах никто не видел. И работы по дальнейшему развитию нативной поддержки ZFS были свёрнуты. Хотя исходники модуля и сопутствующих компонентов до сих пор доступны, последнее их обновление происходило около назад. А информации о дальнейшей судьбе проекта с тех пор не появлялось.

Однако сам Брайн продолжал свою работу – вместе с сотрудниками Ливерморской национальной лаборатории, каковая, будучи в подчинении Министерства энергетики США, занимается не только вопросами ядерного оружия (эвфемизмы вроде Минсредмаша в ходу не только в бывшем Советском Союзе), но и разработкой суперкомьютеров. В результате скоро возник проект ZFS on Linux, в рамках которого модуль поддержки ZFS и сопутствующие утилиты поддержки, портированные из Solaris – так называемый SPL (Solaris Porting Layer), были доведены до ума, и к началу 2011 года стали пригодны для использования в экспериментальном режиме. А к настоящему времени, несмотря на формальное сохранение статуса release candidatе, порт ZFS on Linux можно считать готовым к практическому применению.

Правда, майнтайнеры основных дистрибутивов не торопились включать поддержку ZFS в свои системы даже в качестве дополнительных неофициальных пакетов. Подозреваю, что не столько из косности и лени, сколько из-за очередной сложности: видимо, по всё тем же лицензионным ограничениям модули zfs и spl приходится привязывать к фиксированной версии (и даже конкретной сборке) ядра Linux. Что, при регулярных, даже корректирующих, обновлениях последнего требует и их пересборки.

Тем не менее, разработчики проекта воплотили результаты своей работы в виде дополнительного (так называемого PPA) репозитория для Ubuntu. А также сочинили подробные инструкции по собственноручной сборке пакетов в форматах RPM и Deb (ссылки можно найти на странице проекта).

Достаточно подробно включение ZFS описано в Gentoo Wiki. А майнтайнеры её клона, дистрибутива Sabayon, прославившиеся своей склонностью к экспериментам, включили поддержку ZFS почти «искаропки»: соответствующие модули подгружаются при старте с LiveDVD и могут быть опробованы в «живом» режиме. Хотя штатного способа установки системы на ZFS в инсталляторе этого дистрибутива, всё из-за тех же юридических заковык, и не предусмотрено. Но нет и причин, препятствующих любому благородному дону установить этот дистрибутив на ZFS в любом виде, хоть и корня файловой иерархии. Если ему этого хочется, конечно.

Оглавление книги