Алексей Федорчук
[email protected]
Описание любого дистрибутива принято начинать с его установки. Однако установка FreeBSD стандартным способом столько раз описывалась, в том числе и автором этих строк, что возвращаться к этому вопросу было бы скучно. Тем более что в 5-й ветке отвечающая за это программа (/stand/sysinstall, она же - /usr/bin/sysuinstall, являющаяся, кроме того, и универсальным постинсталляционным конфигуратором) практически не изменилась по сравнению с версиями 4.X, приобретя лишь несколько мелких, но очень приятных усовершенствований, о которых я говорил в ознакомительной заметке.
Разумеется, обойтись без описания sysinstall все равно не удастся. Однако для понимания ее внутренней сущности (а sysinstall - это своего рода интегрирующая надстройка, front-end, над серией низкоуровневых утилит) требуются некоторые предварительные знания, в частности, о дисковых накопителях, дисковых разделах и файловых системах FreeBSD. Тем более, что именно в этом отношении FreeBSD разительно отличается не только от DOS/Windows, но и от Linux, причем как терминологически, так и по существу.
Так что практическое знакомство с FreeBSD целесообразно начать именно с круга вопросов, вынесенных в заглавие этой заметки, в которой будут рассмотрены диски и дисковые разделы. После чего, уже в следующей заметке, я обращусь к файловым системам FreeBSD.
Чтобы более не повторяться, оговорюсь сразу: большая часть того, о чем будет говориться в этой заметке, относится к дискам с интерфейсом IDE (ATA). SCSI-диски имеют свою специфику, но я с ними дела не имел и собственных представлений на сей предмет не имею. Да в контексте настольного использования FreeBSD это становится все менее актуальным. Хотя и тему SCSI устройств придется затронуть - но не в отношении дисков, а накопителей иного типа.
Для начала вспомним, что дисковые накопители во FreeBSD (как и любые другие устройства в любой Unix-подобной системе) предстают перед пользователем в виде файлов специального типа - файлов устройств, конкретнее - файлов блочных устройств (то есть тех, обмен данными с которыми осуществляется не побитно, как, скажем, с сериальными портами, а блоками некоего фиксированного размера). Файлы эти расположены в каталоге /dev, и номенклатура их подчиняется строгим правилам.
Во FreeBSD 5-й ветки используется т.н. файловая система система устройств - DevFS. Подробный разговор о ней - в следующей заметке, пока лишь минимум практических сведений.
Раньше (в ветке 4 и ниже) файлы устройств создавались с помощью специальной утилиты (при установке системы - автоматически) как бы впрок, для (почти) всех теоретически возможных устройств. В результате в каталоге /dev обнаруживалось немерянное количество файлов для дисков и их разделов, терминалов и псевдотерминалов, и многого, многого другого. Большая часть которого оказывалась лишней. В то же время вполне могло не оказаться чего-то необходимого лично вам, но не предусмотренного стандартным сценарием создания устройств.
Эту проблему (на самом деле не только эту, но и многие другие) сняла DevFS. Теперь файлы каталога /dev создаются при загрузке системы только для устройств, реально существующих - раз, и поддерживаемых ядром системы (конкретным, лично сконфигурированным, или типовым ядром GENERIC). Более того, при "горячем" подключении устройств, таковое допускающих, соответствующие им файлы создаются "на лету".
Так вот, файлы устройств ATA-дисков именуются ad#. Как нетрудно догадаться, аббревиатура ad происходит от ATA Disk, а # - соответствует номеру конкретного накопителя в порядке его подключения к IDE-разъемам. То есть
/dev/ad0 Master на 1-м IDE-канале /dev/ad1 Slave на 1-м IDE-канале /dev/ad2 Master на 2-м IDE-канале /dev/ad3 Slave на 2-м IDE-канале
Во FreeBSD по умолчанию принята статичная нумерация файлов дисковых устройств. То есть, например: файл диска Slave на 2-м IDE-канале всегда будет носить имя /dev/ad3, даже если он является единственным в системе. Случай, конечно, гипотетический - реально вряд ли кому понадобиться подключать диск таким образом. Однако важно, что при этом в каталоге /dev установленной FreeBSD 5-й ветки будет присутствовать только один файл устройства - /dev/ad3. Тогда как в более старых ветвях мы увидели бы также созданные "про запас" файлы /dev/ad0, /dev/ad1 и /dev/ad2, хотя попытка обращения к ним ничего, кроме сообщения об ошибке, и не дала.
В старых (но не обязательно устаревших) документах о FreeBSD можно встретить имена дисковых устройств вида /dev/wd0 и так далее. Такая номенклатура для IDE-дисков применялась в версиях ветки 3 и ранее. Начиная с ветки 4, за ними закрепились имена ad#.
Диски, подключенные к дополнительному простому IDE-контроллеру (например, реализованному на отдельной плате расширения), получают следующие по порядку номера - /dev/ad4, /dev/ad5, /dev/ad6, /dev/ad7. А вот с дисками на контроллере ATA RAID (а ныне они стали почти стандартным компонентом материнских плат) получается интереснее. Они существуют как бы в двух ипостасях - то есть одному и тому же физическому устройству соответствует два файла - /dev/ad# (где # будет начинаться с 8 для Master'а на 1-м RAID-канале) и /dev/ar# (где ar, как можно понять по аналогии, означает ATA RAID, а нумерация будет начинаться с единицы). До выполнения процедуры разбиения диска оба имени будут абсолютно равноправны, и любое из них можно будет выбрать как объект для создания разделов. Однако после того, как разбиение закончится, файлы устройств разделов будут образованы только на основе имени выбранного диска (подробнее об этом будет говориться позднее).
Некоторые контроллеры ATA RAID позволяют переключать их в режим работы обычного IDE-контроллера. В этом случае подключенные к ним диски будут именоваться обычным для ATA-накопителей образом - /dev/ad4 и так далее.
Номенклатура и нумерация других ATA-накопителей (а практически речь идет только о внутренних Zip-приводах) подчиняется тем же правилам, по которым обозначаются винчестеры. За исключением ATAPI CD ROM и CD-R/RW - файлы этих устройств по традиции именуются /dev/acd0 и /dev/acd1 (от ATAPI CD ROM - а кто видел в системе больше двух таких приводов?). Причем, в отличие от дисков, - вне зависимости от канала, на котором они сидят, просто в порядке подключения.
Файлы устройств SCSI-дисков именуются /dev/da# (как я предполагаю, ат direct access - устройства прямого доступа), с нумерацией в порядке подключения к SCSI-шине. Сами по себе SCSI-диски нас не интересуют. Однако такие накопители, как USB flash (которые имеют все шансы стать стандартными сменными носителями взамен флоппи-дисков), также предстают перед системой как SCSI-диски. И соответственно первая же подключенная к машине флэшка (вне зависимости от того, к какому USB-разъему) получит имя /dev/da0. Причем это тот самый случай, когда файловая система устройств создаст для нее файл "на лету", в чем легко убедиться командой
$ ls /dev/
до и после подключения USB-накопителя.
Последнее устройство дискового типа, с которым приходится иметь дело пользователю настольной машины - это флоппи-дисководы. Файлы их именуются незамысловато - /dev/fd#, где для # с большой долей вероятности можно предполагать значение 0.
Конечно, FreeBSD поддерживает и все прочие известные типы накопителей - старые CD ROM с фирменными интерфейсами типа псевдо-SCSI, стриммеры с разными интерфейсами, SCSI RAID и так далее. Однако на настольной пользовательской машине обнаружить их нелегко, да и мне иметь дело с ними не приходилось.
Единственное, что может быть актуально для пользователя десктопа - это внешние диски с интерфейсом FireWire. Однако я таковых не только не пользовал, но и не видел, и потому ничего за них не скажу. Могу только предположить, что и они предстанут в каталоге /dev в качестве SCSI-дисков - если кто поделится сведениями по сему поводу, буду признателен.
Далее в этом разделе речь пойдет исключительно о жестких дисках, сиречь винчестерах. Как известно, диски принято делить на разделы (partitions в терминах DOS/Windows и Linux). Но FreeBSD и тут отличается оригинальным подходом. Чтобы понять его, нужно для начала сказать
Слово "геометрия" в заголовке рубрики взято в кавычки не случайно. Дело в том, что с тех пор, как объем дисков перевалил за 500 с небольшим мегабайт (ограничение старых BIOS персональных, ранее именовавшихся IBM-совместимыми, компьютеров), с реальной их геометрией пользователь никогда не сталкивается. Софт, прошитый в дисковой электронике (т.н. firmware) преобразует ее к виду, доступному восприятию BIOS - на деталях, как именно это делается, останавливаться не буду (да и вряд ли кто, кроме производителей дисков, эти детали знает).
А доступная BIOS геометрия диска описывается в терминах цилиндр/головка/сектор (cylinders/heads/sectors, C/H/S). Условно говоря, головки считывают информацию с концентрических магнитных дорожек (tracks), на которые поделена каждая дисковая пластина. Вертикальная совокупность треков с одинаковыми номерами на всех пластинах, составляющих диск как физическое устройство, и образует цилиндр. А сектора нарезают пластину, вместе с ее треками, на радиальные фрагменты, именуемые блоками. То есть это можно представить себе таким образом, что блок лежит на пересечении (в пространстве) цилиндра, трека и сектора. Число треков и секторов в современных дисках фиксировано (вернее, предстает таковым в BIOS): 255 треков нарезается на 63 сектора каждый, что в совокупности дает 16065 блоков на цилиндр. А количество цилиндров определяется объемом диска (в арифметические вычисления вдаваться не буду). Важно здесь только то, что головки диска механически двигаются синхронно по поверхности всех пластин. То есть если на одной пластине информация считывается с 1-го трека, то и все прочие головки перемещаются на ту же дорожку - каждая на своей пластине.
Повторяю, все это условно - хотя бы потому, что понятие цилиндра в геометрическом смысле слова очень трудно применить к современным дискам, часто не то что однопластинным, а даже, если так можно выразиться, полупластинным (то есть только с одной задействованной стороной единственной пластины). Но разбираться с этой геометрией - дело firmware и BIOS, для нас же интересны именно цилиндры - совокупность треков, к которым осуществляется синхронный доступ, и блоки - минимальные кванты дискового пространства.
Образующие цилиндры треки создаются при первичной заводской разметке диска - т.н. низкоуровневом форматировании. Из сказанного выше очевидно, что доступ к данным в пределах одного цилиндра или группы соседних будет выполнен быстрее, чем к данным, записанным частично на первый и, скажем, на последний цилиндр диска. Этот случай не столь уж невероятен, как может показаться: в DOS'е, где пространство, занятое стертыми файлами, помечается как неиспользуемое, но реально перезаписывается только тогда, когда свободное место на диске вообще исчерпано, такая ситуация вполне могла бы возникнуть.
Так вот, чтобы свести к минимуму вероятность разнесения данных по разобщенным цилиндрам, и придуманы были дисковые разделы (вернее, в том числе и для этого - выделение дисковых разделов преследует и другие цели). В единый раздел объединяется группа смежных цилиндров. Где кончается один раздел и начинается другой? Резонные люди из Одессы сказали бы, что полиция кончается именно там, где начинается Беня Крик. Однако для нас очевидно, что для каждого из разделов следует хранить сведения о его начале и конце (то есть номера 1-го и последнего из задействованных в нем цилиндров). Где их хранить? Для ответа на этот вопрос следует обратиться к понятию блока.
Как и треки, дисковые блоки (или физические - есть еще блоки логические, но это относится уже к файловым системам) создаются при низкоуровневом форматировании, и пользователь влиять на них (почти) не может. Размер их также всегда одинаков и равен 512 байтам. Вернее, таким он видится BIOS'у персоналки - каков он на самом деле, одному Аллаху ведомо (в частности, на современных дисках блоки обычно имеют разный размер на внешних и внутренних треках - почему, думаю, интуитивно ясно). Однако то, что обмен данными с диском возможен минимум 512-байтными порциями - объективная реальность, как и то, что любой, сколь угодно маленький, объем информации, записанный на него, будет занимать целый блок. С другой стороны, считывание данных блоками по 512 байт будет происходить быстрее, чем если бы при каждом обращении головки к диску данные считывались бы побайтно. Однако это относится уже к теме файловых систем.
А пока нас интересен один-единственный блок, образованный первым сектором на первом треке первого цилиндра. Он резервируется под служебную область диска, именуемую главной загрузочной записью (MBR - Master Boot Recodr), которая и считывается BIOS'ом при старте машины. Очевидно, что по прямому назначению MBR используется только в том случае, если диск определен в Setup'е BIOS'а как загрузочный (или просто является единственным в системе). Однако поскольку использование каждого конкретного диска остается на усмотрение пользователя, место под него отводится всегда.
Внутри нулевого блока, помимо прочего (в частности, кода какого-либо начального загрузчика, который может быть туда записан) есть еще один зарезервированный участок. Он предназначен для BIOS'овской таблицы разделов (Partition Table), под которую испокон веков отведено 64 байта. В эту таблицу записываются (или могут быть записаны) данные о разделе (разделах) в определенном, доступном пониманию BIOS'а, формате. А формат этот предусматривает указание стартового блока, размера в байтах, идентификатора типа файловой системы и (только для одного из разделов) флага активности (то есть помечающего данный раздел как загрузочный). Последнее необходимо для некоторых операционок типа DOS, хотя FreeBSD или, например, Linux'у флаг этот глубоко безразличен.
Всего информации, необходимой для описания дискового раздела, набегает 16 байт. А поскольку, как мы помним, под всю таблицу разделов этих байт отведено лишь 64, без калькулятора можно подсчитать, что предельное количество разделов на диске - 4. Эти разделы называются первичными или, не совсем точно, физическими. Так как в большинстве случаев такие разделы могут быть также поделены на части - разделы логические (о чем речь впереди).
Повторю еще раз - это относится только к машинам с PC BIOS, то есть обычным персоналкам. На всякого рода PowerPC, Sparc'ах и тому подобных станциях все может быть совсем по другому (хотя как именно - честно говоря, не Ганнибал, не знаю).
Как можно заметить, в описание раздела входит идентификатор файловой системы. Это - некоторое число (во FreeBSD обычно в десятичном представлении, в Linux'е, например, - в шестнадцатеричном), которое ставится в соответствие с файловой системой операционки, планируемой к размещению на диске. Так, раздел, предназначенный для FreeBSD, имеет идентификатор 165 (десятичный) или A5, раздел для Linux (Linux native) - 131 (или 83), FAT16 - 6, расширенный раздел (т.н. DOS Extended) - 5, и так далее.
Присвоение разделу какого-либо идентификатора не значит, что тем самым на нем волшебным образом возникает соответствующая файловая система. Нет, он просто предопределяет, какого рода вторичная таблица разделов может быть на нем записана. Но тут мы переходим к разговору
Продолжение следует
К предыдущему