Jakie operacje na metadanych systemu plików są faktycznie kronikowane w ext4 i xfs?


9

Nie mogę znaleźć prostej, prostej odpowiedzi na temat tego, które operacje metadanych systemu plików są rzeczywiście utrwalane w dziennikach systemu plików ext4 & xfs. Zauważ, że nie pytam o to, co POSIX deklaruje jako „atomowy”. Bardziej martwię się tym, który podzbiór operacji atomowego systemu plików jest faktycznie trwały dzięki temu, że działa z włączonym dziennikiem bez konieczności ciągłego pochylania się do tyłu i przez fsync(2)cały czas.

Operacje, których jestem pewien, liczą się:

  • creat(2)
  • link(2)
  • unlink(2)
  • rename(2)
  • mkdir(2)
  • rmdir(2)

Operacje, których nie jestem całkowicie pewien:

  • symlink(2)

symlink(2)Przypadek jest najbardziej niepokojące, ponieważ nie wydaje się być każdy prosty sposób fsync(2)lub fdatasync(2)bazowe Bloki danych, które przechowują zawartość dowiązania symbolicznego. Świadomość, że dziennik się tym zajmuje, byłaby dla mnie ulgą.

Odpowiedzi:


1

Ze względu na wydajność, ext4 domyślnie zapisuje tylko metadane systemu plików przez dziennik.

Wierzę, że XFS rejestruje również wszystkie transakcje metadanych, chyba że poprawiłeś system plików.


Tak, ale czym konkretnie są „metadane”? Bloki katalogu: na pewno. Same i-węzły: tak. Dowiązania symboliczne z celem wystarczająco małym, aby zmieściły się w samym i-węźle: prawdopodobnie? Dowiązania symboliczne, w których cel rozlewa się na bloki pomocnicze: ??????

link by pomógł
asdmin

1

Bardziej martwię się tym, który podzbiór operacji atomowego systemu plików jest faktycznie trwały dzięki temu, że działa z włączonym dziennikiem bez konieczności ciągłego pochylania się do tyłu i fsync (2) przez cały czas.

Żaden. Jeśli chcesz mieć pewność, że zmiany utrzymują się po awarii, musisz fsync, kropka. Kronikowanie gwarantuje tylko, że w przypadku awarii żadna z wymienionych operacji nie zostanie wykonana w połowie .


Wiem, że jeśli mnie to obchodzi, muszę fsynchronizować pliki i katalogi, aby mieć pewność, że bloki uderzyły w wirującą rdzę, ale nie znalazłem żadnej metody, która pozwoliłaby mi fsynchronizować bloki, które cofają dowiązanie symboliczne, jeśli wyleje się z i-węzeł. W tym momencie moim jedynym wyjściem jest poleganie na dzienniku lub nigdy więcej nie używać dowiązań symbolicznych do niczego, co ma znaczenie.
rboyer

@naelyn, fsync () opróżni wszystkie bloki związane z plikiem, w tym nie szybkie łącze symboliczne.
psusi

1
jak mogę otworzyć odpowiedni deskryptor pliku do użycia w fsync, który opróżniłby nie-szybkie bloki dowiązania symbolicznego?
rboyer

@naelyn, o tak ... dobra uwaga ... może trzeba zapytać o ten na liście mailingowej linux-fsdevel ... z twardymi linkami Wierzę, że otwierasz i synchronizujesz katalog zawierający go, może linki symboliczne działają tak samo?
psusi

0

Wiesz, że dziennik ext4 działa według numeru bloku, a nie operacji, prawda? „Metadane” to cokolwiek innego niż rzeczywiste bloki danych dla danego i-węzła, niezależnie od tego, jakiej operacji użyto do zmodyfikowania danego bloku.


0

Wygląda na to, że xfstests twierdzi, że fsync () w katalogu powinien zachować wszelkie zawarte w nim dowiązania symboliczne.

Nie zweryfikowałem tego. Możliwe, że coś przeoczyłem.

xfstests jest używany przez wielu programistów systemów plików Linux. Ten test znajduje się w katalogu „ogólnym”. Oznacza to, że powinien mieć zastosowanie do wszystkich systemów plików Linux. (Lub przynajmniej wszystkie systemy plików urządzeń blokowych. Test działa przy użyciu specjalnego wirtualnego urządzenia blokowego).

https://github.com/kdave/xfstests/blob/master/tests/generic/348

# Test creating a symlink, fsync its parent directory, power fail and mount
# again the filesystem. After these steps the symlink should exist and its
# content must match what we specified when we created it (must not be empty
# or point to something else).
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.