Zaproponowano ulepszenia Btrfs do włączenia do jądra Linuksa 6.2, aby naprawić problem „dziury zapisu” w implementacji RAID 5/6. Istota problemu sprowadza się do tego, że jeśli podczas nagrywania nastąpiła awaria, początkowo nie można zrozumieć, w którym bloku, na którym z urządzeń RAID zapisano poprawnie, a w którym nagrywanie nie zostało zakończone. Jeśli w tej sytuacji spróbujesz odbudować macierz RAID, bloki odpowiadające blokom gwarantowanym mogą zostać uszkodzone, ponieważ stan bloków RAID nie jest zsynchronizowany. Ten problem występuje w każdej macierzy RAID1/5/6, w której nie podjęto specjalnych środków w celu zwalczania tego efektu.
W implementacji RAID, takiej jak RAID1 w btrfs, problem ten rozwiązuje się poprzez użycie sum kontrolnych w obu kopiach. W przypadku niezgodności dane są po prostu przywracane z drugiej kopii. To podejście działa również, jeśli jakieś urządzenie zamiast całkowitej awarii zacznie podawać nieprawidłowe dane.
Jednakże w przypadku RAID5/6 system plików nie przechowuje sum kontrolnych bloków parzystości: w normalnej sytuacji poprawność bloków sprawdzana jest przez to, że wszystkie są wyposażone w sumę kontrolną, a blok parzystości może zostać odtworzone z danych. Jednak w przypadku zapisu częściowego takie podejście może nie działać w niektórych sytuacjach. W takim przypadku podczas przywracania tablicy możliwe jest, że bloki objęte niekompletnym rekordem zostaną przywrócone niepoprawnie.
W przypadku btrfs problem ten jest najbardziej istotny, jeśli tworzony zapis jest mniejszy niż pasek. W takim przypadku system plików musi wykonać operację odczytu, modyfikacji i zapisu (RMW). Jeśli napotka bloki zapisu w toku, wówczas operacja RMW może spowodować uszkodzenia, które nie zostaną wykryte, niezależnie od sum kontrolnych. Twórcy wprowadzili zmiany, w których operacja RMW sprawdza sumę kontrolną bloków przed wykonaniem tej operacji, a w razie potrzeby odzyskiwanie danych wykonuje również sprawdzanie sumy kontrolnej po zapisie. Niestety w sytuacji zapisywania niekompletnego paska (RMW) prowadzi to do dodatkowego narzutu przy obliczaniu sum kontrolnych, ale znacznie zwiększa niezawodność. W przypadku RAID6 taka logika nie jest jeszcze gotowa, jednak w przypadku takiej awarii w RAID6 konieczne jest, aby zapis nie powiódł się na 2 urządzeniach jednocześnie, co jest mniej prawdopodobne.
Dodatkowo możemy odnotować zalecenia twórców dotyczące stosowania RAID5/6, których istotą jest to, że w Btrfs profil przechowywania metadanych i danych może się różnić. W takim przypadku możesz użyć profilu RAID1 (lustrzany) lub nawet RAID1C3 (3 kopie) dla metadanych oraz RAID5 lub RAID6 dla danych. Zapewnia to z jednej strony niezawodną ochronę metadanych i brak „dziury zapisu”, z drugiej zaś bardziej efektywne wykorzystanie przestrzeni, typowe dla RAID5/6. Pozwala to uniknąć uszkodzenia metadanych i umożliwia naprawienie uszkodzeń danych.
Można również zauważyć, że dla dysków SSD w Btrfs w jądrze 6.2 domyślnie będzie aktywowane asynchroniczne wykonanie operacji „discard” (oznaczanie zwolnionych bloków, których nie można już fizycznie przechowywać). Zaletą tego trybu jest wysoka wydajność ze względu na efektywne grupowanie operacji „odrzuć” w kolejce i dalsze przetwarzanie kolejki przez procedurę obsługi w tle, dzięki czemu normalne operacje FS nie spowalniają, jak ma to miejsce w przypadku synchronicznych „ odrzuć” w miarę zwalniania bloków, a dysk SSD może podejmować lepsze decyzje. Z drugiej strony nie będziesz już musiał używać narzędzi takich jak fstrim, ponieważ wszystkie dostępne bloki zostaną usunięte w FS bez konieczności dodatkowego skanowania i bez spowalniania operacji.
Źródło: opennet.ru