Dlaczego komputer zawiesza się podczas kopiowania pliku na pendrive?

61

Mam tutaj naprawdę dziwną sytuację. Mój komputer działa dobrze, przynajmniej w większości przypadków, ale jest jedna rzecz, z którą nie mogę sobie poradzić. Kiedy próbuję skopiować plik z mojego pendrive'a, wszystko jest w porządku - mam 16-19M / s, działa całkiem dobrze. Ale kiedy próbuję skopiować coś na ten sam pendrive, mój komputer zawiesza się. Wskaźnik myszy przestaje się poruszać na sekundę lub dwie, potem porusza się trochę i znowu się zatrzymuje. Kiedy coś gra np. W Amaroku, dźwięk działa jak karabin maszynowy. Prędkość skacze z 500 K / s do 15 M / s, średnio 8 M / s. Dzieje się tak tylko wtedy, gdy kopiuję coś na pendrive. Po zakończeniu procesu kopiowania wszystko wraca do normy.

Próbowałem wszystkiego - inny pendrive, inny port USB na panelu przednim lub te z tyłu, zmieniłem nawet piny USB na płycie głównej (panelu przednim), ale bez względu na to, gdzie włożyłem pamięć USB, zawsze jest tak samo. Próbowałem różnych plików - fat32, ext4. Nie mam problemu z urządzeniem w systemie Windows, na moim laptopie. To musi być mój komputer lub coś w moim systemie. Nie mam pojęcia, czego szukać. Używam testów Debiana z samodzielnym Openbox. Mój komputer jest trochę stary - Pentium D 3GHz, 1 GB pamięci RAM, 1,5 TB WD Green disk. Jeśli masz coś, co pomogłoby mi rozwiązać ten problem, chętnie to usłyszę.

Nie wiem, jakie jeszcze informacje powinienem podać, ale jeśli czegoś potrzebujesz, po prostu zapytaj, zaktualizuję ten post jak najszybciej.

Próbowałem odtworzyć ten problem na Live CD Ubuntu 13.04. Zamontowałem zaszyfrowaną partycję + zaszyfrowaną swap i podłączyłem pendrive do portu USB. Następnie próbowałem uruchomić niektóre aplikacje, a teraz mam ~ 820 MB w pamięci RAM i około 400 MB w SWAP. Nie ma problemu z kopiowaniem, w ogóle nie ma zamrażania, wszystko jest tak, jak powinno być. Wygląda na to, że to wina systemu, ale gdzie dokładnie? Co spowodowałoby tak dziwne zachowanie?

Michaił Morfikow
źródło
Kiedy spotkałem coś podobnego do tego, to dlatego, że miałem problemy z dyskiem twardym na moim laptopie. Dysk miał kilka złych obszarów i za każdym razem, gdy próbowałem odczytać cokolwiek z tych obszarów, zawieszał się, dopóki nie został ukończony. Pomysł, na który warto spojrzeć. Może masz złe sektory, z których próbujesz czytać.
slybloty
Mój dysk twardy jest w porządku, przynajmniej inteligentne powiedz tak (po pełnym skanie).
Michaił Morfikow
Spróbuj zmniejszyć priorytet IO procesu kopiowania, np ionice -c3 cp something.tgz /media/pendrive. Spowoduje to umieszczenie nowo odrodzonego cpprocesu w trzeciej (= najniższej) klasie priorytetowej „bezczynności”.
n.
Próbowałem tego, ale to nie działa.
Michaił Morfikow
@MikhailMorfikov FYI, ten problem został rozwiązany w Linuksie 4.9. Nadal sam nie testowałem poprawki. YMMV.
Seamus Connor

Odpowiedzi:

85

Czy używasz 64-bitowej wersji systemu Linux z dużą ilością pamięci? W takim przypadku problemem może być to, że Linux może blokować się na kilka minut w przypadku dużych zapisów na wolnych urządzeniach, takich jak na przykład karty SD lub pamięci USB. Jest to znany błąd, który powinien zostać naprawiony w nowszych jądrach.

Zobacz http://lwn.net/Articles/572911/

Obejście: jako problem root:

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

Dodałem go do mojego /etc/rc.localpliku na moich 64-bitowych maszynach.

TANSTAAFL ; ta zmiana może (i prawdopodobnie zmniejszy) przepustowość tych urządzeń --- to kompromis między opóźnieniem a szybkością. Aby wrócić do poprzedniego zachowania, możesz

echo 0 > /proc/sys/vm/dirty_background_bytes
echo 0 > /proc/sys/vm/dirty_bytes

... które są wartościami domyślnymi, co oznacza, że ​​zachowanie zapisu zwrotnego będzie kontrolowane przez parametry dirty_ratioi dirty_background_ratio.

Uwaga dla osób, które nie są tak ekspertami w Linuksie: pliki w pliku /proc to pseudofile --- tylko kanały komunikacji między jądrem a przestrzenią użytkownika. Nigdy nie używaj edytora do zmiany lub patrzenia na nie; zamiast tego otrzymaj monit powłoki - na przykład z sudo -i(smaki Ubuntu) lub su rooti użyj echoi cat).

Aktualizacja 2016/04/18 wydaje się, że mimo wszystko problem nadal występuje. Możesz na to spojrzeć na LWN.net , w tym artykule o kolejkach zapisu .

Rmano
źródło
3
Mam 64-bitową pamięć RAM, ale tylko 1 GB, i muszę powiedzieć, że to rozwiązanie działa! Właśnie go przetestowałem i po ustawieniu dwóch parametrów nie ma już zamrażania. :)
Michaił Morfikow
1
W mojej instalacji 14.04 uname -azwraca 3.13.0-32-generic, więc tak. Ale nie sprawdziłem, czy łatka dla tego problemu została w końcu zintegrowana z jądrem, czy nie. Mam maszynę 16 GB i wydaje się, że działa bez obejścia, choć muszę przyznać, że nie próbowałem ze szczególnie wolnymi urządzeniami.
Rmano,
1
@ IonicăBizău --- to pseudoplik, nie edytuj go vim nigdy . Uzyskaj powłokę roota (z sudo -i) i użyj wyżej wymienionych poleceń.
Rmano
1
@Rmano Udało się! Jednak edytowałem go za pomocą VIM. Dzięki!
Ionică Bizău
2
Używam Ubuntu 16.04 na zupełnie nowym laptopie (z 16 GB pamięci RAM). Byłem naprawdę zły na ten problem. Twoje rozwiązanie działało jak urok! Być może możesz dodać, że może to być nadal potrzebne w jądrze 4.8.0-45.
LGenzelis,
3

Przyczyną może być wzmocnienie zapisu, ponieważ system próbuje pisać mniejszymi fragmentami niż kasowanie bloku (wykonywanie odczytu / modu / zapisu) + niewspółosiowość bloku.

Aby sprawdzić swoje obecne ustawienia:

cat /sys/block/sd**X**/device/max_sectors

Możesz dostroić reguły hal dla tych urządzeń:

Zmień wartość „max_sectors” USB dla całej rodziny urządzeń

W tym przypadku zastąpiłem max_sectors dla wszystkich urządzeń, które używały domyślnie 240 (pamięć USB) na sektory 32K lub sektory 2K.

W moim systemie (Mageia 4, 3.14.24 core i7) musiałem to zrobić z powodu strasznie niskiej prędkości zapisu (2 MB / s) na Kingston DT101 G2 16 GB:

vi /usr/lib/udev/rules.d/81-udisks_maxsect.rules

i dodaj:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="32678"

A ddprędkość zapisu wzrosła trzykrotnie. mc cpprawdopodobnie 10-20x w górę (po uruchomieniu pierwszej partycji @ 8192 sektor i sformatowaniu z 64k wyrównanych klastrów):

fdisk -u /dev/sdh # make DOS compat off if on
mkfs.vfat /dev/sdh1 -n KINGSTON16G -s 128 **-R 4592*** and use *fsck.vfat -v /dev/sdh1

w celu sprawdzenia wyrównania (sprawdź [sektor początkowy danych] powinien być wielokrotnością 128 (rozmiar klastra)). W razie potrzeby dostosuj liczbę zarezerwowanych sektorów (-R).

Domyślnie max_sectors (240) wydaje się powodować wysokie wzmocnienie zapisu na niektórych tanich nowych dyskach. Ale bądź bardzo ostrożny przy tak wysokim ustawieniu, podobny efekt osiąga się w 2048 sektorach (prawdopodobnie bloki usuwania 1M:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="2048"

Przetestuj wszystkie stare urządzenia USB, aby nadal działały dobrze. Użyj bardziej szczegółowych atrybutów dostawcy / modelu w plikach reguł.

znak
źródło
1

sprzęt kontra oprogramowanie

Wystąpił dziwny problem podobny do tego z dyskami USB i w moich badaniach prawie zawsze chodzi o problem ze sterownikiem lub o konkretny sprzęt w komputerze / płycie głównej.

Wiem to, ponieważ mam kilka systemów, które są identyczne, i na jednym mogę wykonać tę operację bez problemu, podczas gdy na innym pojawia się problem.

Co robić?

Twoje opcje są tutaj naprawdę ograniczone. Jedyne, co możesz zrobić, to upewnić się, że masz najnowszy BIOS / oprogramowanie wbudowane w systemie i upewnić się, że masz najnowsze wersje pakietów swojej dystrybucji.

Poza tym wszystko, co mogę zasugerować, to upewnienie się, że unikniesz tej sytuacji, nie próbując kopiować plików, gdy inna kopia jest w toku.

Jeśli masz osobowość, w której irytują cię takie rzeczy, możesz wypróbować kolejną dystrybucję Linuksa na żywo i powtórzyć kroki prowadzące do problemu. To by po prostu wyeliminowało, czy jest to problem specyficzny dla dystrybucji, czy problem sprzętowy, jak opisałem powyżej. Byłoby to małe pocieszenie, ale zawsze wolę wiedzieć rzeczy, niż chować głowę w piasek, a nie.

Coś jeszcze?

Jeśli jesteś naprawdę obsesyjny, możesz spróbować uruchomić aplikację, z którą wykonujesz kopię, stracew nadziei na złapanie systemu w dowolnym zawieszającym się wywołaniu systemowym. Powinieneś być w stanie to zrobić również z wiersza poleceń.

Przykład

$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/. 

Potem, gdy to działa, uruchom inny.

$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/. 

Mam nadzieję, że system zawiesi się podczas tej operacji i być może będziesz mieć szczęście i znajdziesz trochę dymu w jednym z tych plików dziennika.

slm
źródło
Zawsze używam tylko jednego wystąpienia kopiowania plików. Mam zaktualizowany BIOS (2008) i od tego czasu nie ma nowszej wersji. Myślę, że to nie jest BIOS. Moja dystrybucja debiana została również zaktualizowana do gałęzi testowania. Próbowałem użyć stracei prawie natychmiast zamroziło się, więc zaczekałem kilka sekund i zabiłem proces. Mam dziennik 1 Mb, ale nie mogę go odczytać, nie wiem, czego szukać. Możesz to sprawdzić tutaj pastebin.com/u29RvqgC - nie jest to pełny dziennik (ograniczony do 500 KB), ale na końcu były tylko podobne linie. Spróbuję odtworzyć ten problem z Live CD Ubuntu.
Michaił Morfikow
Zaktualizowałem pytanie dotyczące testowania CD na żywo.
Michaił Morfikow
@MikhailMorfikov - Myślę, że jesteś prawie na końcu tego, czego możesz się spodziewać. Twój sprzęt jest dość stary (2008) i naprawdę niewiele można zrobić poza tym, co opisałem powyżej.
slm
Ale nawet starsze komputery są w stanie bez problemu kopiować pliki.
Michaił Morfikow
@MikhailMorfikov - Wiek to nie jedyny czynnik, ale to, co mam na myśli, jest prawdopodobne, że liczba aktualizacji oprogramowania układowego lub aktualizacji oprogramowania starego sprzętu jest niska.
slm