Алексей Федорчук - Вопросы истории: UNIX, Linux, BSD и другие
До недавнего времени в 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, правда, находящейся тогда только в голове создателя, Мэтта Диллона.
