Czy wymusić sumę kontrolną aktualizacji na ZFS?

Niedawno zmienił checksumwłasności na jednej z moich non-powielający systemów plików ZFS do sha256z on(fletcher4), aby lepiej wspierać wysyłając powielanych parowych replikacji, tak jak w tym poleceniu zfs send -DR -I _starting-snaphot_ _ending-snapshot_.

Jednak strona zfs ma to do powiedzenia na temat send -D:

Ta flaga może być używana niezależnie od właściwości deduplikacji zestawu danych, ale wydajność będzie znacznie lepsza, jeśli system plików użyje sumy kontrolnej obsługującej deduplikację (np. Sha256).

Strona ZFS podaje również o tej checksumwłaściwości:

Zmiana tej właściwości wpływa tylko na nowo zapisane dane.

Nie chcę ufać fletcher4. Kompromis polega na tym, że w przeciwieństwie do SHA256, fletcher4 nie jest pseudolosową funkcją skrótu i dlatego nie można ufać, że się nie zderzy. Dlatego nadaje się tylko do deduplikacji w połączeniu z opcją „Sprawdź”, która wykrywa i rozwiązuje kolizje mieszające.

Jak mogę zaktualizować sumy kontrolne systemu plików, najlepiej bez przerywania działania systemu?

zfs zfsonlinux

— 84104
źródło

Aby zmienić właściwości (kompresję, deduplikację lub sumę kontrolną) już zapisanych danych, podejście zfs polega na przepuszczaniu danych przez zfs send | zfs receivesekwencję. Oczywiście nie musisz wyłączać systemu w trybie offline, ale będziesz tego potrzebować

wystarczającą ilość zasobów w twoim zpool / w systemie, aby pomieścić dwie deduplikowane kopie danego zestawu danych
przestój dla zestawu danych, ponieważ albo trzeba go zniszczyć, albo zmienić jego nazwę w procedurze
wystarczająco dużo czasu i cierpliwości do zakończenia operacji

Ponieważ już używasz deduplikacji dla zpool, uruchomienie zfs send | zfs receivez miejscem docelowym w tej samej puli, co źródło, zajmowałoby tylko miejsce potrzebne na nowo napisane bloki metadanych. Ale przygotuj się na kopię - deduplikacja może być strasznie powolna, szczególnie jeśli nie masz wystarczającej ilości pamięci RAM, aby pomieścić całą tabelę deduplikacji w pamięci RAM.

Oczywiście konieczne byłoby zaprzestanie wszystkich operacji zapisu, aby utworzyć ostateczną, autorytatywną kopię zestawu danych, ale można zminimalizować czas przestoju, kopiując najpierw migawkę, zatrzymując wszystkie zapisy i wykonując operacje przyrostowe zfs send -i | zfs receivejako ostatni krok.

— the-wabbit
źródło

Nie jest dla mnie jasne, czy zfs receiveaktualizuje metadane systemu plików. Wydaje mi się, że byłoby znacznie szybciej, gdyby po prostu wziął metadane w obecnej postaci. Może to jednak być niemożliwe ze względu na blok sumy kontrolnej, a nie na poziomie pliku. W takim przypadku zfs send | zfs receivestanowiłoby akceptowalną podstawę dla rozwiązania.

— 84104

zfs send | zfs recv skutecznie zmieni wszystkie metadane (wybór kompresji, wybór sumy kontrolnej, wybór deduplikacji). zfs send tworzy obiekt, który następnie wchłaniasz za pomocą zfs recv, który wypisuje go tak, jakby to były wszystkie nowe dane. Jednak - myślę, że możesz mieć błędne przekonanie na temat zfs send | recv w odniesieniu do deduplikacji. zfs send -D próbuje deduplikować dane / w samym strumieniu /, nie utrzymując istniejącej deduplikacji danych ze źródłowego zestawu danych. Dlatego nie ma wymogu, aby strona odzyskiwania miała również włączoną deduplikację dla docelowego zestawu danych.

— Nex7

W celu dalszego wyjaśnienia - obecnie nie ma sposobu, aby ZFs wysłał | dane deduplikowane | recv w taki sposób, że wszystko, co przechodzi przez drut, to pojedyncza kopia danych deduplikowanych i powiązane pozycje tabeli deduplikacji. Nawet jeśli źródło i cel są zsynchronizowane, a nie wysyłasz nic więcej niż przyrostowy obraz stanu. ZFS nadal balonuje wysyłane dane do pełnego rozmiaru, jeśli dane w nim zawarte są niemożliwe do deduplikacji / w ramach samego strumienia /. Możesz mieć dane, które łatwo można deduplikować w POOL DDT, ale jako mały obiekt wysyłania nie można deduplikować.

— Nex7