Kompresja BTRFS została zaprojektowana tak, aby efektywnie pasowała do całego projektu CopyOnWrite. Używam obu razem i mogę potwierdzić, że nie sprawili mi żadnych problemów.
Jak działają razem: dane pliku w BTRFS są przechowywane w zakresach, które są długimi sekcjami bloków sekwencyjnych. Wszystkie bloki mają ten sam rozmiar, zwykle 4K, a zakresy różnią się rozmiarem o rzeczywisty plik i wolne miejsce. Na przykład, jeśli masz plik o rozmiarze 1M, może to być jeden zakres 256 bloków lub dwa zakresy 113 bloków i 143 bloki. Lub dziesiątki różnych rozmiarów w dowolnej kombinacji. Jeśli zmienisz jeden bajt w środku pliku, skopiuje on zakres zawierający zmieniony bajt. Może stworzyć zupełnie nowy zasięg lub podzielić ten zakres na trzy: dwa po obu stronach zmienionego bajtu, które wskazują na oryginalne niezmienione bloki i jeden na nowe dane.
Zgodnie z wiki btrfs sposób kompresji jest taki, że kompresja odbywa się na zasadzie blok po bloku (rozmiar 4K), w grupach bloków o rozmiarze do 128K. Plik nie jest więc przechowywany w jednym długim strumieniu skompresowanym; jest przechowywany jako sekcje skompresowanych porcji. Po zmianie jednego bajtu w środku pliku większość pliku w skompresowanych blokach jest nietknięta. Skompresowany blok, a być może kilka bloków wokół niego, do 128K, jest kopiowany i ponownie kompresowany, a lista rozszerzeń jest aktualizowana, jak każda inna metoda COW. W dzisiejszych systemach kompresja 4K lub 128K jest trywialna, więc nie ma obniżenia wydajności.
Ponieważ dostosowanie mapy zasięgu pliku jest normalną częścią funkcjonalności COW, nie ma znaczącej różnicy, czy niektóre bloki 4K są skompresowane lub nieskompresowane. (W rzeczywistości w BTRFS plik może zawierać dowolną kombinację nieskompresowanych bloków, bloków skompresowanych ZLIB i bloków skompresowanych LZO, w zależności od tego, która opcja kompresji była aktywna w systemie plików, gdy części pliku zostały zaktualizowane).
Nie przeprowadziłem wyczerpujących badań ani pomiarów; „po prostu działa”, tak jak się tego spodziewałem.
