ZFS: ponownie kompresuj istniejące pliki po zmianie algorytmu kompresji


14

Mam pulę, która została utworzona w 2011 roku, przy użyciu lzjb compressioni dopiero kilka lat później aktualizacja pozwoliła mi ustawić kompresję na lz4. Szacuję, że co najmniej 20% zawartości (według miejsca) w tablicy zostało utworzone przed 2013 rokiem, co oznacza, że ​​nadal jest ona kompresowana przy użyciu lzjb.

Mogę wymyślić kilka opcji, aby to naprawić i odzyskać (trochę) miejsca:

  1. Utwórz kopię zapasową i przywróć do nowej puli. Niezbyt praktyczne, ponieważ nie mam wystarczającej ilości nadmiarowego miejsca do przechowywania kopii tymczasowej. Przywracanie wymagałoby również, aby pula była offline przez kilka godzin.

  2. Napisz skrypt, aby ponownie skopiować dowolny plik ze znacznikiem czasu starszym niż 2013. Potencjalnie ryzykowny, szczególnie jeśli zadławi się spacjami lub innymi znakami specjalnymi i skończy się mangowaniem oryginalnej nazwy.

Czy jest jakiś sposób, aby ZFS ponownie skompresował jakiekolwiek starsze bloki przy użyciu bieżącego algorytmu kompresji? Coś jak peeling, ale leczący kompresję.

Powiązane pytanie: czy jest jakiś sposób, aby zobaczyć użycie każdego rodzaju algorytmu kompresji? zdb pokazuje tylko ogólne statystyki kompresji, zamiast rozkładać je na poszczególne algorytmy.


2
Jestem pewien, że wymieniłeś tylko dwie opcje. Zobacz także dyskusję w numerze 3013, aby dowiedzieć się, dlaczego ta funkcjonalność nie istnieje i możesz w ogóle tego nie chcieć.
Michael Hampton

2
lz4 jest podobno o 10% lepszy w kompresji niż lzjb. Jeśli 20% twoich danych można skompresować o 10% lepiej, zyskasz co najwyżej 2% więcej wolnego miejsca. Czy warto?
rura

1
Jeśli napiszesz skrypt powłoki, aby wykonać kopię, dodaj export LC_ALL=Cna początku skryptu, a wszystkie znaki specjalne spoza ASCII w nazwach plików pozostaną nienaruszone. Utrzymywanie nienaruszonych białych znaków i myślników jest trudniejsze, użyj podwójnych cudzysłowów i --, np cp -- "$SOURCE" "$TARGET".
pkt

4
@pipe Space to jedna (bardzo) niewielka zaleta, ale bardziej interesuje mnie szybkość dekompresji. Z podręcznika FreeBSD o funkcjach zpool: „Zazwyczaj kompresja lz4 jest o około 50% szybsza w przypadku danych podlegających kompresji i o 200% szybsza w przypadku danych nieściśliwych niż lzjb. Jest również o około 80% szybsza w przypadku dekompresji, a jednocześnie zapewnia około 10% lepszy współczynnik kompresji. „
rowan194

@pts Nie nazwałbym przestrzegania podstawowych zasad programowania powłoki (podwójne cudzysłowy wokół zmiennych lub używanie --) „trudniejszym”. Jest to na przykład tak ważne, jak unikanie wstrzykiwania SQL.
glglgl

Odpowiedzi:


14

Musisz skopiować dane (pełne lub częściowe) lub ZFS wysyła / odbiera dane do nowej puli lub systemu plików ZFS.

Nie ma żadnych innych opcji.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.