Praktyczne ograniczenie liczby migawek btrfs?


23

Zastanawiam się nad użyciem btrfs na moim dysku danych, aby móc używać snappera lub czegoś takiego jak snapper, aby robić migawki oparte na czasie. Wierzę, że pozwoli mi to przeglądać stare wersje moich danych. Byłoby to dodatkiem do mojej bieżącej kopii zapasowej poza witryną, ponieważ awaria dysku wymazałaby dane i migawki.

Z mojego zrozumienia, migawki btrfs nie zajmują dużo miejsca (metadane i bloki, które uległy zmianie, plus może trochę narzutu), więc przestrzeń nie wydaje się być ograniczeniem.

Jeśli mam milion migawek (np. Migawka co minutę przez dwa lata), czy spowodowałoby to spustoszenie, zakładając, że mam wystarczającą ilość miejsca na dysku na dane, zmienione dane i metadane?

Jeśli istnieje praktyczny limit liczby migawek, czy zależy to od liczby plików i / lub rozmiaru plików?

Odpowiedzi:


16

Jako osoba korzystająca z btrfssystemu plików od Arch Linuxprawie 2lat mogę śmiało powiedzieć, że nie wydaje się, aby istniał praktyczny limit liczby migawek, które można łatwo uzyskać. Istnieją jednak pewne zastrzeżenia. btrfssystem plików może prowadzić do fragmentacji. Dlatego zaleca się korzystanie z wbudowanej funkcji defragmentacji online btrfs. Ponadto można dobrze wykorzystać btrfsfunkcję kompresji. Te środki powinny rozwiązać większość problemów z wydajnością, które rozsądnie mogłyby powstać na rozsądnie przyzwoitym komputerze w wyniku tworzenia wielu migawek.

Jak btrfszapewne wiesz, podobjętości traktuje podwoluminy jak systemy plików, dlatego liczba migawek jest rzeczywiście ograniczona: mianowicie przez rozmiar plików. Według btrfswiki maksymalny rozmiar pliku, jaki można osiągnąć, to 2^64 byte == 16 EiB[1] .

Oprócz tych ograniczeń, potencjalnie zawsze mogą pojawić się problemy, gdy zabraknie miejsca bez natychmiastowego rozpoznania, ponieważ sprawdzanie wolnego miejsca w btrfssystemach plików może czasami być trudne, tj. Bez możliwości rozróżnienia różnych metod pomiaru wolnego miejsca w btrfssystemie plików łatwo użyć śledzenia, ile faktycznie pozostało miejsca. Jednym z możliwych sposobów uniknięcia tego scenariusza jest wykorzystanie przydziału. Zapewnia to, że użytkownicy (lub użytkownik, jeśli jest tylko jeden), mogą używać tylko określonej ilości miejsca. Ta koncepcja jest omawiana bardzo sprawnie tutaj i tutaj .

Ostatnie ostrzeżenie: nie jestem ekspertem od btrfssystemów plików i czytam o tych rzeczach tylko wtedy, gdy miałem to samo pytanie jakiś czas temu. Co więcej, zawsze istnieje problem, który btrfsjest „szybko zmieniającym się celem” (ładnie brzmi kradzież ze strony Arch Linuxwiki, jak sądzę), więc rzeczy mogą się zmienić.


1
Jestem jednym z tych wcześniejszych użytkowników, a to jest huk.
mikeserv

Tak, prawie wskakuj :)
Mark K Cowan

1
Powinieneś spróbować pozostać poniżej 100 migawek na jednym woluminie BTRFS. W przeciwnym razie mogą wystąpić problemy z wydajnością, zwłaszcza podczas usuwania migawek. Tworzenie migawek jest tanie, ale ich usuwanie nie jest. Należy również pamiętać, że zalecenie przeprowadzenia defragmentacji wraz z użyciem migawek wyeliminuje wydajność miejsca migawek. Defragging przerywa odnośniki i zwielokrotnia wykorzystane miejsce.
MountainX dla Moniki Cellio

@ MountainX możesz rozwinąć tę kwestię w odpowiedzi. 100 migawek na woluminie to nie raz w tygodniu przez dwa lata.
StrongBad

@StrongBad - Otrzymałem te informacje z listy mailingowej BTRFS w odpowiedzi na problem. Wszyscy zgodzili się, że złym pomysłem jest posiadanie wielu setek lub tysięcy migawek. Aby uzyskać bardziej techniczną odpowiedź, musisz zapytać na liście mailingowej BTRFS.
MountainX dla Moniki Cellio

5

Chociaż technicznie nie ma ograniczenia liczby migawek, zapytałem na liście mailingowej BTRFS :

(Praktyczna) odpowiedź zależy w pewnym stopniu od tego, jak korzystasz z btrfs.

Btrfs ma problemy ze skalowaniem z powodu zbyt wielu migawek (lub w rzeczywistości używa migawek reflinków, deduplikacja za pomocą reflinków może wywoływać te same problemy ze skalowaniem), a jedna lub dwie podwójne cyfry migawek na migawkowe podwolumny pozostają silną rekomendacją z tego powodu.

Ale problemy ze skalowaniem wpływają przede wszystkim na same polecenia konserwacyjne btrfs, równoważenie, sprawdzanie, usuwanie objętości podrzędnych. Podczas gdy miliony migawek na przykład skutecznie utrudniają równowagę (będzie to w pewnym sensie działaniem, ale może potrwać miesiące), normalne operacje na systemie plików, takie jak czytanie i zapisywanie plików, nie mają wpływu, z wyjątkiem tego, że fragmentacja staje się problemem ( systemy plików krów, takie jak btrfs, są odnotowywane w celu fragmentacji, chyba że zostaną podjęte kroki takie jak defragmentacja w celu jej zmniejszenia).

Wygląda na to, że używanie migawek jako archiwalnej kopii zapasowej podobnej do wehikułu czasu / migawki nie jest dobrym pomysłem.


Time Machine nie jest archiwalną kopią zapasową, jest kopią zapasową. Nie podzielam twojego wniosku. Używanie migawek btrfs może być bardzo dobrym pomysłem dla Time Machine, takich jak kopie zapasowe (ponieważ jądro Linuksa nie jest w stanie połączyć katalogu, co powoduje odtworzenie pełnej struktury katalogów dla każdej przystawki, co może powodować znaczne zużycie miejsca na dysku). W przypadku kopii zapasowej na jednym urządzeniu do tworzenia kopii zapasowych, bez potrzeby dodawania dodatkowych urządzeń, uruchomienie polecenia balance nie ma nawet sensu. Odpowiedź listy btrfs również próbuje to wyjaśnić.
Pro Backup

@ProBackup odpowiedź na liście btrfs mówi: utrzymuj liczbę migawek od pojedynczych do małych cyfr wątpliwych, czego tak naprawdę nie robi domyślny arch dla snappera . Podczas gdy btrfs-balance nie jest potrzebny do prostej konfiguracji, wielu użytkowników podoba się pomysł btrfs-check, nawet jeśli nigdy go nie potrzebują, a usuwanie podwoluminów wydaje się krytyczne, jeśli chcesz obracać podwolumeny tak, jak robi to Snapper.
StrongBad

Archiwizacja kopii zapasowej @ProBackup prawdopodobnie nie jest właściwym terminem dla Time Machine. Wygląda na to, że wehikuł czasu jest czymś więcej niż tylko przyrostową kopią zapasową, ale nie czułem się dobrze nazywać go kopią zapasową opartą na migawce, taką jak snapper lub rsnapshot, ale może to byłoby lepsze. Cieszę się, że możesz edytować ten termin, ponieważ brzmi to tak, jakbyś dużo wiedział o tej dziedzinie.
StrongBad

Z tego, co przeczytałem na stronie głównej snappera, snapper nie jest narzędziem do tworzenia kopii zapasowych. Pomimo tego, że Lucjan może cofnąć się w czasie, nie oznacza to, że jest jak wehikuł czasu. Istotna różnica polega na tym, że Time Machine przechowuje kopie wszystkich danych na osobnym nośniku, gdzie Snapper może nawet nie utworzyć kopii.
Pro Backup

@ProBackup wreszcie, proszę napisać odpowiedź i wyjaśnić, dlaczego moje wnioski na temat odpowiedzi na liście mailingowej są błędne. W ten sposób możemy zobaczyć, jak czuje się społeczność.
StrongBad

3

Możesz mieć łącznie 2 64 migawek i podwoluminów.

Strona btrfswiki projektu mówi (moja empahsis):

Podwoluminy to w zasadzie nazwane btree, które przechowuje pliki i katalogi. Mają i-węzły wewnątrz drzewa korzeni drzew i mogą mieć właścicieli i grupy inne niż root. Podwoluminy mogą otrzymać przydział bloków, a po osiągnięciu tego przydziału nie są dozwolone nowe zapisy. Wszystkie bloki i zakresy plików w podwoluminach są liczone jako odniesienia, aby umożliwić migawkę. Na FS można utworzyć do 2 64 podwoluminów.

Migawki są identyczne z podwoluminami , ale ich blok główny jest początkowo współdzielony z inną podwoluminami. Kiedy migawka jest wykonywana, liczba referencji w bloku głównym jest zwiększana, a system transakcji kopiowania przy zapisie zapewnia, że ​​zmiany wprowadzone w migawce lub w podrzędnej objętości są prywatne dla tego katalogu głównego. Migawki są zapisywalne i mogą być migawki ponownie dowolną liczbę razy. Jeśli potrzebne są migawki tylko do odczytu, ich przydział bloków jest ustawiony na jeden w czasie tworzenia.

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.