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

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.

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

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.