Чи редагування файлів в Linux безпосередньо зберігаються на диску?


57

Я думав, що зміни файлів зберігаються безпосередньо на диску, тобто, як тільки я закриваю файл і вирішую натиснути / вибрати зберегти. Однак в нещодавній розмові моя знайома сказала мені, що зазвичай це неправда; ОС (зокрема ми говорили про системи Linux) зберігає зміни в пам'яті, і вона має демон, який фактично записує вміст з пам'яті на диск.

Він навіть наводив приклад зовнішніх флеш-накопичувачів: вони встановлюються в систему (копіюються в пам'ять), а іноді втрата даних трапляється через те, що демон ще не зберігав вміст у флеш-пам’яті; саме тому ми демонтуємо флешки.

Я не знаю про функціонування операційних систем, і тому я абсолютно не маю уявлення, чи це правда і за яких обставин. Моє головне питання: чи трапляється це так, як описано в системах Linux / Unix (і, можливо, інших ОС)? Наприклад, чи означає це, що якщо я вимкну комп’ютер відразу після редагування та збереження файлу, мої зміни, швидше за все, будуть втрачені? Можливо, це залежить від типу диска - традиційні жорсткі диски проти твердотілих дисків?

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


8
ФАО: Закрийте рецензентів черги на голосування. Це не запит на навчальні матеріали. Дивіться unix.meta.stackexchange.com/q/3892/22812
Ентоні G - справедливість для Моніки

2
Кеш непрозорий для користувача, в кращому випадку вам потрібно sync, і програми повинні flushгарантувати, що кеші будуть записані назад, але навіть успіх syncне гарантує повернення на фізичний диск лише того, що кеші ядра перекинуті на диск, який може мати затримку у драйвері або на диску на диску (наприклад, кеш-накопичувач, який ви втрачаєте)
аварійне завершення

1
Хоча я не згоден з тим, що це запит на навчальні матеріали, я вважаю, що питання є дещо широким у його теперішній формі. Обмежте сферу застосування дистрибутивами Linux (або будь-якою конкретною ОС) і, можливо, обмежте її певними технологіями зберігання даних та файловими системами.
Джефф Шаллер

3
Як зазначав @AnthonyGeoghegan, я не вважаю це питання запитом до навчальних матеріалів. Я думаю, що це досить специфічно; Я не просив довгого та глибокого пояснення чи посібника щодо файлових систем Linux; лише про коротку ідею, яку я хотів прояснити.
JuanRocamonde

3
Це правда, що він є дещо широким, @JeffSchaller; Я спробую трохи відредагувати це; однак, якщо чесно, якщо на сайті немає таких питань, які безпосередньо стосуються функціонування Linux, то для чого це?
JuanRocamonde

Відповіді:


70

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

Вони можуть бути. Я б не сказав "найімовірніше", але ймовірність залежить від багатьох речей.


Найпростіший спосіб підвищити продуктивність запису файлів - це операційна система просто кешувати дані, повідомляти (брехати) програмі, через яку пройшло написання, а потім фактично робити запис пізніше. Це особливо корисно, якщо одночасно відбувається й інша активність диска: ОС може розставляти пріоритети читання та робити записи пізніше. Він також може повністю усунути необхідність фактичного запису, наприклад, у випадку, коли тимчасовий файл швидко видаляється після цього.

Питання кешування виразніше, якщо зберігання повільне. Копіювання файлів з швидкого SSD на повільний USB-накопичувач, ймовірно, передбачає багато кешування запису, оскільки USB-накопичувач просто не може йти в ногу. Але ваша cpкоманда повертається швидше, тому ви можете продовжувати працювати, можливо, навіть редагувати файли, щойно скопійовані.


Звичайно, кешування таким чином має і зворотний бік, який ви зазначаєте, деякі дані можуть бути втрачені ще до того, як вони фактично збережені. Користувач буде змінено, якщо їх редактор сказав, що запис вдалося, але файл насправді не був на диску. Ось чому є fsync()системний виклик , який повинен повернутися лише після того, як файл фактично потрапив на диск. Ваш редактор може використовувати це, щоб переконатися, що дані є чудовими, перш ніж повідомити користувачеві про те, що запис вдалося.

Я сказав: "Потрібно", оскільки сам диск може сказати ті самі брехні ОС і сказати, що запис завершено, тоді як файл дійсно існує лише в енергонезалежній кеш-записи на диску. Залежно від накопичувача, це може не обійтись.

Крім того fsync(), є також sync()і syncfs()системні дзвінки, які просять систему переконатися, що всі записи або всі записи в певній файловій системі потрапили на диск. Утиліта syncможе використовуватися для виклику цих.

Тоді також є O_DIRECTпрапор доopen() , який повинен "намагатися мінімізувати ефекти кеш-пам'яті вводу-виводу до цього і з цього файлу". Видалення кешування знижує продуктивність, тому це в основному використовується додатками (базами даних), які виконують власне кешування і хочуть контролювати його. ( O_DIRECTне обійшлося без проблем, коментарі до нього на сторінці чоловіка дещо кумедні.)


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

Як файлова система обробляє зміни метаданих та впорядкування між метаданими та записами даних значно відрізняється. Наприклад, ext4якщо ви встановите прапор кріплення data=journal, то всі записи - навіть записи даних - проходять через журнал і мають бути досить безпечними. Це також означає, що вони пишуться двічі, тому продуктивність знижується. Параметри за замовчуванням намагаються впорядкувати запис так, щоб дані були на диску перед оновленням метаданих. Інші параметри або інша файлова система можуть бути кращими або гіршими; Я навіть не спробую всебічного дослідження.


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


Схоже, ваше some cases whereпосилання не говорить про такі випадки - це натомість говорить про те, що існували проблеми, коли додатки не використовувались fsync. Або я повинен заглянути в коментарі, щоб знайти ці випадки, на які ви вказуєте?
Руслан

1
Ви також можете використовувати syncбезпосередньо як команду системної оболонки, щоб проштовхувати ядро, щоб очистити всі кеші.
катастрофа

3
На практиці, у злегка завантаженій системі, файл потрапить на диск за хвилину. Тільки якщо ваш редактор використовує fsync()після написання файлу. За замовчуванням для Linux /proc/sys/vm/dirty_writeback_centisecsстановить 500 (5 секунд), і PowerTop рекомендує встановити його на 1500 (15 секунд). ( kernel.org/doc/Documentation/sysctl/vm.txt ). У системі з легким завантаженням ядро ​​просто дозволить йому сидіти брудно в кеш-пам'яті сторінок, який задовго до того, write()як перейти на диск, щоб оптимізувати випадок, коли він буде видалений або змінений незабаром знову.
Пітер Кордес

2
+1 для, оскільки сам накопичувач може скласти таку ж брехню в ОС . Я розумію, що накопичувачі такого типу кешування також мають достатню ємність потужності, щоб зберегти їх кеші навіть при катастрофічних втратах потужності. Це не для ОС; У Windows є механізм "Безпечне видалення USB", щоб виконувати промивання кешу перед тим, як користувач вимкнеться з розетки.
студія

1
@studog, я б не був таким впевненим, особливо на споживчому обладнання. Але це може бути просто параноїя. Хоча було б цікаво перевірити.
ilkkachu

14

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

Деякі приклади:

  • tmpfs, файлова система, яка існує лише в оперативній пам'яті (точніше, в кеш-пам'яті)
  • ramfs, файлова система, яка існує лише в оперативній пам'яті
  • будь-яка мережева файлова система (NFS, CIFS / SMB, AFS, AFP,…)
  • будь-яка віртуальна файлова система ( sysfs, procfs, devfs, shmfs, ...)

Але навіть для файлових систем, захищених дисками, це зазвичай не відповідає дійсності. На сторінці " Як пошкодити базу даних SQLite " є глава під назвою " Нездатність синхронізації", в якій описано багато різних способів, коли записи (у цьому випадку передається в базу даних SQLite) не можуть потрапити на диск. SQLite також має білий документ, в якому пояснюється безліч обручів, через які вам доведеться перестрибнути, щоб гарантувати Atomic Commit In SQLite . (Зверніть увагу, що Atomic Write набагато складніше, ніж проблема, ніж просто Write , але, звичайно, запис на диск - це підзадача атомного запису, і ви можете багато чого дізнатися про цю проблему також з цієї статті.) У цьому документі є розділ " Речі, які можуть піти не так", який включає підрозділ проНеповні диски, що наводять кілька прикладів тонких тонкощів, які можуть перешкоджати потраплянню запису на диск (наприклад, контролер жорсткого диска, який повідомляє, що він записав на диск, коли фактично цього немає - так, є виробники жорстких дисків, які роблять це, і це може бути навіть законним згідно зі специфікацією ATA, оскільки це неоднозначно сформульовано в цьому відношенні).


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

3
Як зазначав @pipe, той факт, що існують файлові системи, які не зберігають дані на диску, оскільки вони не використовують диск для зберігання даних, не визначає, чи можуть ті, хто це має, можуть зберігати їх безпосередньо. Однак відповідь виглядає цікаво
JuanRocamonde

1
@pipe Я майже впевнений, що використання терміна "besserwissering" - це бездоганно! Сказав, що як німецький Бесервізер з авторитетом.
Volker Siegel

11

Правда, більшість операційних систем, включаючи Unix, Linux та Windows, використовують кеш запису для прискорення операцій. Це означає, що вимкнення комп'ютера без його вимкнення є поганою ідеєю і може призвести до втрати даних. Те ж саме, якщо ви виймете USB-накопичувач до його готовності.

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

Коротше кажучи, є причина, чому слід правильно вимкнути комп’ютер і правильно підготувати USB-накопичувач до видалення.


Дякую за відповідь! Чи є спосіб змусити записувати диск на певний файл у Linux? Можливо, посилання на підручник або сторінку з документами, навіть питання SE було б добре :)
JuanRocamonde

4
Ви можете примусити записати файл за допомогою fsync()syscall з програми. З оболонки просто використовуйте syncкоманду.
RalfFriedl

2
Існують (або принаймні були) деякі файлові системи в деяких версіях Linux, де syncреалізовано як неоперативний варіант . І навіть для файлових систем, які правильно реалізують sync, все ще існує проблема, яку деякі дискові прошивки реалізують FLUSH CACHEяк неоперативні або негайно повертаються з неї та виконують її у фоновому режимі.
Йорг W Міттаг

9

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.


5

У злегка завантаженій системі ядро ​​дозволить щойно записаним даним файлів просидіти в кеш-сторінках, можливо, 30 секунд після write(), перш ніж передати його на диск, щоб оптимізувати випадок, коли незабаром буде видалено або змінено.

За dirty_expire_centisecsзамовчуванням Linux - 3000 (30 секунд) та контролює, як довго "закінчується термін дії". (Див. Https://lwn.net/Articles/322823/ ).

Див. Https://www.kernel.org/doc/Documentation/sysctl/vm.txt для отримання більш пов’язаних змін, а Google ще багато інших. (наприклад, Google увімкнено dirty_writeback_centisecs).

За замовчуванням для Linux /proc/sys/vm/dirty_writeback_centisecsстановить 500 (5 секунд) , і PowerTop рекомендує встановити його на 1500 (15 секунд), щоб зменшити споживання енергії.


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

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

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


Якщо ваш редактор використовував fsync()після написання файлу, ядро ​​записує його на диск без зволікань. (І fsyncне повернеться, поки дані фактично не будуть надіслані на диск).


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

На обертовому (магнітному) диску ви можете побачити кілька запитів затримки від 7 до 10 мс кожен перед тим, як дані команди SATA запису фактично є безпечними від вимкнення, якщо перед записом були очікування читання / запису. (Деякі інші відповіді на це питання детальніше описують кеші запису на диск та бар'єри для запису, якими можуть користуватися журнали FSes, щоб уникнути корупції.)

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