Я помітив, що XFS не реалізує fsck під час завантаження системи, і одна з причин, про яку йдеться в тому, що файлові системи журналу допомагають забезпечити, щоб файлова система перебуває у стабільному стані після нечистого відключення; при наступному монтажі (наприклад, після перезавантаження) журнал відтворюється.
Чи потрібен fsck після нечистого відключення і чому?
Відповіді:
Я відповідаю на це в загальному контексті "журнальованих файлових систем".
Я думаю , що якщо ви зробили кілька «нечистими зупинок» (від потягнувши за кабель живлення або що - то ) , рано чи пізно ви отримаєте в стан файлової системи , що потребують fsckабо морального еквівалента FSCK, xfs_repair. ext4Fileystsm на моєму ноутбуці , здебільшого просто переграє журнал при кожному перезавантаженні, включені чисті аррестори, але кожен раз в той час, він робить повний на fsck.
Але запитайте себе, що досягає "перезапис журналу". Повторне відтворення журналу гарантує, що блокові диски решти файлової системи відповідають порядку, який вимагають записи журналу. Повторна публікація журналу - це невелика кількість fsckчастин, а також їх частина fsck.
Я думаю, що відбувається деяка словесна хитрість рук: відтворення журналу є частиною того, що fsckробить традиційний , і xfs_repairсаме те, що та сама програма, яка e2fs.fsck(або будь-яка інша файлова система fsck). Люди XFS просто вірили, або їхній досвід привів їх до запуску не xfs_repairкожного завантаження, а лише до відтворення журналу.
fsckне є "педантичним". Я перетворив ext3 LVMрозділ ext4і почав отримувати помилки 'ext4_mb_generate_buddy' через, наскільки я розумію, помилки в ext4коді, яка спричинила невідповідність копій на диску та в пам'яті копій растрової карти на перетворених розділах 'LVM'. Наскільки я можу сказати fsck, жодної корупції не сталося. Рішенням було або вимкнути UNINIT_BGопцію, або перемістити дані та повторно ініціалізувати розділ як ext4; Я взяв останній курс. Але я все ще думаю, що кілька хвилин очікування на fsckварту не варто втрачати дані!
допомогти гарантувати, що файлова система перебуває у стабільному стані після нечистого відключення
Перше, що слід зауважити, це те, що XFS, рейзер і більшість конфігурацій ext реалізують лише мета-дані, що стосується уникнення fsck. Журнал не завжди відтворюється при запуску - він може бути відкинутий, якщо він неповний.
Існують системи, що підтримують повний обмін даними, але на практиці рівень впевненості, який вони дають лише за допомогою метаданих, у реальних сценаріях дуже малий.
Отже, "непослідовний стан" та проблеми, виправлені fsck, - це невідповідність між метаданими та самими файлами. Щоб уникнути цього, ОС записує запропоновані зміни метаданих у журнал, потім записує фактичні дані на диск, потім застосовує зміни метаданих, які реплікуються у журналі, на диск. Єдине спіймане в цьому полягає в тому, що контролер диска буде буферувати і потенційно переробляти запити. Щоб цього уникнути, більшість файлових систем, що керуються, реалізують бар'єри: вони розділяють кожну операцію і чекають, коли диск підтвердить, що він завершив операцію. Але багато сучасних дисків насправді підтверджують завершення запису до введення даних. Отже, речі можуть стати брудною.
Чи потрібен fsck після нечистого відключення і чому
Більшість файлових систем підтримують кількість змонтування - коли ця кількість буде досягнута, повна fsck буде запущена при наступній спробі встановлення диска. Причина полягає в тому, що дані диска можуть бути пошкоджені навіть тоді, коли вони явно не записуються, навіть без помилок у програмному забезпеченні. Коментар psusi вище є неправильним.
hdparm -W), диск не завершує запити запису, поки він не знаходиться на носії. Чому ви вважаєте, що такий варіант існує? Шлагбауми запобігають переупорядковуванню, коли надсилається кілька запитів. Без бар'єрів, fs просто не надсилає більше запитів, поки попередні не завершиться, таким чином зберігаючи замовлення без бар'єрів ... за умови, що кеш запису на диск не ввімкнено. Мета бар'єрів - дозволити ввімкнути кеш запису, не псуючи fs при збої.
sync. Дозвольте спробувати ще раз. Процедура запису на диск без бар’єрів полягає в тому, щоб записати в журнал sync, таким чином, промити будь-які кеші запису, а потім записати реальні дані. Це гарантує, що журнал завжди може бути використаний для відновлення файлів після аварії, але синхронізація сповільнює роботу і наполовину перемагає мету кешу запису. Таким чином, бар'єри були додані як краща заміна sync, і при належній підтримці диска вони можуть спокійно відшкодувати більшу частину продуктивності, яку синхронізація забирає.
Немає необхідності руйнувати файлову систему журналу просто через нечисте відключення.
Вся причиною переносячи продуктивністю виконання штрафу метаданих журналирования є забезпечення того , файлова система може бути 100% послідовно знову автоматично Відтворюється журнал метаданих на наступному монтуванні, якщо файлова система не була отмонтировать.
Єдина роль fsck полягає у забезпеченні послідовності метаданих, тому зайве запускати fsck просто тому, що файлова система не була належним чином відключена.
Файлова система журналу може бути пошкоджена з інших причин, хоча - збій обладнання, помилки драйверів, помилки адміністратора тощо - тому інструменти fsck, безумовно, необхідні. Просто немає причин звертатися до них виключно через нечисте відключення.