0
(03-02-2022, 09:34)omkar napisał(a): Nie chodzi o uszkodzenie danych, tylko o błędne wskazanie zakończenia pobierania.
Te "błędne wskazania" wynikają właśnie ze zbyt dużego bufora pod diry pages. Ten problem jest najbardziej widoczny, gdy kopiuje się dane z bardzo szybkich nośników na bardzo wolne nośniki, np. z dysku hdd/ssd na pendrive (zwłaszcza po usb2). Wtedy jeśli system ma bardzo dużo RAM (kilkanaście GiB) potrafi załadować sobie cały kopiowany plik natychmiast do RAM (z prędkością setek MiB/s) i aplikacja co te dane kopiuje odbiera to jako zakończony proces kopiowania, bo wszystkie dane z dysku zostały już odczytane. Nawet jeśli masz mniej RAM, to spora część pliku zostanie natychmiast załadowania do RAM, np. 300M z 1G, i wtedy po "zakończonym procesie kopiowania" te 300M system dalej kopiuje z RAM na docelowy nośnik ale nie ma już na ten temat wizualnej informacji w tej aplikacji. Dlatego to może dać mylne wrażenie, że dane się skopiowały już, podczas gdy system je dalej kopiuje i dlatego też prosiłem cię o pokazanie ile danych masz w dirty pages po "zakończonym" (twoim zdaniem) procesie kopiowania danych na nośnik zewnętrzny.
(03-02-2022, 09:34)omkar napisał(a): Być może nie dotyczy to wszystkich dysków USB sformatowanych w NTFS i exFAT, ale przynajmniej na niektórych musisz odczekać ponieważ kopiowanie nie będzie kompletne. Nie mam co do tego najmniejszych wątpliwości, a o tym problemie ludzie pisali na forach. Przypuszczam, że błąd związany jest z niedoskonałą obsługą obcych formatów plików, co mnie nie dziwi.
Ten problem, o którym wspomniałem wyżej, dotyczy każdego nośnika, nawet jeśli ma partycje sformatowane systemem plików EXT4 -- ten problem jest niezależny od systemu plików. W kernelu 5.16 zdaje się, że coś w tej kwestii zostało poczynione.
By uzupełnić jeszcze potrzebne dane, przydałoby się podać info o tym ile masz RAM, czy kopiowanie było po USB2/3 (jaka była średnia prędkość kopiowania) i jak wygląda wyjście tego poniższego polecenia:
Kod:
# sysctl -a | grep -i dirty