ddrescue bardzo wolno na dysku twardym USB

Odzyskuję dysk twardy z laptopa, który zmarł (w ogóle się nie uruchamiał, Narzędzie dyskowe zgłosiło, że nie ma żadnych problemów, ale nie zamontuje dysku). Podłączyłem dysk twardy za pomocą adaptera USB. Działa ddrescuetak:

sudo ddrescue -v -n /dev/disk1s2 "/Volumes/Original HD/image.dmg" ddrescue.log

Do tej pory nie ma błędów, ale średnia prędkość odczytu stopniowo spadła do 50 KB / s. Na początku było to około 2 MB / s. Rozmiar partycji wynosi 300 GB. Do tej pory udało mi się odzyskać 160 GB. Odzyskuję na partycję HFS + na moim MacBooku.

Jakie mogą być przyczyny tego wolnego transferu i jak go zwiększyć?

Wydaje się, że tak właśnie ddrescuedziała transfer i USB w OSX. Z tego wątku zatytułowanego: Temat: [Bug-ddrescue] ddrescue 10x wolniej pod OSX .

pracując na w pełni funkcjonalnych dyskach twardych, pod Linuksem osiąga pełną prędkość we / wy. kiedy jest kompilowany pod OSX z domyślnymi flagami kompilacji, jest on o wiele razy wolniejszy, czasem indeksuje się do Kb / s. problem występuje nadal, jeśli plik wyjściowy to / dev / null.

Ten sam wątek również otrzymał tę odpowiedź.

Z mojego doświadczenia i testowania na OS X /dev/rdisk…zawsze korzystam zawsze przy użyciu surowych urządzeń postaci . Szybkość przesyłania można również zwiększyć, ustawiając większy rozmiar bloku kopiowania. Rozmiar 512KiB ( ddrescue -c 1Ki) dał mi najlepsze wyniki w większości przypadków.

Oraz: surowe urządzenia znakowe OS X mają określony rozmiar, dzięki czemu można je łatwo używać nawet w pierwszym uruchomieniu. (Przynajmniej w tym punkcie uwagi dotyczące surowych urządzeń w istniejącej dokumentacji ddrescuenie dotyczą OS X.)

Nie sądzę, że jest to błąd w ddrescue, ponieważ inne narzędzia, takie jak ddlub catwykazują takie samo zachowanie na OS X.

Dostęp do urządzenia blokowego / dev / disk… daje raczej wolną prędkość, niezależnie od użytego rozmiaru bloku kopiowania. Z drugiej strony szybkość odczytu surowego urządzenia znaków / dev / rdisk… zależy od wybranego rozmiaru bloku kopiowania:

• 512 bajtów ( ddrescue -c 1domyślnie w dd) jest najwolniejszy.
• Ustawienie na 4096 Byte ( ddrescue -c 8, dd bs=4K) daje taką samą małą prędkość jak dostęp do / dev / disk…
• Domyślnym ddrecue za 128 sektorów (= 64Kb, ddrescue -c 128, dd bs=64K) daje dość dobre wyniki.
• Mnożenie tego dalej (do ddrescue -c 1Ki/ dd bs=512K) zapewnia maksymalną prędkość (przeważnie 8-12 razy większą niż /dev/disk…)
• Wznosząc się powyżej tego, nie zwiększyłem prędkości transferu w dalszych testach; czasami nawet się zmniejszyła.

To są wyniki moich własnych pomiarów, twoje wyniki mogą się różnić w zależności od użytego nośnika i sprzętu IO. Może gdyby inni użytkownicy podzielili się swoimi doświadczeniami, moglibyśmy uzyskać lepszy obraz tego tematu.

Bibliografia

• ddrescue znacznie zwolnił na OS X
• GNU DDrescue, czy robię to dobrze? [wolny / wysoki rozmiar błędu]

Nie wiem dużo o systemie HFS+plików na MacOS, jednak właśnie skorzystałem z możliwości ratowania wewnętrznego dysku twardego o pojemności 500 GB (podłączonego przez SATA) na laptopie z Linux Mint z pamięci USB, zapisując obraz ratunkowy i plik dziennika na exFatsformatowany dysk twardy USB zaczynał się raczej powoli (1-2 MB / s), ale po około 250 GB indeksował tylko z prędkością <100 KB / s. Wydawało się, że im wolniej, tym większy był plik obrazu ratunkowego.

Następnie przeniosłem obraz ratunkowy i ext4plik dziennika do innego tymczasowego miejsca, ponownie sformatowałem dysk twardy USB za pomocą systemu plików, przeniosłem na niego pliki i wznowiłem proces ddrescue - a teraz znów działa z prędkością 1-20 MB / s (waha się ale średnio około 7 MB / s)!

Wydaje się, exFatże nie gra zbyt dobrze z bardzo dużymi plikami (kilkaset gigabajtów). Jak już powiedziano, nie wiem, czy tak jest, HFS+ale może chcesz spróbować ext4.