Маленькое отступление: Внимательный читатель (и к тому же пользователь Linux по натуре) наверняка задаст вопрос: пардон, а где же здесь общесистемные библиотеки? В частности, glibc, без которой ничего не работает. Ибо в Linux предназначенный для них каталог находится непосредственно в корне файловой системы (/lib), которого в списке кандидатов на исконность корней не видно. Забегая впред, отвечу: файлы главной системной библиотеки в BSD-системах (здесь она величается просто - libc) размещаются в каталоге /usr/lib, который мы в следующем абзаце отчленим от корня и поместим на отдельный раздел.

Но как же тогда будут работать бинарники из каталогов /bin и /sbin в однопользовательском режиме, когда никакие другие файловые системы, кроме корневой, не монтируются? - задаст следующий вопрос пользователь, просветленный Linux'ом. Очень просто: в DragonFly все системные утилиты из каталогов /bin и /sbin (а их содержимое - и есть системные утилиты, просто в первом лежат те, к которым иногда прибегает и простой пользователь, а утилиты из второго ему без надобности), слинкованы с libc статически, и в наличии ее не нуждаются.

Реплика в сторону: раньше (включая все версии 4-й ветки) так было и во FreeBSD, но в 5-й ветке бинарник из каталогов /bin и /sbin линкуются динамически, а статически слинкованные утилиты "на всякий пожарный случай" располагаются в каталоге /restore.

Так что от выноса на отдельный раздел неизменяемого (и легко восстановимого) каталога /usr - вреда ни малейшего. А заодно отделяем и изменяемые каталоги - /tmp и /var, ну и конечно же /home. То есть пока мы движемся в русле схемы разметки, предложенной по умолчанию. Но вот теперь пойдут разночтения. Потому что /usr в этом случае оказывается сборной солянкой неизменяемых и изменямых подкаталогов, к тому же - разной степени восстановимости. Так что с безжалостностью эсторского палача-расчленителя по прозвищу Голый Дьявол приступим к его разделу.

Для начала вычленяем из древа /usr его заведомо изменяемую часть - каталог /usr/obj: это то место, куда по умолчанию помещаются промежуточные продукты компиляции ядра и базовой системы, как будет показано в следующей статье, роль его весьма велика.

Теперь - умеренно восстановимые части, /usr/local и /usr/X11R6, а при использовании системы pkgsrc - также и /usr/pkg. Это обеспечит нам сохранность инсталляций дополнительных программ при переустановке базовой системы.

Правда, не до конца: для обеспечения контроля их зависимостей потребуется еще и сохранить базу данных установленных пакетов. Так что "умолчальный" ее каталог /var/db/pkg также логично было бы вынести на отдельный раздел. Хотя, если это делать не хочется (а так оно и есть - больно уж много чести для массива данных в десяток мегабайт, эту сохранность можно обеспечить иными способами (о них речь пойдет в статье про управление пакетами), не говоря уже о простом backup.

Теперь отрезаем изменяемые и трудновосстановимые части - /usr/ports и (или) /usr/pkgsrc. Лишним резоном к чему будет специфика из содержимого - очень большое число (многие десятки тысяч) очень маленьких (по несколько байт) файлов. И потому из состава этих ветвей целесообразно вытащить их менее специфичные и наиболее "затратные" (в том числе и финансово:-) компоненты - /usr/ports/disfiles (или, соответственно, /usr/pkgsrc/distfiles). На чем сердце расчленителя может успокоиться - вряд ли на индивидуальной машине имеет смысл дробить на подкаталоги /home или /var (хотя на большом сервере это, скорее всего, необходимость).

В итоге получаем максимальное целесообразное количество отдельных ветвей файловой системы - 14, что вполне укладывается в допустимый максимум слайса DragonFly (16 подразделов). Впрочем, очевидно, что все перечисленное и не понадобится: вряд ли есть смысл в использовании и системы портов, и pkgsrc. Так что реальное число ветвей сразу уменьшается на три. Ну и без отдельного раздела под /usr/X11R6 также можно обойтись в любом случае. При pkgsrc он вообще не нужен, а при использовании портов его можно оставить внутри /usr: если следить за тем, чтобы все X-приложения собирались в каталог /usr/local (как - будет рассказано в статье про управление пакетами), то /usr/X11R6 сразу станет фактически неизменяемым.

Далее, может иметь смысл помещение трудновосстановимых и невосстановимых разделов (/usr/src, /usr/ports, /usr/ports/distfiles, /home) на отдельный слайс: именно поэтому ранее я столь подробно останавливался на том, как средствами DragonFly сделать это вручную. Смысл такого действия - облегчить полную переустановку системы в случае необходимости. Правда, надеюсь, таковой не будет - в следующей статье будет говориться и о том, как избирательно восстановить с дистрибутива только нужные ветви файлового древа. Но - береженого Бог бережет...

Итак, с количеством и назначением разделов разобрались. Теперь остается только "разделить по Божьи" между ними наличное дисковое пространство. И действительно - "тут очень рассчет нужон". Причем при рассчетах следует помнить о специфике файловой системы UFS вообще: в ней быстродействие файловых операций (и так не рекордное сравнительно с Ext2fs или ReiserFS) резко падает, как только объем свободного места становится менее 10%. Так что, как говорится, запас горба не сломит (тем более на современных-то дисках).

Для начала - вычисляем корень. Тут можно спокойно согласиться с "умолчальным" предложением в 256 Мбайт. Да и того за глаза хватит - у меня, например, в данный момент в корне (того самого размера) задействовано даже менее 50 Мбайт; ну да ладно - не будем жмотничать на важнейшем каталоге.

С предлагаемым по умолчанию объемом раздела под каталог /var я, не мудрствуя лукаво, тоже согласился (правда, у меня он обычно используется едва на 15-15%). А вот от раздела под /tmp я давно отказался: при достаточном количестве памяти (начиная с 512 Мбайт - точно, а меньше - я и забыл, когда было) в этот каталог целесообразно смонтировать файловую систему в оперативной памяти (mfs - Memory Filesystem), и при финальных настройках системы (в заключительно разделе этой статьи) мы будем исходить из этого.

Остается отпрепарировать каталог /usr. Ясно, что при предложенной выше схеме разметки 8 "умолчальных" (и даже 4 допускаемых) гигабайта для него - излишне. Подсчет объема, занимаемого "родными" подкаталогами (от /usr/bin до /usr/share) в установленной системе даст около 180 Мбайт, "чистые" Иксы добавят еще сотню. То есть при использовании портов на весь /usr можно кинуть 512 Мбайт, а при pkgsrc - сократить этот объем вдвое.

Объем промежуточных продуктов компиляции базовой системы, включая ядро, помещаемых в каталог /usr/obj, составляет, в зависимости от настроек ее условий, 500-600 Мбайт. С учетом разрастания ее в будущем - отводим под это дело 1 Гбайт. Причем при тех же 512 Мбайт ОЗУ и в этот каталог можно смонтировать файловую систему mfs, что имеет как свои плюсы, так и минусы, которые подробно будут рассмотрены в следующей статье.

Труднее всего определиться с каталогом /usr/local (или его аналогом /usr/pkg для системы pkgsrc). Требуемое под него место определяется исключительно аппетитами пользователя на дополнительный софт. У меня под /usr/local отведено 2 Гбайт - и до их исчерпания (при установленных KDE и OpenOffice) еще далеко.

Теперь исходники базовой системы. Вместе с ядром в распакованном из тарбалла (доступного на некоторых ftp-зеркалах проекта) виде они занимают около 400 Мбайт. Снапшот текущего дерева, полученный через cvs, будет несколько больше. Так что под каталог /usr/src я не поскупился бы гигабайтом - с запасом на будущее.

Как ни странно, трудно определиться также с пространством под /usr/ports (или /usr/pkgsrc). Правда, объем дерева соответствующей системы вычисляется легко - в распакованном из тарбалла виде они займут около 150 Мбайт. Однако следует учесть, что по умолчанию здесь же окажутся и промежуточные продукты сборки - распакованные исходники, объектные модули и т.д., а для pkgsrc - еще и собранные бинарные пакеты. От всего этого потом можно избавиться - однако, дабы не получить в процесс сборки KDE или OpenOffice сообщения об исчерпании дискового пространства, лучше создать под эти каталоги разделы с о-очень большим запасом. Руководство к системе pkgsrc рекомендует 5 Гбайт, однако для /usr/ports, мне кажется, хватит и двух.

Относительно /usr/ports/distfiles (или /usr/pkgsrc/distfiles) можно сказать то же самое, что и о /usr/local (или /usr/pkg): выделяемое под них пространство определяется запросами пользователя. Руководство по pkgsrc определяет полный объем исходников для этой системы в 10 Гбайт. Какой процент из входящих в pkgsrc 5 тысяч приложений потребуется именно вам - предлагается рассчитать в качестве домашнего задания. Я лично под /usr/ports/distfiles ограничиваюсь 2 Гбайт.

И, наконец, с /home все ясно. Под него отводится места а) сколько нужно, б) сколько можно или в) сколько не жалко. У меня это всегда - все оставшееся дисковое пространство (собственно, так BSD Installer и предлагает по умолчанию.

В заключение - о swap-разделе, не несущем файловой системы. Рекомендуемый его объем равен удвоенному ОЗУ, и я всегда следую этому правилу. Конечно, при объеме памяти 512 Мбайт и больше можно вообще обойтись без подкачки (или ограничиться swap-файлом, на всякий случай). Однако мы ведь решили разместить на mfs (то есть в оперативной памяти) каталог /tmp, а возможно, и /usr/obj, под что физической памяти, при некоторых услвоиях, может и не хватить. И тут в дело вступит swap - ведь для системы он вместе с физическим ОЗУ предстает в виде единой виртуальной памяти.

Казалось бы, с точки зрения быстродействия, замена дискового раздела разделом подкачки - все равно что сменить шило на мыло. Однако на самом деле это не так, и механизм виртуальной памяти DragonFly обеспечит некоторый прирост производительности и в этом случае. А кроме того, перемещение этих ветвей файлового древа в mfs обеспечивает автоматическую очистку от временных файлов при рестарте системы. Что однозначно полезно для /tmp (хотя в некоторых случаях может быть лишним для /usr/obj - но это мы обсудим в следующей статье.

Свои представления об оптимальной схеме дисковой разметки для установки DragonFly я суммировал бы так (табл. 4).

Таблица 4. Схема дисковой разметки для DragonFly

Прошу не рассматривать приведенную схему как догму - это лишь предложение к размышлению. Разметка диска - процесс творческий, и походить к нему нужно соответственно.

Столь дробная схема разметки полезна еще и тем, что позволяет индивидуально определить размер блока и его фрагмента для каждой файловой системы - в зависимости от специфики размещаемых на ней данных. При разметке в нормальном режиме (см. рис. 5) оба эти параметра, влияющие на производительность файловых операций, эффективность использования дискового пространства и максимально возможное количество файлов, вычисляются автоматически - исходя из объема раздела. И в большинстве случаев с этим можно согласиться. Исключение - файловая система ветви /usr/ports (или /usr/pkgsrc), Как уже говорилось, обе они образованы невообразимым количеством малюсеньких файлов. И потому для них, не зависимо от объема раздела, размеры блока и фрагмента лучше сделать поменьше - например, 1024 b 512 байт соответственно.

И еще, как можно видеть из рис. 6, режим эксперта позволяет включить или выключить механизм Softupadets (по умолчанию включено для всех файловых систем, кроме корневой). Это такая интересная штука, которая волшебным образом способствует как росту быстродействия файловых операций, так и повышению надежности файловой системы. Однако она имеет альтенартиву - чисто асинхронное монтирование, при котором производительность растет еще больше, хотя и надежность резко уменьшается. Почему оно обычно и не рекомендуется к употреблению резонными людьми. Однако при вычленении из файловой иерархии частей, в надежности заведомо не нуждающихся (в нашем случае это будут /tmp и /usr/obj), к ним вполне может быть применимо - с предварительным отключением Softupadets в режиме эксперта).

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

назад | к началу | вперед