Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Kopiowanie plików na dyski zewnętrzne USB - poradnik
#11
0
Możemy dalej opierać się na przypuszczeniach lub po prostu znaleźć przyczynę w oparciu o dane wskazane przez morfika.
Odpowiedz
#12
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
Odpowiedz
#13
0
U mnie przy wielu próbach. nigdy nie było problemu przy FAT32, a przy NTFS i exFAT zawsze. Gdy odczekałem około minuty, a przy pendrive kilka minut, to kopiowanie było prawidłowe.

Dodano po pewnym czasie:
Precyzyjnie rzecz ujmując przy FAT32 gdy wskaźnik kopiowania osiągnie szybko zero, to nie znika z pulpitu do czasu prawidłowego skopiowania. Czasem nawet trwa to kilka minut na pendrive'ie. Natomiast przy NTFS gdy osiągnie zero, natychmiast znika z pulpitu i jeżeli odmontuję i wyjmę, to skopiowany plik jest niekompletny. Sprawdzę jeszcze na starym, wolniejszym laptopie z zainstalowanym Mintem Mate w Legacy.

Na starym lapku, jest to samo. Dla mnie nie jest to problem. Mam czas i mogę chwilę poczekać. Trudno wymagać, żeby obsługa NTFS, czy exFAT była w Linuksie perfekcyjna. W Windowsie, czy w Macu jest zdecydowanie gorzej z obsługą systemu plików Linuksa ext. Trzeba korzystać z dodatkowych programów (w Macu Paragon jest płatny, a w Windowsie Linux Reader pozwala tylko na odczyt), a twórcy systemów maja to gdzieś.
Tylko dwie rzeczy są nieskończone: wszechświat oraz ludzka głupota, choć nie jestem pewien co do tej pierwszej.
Albert Einstein
Odpowiedz


Skocz do:




Użytkownicy przeglądający ten wątek: 3 gości