Czy istnieje sposób tworzenia kopii krów w ZFS?

Staram się tworzyć krowie kopie niektórych plików / katalogów, ale z kilku znanych mi sposobów wszystkie wydają się nieoptymalne.

Na przykład, btrfs może, za pomocą cp --reflink=autoszybkiego generowania krowich kopii plików.

Co próbowałem:

1. Symlinks: Nie dobrze. Zmieniono nazwę pliku, uszkodzony link.
2. Twarde linki: lepsze, ale wciąż nie są dobre. Zmiany w jednym pliku zmienią drugi, i niekoniecznie chcę, aby drugi plik został zmieniony.
3. Utwórz migawkę zestawu danych, a następnie sklonuj migawkę: To może działać, ale nie dobrze. Często nie szukam kopii całego zestawu danych ani kopii, które działałyby jak inny zestaw danych. Są też relacje rodzic / dziecko między klonem / migawką / oryginałem, które, jak rozumiem, są trudne, jeśli nie niemożliwe, do zerwania.
4. Za pomocą zfs send/receivei włączonej deduplikacji replikuj zestaw danych do nowego zestawu danych: Pozwala to uniknąć relacji rodzic / dziecko korzystania z klonu, ale wciąż niepotrzebnie tworzy inny zestaw danych i wciąż cierpi na powolność związaną z plikami, które muszą być odczytane w 100% i bloki odwoływały się ponownie zamiast pisać.
5. Skopiuj pliki i pozwól deduprze wykonać swoje zadanie: Działa to, ale działa wolno, ponieważ pliki muszą być w 100% odczytane, a następnie bloki ponownie odwoływane zamiast pisać.

Powolność wysyłania / odbierania ZFS i fizycznego kopiowania lub rsynchronizacji jest jeszcze bardziej zaostrzona, ponieważ większość rzeczy jest przechowywana w formie skompresowanej i musi zostać zdekompresowana podczas odczytu, a następnie skompresowana przed uruchomieniem deduplikacji w celu odniesienia do duplikatów bloków.

We wszystkich moich badaniach nie udało mi się znaleźć niczego, co przypominałoby prostotę --reflink w btrfs.

Czy istnieje sposób tworzenia kopii krów w ZFS? Czy też „fizyczne” kopiowanie i pozwalanie deduplikacji wykonywać swoją pracę jest jedyną realną opcją?

Myślę, że opcja 3, jak opisano powyżej, jest prawdopodobnie najlepszym wyborem. Największy problem z tym, czego chcesz, to to, że ZFS naprawdę obsługuje tę kopię przy zapisie na poziomie zestawu danych / migawki.

Zdecydowanie sugeruję unikanie deduplikacji, chyba że upewnisz się, że działa ona dobrze w twoim środowisku. Mam osobiste doświadczenie z deduplikacją, która działa świetnie, dopóki nie zostanie wprowadzony jeszcze jeden użytkownik lub sklep VM, a następnie spadnie on z poziomu wydajności i spowoduje wiele problemów. Tylko dlatego, że wygląda na to, że działa świetnie z pierwszymi dziesięcioma użytkownikami, twoja maszyna może się przewrócić, gdy dodasz jedenastego (lub dwunastego, trzynastego, czy cokolwiek innego). Jeśli chcesz pójść tą drogą, upewnij się, że masz środowisko testowe dokładnie naśladujące środowisko produkcyjne i działające dobrze w tym środowisku.

Wróć do opcji 3, musisz skonfigurować określony zestaw danych do przechowywania każdego z drzew systemu plików, którym chcesz zarządzać w ten sposób. Po skonfigurowaniu i początkowym zapełnieniu, weź swoje migawki (po jednym dla każdego zestawu danych, który będzie się nieco różnić) i następnie przenieś je do klonów. Nigdy więcej nie dotykaj oryginalnego zestawu danych.

Tak, to rozwiązanie ma problemy. Nie twierdzę, że tak nie jest, ale biorąc pod uwagę ograniczenia ZFS, jest to prawdopodobnie najlepszy. Znalazłem to odniesienie do kogoś, kto skutecznie używa klonów: http://thegreyblog.blogspot.com/2009/05/sparing-disk-space-with-zfs-clones.html

Nie znam się naprawdę na btrfs, ale jeśli obsługuje on żądane opcje, czy zastanawiałeś się nad utworzeniem osobnego serwera tylko do obsługi tych zestawów danych, używając Linuksa i btrfs na tym serwerze?

Opcja 5 jest najlepsza.

W odniesieniu do nadrzędnych / podrzędnych zestawów danych w opcji 3 możesz promować klon i nie będzie on już potomkiem sklonowanego zestawu danych. Nadal nie zużywa dodatkowych bloków. Edycja: Zauważono, że odwraca to tylko relacje rodzic / dziecko, a nie niszczy.

W odniesieniu do rzeczy kompresowanych / szyfrowanych i spowalniających kopię, jest to całkowicie fałszywe. Twój procesor jest znacznie szybszy niż urządzenie blokujące (nawet jeśli używasz dysków SSD). Na przykład w przypadku liczb przykładowych powiedzmy, że odczyt bloku zajmuje 10 sekund, ale jego dekompresja zajmuje tylko jedną sekundę, a jego odszyfrowanie - 2 sekundy. Blok 1 zostaje odczytany w 10 sekund i przesłany do procesora. Procesor zaczyna dekompresować i deszyfrować, gdy dysk zaczyna czytać blok 2. Procesor zakończy zadanie w ciągu 3 sekund, a następnie spędzi następne 7 sekund na oczekiwaniu na dysku. Tymczasem dysk spędził dokładnie tyle samo czasu czytając te dwa bloki (20 sekund) niezależnie od tego, czy bloki są skompresowane, czy nie.

Podobnie podczas pisania opóźnia się tylko pierwszy blok. CPU kompresuje / szyfruje blok 1 i wysyła go na dysk. Gdy dysk zapisuje blok 1, procesor zacznie kompresować / szyfrować kolejne bloki. Procesor będzie przeżuwał bloki znacznie szybciej niż dysk może je zapisać, więc nie stanowi to problemu. (Tak, to bardziej skomplikowane niż to, ale to jest sedno).

Przepraszam za zbyt długie wyjaśnienie drobnego punktu w twoim pytaniu, ale chciałem wyjaśnić to nieporozumienie.