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

linux filesystems ext4 xfs rboyer
źródło

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.

John Westlund
źródło
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 .

psusi
źródło
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.

Bratchley
źródło
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).
sourcejedi
źródło