Linux создаем файловую систему

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Создание и форматирование разделов жестких дисков в Linux

Работаем с дисками

Целью статьи является рассмотреть вопросы разбития жестких дисков и создание на разделах различных файловых систем в Linux. Будет рассмотрено управление дисками MBR и GPT.

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Использование утилиты mkfs.

Основные утилиты для работы с разделами жестких дисков и создания файловых систем: fdisk , gdisk , parted , gparted , mkfs , mkswap .

Для работы с жесткими дисками, такими операциями как изменение размеров логических разделов, разбиение жестких дисков, создание файловых таблиц на разделах жестких дисков требуются права суперпользователя. Переключится в данных режим из режима обычного пользователя можно командой sudo –s и введя пароль.

Утилита fdisk , позволяет нам проводить различные манипуляции с разделами жесткого диска.

Команда fdisk –l , мы можем посмотреть какие разделы у нас есть на жестком диске.

И так вводим команду fdisk –l и видим у на 3 физических жестких диска /dev/sda , /dev/sdb , /dev/sdc соответствующих размеров. Нас интересует раздел /dev/sdc/ на 10 GB с которым мы будем производить манипуляции.

Далее сделаем разбивку и создадим логические разделы.

Сразу получаем предупреждение, что раздел не содержит ни одного опознанного раздела.

Создадим новые разделы. Поделим на 2 части. У нас получится следующее.

Как мы можем увидеть создались 2 раздела и имеют ID 83, т.е. Linux раздел по умолчанию.

Теперь давайте поменяем тип раздела. Это сделать можно просто в меню выбираем t – смена раздела. Выбираем номер, например, 2 и нажимаем L , чтобы посмотреть hex коды, соответствующие разным типам. Изменим тип раздела Linux на swap раздел подкачки.

И теперь мы можем увидеть введя команду p .

У нас изменился тип раздела на раздел подкачки. Обычно данные раздел используется, когда не хватает оперативной памяти у машины. Теперь необходимо записать производимые изменения командой w. После ввода данной команды диски синхронизируются и таблица разделов изменена. После этого введя команду fdisk –l мы можем убедиться, что действительно появились разделы. Для того, чтобы этот раздел действительно стал работать, как раздел подкачки, его необходимо отформатировать, как раздел подкачки. Для этого есть команда специальная mkswap /dev/sdc2 . Указываем команду и раздел, который должен быть размечен. После команды mkswap раздел размечается и теперь его необходимо включить swapon /dev/sdc2 .

Для того, чтобы посмотреть какие разделы подкачки используются используем команду swapon –s .

Для выключения раздела подкачки можно использовать обратную команду swapoff /dev/sdc2 .

На самом деле, как мы убедились разделы подкачки создавать достаточно просто. Если не хватает оперативки, то пере разбили, отформатировали и включили.

Теперь поработает с первым разделом. Будем использовать команду mkfs .

В описании утилиты сказано, что данная утилита, строит Linux файловую систему. У данной утилиты, очень большое количество ключей. Использую данную утилиты мы можем отформатировать логический раздел в старую файловую систему ext2, с помощью команды mkfs –t ext2 /dev/sdc1 . А затем переформатировать в более новую ext3. Файловые системы различаются тем, что более новая файловая система журналируемая. Т.е. ведется журнал изменений происходящего на данной файловой системе и в случае чего-нибудь мы можем восстановить или откатить изменения. Еще более новая файловая система ext4. Отличия данной файловой системы от предыдущей в том, что она может работать с большими размерами жестких дисков, может в себе хранить большие размеры файлов, намного меньше фрагментация. В случае если мы хотим использовать, какие-то более экзотические файловые системы, то нам необходимо скачать соответствующую утилиту. Например, если мы хотим использовать файловую систему xfs.

Если мы попробуем отформатировать mkfs –t xfs /dev/sdc1 то мы получим ошибку. Попробуем поискать в кэше необходимый пакет apt-cache search xfs .

Находим необходимый пакет. Как мы можем видеть это утилита для управления XFS файловой системой. Следовательно, необходимо установить данный пакет, и мы сможем отформатировать в xfs файловую систему. Устанавливаем apt-get install xfsprogs . После установки пробуем отформатировать в xfs. Учитывая то, что мы уже форматировали в файловую систему ext4, нам необходимо команду на форматирование запускать с ключом –f . Получаем в следующем виде:

Теперь думаю интересно будет посмотреть, как сделать данный раздел рабочим под Windows операционную систему.

Возвращаемся обратно в редактирование логических разделов fdisk /dev/sdc и говорим , что мы ходим поменять тип первого нашего раздела с помощью команды t . Далее выбираем метку, которую понимает операционная система Windows, это FAT/FAT16/FAT32/NTFS. Например, NTFS id 86. Изменили. В этом можно убедится выведя таблицу с помощью команды p .

После изменения типа логического раздела, не забываем записать изменения с помощью команды w . Далее необходимо логический раздел отформатировать mkfs -t ntfs /dev/sdc1 .

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

Если посмотреть мануал по fdisk , то мы увидим, что он не умеет работать с дисками GPT и не может работать с большими разделами, только с MBR. Как известно в современных ПК уже используется UEFI, которая работает с GPT. А как следствие мы можем сделать вывод, что fdisk не сможет работать с дисками размер которых более 2 ТБ. Для работы с большими дисками можно использовать другую программу gdisk .

Как можно прочитать в описании gdisk – это интерактивный манипулятор для работы с gpt . Он работает практически также как и fdisk , только для начала необходимо переразбить жесткий диск из MBR в GPT.

Нажав на знак вопроса получим небольшую подсказку.

И нажимаем команду o для создания нового пустого GPT.

Получаем вот такое предупреждение.

Которое говорит о том, что будет создан новый GPT и создаст маленький новый защищенный MBR для совместимости со старыми системами, иначе старые системы будут затирать GPT.

С помощью команды p можно посмотреть список логических разделов, а с помощью команды w записать изменения. Разделы в данной программе создаются аналогично fdisk .

Посмотрим еще одну утилиту parted .

Интересная программа имеющая больший функционал, чем fdisk и gdisk . Умеет работать с дисками более 2 ТБ, умеет изменять разделы на горячую, может создавать разделы сразу с файловой системой, искать и восстанавливать разделы на жестком диске.

Команда parted –l покажет информацию по подключенным жестким дискам, типам разделов и логическим разделам.

Заходим в редактирование жесткого диска parted /dev/sdc и набираем слово help . Получаем достаточно справку с опциями.

У данной утилиты есть графический интерфейс, если вы работаете с GUI. Можно установить через apt-get install gparted .

Онлайн курс по Linux

Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps

Источник

⌨ Как создать новую файловую систему Ext4 (раздел) в Linux

Ext4 – широко используемая файловая система журналирования для Linux.

Она был разработана как прогрессивная версия файловой системы ext3 и преодолевает ряд ограничений в ext3.

Она имеет значительные преимущества перед предшественником, такие как улучшенный дизайн, лучшая производительность, надежность и новые функции.

Хотя она лучше всего подходит для жестких дисков, его также можно использовать на съемных устройствах.

Эта статья покажет вам, как создать новую файловую систему ext4 (раздел) в Linux.

Сначала мы рассмотрим, как создать новый раздел в Linux, отформатировать его в файловой системе ext4 и смонтировать.

Примечание. Для целей данной статьи:

• Предположим, что вы добавили новый жесткий диск на свой компьютер Linux, на котором вы создадите новый раздел ext4, и
• Если вы работаете с системой как пользователь с правами администратора, используйте команду sudo для получения привилегий root для запуска команд, показанных в этой статье.

Создание нового раздела в Linux

Перечислите разделы с помощью команд fdisk -l или parted -l, чтобы определить жесткий диск, который вы хотите разбить на разделы.

Посмотрите на вывод на скриншоте выше, у нас есть два жестких диска, добавленных в тестовую систему, и мы разделим диск /dev/sdb.

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

Теперь присвойте новому диску метку с помощью команды mklabel.

Затем создайте раздел с помощью команды mkpart, присвойте ему дополнительные параметры, такие как «основной» или «логический», в зависимости от типа раздела, который вы хотите создать.

Затем выберите ext4 в качестве типа файловой системы, установите начало и конец, чтобы установить размер раздела:

Чтобы вывести таблицу разделов на устройстве /dev/sdb или подробную информацию о новом разделе, выполните команду print

Теперь выйдите из программы, используя команду quit.

Форматирование нового раздела Ext4

Далее необходимо правильно отформатировать новый раздел с типом файловой системы ext4 с помощью команды mkfs.ext4 или mke4fs, как показано ниже.

Затем пометьте раздел с помощью команды e4label следующим образом.

Монтирование нового раздела Ext4 в файловой системе

Затем создайте точку монтирования и смонтируйте только что созданную файловую систему раздела ext4.

Теперь с помощью команды df вы можете перечислить все файловые системы в вашей системе вместе с их размерами в удобочитаемом формате (-h), а также их точки монтирования и типы файловых систем (-T):

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

Вы также можете прочитать следующие статьи по теме:

Источник

Пишем файловую систему в ядре Linux

Для кого эта статья

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

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

Введение

Файловая система является одной из центральных подсистем ОС. Развитие файловых систем шло вместе с развитием ОС. На настоящий момент мы имеем целый зоопарк самых разнообразных файловых систем от старой «классической» UFS , до новых интересных NILFS (хотя идея совсем не новая, посмотрите на LFS ) и BTRFS . Так что, можно сказать, теория и практика создания файловых систем вполне проработаны. Мы не будем пытаться свергнуть монстров вроде ext3/4 и BTRFS, наша файловая система будет носить исключительно образовательный характер, на ее примере мы будем знакомиться с ядром Linux.

Настройка окружения

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

sudo apt-get install gcc build-essential

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

sudo apt-get install linux-headers-`uname -r`

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

Проверяем окружение

Чтобы проверить окружение напишем и запустим модуль ядра, который не будет делать ничего полезного (Hello, World!). Посмотрим на код модуля, я его назвал super.c (не подумайте ничего, super это от superblock):

В самом начале идут два заголовка, считайте, что они обязательная часть любого загружаемого модуля ядра, ничего интересного в них нет. Далее идут две функции aufs_init и aufs_fini — они будут вызваны после загрузки и перед выгрузкой модуля соответственно.

Некоторых из вас может смутить метка __init. __init это подсказка ядру, что функция используется только во время инициализации модуля, а значит, после инициализации модуля эту функцию можно выгрузить из памяти. Аналогичный маркер есть и для данных, впрочем, ядро вполне может игнорировать эти подсказки. Обращение к __init функциям и данным из основного кода модуля это потенциальная ошибка, поэтому во время сборки модуля проверяется, что таких обращений нет. Если же такое обращение найдено, система сборки ядра выдаст предупреждение. Аналогично проверка делается для __exit функций и данных. Если вам интересны детали того, что из себя представляют __init и __exit, то можете обратиться к исходникам .

Обратите внимание, что aufs_init возвращает int. Таким образом ядро узнает, что во время инициализации модуля что-то пошло не так — если модуль вернул не нулевое значение, значит во время инициализация произошла ошибка.

Чтобы указать какие именно функции нужно вызвать при загрузке и выгрузке модуля используются два макроса module_init и module_exit. Они раскрываются в некоторое количество компиляторной магии, но мы не будем углубляться в детали, интересующиеся могут обратиться к lxr и походить по ссылкам (надо сказать, для освоения ядра очень удобная штука).

pr_debug — это функция (на самом деле это макрос, но пока нам это не важно) вывода в лог ядра, очень похожа семейство функций printf с некоторыми расширениями, например, для печати IP и MAC адресов. Полный список модификаторов можно найти в документации к ядру. Вместе с pr_debug, есть целое семейство макросов: pr_info, pr_warn, pr_err и другие. Те кто немного знаком с разработкой модулей Linux наверняка знают про функцию printk, в принципе, макросы pr_* раскрываются в вызовы printk, так что вместо них можно использовать напрямую printk.

Далее идут макросы с информацией для потомков — лицензия и автор. Есть и другие макросы позволяющие сохранить самую разнообразную информацию о модуле, например, MODULE_VERSION, MODULE_INFO, MODULE_SUPPORTED_DEVICE и другие. Кстати, забавный факт, если вы используете лицензию отличную от GPL, то некоторые функции доступные GPL модулям вы использовать не сможете.

Теперь соберем и загрузим наш модуль. Для этого напишем Makefile, который будет собирать наш модуль:

По факту, этот Makefile для сборки вызывает Makefile ядра, который должен находиться в каталоге /lib/modules/$(shell uname -r)/build (uname -r — команда, которая возвращает версию запущенного ядра), если у вас заголовки (или исходники) ядра находятся в другом каталоге, то нужно поправить.

obj-m — позволяет указать имя будущего модуля, в нашем случае модуль будет называться aufs.ko (именно ko — от kernel object). А aufs-objs позволяет указать из каких исходных файлов собирать модуль aufs, в нашем случае будет использоваться всего один файл super.c. Кроме того, можно указать различные флаги компилятора, которые будут использоваться (в дополнение к тем, которые использует Makefile ядра) при сборке объектных файлов, в нашем случае я передаю флаг -DDEBUG при сборке super.c. Если не передавать флаг -DDEBUG, то мы не увидим вывод pr_debug в системном логе.

Чтобы собрать модуль нужно выполнить команду make. Если все хорошо, то в каталоге должен будет появится файл aufs.ko — это наш загружаемый модуль. Загрузить модуль довольно просто:

sudo insmod ./aufs.ko

Чтобы убедиться, что модуль загрузился можно посмотреть на вывод команды lsmod:

lsmod | grep aufs

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

sudo rmmod aufs

Возвращаемся к файловой системе

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

Жизнь файловой системы начинается с регистрации. Зарегистрировать файловую систему можно с помощью вызова register_filesystem . Мы будем регистрировать файловую систему в функции инициализации модуля. Чтобы разрегистрировать файловую систему есть функция unregister_filesystem , и вызывать мы ее будем в функции aufs_fini нашего модуля.

Обе функции принимают как параметр указатель на структуру file_system_type — она будет «описывать» файловую систему, считайте, что это класс файловой системы. Полей в этой структуре хватает, но нас интересуют лишь некоторые из них:

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

mount и kill_sb — два поля хранящие указатели на функции. Первая функция будет вызвана при монтировании файловой системы, а вторая при размонтировании. Нам достаточно реализовать всего одну, а вместо второй будем использовать kill_block_super, которую любезно предоставляет ядро.

Поле fs_flags — хранит различные флаги, в нашем случае оно хранит флаг FS_REQUIRES_DEV, который говорит, что нашей файловой системе для работы нужен диск (хотя пока это не так). Можно этот флаг не указывать, все будет прекрасно работать и без него.

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

Теперь рассмотрим функцию aufs_mount. Она должна примонтировать устройство и вернуть структуру описывающую корневой каталог файловой системы. Звучит довольно сложно, но, к счастью, и тут ядро почти все сделает за нас:

По факту, большая часть работы происходит внутри функции moun_bdev, нас интересует лишь ее параметр aufs_fill_sb — это указатель на функцию (опять), которая будет вызвана из mount_bdev чтобы инициализировать суперблок. Но перед тем как мы перейдем к ней остановимся на важной для файловой подсистемы ядра структуре dentry . Эта структура представляет участок пути в имени файла, например, если мы обращаемся к файлу /usr/bin/vim, то у нас будут экземпляры структуры dirent представляющие участки пути / (корневой каталог), bin/ и vim. Ядро поддерживает кеш этих структур, что позволяет быстро искать inode (еще одна центровая структура) по имени (пути) файла. Так вот, функция aufs_mount должна вернуть dentry представляющую корневой каталог нашей файловой системы, а создаст его функция aufs_fill_sb.

Итак, aufs_fill_sb пока что самая важная функция в нашем модуле, и выглядит она так:

В первую очередь мы заполняем структуру super_block . Что это за структура такая? Обычно, файловые системы хранят в специальном месте раздела диска (это место выбирает файловая система) набор параметров файловой системы, таких как размер блока, количество свободных/занятых блоков, версию файловой системы, «указатель» на корневой каталог, магическое число, по которому драйвер файловой системы может проверить, что на диске хранится именно та самая файловая система, а не что-то еще, ну и прочие данные. Эта структура называется суперблоком (см. картинку ниже). Структура super_block в ядре Linux, в целом, предназначен для схожих целей, мы сохраняем в нем магическое число и dentry для корневого каталога (ту самую, которую возвращает mount_bdev).

Кроме того, в поле s_op структуры super_block мы сохраняем указатель на структуру super_operations — это «методы класса» super_block, т. е. еще одна структура, которая хранит кучу указателей на функции.

Тут я сделаю еще одно отступление, ядро Linux написано на C, т. е. без поддержки различных ООП фич со стороны языка, но структурировать программу следуя идеям ООП можно и без поддержки со стороны языка, поэтому структуры содержащие кучу указателей на функции довольно часто встречаются в ядре — это такой способ реализации полиморфизма подтипов (aka виртуальных функций) имеющимися средствами.

Но вернемся к структуре super_block и ее «методам», мы не будем сейчас углубляться в детали структуры super_operations, нас будет интересовать только одно ее поле — put_super. В put_super мы сохраним «деструктор» нашего суперблока:

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

Теперь вернемся к нашей самой важной функции aufs_fill_sb. Перед созданием dentry для корневого каталога мы должны создать inode корневого каталога. Структура inode является, пожалуй, самой важной в файловой подсистеме, каждый объект файловой системы (файл, папка, специальный файл, журнал и пр) идентифицируется inode. Как и с super_block, структура inode отражает то, как файловые системы хранятся на диске. Название inode происходит от index node, т. е. он индексирует файлы и папки на диске. Обычно внутри inode на диске хранится указание на то, где хранятся данные файла на диске (в каких блоках сохранено содержимое файла), различные флаги доступа (доступен для чтения/записи/исполнения), информация о владельце файла, время создания/модификации/доступа и прочие подобные вещи (см. картинку выше).

Пока мы не умеем читать с диска, так что заполняем inode фиктивными данными. В качестве времени создания/модификации/доступа используем текущее время, а назначение владельца и прав доступа делегируем ядру (вызываем функцию inode_init_owner). Ну наконец создаем dentry связанную с корневым inode.

Проверяем каркас

Каркас нашей файловой системы готов, пора его проверить. Сборка и загрузка драйвера файловой системы ничем не отличается от сборки и загрузки обычного модуля. Вместо реального диска для экспериментов мы будем использовать loop устройство. Это такой драйвер «диска», который пишет данные не на физическое устройство, а в файл (образ диска). Создадим образ диска, пока он не хранит никаких данных, поэтому все просто:

Кроме того, нам нужно создать каталог, который будет точкой монтирования (корнем) нашей файловой системы:

Теперь используя этот образ примонтируем нашу файловую систему:

sudo mount -o loop -t aufs ./image ./dir

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

sudo umount ./dir

И опять проверяем системный лог.

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

Далее мы планируем рассмотреть чтение данных с диска, для начала мы определим, как мы будем хранить данные на дисках, и научимся читать суперблок и иноды с диска.

Список литературы и ссылки

1. Код к статье лежит на github
2. Не так давно, один индиец уже писал простую файловую систему с нуля в образовательных целях, он проделал очень большую работу
3. Я понимаю, что отправлять новичков к исходникам ядра не очень педагогично (хотя исходники читать полезно), но тем не менее советую всем интересующимся посмотреть на исходники очень простой файловой системы ramfs . Кроме того, в отличие от нашей файловой системы ramfs не использует диск, а хранит все в памяти.

Источник