Dlaczego komputer zawiesza się podczas kopiowania pliku na pendrive?

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?

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 .

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ł.

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.