Структура Файловой Системы XFS

Николай (unDEFER) Кривченков

Эта статья описывает структуру файловой системы XFS (disk-layout). Она написана «по горячим следам» после создания утилиты build_xfs для проекта anyfs-tools ( http://anyfs-tools.sourceforge.net ).

Все они довольно разрознены и такого описания как в 16-ой главе книги В.Костромина «Linux для пользователя»:
http://www.linuxcenter.ru/lib/books/kostromin
по Ext2FS, по XFS не найти.

Эта статья не является полным описанием структуры XFS. Она описывает её лишь в той степени, которая мне была необходима для написания build_xfs. Таким образом останутся незатронутыми назначения real-time блоков, структура журнала, расширенные аттрибуты и многие другие поля в структурах, от понимания назначения, которых я сам всё ещё далёк.

Перед знакомством с этой статьёй желательно иметь некоторое представление о том как устроены Файловые Системы вообще и Ext2FS в частности.

Итак, передо мной лежат 9 листов рукописи структур данных XFS, а ниже я попробую привести это всё в хоть каком-то упорядоченном виде. Писать постараюсь по возможности живым языком, чтобы читать эту статью было не слишком скучно.

Сообщения об ошибках, поправки и пожелания по поводу этой статьи прошу направлять по адресу: undefer@gmail.com

Итак, вся файловая система делится на так называемые Группы Выделения ( Allocation Groups или просто AG ), аналог групп Блоков в Ext2FS.

Размер/количество и прочее описание Групп Выделения находится в суперблоке, а суперблок находится в начале каждой из Групп Выделения (т.е. здесь пока всё как и в Ext2FS), а потому сразу перейдём к описанию её структуры.

По меньшей мере первые 0x800 байт (2048 байт, 2 Кб) каждой Группы Выделения имеют совершенно одинаковый формат. Причём нулевая (будем считать всё от нуля) Группа Выделения (а вместе с ней и нулевой суперблок) располагается прямо в начале устройства. Здесь, важное отличие от абсолютного числа других Файловых Систем: когда ребятами из SGI проектировалась их файловая система XFS ещё для платформы IRIX, они и думать не думали ни о каких загрузчиках в начале диска, а потому даже не пытайтесь ставить загрузчик в раздел с XFS.

Я бы мог привести цитату этого файла, как обычно это делается в таких случаях, но для описания структуры в данном случае это вовсе не удобно уже потому, что названия типов вроде xfs_drfsbno_t ничего не говорят об их размере.

А потому, я буду записывать структуры в формате, который был более удобен для меня. Надеюсь, он также будет удобен и для Вас.

Вторым же полем в суперблоке идёт размер блока ( sb_blocksize ). И я думаю не надо объяснять с каким смещением в файловой системе должен находится скажем блок 12. Правильно, в нашем случае, со смещением 12 x 4096.

Файловая система XFS любопытна тем, что такой же метод как для блоков применён и в отношении инф.узлов, т.е. номер инф.узла одновременно однозначно определяет и его местоположение в файловой системе. В связи с чем существуют поля размера инф.узла (0x68 sb_inodesize ) и числа инф.узлов на блок (0x6A sb_inopblock ). Таким образом размер инф.узла должен быть меньше размера блока в число раз являющемся степенью двойки.

В приведённом примере корневой узел имеет номер 128 (0x38 sb_rootino ). Таким образом его смещение можно вычислить как 128 x 256.

Если, теперь, я попрошу Вас назвать смещение блока номер 16384, выходящем за пределы первой Группы Выделения, вы смело можете назвать 16384 x 4096 и.. не ошибётесь.

Дело всё в том, что поле sb_agblklog существует не просто так, оно действительно округляет размер Группы Выделения, и для Групп Выделения в 16000 блоков, sb_agblklog по-прежнему равно 14.

Таким образом номер блока равен:

Определение структуры xfs_agf находится в файле /usr/include/xfs/xfs_ag.h.

Это позволяет быстро найти группу свободных блоков наиболее подходящего размера.

В примере структуры указано, что корни этих деревьев (элементы массива 0x10 agf_roots ) находятся в блоках 1 и 2. Т.к. уровни деревьев (элементы массива 0x1C agf_levels ) равны единице, то эти корни одновременно являются и листьями. А подробнее структура Би-дереьев будет описана ниже.

Список этих зарезервированных блоков располагается со смещением 0x600 в Группе Выделения. Он представляет из себя простой массив с элементами по 32 бита каждый.

В приведённом примере в этом массиве хранится 4 элемента (0x30 agf_flcount ) с индексами от 0 (0x28 agf_flstart ) до 3 (0x2C agf_fllast ).

А, вот, собственно, пример этого списка:

Инф.узлы выделяются группами по 64 штуки. Информация о занятости/свободе инф.узлов такой группы хранится всё в том же bitmap’е (64-битном числе).

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

Такая схема позволяет снять ограничение на количество инф.узлов присущее многим другим файловым системам. На XFS сообщение «Не достаточно места» однозначно, оно не может означать «Таблица инф.узлов переполнена» при создании файла.

Подробнее о всех Би-деревьях в следующем разделе.

Ну, ладно, ладно.. Не буду вас отправлять на английскую Википедию.. Скажу пару слов по-русски.

Примерно так. Хотя очень не точно, но относительно XFS всё вышесказанное верно.

Да, чтобы описать две структуры одной схемой нам пришлось немного «смухлевать», но как видите они отличаются лишь размером ссылок на братьев (32 или 64 бит).

Само собой заголовок это ещё не весь блок. Основные данные следуют далее.

Для листьев всё просто: сразу же за полем bb_rightsib следует массив записей (фиксированного размера) в количестве bb_numrecs штук.

Для узлов же всё несколько сложнее. Записи здесь разделены на две части: ключ и указатель на блок более нижнего уровня (на подветку) отвечающего этой записи.

Записи листьев и ключи узлов у Би-деревьев свободных блоков имеют одну и ту же структуру xfs_alloc_rec (файл /usr/include/xfs/xfs_alloc_btree.h)

Однако, ключи узлов Би-деревьев с сортировкой по размеру фрагментов имеют перевёрнутую структуру: Остаётся только удивляться почему же записи листьев в таком случае у них всё равно имеют прямую структуру.

Записи листьев описываются структурой xfs_inobt_rec (файл /usr/include/xfs/pwd).

Ключом в данных деревьях является единственное значение:

Реальное объяснение всего этого безобразия (иначе, я просто не могу это назвать) будет дано в пункте «Карта блоков» следующего раздела.

Ключом в Би-деревьях карты блоков является также единственное значение:

Структура инф.узлов делится на две части: общая для всех (ядро инф.узла) и зависимая от типа.

В основном данные предоставляемые этой структурой совпадают с данными структуры stat выдаваемой соотсветсвующим системным вызовом, что не удивительно.

Значение di_format = XFS_DINODE_FMT_DEV предназначено для специальных файлов.

Надо сказать, что этот формат явно имеет исторические причины, и даже макрос-конструктор xfs_dev_t из MAJOR и MINOR-чисел имеет название IRIX_MKDEV.

Значение di_format = XFS_DINODE_FMT_LOCAL означает, что сам инф.узел находится прямо в хвосте его описания (со смещением 0x64).

Это применимо для символических ссылок и коротких директорий.

Тут стоит сказать об одном странном ограничении XFS: длина символических ссылок здесь не должна превышать (так же как имя файла) 255 символов. Если для имени файла такое ограничение вполне понятно, то о причинах такого же ограничения для символических ссылок остаётся только догадываться. В Ext2FS длина символической ссылки в свою очередь ограничена размером блока. (т.е. обычно это 4096 или 4095 символов)

Значение di_format = XFS_DINODE_FMT_EXTENTS означает, что в хвосте описания инф.узла находится карта блоков.

Да, почему-то создатели пожадничали ещё 32 бита для этой структуры. О причинах этого нам опять же остаётся только догадываться (возможно, всё опять же для выравнивания).

Значение di_format = XFS_DINODE_FMT_BTREE означает, что в хвосте описания инф.узла находится корень Би-дерева карты блоков.

Вы, вероятно, уже обратили внимание на уровень вложенности содержания этого пункта..

Ну, так начнём наш сказ.

Директория в этом случае имеет структуру xfs_dir2_sf (файл /usr/include/xfs/xfs_dir2_sf.h):

Элементы имеют структуру xfs_dir2_sf_entry (файл всё тот же):

Структура одноблочной директории xfs_dir2_block описана в файле /usr/include/xfs/xfs_dir2_block.h:

Последующее описание структуры возможно имело бы смысл начать с конца (я подозреваю что драйвер файловой системы просматривает её именно так), тем не менее мы не будем переворачивать всё с ног на голову.. Пойдём попорядку.

Где элементы массива bestfree имеют структуру xfs_dir2_data_free (файл тот же):

Надеюсь, вы теперь также прекрасно понимаете почему offset кратен восьми.

Перейдём теперь непосредственно к этим подблокам:

В группе подблоков хранится union xfs_dir2_data_union_t (файл всё ещё /usr/include/xfs/xfs_dir2_data.h):

Итак, элемент директории описывается структурой xfs_dir2_data_entry (файл всё тот же):

Группа свободных подблоков описывается структурой xfs_dir2_data_unused (тот же файл):

Теперь должно быть уже понятно, что за offset был в короткой форме директории.

В одноблочной директории уже присутствуют элементы ‘.’ и ‘..’.

Т.е. каждый такой элемент состоит из значения хэша и указателя в виде номера подблока.

Каждый такой элемент хэша сам занимает один подблок. Элементы в массиве отсортированы по возрастанию хэша.

Это структура xfs_dir2_block_tail (файл /usr/include/xfs/xfs_dir2_block.h):

Смысла элемента stale к сожалению мною найдено не было (всегда ноль?).

Если директория не помещается в один блок, то он разделяется на несколько следующим способом.

Итак, во-первых, из одноблочной директории исключается хэш. Полученная структура (блок данных директории) xfs_dir2_data (файл /usr/include/xfs/xfs_dir2_data.h) также занимает целый блок, но в отличии от блока одноблочной директории, в многоблочной директории блоков данных может быть несколько:

Формат элемента хэша (структура xfs_dir2_leaf_entry ) уже была описана выше.

Действительно интересен здесь заголовок..

Где заголовок узла Би-дерева хэша это структура xfs_da_blkinfo (файл /usr/include/xfs/xfs_da_btree.h):

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

Да, для массива bests[] здесь тоже выделяется отдельный блок. Это структура xfs_dir2_free (файл /usr/include/xfs/xfs_dir2_node.h):

Таким образом таких блоков в одной директории тоже может быть несколько (при этом в каждом таком блоке поле firstdb равно сумме nvalid всех предыдущих блоков).

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

Если у файла совершенно ясно что такое 0-ой байт, 5-ый, 10-ый.. То у директории с этим некоторый напряг..

Хорошо, пусть блоки данных мы уложим попорядку и соответсвующим образом проадресуем, но как же блоки хэша и блоки лучших свободных подблоков?

Тут разработчики XFS, чтобы уже по адресу можно было понять является ли блок блоком данных, хэша или блоком лучших свободных подблоков решили разделить адресное пространство директорий на соответсвенно три части (по 32 Гб):

В хэше узлов в качестве ключа указывается значение ключа самого последнего из всех его дочерних элементов.

This document was generated using the LaTeX 2HTML translator Version 2002-2-1 (1.70)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The translation was initiated by unDEFER on 2006-08-19
unDEFER 2006-08-19

Источник

Понимая, как используется дисковое пространство в Linux

Прим перев.: Автор оригинальной статьи — испанский Open Source-энтузиаст nachoparker, развивающий проект NextCloudPlus (ранее известен как NextCloudPi), — делится своими знаниями об устройстве дисковой подсистемы в Linux, делая важные уточнения в ответах на простые, казалось бы, вопросы…

Сколько пространства занимает этот файл на жёстком диске? Сколько свободного места у меня есть? Сколько ещё файлов я смогу вместить в оставшееся пространство?

Ответы на эти вопросы кажутся очевидными. У всех нас есть инстинктивное понимание работы файловых систем и зачастую мы представляем хранение файлов на диске аналогично заполнению корзины яблоками.

Однако в современных Linux-системах такая интуиция может вводить в заблуждение. Давайте разберёмся, почему.

Размер файла

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

Зачастую всё содержимое файла представляется как расположенное байт за байтом:

Здесь можно увидеть знакомые атрибуты, такие как время доступа и модификации, а также i_size — это и есть размер файла, как он был определён выше.

Размышлять в терминах размера файла интуитивно понятно, но больше нас интересует, как в действительности используется пространство.

Блоки и размер блока

Для внутреннего хранения файла файловая система разбивает хранилище на блоки. Традиционным размером блока были 512 байт, но более актуальное значение — 4 килобайта. Вообще же при выборе этого значения руководствуются поддерживаемым размером страницы на типовом оборудовании MMU (memory management unit, «устройство управления памятью» — прим. перев.).

Файловая система вставляет порезанный на части (chunks) файл в эти блоки и следит за ними в метаданных. В идеале всё выглядит так:

… но в действительности файлы постоянно создаются, изменяются в размере, удаляются, поэтому реальная картина такова:

Это называется внешней фрагментацией (external fragmentation) и обычно приводит к падению производительности. Причина — вращающейся головке жёсткого диска приходится переходить с места на место, чтобы собрать все фрагменты, а это медленная операция. Решением данной проблемы занимаются классические инструменты дефрагментации.

Что происходит с файлами меньше 4 КБ? Что происходит с содержимым последнего блока после того, как файл был порезан на части? Естественным образом будет возникать неиспользуемое пространство — это называется внутренней фрагментацией (internal fragmentation). Очевидно, этот побочный эффект нежелателен и может привести к тому, что многое свободное пространство не будет использоваться, особенно если у нас большое количество очень маленьких файлов.

Таким образом, мы смотрим на две величины: размер файла и использованные блоки. Мы привыкли думать в терминах первого, однако должны — в терминах последнего.

Специфичные для файловой системы возможности

Помимо актуального содержимого файла ядру также необходимо хранить все виды метаданных. Метаданные inode’а мы уже видели, но есть и другие данные, с которыми знаком каждый пользователь UNIX: права доступа, владелец, uid, gid, флаги, ACL.

Наконец, существуют ещё и другие структуры — вроде суперблока (superblock) с представлением самой файловой системы, vfsmount с представлением точки монтирования, а также информация об избыточности, именные пространства и т.п. Как мы увидим далее, некоторые из этих метаданных также могут занимать значительное место.

Метаданные размещения блоков

Эти данные сильно зависят от используемой файловой системы — в каждой из них по-своему реализовано сопоставление блоков с файлами. Традиционный подход ext2 — таблица i_block с прямыми и непрямыми блоками (direct/indirect blocks).

Эту же таблицу можно увидеть в структуре памяти (фрагмент из fs/ext2/ext2.h ):

Для больших файлов такая схема приводит к большим накладным расходам, поскольку единственный (большой) файл требует сопоставления тысяч блоков. Кроме того, есть ограничение на размер файла: используя такой метод, 32-битная файловая система ext3 поддерживает файлы не более 8 ТБ. Разработчики ext3 спасали ситуацию поддержкой 48 бит и добавлением extents:

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

Примечание для любопытных: у ext4 предусмотрена обратная совместимость, то есть в ней поддерживаются оба метода: непрямой (indirect) и extents. Увидеть, как распределено пространство, можно на примере операции записи. Запись не идёт напрямую в хранилище — из соображений производительности данные сначала попадают в файловый кэш. После этого в определённый момент кэш записывает информацию на постоянное хранилище.

Контрольные суммы

Файловые системы последнего поколения хранят также контрольные суммы (checksums) для блоков данных во избежание незаметного повреждения данных. Эта возможность позволяет обнаруживать и корректировать случайные ошибки и, конечно, ведёт к дополнительным накладным расходам в использовании диска пропорционально размеру файлов.

Более современные системы вроде BTRFS и ZFS поддерживают контрольные суммы для данных, а у более старых, таких как ext4, реализованы контрольные суммы для метаданных.

Журналирование

Это специальный скрытый файл, обычно с номером inode 8 и размером 128 МБ, объяснение про который можно найти в официальной документации:

Журнал, представленный в файловой системе ext3, используется в ext4 для защиты ФС от повреждений в случае системных сбоев. Небольшой последовательный фрагмент диска (по умолчанию это 128 МБ) зарезервирован внутри ФС как место для сбрасывания «важных» операций записи на диск настолько быстро, насколько это возможно. Когда транзакция с важными данными полностью записана на диск и сброшена с кэша (disk write cache), запись о данных также записывается в журнал. Позже код журнала запишет транзакции в их конечные позиции на диске (операция может приводить к продолжительному поиску или большому числу операций чтения-удаления-стирания) перед тем, как запись об этих данных будет стёрта. В случае системного сбоя во время второй медленной операции записи журнал позволяет воспроизвести все операции вплоть до последней записи, гарантируя атомарность всего, что пишется на диск через журнал. Результатом является гарантия, что файловая система не застрянет на полпути обновления метаданных.

«Упаковка хвостов»

Возможность tail packing, ещё называемая блочным перераспределением (block suballocation), позволяет файловым системам использовать пустое пространство в конце последнего блока («хвосты») и распределять его среди различных файлов, эффективно упаковывая «хвосты» в единый блок.

Замечательно иметь такую возможность, что позволяет сохранить много пространства, особенно если у вас большое количество маленьких файлов… Однако она приводит к тому, что существующие инструменты неточно сообщают об используемом пространстве. Потому что с ней мы не можем просто добавить все занятые блоки всех файлов для получения реальных данных по использованию диска. Эту фичу поддерживают файловые системы BTRFS и ReiserFS.

Разрежённые файлы

Большинство современных файловых систем поддерживают разрежённые файлы (sparse files). У таких файлов могут быть дыры, которые в действительности не записаны на диск (не занимают дисковое пространство). На этот раз реальный размер файла будет больше, чем используемые блоки.

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

Чтобы медленно создать 10-гигабайтный файл, который занимает около 10 ГБ дискового пространства, можно выполнить:

Чтобы создать такой же большой файл мгновенно, достаточно лишь записать последний байт… или даже сделать:

Или же воспользоваться командой truncate :

Команда cp поддерживает работу с разрежёнными файлами. С помощью простой эвристики она пытается определить, является ли исходный файл разрежённым: если это так, то результирующий файл тоже будет разрежённым. Скопировать же неразрежённый файл в разрежённый можно так:

… а обратное действие (сделать «плотную» копию разрежённого файла) выглядит так:

Таким образом, если вам нравится работать с разрежёнными файлами, можете добавить следующий алиас в окружение своего терминала (

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

Файловые системы COW (copy-on-write)

Следующее (после семейства ext) поколение файловых систем принесло очень интересные возможности. Пожалуй, наибольшего внимания среди фич файловых систем вроде ZFS и BTRFS заслуживает их COW (copy-on-write, «копирование при записи»).

Когда мы выполняем операцию copy-on-write или клонирования, или копии reflink, или поверхностной (shallow) копии, на самом деле никакого дублирования extent’ов не происходит. Просто создаётся аннотация в метаданных для нового файла, которая отсылает к тем же самым extents оригинального файла, а сам extent помечается как разделяемый (shared). При этом в пользовательском пространстве создаётся иллюзия, что существуют два отдельных файла, которые можно отдельно модифицировать. Когда какой-то процесс захочет написать в разделяемый extent, ядро сначала создаст его копию и аннотацию, что этот extent принадлежит единственному файлу (по крайней мере, на данный момент). После этого у двух файлов появляется больше отличий, однако они все ещё могут разделять многие extents. Другими словами, extents в файловых системах с поддержкой COW можно делить между файлами, а ФС обеспечит создание новых extents только в случае необходимости.

Как видно, клонирование — очень быстрая операция, не требующая удваивания пространства, которое используется в случае обычной копии. Именно эта технология и стоит за возможностью создания мгновенных снапшотов в BTRFS и ZFS. Вы можете буквально клонировать (или сделать снапшот) всей корневой файловой системы меньше чем за секунду. Очень полезно, например, перед обновлением пакетов на случай, если что-то сломается.

/.bashrc ) может пригодиться, если вы хотите по умолчанию делать быстрые shallow-копии:

Следующий шаг — если есть не-shallow-копии или файл, или даже файлы, с дублирующимися extents, можно дедуплицировать их, чтобы они использовали (через reflink) общие extents и освободили пространство. Один из инструментов для этого — duperemove, однако учтите, что это естественным образом приводит к более высокой фрагментации файлов.

Если мы попытаемся теперь разобраться, как дисковое пространство используется файлами, всё будет не так просто. Утилиты вроде du или dutree всего лишь считают используемые блоки, не учитывая, что некоторые из них могут быть разделяемыми, поэтому они покажут больше занятого места, чем на самом деле используется.

К сожалению, я не знаю простых способов отслеживания занятого пространства отдельными файлами в файловых системах с COW. На уровне подтома с помощью утилит вроде btrfs-du мы можем получить приблизительное представление о количестве данных, которые уникальны для снапшота и которые разделяются между снапшотами.

Источник

Основы Linux от основателя Gentoo. Часть 4 (1/4): Файловые системы, разделы и блочные устройства

Навигация по основам Linux от основателя Gentoo:

Часть I: 1, 2, 3, 4

Часть II: 1, 2, 3, 4, 5

Часть III: 1, 2, 3, 4

Часть IV

Предисловие

Об этом руководстве

Добро пожаловать в «Системное администрирование», последнюю из четырех частей руководства, предназначенного для подготовки к экзамену “101 Linux Professional Institute’s”. В этой части, вы познакомитесь с такими навыками администрирования Linux, как файловые системы, процесс загрузки, уровни запуска, файловые квоты, а также системные журналы (логи).

Это руководство является особенно полезным для тех, кто хочет впервые попробовать себя в качестве системного администратора, так как тут описано много основных вопросов, которые должны знать системные администраторы. Если вы новичок в Linux, мы рекомендуем вам начать изучение с части 1. Для некоторых, большая часть этого материала будет новой, но и более опытные пользователи Linux могут найти в этом руководстве новое для себя, что может быть отличным способом обновления своих знаний по системному администрированию Linux и подготовке к следующему уровню сертификации LPI.

К концу этой серии учебных пособий (всего их восемь для экзаменов LPI 101 и 102), вы будете иметь знания, необходимые, чтобы стать администратором систем Linux и будете готовы для достижения первого уровня LPIC сертификации от “Linux Professional Institute” если вы того пожелаете.

Файловые системы, разделы и блочные устройства

Введение в блочные устройства

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

Вначале ознакомимся с «блочными устройствами». Наиболее известным блочным устройством, вероятно, будет первый диск IDE в системе Linux, который будет называться: /dev/hda

Если в вашей системе есть SCSI диски (или, что вероятнее, вы используете современным драйвер libATA — прим. ред.), то он будет называться: /dev/sda

Уровни абстрагирования

Блочные устройства представляют абстрактный интерфейс к диску. Пользовательские программы могут использовать эти блочные устройства для взаимодействия с диском, не беспокоясь о том, что у вас за диски: IDE, SCSI, или какие-то другие. Программы могут легко адресовать место на диске, как последовательность блоков по 512 байт с произвольным доступом.

Разделы

Введение в fdisk

Примечание:

Важно!

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

Внутри fdisk

Введите p для отображения текущей таблицы разделов вашего диска:

Данный диск сконфигурирован для размещения семи файловых систем Linux (каждая на соответсвующем разделе, помеченном как «Linux»), а также раздела подкачки (помечен как «Linux swap»).

Обзор блочных устройств и разделов

Разметка диска

Все разделы от hda5 и далее — это логические разделы. Номера с hda1 по hda4 зарезервированы для первичных или расширенного разделов.

Типы разделов

Использование fdisk для создания разделов

Теперь, когда вы имеете представление о дисковых разделах в Linux, пришло время, чтобы начать процесс создания разделов на диске и ФС для установки Linux. Мы настроим разделы на диске, а затем создадим файловые системы на них. На этом этапе мы полностью очистим диск от данных, и будем его использовать для установки новой копии Linux системы.

Важно!

Для выполнения этих действий, у вас должен быть жесткий диск, который не содержит никакой важной информации, так как, на этом этапе, данные на диске будут удалены. Если это всё для вас в новинку, вы можете только прочитать эти шаги, или воспользоваться загрузочным диском с Linux на тестовой системе (например в виртуальной машине — прим. ред.), так что данные не будут в опасности.

Как будет выглядеть диск после разбивки

После того, как мы пройдем процесс создания разделов на вашем диске, ваша таблица разделов будет выглядеть примерно так:

Комментарий к примеру

Рекомендовалось держать загрузочный раздел (содержащий всё необходимое для загрузки) в начале диска. Это не обязательно, так как берет свои истоки из прошлого, когда загрузчик LILO не мог загружать ядро с файловых систем, которые располагались за 1024 цилиндром диска.

Начало работы

Теперь, чтобы создать разделы по примеру выше, введите fdisk /dev/hda или fdisk /dev/sda в зависимости от того, используете ли вы диски IDE или SCSI (или современную libATA — прим. ред.) соответственно. Затем введите “p” для просмотра текущей таблицы разделов. Есть ли что-то на диске, что требуется сохранить? Если да, остановитесь сейчас. Если вы продолжите, вся существующая информация на диске будет уничтожена.

Важно!

Нижеследующие инструкции уничтожат все существующие данные на диске! Если на диске есть какие-либо данные, убедитесь, что информация не является для вас критически важной. Также убедитесь что вы выбрали правильный диск, чтобы ошибочно не стереть данные с другого диска.

Удаление существующих разделов

Теперь самое время удалить все существующие разделы. Чтобы это сделать, введите “d” и нажмите Enter. Вам будет предложено выбрать номер раздела, который будет удален. Чтобы удалить существующий раздел /dev/hda1 вы должны ввести:

Command (m for help): d

Partition number (1-4): 1

Раздел будет запланирован для удаления. Он больше не будет отображаться, если вы введете “p”, но он не будет удален, пока вы не сохраните свои изменения. Если вы ошиблись и хотите отменить действия, введите “q”, и нажмите Enter, и ваш раздел не будет удален.

Теперь, предполагая, что вы в самом деле хотите удалить все разделы в вашей системе, наберите “p”, чтобы вывести еще раз список разделов, а затем введите “d” и номер раздела для удаления. В итоге вы получите пустую таблицу разделов:

Создание загрузочного раздела

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1

First cylinder (1-3876, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-3876, default 3876): +100M

Теперь введите “p”, вы должны увидеть нижеследующую таблицу разделов:

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 14 105808+ 83 Linux

Создание раздела подкачки

Теперь, давайте создадим раздел подкачки. Чтобы это сделать введите “n” для создания нового раздела, затем “p” чтобы сообщить fdisk что вы хотите создать первичный раздел. Затем введите “2” для создания второго первичного раздела, /dev/hda2 в нашем примере. Затем будет предложено ввести номер первого цилиндра, нажмите Enter, когда будет предложено ввести номер последнего цилиндра, введите “+512M” для создания раздела подкачки, размером 512 МБ. После того, как вы сделаете это, введите “t” для установки типа раздела, и затем введите “82” для установки типа ”Linux swap”. После завершения этих шагов, введите “p” для просмотра таблицы разделов, она должна быть похожей на эту:

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 14 105808+ 83 Linux
/dev/hda2 15 81 506520 82 Linux swap

Делаем загрузочным

В завершении мы должны установить флаг «загрузочный» на наш загрузочный раздел и записать изменения на диск. Для отметки раздела /dev/hda1 как «загрузочного» раздела, введите в меню “a” и затем “1” как номер раздела. Если вы введете сейчас “p”, вы увидите что /dev/hda1 содержит символ “*” в столбце Boot. Теперь давайте запишем наши изменения на диск. Для этого введите “w” и затем Enter. Ваши разделы диска сейчас правильно сконфигурированы для установки Linux.

Замечание:

Если fdisk запрашивает перезагрузку, пожалуйста, сделайте это для того, чтобы ваша система определила новую настройку разделов.

Расширенные и логические разделы

В приведенном выше примере мы создали один первичный раздел который будет содержать ФС для хранения всех наших данных. Это означает что после установки Linux, главная файловая система будет смонтирована в “/” и будет содержать дерево директорий которое содержит все наши файлы.

Хотя это общий подход, есть и другой подход, с которым вы тоже должны быть знакомы. Этот подход использует несколько разделов, как место для нескольких ФС, и которые вместе образовывают дерево файловой системы. Например, довольно распространено помещать /home и /var в отдельные ФС.

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

Создание файловых систем

Теперь, когда разделы уже созданы, пришло время установить ФС на загрузочные и корневые разделы так, чтобы они могли использоваться для хранения данных. Мы также настроим раздел подкачки для обслуживания данных подкачки.

Линукс поддерживает различные типы ФС; каждый из них имеет свои достоинства и недостатки и свои характеристики. Мы рассмотрим создание файловых систем ext2, ext3, XFS, JFS и ReiserFS в этом руководстве. Перед созданием ФС на нашем примере, мы кратко рассмотрим различные файловые системы доступные в Linux.

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

Файловая система ext2

ext2 является проверенной годами файловой системой Linux, но она не обладает средствами журналирования метаданных, что означает, что время на проверку файловой системы во время запуска может быть довольно большим. В настоящее время существует широкий выбор журналируемых файловых систем, которые могут быть проверены на целостность очень быстро, и потому предпочтительны, нежели их не журналируемые аналоги. Журналируемая ФС позволяет избежать долгих задержек при старте системы, когда целостность вашей ФС нарушена (например, в случае сбоя электроснабжения — прим. ред.).

Файловая система ext3

ext3 – журналируемая версия файловой системы ext2, которая обеспечивает журналирование метаданных для быстрого восстановления, а также другие режимы журналирования, такие как полное журналирование всех данных и упорядоченное журналирование. ext3 – очень хорошая и надежная ФС. Она предлагает достойную производительность в большинстве случаев. Поскольку она мало использует «деревья» в своем внутреннем устройстве, она плохо масштабируется, это означает, что этот тип ФС не лучший выбор для очень больших файловых систем, или в условиях, когда вы будете обрабатывать большие файлы или большое количество файлов в одном каталоге. Но при использовании её в условиях, под которые она проектировалась, ext3 прекрасная файловая система.

Одна из приятных особенностей ext3 – это то, что существующие системы ext2 могу быть обновлены «на месте» до ext3 довольно просто. Это позволяет плавно обновлять существующие системы Linux, которые уже используют ext2.

Файловая система ReiserFS

ReiserFS – это файловая система, основанная на B-дереве, которая имеет очень хорошую производительность и значительно превосходит ext2 и ext3 при работе с небольшими файлами (файлы менее 4 кБ), часто в 10-15 раз. А также ReiserFS отлично масштабируется и имеет журналирование метаданных. Начиная с ядра версии 2.4.18 и выше, ReiserFS является стабильной и рекомендуется, как в качестве ФС общего назначения, так и в крайних случаях, таких как создание больших файловых систем, использование для множества маленьких файлов, для огромных файлов, а также для каталогов с десятками тысяч файлов. Мы рекомендуем ФС ReiserFS для использования по умолчанию для всех не загрузочных разделов.

Файловая система XFS

XFS – это файловая система с журналированием метаданных. Она обладает конкретным набором возможностей и оптимизирована для масштабирования. Мы рекомендуем использовать эту файловую систему исключительно на Linux системах с высококлассными SCSI и/или Fibre Channel накопителями и источниками бесперебойного питания. Поскольку XFS агрессивно кэширует данные в ОЗУ, неподходяще спроектированная программа (т. е. та, которая не принимает должной предосторожности при записи на диск (таких совсем немного)) может потерять приличную порцию данных, если система неожиданно даст сбой.

Файловая система JFS

JFS является созданной в IBM высокопроизводительной журналируемой файловой системой. В последнее время она стала предустановленной, и мы бы хотели накопить больший опыт её использования, прежде чем выявлять сильные и слабые стороны этой файловой системы.

Рекомендации к файловым системам

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

Основываясь на нашем примере выше, мы будем использовать следующие команды чтобы инициализировать все наши разделы для использования:

Создание раздела подкачки

mkswap – команда для инициализации раздела подкачки:

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

Создание файловых систем ext2, ext3, ReiserFS

Для создание файловой системы ext2 можно использовать команду mke2fs :

Для создание файловой системы ReiserFS используется команда mkreiserfs :

Создание файловых систем XFS и JFS

Для создания файловой системы XFS используется команда mkfs.xfs :

Примечание:

Прим. ред: Информация в данном руководстве несколько устарела. На самом деле, ещё, по меньшей мере, более 6 лет назад, максимальный размер группы распредления (allocation group) в XFS увеличен до терабайта.

Для создания файловой системы JFS, используется команда mkfs.jfs :

Монтирование файловых систем

После того как файловая система создана, мы можем её примонтировать, используя команду mount :

Чтобы смонтировать файловую систему, в качестве первого аргумента необходимо указать раздел блочного устройства, и «точку монтирования» – в качестве второго. Новая файловая система будет «привита» в точке монтирования. Это также приводит к эффекту скрытия любых файлов которые находятся в директории /mnt в родительской файловой системе. Позже когда файловая система отмонтирована, эти файлы снова появятся. После выполнения команды монтирования, любые файлы созданные или скопированные внутри /mnt будут находится на новой файловой системе ReiserFS, которую вы смонтировали.

# mkdir /mnt/boot
# mount /dev/hda1 /mnt/boot

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

Еще немного о монтировании

Опции монтирования

Также возможно настраивать атрибуты для монтируемых ФС с помощью опций монтирования. К примеру, вы можете смонтировать файловую систему в режиме «только чтение» используя опцию “ro”:

С /dev/hdc6 смонтированной только для чтения, никакие файлы в /mnt не смогу быть изменены – только прочитаны. Если ваша ФС уже смонтирована для «чтения/записи» и вы хотите переключить её в режим «только чтение», вы можете использовать опцию remount избежав отключения и подключения ФС снова:

Знакомство с fstab

Итак, ядру Linux сообщается загрузчиком, какая используется корневая ФС, и мы рассмотрим загрузчики Linux позже в этом руководстве. Но для всего остального, ваша Linux система содержит файл, называемый /etc/fstab который сообщает ядру о доступных для монтирования файловых системах. Давайте взглянем на него.

Образец fstab

Давайте взглянем на образец файла /etc/fstab :

Также обратите внимание на опцию “noatime”, которая отключает запись atime (время последнего доступа) информации на диск. Эта информация в основном не требуется, и выключение всех обновлений atime даст положительный эффект на производительности системы.

Теперь взглянем на строку /proc и заметим опцию “defaults”. Используйте “defaults”, если вы хотите чтобы ФС была смонтирована со стандартными опциями. Т. к. /etc/fstab содержит множество полей, мы не можем просто оставить поле опций пустым.

Мы теперь можем ввести:

На самом деле, /etc/fstab позволяет нам получить приемущество от использования опции “user”. Эта опция монтирования сообщают системе, что данная конкретная ФС может монтироваться любым пользователем. Это очень удобно для съемных носителей, таких как CD-ROM. Без этой опции монтирования, только пользователь root смог бы использовать CD-ROM.

Размонтирование файловых систем

Как правило, все подключенные ФС размонтируются системой автоматически при выключении или перезагрузке. Когда ФС отмонтирована, то все закешированные в памяти данные ФС сброшены на диск.

Введение в fsck

Важно!

Иногда, мы можете обнаружить, что после перезагрузки fsck не может полностью восстановить частично поврежденную ФС. В таких случаях, всё, что вам нужно сделать, это перевести систему в однопользовательский режим и запустить fsck вручную, передав в качестве аргумента блочное устройство раздела. Поскольку fsck будет производить восстановление его ФС, то может спросить вас об исправлении конкретных дефектов ФС. В основном, вам стоит отвечать “y” (да) на все эти вопросы, разрешая fsck делать свое дело.

Проблемы с fsck

Одна из проблем со сканированием fsck состоит в том, что оно может занять длительное время до завершения, поскольку совокупность метаданных файловой системы (внутренняя структура данных) должна быть просканирована, чтобы убедиться в их целостности. Для особо больших ФС, не редко, для полного завершения fsck требуется более часа.

Для того, чтобы решить эту проблему, были спроектированы новые типы ФС, называемые журналируемые файловые системы. Журналируемые ФС пишут на диск журнал последних изменений метаданных файловой системы. В случае сбоя, драйвер ФС проверяет журнал. Так как журнал содержит точный отчет о последних изменениях на диске, то только эти части метаданных ФС требуют проверки на ошибки. Благодаря этому важному отличию, проверка журналируемой системы на целостность обычно занимает только считанные секунды, независимо от размера ФС. Поэтому журналируемые ФС завоёвывают популярность в сообществе Linux. Больше информации про журналируемые ФС смотрите на статье Funtoo Filesystem Guide, part 1: Journaling and ReiserFS.

За перевод этой части благодарим andrewww. Продолжение следует.

Об авторах

Daniel Robbins

Дэниэль Роббинс — основатель сообщества Gentoo и создатель операционной системы Gentoo Linux. Дэниэль проживает в Нью-Мехико со свой женой Мэри и двумя энергичными дочерьми. Он также основатель и глава Funtoo, написал множество технических статей для IBM developerWorks, Intel Developer Services и C/C++ Users Journal.

Chris Houser

Крис Хаусер был сторонником UNIX c 1994 года, когда присоединился к команде администраторов университета Тэйлора (Индиана, США), где получил степень бакалавра в компьютерных науках и математике. После он работал во множестве областей, включая веб-приложения, редактирование видео, драйвера для UNIX и криптографическую защиту. В настоящий момент работает в Sentry Data Systems. Крис также сделал вклад во множество свободных проектов, таких как Gentoo Linux и Clojure, стал соавтором книги The Joy of Clojure.

Aron Griffis

Эйрон Гриффис живет на территории Бостона, где провел последнее десятилетие работая в Hewlett-Packard над такими проектами, как сетевые UNIX-драйвера для Tru64, сертификация безопасности Linux, Xen и KVM виртуализация, и самое последнее — платформа HP ePrint. В свободное от программирования время Эйрон предпочитает размыщлять над проблемами программирования катаясь на своем велосипеде, жонглируя битами, или болея за бостонскую профессиональную бейсбольную команду «Красные Носки».

Источник