System zawiesza się / nie odpowiada / nie można go użyć podczas kopiowania dużego pliku na USB

50

Wczoraj kopiowałem pojedynczy plik o pojemności 8 GB na dysk USB o niskiej prędkości zapisu 7 MB / s, a moja pamięć RAM wynosi 3 GB. Podczas kopiowania system zamarł, do tego stopnia, że nie mogłem nawet przesunąć kursora.

Udało mi się zalogować do konsoli tekstowej i uruchomiłem iotop, to pokazało, że proces o nazwie kswapd0zabiera 99,99% IO.

Czy istnieją obejścia, więc kopiowanie dużego pliku nie powoduje, że mój system nie nadaje się do użytku?

usb freeze

— sashoalm
źródło

12

Ten błąd jest taki niedorzeczny ...

— king_julien

Tak, dzieje się to nie tylko z Ubuntu, ale także w innych wersjach Debiana. Widziałem również ten sam problem w Kali Linux i Parrot OS. Kali ma najgorszy scenariusz, podczas gdy papuga sprawia, że jest gładka, ale wisi przy bardzo dużych rozmiarach. Myślę, że jest to problem w jądrze Linuksa i sposób jego zapisu. To jest i pozostanie najgorszym koszmarem Linuksa wszechczasów.

— Mohith7548

32

Zgodnie z tym raportem błędu rozwiązałem go, dodając następujące wiersze

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

do /etc/sysctl.conf

i bieganie

sudo sysctl -p

— Philippe Gachoud
źródło

12

Chcesz wyjaśnić, co robią powyższe linie?

— nsane

3

@ nisargshah95 przepraszam, ale nie mam pojęcia, poszukaj siebie ;-)

— Philippe Gachoud

4

@ nisargshah95 Szczegóły problemu wyjaśniono w dwóch artykułach LWN połączonych w unix.stackexchange.com/a/107722/52205

— Rmano

1

Dziękuję, właśnie odkryłem, że mój Ubuntu 16.04 nie może zapisać dwóch plików 1,4 GB na USB bez tych dwóch linii, zamarzałem przez wiele godzin, to rozwiązany problem, kogo to obchodzi, czasami chce po prostu skopiować pliki i przenieść na.

— Mike,

1

Miałem wartości 5 i 60. Kontrolują one procent pamięci używanej do operacji dirty_background_bytesi dirty_bytesużywają bezwzględnych wartości bajtów. Rozwiązałem ten problem z drugą odpowiedzią, ale aby była trwała, dodaj ją sysctl.conf, zobacz tę odpowiedź . Tak więc, używając wartości procentowych, popraw je podczas aktualizacji pamięci.

— PeterM

20

Natrafiłem na podobny problem. Mój jest 64-bitowy Ubuntu 14.04. Po długiej walce znalazłem odpowiedź, która rozwiązuje mój problem. Dla łatwego użycia dodałem poniższe polecenia użyte w wyżej wymienionej odpowiedzi . Sprawdź odpowiedź, aby uzyskać szczegółowe wyjaśnienie.

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

Po użyciu powyższego polecenia system zaczął normalnie działać przy kopiowaniu plików.

Podziękowania dla @Rmano .

— Mahendran Sakkarai
źródło

2

Ustawienia współczynnika nie pomogły w moim systemie 12.04 z wolnym udostępnianiem NAS. Ale po ustawieniu bajtów bezpośrednio, jak tutaj sugerowano, mój system jest ponownie użyteczny podczas kopiowania na NAS.

— mivk

6

To pytanie ma 3 lata i nadal jest wymagane, aby uniknąć awarii systemu podczas kopiowania na pendrive. Kilka informacji: jeśli pendrive jest sformatowany przy użyciu Linux-a takiego jak ext4, tak się nie dzieje. Kiedy powiedziałem „nieużywalny system”, mam na myśli to, że wskaźnik myszy przestaje reagować i musisz nalegać, aby przesuwać go po ekranie, patrzysz na monitor systemu i nie ma żadnego nieprawidłowego użycia zasobów. Czy wszyscy ludzie jądra używają procesorów Intel 6. generacji i napędów SSD? Dlaczego nie zauważają tego podczas testowania.

— Hatoru Hansou

3

@HatoruHansou Czuję to samo, właśnie zainstalowałem świeżą wersję Debian Stretch i ten błąd występuje również tutaj. Wiem, że to nie zależy od dystrybucji, ale od źródeł jądra, ale ludzie, dlaczego to wciąż nie jest naprawione?

— Marecky

1

@Marecky Po krótkiej lekturze wydaje się, że dirty_bytes to nie tylko usb. Wpływają na wszystkie wejścia / wyjścia, więc po wykonaniu echa zmieniasz je globalnie na system, nie tylko na pendrivy. Myślę, że tylko w bieżącej sesji. Wygląda na to, że obecne wartości jądra są poprawione w myśleniu w nowszych urządzeniach pamięci masowej. Wolne pendrive cierpią jako efekt uboczny. Przepraszamy, brak linku, ale należy go łatwo znaleźć, wyszukując go w Google.

— Hatoru Hansou

3

Zobacz tę odpowiedź, aby była trwała

— PeterM

5

Mam podobny problem z zawieszaniem się systemu podczas kopiowania na dysk flash. Przesłałem raport o błędzie na ten temat: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1267648

W ramach obejścia stwierdziłem, że wyłączenie wymiany całkowicie eliminuje problem.

— Vladimir Rutsky
źródło

1

Niestety nie działało to dla mnie na Ubuntu 16.04.

— Programster

Nie działało też dla mnie na Ubuntu 16.04.3 LTS - to na laptopie Alienware 17 R2.

— AnthonyK

4

Tak, istnieją ustawienia jądra, które można dostosować, określając, ile danych należy oznaczyć jako zapisane, zanim zostaną zapisane na dysk. Zajrzyj tutaj, aby uzyskać dość wyczerpujący ich opis. W szczególności będziesz chciał znaleźć wartość dirty_ratio, która działa dobrze dla ciebie (jest na ogół zbyt wysoka dla komputera stacjonarnego / laptopa, ale nie ma jednej magicznej liczby, która działałaby dla wszystkich).

— Bandrami
źródło

2

Hej, czy mógłbyś mi zasugerować, jakie liczby muszę ustawić na podstawie specyfikacji mojego laptopa? patrz askubuntu.com/questions/713723/…

1

Miałem podobne problemy podczas kopiowania plików na exfatdysk. Miałem mniej problemów z użyciem ext4systemu plików na dysku twardym USB.

— Buzdygan
źródło

1

Miałem ten problem także na ext4

— PeterM

Fedora 27 (jądro 4.17.5-100) kopiuje z podłączonej przez USB wirującej rdzy do podłączonej pamięci flash USB. Wydaje się, że idzie to tak daleko, jak zamrażanie blokady ekranu w połowie zanikania. :-( ~~~

— David Tonhofer

1

Właśnie miałem dokładnie ten sam problem (w 2019 r.) Na Ubuntu 19.10, podczas kopiowania dużej liczby plików z dysku USB na dysk SATA. Oba systemy plików to ext4. Kiedy wyłączyłem swap, problem zniknął. Wygląda to na jakiś błąd w alokacji pamięci dla buforów dyskowych - najwyraźniej jądro próbuje przydzielić jak najwięcej pamięci dla buforów dyskowych, jak to możliwe w takiej sytuacji, co nie ma sensu (tworzenie buforów dyskowych w zamianie ...), lub po prostu błędnie oblicza rozmiar pamięci, niż można użyć do buforowania ...

— chaker
źródło