Gnom, nautilus kopiuje pliki na USB zatrzymuje się na 100% lub blisko

29

Miałem wcześniej podobne problemy, ale nie pamiętam, jak to rozwiązałem.

Kiedy próbuję skopiować coś na pamięć USB, z FAT, zatrzymuje się pod koniec, czasem na 100%. I oczywiście, kiedy przesyłam kartę pamięci gdzie indziej, nie zawiera ona kompletnego pliku. (plik to film!)

Próbowałem zamontować urządzenie z opcją mount -o flush, ale mam ten sam problem.

Sformatowałem pamięć USB za pomocą nowej partycji FAT ...

Masz pojęcie, co robię na zimno?

ps Wydaje mi się, że nie jest to związane z systemem operacyjnym, jakim jest Debian, i uważam, że radzenie sobie z dyskiem SSD nie powoduje tego.


źródło
3
Gdzieś spotkałem następujące wyjaśnienie sprawy. W przypadku, gdy kopiowanie zostało wykonane za pomocą pamięci operacyjnej, a wskaźnik pokazuje proces odczytu danych z dysku. Ale proces wyrównywania jest znacznie dłuższy, szczególnie w przypadku pamięci USB (może być 100 razy wolniejszy: na przykład wykręcanie 2 Mb / s przy 200 Mb / s odczytu) i więcej, jeśli używasz nie-rodzimych systemów plików, takich jak FAT lub NTFS w systemie Linux . Spróbuj więc poczekać na transakcję końcową, nawet jeśli zatrzymasz się na 100%, ale nie zamknij (co powinno oznaczać zakończenie).
Costas
tylko zastanawiam się, czy w ogóle można sprawdzić postęp w tej sytuacji ???
spróbuj sformatować pendrive z opcją zastąpienia wychodzących danych zerami To działa na My trancend 8GB pendrive
Akshay Daundkar
Dla każdego, kto napotka ten problem, po prostu sformatuj dysk w systemie NTFS.
Ricky Boyce

Odpowiedzi:

37

Dzieje się tak dlatego, że program mówi „zapisz te dane”, a jądro Linuksa kopiuje je do bufora pamięci, który czeka w kolejce na dysk, a następnie mówi „ok, gotowe”. Program uważa, że ​​skopiował wszystko. Następnie program zamyka plik, ale nagle jądro każe mu czekać, aż bufor zostanie wypchnięty na dysk.

Niestety program nie może powiedzieć, ile czasu zajmie opróżnienie bufora, ponieważ nie wie.

Jeśli chcesz wypróbować kilka sztuczek dla zaawansowanych użytkowników, możesz zmniejszyć rozmiar bufora używanego przez Linuksa, ustawiając parametr jądra vm.dirty_bytesna około 15000000(15 MB). Oznacza to, że aplikacja nie może uzyskać więcej niż 15 MB przed faktycznym postępem. (Możesz zmieniać parametry jądra na bieżąco, sudo sysctl vm.dirty_bytes=15000000ale zmuszenie ich do pozostania w trakcie restartu wymaga zmiany pliku konfiguracyjnego, /etc/sysctl.confktóry może być specyficzny dla twojej dystrybucji.)

Efektem ubocznym jest to, że komputer może mieć mniejszą przepustowość zapisu danych przy tym ustawieniu, ale ogólnie uważam, że warto zauważyć, że program działa przez długi czas, gdy zapisuje dużo danych, w przeciwieństwie do zamieszania związanego z posiadaniem program wydaje się być skończony ze swoim zadaniem, ale system źle się opóźnia, ponieważ jądro wykonuje właściwą pracę. Ustawienie dirty_byteswzględnie małej wartości może również pomóc zapobiec przestaniu systemu w przypadku braku wolnej pamięci i uruchomienia programu, który nagle zapisuje dużo danych.

Ale nie rób tego zbyt małego! Używam 15 MB jako przybliżonego oszacowania, że ​​jądro może opróżnić bufor na normalnym dysku twardym w 1/4 sekundy lub mniej. Dzięki temu mój system nie czuje się „opóźniony”.

bez danych
źródło
Szukałem rozwiązania tego problemu przez rok lub dłużej, myślałem, że to tylko błąd w systemie Linux. Wielkie dzięki.
Sidahmed,
1
Linux noob tutaj, czy ktoś może opublikować, jak zmienić wartości <dirty_bytes>?
Brofessor
@Brofessor Och, przepraszam, powinienem opisać to oficjalną nazwą zamiast szczegółów / proc. Odpowiedź została zaktualizowana.
danych
1
Jest to podobne do unix.stackexchange.com/questions/107703/… --- powinno zostać naprawione, ale wierz mi, nie jest. Musiałem dodać go do Ubuntu 18.04 przestać zachowywać się śmieszne ...
Rmano
Działa również na Fedorze 30. Jestem zaskoczony widząc takie głupie zachowanie nawet w nowoczesnych dystrybucjach Linuksa.
sziraqui
0

Stare pytanie, ale wydaje się, że problem wciąż się pojawia. Ustawienie bufora na 15 MB, jak sugerowano tutaj, nie działało na Ubuntu 19.04 i spowodowało zatrzymanie mojego systemu.

Próbowałem skopiować plik 1,5 GB na pusty (nowo sformatowany) dysk FAT32 16 GB. Pozwoliłem mu działać przez około 10 minut, aby zobaczyć, czy się skończy, bez powodzenia.

Ponowne formatowanie do NTFS pozwala zakończyć operację w mniej niż 10 sekund. Nie wiem, dlaczego miałoby to mieć znaczenie, ponieważ FAT32 powinien pozwalać na wszystko poniżej 2 GB, ale wydawało się, że działa dobrze. Nie jest to idealna poprawka dla dysków, których chcesz używać w systemie MacOS, ale łatwe obejście dla wszystkich innych przypadków użycia. Wyobrażam sobie, że exFAT działałby podobnie, ale go nie testowałem.

Jacob Jones
źródło