Skopiować na pamięć USB naprawdę wolno?


45

Kiedy kopiuję pliki na urządzenie USB, zajmuje to dużo dłużej niż w systemie Windows (to samo urządzenie USB, ten sam port), jest szybsze niż prędkości USB 1.0 (1 MB / s), ale znacznie wolniejsze niż prędkości USB 2.0 (12 MB / s). Kopiowanie 1,8 GB zajmuje mi ponad 10 minut (powinno to być <3 min.) Mam dwa identyczne dyski SanDisk Cruzer 8 GB i mam ten sam problem z obydwoma. Mam super talent 32 GB SSD USB w sąsiednim porcie i działa z oczekiwanymi prędkościami.

Problem, który wydaje mi się widoczny w interfejsie GUI, polega na tym, że pasek postępu prawie natychmiast osiąga 90%, kończy się do 100% nieco wolniej, a następnie zawiesza się tam przez 10 minut. Przerwanie kopiowania w tym momencie wydaje się powodować uszkodzenie na końcu pliku. Jeśli poczekam na zakończenie, kopiowanie się powiedzie.

Jakieś pomysły? Wyjście dmesg poniżej:

[64059.432309] usb 2-1.2: new high-speed USB device number 5 using ehci_hcd
[64059.526419] scsi8 : usb-storage 2-1.2:1.0
[64060.529071] scsi 8:0:0:0: Direct-Access     SanDisk  Cruzer           1.14 PQ: 0 ANSI: 2
[64060.530834] sd 8:0:0:0: Attached scsi generic sg4 type 0
[64060.531925] sd 8:0:0:0: [sdd] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
[64060.533419] sd 8:0:0:0: [sdd] Write Protect is off
[64060.533428] sd 8:0:0:0: [sdd] Mode Sense: 03 00 00 00
[64060.534319] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.534327] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.537988] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.537995] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.541290]  sdd: sdd1
[64060.544617] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.544619] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.544621] sd 8:0:0:0: [sdd] Attached SCSI removable disk

Linux odracza zapisy na dysku w zamian za szybsze wykonywanie innych zadań. Tylko zgadnij, spróbuj uruchomić synci sprawdź, czy to nie przyspieszy procesu. <- niesprawdzone, ale możliwe
— RobotHumans

to nie ma sensu, że odłożyłoby to na jeden typ USB, ale nie na inny. Wydaje mi się również, że przypominam sobie, że połączenia z linuksem są synchronizowane co około 30 sekund? Może być przestarzały. Spodziewam się, że jest to jakiś problem ze sterownikiem lub zgodnością, ponieważ zależy to od typu urządzenia.
— Eloff,

Bycie szybszym na innych dyskach USB nie jest Twoim pytaniem. Gdyby tak było, sugerowałbym zajrzenie do hdparm. Ma to więc sens, jeśli
— spojrzysz na

„Mam super talent 32 GB SSD USB w sąsiednim porcie i działa z oczekiwanymi prędkościami”. było tam, ale dobrze ukryte, przyznaję :) Więc do czego to jest hdparm, do którego nawiązujesz?
— Eloff,

Okej, SSD i pamięć flash NIE SĄ tym samym. Ale poruszając się dalej, hdparm jest narzędziem, które pozwala ręcznie ustawić prędkości dostępu / wirowania dla napędu
— RobotHumans

Odpowiedzi:


29

Dlaczego kopiowanie na mój dysk USB jest tak wolne w systemie Linux (i szybsze w systemie Windows)?

Buforowanie Powód 1. Plik może zapisy pojawiają się wolniej lub szybciej

Problem, który wydaje mi się widoczny w interfejsie GUI, polega na tym, że pasek postępu prawie natychmiast osiąga 90%, kończy się do 100% nieco wolniej, a następnie zawiesza się tam przez 10 minut.

Jedną rzeczą, którą musisz zrozumieć, jest buforowanie plików. Linux (i Windows) użyje inaczej „pustej” pamięci RAM do buforowania operacji odczytu / zapisu i przyspieszenia ich przy kolejnych dostępach. Buforowanie operacji kopiowania na wolne urządzenia powoduje zachowanie, które widzisz - „szybkie zakończenie” faktycznie zapisuje w pamięci podręcznej, a następnie spowalnia i zatrzymuje się, ponieważ faktyczne opróżnianie danych w pamięci podręcznej (synchronizacji) na wolne urządzenie jest trwa bardzo długo. Jeśli przerwiesz w tym momencie, dane zostaną uszkodzone (jak zauważyłeś), ponieważ synchronizacja nigdy się nie zakończyła.

Takie kopiowanie w systemie Windows może wydawać się szybsze (w tym zgłaszane prędkości MB / s), ponieważ czasami system Windows nie będzie czekać na synchronizację i zadeklaruje ukończenie zadania, gdy tylko dane zostaną zapisane w pamięci podręcznej.

Powód 2. Pisanie dużej liczby plików, zwłaszcza małych, jest powolne

Aby skopiować 1,8 GB

Ze względu na sposób działania pamięci flash i systemów plików najszybszą przepustowość (szybkość) osiąga się przy pisaniu bardzo dużych plików. Pisanie wielu małych plików, a nawet mieszanych danych zawierających wiele małych plików, może znacznie spowolnić proces. Dotyczy to również dysków twardych, ale w nieco mniejszym stopniu.

Powód 3. Nie można porównać prędkości zapisu w pamięci USB i dysku SSD

Mam super talent 32 GB SSD USB w sąsiednim porcie i działa z oczekiwanymi prędkościami.

  • Pamięć USB w odmianie ogrodowej zwykle składa się z układów pamięci flash, które są zapisywane szeregowo (sekwencyjnie) i nie mają własnego bufora.

  • Z drugiej strony dysk SSD zawiera kontroler, który zapisuje równolegle w układach pamięci flash , zwiększając przepustowość o 2 lub więcej razy w stosunku do pamięci USB.

    • Gdyby twój dysk SSD o pojemności 32 GB posiadał 4 x 8 GB układów, byłby nadal 4x szybszy niż pamięć USB przy każdej operacji zapisu.
    • Dysk SSD zawiera również pamięć podręczną RAM (podobnie jak dyski twarde), dzięki czemu może szybko przechowywać przychodzące dane w pamięci podręcznej i informować system operacyjny o tym, że zostało wykonane, podczas gdy nadal musi zapisywać te dane w pamięci flash.
  • Tak więc, z jednym dużym plikiem, twoja 32 GB GB ze strukturą 4x, którą zakładamy, byłaby 4x tak szybka; przy wielu małych plikach byłoby 10 razy szybsze, ponieważ mógłby inteligentnie przechowywać je w pamięci podręcznej.


Podsumowując , są to powody, dla których kopiowanie plików na pamięci USB może wydawać się wolniejsze w systemie Linux. Czy faktycznie jest wolniejszy z powodu problemu ze sprzętem / sterownikiem lub czegoś innego ...

Właściwe porównanie prędkości zapisu między Linuksem a Windowsem

  • Przede wszystkim zapomnij o dysku SSD z powodu przyczyny 3. To jest jak pomarańcze i jabłka.
  • Aby zneutralizować skutki przyczyny 1 (buforowanie) i przyczyny 2 (małe pliki), musisz przetestować pojedynczy duży plik, większy niż ilość pamięci RAM w systemie testowym.
  • W systemie Linux możesz go utworzyć za pomocą dd if=/dev/urandom of=largetest bs=1M count=7500, co daje 7500 MB pliku testowego. Zakładając, że twój system ma mniej niż 4 GB pamięci RAM, jest wystarczająco dobry. Skopiuj go na świeżo sformatowany dysk Sandisk 8 GB i zmierz czas.
  • Uruchom ponownie w systemie Windows i skopiuj largetestz pamięci USB na dysk twardy. Uruchom ponownie (aby usunąć go z pamięci podręcznej). Następnie sformatuj pamięć USB (ten sam vat / FAT32!) I skopiuj largetestz dysku twardego na pamięć.
  • Jak się mają czasy?

2
cc: @Eloff Re Powód 1 : Tak, synchronizacja pamięci podręcznej może z pewnością wpłynąć na pozorny czas zapisu. Ale czy sama pamięć podręczna wyjaśni, dlaczego wisi tam przez 10 minut ? Myślę, że potrzebujemy więcej szczegółów z PO. Re Powód 2 : Dlaczego zakładasz, transfer ten składał się z wielu małych plików? Nie sądzę, że OP podaje jakieś szczegóły na temat transferu 1,8 GB, prawda? Re Powód 3 : Tak, SSD jest inna bestia. Prawdopodobnie byłby również podłączony przez SATA, a nie USB. Myślę, że OP po prostu źle powiedział i nazywał pamięć USB dyskiem SSD. Ale znowu, nie ma możliwości poznania, chyba że otrzymamy więcej szczegółów z PO.
— irracjonalny Jan

2
Ta odpowiedź rażąco ignoruje sposób sformułowania pytania. Pytanie wyraźnie mówi o jednym dużym pliku, a fakt, że przerwanie kopiowania powoduje uszkodzenie pliku.
— zrajm

4
@zrajm to prawda. Jednak dla osób takich jak ja wpadających na ten sam problem jest to bardzo pomocne.
— Pithikos,

Jak zatem wyłączyć to zachowanie buforowania?
— Aminu Kano,

7

Znaleziono poprawkę, którą zrobiłem, to odmontowałem, usunąłem dysk i uruchomiłem sudo modprobe ehci_hcdw terminalu. Włóż dysk i Agian, sudo modprobe ehci_hcdkiedy go włożę i wow 20 / mbs myślałem, że podzielę się. Mam nadzieję, że nie muszę tego robić za każdym razem ... ale nie jest to trudne ...

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177235 mówi, że naprawili błąd.


Poważnie?? Ten raport o błędach pochodzi z grudnia 2007 roku i odnosi się do Ubuntu gutsy 7.10. (FYI: @MarcoCeppi)
— irracjonalny Jan

3
@irrationalJohn Nie podałem odpowiedzi, po prostu ją posprzątałem. Po drugie, fakt, że zgłoszenie błędu jest stare, nie oznacza, że ​​nadal nie jest ważny. To są przyporządkowani według tego
— Marco Ceppi

@MarcoCeppi Tak, wiem, że tylko edytowałeś. Dlatego poprzedziłem „ FYI: ”. Pomyślałem, że jeśli go zredagowałeś, możesz (lub nie ) być zainteresowany. Pomyślałem, że jeśli cię to nie obchodzi, po prostu zignorujesz to powiadomienie. Co do starego raportu o błędach, który nadal ma znaczenie ... Ponad 4 lata temu i myślę, że co najmniej 8 (?) Wydań później? W przypadku błędu wydajności? Jasne, może to być możliwe, ale nie jest to pierwsze miejsce, w którym wyglądam. FWIW.
— irracjonalny Jan

7

Myślę, że są bardzo małe szanse, że jest to problem z portem. Bardziej prawdopodobne jest, że występuje problem z Linuksem (lub konfiguracją Linuksa) - przeglądaj go, a znajdziesz tysiące raportów problemów dotyczących wolnego USB w Linuksie / Ubuntu. Dla mnie jest to prawie showstopper dla Linuksa - mam teraz Ubuntu 12.04 LTS i nadal mam ten problem (więc raczej używam konfiguracji Win7 - głównie / tylko z tego powodu). Ten problem (lub coś z podobnymi objawami) istnieje już od kilku lat, najwyraźniej nie ma rozwiązania. W tym czasie wypróbowałem kilka fizycznych komputerów z kilkoma różnymi wersjami ubuntu (domyślna konfiguracja) i 2-3 różnymi pamięciami USB ....


5

Tylko umounturządzenie, jeśli jest już automatycznie zamontowane, i ręcznie je podłącz /mnt/foldername.

W moim przypadku,

umount /media/usb0
mount /dev/sdb1 /mnt/sam

Potem radzi sobie bardzo szybko.


To wraz z rsynczamiast cpwydaje się załatwić sprawę.
— Irfan

19
Nie miało to żadnego wpływu na moją sytuację. Poza tym nie jest to tak naprawdę rozwiązanie bez teorii, dlaczego ma to mieć znaczenie.
— LondonRob

@Irfan Nie, rsync też zwalnia ...
— sergzach,

3

Jest rok 2019 i nadal mam ten sam problem. Pomyślałem więc, że szukam rozwiązania w Internecie. Znalazłem następującą stronę, która sugeruje jedną: https://gist.github.com/2E0PGS/f63544f8abe69acc5caaa54f56efe52f

To mówi:

Wykonaj następujące polecenia w konsoli, aby sprawdzić, czy to rozwiąże problem. Być może trzeba sudo subędzie mieć wymagane pozwolenie.

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

Jeśli zadziała, możesz sprawić, że zmiana będzie trwała podczas ponownego uruchamiania, wklejając dwie linie na końcu /etc/rc.localpliku.

Dla mnie miało to następujący efekt:

Wcześniejsze kopiowanie dużych plików na dysk USB zaczynałoby się naprawdę szybko (jak 60 MB / s) i stawało się coraz wolniejsze (<10 MB / s), aż wyglądałoby na to, że nigdy się nie skończy.

Teraz zaczyna się wolniej, ale staje się coraz szybszy i kończy się wcześniej niż wcześniej. Wydaje się więc, że „rozwiązuje” problem lub przynajmniej ma pozytywny wpływ.


1

Jeśli przełączysz się na USB 3.0, przejdziesz z 1 Mb / s do niesamowitego 5-8 Mb / s. Przełączam się na USB 3.0 3.0 i zewnętrzny HD i nie oglądałem się za siebie.


1

Kiedy patrzysz na / etc / mtab, czy widzisz, że urządzenie zostało zamontowane z opcją „flush”?

Jeśli tak, może to być przyczyną problemu (dotyczyło mnie). Po prostu odmontuj urządzenie i podłącz je ponownie, nie powinno być domyślnie ustawione.


Opcja spłukiwania jest ustawiona domyślnie, jakoś to zatrzymać?
— Ben Lutgens

@ Ben Lutgens - Tak, możesz umieścić swój własny wpis w / etc / fstab, który nie ma opcji koloru. Użyj sudo blkid, aby znaleźć odpowiedni UUID urządzenia i wstaw taki wpis, jak UUID = „Twój identyfikator urządzenia tutaj” / mnt / <Twój punkt podłączenia tutaj> Uid = 1000, gid = 1000, fmask = 0022, dmask = 0022 0 0. Zmień identyfikator uid, gid, aby pasował do identyfikatora użytkownika i identyfikatora groupid zwykłego użytkownika, którego używasz (znaleziony przez getent passwd <twój użytkownik>).
— A.Danischewski

Gdy to robię, wszystko, co się zmienia, polega na tym, że nie otrzymuję już paska postępu kopiowania, a kopiowanie wydaje się naprawdę uruchamiać / kończyć, gdy próbuję odmontować urządzenie, i mówi mi: „nie odłączaj, dopóki operacja nie zostanie zakończona „.
— Jenny O'Reilly,

0

Miałem też pewne problemy z szybkością transferu na zewnętrznym dysku WD, po otwarciu go w Windows SO zawsze korzystałem z LINUX, po czym szybkość transferu wynosiła około 1,5 Mb / s, a następnie odmontowałem zewnętrzny dysk twardy uruchomiony tam dmesg, tam był mówiąc, że sdb1 był niepoprawnie odmontowany, uruchomił fsck, który dokonał kilku napraw, a następnie ponownie 20 Mb / s prędkości transferu przy kopiowaniu z sda na dysk zewnętrzny. fsck zawsze stanowi ryzyko, jeśli masz dane, ale działało to dla mnie, bez utraty danych.


-2

Miałem również ten problem, ale używam polecenia cp, a ty aktualizujesz pamięć USB w kilka sekund;

cp -r -u /home/user/Muziek/ /media/user/Audiousbsti
cp -r -u /home/user/Muziek/ /media/user/4F49-4A65/

Myślę, że to bardzo późna odpowiedź, ale wciąż jest otwarta.


-3

Okej, miałem ten sam problem przez trzy dni i jak udało mi się wykonać kopię zapasową mojego dysku twardego 1 TB za pomocą rsync, wiem, że jest on używany do tworzenia kopii zapasowych, ale wykonał zadanie, nawet podczas przesyłania dużych plików, których używam do wykonać tę pracę. Jeśli chcesz używać go z GUI, sugeruję zainstalowanie Grsync, która jest graficzną wersją rsync, ponieważ rsync działa na terminalu.

Mam nadzieję, że to pomogło

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.