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.
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?