Використання команди `mkfs` в Linux: Повний посібник з форматування дисків і розділів

Команда `mkfs` (make filesystem) є основною утилітою Linux для запису структури файлової системи на блоковий пристрій — будь то необроблений диск, розділ або логічний том. Вона ініціалізує суперблок, таблиці inode, групи блоків і структури журналу, необхідні перед тим, як будь-які дані можуть бути записані на цей пристрій.

Перш ніж торкатися будь-якого диска, зрозумійте наступне: `mkfs` — це деструктивна, незворотна операція. Вона не просто стирає запис таблиці розділів — вона перезаписує критичні метадані на диску. Запуск команди на неправильному пристрої, навіть короткочасний, робить наявні дані невідновними без криміналістичних інструментів. Перевіряйте цільовий пристрій за допомогою `lsblk` або `blkid` перед кожним викликом.

Що насправді робить `mkfs` під капотом

Коли ви виконуєте `mkfs -t ext4 /dev/sdb1`, ядро не просто «форматує» розділ у розумінні Windows. Команда викликає відповідний бінарний файл для конкретної файлової системи (у цьому випадку `mkfs.ext4`, який насправді є `mke2fs` з налаштуваннями ext4 за замовчуванням) і виконує наступне:

• Записує суперблок і резервні копії суперблоку за фіксованими зміщеннями груп блоків
• Виділяє та ініціалізує таблицю inode у всіх групах блоків
• Створює таблицю дескрипторів груп блоків
• Ініціалізує журнал (для файлових систем із журналюванням, таких як ext4 та XFS)
• Записує inode кореневого каталогу (inode 2 для ext4)
• Присвоює UUID файловій системі для постійної ідентифікації

Ця відмінність важлива на великих дисках. Форматування розділу ext4 розміром 4 TB з повною ініціалізацією таблиці inode може зайняти кілька хвилин. XFS, навпаки, відкладає більшу частину цієї роботи до часу виконання, що робить `mkfs.xfs` майже миттєвим незалежно від розміру тому.

Визначення правильного пристрою перед форматуванням

Ніколи не вгадуйте назву пристрою. Використовуйте наступні інструменти для зіставлення фізичного обладнання з вузлами пристроїв ядра.

Використання `lsblk`

“`bash

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINT

“`

Приклад виводу:

“`

NAME SIZE FSTYPE LABEL UUID MOUNTPOINT

sda 100G

├─sda1 20G ext4 a1b2c3d4-… /

└─sda2 80G ext4 e5f6a7b8-… /home

sdb 500G

└─sdb1 500G

“`

Порожнє поле `FSTYPE` підтверджує, що `/dev/sdb1` не має існуючої файлової системи — його безпечно форматувати.

Використання `blkid`

“`bash

sudo blkid /dev/sdb1

“`

Якщо команда не повертає жодного виводу, розділ не містить розпізнаного підпису файлової системи. Якщо вона повертає тип, ви збираєтесь перезаписати наявні дані.

Використання `fdisk -l`

“`bash

sudo fdisk -l /dev/sdb

“`

Це розкриває межі розділів, типи розділів і те, чи використовує диск MBR або GPT. Якщо `/dev/sdb` не показує жодної таблиці розділів, вам може знадобитися спочатку розбити диск на розділи за допомогою `fdisk`, `gdisk` або `parted` перед запуском `mkfs`.

Основний синтаксис та шаблони виклику `mkfs`

Канонічний синтаксис:

“`bash

mkfs -t <filesystem_type> [options] <device>

“`

Однак `mkfs` сам по собі є тонкою обгорткою. Кожен тип файлової системи постачається зі своїм власним спеціалізованим бінарним файлом:

Виклик `mkfs -t ext4` і безпосередній виклик `mkfs.ext4` функціонально ідентичні — перший просто перенаправляється до другого. У виробничих скриптах надавайте перевагу явному псевдоніму (`mkfs.ext4`), щоб зробити намір однозначним.

Вибір типу файлової системи: технічне порівняння

Вибір неправильної файлової системи для робочого навантаження є поширеною та дорогою помилкою. Наступна таблиця зіставляє характеристики файлових систем з реальними випадками використання.

Критичний граничний випадок — EFI System Partition: ESP повинен бути відформатований як `vfat` (конкретно FAT32). Використання будь-якої іншої файлової системи тут не дозволить прошивці UEFI знайти завантажувач. Завжди форматуйте ESP за допомогою:

“`bash

sudo mkfs.vfat -F 32 /dev/sda1

“`

Прапорець `-F 32` явно примушує використовувати FAT32 замість FAT16, що важливо для ESP-розділів розміром більше 32 MiB.

Практичні приклади `mkfs` з параметрами виробничого рівня

Приклад 1: Створення файлової системи ext4 з налаштованими параметрами

“`bash

sudo mkfs.ext4 -L "data_vol" -m 1 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdb1

“`

Що робить кожен прапорець:

• `-L "data_vol"` — присвоює постійну мітку, дозволяючи записам `/etc/fstab` використовувати `LABEL=data_vol` замість шляху до необробленого пристрою (безпечніше на системах, де порядок перерахування пристроїв може змінюватися)
• `-m 1` — зменшує відсоток зарезервованих блоків з типових 5% до 1%; на томі даних розміром 2 TB типове значення витрачає ~100 GB, які може використовувати лише root
• `-E lazy_itable_init=0,lazy_journal_init=0` — примушує виконати повну ініціалізацію таблиці inode під час форматування, а не відкладати її у фоновий ввід-вивід; критично для виробничих серверів, де фонова ініціалізація може спричинити несподівані сплески ввід-виводу через години після розгортання

Приклад 2: Створення файлової системи XFS для сервера баз даних

“`bash

sudo mkfs.xfs -L "pg_data" -f /dev/sdb1

“`

• `-f` — примушує створення навіть якщо виявлено підпис існуючої файлової системи; використовуйте лише тоді, коли ви підтвердили, що пристрій можна витратити
• XFS не підтримує стиснення; ретельно плануйте розмір тому перед форматуванням

Для робочих навантажень PostgreSQL або MySQL на XFS також встановіть параметр монтування `noatime` у `/etc/fstab`, щоб усунути накладні витрати на запис часу доступу inode при кожній операції читання.

Приклад 3: Створення файлової системи Btrfs з RAID-1 на двох пристроях

“`bash

sudo mkfs.btrfs -L "btrfs_mirror" -d raid1 -m raid1 /dev/sdb /dev/sdc

“`

Btrfs може охоплювати кілька блокових пристроїв нативно. `-d raid1` дзеркалює дані; `-m raid1` дзеркалює метадані. Це є законною альтернативою програмному RAID mdadm для середовищ, де також потрібна функціональність знімків і підтомів.

Приклад 4: Створення файлової системи vFAT для USB-накопичувача

“`bash

sudo mkfs.vfat -F 32 -n "BACKUP_USB" /dev/sdc1

“`

• `-n "BACKUP_USB"` — встановлює мітку тому (мітки FAT32 обмежені 11 символами, у верхньому регістрі)
• `-F 32` — явно вибирає FAT32 замість FAT16

Приклад 5: Створення файлової системи F2FS на SSD

“`bash

sudo mkfs.f2fs -l "ssd_cache" /dev/sdb1

“`

F2FS спеціально розроблений для флеш-сховищ NAND. Він зменшує підсилення запису та керує вирівнюванням зносу на рівні файлової системи. На екземплярах VPS Хостингу, що використовують NVMe-сховище, F2FS може перевершити ext4 для ефемерних томів кешу з інтенсивним записом.

Форматування цілого диска без таблиці розділів

У певних сценаріях — фізичні томи LVM, Ceph OSD або спеціалізовані сховищні пристрої — ви можете записати файлову систему безпосередньо на весь диск, а не на розділ:

“`bash

sudo mkfs.ext4 /dev/sdb

“`

Коли це доречно:

• Диск призначений для єдиної мети і гнучкість розділів не потрібна
• Ви готуєте диск для LVM (`pvcreate` обробляє це по-іншому, але концепція схожа)
• Ви створюєте образ файлової системи на петлевому пристрої

Коли це недоречно:

• Будь-який диск, з якого потрібно завантажуватися (потребує таблиці розділів з прапорцем завантаження)
• Будь-який диск, що спільно використовується кількома файловими системами або операційними системами
• Диски на системах, де правила udev або інструменти хмарної інфраструктури очікують наявності таблиці розділів

Монтування відформатованого розділу та забезпечення його постійності

Форматування створює файлову систему; монтування робить її доступною. Завжди використовуйте посилання на основі UUID у `/etc/fstab` замість назв пристроїв, оскільки назви пристроїв (`/dev/sdb1`) не гарантовано стабільні між перезавантаженнями на системах з кількома дисками або гарячим підключенням сховища.

“`bash

Create the mount point

sudo mkdir -p /mnt/data_vol

Mount temporarily to verify

sudo mount /dev/sdb1 /mnt/data_vol

Retrieve the UUID

sudo blkid /dev/sdb1

Output: /dev/sdb1: LABEL="data_vol" UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"

Add a persistent, UUID-based fstab entry

echo 'UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /mnt/data_vol ext4 defaults,noatime 0 2' | sudo tee -a /etc/fstab

Validate the fstab entry without rebooting

sudo mount -a

“`

Значення `0 2` в кінці запису fstab керує `dump` (утиліта резервного копіювання, встановіть 0 для вимкнення) і порядком перевірки `fsck` (2 означає перевірку після кореневої файлової системи; root повинен мати значення 1).

Перевірка цілісності файлової системи після форматування

Не припускайте, що форматування пройшло успішно без перевірки.

“`bash

Check filesystem type, label, and UUID

lsblk -f /dev/sdb1

For ext4: run e2fsck in read-only check mode

sudo e2fsck -n /dev/sdb1

For XFS: verify the filesystem structure

sudo xfs_repair -n /dev/sdb1

Check available space after mounting

df -hT /mnt/data_vol

“`

Прапорець `-n` як для `e2fsck`, так і для `xfs_repair` виконує пробну перевірку без змін файлової системи. Це безпечно запускати на змонтованій файловій системі для діагностичних цілей, хоча повне відновлення вимагає попереднього демонтування.

Довідник розширених параметрів

Поширені помилки та способи їх уникнення

Форматування змонтованої файлової системи: Linux не завжди запобігає цьому. Запуск `mkfs` на змонтованому розділі негайно пошкоджує файлову систему і може спричинити паніку ядра. Завжди перевіряйте стан монтування за допомогою `mount | grep /dev/sdb1` перед продовженням.

Вичерпання inode на ext4: Якщо ви встановите великий розмір блоку (наприклад, 4096 байт) на томі, який зберігатиме мільйони крихітних файлів (поштові спули, кеші сесій), ви вичерпаєте inode задовго до вичерпання дискового простору. Використовуйте `-i 4096` або `-i 2048` для збільшення щільності inode. Це особливо поширена проблема на серверах Email Хостингу та веб-серверах з високим трафіком, що зберігають файли для кожної сесії.

XFS та стиснення: Томи XFS не можна стиснути після створення. Якщо ви відформатуєте том XFS розміром 2 TB і пізніше вам знадобиться звільнити місце, єдиним варіантом є резервне копіювання, переформатування та відновлення. Плануйте розміри томів XFS консервативно або використовуйте тонке виділення LVM знизу.

Вирівнювання смуг для RAID та SSD: Форматування без вказівки вирівнювання смуг на масиві RAID або SSD спричиняє невирівняний ввід-вивід, що значно погіршує продуктивність. Для масиву RAID-5 зі смугою 512 KB та 4 дисками:

“`bash

sudo mkfs.ext4 -E stride=128,stripe-width=384 /dev/md0

“`

Де `stride = stripe_size / block_size` та `stripe-width = stride * (data_disks)`.

Колізії UUID після клонування диска: Клонування диска за допомогою `dd` дублює UUID файлової системи. Два пристрої з однаковими UUID спричиняють збої монтування та пошкодження даних. Після клонування регенеруйте UUID:

“`bash

sudo tune2fs -U random /dev/sdb1 # ext4

sudo xfs_admin -U generate /dev/sdb1 # XFS

“`

Це є критичним міркуванням при розгортанні Виділених Серверів з образів дисків або підготовці кількох вузлів з єдиного шаблону.

Міркування щодо файлової системи для VPS та хмарних середовищ

На віртуальних машинах та хмарних екземплярах базове сховище часто є тонко виділеним віртуальним диском, підкріпленим розподіленою системою зберігання. Кілька рішень `mkfs` стають більш впливовими в цьому контексті:

• Підтримка Discard/TRIM: Форматуйте ext4 з `-E discard` або додайте параметр монтування `discard` для увімкнення онлайн TRIM, який повертає звільнені блоки до базового пулу сховища та підтримує продуктивність з часом на екземплярах VPS з cPanel, що використовують SSD-сховище.
• Режим журналу: Для застосунків, чутливих до затримок, розгляньте режим журналу `data=writeback` у `/etc/fstab` для ext4. Це обмінює суворе впорядкування даних на меншу затримку запису, що прийнятно для баз даних, які керують власними журналами попереднього запису.
• Уникайте форматування swap як файлової системи: Розділи swap використовують `mkswap`, а не `mkfs`. Запуск `mkfs` на розділі swap знищує підпис swap без створення придатної файлової системи.

При керуванні сховищем на Панелях керування VPS, додаткові дискові томи зазвичай з’являються як неформатовані блокові пристрої. Робочий процес завжди такий: ідентифікація за допомогою `lsblk`, розбиття на розділи за потреби за допомогою `fdisk`/`gdisk`, форматування за допомогою `mkfs`, монтування та збереження в `/etc/fstab`.

Матриця рішень: вибір правильної файлової системи

Використовуйте цю матрицю для вибору файлової системи на основі вашого основного обмеження:

Технічний контрольний список ключових висновків

Перед запуском `mkfs` у будь-якому середовищі пройдіть цей контрольний список:

• Підтвердіть цільовий пристрій за допомогою `lsblk -f` та `blkid` — ніколи не покладайтеся на пам’ять або припущення
• Демонтуйте ціль за допомогою `umount /dev/sdXN` та перевірте за допомогою `mount | grep sdX`
• Зробіть резервну копію будь-яких даних на пристрої; `mkfs` є незворотною операцією
• Виберіть тип файлової системи на основі робочого навантаження (дивіться матрицю рішень вище), а не звички
• Встановіть мітку файлової системи за допомогою `-L` для зрозумілої людині ідентифікації в журналах та `fstab`
• Зменшіть зарезервовані блоки на великих томах даних (`-m 1` для ext4) для відновлення придатного простору
• Вимкніть ліниву ініціалізацію (`-E lazy_itable_init=0`) на виробничих серверах для запобігання сплескам ввід-виводу після розгортання
• Використовуйте UUID у `/etc/fstab`, а не назви пристроїв, для постійності монтування
• Перевірте за допомогою `mount -a` після редагування `/etc/fstab` для виявлення помилок перед перезавантаженням
• Запустіть `e2fsck -n` або `xfs_repair -n` після форматування для підтвердження цілісності файлової системи
• Регенеруйте UUID на будь-якому диску, клонованому з шаблонного образу

FAQ

П: Чи можна запустити `mkfs` на розділі, який наразі змонтований?

В: Технічно ядро може це дозволити, але це негайно пошкоджує файлову систему і може спричинити паніку ядра або втрату даних. Завжди спочатку демонтуйте розділ і підтвердіть за допомогою `mount | grep <device>` перед запуском `mkfs`.

П: У чому різниця між `mkfs.ext4` та `mke2fs`?

В: `mkfs.ext4` є символічним посиланням або обгорткою, яка викликає `mke2fs` з налаштуваннями `-t ext4` за замовчуванням. Вони функціонально ідентичні. `mke2fs` є канонічним інструментом і приймає повний діапазон параметрів створення ext2/ext3/ext4.

П: Чому форматування великого розділу ext4 займає так багато часу порівняно з XFS?

В: ext4 ініціалізує таблицю inode для кожної групи блоків під час форматування (якщо не встановлено `lazy_itable_init=1`). На томі розміром 4 TB це передбачає запис гігабайтів обнулених даних таблиці inode. XFS відкладає ініціалізацію структури до часу виконання, що дозволяє `mkfs.xfs` завершуватися за секунди незалежно від розміру тому.

П: Як змінити мітку файлової системи після форматування без переформатування?

В: Для ext4 використовуйте `sudo tune2fs -L "NewLabel" /dev/sdb1`. Для XFS використовуйте `sudo xfs_admin -L "NewLabel" /dev/sdb1`. Для FAT32 використовуйте `sudo fatlabel /dev/sdb1 NEWLABEL`. Перемаркування не впливає на дані.

П: Чи безпечно використовувати `mkfs` на логічному томі LVM?

В: Так. Логічні томи LVM відображаються як блокові пристрої (наприклад, `/dev/mapper/vg0-lv_data` або `/dev/vg0/lv_data`) і обробляються `mkfs` ідентично фізичним розділам. Це стандартний робочий процес для виробничого сховища Linux: створіть LV за допомогою `lvcreate`, відформатуйте за допомогою `mkfs`, змонтуйте та збережіть у `/etc/fstab`.