Коли fsck небезпечний?


37

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

При перезавантаженні була показана така помилка:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

Після запуску fsck, як було запропоновано, та прийняття виправлень вручну Y, помилки були виправлені, і система тепер добре.

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

Моє запитання: чому fsck за замовчуванням вимагає вручну втручання? Як і коли виправлення, виконане такою програмою, було б небезпечним? Які випадки, коли систематик може захотіти залишити запропоновану корекцію на деякий час (виконувати деякі інші операції) або взагалі відмінити її?


15
Якби розробники були на 100% впевнені, помилка може бути виправлена ​​автоматично, то це не буде помилкою в першу чергу.
користувач253751

Відповіді:


42

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

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


4
Я багато працював із несправним обладнанням, і я згоден з цим. Останнє, що я хочу зробити, - це fsck, якщо є підозра на шкідливе обладнання будь-якого типу. Я також бачив події з низькою потужністю та подальше відновлення, яке сильно затрималось автоматичним fsck.
jorfus

Щоб навести конкретний приклад: я працював на машині з дисковим контролером, який "випадковим чином" (приблизно 1 раз в 10 ^ 5) перетворив би читання або запис, щоб заблокувати XXXXXXYY на будь-якому пристрої в запис для блокування 000000YY на перший пристрій. Тобто, часто завантажуються структуровані неправильні та неструктуровані неправильні дані в завантажувальний сектор та різні критичні структури файлової системи завантажувального диска. Запуск fsck у такій ситуації (мільйони читань) може усунути будь-який інший шанс відновити дані.
Ерік Тауерс

2
1 на 10 ^ 5 - це багато ... це 10 байт МБ.
Нельсон

1
@Nelson: Це начебто ... У підрозділі є "передача одного блоку", а не "байти". Тож десять поганих блоків записують на мільйон блоків (а блоки значно більше байтів).
Ерік Тауерс

21

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

Це ніколи, ніколи ідея добре , щоб спробувати що - щось подібне , що автоматичний взагалі.

О, а сучасні сервери повинні мати віддалені консолі або принаймні незалежні рятувальні системи, щоб відновитись із чогось подібного, не затягуючи стійки KVM на сервер.


7
Насправді, те, що не годиться, - говорити так " ніколи, ніколи ", коли це неправда. Використовуйте випадок, коли це гарна ідея: основні розділи сервера можуть бути створені з нуля досить швидко, у разі виникнення проблем. Насправді важливі дані отримують доступ через віддалену файлову систему з відповідним надмірністю для цих даних. Я набагато скоріше ризикую, fsck -p /і fsck -p /varт. Д., Працюю чудово, і вставляю сервер без ручного втручання, і ризикую невеликим, ненульовим% шансом серйозної катастрофи на ті розділи, які я можу просто створити, якщо потрібно .
TOOGAM

1
Якщо систему можна легко перевстановити, я просто роблю це ...
Sven

1
Це займе більше часу. Варіанти: А) Ризикуйте робити це автоматично. Б) Попросіть когось сказати fsckна попередній перегляд, і тоді все працює добре. Займає близько 2 хвилин, якщо це. Час простою, поки цього не станеться. C) Нехай хтось перевстановить операційну систему. Займає 30+ хвилин. Ви вибираєте варіант C? Можливо, ключовою відмінністю є те, що я fsckпрацював більший відсоток часу, ніж те, що ви цитуєте у своїй відповіді. Головним моїм моментом був не дизайн системи (ця дешева система не використовує віддалену консоль), а лише те, що приказка " ніколи і ніколи " не була занадто сильною фразою, щоб бути точною
TOOGAM

Давайте просто погодимось не погодитися.
Свен

0

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

Ext3, Ext4, ZFS, btrfs, xfs та всі сучасні FS на 100% відповідають після збоїв або скидання системи.

Нерукалізовані FS, такі як ext2 або vfat, є великим NOGO для системних коренів.

Тепер, якщо вашій системі потрібен fsck під час завантаження, ви повинні запитати себе: що було причиною цього в першу чергу?

Після цього слід дослідити журнали ядра, щоб з’ясувати, коли і що сталося. Ви також повинні повернутися в часі до журналів, щоб знайти з моменту початку помилки. Ви повинні перевірити свої диски за допомогою smartctl. І т. Д. ... Якщо вам потрібен fsck на гуманізованому файлі fs, ви практично впевнені, що ваше обладнання виходить з ладу, припускаючи, що fs не було пошкоджено адміністратором (за допомогою інструментів рівня блоків, таких як dd) або помилкою.

Тож нерозумно використовувати fsck, щоб "виправити" проблему, не досліджуючи та не виправляючи першопричину (замінивши / оновивши несправне апаратне / програмне забезпечення / програмне забезпечення).

Робити fsck, завершувати завантаження та бути щасливим - це найменше. Заявивши, що "у мене була робота на fsck більший відсоток часу, ніж те, що ви цитуєте", змушує мене замислитися, що ви маєте на увазі під "fsck work". fsck, можливо, повернув ваш fs до стійкого стану, втративши деякі файли та дані в процесі ... Ви порівняли з резервною копією? Багато людей втрачають файли або отримують пошкодження даних про файли, не помічаючи ...

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.