Czy system plików może stać się niespójny, jeśli zostanie przerwany podczas przenoszenia pliku?

13

Mam dwa foldery na tej samej partycji (EXT2). Jeśli mv folder1/file folder2wystąpią pewne przerwy (np. Awaria zasilania), czy system plików może kiedykolwiek być niespójny?

Czy mvoperacja nie jest atomowa?

Aktualizacja: Do tej pory na IRC miałem następujące perspektywy:

  1. jest atomowy, więc niespójności nie mogą się zdarzyć
  2. najpierw kopiujesz wpis dir w nowym dir, a następnie usuwasz wpis z poprzedniego dir, więc możesz mieć niekonsekwencję, aby dwukrotnie odwoływać się do pliku, ale liczba odwołań wynosi 1
  3. najpierw usuwa wskaźnik, a następnie kopiuje wskaźnik, więc niespójność polega na tym, że plik ma odniesienie 0

Czy ktoś może to wyjaśnić?

graphtheory92
źródło

Odpowiedzi:

11

Najpierw rozwińmy niektóre mity.

jest atomowy, więc niespójności nie mogą się zdarzyć

Przenoszenie pliku w tym samym systemie plików (tj. rename) Wywołanie systemowe ma charakter atomowy w stosunku do środowiska oprogramowania. Atomowość oznacza, że ​​każdy proces, który szuka pliku, zobaczy go w swojej starej lub nowej lokalizacji; żaden proces nie będzie w stanie zaobserwować, że plik ma inną liczbę linków lub że plik jest obecny w katalogu źródłowym po tym, jak jest obecny w katalogu docelowym, lub że plik jest nieobecny w katalogu docelowym po nieobecności w źródłowym informator.

Jednak jeśli system ulegnie awarii z powodu błędu, błędu dysku lub utraty zasilania, nie ma gwarancji, że system plików pozostanie w spójnym stanie, nie mówiąc już o tym, że przeniesienie nie zostało w połowie wykonane. Linux zasadniczo nie oferuje gwarancji atomowości w odniesieniu do zdarzeń sprzętowych.

najpierw kopiujesz wpis dir w nowym dir, a następnie usuwasz wpis z poprzedniego dir, więc możesz mieć niekonsekwencję, aby dwukrotnie odwoływać się do pliku, ale liczba odwołań wynosi 1

Odnosi się to do konkretnej techniki wdrażania. Są inni.

Zdarza się, że ext2 w Linuksie (od jądra 3.16) używa tej szczególnej techniki. Nie oznacza to jednak, że zawartość dysku przechodzi przez sekwencję [stara lokalizacja] → [obie lokalizacje] → [nowa lokalizacja], ponieważ dwie operacje (dodanie nowej pozycji, usunięcie starej pozycji) nie są atomowe na poziomie sprzętowym : możliwe jest przerwanie jednego z nich, pozostawiając system plików w niespójnym stanie. (Mam nadzieję, że fsck to naprawi.) Ponadto warstwa blokowa może zmieniać kolejność zapisów, więc pierwsza połowa może zostać zapisana na dysku tuż przed awarią, a druga połowa nie zostałaby wykonana.

Liczba referencyjna nigdy nie będzie różna od 1, dopóki system nie ulegnie awarii (patrz wyżej), ale ta gwarancja nie obejmuje awarii systemu.

najpierw usuwa wskaźnik, a następnie kopiuje wskaźnik, więc niespójność polega na tym, że plik ma odniesienie 0

Ponownie odnosi się to do konkretnej techniki implementacji. Nie można zaobserwować wiszącego pliku, jeśli system nie ulegnie awarii, ale jest to możliwa konsekwencja awarii systemu, przynajmniej w niektórych konfiguracjach.


Zgodnie z postem na blogu Aleksandra Larssona , ext2 nie daje gwarancji spójności w przypadku awarii systemu, ale ext3 działa w tym data=orderedtrybie. (Pamiętaj, że ten post na blogu nie dotyczy renamesamego siebie, ale połączenia kombinacji do pliku i wywołania renametego pliku).

Theodore Ts'o, główny autor systemów plików ext2, ext3 i ext4, napisał post na blogu na ten sam temat . Ten post na blogu omawia atomowość (tylko w odniesieniu do środowiska oprogramowania) i trwałość (która jest atomicznością w odniesieniu do awarii oraz gwarancja zaangażowania, tj. Wiedza o tym, że operacja została wykonana). Niestety nie mogę znaleźć informacji o atomowości w odniesieniu do samych awarii. Jednak gwarancje trwałości podane dla ext4 wymagają, że renamejest atomowy. Dokumentacja jądra dla ext4 stwierdza, że ​​ext4 z auto_da_allocopcją (która jest domyślna w nowoczesnych jądrach), a także ext4, zapewnia gwarancję trwałości, writepo której następujerename, co oznacza, że renamejest to atomowe w odniesieniu do awarii sprzętu.

W przypadku Btrfs, a, renamektóra zastępuje istniejący plik, ma gwarancję atomowości w odniesieniu do awarii, ale taka rename, która nie zastępuje pliku, może spowodować, że żaden plik lub oba pliki nie będą istnieć.


Podsumowując, odpowiedź na twoje pytanie jest taka, że ​​nie tylko przenosi plik nie atomowy w odniesieniu do awarii na ext2, ale nawet nie ma gwarancji, że pozostawi plik w spójnym stanie (chociaż awarie, fsckktórych nie można naprawić, są rzadkie) - właściwie nic nie jest, dlatego wymyślono lepsze systemy plików. Ext3, ext4 i btrfs dają ograniczone gwarancje.

Gilles „SO- przestań być zły”
źródło
13

Operacja zmiany nazwy jest bardzo szybka w każdym systemie plików, więc nie jest prawdopodobne, aby została przerwana, ale w klasycznym systemie plików z pewnością może zostać przerwana - jeśli najpierw utworzy łącze docelowe, może pozostawić dwa łącza w pliku - co jest legalne, ale plik uważa, że ma tylko jeden, co może powodować problemy, jeśli plik zostanie później usunięty. Z drugiej strony, jeśli najpierw usunie link źródłowy, plik może zostać utracony. Uruchomienie fsck zwykle wykryje i poprawi oba warunki, chociaż jeśli plik zostanie utracony, zostanie umieszczony w katalogu „lost + found” o dowolnej nazwie, a nie w pożądanej lokalizacji - a jeśli ma dwa łącza, liczba linków po prostu zostać zaktualizowane, więc plik będzie istniał w dwóch lokalizacjach, jeśli system plików obsługuje to.

Jeśli potrzebujesz systemu plików, aby był odporny na awarie zasilania, powinieneś użyć systemu plików kronikowania , takiego jak NTFS, EXT3 lub XFS. Większość współczesnych systemów domyślnie korzysta z systemu plików kronikowania, choć należy pamiętać, że FAT nie jest systemem plików kronikowania, jeśli jest używany do dysków zewnętrznych.

System plików kronikowania korzysta z systemu „podwójnego wpisu” - zapisuje w pliku kroniki fakt, że zamierza go przenieść, a następnie wykonuje ruch. Gdy system plików zostanie sprawdzony przy starcie, jeśli został przerwany, zauważy, że przenoszenie nie zostało ukończone, a następnie powtórz je.

Istnieją dwa rodzaje systemów plików kronikowania - kronikowanie metadanych i kronikowanie pełne. Kronikowanie metadanych oznacza, że ​​nie śledzi zmian w zawartości pliku w systemie kronikowania (więc możesz stracić zawartość, jeśli piszesz do pliku), ale nadal będzie śledzić ważne informacje o systemie plików, takie jak zawartość katalogu , właściwości pliku itp.


Kiedy ludzie mówią, że operacja zmiany nazwy ma charakter atomowy, mają na myśli, że nie można tego zaobserwować w trakcie przejścia przez inny proces w systemie i nie można go w połowie dokończyć, np. Przez przerwanie samego mvpolecenia ^C. Fizyczny proces zapisu do każdego katalogu, w którym przestrzeń dyskowa może znajdować się w bardzo różnych lokalizacjach na dysku, nie może być prawdziwie atomową operacją na poziomie sprzętowym.


Dla kompletności zwrócę uwagę, że istnieją również incydentalne operacje We / Wy związane ze zmianą nazwy oprócz tworzenia nowego łącza w katalogu docelowym i usuwania go w starym - aktualizowanie mtime obu katalogów, ewentualnie przedłużanie rozmiar alokacji katalogu docelowego, zmiana ..linku i liczby linków do katalogów nadrzędnych, jeśli plik jest katalogiem. Nie jestem również pewien, czy dotyczy to samego pliku.

Losowo 832
źródło
Czasopismo nie gwarantuje awarii zasilania z powodu braku atomowości. Myślę, że ext3 i ext4 gwarantują, że renamejest atomowy, ale btrfs nie zgadza się z wiki (zobacz moją odpowiedź). Możliwe jest również zagwarantowanie atomowości bez dziennika (nie znam przykładów dotyczących Linuksa, ale mogą być pewne). Czy masz wiarygodne informacje na temat ext2?
Gilles „SO- przestań być zły”
@Gilles, czy masz jakieś informacje na temat tego, jak można to teoretycznie zagwarantować bez czasopisma? Chodzi mi o to, że na poziomie podstawowym mówimy o synchronizacji zapisów do dwóch różnych plików, aby zagwarantować, że nigdy nie uzyskasz rezultatu, że wykonano tylko jeden z nich.
Random832
Systemy plików o strukturze dziennika zachowują spójność, nie nadpisując używanych bloków. Jest to odpowiednie rozwiązanie dla nośników flash, w których nadpisywanie istniejących danych jest kosztowne. Dziennik nie jest tak naprawdę jak dziennik, ponieważ nic nie jest odtwarzane podczas montowania - choć można powiedzieć, że cały system plików jest dziennikiem (z wyjątkiem tego, że montowanie nigdy nie obejmuje odtwarzania całej rzeczy w pamięci, ponieważ byłoby zbyt wolne). Opis LogFS w Wikipedii stanowi dobry przegląd.
Gilles „SO- przestań być zły”
1

To pytanie zostało zadane w nieco inny sposób na Super User. Strona Wikipedii na temat mvpolecenia również wyjaśnia to całkiem dobrze:

Przenoszenie plików w tym samym systemie plików jest zasadniczo realizowane inaczej niż kopiowanie pliku, a następnie usuwanie oryginału. Na platformach, które nie obsługują zmiany nazwy syscall, nowy link jest dodawany do nowego katalogu, a oryginalny usuwany. Dane pliku nie są dostępne.

Linux ma nazwę syscall i dlatego zmieni nazwę pliku na operację atomową, tj. Nieprzerwaną. Więc nie, system plików nie może stać się niespójny w opisanej sytuacji.

Benjamin B.
źródło
2
czy zmiana nazwy sys nazywa się abstrakcją OS? Ze
względów
Nie, to nie jest abstrakcja systemu operacyjnego, ale pomyślałem, że stwierdzenie „dlatego bardzo mało prawdopodobne jest, aby system plików stał się niespójny ...” spowodowałoby, że sprawy byłyby zbyt skomplikowane. Zgadzam się z tobą.
Benjamin B.,
2
Odpowiedź ta pozostawia mnie zastanawiać, dlaczegorename wywołanie systemowe nie mogą prowadzić do plików będącej w niespójnym stanie, nawet jeśli nie jest to awaria zasilania. Czułem, że to jest sedno pytania @ graphtheory92.
Tanner Swett
1
@ graphtheory92: Jeśli wywołanie systemowe ma charakter atomowy, wcale nie oznacza to, że wynikowa operacja dyskowa (lub seria operacji dyskowych!) również będzie atomowa. ------ Mogę sobie wyobrazić, że przenosząc plik (liczba linków twardych 1) i odcinając zasilanie, połączenie dysku twardego lub awarię jądra w odpowiednim czasie, możesz uzyskać dwa twarde linki (oryginalny i nowy ) do pliku, w którym liczba twardych linków nadal wynosi 1. ------ Myślę, że istnieją dwa podstawowe rozwiązania tego problemu: a) oprogramowanie - kronikowanie FS, które może automatycznie odzyskać z niespójnych stanów. b) Transakcje obsługiwane przez HW.
pabouk
2
Gwarancja atomowości, o której mówisz, dotyczy obserwacji innych procesów. Nie działa, jeśli system ulegnie awarii.
Gilles „SO- przestań być zły”