Как разделяют пингвинов.

"Мой компьютер" (еженедельник)

Сергей А. ЯРЕМЧУК grinder@ua.fm

MK ©8(231)/24.02.2003

Как и любая другая операционная система, Linux обычно размещается на жестком диске компьютера, и пользователю, начиная с установки и заканчивая повседневным пользованием, приходится как-то взаимодействовать с разделами винчестера. Пришла пора разобраться, что все-таки творится там, на пингвиньих островах, с помощью чего можно их создавать, как они обозначаются, какие программы можно использовать для обслуживания файловых систем и, наконец, осмотреться во всем многообразии этих систем.
В статье я попробую ответить на все вопросы, которые когда-либо поступали на мой почтовый адрес по данной теме, а также на часто задаваемые в различных форумах. В некоторых случаях придется повторяться, исключительно для целостности восприятия общей картины и, естественно, для недавно присоединившихся. Также естественным желанием у меня было собрать всю информацию воедино. Статья будет логически разделена на четыре части. В первой рассмотрим все, что связано с разделами, от их наименования до количества. Во второй и третьей посмотрим, какие файловые системы можно использовать на созданных разделах. И в четвертой поговорим об утилитах, не рассмотренных в первых трех частях, и об оптимизации работы дисков.

Разделяй и властвуй

Начнем, пожалуй, с обозначения дисков, принятом в Linux. Традиционно в этой ОС ATA-диск (я думаю, SCSI уже как-то не актуален для десктопа) обозначается в соответствии с тем, к какому из интерфейсов он подключен: диск Primary IDE, подключенный как Master, всегда обозначается как /dev/hda, как Slave - hdb, соответственно, диск Secondary IDE, подключенный как Master - hdd, и как Slave - hdc. Причем называться он так будет независимо от того, есть ли диск в устройстве в наличии на данный момент или нет. Так обозначается весь диск целиком. Но как и повелось в любой операционной системе, диск делится для удобства работы на разделы. Жесткий диск может иметь не более четырех первичных (Primary) разделов, которые в Linux всегда обозначаются цифрами от 1 до 4, например hda2 для второго первичного раздела первого IDE-мастера. Но кому-то одних только первичных разделов может показаться мало, поэтому нередко создают в одном из первичных так называемый расширенный (Extended) раздел, на котором в свою очередь создается несколько логических разделов, обозначаемых цифрами начиная с 5. При этом в Linux разделы можно создавать, как это принято в DOS/Windows, то есть расширенный раздел может быть создан только в одном из первичных! Например, на диске может быть три первичных раздела hda1-hda3 и несколько логических, начиная от hda5, которые размещаются на четвертом первичном. Напомню, что в BSD-системах логические разделы (BSD Partitions) можно создать внутри каждого первичного (см. статью <Вольный чертик>, МК ©7 (230)).

До недавнего времени описанная здесь система обозначения дисков считалась стопроцентно правильной и сомнению не подвергалась. Но появившиеся в последнее время дистрибутивы новой волны, такие как Gentoo, Lunar Linux (см. статью <Первые пингвины на Луне>, МК ©50 (221)) внесли в свои коррективы в обозначение дисков. И виноваты в этом не сами их создатели, которые хотят запутать пользователя или как-то особенно выделиться. Нет, все обстоит иначе. Дело в том, что в ядрах Linux серии 2.4.* появилась новая файловая система устройств devfs, которая избавляет от множества неприятностей и неудобств. В двух словах, так как это соответствует теме статьи, назначение ее таково. Как известно, в Linux все, что ни попадя, в том числе и различные устройства, являются файлами - это упрощение намного облегчает взаимодействие пользователя с системой, так как для работы с диском могут применяться те же команды, что и для работы с обычным текстовым файлом (.cat, .dd) причем это взаимодействие абсолютно одинаково для всех типов и марок дисков. Но все было бы хорошо, если бы не один момент. Для того чтобы ядро могло нормально распознавать устройства, специальные файлы устройств нумеруются двумя целыми числами - старшим (major number) и младшим (minor number). Первое из них соответствует типу устройства (например, 3 - это первый IDE-диск), а второе - конкретному устройству (0A - его десятый раздел)(подробнее о наименовании устройств посмотрите в /usr/src/linux/Documentation/devices.txt). Так вот, major-номер не может быть присвоен от балды: если производитель хочет предложить свой драйвер для широкого использования, он должен входить в контакт с производителем ядер и получить для своего устройства <официальный> major-номер. И только после этого он может использоваться публично. Проблемы здесь две. Одна состоит в том, что каталог /dev буквально завален различными файлами устройств для возможной совместимости системы со всеми девайсами; по большому счету, если не предвидится серьезного апгрейда, лишние, конечно, можно и убрать, но не лучше ли их вообще туда не класть? Вторая состоит в следующем. На первоначальном этапе эта схема распределения номеров еще была, скажем так, вполне оправдана малым количеством доступных девайсов (на заре Интернета при распределении IP-номеров и имен службы DNS названия узлов и соответствующий адрес тоже просто заносились в файл hosts на каждом компьютере). Но при современных темпах почкования новых устройств все это вызывает головную боль как производителя, так и лиц, отвечающих за поддержку ядра. Да и Linux уже подошел к тому рубежу, когда все major-номера скоро будут исчерпаны. Выходом из всех этих проблем является использование devfs. При этом файлы устройств создаются <на лету> по мере подключения (хотя бывает, что для этого приходится систему все-таки перезагружать), при этом не захламляется каталог ненужными файлами, вдобавок, теперь, зайдя в /dev, можно узнать, какие устройства у вас присутствуют реально. После инициализации к устройствам обращаются по именам, поэтому необходимость в номерах отпала, со всеми вытекающими отсюда преимуществами. Хотя для обратной совместимости можно (но необязательно) указать major- и minor-номера. Так вот, в devfs по умолчанию используется совершенно другая номенклатура и предусмотрены иные каталоги для размещения файлов устройств. Так, в некоторых дистрибутивах файловая система устройств вообще монтируется в каталог /devices, а каталог /dev сохраняется для совместимости. Наши IDE-диски теперь можно найти в каталоге /dev/ide (SCSI - /dev/scsi), встроенному контролеру соответствует каталог /dev/ide/host0 (в платах с дополнительным контроллером доводилось видеть и каталог host1). Двум IDE-каналам этого контроллера соответствуют файлы /dev/ide/host0/bus0 и bus1, а подключенным дискам - каталоги /dev/ide/host0/bus0/target0 и target1. В каждом из этих каталогов имеется еще один lun0, в котором собственно и находятся файлы устройств, соответствующие как всему накопителю - disc, так и первичным (part1 - part4) и логическим (part5 - partN) его разделам. Исходя из этого, полное название дискового раздела будет выглядеть так: /dev/ide/host0/bus0/target0/lun0/part2. Поверьте мне, что когда я не смог найти привычного hda, то просто обалдел. Такое обозначение можно назвать логичным, понятным, но уж никак не удобным. Поэтому в некоторых дистрибутивах (в частности, Lunar Linux, Gentoo) используется более удобный вариант, предполагающий создание жестких ссылок - например, в файле /etc/fstab для обозначения приведенного в предыдущем примере раздела встречается уже совсем другое обозначение: /dev/discs/disc0/part2. Но для совместимости никто не запрещает создать символическую ссылку со старым обозначением и работать как ни в чем не бывало - в некоторых дистрибутивах это предусмотрено автоматически.

Итак, с обозначением разобрались. Следующий вопрос, постоянно мучающий читателя: сколько и какие разделы нужно создавать. Итак, внимание - для нормальной работы необходимо создать как минимум два раздела: первый системный - Linux native, второй раздел подкачки - Linux Swap. Под системный раздел желательно выделить, если вы предполагаете работать с X-Window, как минимум 800 - 1000 Мб, но это, как вы понимаете, во многом зависит от самого дистрибутива: есть однодисковые, а есть 3-, 5- и даже 9-дисковые, так что разбирайтесь сами. Раздел подкачки желательно расположить, для увеличения скорости обмена данными, как можно ближе к началу диска, а идеальный вариант - на другом физическом диске. А лучше вообще разделить поровну между ними, сделав запись в /etc/fstab о равенстве их приоритетов:

/dev/hda5 swap swap defaults,pri=1 0 0 /dev/hdc5 swap swap defaults,pri=1 0 0

Но здесь, в зависимости от старости дистрибутива (ядра), могут быть свои ограничения на размер. В очень ранних дистрибутивах максимальный размер раздела подкачки не должен был превышать 16 Мб, а максимальное количество таких разделов достигало восьми. В более поздних предел составлял уже 128 Мб. Современные же ядра, начиная с 2.4.10, не могут монтировать swap, если размер дискового раздела меньше 128 Mб. Когда я это первый раз прочитал и посмотрел на свой 64-Мб swap, то не понял, в чем тут прикол. Вроде и так работает. Но ведь это официальная информация, а реально swap ограничен половиной адресного пространства оперативной памяти. Для i86-процессоров при размере страницы памяти 4 Kб (значение по умолчанию) размер адресного пространства равен 4 Гб, а максимальный размер swap, соответственно, - 2 Гб. Такой вариант разбиения на два раздела, по-моему, - наиболее удобный вариант для новичка, во всяком случае мороки и проблем на этапе освоения будет поменьше. Затем, если пингвин приживется на вашем компьютере (только не стирайте сразу - у самого месяца три ушло на то, чтобы разобраться что к чему), желательно на отдельные разделы вынести каталог /home, в котором хранятся все пользовательские данные и настройки, а также раздел /usr/local в который по умолчанию устанавливаются все пользовательские программы, не входящие в дистрибутив штатно. В таком случае можно будет переустановить заново дистрибутив, не затрагивая при этом всех пользовательских настроек и не переустанавливая заново кучу программ, и пользоваться ими сразу после запуска (сравните с Windows). А что делать, если первоначально не были созданы все эти разделы, а теперь, по мере прочтения статьи, у вас созревает желание перенести их на отдельные разделы диска? Все очень просто до безобразия, создаем еще один раздел, затем монтируем в произвольную точку и просто копируем в него данные, а затем удаляем их из исходной папки, чтобы место не занимали. Например:

# mount -t ext3 /dev/hdb3 /mnt/temp # монтируем созданную файловую систему. # cp -R /usr/local/ /mnt/temp # рекурсивно копируем в нее все из каталога /usr/local (это можно проделать и с помощью mc или другим удобным способом); здесь необходимо проследить за выводимыми сообщениями # umount /dev/hdb3 # размонтируем # mount -t ext3 /dev/hdb3 /usr/local # монтируем поверх старого /usr/local (новые ядра позволяют это) для проверки, теперь прогоняем любимые программы # umount /dev/hdb3 # rm -f /usr/local/* # очищаем диск, так как информация все равно будет присутствовать # mount -t ext3 /dev/hdb3 /usr/local # монтируем новый раздел в качестве /usr/local и наслаждаемся полученным результатом.

И теперь, чтобы новый раздел при загрузке каждый раз монтировался на свое место, прописываем в файл /etc/fstab следующие строки:

/dev/hdb3 /usr/local ext3 defaults 0 0

Вот за что я и люблю Linux. Все просто, никаких тебе реестров, где регистрируется каждая программа и потому при смене раздела или добавлении нового диска как правило приходится заново ее переустанавливать. Кстати, если есть сеть с постоянно работающими компьютерами, то можно данный раздел вообще расположить только на ОДНОМ из них, тем самым экономя место, резервируя возможность контролировать и централизованно наполнять его содержание, а монтировать его уже на этапе загрузки с помощью NFS; тогда и бэкапить легче будет. При этом пользователи даже не будут догадываться, что какой-то раздел находится где-то совсем на другом компьютере. К слову, в соответствии со стандартами, продвигаемыми Linux Standard Base (http://www.linuxbase.org/), на смену каталогу /usr/local постепенно продвигается другой - /opt. И если первые два года моего знакомства с этой системой там было совсем пусто, то в последнее время он начал быстро и методично заполняться. Чтобы не создавать и здесь новый раздел, есть два выхода: явно задавать с помощью -prefix=/usr/local путь при компиляции таких программ, или, что удобнее всего, вместо каталога /opt просто создать символическую ссылку на /usr/local:

# ln -s /usr/local /opt

После этого все программы при установке будут попадать на созданный раздел диска.

Также не помешает создать еще один раздел - /boot, это самая критическая часть для загрузки операционной системы. И как я уже говорил в статье о загрузчиках, ядро не всегда можно загрузить с современных журналируемых файловых систем. После публикации статьи мне пришло много писем о том, что, мол, грузимся, и ничего. Но это ведь придумал не я, моя задача - просто предупредить, что такой вариант вполне возможен, особенно на первых ядрах серии 2.4. Кроме того, есть второе ограничение для старых дистрибутивов (в основном для тех, у кого ядро древнее 2.4 - пользователей Mandrake 7, Red Hat 6 и т.д.), связанное с так называемой проблемой 1023-го цилиндра. Дело в том, что из-за ограничений, накладываемых BIOS'ом большинства Intel-совместимых компьютеров (заметьте, это ограничение именно BIOS'а, a не Linux'а), ядро может загружаться только с первых 1023 цилиндров жесткого диска, причем если у вас их два, то возможно даже, только с первого мастер-диска (для справки: в Partition Magic есть даже ярлычок, указывающий на 1023-й цилиндр). Вся необходимая информация для загрузки LILO/GRUB, в том числе и ядро, находится в каталоге /boot. Поэтому чтобы выйти из сложившейся ситуации, расположите этот каталог в первых 1023 цилиндрах (вариант загрузки с дискеты я откидываю сразу), а корневой / (и все остальные) раскидайте по диску (или дискам) так, как вам хочется. Монтировать данный раздел следует только при инсталляции нового ядра или новой схемы загрузки.

Запись в /etc/fstab может быть примерно следующей:

/dev/hda1 /boot ext2 noauto 1 2

Больше чем 20 Мб данный раздел все равно не потянет, так что можно и раскошелиться. На серверах обычно дополнительно выносят в отдельный раздел каталоги /var и /tmp, но на домашнем компьютере вряд ли есть в этом какая-то необходимость. Из всего вышеизложенного вы должны понять, что создание разделов - процесс сугубо творческий, и ограничивает вас в этом только ваша собственная фантазия (и размеры диска(ов)).

Итак, с обозначениями мы разобрались, теперь давайте посмотрим, с помощью чего все это можно сотворить.

При установке каждого дистрибутива Linux пользователь сталкивается с какой-нибудь более или менее удобной программой, с помощью которой можно разбить диск и отформатировать его под нужную файловую систему. Особенно просты в применении графические утилиты Disk Druid в Red Hat и Hard Drake в Mandrake (Рис. 1). Для тех, кто сталкивался хоть раз с Partition Magic и немного понимает суть процесса, особых проблем при их использовании возникнуть не должно. Но, господа (панове, товарищи), раздел под новую операционную сист ему должен быть предварительно подготовлен, т.е. очищен от информации, хотя это можно попробовать сделать и при установке, зайдя в другую консоль, и скопировать файлы в другой раздел. Не говорю уже о таком обычае как предварительное резервирование данных при всякой рискованной операции, к чему относится, конечно, и установка ЛЮБОЙ операционной системы. При установке же других дистрибутивов и в последующей деятельности придется общаться с совсем другими утилитами. Познакомимся с ними поближе.

До недавнего времени для работы с дисковыми разделами в уже установленном Linux я пользовался только одной программой, к которой привык с еще с долинуксовских времен - имя ей fdisk. Да, это та страшилка, которой пугают начинающего линуксоида на каждом сайте и книге. Она полностью удовлетворяла моим довольно скромным потребностям; к тому же и программы, аналогичной PM, в Linux все равно нет. Но естественно, есть и другие предназначенные для этого инструменты: cfdisk (кстати, применяется при установке Debian) и совсем новая GNU/parted, с которой я впервые столкнулся при установке Lunar Linux. В моем Red Hat их не было, и для того чтобы не лазить за ними в Интернет, я их просто скопировал из раздела с Lunar Linux в аналогичный каталог Red Hat; если программа требовала какую-то библиотеку, то поступал аналогично. В более тяжелых случаях (например, перенос KDE) я пользуюсь jail (http://www.gsyc.inf.uc3m.es/~assman/). Эта программка, правда, предназначена совсем для другой цели - создания chroot-среды на серверах и переноса в нее только нужных для работы программ, чтобы злоумышленник, взломав аккаунт, думал что он находится в настоящем корневом каталоге. Уж простите за маленькое отступление.

Итак, fdisk. Тех, кто пользовался хоть раз Windows-аналогом, найдут данную программу очень похожей. Позволю все-таки немного остановиться на ее работе, так как есть небольшие отличия. Запускается она с аргументом - названием диска, с которым будет производиться дальнейшая работа.

[root@grinder sergej]# /sbin/fdisk /dev/hdb Command (m for help): m

Взаимодействие с пользователем осуществляется путем нажатия клавиш соответствующей требуемой операции. Как видно из примера, m (manual) выводит полную справку, p (print) - состояние разделов, n (new) создает раздел, d (delete) удаляет его (кстати, удалить раздел Linux можно только с помощью описываемых программ и PM, ДОСовский fdisk в данном случае абсолютно бесполезен). Все введенные команды будут выполнены только после ввода w (write), а при помощи q (quit) можно выйти без записи изменений.

Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 3649 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 247 3649 27334597+ f Win95 Ext'd (LBA) /dev/hda2 * 1 246 1975963+ b Win95 FAT32 /dev/hda5 247 756 4096543+ 83 Linux /dev/hda6 757 772 128488+ 82 Linux swap

Далее, клавиша а включает флаг указания загрузочного раздела, с помощью t устанавливается типфайловой системы раздела - список всех доступных можно просмотреть с помощью опции -l (list) (Рис. 2). Как видите, в списке присутствуют практически все широко известные файловые системы, но это не значит, что после выбора a5 FreeBSD на данном участке диска тут же будет создана файловая система FFS. Нет, в данном случае разделу присваивается только идентификатор раздела, с помощью которого можно разве что зарезервировать тип, а сама файловая система будет создана только после его форматирования. Вспомните, в ДОС после fdisk всегда нужно было запускать format. Здесь ситуация аналогична, только программы для создания файловой системы (форматирования) немного другие (и не одна). В нашем случае нас интересуют типы раздела Linux native (идентификатор 83), Linux swap (82), еще может пригодится тип 5 для создания расширенного раздела.

Итак, для создания раздела вводим n:

Command (m for help): n Command action l logical (5 or over) p primary partition (1-4)

На первом этапе нужно определиться, какой раздел нужен, если первичный - жмем на p, расширенный - l (хотя в старых версиях встречалась и е). После ввода, когда запросят номер раздела, порядка придерживаться не обязательно, можно вначале создать второй, а потом первый. Следующий вопрос - о размере. Его можно задать в цилиндрах (по умолчанию), в байтах, килобайтах и мегабайтах. Если просто ввести цифру 100, то раздел будет занимать ровно сто цилиндров, а для того чтобы задать сразу в мегабайтах, необходимо ввести +100M. При этом созданный раздел будет равен ближайшему кратному числу цилиндров. По умолчанию каждому созданному разделу присваивается идентификатор 83.

Более наглядна в работе утилита cfdisk (Рис. 3), с помощью которой легко проделать с дисковыми разделами все требуемые операции. Выбор раздела, с которым будут производиться дальнейшие действия, осуществляется с помощью клавиш вверх-вниз, а выбор требуемого действия - вправо-влево. Все изменения на диск будут записаны только при выборе пункта Write, после чего еще придется для подтверждения ввести yes, до этого можно совершенно не волноваться о сохранности данных. Удалить раздел можно с помощью Delete, пометить как загрузочный - Bootable, Print позволяет просмотреть таблицу разделов или сохранить ее в файле (Рис. 4), выбрать тип файловой системы можно с помощью Type, c помощью Units, чтобы не набирать каждый раз размер в мегабайтах, можно сразу установить режим ввода и отображения по умолчанию (Mb, sectors, cylinders), выйти, не внося изменения, - с помощью все той же Quit. Кстати, кто разбивал диски FreeBSD'шной программой /stand/sysinstall, не найдут здесь абсолютно ничего особенного. Можно вместо выбора пунктов меню использовать горячие клавиши, которые совпадают по назначению с таковыми в fdisk, что совсем не вызывает удивление, т.к. вышеописанная утилита является фронт-эндом к ней.

      

И наконец, GNU/parted, рожденная в недрах проекта GNU утилита, позволяющая не только создавать новые разделы, но дополнительно и файловые системы на них, к тому же она осуществляет проверку их целостности, а также удаление, перемещение, копирование и, что в новость для Linux, изменение размера разделов - правда, некоторые операции можно производить пока только с ext2fs, swap и FAT16/FAT32 .

Работать программа может в двух режимах: в интерактивном и командном.

Первый можно запустить, набрав просто parted в командной строке или добавив опцию -i в командном режиме. После запуска программы и выдачи стандартных для такого рода программ предупреждений и информации о диске, пользователь получает приглашение для ввода команд:

(parted)

Команда help позволяет получить краткую справку, а с аргументом [название команды] - справку по ее работе. Другие команды:

- print выводит таблицу разделов;

- check MINOR (где MINOR - раздел диска в терминологии parted, который можно узнать с помощью предыдущей команды) производит простую проверку файловой системы;

- cp [FROM-DEVICE] FROM-MINOR TO-MINOR - копирует файловую систему в другой раздел;

- mklabel ТИП-МЕТКИ - создать новую метку диска (таблицу раздела);

- mkfs MINOR ТИП-ФС - создать файловую систему на разделе MINOR; ТИП-ФС может принимать значения ext2, ext3, FAT, hfs, jfs, linux-swap, ntfs, reiserfs, hp-ufs, sun-ufs, xfs; хотя на данный момент поддерживаются только ext2fs, swap и FAT, будем надеяться, что это ненадолго;

- mkpart ТИП-РАЗД [ТИП-ФС] НАЧ КОН - создает раздел без файловой системы; ТИП_РАЗД может принимать значения primary, logical, extended. Полезная команда, если раздел удален случайно. НАЧ КОН - расстояние в мегабайтах от начала диска;

- mkpartfs ТИП-РАЗД ТИП-ФС НАЧ КОН - создать раздел с файловой системой;

- move MINOR START [END] - перемещение раздела в пределах диска;

-name MINOR NAME - присвоение имени разделу;

-quit - выйти из программы

- resize MINOR НАЧ КОН - изменить размер файловой системы на разделе, при этом гарантируется (если это вообще возможно при работе с дисками) сохранность данных (размер можно изменить только в соседних разделах);

- rm MINOR - удалить раздел MINOR;

- select DEVICE - смена рабочего диска;

- set MINOR FLAG STATE - изменение флага раздела, где FLAG - boot, root, swap, hidden, raid, lvm или lba, а STATE - on или off.

Взаимодействие с пользователем напоминает bash, тот же механизм автодополнения, редактирования строки ввода, та же история команд. Главное отличие от предыдущих программ - все изменения вступают в силу сразу после ввода команды. Вообще, утилита мне показалась продуманной, логичной и довольно удобной, правда, поначалу несколько непривычной. Но командный режим, скажу вам, это что-то. Введя сразу все необходимые опции, в bash на выходе получим уже готовый размеченный диск:

[root@grinder sergej]# parted /dev/hda mkpartfs primary linux-swap 0 128 && parted /dev/hda mkpartfs primary ext2 129 ###

Если необходимо разметить сразу несколько дисков, лучшего инструмента не сыскать. Жаль, правда, что пока возможности ограничены только ext2. Зная мир OpenSource, можно надеяться, что где-то уже пишется фронт-энд к данной утилите, и если это так, то, возможно, мы получим свой бесплатный Partition Magic!

Для работы с разделами можно использовать и программу sfdisk, которая имеет четыре основных режима работы: вывод размера раздела, вывод размера дисков, проверка разделов и еще один, помеченный как very dangerous, - изменение разделов.

Опция s выводит информацию о размерах дисков в блоках:

[root@grinder sergej]# /sbin/sfdisk -s /dev/hda: 29316672 /dev/hdb: 3167640 total: 32484312 blocks

Запуск с опцией -l позволяет просмотреть таблицу разделов; если при этом не указывать конкретно диск, то будет выведена информация обо всех дисках (Рис. 5). С помощью команды sfdisk -V можно проверить раздел на соответствие записи в таблице и реального состояния; если все прошло благополучно, то выведет ОК, иначе - краткий отчет о проблеме. Создавать разделы с помощью этой программы все-таки неудобно, поэтому трогать мы ее не будем, зато очень легко сохранить таблицу разделов:

[root@grinder sergej]# /sbin/sfdisk /dev/hda -O hda-partition-sectors.save и восстановить ее в случае проблем [root@grinder sergej]# /sbin/sfdisk /dev/hda -I hda-partition-sectors.save

Напомню, что эти же операции можно проделать и с помощью команд cat или dd.

Вот мы и рассмотрели все вопросы касательно размещения и создания разделов для ОС Linux на жестком диске. В следующей части посмотрим, чем можно их наполнить. Linux forever!

(Продолжение следует)

---

Продолжение, начало см. в МК © 8 (231).

В прошлой части статьи мы рассмотрели вопросы, связанные так или иначе с дисковыми разделами: их обозначение, рекомендуемое количество и инструменты, предназначенные для их создания. Но создать раздел на диске мало - для того чтобы можно было разместить на нем данные, необходимо позаботиться о создании на нем файловой системы.

Файловые системы: что посеешь, то пожнешь

Под файловой системой понимается, физический способ организации данных на дисковом разделе - возможность их хранения, нахождения и манипулирования ими (запись, стирание). Я думаю, такого простенького определения достаточно, чтобы понять, какие требования выдвигаются к ФС. До недавнего времени в Linux к услугам пользователей предлагалась только одна ФС - ext2fs, предоставлявшая возможность взаимодействовать с ФС других ОС, расположенных на одном диске. Посмотреть перечень таких ФС можно, набрав #make xconfig и зайдя в пункт меню File system. Для включения поддержки их ядром последнее необходимо пересобрать, активировав необходимый пункт. В современных ядрах Linux добавилась возможность работы с различными журналируемыми файловыми системами: ext3fs, ReiserFS, XFS и JFS. Для тех же, кому нужна более гибкая в конфигурировании и быстродействующая файловая система, появилась возможность создавать программные RAID-массивы (раздел raid auto, идентификатор fd) и системы управления логическими томами (LVM, идентификатор 8e). Кроме того, те, кому нужна повышенная конфиденциальность информации, хранимой на компьютере, могут воспользоваться CFS, свободной криптографической файловой системой для Unix/Linux от Матта Блейза (Mutt Blaze). В этой и последующих статьях будут рассмотрены только классические файловые системы, чаще всего применяемые на ПК.

Она была первой: Ext2fs

Как уже говорилось, данная ФС в Linux - это уже стандарт де-факто, ее характеризует довольно высокая надежность и самое высокое из рассматриваемых ФС быстродействие, которое в свою очередь достигается очень эффективным механизмом кэширования дисковых операций. Но так как Linux все чаще используется на высокопроизводительных серверах, то ext2fs уже не удовлетворяет их требованиям - необходимы большие разделы жесткого диска, быстрое восстановление после сбоев, высокопроизводительные операции ввода/вывода, потребность в хранении тысяч и тысяч файлов, представляющих терабайты данных. Все это превышает возможности данной ФС.

Еще одной ее особенностью является тройная косвенная адресация для указания расположения блоков больших файлов. Выглядит это примерно так. Если файл маленький, то в его метаданных содержится прямая ссылка на ячейки, в которых хранятся данные (логические блоки). Это прямая адресация. При увеличении же объема файла до некоторой критической величины занимаемое им место не удается адресовать с помощью прямой адресации. Блоки метаданных указывают уже на косвенные блоки, в которых содержатся адреса с данными, определенными в файле, или опять же указатели на следующие косвенные блоки. Количество таких косвенных блоков для одного файла может достигать трех. То есть если файл увеличивается в размере, внешне это выглядит как единичная операция, внутри же несколько иначе: поначалу распределяются новые блоки, чтобы принять новые данные, затем модифицируется inode, чтобы сделать запись о новых указателях и новых размерах, затем наконец производится запись данных.

Вот теперь представьте, что будет, если при записи файла произойдет сбой. Возможен вариант, когда запись уже произведена или еще не начиналась. Это самый благоприятный вариант: в первом случае после перезагрузки вы так и будете работать с документом, ну а во втором случае потеряется пару часов работы, но с файловой системой ничего страшного не произойдет. А вот если система <упала> именно в момент сохранения файла, то это худшее из того, что могло произойти. Если запись производилась в зону метаданных, то теперь информация, содержащаяся в них, не будет соответствовать реальному расположению файлов на диске. Ситуация усугубляется еще и тем, что Linux, в отличие от Windows, не обязательно записывает обновленный файл поверх старого - при записи во избежание фрагментации выбирается такое место, чтобы он влез полностью. Потому-то в этой системе нет программ-дефрагментаторов (мне доводилось наблюдать фрагментацию данных максимум 0.5%, да и то на переполненном диске, что, согласитесь, очень мало). Так вот, если данные заносились в каталог - а ведь это тоже файл, - то после перезагрузки мы можем недосчитаться одного каталога или, что еще хуже, целого раздела. Ну а если произошел сбой при записи в область данных, то что он будет потом содержать, зависит от вашего везения, особенно в случае, если производилась запись поверх старого варианта файла. Конечно, ситуация не так плачевна, как я обрисовал. За все время активной эксплуатации системы, пережив вместе с ней не одно выключение электропитания, случаев, из ряда вон выходящих, не было (тук-тук-тук).

Естественно, для данной файловой системы (это я все еще о ext2fs веду речь) были разработаны утилиты, помогающие восстановить ее после сбоев. За несколько лет их алгоритм, в отличие, от всеми любимого Scandisk'a, не поленились довести до почти совершенства. Так как проверять при каждой перезагрузке все диски, установленные на компьютере, согласитесь, накладно по времени, нашли такой простой выход. После того как все данные согласованы, непосредственно перед самым ее размонтированием устанавливается clean bit (в Windows также используется аналогичная технология). Перед загрузкой системы перед ее монтированием программа fsck (FileSystem ChecK) просто проверяет его наличие; если бит установлен, то делается вполне разумное предположение, что файловая система находится в непротиворечивом состоянии, а если нет, то запускается изрядно всем надоевшая утилита fsck (scandisk, по-Microsoft'овски). В связи с тем, что ext2fs содержит избыточные копии критически важных метаданных, вероятность полной потери данных чрезвычайно мала. Система определяет местонахождение поврежденных метаданных и потом либо восстанавливает данные, копируя их из резервных копий, либо просто удаляет файл или файлы, чьи метаданные пострадали. Точнее, не удаляет, а переносит их в каталог /lost+found. В этом-то и состоит очевидное неудобство: согласитесь, что чем больше файловая система, тем дольше длится процесс проверки. На дисковом разделе размером в несколько гигабайт, что давно уже перестало быть редкостью, с большим количеством файлов и каталогов, процедура проверки метаданных во время загрузки может очень сильно затянуться. А если выбило главный производственный сервер, и теперь пользователи вынуждены ждать, пока он перегрузится? Вот так мы плавно подошли к журналируемым файловым системам.

Что есть журнал?

Вся волшебная сила журнала заключена в механизме транкзаций - этот термин неплохо известен тем, кто работал с базами данных. Как и там, механизм транкзаций вместо отслеживания модификаций к таблицам и данным, рассматривает операцию записи на диск как атомарную, а не разделенную на несколько этапов, что позволяет отследить, прошла ли запись вообще, и в свою очередь гарантировать, что изменение файловой системы произведено полностью или не произведено вообще. Поясню сказанное на примере. Например, при создании нового файла изменяются несколько структур метаданных (inodes, списки свободных блоков, список файлов каталога и др.) Прежде, чем в файловой системе произойдут изменения, создается транзакция, в которой описывается то, что должно быть сделано. Как только транзакция будет зарегистрирована (на диске), файловая система приступает непосредственно к изменению метаданных. То есть фактически журнал в такой файловой системе - просто список производимых операций. В случае системного сбоя файловая система будет восстановлена к непротиворечивому состоянию путем повторного запуска журнала и отката к предыдущему состоянию. К тому же в таком случае файловая система осматривает только те участки диска, в которых изменялись метаданные, т.е. она уже <знает>, где произошел сбой. Это намного быстрее, чем при традиционной проверке с помощью fsck. И что самое существенное, время восстановления совсем не зависит от размера раздела - скорее, от интенсивности операций на момент сбоя.

Можно выделить два возможных варианта работы журналируемой файловой системы. В первом варианте в журнал заносятся только изменяемые метаданные файла, в таком случае при сбое будет гарантированы метаструктуры файловой системы, а сохранность самих данных уже зависит от везучести. Второй вариант предусматривает занесение в журнал вместе с метаданными также и самих данных, как изменившихся, так и не модифицированных, в этом случае есть вероятность, что данные после сбоя будут восстановлены. И конечно же, как говорил мой преподаватель по теоретическим основам электроцепей, <природу не обманешь, за все нужно платить>, а платить теперь приходиться быстродействием, так как самые медленные операции в компьютере - это операции ввода/вывода на диск, а количество таких операций возросло, особенно при использовании варианта с журналированием данных. Решают вопрос разными ухищрениями: например, запись происходит в момент наименьшей активности, некоторые журналируемые файловые системы позволяют разместить журнал на другом физическом диске. Да и фактически время работы с журналом намного меньше, чем работа непосредственно с данными. И естественно, некоторый полезный объем теперь приходится отводить под сам журнал, но его размеры как правило не превышают 32 Мб, что по нынешним временам не так уж и много.

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

Большинство современных journaling файловых систем поддерживают:

более быстрое распределение свободных блоков; для этого большинство из них построено на основе сбалансированных деревьев, иначе известных как B+ деревья. О том, что это такое, лучше спросите у авторов, пишущих о различных языках программирования, особенно об алгоритмах поиска и сравнения, а особо любопытные пусть посмотрят документ по адресу http://starship.python.net/crew/aaron_watters/bplustree/bplustree.py.txt;

большее количество файлов в каталоге: поскольку обычная связка name-inode становится неэффективной, то опять же для хранения имен файлов используются B+ деревья. В некоторых случаях возможно использование всего одного B+ дерева для полной системы, что намного укорачивает поиск файла и, соответственно, операции по работе с ним. Плюс динамическое выделение inides вместо неэффективного статического;

старая методика прямого, косвенного т.д. механизма хранения информации о нахождении данных файла, очень неудобная при работе с файлами большого размера по причине долгого поиска информации, заменена на более гибкую, позволяющую работать с большими файлами <напрямую>;

кроме того, некоторые новые файловые системы имеют более совершенный механизм управления внутренней фрагментацией (что это такое, объясню чуть ниже) и распределения inodes, чем Ext2. Может, конечно, сложиться впечатление, что место журналируемым файловым системам - где-нибудь на сервере; нет, они подходят на все сто процентов для использования на клиентских машинах, везде где есть необходимость в сохранении данных. Теперь, когда мы точно знаем, что ожидать от описываемых файловых систем, перейдем к их конкретной реализации.

Система в красной шапке: Ext3fs

Хотя данная файловая система не была первой, поддерживаемой ядром Linux официально (появилась только с версии 2.4.16), все таки я думаю, что справедливо будет начать именно с нее. Разработана она в недрах компании Red Hat (там и следует искать всю информацию о ее работе) доктором Стефеном Твиди (Stephen Tweedie). Найти патчи для ядра можно по адресу ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs. Чтобы не изобретать колесо, поступили просто, прикрутив к стандартной ext2fs журнал (в зависимости от опций монтирования, его можно и не видеть; находится в ./.journal) и заменив драйвер ядра, отвечающий за файловую систему. По этой причине она, естественно, наследует все достоинства и недостатки, присущие ext2fs . Но что это дало?

Самое главное - это то, что утилиты ext2fs, которые шлифовались в течение нескольких лет, работают в ней как ни в чем не бывало. К тому же идентичность файловых систем позволяет оперативно переходить как с еxt3fs на ext2fs, так и наоборот. Поясню. Мне часто приходится устанавливать другие дистрибутивы, в том числе и со старыми ядрами, не поддерживающими новинку. Так вот, все разделы, на которых используется ext3fs, я монтирую просто как ext2fs - и никаких, повторяю, никаких недоразумений при использовании не происходит.

Другое преимущество данной файловой системы состоит в том, что она, в отличие от остальных, поддерживает режим журналирования данных (полное или частичное). Естественно, добавление журнала, казалось бы, должно было ухудшить производительность такой системы по сравнению с <нежурнальным> вариантом. Оказалось, что за счет улучшения алгоритма движения головки жесткого диска данная файловая система в некоторых случаях даже обходит ext2fs. Ext3fs имеет три режима работы:

data=writeback - режим, при котором не выполняется никакого журналирования данных, учитываются только метаданные - самый ограниченный режим журналирования (кстати, применяемый во всех других ФС рассматриваемых ниже), не гарантирующий сохранности данных после сбоя. Но за счет этого возрастает скорость работы такой файловой системы: фактически журнал предназначен только для того, чтобы уменьшить время начальной загрузки системы;

по умолчанию же используется data=ordered - золотая середина между полным журналированием данных и предыдущим режимом. Официально в этом случае журналируются только метаданные, но блоки соответствующих им данных записываются первыми. В большинстве случаев такой режим гарантирует сохранность данных, особенно если данные дописывались в конец файла, чего в большинстве случаев предостаточно. Производительность, естественно, чуть ниже предыдущей и выше

режима полного журналирования - data=journal, - в котором все новые данные сначала пишутся в журнал и только после этого переносятся на свое законное место. В случае аварийного отказа журнал можно повторно перечитать, приведя данные и метаданные в непротиворечивое состояние. Кстати, как оказалось, данный режим в случае, когда диск интенсивно загружен операциями IO, оказывается даже быстрее всех остальных.

Выбрав режим, отличный от установленного по умолчанию, необходимо указать его с помощью опции -o. Например:

#mount -o data=journal -t ext3 /dev/hda5 /usr/local

Или в /etc/fstab:

/dev/hda5 /usr/local ext3 data=writeback 1 0 или если режим по-умолчанию, то просто /dev/hda5 /usr/local ext3 data=writeback 1 0

Если же теперь захочется отказаться от него, то, исправив ext3 на ext2, можно забыть о журнале:

/dev/hda5 /usr/local ext2 data=writeback 1 0

Для того чтобы к обычной ext2fs добавить журнал, достаточно выполнить команду

# /sbin/tune2fs -j /dev/hdа5

причем на неразмонтированной файловой системе. При этом вроде как гарантируется сохранность данных, хоть предварительно заархивировать их все же не повредит. Для того чтобы изначально создать ext3 на пустом только что созданном разделе диска, достаточно выполнить команду:

# /sbin/mke2fs -j /dev/hdb5

Начиная с версии 0.9.5, ext3fs может использовать другой диск для хранения файла журнала. Подробности можно узнать по адресу http://www.zipworld.com.au/~akpm/linux/ext3/ext3-usage.html.

Вот и все о данной файловой системе. От себя хочу заметить, что разделы /home, /usr/local, которые часто приходится монтировать к другим Linuxам, у меня отформатированы именно под ext3. Что и говорить, это предсказуемая и, главное, УДОБНАЯ файловая система. Характеристики относительно максимального количества файлов и каталогов, а также максимальных размеров разделов меня полностью устраивают. Но у нее есть один наследственный недостаток, который практически полностью решен в другой ФС. Но об этом поговорим чуть позже.

(Продолжение следует)

---

Продолжение, начало см. в МК © 8-9 (231-232).

ReiserFS

Это первая <сторонняя> файловая система, появившаяся в официальном ядре 2.4.4. На первое время ее работа вызывала одни только нарекания, поэтому ее использовали только любители острых ощущений. Данный проект стартовал в 90-х годах, первый прототип носил название TreeFS. Разработана Хансом Райзером (Hans Reiser) и его компанией Namesys (http://www.namesys.com), причем задачи они перед собой поставили очень, я бы сказал, революционные. Разработчики системы мечтают создать не только файловую систему, но вообще механизм иерархического именования объектов. Они считают, что лучшая файловая система та, которая формирует единую общедоступную среду - namespace. Для этого файловая система должна выполнять часть работы, традиционно выполнявшуюся приложениями, что уменьшит количество несовместимых API узкоспециального назначения. При таком подходе пользователи смогут продолжать прямое использование файловой системы без необходимости формировать уровни специального назначения, типа баз данных и т.п. А вообще, зайдите на сайт, благо из всех подобных проектов этот наилучшим образом документирован. Но предупреждаю, документации там много. Базируется она на оптимизированных b*-сбалансированных деревьях (одно на файловую систему), использование которых кроме увеличения производительности снимает ограничение на количество каталогов (хотите 100 тыс. - без проблем!) На данный момент поддерживает журналирование только метаданных, но разработчики обещают в скором времени предусмотреть и режим, аналогичный data=journal в ext3. Преимущества данной ФС в основном проявляются в работе с маленькими файлами. Поясняю. Как я уже говорил, информация на физическом носителе хранится не как попало, а отдельными блоками, размер которых зависит и от размера раздела (это связано с максимально возможной адресацией) в том числе (устанавливается при форматировании), но в большинстве случаев равен 4 Кб. Так вот, еxt2 (ext3 и FAT тоже) могут адресовать только целое количество блоков. Ну и что? Имеем файл 10 Кб, размер блока 4 Кб. Получается, что файл займет 2 целых блока и один только на половину - 4+4+2 (2 осталось незанятыми, это и называется внутренней фрагментацией). Для единичного файла это не страшно, но если их несколько тысяч? По подсчетам, в этих ФС теряется где-то от 6 до 10 процентов. Кстати, Fast File System (FFS), применяемая в BSD, умеет адресовать субблоки, а во всеми любимой FAT придется мириться с неизбежной потерей места. Разработчики ReiserFS решили отказаться от решения вереницы противоречивых задач, сосредоточившись на одной. ReiserFS может запросто упаковывать несколько маленьких файлов в один дисковый блок (tail packing), а совсем маленькие вообще просто запихать в inode (внутрь b*tree). По необходимости для файла может ассигноваться точный размер. Такой режим работы предусмотрен по умолчанию, но для повышения быстродействия есть возможность ее отключить. Хотя показатели ReiserFS при работе с большими файлами довольно высоки, именно работа с маленькими файлами (меньше Кб) и обслуживание большого их количества выделяет данную ФС. По работе с ними она превосходит по быстродействию все представленные файловые системы (видел цифры: в 8-15 раз), именно за счет того, что данные и метаданные хранятся рядом, но с <разреженными> файлами работает все-таки хуже (это, как ожидается, будет исправлено в четвертой версии, ожидаемой 30 июня 2003 года). Плюс, как видите, достигается значительная экономия дискового пространства. Различные источники называют ReiserFS самой устойчивой из всех рассматриваемых ФС; ее, я думаю, можно рекомендовать для корневого раздела, который к тому же состоит из маленьких файлов. Такая себе рабочая лошадка. Но для работы с данной ФС, кроме поддержки ее самим ядром, необходимы также специфические утилиты для работы и обслуживания разделов - они уже входят в стандартную поставку всех современных дистрибутивов, а если нет, то можете взять их по адресу ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.4.tar.gz.

Если ядро уже поддерживает ReiserFS и имеются необходимые утилиты, то набрав

# /sbin/mkreiserfs /dev/hda2

можно создать на ней соответствующую файловую систему. Для автоматического монтирования ее при загрузке достаточно прописать в файле /etc/fstab

/dev/hda2 /home reiserfs defaults 0 0

или

#/sbin/mount -t /reiserfs dev/hda2 /home

при монтировании вручную. Если для увеличения производительности необходимо отключить упаковку хвостов, то добавьте опцию notail:

/dev/hda2 /home reiserfs notail 0 0

А опция -genericread может увеличить производительность при операциях поиска файлов, т.е. когда головка мало считывает, но много перемещается по диску.

XFS

Основа этой файловой системы была создана в начале 90-х (1992-1993) фирмой Silicon Graphics (сейчас SGI) - чувствую, как напряглись те, кто занимается графикой, - для мультимедийных компьютеров с ОС Irix, заменив уже не удовлетворявшую требованиям времени EFS, но немного <очищенная> версия 1.0 стала доступна только первого мая 2001. Найти все необходимую информацию можно по адресу http://oss.sgi.com/projects/xfs. Файловая система была ориентирована на ну очень большие файлы (9 тыс. петабайт - 9 млн. терабайт - 1018 байт) и файловые системы (18 тыс. петабайт) - в отличие от предыдущих, она является полностью 64-битной, что позволяет адресовать большие массивы данных. Особенностью этой файловой системы является устройство журнала - в журнал пишется часть метаданных самой файловой системы таким образом, что весь процесс восстановления сводится к копированию этих данных из журнала в файловую систему. Размер журнала задается при создании системы, он должен быть не меньше 32 мегабайт (больше, наверное, и не надо - такое количество незакрытых транзакций тяжело получить). Тесты на производительность показывают бесспорное преимущество XFS, особенно при работе с большими и средними файлами. Также эту файловую систему характеризует прямолинейность падения производительности при увеличении нагрузки и предсказуемость - дополнительно она не генерирует излишнюю дисковую активность, т.к. пытается кэшировать как можно больше данных и <основанием> для сброса на диск является заполнение памяти, а не интервал времени, как это принято в других ФС. Любое дисковое устройство при создании файловой системы XFS разбивается на несколько равных по размеру линейных областей (0.5-4 Гб), в терминологии XFS они именуются allocation group. Уникальность allocation group в том, что каждая группа управляет своими собственными inodes и свободным местом, что превращает группы в своего рода автономные файловые системы, сосуществующие в рамках общей XFS. Такая организация позволяет эффективно организовать параллельную обработку операций ввода/вывода, которая особенно ярко проявляется на многопроцессорных системах. В каждой такой группе используется три В+-дерева, два из которых отвечают за свободные inodes (allocation). В этой системе реализована очень хорошая возможность, позволяющая избежать фрагментации файлов, называемая delayed allocation. При этом файловая система, получая данные для записи, по началу лишь резервирует под них необходимое свободное место, откладывая саму запись до момента фактического сброса данных. Когда же такой момент наступает, XFS решает, куда необходимо их поместить. Если осуществляется дозапись, то подбираются соседние сектора. Но наибольший эффект от такой задержки получается еще и за счет того, что при создании временного файла с малым временем жизни последний вообще на диск не пишется (соответственно, не приходится занимать/освобождать метаданные). Для борьбы с внешней фрагментацией (это как раз то, против чего борются программы типа Norton Speed Disk) разработчики в ближайшее время планируют выпустить аналогичную утилиту. К сожалению, каноническим ядром пока данная ФС не поддерживается, хотя в экспериментальных 2.5.х версиях ядра поддержка ее уже включена, что позволяет надеяться на скорое решение этого вопроса, а некоторых дистрибутивах (Gentoo, Lunar Linux) она уже предлагается пользователю. Так что придется сходить на сайт разработчика за патчем (ftp://oss.sgi.com/projects/xfs/download) и необходимыми утилитами (как минимум xfsprogs) для работы с ней. Сейчас на сайте доступен релиз 1.2pre4, меньше 1.1 брать точно не стоит, в них были замечены некоторые ошибки, в частности, малая скорость удаления большого количества файлов. Теперь, пересобрав ядро и установив необходимые утилиты, можно создать файловую систему:

#/sbin/mkfs.xfs /dev/hdb2 или mkfs -t xfs /dev/hdb2

Для увеличения производительности в некоторых случаях может помочь опция -l size=32m, фиксирующая размер журнала (32 Мб), также с помощью -d agcount=x хорошо бы установить минимально возможное количество allocation groups (т.е. взяв максимально возможные 4 Гб на группу). Например, при разделе 18 Гб устанавливаем:

#/sbin/mkfs.xfs -d agcount=5 -l size=32m -f /dev/hdb2

Необязательная опция -f позволяет создать XFS поверх любой существующей ФС, но при создании раздела поверх ReiserFS (и наоборот) необходимо заполнить нулями начальный раздел, содержащий метаданные перед переформатированием, т.к. команда mount может неправильно определить, какая из файловых систем установлена. Вот как это делается:

# dd if=/dev/zero of=/dev/hdb2

Прервать операцию секунд через 10 - 20 комбинацией Ctr+C. Смонтировать вновь созданный раздел теперь можно командой

# mount -t xfs =/dev/hdb2 /home или в файле /etc/fstab /dev/hdb2 /home xfs defaults 0 0

Для повышения производительности можно задать некоторые опции noatime, nodiratime, osyncisdsync, вместе помогающие добиться асинхронного вывода информации и практически имитировать поведение ext2, а также logbufs, устанавливающую размер буфера (по умолчанию равен 2), - здесь особо усердствовать не стоит, например, 8 при 128 Мб оперативной памяти уже многовато:

/dev/hdb2 /home xfs noatime, nodiratime, osyncisdsync,logbufs=4 0 0

Остальную информацию смотрите в каталоге /usr/src/linux/Documentation/filesystems, файл xfs.txt.

JFS (Journaled File System)

Первоначально создана фирмой IBM для своей OS/2 Warp, а затем выпущена по лицензии GPL и портирована под Linux. Всю необходимую информацию можно получить по адресу http://oss.software.ibm.com/jfs. По своим характеристикам и архитектуре очень схожа с предыдущей, поэтому вдаваться в подробности не буду. Как и в предыдущей, в этой файловой системе раздел логически подразделяется на <агрегаты>, но последние включают, кроме данных, еще и отдельный журнал, при этом каждый из таких сегментов можно монтировать отдельно; также имеется возможность хранения маленьких файлов в пределах inode. Если катлог имеет до 8 файлов, то информация о них содержится в самом inode, при увеличении же их количества используются уже знакомые B+-деревья. По тестам это, наверное, самая медленная файловая система из рассматриваемых, хотя и разрабатывалась она для работы на высокопроизводительных серверах. Для установки необходима утилита jfsutils, патч к ядру jfs-2.4.х-patch и код ФС jfs-2.4-1.0.20.tar.gz. После установки и компиляции всех программ для создания раздела достаточно выполнить команду

# mkfs.jfs /dev/hdb3

и смонтировать ее:

# mount -t jfs /dev/hdb3 /jfs.

Для возможности работы с внешним журналом необходимо два неиспользуемых раздела, например:

# mkfs.jfs -j /dev/hdb1 /dev/hda6 # mount -t jfs /dev/hda6 /jfs или в /etc/fstab /dev/hda6 /jfs jfs defaults 1 2

***

Как видите, ОС Linux предоставляет пользователю возможность выбрать даже файловую систему под конкретные задачи. И самое главное, необязательно, чтобы была установлена только одна из этих файловых систем. Например, для корневого раздела вполне подойдет ReiserFS, для /usr/local - ext3, а домашний каталог, битком набитый видео, можно отформатировать под XFS. В следующий раз поговорим об оставшихся утилитах и оптимизации работы диска. Linux forever!

(Продолжение следует)

---

Окончание, начало см. в МК © 8-11 (231-234).

К сожалению жесткий диск не резиновый и не может вместить все, что хочется на него записать, поэтому очень часто просто необходимо узнать, сколько осталось на нем свободного места. В таком случае самым простым вариантом будет воспользоваться консольной утилитой df (disk free):

[sergej@grinder sergej]# df /usr/local Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda7 1011928 501056 459468 53% /usr/local

Без аргументов утилита выдает отчет обо всех смонтированных файловых системах, по умолчанию в GNU-версии размер выдается в блоках по 1 Кб. Утилита имеет большое количество опций, но я чаще всего пользуюсь двумя: -Т выводит также тип файловой системы (берется, как правило, из /etc/mtab), -h (human-readable) выдает более привычный формат. Иногда для получения более достоверной информации можно воспользоваться опцией -sync, вызывающий сброс системного кэша. Естественно, в данном случае не обошлось без различных фронт-эндов, их множество в Gnome. Например, можно вызвать Система > Информация о системе (Рис. 1) или же просто воспользоваться gtop (Рис. 2). В KDE их тоже предостаточно - KdiskFree (kdf) (Рис. 3), Системные > Системный монитор (ksysguard) (Рис. 4) или же просто Центр Управления во вкладке Сведения о системе > Блочные устройства или Разделы.

   

   

Но выдаваемой df информации бывает недостаточно, иногда требуется более полная информация об используемом дисковом пространстве - в этом случае на помощь приходит утилита du (disk usage). Она позволяет узнать размер дискового пространства, занимаемый каждым каталогом или файлом. Запущенная без аргументов команда выдает список всех файлов текущего каталога. Программа имеет множество опций, все они описаны в соответствующем man'е. Я наиболее часто пользуюсь -h (назначение то же, что и в df) и -с - выводит только окончательный результат для указанных аргументов, иначе будет выведен отчет о каждом встреченном файле:

[sergej@grinder sergej]$ du -hs /usr/local 484M /usr/local

Конечно же, никто не мешает посмотреть размер файла с помощью подпункта Свойства контекстного меню Konqueror или в MC, но консольные утилиты удобны тем, что их можно использовать в скриптах, да и работают они побыстрее.

Следующей утилитой будет hdparm, которой все же желательно воспользоваться, так как настройки работы жесткого диска, по умолчанию устанавливаемых дистрибутивом, далеки от оптимальных, в связи с чем часто приходят письма, что, мол, диск о-о-очень тормозит под пингвином. С помощью же данной утилиты можно выжать максимальную производительность своего диска, но предупреждаю: действуйте очень осторожно, это как раз тот случай, когда лучше недобдеть чем перебдеть. Все я вам рассказать не смогу, лучше почитайте подшивку МК о различных режимах работы IDE-дисков для общего понимания процесса. Для начала необходимо получить полную информацию о жестком диске.

[root@grinder sbin]# /sbin/hdparm -i /dev/hda /dev/hda: Model=QUANTUM FIREBALLlct20 30, FwRev=APL.3900, SerialNo=353106162000 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4 BuffType=DualPortCache, BuffSize=418kB, MaxMultSect=8, MultSect=8 (# количество секторов, считываемое за раз максимальное и установленное) CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=58633344 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} # ниже перечислены режимы которые поддерживает жесткий диск, текущий обозначен звездочкой PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 AdvancedPM=no # поддержка APM WriteCache=enabled Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5

Теперь, запустив команду без параметров, узнаем, какие параметры уже установлены:

[root@grinder sbin]# /sbin/hdparm /dev/hda /dev/hda: multcount = 8 (on) # количество одновременно считываемых секторов (аппаратная возможность) I/O support = 1 (32-бит) # режим обмена с жестким диском (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) # DMA да/нет keepsettings = 0 (off) # сохраняются ли настройки после программного сброса (лучше не трогать) nowerr = 0 (off) readonly = 0 (off) # только для чтения (CD-ROM обычно в on) readahead = 8 (on) # указывает на количество секторов, для которых должно производиться опережающее чтение geometry = 3649/255/63, sectors = 58633344, start = 0 busstate = 1 (on)

Для установки максимального числа одновременно считываемых секторов необходимо воспользоваться опцией -m:

[root@grinder sbin]# /sbin/hdparm -m 8 /dev/hda

I/O support может быть трех режимов: 0-16 бит, 1-32 бит и 3-32 синхронный. В большинстве случаев максимальное быстродействие достигается установкой режима 1. Режим 0 можно оставить разве что для очень старых дисков, а 3 - для отдельных марок чипов. DMA устанавливается опцией -d (1 - вкл/0 - выкл)

[root@grinder sbin]# /sbin/hdparm -d 1 /dev/hda

С помощью флага -а можно установить параметр readahead, который в оптимальном случае должен равняться аппаратно заложенной возможностью считывания одновременно нескольких секторов multcount, но если есть необходимость в частом чтении файлов большого размера, то можно его немного увеличить, это повысит производительность.

[root@grinder sbin]# /sbin/hdparm -а 16 /dev/hda

С помощью опции -А можно вообще отключить данный режим, хотя вообще это абсолютно бесполезная в большинстве случаев опция.

А вот режимы PIO и DMA устанавливаются с помощью одного и того же флага -Х. Использовать данный ключ нужно очень внимательно, устанавливать только реально поддерживаемые диском режимы, а то можно спокойно потерять все данные. Так, для установки выбранного режима PIO необходимо добавить к числу 8 требуемый номер режима. Например, для PIO2 команда будет такая:

[root@grinder sbin]# /sbin/hdparm -Х10 /dev/hda

где 10=8+2 режим. Аналогично для mdma (multiword DMA) используется начальное число 32 (плюс номер режима), а для UltraDMA начальным будет число 64. Например, для установки UltraDMA5 вводим такую команду:

[root@grinder sbin]# /sbin/hdparm -Х69 /dev/hda

Но нужно помнить: мало того, чтобы режим UltraDMA поддерживался жестким диском, необходимо также, чтобы его поддержка была заложена в материнскую плату (южный мост). Если нахомутали с данным режимом, то, введя 00, можно вернуться к режиму по умолчанию.

Hdparm - мощная утилита, имеющая множество параметров, правда, в большинстве своем бесполезных в практическом применении. Из оставшихся интерес представляет разве что параметр -Е для установки скорости CD-ROM приводов, а также -t и -T, позволяющие оценить производительность: первый оценивает скорость считывания из кэша буфера на диск, второй - скорость чтения непосредственно из кэша буфера без доступа к диску.

[root@grinder sergej]# /sbin/hdparm -t -T /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 1.32 seconds = 102.40 MB/sec Timing buffered disk reads: 64 MB in 3.12 seconds = 20.51 MB/sec

Также иногда может понадобиться параметр -r, позволяющий установить/снять флаг только для чтения для всего диска сразу, и -f, вызывающий синхронизацию буфера, т.е. сброс данных на диск (также можно вызвать, просто набрав sync). Может показаться, что это очень сложно и уныло, да и еще разбираться надо, проще в Windows воткнуть DMA и забыть, но как видите, данная утилита дает возможность тонко настроить режим работы диска, а если возникают неприятности при работе с максимальными параметрами, то установить такие, чтобы можно было спокойно работать.

Позволю себе привести маленький, но очень показательный пример из личного опыта. Захотелось мне как-то заиметь диск пообъемистей. Без проблем, пошел, купил и установил. Но вся заковырка состоит в том, что мой Quantum (нынче уже Maxtor) поддерживает максимально возможный режим UltraDMA 5, а вот материнка на чипсете ВХ, по старинке, - всего лишь 2. Так вот, установил Linux и с помощью hdparm выставил UltraDMA 2, т.к. все равно выше головы не прыгнешь. Все работало нормально, пока не перешел в <любимую> Windows 98SE. Там, чтобы облегчить жизнь своему диску, поступил аналогичным образом (Система > Свойства > : > DMA (в МЕ это устанавливается автоматически)). Windows, будучи впереди планеты всей, очевидно, вполне справедливо решила (или решил), что самый лучший режим - максимальный. Дальше можно не рассказывать, и о словах, которые я тогда говорил, тоже вам знать не надо. Разрешил эту проблему только с помощью программки, которую нашел на сайте производителя, с помощью которой диск может максимально работать в режиме АТА-33, но потерянные данные уже не вернешь. Так что бывают случаи, когда ручная настройка гораздо лучше автоматической. Тогда, кстати, наверное, и был мной забит самый большой и ржавый гвоздь в крышку с флагом Windows.

Идем дальше. Установленные таким образом параметры будут действительны только в период текущей сессии, после выключения питания или перезагрузки все настройки сбросятся. Для того чтобы задействовать их каждый раз, необходимо занести их в стартовый скрипт /etc/rc.d/rc.local или поместить их в отдельный файл, а в rc.local указать строку для запуска.

Посмотрев в файл /etc/rc.d/rc.sysinit, я нашел следующие довольно интересные строки:

# Turn off DMA on CD-ROMs. It more often than not causes problems. if [ -e /proc/ide ]; then for N in `grep -v ide-disk /proc/ide/*/*/driver 2>/dev/null | awk -F / '{ print $5 }'`; do hdparm -q -d0 /dev/$N >/dev/null 2>&1 done fi

Т.е., у нас не спрашивая, принудительно выключают режим DMA на CD-ROM, ссылаясь на возможные проблемы. Еще ниже есть не менее интересные строки, которые полностью приводить не буду, но суть их такова (опять же для Red Hat и компании). В каталоге /etc/sysconfig/ есть файл-шаблон установок параметров - harddisks. Для того чтобы установить режим для hda-диска, необходимо переименовать его в harddiskhda (cp /etc/sysconfig/harddisks /etc/sysconfig/harddiskhda), после чего можно его редактировать (он, кстати, хорошо комментирован). Так, установить режим DMA можно строкой USE_DMA=1, возможна установка и других параметров (MULTIPLE_IO, EIDE_32BIT, UNMASKIRQ, LOOKAHEAD), а с помощью EXTRA_PARAMS можно установить остальные режимы, например DMA -X66 или -a и -m. Кстати, в AltLinux всем этим заправляет другой скрипт - /etc/rc.d/scripts/idetune, а параметры устанавливаются в файле /etc/sysconfig/harddisk/hd$i, но удобный шаблон, увы, не предусмотрен.

На этом я хотел, собственно, и закончить статью, но в процессе переписки с читателями появилась необходимость осветить еще некоторые вопросы, чтобы полностью закрыть тему. Дело в том, что кроме классических файловых систем Linux поддерживает еще так называемые виртуальные файловые системы - devfs, procfs и tmpfs. О devfs я уже говорил в первой части статьи, procfs - это файловая система процессов, о ней также поговорили немного, осталась нетронутой tmpfs, доступная пользователям ядер серии 2.4.х. В двух словах: это RAMDISK-подобная файловая система, использующая для хранения информации оперативную память компьютера (точнее, ОЗУ + swap). Круто, да. Причем эта система не требует предварительного форматирования, т.е. команды mkfs.tmpfs в природе не существует. Если она поддерживается ядром (make хconfig > File systems > Virtual memory file system support), то она УЖЕ готова к использованию, т.е. в большинстве случаев необходимо просто указать точку входа (а может, выхода на поверхность, уж не знаю, как это назвать), с которой будет и общаться пользователь или программа. Создается такая точка все той же командой mount.

[root@grinder /]# mount tmpfs /mnt/tmpfs -t tmpfs

После этого можно работать с каталогом /mnt/tmpfs практически так же, как и с обычным диском, кроме двух моментов. Во-первых, размер такой ФС, как вы понимаете, невелик, во-вторых, в случае отключения электричества все, что там было, улетучится вместе с многочасовыми трудами. Но есть и положительные стороны - например, в нее можно смонтировать каталог /tmp, в котором хранятся временные файлы и который все равно очищается в большинстве случаев при запуске (или захламляется всяким мусором). Но все окупается той скоростью, которую может дать tmpfs. Ведь т.к. данная файловая система уже находится в оперативной памяти, то самые медленные операции ввода-вывода здесь происходят практически мгновенно, а если объема ОЗУ будет мало и понадобится использовать swap, то туда в первую очередь будут сбрасываться приложения, в которых система наименее нуждается в данный момент. Поэтому, если есть необходимость в компиляции больших пакетов, или же если вы работаете с музыкой, графикой или видео, то не использовать данную возможность - все равно что таскать щебенку ведрами, когда есть тачка. Опять же, никакой надежды на автоматику, как в Windows: нужна скорость - откусил кусок от оперативки, и работай с ней. Один интересный вопрос возникает при использовании tmpfs. А что будет, если произойдет ее переполнение? Да ничего страшного и не будет. В более новых ядрах при достижении определенного объема информация туда просто перестанет записываться (хотя в первых ядрах серии 2.4.х могут возникнуть проблемы). Но чтобы на всякий случай не доводить до такого, можно с помощью опции size указать максимальный размер при монтировании:

[root@grinder /]# mount tmpfs /mnt/tmpfs -t tmpfs -o size=128m

И конечно же, воспользовавшись файлом /etc/fstab, можно монтировать tmpfs при загрузке, посмотрите внимательно там уже есть наверняка такие строки:

none /dev/shm tmpfs defaults 0 0

или

none /dev/shm tmpfs size=1g 0 0

где /dev/shm - <законное> место данной файловой системы. Чтобы ничего не изменять, я для удобства создал символическую ссылку, которой и пользуюсь в повседневной деятельности:

[root@grinder /]# ls-l /dev/shm /mnt/tmpfs

Вот теперь, пожалуй, и все. Остальное в man'ах и в Интернете. По адресу http://linux.yaroslavl.ru/docs/conf/fs/l-fs_ru/l-fs_ru.htm, можно найти переводы цикла статей Daniel'a Robbins'a, оригинал которых расположен на сайте IBM (http://www-106.ibm.com/developerworks/library/l-fs.html - цикл неокончен, ожидается еще продолжение). И еще новость: заработал, наконец, в полную мощность сайт LinuxBegin, назначение которого - помочь пользователю в освоении этой непростой системы и имеющий к тому же мою самую любимую рассылку по Linux. Адрес такой: http://www.linuxbegin.ru/.

---

---

---