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

Однако открытие исходников SunOS и её обрамления спровоцировало также и несанкционированную старшими партийными товарищами активность в виде клонов. Причём первый из них, ShilliX, был представлен Георгом Шиллингом (известным разработкой утилиты cdrecord) буквально через несколько дней после данного события. Вслед за чем появились такие клоны (или дистрибутивы?) OpenSolaris, как BeleniX, Nexenta и MilaX.

Затем последовало приобретение Sun'а фирмой Oracle и закрытие разработки OpenSolaris -- ей на смену пришёл бесплатный, но не открытый Solaris «для нищебродов». Что вызвало появление свободного форка – illumos, продолжавшего развития SunOS, и разрабатываемого на его основе дистрибутива OpenIndiana, явившейся преемницей OpenSolaris.

Это была, так сказать, генеральная линия комсомола, не примирившегося с засильем партийных геронтократов из официального Solaris'а и классово чуждых буржуинов Oracle. Однако наряду с ней образовался и левый уклон.

Выше я упоминал клоны (или дистрибутивы?) OpenSolaris. Из них SchilliX как-то развивается и по сей день -- но это система, ни в коем случае не предназначенная для конечного пользователя (честно говоря, я так и не понял, для кого она предназначена, кроме её собственного разработчика). Прочие же системы не пережили продажи Sun'а и фактического сворачивания головного проекта, OpenSolaris. Но если BeleniX и MilaX тихо канули в Лету, то Nexenta породила сразу две линии систем.

Первой была Nexenta сама по себе -- своеобразная надстройка инфраструктуры Debian над SunOS и её userland'ом. Однако и она как самостоятельный продукт прекратила своё развитие довольно быстро. Ныне это своего рода основа для NexentaStor -- специализированной коммерческой системы для хранилищ данных, использующей преимущества ZFS. А вот вторая линия её развития имела неожиданное продолжение -- в виде ориентированной на десктопы системы StormOS, которая своей быстротой и компактностью вызывала ассоциации с теми дистрибутивами Linux'а, которые я некогда назвал системами быстрого развёртывания.

Система StormOS меня некогда очень заинтересовала, однако век ей был отпущен недолгий: уже через год на её официальном сайте сообщения о дальнейшем развитии стали носить очень уклончивый характер. И я почти забыл о ней -- мало ли в бозе усопших дистрибутивов UNIX-подобных систем мне довелось видеть на своём веку. Но однажды, зайдя на полумёртвый сайт проекта StormOS, я неожиданно обнаружил на нём следы очередного всхода – DysonOS, возникший в сентябре 2012 года.

По агентурным данным, разработчиком Dyson является наш соотечественник, Игорь Пашев. И она представляет собой продукт дальнейшей интеграции Solaris и Linux в его Debian-ипостаси. Если в Nexenta и StormOS (как и в современной OpenIndiana) Debian'овские механизмы накладываются на ядро и userland от Solaris'а, то в Dyson последний планомерно замещается своими GNU-аналогами. В настоящее время от исходной системы, кроме ядра и специфичных служб обеспечения (SMF, DTrace, ZFS) сохраняется также собственная LibC, которую автор в ближайшее время планирует заменить на glibc.

Разработка Dyson находится на достаточно ранней стадии, и кое-что из критически важного для конечного пользователя в ней не реализовано. Однако самое интересной в этой системе -- то, что в существующем виде она работает. И есть шанс, что она будет развиваться и дальше, храня наследие Solaris в мире FOSS.

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

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

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

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

Однако с некоторых пор в 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-подобных ОС): второй (новый) накопитель просто размечался по соответствующей для данной ОС схеме, на нем создавалась новая файловая система определенного типа, которая монтировалась в общую файловомую иерархию. Однако выход за границы существующего раздела и диска для файловой системы был по-прежнему невозможен.