Чи може файлова система стати непослідовною, якщо її перервати під час переміщення файлу?

У мене є дві папки на одному розділі (EXT2) Якщо я mv folder1/file folder2і якась перерва (наприклад, відмова живлення) може файлова система коли-небудь виявиться непослідовною?

Хіба mvоперація не атомна?

Оновлення: Поки на IRC я ​​отримав такі перспективи:

1. це атомно, тому невідповідності не може відбутися
2. спочатку ви копіюєте запис dir у новий dir, а потім стираєте запис попереднього dir, тож у вас може виникнути невідповідність того, що файл буде посилатися двічі, але кількість посилань становить 1
3. він спочатку стирає вказівник, а потім скопіює покажчик, щоб невідповідність полягала в тому, що файл має посилання 0

Може хтось уточнить?

Спочатку давайте розвіємо кілька міфів.

це атомно, тому невідповідності не може відбутися

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

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

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

Це стосується конкретної техніки реалізації. Є й інші.

Так трапляється, що ext2 в Linux (на ядро ​​3.16) використовує саме цю техніку. Однак це не означає, що вміст диска проходить через послідовність [старе розташування] → [обидва місця] → ​​[нове місце розташування], оскільки дві операції (додавання нового запису, видалення старого запису) не є атомними на апаратному рівні : можливо, один з них може бути перерваний, залишаючи файлову систему в непослідовному стані. (Сподіваємось, fsck виправить його.) Крім того, блок-блок може змінити порядок написання, тому перша половина може бути передана на диск безпосередньо перед збоєм, а друга половина тоді не була б виконана.

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

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

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

Відповідно до публікації в блозі Олександра Ларссона , ext2 не дає гарантії послідовності системної аварії, але ext3 працює в data=orderedрежимі. (Зауважте, що це повідомлення в блозі не про renameсебе, а про поєднання написання у файл та виклику renameцього файлу.)

Теодор Цьо, головний автор файлових систем ext2, ext3 та ext4, написав допис у блозі з цього ж питання . У цьому дописі в блозі йдеться про атомність (лише щодо програмного середовища) та довговічність (що є атомністю щодо аварій, плюс гарантія прихильності, тобто знання, що операція виконана). На жаль, я не можу знайти інформацію про атомність щодо аварій. Однак гарантії довговічності, надані для ext4, вимагають, щоб renameце було атомним. Документації ядра для ext4 станів, ext4 з auto_da_allocопцією (яка за замовчуванням в сучасних ядрах), а також ext4, забезпечує гарантію міцності для writeподальшого аrename, з чого випливає, що renameце атомно по відношенню до апаратних збоїв.

Для Btrfs, що перезаписує існуючий файл гарантовано атомарні щодо аварій, але , що не перезаписати файл може привести ні файлу або обох файлів існуючих.renamerename

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

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

Якщо вам потрібна надійна файлова система внаслідок відключення живлення, слід використовувати файлову систему журналу , наприклад NTFS, EXT3 або XFS. Більшість сучасних систем використовуватимуть файлову систему журналу за замовчуванням, хоча ви повинні знати, що FAT не є файловою системою журналу, якщо ви використовуєте її для зовнішніх накопичувачів.

Журнальна файлова система використовує систему "подвійного запису" - вона записує в журнальний файл той факт, що він має намір перемістити її, а потім виконує переміщення. Коли перевіряється файлова система при запуску, якщо вона була перервана, вона помітить, що переміщення не було завершено, і повторіть її потім.

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

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

Для повноти зауважу, що існують також деякі випадкові операції вводу / виводу, пов'язані з перейменуванням, на додаток до створення нового посилання в каталозі призначення та видалення його в старому - оновлення mtime обох каталогів, можливо, подовження розмір виділення каталогу призначення, зміна ..посилання та кількість посилань батьківських каталогів, якщо файл - це каталог. Також я не впевнений, чи впливає на atime самого файлу.

Це питання було задано дещо по-іншому у Super User. Сторінка Вікіпедії в mvкоманді також це досить добре пояснює :

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

Linux має системну виклик перейменування і тому перейменовує файл як атомну, тобто безперебійну, операцію. Отже ні, файлова система не може стати непослідовною у описаній вами ситуації.