Ostatnio pojawiła się wiadomość, że twórca jądra Linuksa, „Linus Torvalds” przyjęty do głównego oddziału (na podstawie której powstaje wersja 5.4) implementacja modułu dm-clone wraz z wdrożeniem nowego sterownika w oparciu o narzędzie do mapowania urządzeń.
Ta nowa propozycja dla jądra Linuksa pozwoli ci sklonować istniejące urządzenie blokowe. Moduł pozwala na tworzenie kopii lokalnej na podstawie na urządzeniu blokowym tylko do odczytu, na którym można zapisywać podczas procesu klonowania.
Jako typową aplikację zaproponowano moduł dla jądra systemu Linux „dm-clone” odnosi się do klonowania sieciowego zdalnych urządzeń plików w trybie tylko do odczytu i przetwarzania we/wy z dużymi opóźnieniami, do szybkiego urządzenia lokalnego, które obsługuje rejestrowanie i przetwarzanie żądań z minimalnymi opóźnieniami.
Z tym zapewnia możliwość zamontowania sklonowanego urządzenia i natychmiastowego rozpoczęcia korzystania z niego po jego utworzeniu, bez czekania na zakończenie procesu przenoszenia danych.
Z drugiej strony kopiowanie informacji będzie kontynuowane w tle, równolegle z wejściem/wyjściem generowanym podczas uzyskiwania dostępu do nowego urządzenia.
Głównym przypadkiem użycia dm-clone jest sklonowanie potencjalnie zdalnego urządzenia blokującego o opóźnieniu, tylko do odczytu, na zapisywalne urządzenie typu podstawowego.
Na przykład dm-clone może służyć do przywracania kopii zapasowych z podłączonego magazynu do sieci dostępnej za pośrednictwem protokołów, takich jak NBD, Fibre Channel, iSCSI i AoE na lokalnym dysku SSD lub pamięci masowej opartej na NVMe.
Kod dm-clone jest zoptymalizowany pod kątem małych losowych operacji zapisu, których rozmiar odpowiada rozmiarowi bloku (domyślnie 4K).
Podczas procesu klonowania żądania odczytu będą prowadzić do bezpośredniego żądania danych ze sklonowanego urządzenia, a żądania zapisu dotyczące obszarów, które nie zostały jeszcze zsynchronizowane, zostaną opóźnione do czasu zakończenia nieplanowanego przesyłania żądanych bloków (bloków). operacje dla bloków związanych z zapisem są uruchamiane natychmiast).
Bloki usunięte przez operację „discard” są wykluczone z procesu kopiowania (po zamontowaniu użytkownik może uruchomić „fstrim /mnt/cloned-fs”, aby uniknąć kopiowania bloków, które nie są używane w FS).
Informacja o zmianach i danych w załadowanych blokach są one przechowywane w oddzielnej lokalnej tabeli metadanych.
Po zakończeniu klonowania użytkownik otrzymuje pełną kopię roboczą urządzenia źródłowego, odzwierciedlającą wszystkie zmiany dokonane od rozpoczęcia klonowania.
Tabelę z klonowanymi metadanymi można usunąć po synchronizacji, zastępując ją tabelą liniową, która bezpośrednio odzwierciedla dane na nowym urządzeniu.
Kluczowa różnica między rozwiązaniami opartymi na Unionfs i OverlayFS polega na tym, że dm-clone działa na poziomie urządzenia blokowego, niezależnie od systemu plików używanego na tym urządzeniu i tworzy pełną kopię urządzenia źródłowego i nie narzuca dodatkowej warstwy, w której zmiany są śledzone.
W przeciwieństwie do dm-mirror, moduł dm-clone został pierwotnie zaprojektowany do pracy tylko z oryginalną sekcją w trybie tylko do odczytu, bez tłumaczenia na nią operacji zapisu.
W dm-snapshot pełna kopia nie jest tworzona, a kopiowanie w tle nie jest obsługiwane. W dm-cache pełna kopia nie jest tworzona, operacje zapisu są ponownie przesyłane, a praca ogranicza się do trafień w pamięci podręcznej. Najbliższa funkcjonalność to dm-thin.
dm-clone używa dm-kcopyd do kopiowania części urządzenia źródłowego do urządzenia docelowego. Domyślnie wysyłane są żądania kopiowania o rozmiarze równym rozmiarowi regionu.
Komunikat `hydration_batch_size <#regions>` może być użyty do dostosowania rozmiaru tych żądań kopiowania. Zwiększenie rozmiaru partii hydratacji powoduje, że dm-clone próbuje grupować ciągłe regiony, więc kopiujemy dane w partiach tych wielu regionów.
źródło: https://git.kernel.org