W jądrze Linux 6.2 wprowadzone zostały poprawki Btrfs, dotyczące problemu związanego z 'dziurą zapisu' w realizacji RAID 5/6. Problematyka ta polega na tym, że w przypadku awarii podczas zapisu, początkowo niemożliwe jest określenie, który blok został poprawnie zapisany na którym urządzeniu RAID, a który nie został ukończony. Przy próbie odbudowy RAID w takiej sytuacji może dojść do zniszczenia bloków odpowiadających niezapisanym blokom, ponieważ stan bloków RAID jest niesynchronizowany. Problem ten występuje w każdym macierzy RAID1/5/6, gdzie nie zastosowano specjalnych środków przeciwdziałających temu efektowi.
W implementacji RAID, takiej jak RAID1 w btrfs, problem ten rozwiązany jest poprzez użycie sum kontrolnych w obu kopiach; w przypadku rozbieżności dane po prostu odzyskuje się z drugiej kopii. To podejście działa również, gdy jakieś urządzenie zaczyna zwracać niepoprawne dane zamiast całkowitego uszkodzenia.
Jednak w przypadku RAID5/6 system plików nie przechowuje sum kontrolnych dla bloków parzystości: w normalnej sytuacji poprawność bloków sprawdzana jest przez fakt, że wszystkie są zaopatrzone w sumę kontrolną, a blok parzystości można odtworzyć z danych. Jednak w przypadku częściowego zapisu podejście to w określonych sytuacjach może nie zadziałać. W takim przypadku przy odbudowie macierzy nie można wykluczyć, że bloki, które znalazły się pod niedokończonym zapisem, zostaną niepoprawnie odtworzone.
W przypadku btrfs ten problem jest szczególnie istotny, gdy zapisywana wartość jest mniejsza niż rozmiar stripe'a. W takim przypadku system plików musi wykonać operację odczytu-modyfikacji-zapisu (read-modify-write, RMW). Jeśli podczas tego procesu napotka bloki z niekompletnym zapisem, operacja RMW może spowodować uszkodzenia, które nie zostaną wykryte, pomimo zastosowania sum kontrolnych. Twórcy wprowadzili zmiany, które sprawiają, że operacja RMW weryfikuje sumy kontrolne bloków przed jej wykonaniem, a w przypadku potrzeby odzyskania danych przeprowadza także weryfikację sum kontrolnych po zapisie. Niestety, w sytuacji z zapisem niepełnego stripe'a (RMW) wiąże się to z dodatkowymi kosztami obliczeniowymi dla sum kontrolnych, jednak znacząco zwiększa niezawodność. Dla RAID6 taka logika nie jest jeszcze gotowa, niemniej jednak w przypadku awarii w RAID6 konieczne jest, aby zapis nie powiódł się na dwóch urządzeniach jednocześnie, co jest mniej prawdopodobne.
Dodatkowo warto zwrócić uwagę na zalecenia dotyczące używania RAID5/6 od twórców, które polegają na tym, że w Btrfs profil przechowywania metadanych i danych może się różnić. Można zastosować profil RAID1 (lustrzany) lub nawet RAID1C3 (3 kopie) dla metadanych, a dla danych RAID5 lub RAID6. Dzięki temu zapewnia się niezawodną ochronę metadanych i brak 'write hole' z jednej strony oraz bardziej efektywne wykorzystanie przestrzeni charakterystyczne dla RAID5/6 z drugiej. Pozwala to unikać uszkodzeń metadanych, a uszkodzone dane mogą być naprawiane.
Warto również zaznaczyć, że dla SSD w Btrfs w jądrze 6.2 domyślnie włączone zostanie asynchroniczne wykonywanie operacji „discard” (oznaczanie zwolnionych bloków, które nie muszą już być fizycznie przechowywane). Zaletą tego trybu jest wysoka wydajność dzięki efektywnemu grupowaniu operacji „discard” w kolejce, a następnie przetwarzaniu kolejki przez proces w tle, przez co normalne operacje systemu plików nie są spowolnione, jak ma to miejsce w przypadku synchronicznego „discard” w miarę zwalniania bloków, a SSD może podejmować bardziej korzystne decyzje. Z drugiej strony, nie będzie już konieczności korzystania z narzędzi takich jak fstrim, ponieważ wszystkie dostępne bloki będą oczyszczane w systemie plików bez potrzeby dodatkowego skanowania i bez spowolnienia operacji.
Źródło: opennet.ru
