Перевірка файлової системи в Debian 13 триває вічно: що вважати нормою, червоні прапорці та виправлення (випадок №31)

Що вважати нормою, а що — тривожним сигналом

Спочатку: зрозумійте, який саме «перевірки» ви спостерігаєте

Кажуть «fsck», ніби це одна річ. Насправді — ні. У Debian 13 ви можете бачити:

• Відтворення журналу (досить швидко): ext4 відтворює журнал після незачиненого вимкнення. Це не повне сканування; по суті застосовуються останні транзакційні записи. Часто — секунди або кілька хвилин.
• Повна перевірка файлової системи (повільно): сканує метадані і інколи дерева каталогів та іноди. Саме вона може тривати годинами на багатотерабайтних томах.
• Відбудова пристрою/RAID (не fsck): mdadm resync або відновлення контролера, що робить кожен читання повільним, тому fsck здається «застиглим».
• Відновлення помилок на шарі зберігання (страшний варіант): диск/SSD повторює читання, ядро логує I/O помилки, і fsck чекає відповіді блочного пристрою.

Який час «нормальний»?

Норма залежить від того, скільки метаданих у файловій системі, а не лише від сирого розміру диска, і від вашого IO-профілю (HDD vs SATA SSD vs NVMe, локально чи мережево, та чи не в поганому настрої контролер). Тим не менш, деякі практичні евристики:

• Відтворення журналу: зазвичай менше хвилини на SSD/NVMe, кілька хвилин на HDD; довше, якщо зберігання навантажене або деградоване.
• Повний ext4 fsck: може займати 10–30 хвилин на терабайт для обертових дисків за нормальних умов. На SSD/NVMe може бути значно швидше, але не тримайте надії під час виклику на нічне чергування.
• Велика кількість інодів: мільйони дрібних файлів — класичний податок для fsck. Том 500 ГБ з 200 мільйонами інодів може займати довше, ніж 4 ТБ з переважно великими файлами.

Як виглядає «вічно»: тривожні сигнали, які треба вважати інцидентами

Це ті моменти, коли треба перестати чекати і почати діагностику:

• Відсутність дискової активності протягом хвилин, поки fsck стверджує, що виконується, і системний журнал показує повторювані I/O помилки або таймаути.
• Прогрес зупиняється на певному проході (для ext4: Pass 1, 2, 3, 4, 5) надовго на невеликій файловій системі. Велика файлова система може законно повільно працювати, але «застрягла» на кореневому диску 50 ГБ — підозріло.
• Повідомлення ядра про ресети, link down/up або NCQ помилки. Це не складність файлової системи; це пристрій, який просить виходу на пенсію.
• fsck виводить «UNEXPECTED INCONSISTENCY» або запитує підтвердження під час завантаження. Ви опинилися в інтерактивному ремонті в завантажувальному шляху — пастка для безлюдних систем.
• Перезавантаження повторюють перевірку при кожному старті, навіть після того, як вона «закінчується». Це може означати, що файлова система ніколи не монтується як чиста, або базовий блочний пристрій бреше.

Швидка ментальна модель: якщо fsck повільний, але диск стабільно працює, то, ймовірно, у вас проблема масштабу, але не обов’язково небезпечна. Якщо fsck повільний і диск зовсім не працює, або ядро лунає попередженнями — ймовірно, це серйозна проблема (апаратна або корупція).

Цікаві факти та контекст (чому fsck так поводиться)

• Факт 1: Класична файловa система ext2 вимагала регулярних повних перевірок, бо не мала журналу; journaling у ext3/ext4 зменшив потребу у частих повних скануваннях.
• Факт 2: ext4 використовує контрольні суми метаданих і покращення журналювання, що дозволяє легше виявляти деяку корупцію, але виявлення не робить ремонт автоматично швидким.
• Факт 3: «Чисте» відмонтування позначається бітом у суперблоці. Якщо система втрачає живлення, цей біт не скидається, і наступний монтування може ініціювати перевірку — навіть якщо дані користувача в порядку.
• Факт 4: tune2fs може планувати перевірки за кількістю монтажів або за інтервалом часу; багато серверних систем роками не проходять повну перевірку, бо значення за замовчуванням консервативні.
• Факт 5: Каталог lost+found існує, бо fsck може «врятувати» сироти файлів, приєднавши їх до чогось. Це версія файлової системи для шухляди з непотрібними речами.
• Факт 6: «Лінива ініціалізація таблиці інодів» у ext4 робить створення нових файлових систем швидким, але це також означає, що фонове ініціалізування може конкурувати за IO на ранніх етапах життя файлової системи.
• Факт 7: SSD можуть сповільнюватись без драматичного «зламу»: прошивка може займати час на внутрішню збірку сміття або корекцію помилок, що проявляється як спайки латентності і затримки fsck.
• Факт 8: На великих RAID-масивах відбудова може зменшити ефективну пропускну здатність на читання. Тоді fsck стає «вісником», якого звинувачують у всьому.

Одна інженерна цитата, що пережила досить постмортемів, щоб заслужити стілець за столом: «Сподівання — не стратегія». Цей вислів широко використовують в ops-культурі; сприймайте його як перефразовану ідею з літератури про надійність, а не як догму.

Жарт №1: Спостерігати за прогресом fsck — як дивитися, як сохне фарба, але фарба іноді просить вибрати між двома поганими варіантами.

Швидкий план діагностики (знайти вузьке місце швидко)

Ваша мета: визначити, у якій корзині ви перебуваєте, за 5–10 хвилин.

По-перше: чи справді виконується перевірка файлової системи, і на якому пристрої?

• Перегляньте повідомлення консолі під час завантаження і статус юніта systemd, якщо маєте доступ.
• Визначте блочний пристрій, що підкріплює файлову систему (/dev/nvme0n1p2, /dev/md0, LVM LV тощо).

По-друге: чи здоровий зараз стек зберігання?

• Пошукайте I/O помилки ядра, ресети лінків, таймаути контролера.
• Перевірте здоров’я SMART і поточні лічильники помилок.
• Якщо є RAID, перевірте статус ресинхронізації/відновлення.

По-третє: чи fsck просувається вперед або блокується на IO?

• Заміряйте завантаженість пристрою і латентність (навіть грубі числа допоможуть).
• Слідкуйте за стабільними читаннями; «застряглий» вивід може все ще означати активне сканування.
• Вирішіть, чи дозволити йому працювати, перезавантажитися в rescue, або зупинити і зробити образ диска.

Дерево рішень, яким варто користуватися

• Якщо в логах ядра видно I/O помилки/таймаути: розглядайте як потенційний вихід з ладу диска. Пріоритезуйте безпеку даних: зробіть образ/бекап, замініть апарат, потім ремонтуйте файлову систему.
• Якщо йде відновлення RAID/resync: очікуйте повільності; розгляньте можливість тимчасово призупинити resync (обережно) або запланувати fsck після стабілізації.
• Якщо помилок немає і IO активний: найімовірніше це легітимне довге сканування. Дайте йому завершитися, але плануйте майбутні пом’якшувальні заходи (налаштування, розбиття файлових систем, швидше зберігання).
• Якщо під час завантаження з’являються інтерактивні питання: припиніть таке. Завантажуйтеся в rescue і виконуйте контрольований ремонт з логами.

Практичні завдання: команди, вивід і рішення (12+)

Ці завдання написані для Debian 13 із systemd. Підлаштуйте імена пристроїв під свою реальність. Кожне завдання містить: команду, що означає її вивід, і яке рішення прийняти.

Завдання 1: Визначте, на що чекає systemd (fsck під час завантаження)

cr0x@server:~$ systemctl list-jobs
JOB UNIT                       TYPE  STATE  
123 systemd-fsck@dev-disk-by\x2duuid-... service running
124 dev-mapper-vg0-root.device  start waiting

2 jobs listed.

Значення: Юніт systemd для fsck активно працює для пристрою, вказаного UUID.

Рішення: Визначте, якому блочному пристрою відповідає цей UUID, і перевірте I/O помилки перед тим, як вважати, що це «просто повільно».

Завдання 2: Відобразіть UUID файлової системи на пристрій

cr0x@server:~$ ls -l /dev/disk/by-uuid | head
total 0
lrwxrwxrwx 1 root root 10 Dec 30 02:11 1a2b3c4d-... -> ../../sda1
lrwxrwxrwx 1 root root 15 Dec 30 02:11 7f8e9d0c-... -> ../../dm-0
lrwxrwxrwx 1 root root 10 Dec 30 02:11 9abc0123-... -> ../../sda2

Значення: UUID відповідає розділу (sda1) або вузлу device-mapper (dm-0 для LVM/crypt).

Рішення: Якщо це dm-*, також ідентифікуйте вихідні PV(и). Повільний fsck на dm-0 може означати, що під LVM є відмовний диск.

Завдання 3: Перевірте останні повідомлення ядра на предмет I/O болю

cr0x@server:~$ dmesg -T | tail -n 25
[Mon Dec 30 02:12:11 2025] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Mon Dec 30 02:12:11 2025] ata1.00: failed command: READ FPDMA QUEUED
[Mon Dec 30 02:12:11 2025] blk_update_request: I/O error, dev sda, sector 12345678 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[Mon Dec 30 02:12:12 2025] EXT4-fs (sda2): I/O error while writing superblock

Значення: Це не «повільний fsck». Це помилки читання і зависання лінка. ext4 також не зміг коректно записати суперблок.

Рішення: Припиніть вважати це проблемою лише файлової системи. Підготуйтеся замінити диск; пріоритет — блочний знімок або резервна копія перед повторними ремонтними записами.

Завдання 4: Перевірте, які файлові системи налаштовані на автоматичні перевірки

cr0x@server:~$ cat /etc/fstab
UUID=7f8e9d0c-... /     ext4  defaults,errors=remount-ro  0  1
UUID=1a2b3c4d-... /boot ext4  defaults                  0  2
UUID=9abc0123-... /data ext4  defaults                  0  2

Значення: Останній стовпець — порядок проходів fsck. Root — 1 (перший), інші — 2 (після root), 0 вимикає fsck.

Рішення: Якщо бачите великий том даних з pass 2 і він викликає довгі затримки при завантаженні, розгляньте встановлення 0 і запуск fsck у вікні техобслуговування. Не робіть цього, щоб приховати корупцію; робіть це, щоб контролювати масштаб впливу.

Завдання 5: Подивіться розклад перевірок ext4 і час останньої перевірки

cr0x@server:~$ sudo tune2fs -l /dev/sda2 | egrep -i 'Filesystem state|Mount count|Maximum mount count|Last checked|Check interval'
Filesystem state:         not clean
Mount count:              41
Maximum mount count:      42
Last checked:             Sun Dec  1 03:10:22 2025
Check interval:           15552000 (6 months)

Значення: Ви досягли порогу за кількістю монтажів, або файлова система позначена як «not clean», тому тригериться повна перевірка.

Рішення: Якщо це плановий тригер обслуговування — дайте йому працювати. Якщо це несподівано, з’ясуйте, чому файлова система постійно стає «not clean» (втрати живлення, kernel panic, таймаути зберігання).

Завдання 6: Отримайте реальний вигляд, що робить fsck (перегляд процесу)

cr0x@server:~$ ps -eo pid,etime,stat,cmd | grep -E 'fsck|e2fsck' | grep -v grep
  622 01:17:43 D    /sbin/e2fsck -p -C 0 /dev/sda2

Значення: Стан D часто вказує на невідвісний сон (uninterruptible sleep), зазвичай очікування IO. Це сигарний стержень у поєднанні з помилками диска або високою латентністю.

Рішення: Якщо процес у D і в вас є I/O помилки — зупиніться і проводьте діагностику диска. Якщо він у R або S зі стабільним IO — ймовірно в порядку.

Завдання 7: Заміряйте латентність і завантаження пристрою (швидко і грубо)

cr0x@server:~$ iostat -x 1 5
Linux 6.12.0 (server)  12/30/2025  _x86_64_ (8 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          1.20  0.00    2.40   72.00    0.00   24.40

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await aqu-sz  %util
sda             90.0  14400.0     0.0   0.00  850.00   160.00      2.0     64.0  120.00  40.00  99.00

Значення: r_await 850ms і %util ≈ 99% означають, що диск насичений і повільний. iowait дуже велике. Ось чому fsck тягнеться як мед.

Рішення: Якщо це один HDD на великій файловій системі — це може бути «нормально» але болісно. Якщо це SSD/NVMe — це тривожний знак: проблеми з прошивкою, зношування медіа або деградований RAID.

Завдання 8: Перевірка SMART і лічильників помилок

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'SMART overall|Reallocated|Pending|Offline|Error|Power_On_Hours'
SMART overall-health self-assessment test result: FAILED!
Reallocated_Sector_Ct   0x0033   001   001   005    Pre-fail  Always       -       8123
Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       97
Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       97
ATA Error Count: 203

Значення: Pending/offline-uncorrectable сектори означають, що диск не може надійно прочитати деякі дані. fsck буде вимагати багато доступів до тих областей і може застрягти.

Рішення: Замініть диск. Перед агресивними варіантами ремонту зробіть образ або резервну копію того, що можете. Кожен ремонт — це додаткові записи на деградованому диску.

Завдання 9: Перевірте стан mdadm RAID (якщо застосовано)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976630336 blocks super 1.2 [2/1] [U_]
      [========>............]  recovery = 41.2% (402123456/976630336) finish=210.3min speed=45512K/sec

Значення: Масив деградований ([U_]) і відновлюється. Читання можуть бути повільні; конкуренція за IO робить fsck повільним.

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

Завдання 10: Якщо використовуєте LVM, підтвердіть, який PV повільний

cr0x@server:~$ sudo lvs -a -o +devices
  LV   VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  root vg0 -wi-ao---- 120.00g                                                     /dev/sda2(0)
  data vg0 -wi-ao----   3.50t                                                     /dev/sdb1(0)

Значення: Ви можете зіставити повільну файлову систему з фізичним диском. Якщо / на sda2, зосередьте перевірку SMART і кабелі на ньому.

Рішення: Не гадати. Якщо том охоплює кілька PV, знайдіть слабку ланку, а не запускайте fsck двічі в надії на краще.

Завдання 11: Запустіть контрольовану перевірку з rescue (спочатку тільки читання)

cr0x@server:~$ sudo e2fsck -f -n -v /dev/sda2
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Inode 774533 has illegal block(s).  Clear? no
Pass 2: Checking directory structure
Entry 'tmp123' in /var/tmp (12345) has deleted/unused inode 778899.  Clear? no
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 164233/7864320 files, 19200322/31457280 blocks

Значення: -n означає «без змін», тому це безпечно для оцінки. Воно все одно повідомляє, що б було виправлено й чи потрібні модифікації.

Рішення: Якщо повідомляє «WAS MODIFIED» навіть з -n, значить потрібні зміни. Плануйте простій і запускайте без -n (або використайте -p для preen) лише після підтвердження, що диск достатньо здоровий, щоб витримати записи.

Завдання 12: Запустіть ремонт з логуванням (і прийміть відповідальність за результат)

cr0x@server:~$ sudo e2fsck -f -y -v /dev/sda2 | tee /root/e2fsck-root.log
Pass 1: Checking inodes, blocks, and sizes
Inode 774533 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
...
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 164233/7864320 files, 19200320/31457280 blocks

Значення: -y відповідає «так» на запити. Це грубий інструмент ремонту. Корисно для безлюдного відновлення, але небезпечно, якщо проблема — апаратна.

Рішення: Використовуйте -y, коли вирішили, що відновлення монтування важливіше за збереження всіх імен файлів. Для критичних систем розгляньте шлях бекапу/відновлення замість агресивного ремонту.

Завдання 13: Перевірте фічі ext4, що впливають на поведінку перевірки

cr0x@server:~$ sudo dumpe2fs -h /dev/sda2 | egrep -i 'Filesystem features|Checksum|metadata_csum|64bit'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit metadata_csum

Значення: Сучасні можливості ext4, як-от metadata_csum і 64bit, нормальні для великих файлових систем. Вони можуть змінювати спосіб перевірки і вигляд помилок.

Рішення: Якщо ви переносите диски між старими інструментами, переконайтесь, що ваше rescue-середовище має сучасний e2fsck. Давні інструменти плюс сучасні фічі = поганий день.

Завдання 14: Підтвердіть монтування і уникайте запуску fsck на змонтованій файловій системі

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE / /data
/dev/sda2 / ext4
/dev/sdb1 /data ext4

Значення: Показує, які пристрої куди змонтовані.

Рішення: Не запускайте rw fsck на змонтованій файловій системі. Якщо потрібно перевірити змонтований ext4 — використовуйте fsck -n лише для огляду і заплануйте простій для реального ремонту офлайн.

Завдання 15: Примусити перевірку при наступному перезавантаженні (контрольовано)

cr0x@server:~$ sudo touch /forcefsck
cr0x@server:~$ ls -l /forcefsck
-rw-r--r-- 1 root root 0 Dec 30 02:45 /forcefsck

Значення: Багато Debian-налаштувань поважають /forcefsck при завантаженні для запуску перевірок.

Рішення: Використовуйте це, коли хочете планову перевірку, а не коли бажаєте ризикнути несподіваною 2-годинною затримкою під час вікна деплою.

Завдання 16: Знайдіть, чому попереднє завершення роботи було нечистим

cr0x@server:~$ journalctl -b -1 -p warning..alert | tail -n 30
Dec 30 01:58:09 server kernel: EXT4-fs warning (device sda2): ext4_end_bio:345: I/O error 10 writing to inode 2625315 starting block 1234567)
Dec 30 01:58:12 server systemd[1]: Failed to start Flush Journal to Persistent Storage.
Dec 30 01:58:16 server kernel: Kernel panic - not syncing: Fatal exception

Значення: Попередній завантаження завершився погано. fsck не є причиною; він є наслідком.

Рішення: Виправте тригер (помилки диска, паніки ядра, проблеми з живленням), інакше ви знову опинитеся у тій самій ситуації з «довгою перевіркою файлової системи».

Три корпоративні міні-історії (що трапляється насправді)

1) Інцидент через неправильне припущення: «То просто великий диск»

Середня компанія керувала флотом Debian з внутрішніми артефактами збірки. Одного ранку критичний build-runner перестав завантажуватись. На консолі була перевірка ext4. На чергуванні знизили плечима: великий диск, багато файлів, закінчиться сам.

Через дві години він усе ще працював. Повідомлення про прогрес рухались повільно, але не так, як очікуєш від NVMe-хоста. Перша помилка команди була в тому, що вони сприйняли «повільно» за «нормально» і не подивились логи ядра. Вони трактували fsck як завдання обслуговування, а не як симптом.

Зрештою хтось перевірив dmesg і знайшов ресети лінка на SATA-шляху, що живив дешевий SATA SSD, який спочатку був «тимчасовим» кешем, а став постійним. Читання повторювалися. Диск не був мертвим; він помирав ввічливо, тягнучи всіх за собою.

Ремонт завершився, але файлова система вимагала ще однієї перевірки при наступному завантаженні, бо під час фінальних записів суперблока диск кинув ще помилок. Тільки після цього вони зупинилися і замінили пристрій. Урок був нудно болючим: помилки зберігання маскуються під «довгі перевірки» перш ніж стати очевидними відмовами.

Після цього вони додали runbook: якщо fsck перевищує поріг, перевіряти SMART і dmesg протягом десяти хвилин. Не тому, що вони люблять процеси, а тому що люблять спати.

2) Оптимізація, що вдарила в обличчя: «Погнали збільшувати швидкість відбудови RAID»

Інша організація керувала парою великих RAID1 на комоді. Диск вийшов з ладу, почалась відбудова RAID, і хтось вирішив «оптимізувати», підвищивши швидкість відбудови, щоб скоротити час деградації. На папері все було раціонально: швидше відбудова — менший ризик.

В реальності на тій машині також працювала критична база даних і купа задач обробки логів. Збільшення агресивності відбудови задушило чутливість до латентності читань. База почала таймаутитись, черги ядра зросли, і потім прийшло перезавантаження — бо хтось вирішив, що база «зависла». Насправді вона задихалась.

При перезавантаженні почалась перевірка файлової системи. Тепер fsck конкурував з ще не завершеним відновленням RAID. «Оптимізація» перетворила один проблемний день на два: деградований RAID плюс болісно повільний fsck, плюс час на відновлення застосунків.

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

3) Нудна, але правильна практика, яка врятувала день: «Вікна обслуговування і відрепетироване відновлення»

Третя команда керувала Debian-серверами для середовища з високими вимогами до відповідності. У них була найменш захоплива інженерна культура, яку тільки можна уявити, і це було чудово. Вони щоквартально планували вікна обслуговування сховищ, включно з контрольованими перезавантаженнями, перевіркою SMART і плановою fsck на обертовому наборі машин.

Коли хост зазнав нечистого вимкнення через проблему з розподілом живлення, черговий побачив довгу перевірку і не запанікував. У них були базові показники: скільки часу займає повна перевірка на конкретному томі та обладнанні, і як виглядають нормальні проходи. Також вони мали відомий хороший rescue-образ з сумісними версіями e2fsck.

Під час діагностики вони не знайшли I/O помилок, лише файлову систему, позначену як нечиста. Вони дали їй завершитись, вона вкладалась у очікуване вікно, і сервіси повернулись. Ніякої драми, жодних імпровізованих подвигів.

Наступного дня вони провели аудит події з живленням, впевнились, що це не повторюється, і все. Їх «секретний соус» — не розум; а репетиція і нудні базові показники. Те, що ніхто не хоче фінансувати, поки не прийде рахунок за відмову.

Жарт №2: Файлові системи — як корпоративні оргшарти: усе здається погодженим, поки не спробуєш звірити, хто кому підпорядковується.

Поширені помилки: симптом → корінь → виправлення

1) «fsck застряє на 0–5% назавжди»

Симптом: Ранній прохід займає вічність, консоль показує мало руху.

Корінь: Пристрій повертає читання з величезною латентністю через повторні спроби, або ви на деградованому RAID/йде ресинхронізація.

Виправлення: Перевірте dmesg на предмет I/O помилок, запустіть iostat -x для await/%util, і подивіться SMART-лічильники. Якщо йде відбудова RAID — вирішіть, чи не краще її завершити спочатку.

2) «fsck виконується при кожному перезавантаженні»

Симптом: Система завжди перевіряє root при старті, навіть після чистого завершення роботи.

Корінь: Файлова система ніколи не позначається як чиста: помилки зберігання, примусові перевірки через полісі за кількістю монтажів, або завершення роботи не доходить до коректного відмонтування.

Виправлення: Перевірте стан/лічильник монтажів через tune2fs -l, подивіться логи попереднього збою, усуньте проблему з перезавантаженням/живленням і переконайтесь, що завершення роботи відбувається коректно.

3) «Під час завантаження просить ручного втручання»

Симптом: При старті падає в промпт із запитом виправити помилки.

Корінь: Помилки, що не піддаються автоматичній обробці, або невідповідність політик (система очікує -p, але помилки вимагають ручних рішень).

Виправлення: Завантажтесь у rescue/emergency, спочатку оцініть за допомогою e2fsck -f -n, потім ремонтуйте з логуванням. Розгляньте налаштування обробки перевірок, щоб продакшн-завантаження не були інтерактивними іграми.

4) «fsck повільний на NVMe, а це має бути швидко»

Симптом: Хвилини здаються годинами на сучасному сховищі.

Корінь: Тротлінг NVMe через температуру, корекція помилок на рівні прошивки, проблеми PCIe link або контенція у віртуалізованому доступі до сховища.

Виправлення: Перевірте dmesg на предмет NVMe ресетів, використайте iostat для await, і перевірте NVMe SMART/health. Якщо віртуалізовано — підтвердіть здоров’я хоста і відсутність «шумних сусідів».

5) «Ми відключили fsck у fstab і корупція стала гіршою»

Симптом: Після серії крашів файлова система монтується, але поводиться дивно; пізніше стає не відмонтованою.

Корінь: Вимкнення перевірок, щоб пришвидшити старт, приховало наростаючі проблеми з метаданими.

Виправлення: Увімкніть перевірки для root, заплануйте перевірки для великих томів і побудуйте робочий процес обслуговування замість того, щоб сподіватися, що журналювання вирішить усе.

6) «Ми запустили fsck на змонтованій файловій системі і стало якось дивно»

Симптом: Файли зникають, каталоги поводяться неправильно, пізніше помилки наростають.

Корінь: Ремонт запущено під час того, як файлова система змінюється (змонтована і активна).

Виправлення: Зупиніться. Перемонтуйте лише для читання, якщо можливо, або ремонтуйте офлайн з rescue або під час технічного вікна. Якщо дані критичні — зробіть снапшот/резервну копію перед діями.

Контрольні списки / покроковий план

Чекліст A: Коли fsck працює під час завантаження і ви на чергуванні

1. Підтвердіть, що саме працює: ідентифікуйте юніт fsck і пристрій (Завдання 1–2).
2. Пошукайте помилки зберігання в ядрі: dmesg і журнал попереднього завантаження (Завдання 3 і 16).
3. Заміряйте здоров’я IO: iostat -x для латентності/завантаження (Завдання 7).
4. Перевірте SMART / NVMe health: переконайтесь, що не працюєте на помираючому пристрої (Завдання 8).
5. Перевірте RAID/LVM-шари: переконайтесь, що ви не конкуруєте з відновленням або деградованим шляхом (Завдання 9–10).
6. Прийміть рішення:
   • Якщо помилки пристрою: припиніть повторні ремонти, плануйте заміну диска і відновлення даних.
   • Якщо помилок немає, але том великий: дайте завершитись; повідомте очікуваний діапазон часу, а не обіцянку.
   • Якщо інтерактивні запити: завантажтесь в rescue і зробіть контрольований ремонт з логами.

Чекліст B: Контрольований робочий процес ремонту (план «хочу своє життя назад»)

1. Завантажтесь у rescue/emergency або з інсталяційного/live-образу.
2. Переконайтесь, що файлова система відмонтована: перевірте findmnt (Завдання 14).
3. Запустіть оцінку тільки для читання: e2fsck -f -n -v (Завдання 11).
4. Якщо диск достатньо здоровий, запустіть ремонт з логами: e2fsck -f -y -v | tee (Завдання 12).
5. Повторно запускайте fsck, поки він не повідомить про «clean». Один прохід не завжди достатній після важких ремонтів.
6. Змонтуйте і перевірте працездатність: підтвердіть ключові каталоги, сервіси і контрольні суми рівня застосунків, якщо вони є.
7. Після завантаження зберіть докази: SMART, логи ядра і файл журналу fsck для запису інциденту.

Чекліст C: Запобігти наступному нічному марафону fsck

1. Базуйте часи перевірок для кожного класу хостів (HDD vs SSD vs NVMe, RAID vs non-RAID).
2. Налаштуйте моніторинг і сповіщення за латентністю диска і деградацією SMART, а не лише «диск заповнений».
3. Перегляньте значення pass у /etc/fstab. Не дозволяйте терабайтним томам блокувати завантаження, якщо ви цього не маєте на увазі.
4. Заплануйте періодичні контрольовані перевірки для великих томів, якщо ваш ризик-модель цього вимагає.
5. Усуньте причини нечистого завершення роботи: ненадійне живлення, нестабільні ядра/драйвери, перегрів контролерів, погані кабелі.

Питання й відповіді

1) Скільки має тривати ext4 fsck на Debian 13?

Від секунд (відтворення журналу) до годин (повний скан). Для мульти-терабайтних HDD-файлових систем з великою кількістю дрібних файлів години можуть бути нормою. Для SSD/NVMe години — підозріло, якщо тільки файлова система не гігантська або пристрій не хворий.

2) Чому fsck здається застиглим без оновлення відсотка?

Деякі проходи не виводять частий прогрес, і консолі завантаження можуть буферизувати вивід. Важливіше — fsck може блокуватись на I/O і все одно «працювати». Використовуйте ps для статусу і iostat -x, щоб відрізнити це.

3) Чи можна скасувати fsck?

Можна, але зазвичай це погана угода. Переривання ремонту може залишити файлову систему в гіршому стані. Якщо підозрюєте апаратну відмову, правильне «скасування» — зупинити записи, зробити образ диска і відновлювати безпечно.

4) Чи безпечно запускати fsck на змонтованій файловій системі?

Для ext4 запуск rw fsck на змонтованій файловій системі небезпечний. Використовуйте -n лише для огляду, якщо треба, і плануйте простій для офлайн-ремонту.

5) Навіщо Debian взагалі запускає fsck при завантаженні?

Тому що монтування пошкодженої файлової системи на запис може розповсюдити пошкодження. Перевірка під час завантаження — це запобіжний засіб. Іноді це дратує, але краще, ніж тиха корупція.

6) Мій сервер віртуалізований. Що змінюється?

Латентність може бути оманливою. Віртуальна машина може показувати «повільний диск», бо хост перевантажений, бекенд сховища деградований або є шумні сусіди. Діагностика на рівні VM все одно допомагає, але може знадобитись підтвердження стану на хості.

7) Чи вимикати автоматичні перевірки для великих томів?

Часто так — якщо ви заміните їх запланованими перевірками і моніторингом. Використовуйте 0 у полі pass для монтажу даних у /etc/fstab, залишайте root під перевіркою, і запускайте контрольований fsck у вікні обслуговування.

8) У чому різниця між відтворенням журналу і повним fsck?

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

9) fsck завершився, але система все одно не завантажується. Що робити?

Перевірте, чи не відсутні файли у завантажувачі або initramfs, чи /etc/fstab не вказує неправильний UUID, і чи базовий диск не продовжує видавати помилки. «Успішний» fsck на деградованому диску може бути тимчасовим.

10) Чи XFS/Btrfs/ZFS мають той самий fsck-проблему?

У них інші режими відмов. XFS використовує xfs_repair (офлайн, може бути важким). Btrfs має власні інструменти і може бути болісним при певних корупціях. ZFS — зовсім інша історія (scrub, контрольні суми). Загальна тема: латентність сховища і апаратні помилки роблять будь-який ремонт повільним.

Наступні кроки, що не витратять вашу ніч даремно

Якщо fsck у Debian 13 «триває вічно», не сприймайте це як погоду. Вважайте це діагностичною миттю.

1. Протягом 10 хвилин: перевірте dmesg, iostat -x і SMART. Визначте, чи маєте справу з корупцією на здоровому накопичувачі або корупцією через відмову обладнання.
2. Якщо апарат виглядає хворим: припиніть повторні спроби ремонту, захистіть дані, замініть пристрій, а потім ремонтуйте/відновлюйте.
3. Якщо апарат виглядає здоровим: дайте fsck завершитись, але усуньте причину нечистих завершень і перегляньте політику перевірок при завантаженні для великих не-root томів.
4. Після відновлення: збережіть лог fsck, обдумано відкоригуйте /etc/fstab pass-значення та базуйте часи перевірок, щоб наступний черговий не мусив гадати.

Вам не потрібно любити перевірки файлових систем. Потрібно просто перестати дивуватись їм.