Czy są jakieś skrypty do deduplikacji, które używają oprogramowania btrfs CoW jako deduplikacji?

Poszukując narzędzi do deduplikacji w systemie Linux jest ich mnóstwo, patrz np. Ta strona wiki .

Prawie wszystkie skrypty wykrywają tylko, drukują duplikaty nazw plików lub usuwają duplikaty plików, łącząc je twardo z jedną kopią.

Wraz z pojawieniem się btrfs pojawiła się inna opcja: utworzenie kopii pliku CoW (kopiowanie przy zapisie) pliku (jak cp reflink=always). Nie znalazłem żadnego narzędzia, które to robi, czy ktoś wie o narzędziu, które to robi?

W tym celu napisałem bedup . Łączy przyrostowe skanowanie btree z deduplikacją CoW. Najlepiej stosować z Linuksem 3.6, w którym możesz uruchomić:

sudo bedup dedup

Próbowałem snu. Chociaż jest dobry (i ma kilka użytecznych, zróżnicowanych funkcji, które mogą uczynić go najlepszym wyborem dla wielu), wydaje się, że skanuje wszystkie pliki docelowe w poszukiwaniu sum kontrolnych.

Co jest boleśnie powolne.

Inne programy, takie jak rdfind i rmlint, skanują inaczej.

rdfind ma funkcję „eksperymentalną” do używania reflink btrfs. (I „stałe” opcje dla dowiązań twardych, dowiązań symbolicznych itp.)

rmlint ma „stałe” opcje klonowania btrfs, reflink, zwykłych hardlinków, dowiązań symbolicznych, usuwania i własnych poleceń niestandardowych.

Co ważniejsze, rdfind i rmlint są znacznie szybsze. Jak w rzędach wielkości. Zamiast skanować wszystkie pliki docelowe w poszukiwaniu sum kontrolnych, robi to w przybliżeniu:

• Przeskanuj cały docelowy system plików, zbierając tylko ścieżki i rozmiary plików.
• Usuń z analizy pliki o unikalnych rozmiarach plików. Tylko to pozwala zaoszczędzić mnóstwo czasu i aktywności na dysku. („Scads” to jakaś odwrotna funkcja wykładnicza lub coś takiego.)
• Z pozostałych kandydatów zeskanuj pierwsze N ​​bajtów. Usuń z rozważań te, które mają taki sam rozmiar pliku, ale różne pierwsze N ​​bajtów.
• Zrób to samo dla ostatnich N bajtów.
• Pozostała tylko ta część (zwykle niewielka część), poszukaj sum kontrolnych.

Inne zalety rmlint Jestem świadomy:

• Możesz określić sumę kontrolną. md5 zbyt przerażające? Spróbuj sha256. Lub 512. Lub porównanie bit-za-bitem. Lub twoja własna funkcja haszująca.
• Daje ci opcję „klonowania” i „reflink” Btrfs zamiast tylko reflink. „cp --reflink = always” jest nieco ryzykowne, ponieważ nie jest atomowe, nie jest świadome tego, co dzieje się dla tego pliku w jądrze i nie zawsze zachowuje metadane. „Klon”, OTOH (który jest skrótem ... Mam na myśli oficjalną nazwę związaną z API), to wywołanie na poziomie jądra, które jest atomowe i zachowuje metadane. Prawie zawsze skutkuje tym samym, ale odrobinę solidniejszym i bezpieczniejszym. (Chociaż większość programów jest wystarczająco inteligentna, aby nie usuwać duplikatu pliku, jeśli nie może najpierw pomyślnie utworzyć tymczasowego łącza zwrotnego do drugiego.)
• Ma mnóstwo opcji dla wielu przypadków użycia (co jest również wadą).

Porównałem rmlint z deduperemove - która również ślepo skanuje wszystkie pliki docelowe w poszukiwaniu sum kontrolnych. Duperemove zajęło mi kilka dni na ukończenie tomu (chyba 4), przechodząc do pełnego tiltu. fmlint potrzebował kilku godzin na zidentyfikowanie duplikatów, a następnie poświęcił je nie więcej niż dzień na klonowanie Btrfs.

(To powiedziawszy, każdy, kto stara się pisać i wspierać wysokiej jakości, solidne oprogramowanie i oddawać je za darmo, zasługuje na wielkie uznanie!)

Btw: Powinieneś unikać deduplikacji za pomocą zwykłych linków jako „ogólnego” rozwiązania deduplikacji za wszelką cenę.

Chociaż twarde linki mogą być bardzo przydatne w określonych przypadkach użycia (np. Pojedyncze pliki lub narzędzie, które może skanować w poszukiwaniu określonych typów plików przekraczających pewien minimalny rozmiar - lub jako część wielu bezpłatnych i komercyjnych rozwiązań tworzenia kopii zapasowych / migawek), może być katastrofalne do „deduplikacji” w dużym systemie plików ogólnego zastosowania. Powodem jest to, że większość użytkowników może mieć w systemie plików tysiące plików, które są binarnie identyczne, ale funkcjonalnie zupełnie inne.

Na przykład wiele programów generuje szablony i / lub ukryte pliki ustawień (czasami w każdym folderze, który widzi), które początkowo są identyczne - i większość z nich pozostaje, dopóki użytkownik nie będzie tego potrzebował.

Jako konkretna ilustracja: Pliki pamięci podręcznej miniatur zdjęć, które niezliczone programy generują w folderze zawierającym zdjęcia (i nie bez powodu - przenośność), mogą zająć godziny lub dni, ale wygenerowanie aplikacji do zdjęć jest dziecinnie proste. Jeśli wszystkie te początkowe pliki pamięci podręcznej są połączone ze sobą na stałe, to później otworzysz aplikację w katalogu i utworzy ona dużą pamięć podręczną ... to zgadnij co: Teraz KAŻDY folder, który ma wcześniej połączoną pamięć podręczną, teraz ma niewłaściwą pamięć podręczną. Potencjalnie z katastrofalnymi skutkami, które mogą spowodować przypadkowe zniszczenie danych. A także potencjalnie w sposób, który wybucha rozwiązanie do tworzenia kopii zapasowych, które nie obsługuje hardlink.

Ponadto może zepsuć całe migawki. Cały sens migawek polega na tym, że wersja „na żywo” może się nadal zmieniać, z możliwością przywrócenia do poprzedniego stanu. Jeśli jednak wszystko jest połączone ze sobą na stałe, „przywracasz” to samo.

Dobrą wiadomością jest to, że deduplikacja za pomocą klonowania / reflink Btrfs może cofnąć to uszkodzenie (myślę - ponieważ podczas skanowania powinien widzieć pliki dowiązane jako identyczne ... chyba że ma logikę, aby nie brać pod uwagę dowiązań twardych. Prawdopodobnie zależy to od konkretne narzędzie wykonujące deduplikację).