Moje środowisko to Ubuntu 15.04 z jądrem 3.19.0-28-generic i Btrfs v3.17.
Mam dwa identyczne zewnętrzne dyski twarde USB, których używam ze swoim skryptem kopii zapasowej. Jeden z nich jest sformatowany za pomocą, btrfs
a drugi za pomocą ext4
. Źródłowy system plików jest zawsze ext4
. rsync
Polecenia wygląda następująco:
rsync --inplace --no-whole-file --link-dest="$previousBackup" "$sourceDir" "$destDir"
Właśnie zdałem sobie sprawę, że wykonanie kopii zapasowej btrfs
trwa bardzo długo: nieco ponad godzinę, w porównaniu do 4 minut, które zajmuje wykonanie tej samej kopii ext4
.
Aby wykluczyć nieprawidłowe działanie dysku, przeprowadziłem kilka testów porównawczych z dd
„narzędziem dyskowym” dostarczonym z Ubuntu, ale mam taką samą wydajność na obu dyskach. Powolna część wydaje się być dowiązaniem twardym do poprzedniej kopii zapasowej. Nawet po defragmentacji i szorowaniu następujące polecenie trwa około 53 minut btrfs
, ale tylko 1 minuta ext4
:
cp -arl "$previousBackup" "$destDir"
Badając Internet, znalazłem wskazówki, że wydajność btrfs
cierpi na linkach twardych, ale nie spodziewałbym się tak dużej różnicy. Dowiedziałem się, że to polecenie jest szybsze, ale jego wykonanie zajmuje ponad 30 minut:
cp -ar --reflink "$previousBackup" "$destDir"
Czy ktoś ma doświadczenie z tym zachowaniem i może je potwierdzić? Czy jest jakiś prosty sposób, aby to poprawić (np. Różne opcje montowania), czy powinienem spróbować usunąć jak najwięcej linków i po prostu użyć linków?
EDYTOWAĆ
Właśnie dowiedziałem się, że nawet usunięcie katalogu btrfs
wymaga więcej niż jednej godziny. Ta sama operacja jest natychmiastowa na „bliźniaczym” ext4
dysku. Oczywiście jest tutaj problem z metadanymi.
btrfs
.ext4
dobtrfs
jest zwykle niewielka (około 200). Tego nie potrafię wyjaśnić: kopiowanie przy zapisie powinno sprawić, że linkowanie będzie prawie natychmiastowe (przetwarzane są tylko metadane), ale transfer będzie nieco wolniejszy ... podczas gdy tutaj dzieje się odwrotnie.btrfs filesystem df
Raporty @Tobu Dane, pojedyncze: ogółem = 1,34TiB, używane = 1,34TiB System, DUP: ogółem = 8,00MiB, używane = 176,00KiB System, pojedyncze: ogółem = 4,00 Mb, używane = 0,00B Metadane, DUP: ogółem = 38,47GiB , użyte = 37,49GiB Metadane, pojedyncze: łącznie = 8,00 MB, użyte = 0,00B Nie wydaje mi się pełne ... jednak czy jest jakiś sposób na poprawienie miejsca przydzielonego na metadane?Odpowiedzi:
Mówisz, że kopiujesz twarde linki za pomocą swojego
rsync
polecenia, ale gdzie jest-H
flaga? Nie widzę tego w twoim poleceniu:Rozumiem, jak
rsync
działa - w odniesieniu do linków twardych - to, że bez-H
flagi kopiowane są rzeczywiste dane zamiast linku twardego, jak wyjaśniono narsync
stronie podręcznika :Mogę sobie wyobrazić, że taka procedura, w której wiele podobnych plików jest kopiowanych w kółko zamiast twardych łączy, przyczynia się do wolniejszego transferu.
Rozważ również użycie flagi
-z
(--compress
):Tak, jest to transfer USB na USB w tym samym systemie, więc prawdopodobnie prędkość jest już zoptymalizowana, ale nie szkodzi,
-z
że może pomoże ci pokonać naturalne wąskie gardła transferu danych USB.Miły, prosty samouczek, który wyjaśnia te flagi - i inne - można znaleźć tutaj .
źródło
--hard-links
Służy do zachowania dowiązania twarde w katalogu źródłowym. Za pomocą polecenia, które używam,--link-dest
katalog docelowy zostaje na stałe połączony z poprzednią kopią zapasową na tym samym dysku USB . Zasadniczo jest to różnicowa kopia zapasowa, w której tylko zmienione pliki są faktycznie przesyłane ze źródła, wszystko inne to długi łańcuch linków twardych od kopii zapasowej do kopii zapasowej.--compress
opcję, jest to szczególnie przydatne w przypadku transferów sieciowych. Różnicę można przetestować, ale w przypadku USB jest mało prawdopodobne, aby przyniosła jakąkolwiek korzyść, ponieważ szybszy transfer prawdopodobnie równoważy czas procesora do kompresji danych. Tak czy inaczej, nie dotyczy to mojego przypadku, ponieważ opcje są takie same dla obuext4
(które jest szybkie) ibtrfs
(które jest wolne).