Берклиада Unix-кода
Одним из первых учреждений американского наробраза, получившего доступ к исходникам Unix, оказался Университет Беркли (штат Калифорния). Именно сюда Unix "вписался с точностью патрона, досланного в патронник" (Олег Куваев). И здесь с лихвой выполнил свои "научно-образовательные цели"...
В Беркли, в условиях открытого общения профессиональных специалистов в области зарождавшихся Computer Sciences, система Unix медленно, но верно превращалась именно в то, чем она стала ныне. И в значительной мере - именно усилиями трудящихся из университета, объединенных в Computer System Research Group (CSRG), финансировавшуюся в сугубо мирных целях, как не трудно догадаться, Министерством обороны США.
Что же принципиально нового привнесли берклианцы в первозданный Unix? Во-первых, конечно же, интеграцию в ядро системы протокола TCP/IP. Того самого, на котором базируется весь сегодняшний Интернет. Собственно, ради этого американские компьютерщики в штатском и финансировали работы Университета Беркли - ведь первоначально Интернет задумывался как отказоустойчивая система правительственной связи на случай советского ядерного удара. Однако это - совсем отдельная история...
Следующим принципиальным вкладом Беркли была реализация файловой системы. Поскольку именно это весьма важно для нас, простых пользователей персоналок, остановлюсь на этом вопросе подробнее.
Извинение: возможно, сказанное выше покажется не вполне понятным начинающему пользователю, скажем, Linux. Надеюсь, что все недоразумения разрешатся при дальнейшем чтении моего сочинения, на протяжении которого к вопросам устройства файлов и файловых систем придется возвращаться неоднократно.
Я уже говорил, что основные характеристики файловой системы были сформированы уже в первозданном Unix. Эта файловая система (получившая впоследствии название s5fs, то есть файловой системы System V) базировалась на трех китах - понятиях суперблока, таблицы так называемых inodes, и области блоков данных.
Суперблок - это часть файловой системы, описывающая ее в целом: положение на физическом носителе, размер минимального кванта информации (логического блока) и их суммарное количество, число свободных и занятых блоков, и так.
далее.
Таблица inodes (индексных, или информационных, узлов - однако лучше сохранить этот термин без перевода, опять-таки как своего рода идеограмму) - это метаданные (то есть данные о данных) файлов файловой системы. Для каждого файла она содержит: его уникальный идентификатор, по которому он находится системой, число ссылок на него (фигурально говоря, количество имен файла - как будет сказано в , любой файл может иметь несколько имен), размер, т.н. атрибуты файла - принадлежности (владельца файла, группы, к которой он принадлежит, и прочих), доступа (права чтения, исполнения, изменения), времени (последнего обращения, изменения данных и метаданных), и еще некоторые.
Адреса блоков данных файла, то есть собственно физического расположения его контента на диске, также описываются в таблице inodes. Ну а сами блоки данных (то есть полезная для пользователя информация), как легко догадаться, и составляют наполнение одноименной области.
В устройство файловой системы s5fs изначально были заложены три существенных ограничения с точки зрения надежности, экономичности и быстродействия. Первое - то, что суперблок ее имелся в единственном экземпляре, и его утрата (например, вследствие физического повреждения носителя) автоматически влекла недоступность всех данных.
Второе - s5fs была образована некими квантами информации - логическими блоками, имевшими размер от 512 (размер физического дискового блока) до 2048 байт. Очевидно, что увеличение размера блока вело к повышению быстродействия дисковых операций. Однако не менее ясно, что при этом дисковое пространство расходовалось неэффективно: ведь любой файл, сколь мал бы он ни был (а в Unix количество очень маленьких файлов весьма велико), занимал логический блок целиком.
Третье ограничение, быстродействия, сказалось позднее, когда "винчестеры стали большими". Легко сообразить, что единственная таблица inodes при непрерывности области данных на разделах большого объема требовала значительных перемещений считывающих головок диска - ведь каждая операция чтения файла или его записи требовала обращения сначала к метаданным файла, а потом - к его данным.
Это - что касается физики хранения данных. Логически же файловая система Unix изначально приобрела древовидную (или иерархическую) структуру, основанную на разделении каталогов и всех прочих файлов. Каталоги образовывали как бы скелет файловой иерархии и содержали только идентификаторы файлов и их имена - это и были те самые ссылки, о которых говорилось чуть выше. Причем, вследствие изначально принятого формата каталога, длина имени файла (как это ни покажется парадоксальным пользователям нынешних Linux или BSD, привыкшим к файлам с именами длины немерянной) ограничивалась 14 символами. Ведь каталог - это, в сущности, база данных для идентификаторов файлов и их имен, состоящая, как и любая БД, из записей и полей. Так вот, каждая каталожная запись в s5fs имела фиксированную длину в 16 байт, из которых два первых отводились под идентификатор, так что на имя этих байт оставалось только 14.
Разработки Университета Беркли сняли многие ограничения как физики, так и логики s5fs. Во-первых, единое пространство файловой системы было разделено на части, именовавшиеся группами цилиндров, каждая из которых имела копию суперблока, самостоятельную таблицу inodes и область данных. Это давало большой прирост в быстродействии файловых операций за счет минимизации перемещения дисковых головок. Плюс к тому дублирование критически важной части файловой системы - суперблока - весьма способствовало надежности.
Далее, было введено понятие внутренней фрагментации. То есть каждый логический блок файловой системы разделялся на части (фрагменты), которые могли адресоваться независимо. И, соответственно, если файл имел размер менее логического блока - то реально он занимал не его целиком, а только один (или несколько) таких фрагментов, остальные же сохранялись свободными и могли быть использованы для других целей. Но дисковые операции все равно осуществлялись поблочно, так что на их быстродействии фрагментация почти не сказывалась.
Все это привело к потере совместимости новой файловой системы с файловой системой изначального Unix.
И потому (снявши голову - плачут ли по волосам?) разработчики из Беркли решились на еще один радикальны шаг - изменение формата каталогов. Каждая запись в них разделилась на постоянную часть - идентификатор, размер переменной части и размер имени файла, - и переменную, содержащую собственно имя файла. В результате максимально возможная длина последнего возросла до 256 символов, что с точки зрения здравого смысла можно считать практически безграничным - вряд ли кому придет в голову изобретать имя файла длинее трех строк стандартной текстовой консоли (и, тем паче, запомнить таковое).
Утрата совместимости в формате каталогов, казалось бы, должна была стать препятствием для использования программ - ведь подавляющее большинство их уже тогда создавалось под абстрактный Unix, а трудно представить себе пользовательское приложение или системную утилиту, не нуждающуюся в считывании имен файлов. Однако в Беркли было предусмотрено и это - путем описания специальных процедур открытия и чтения каталогов, не зависимо от формата последних. Что вовсю заиграло позднее - когда файловых систем в Unix стало множество.
Новая файловая система получила имя FFS - Fast File System, что подчеркивало ее быстродействие относительно исходной s5fs. Я столь подробно остановился на ее отличиях от прототипа по двум причинам. Во-первых, из-за важности их для пользователей. И во-вторых - потому что реализованные в FFS принципы разделения файловой системы и фрагментации ее блоков были ассимилированы во всех последующих файловых системах, применяемых ныне в любых разновидностях Unix. К этим принципам восходят и группы блоков в файловой системе Linux (ext2fs), и экстенты (extents) JFS и, особенно, allocations group в XFS, выступающие здесь уже как почти самостоятельные файловые субсистемы.
И все потому, что Университет Беркли, представляя собой обычное научное сообщество, отнюдь не делал секрета из своих разработок. Распространяя их на условиях, общепринятых в академических кругах всех времен и народов.
То есть все эти результаты публиковались в простых научных журналах и были доступны для воспроизведения любым желающим (и, что немаловажно, можущим). Позднее такие условия распространения софта, с одной стороны, легли в основу лицензии BSD. А с другой, Ричард Столлмен, в юности не чуждый академической науке, опираясь на них, изобрел очень похожий велосипед, и назвал его GPL (General Public License).
Распространялась и сама берклианская разновидность Unix как программный продукт. Группа CSRG, начиная с 1976 г., внедряла в народе свои достижения - на магнитных лентах, под названием Berkely Software Distribution, что, с указанием номера версии, и дало в дальнейшем имя системе. Это было первичное понимание аббревиатуры BSD, которое не следует путать с возникшим позднее BSDi - Berkely Software Development, Inc (или Berkeley Software Design, Inc, мне попадались обе расшифровки этой аббревиатуры), фирмой, выпускающей коммерческий клон BSD-систем, называемый, строго говоря, BSD/386 (хотя в обиходе за этой системой закрепилось то же имя - BSDi).
Первоначально (под именем 2BSD и по цене 50 американских рублей) распространялся только пакет собственно берклианских наработок, включающий, в частности, командную облочку C-Shell и культовый редактор юниксоидов vi. Однако, начиная с 3BSD, берклианские ленты включали уже и модернизированную Unix-систему. Особенно обильные побеги дала ее 4-я ветка - 4.0BSD, 4.1BSD с несколькими подвариантами, 4.2BSD, 4.3BSD и, под занавес истории, 4.4BSD.
Наиболее существенным этапом был выпуск в 1982 г. системы 4.2BSD: именно в ней была реализована файловая система FFS, да и большинство прочих специфических особенностей BSD-систем. Не случайно тип раздела FreeBSD (и DragonFlyBSD) по сию пору идентифицируется как раздел 4.2BSD, а до недавнего времени этот же идентификатор имели и разделы Net- и OpenBSD. С этого момента стало реальностью сосуществование двух самостоятельных линий развития Unix - System III/V и BSD Unix.
А системе 4.4BSD, была предначертана особая судьба, о чем я расскажу несколько позднее.
