1. Флеш-пам’ятка
Це залежить від типу диска (традиційні жорсткі диски та твердотілі диски) чи будь-якої іншої змінної, про яку я, можливо, не знаю? Чи трапляється це (якщо воно є) лише в Linux або це є в інших ОС?
Якщо у вас є вибір, ви не повинні дозволяти пам’яті на базі флеш втрачати живлення без чистого відключення.
На недорогих сховищах, як-от SD-карт, можна очікувати втрати цілих блоків стирання (в кілька разів більших за 4 КБ), втрачаючи дані, які можуть належати до різних файлів або основних структур файлової системи.
Деякі дорогі SSD-диски можуть стверджувати, що вони надають кращі гарантії в разі відключення електроенергії. Однак стороннє тестування свідчить про те, що багато дорогих SSD не роблять цього. Шар, який переробляє блоки для "вирівнювання зносу", є складним і власним. Можливі збої включають втрату всіх даних на накопичувачі.
Застосовуючи наші тестові рамки, ми тестуємо 17 товарних SSD від шести різних постачальників, використовуючи більше трьох тисяч циклів введення несправностей. Наші експериментальні результати виявляють, що 14 із 17 перевірених SSD-пристроїв демонструють дивовижне поведінку при збоях живлення, включаючи біт-корупцію, шорн пише, несеріалізаційні записи, пошкодження метаданих та повну несправність пристрою.
2017: https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat
2013: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf?wptouch_preview_theme=enabled
2. Спінінг жорстких дисків
Обертові жорсткі диски мають різні характеристики. Для безпеки та простоти я рекомендую припустити, що вони мають таку ж практичну невизначеність, як і флеш-пам’ять.
Якщо у вас немає конкретних доказів, яких ви, очевидно, не маєте. У мене немає порівняльних цифр для обертання жорстких дисків.
HDD може залишити один неповно написаний сектор з поганою контрольною сумою, що надасть нам непогашений помилка читання згодом. Загалом, цей режим відмов жорстких дисків цілком очікуваний; рідні файлові системи Linux розроблені з урахуванням цього. Вони мають на меті зберегти контракт fsync()
у зв'язку з цим видом втрат електроенергії. (Ми дуже хотіли б, щоб це було гарантовано на SSD).
Однак я не впевнений, чи досягають файлові системи Linux у всіх випадках, чи це можливо навіть.
Наступне завантаження після цього типу помилок може потребувати ремонту файлової системи. Оскільки Linux, можливо, відновлення файлової системи задасть вам деякі незрозумілі запитання, де ви можете лише натиснути Y і сподіватися, що воно розібрається.
2.1 Якщо ви не знаєте, що таке контракт fsync ()
Контракт fsync () є джерелом як добрих, так і поганих новин. Ви повинні спочатку зрозуміти добрі новини.
Хороша новина: fsync()
добре задокументована як правильний спосіб запису даних у файли, наприклад, коли ви натискаєте "зберегти". І широко розуміється, що, наприклад, текстові редактори повинні замінювати наявні файли атомарним шляхом rename()
. Це покликане переконатися, що ви завжди або зберігаєте старий файл, або отримуєте новий файл (який був fsync()
відредагований перед перейменуванням). Ви не хочете, щоб у вас залишилася напівзаписана версія нового файлу.
Погана новина: протягом багатьох років виклик fsync () у найпопулярнішій файловій системі Linux міг ефективно залишити всю систему на десятки секунд. Оскільки програми не можуть нічого з цим зробити, дуже оптимістично було використовувати rename () без fsync (), що виявилося досить надійним у цій файловій системі.
Тому існують програми, які не використовують коректно fsync ().
Наступна версія цієї файлової системи зазвичай уникала зависання fsync () - одночасно, коли вона почала покладатися на правильне використання fsync ().
Це все досить погано. Розуміння цієї історії, ймовірно, не допомагає зневажливим тоном і вигадливістю, яку використовували багато хто з конфліктуючих розробників ядра.
Поточна резолюція - це найпопулярніша найпопулярніша файлова система Linux за замовчуванням підтримує шаблон перейменування (), не вимагаючи fsync ()реалізує "сумісність помилок для помилок" з попередньою версією. Це можна відключити за допомогою параметра кріплення noauto_da_alloc
.
Це не повний захист. В основному, він промиває очікуваний IO під час перейменування (), але він не чекає завершення IO перед перейменуванням. Це набагато краще, ніж, наприклад, 60-секундне вікно небезпеки! Дивіться також відповідь на те, які файлові системи потребують fsync () для забезпечення аварійних ситуацій при заміні існуючого файлу на перейменувати ()?
Деякі менш популярні файлові системи не забезпечують захисту. XFS відмовляється це робити. І UBIFS також не реалізував це, мабуть, це можна було б прийняти, але для того, щоб зробити це можливим, потрібно багато роботи. На цій же сторінці вказується, що UBIFS має кілька інших "TODO" питань щодо цілісності даних, у тому числі щодо втрати електроенергії. UBIFS - це файлова система, що використовується безпосередньо на флеш-накопичувачі. Я думаю, що деякі труднощі, які згадує UBIFS з флеш-пам’яттю, можуть мати відношення до помилок SSD.