Czy BTRFS gwarantuje spójność danych w przypadku awarii zasilania?

Jak podaje wyłącznie ZFS ,ZFS jest uważany za niewrażliwy ZFS akceptuje fakt, że może być podatny na awarie zasilania.

Nie mogłem znaleźć takiego oświadczenia dla BTRFS. Czy jest (lub zaprojektowany / ma być) trwały między przerwami w dostawie prądu?

Zadałem pytanie na #btrfs IRC, powiedzieli should be ok if your hw isn't "buggy"gdzie nie znaczy „buggy” your hw has correct flush/barrier semantics.

TL; DR: Oznacza to, że btrfs jest chroniony przed uszkodzeniem danych spowodowanym utratą zasilania w podobny sposób jak ZFS.

Oto dlaczego: Ogólna idea ZFS i btrfs jest podobna. Oba wykorzystują drzewa Merkle jako strukturę danych . Zapisy mogą wymagać aktualizacji wielu bloków na dyskach. System plików obsługuje to, zapisując nowe dane w pustych blokach (nawet jeśli istniejący plik jest modyfikowany, więc nie trzeba modyfikować bloków odzwierciedlających stary stan) i budując nowe zaktualizowane drzewo. Gdy wszystkie ciężkie podnoszenie zostanie wykonane, a dane + zaktualizowane drzewo zostaną zapisane na dysku, wskaźnik głowy zostanie zaktualizowany do nowego drzewa, dzięki czemu zmiana będzie widoczna.

Oto, jak mają się zachowywać zapisy do pliku:

1. Zapisuj dane do wolnych bloków na dysku.
2. Zrób kopię drzewa Merkle *, zaktualizuj go zgodnie ze zmianami zapisanymi w (1).
3. Poproś sprzęt o przepłukanie danych na dysk - sprzęt zapisuje wszystkie oczekujące dane.
4. Zaktualizuj wskaźnik głowy do nowego drzewa Merkle.
5. Darmowe stare bloki, które nie są już potrzebne.

W przypadku utraty zasilania po (4) transakcja jest zakończona. W przypadku utraty zasilania w krokach (1) do (3) system plików powróci do starego stanu (dane zapisane w kroku (1) zostaną utracone, ale system plików będzie spójny). Pamiętaj, że nie ma potrzeby sprawdzania błędów systemu plików, co oznacza, że ​​system plików jest dostępny natychmiast, co jest dużą zaletą (sprawdzanie dużych systemów plików może trwać bardzo długo!).

Oto przykład, jak coś może pójść nie tak z „buggy” sprzętem:

1. Zapisuj dane do wolnych bloków na dysku.
2. Zrób kopię drzewa Merkle *, zaktualizuj go zgodnie ze zmianami zapisanymi w (1).
3. Poproś sprzęt o wypłukanie danych na dysk - sprzęt potwierdza zakończenie, ale nie jest całkowicie opróżniany (np. Dane mogą pozostać w pamięci podręcznej zapisu).
4. Zaktualizuj wskaźnik głowy do nowego drzewa Merkle. Dane te są zapisywane na dysku przed innymi oczekującymi danymi (np. Ponieważ głowa dysku znajduje się we właściwej lokalizacji).
5. Dane zapisane w krokach (1) i (2) zostają zapisane na dysk.
6. Darmowe stare bloki, które nie są już potrzebne.

System plików stanie się niespójny, jeśli nastąpi utrata zasilania między (4) a (5) lub podczas wykonywania kroku (5). W konsekwencji drzewo Merkle i / lub dane mogą być tylko częściowo zapisane, powodując niespójność systemu plików.

W praktyce należy zachować szczególną ostrożność podczas korzystania z kontrolerów RAID . Zwykle wyłączają pamięci podręczne zapisu na dysku i zamiast tego używają własnej pamięci podręcznej zapisu. Istnieją dwa typowe sposoby, aby coś poszło nie tak:

• Pamięć podręczna kontrolera RAID to pamięć RAM. Jeśli nie jest wspierany przez baterię lub podobną technologię, możesz stracić znaczną ilość danych.
• Niektóre dyski nie wyłączają swoich pamięci podręcznych zapisu, gdy zostanie o to poproszony . Jest to bardziej prawdopodobne w przypadku tanich dysków stacjonarnych niż dysków serwerowych zaprojektowanych dla macierzy RAID.

* Upraszczam tutaj. W rzeczywistości nie jest konieczne kopiowanie całego drzewa. Należy dodać tylko te części, które uległy zmianie - pozostałe części można współdzielić między starym i nowym drzewem .