Ubuntu 20.04 - psujące się dane na pendrive

0

Posiadam Ubuntu Linux 20.04 (pierwotnie zainstalowałem 19.10, ale sam się zaktualizował do najnowszej wersji) na dwóch komputerach (stacjonarny i laptop).

W obu komputerach, często, jak nagrywam na pendrive 64GB (mam dwie sztuki i w obu jest ten problem) sformatowany w NTFS plik o wielkości gdzieś powyżej 1GB, to bardzo często plik nagrywa się uszkodzony (chyba nawet za każdym razem bez wyjątku, tyle, że po dwóch, trzech próbach przepycham plik przez sieć lub FTP). Nagrany plik jest ucięty (bardzo łatwo to stwierdzam, bo jest to archiwum ZIP lub RAR). Nierzadko również był naruszony system plików, przez co były komunikaty błędów przy otwieraniu różnych plików, a także bywałem zmuszony do sformatowania pendrive.

Przy małych plikach (do kilku megabajtów, nawet, jak jest dużo takich plików) nie mam takich problemów. Na tym samym laptopie wcześniej miałem Windows 10 i takich problemów nigdy nie było. Pendrive używałem też w innym komputerze stacjonarnym, w którym był Windows 8 i też zero takich problemów. Oczywiście przed wyjęciem pendriva uruchamiam odmontowanie w systemie operacyjnym.

Co może być przyczyną i jak to rozwiązać (podział dużych plików na części nie uznaję za rozwiązanie problemu)?

1

A myślałeś, żeby odmontować urządzenie przed wysunięciem pendrive'a?

0
enedil napisał(a):

A myślałeś, żeby odmontować urządzenie przed wysunięciem pendrive'a?

Przecież napisałem, ze zanim wyciągnę pendrive z komputera, to robię odmontowanie.
W międzyczasie sprawdziłem kartę SD 32GB z czytnikiem, którą używam w roli pendrive. Po nagraniu plików, jak odmontuję, to pendrive przestaje być widoczny w systemie, ale jeszcze kilka minut pracuje (przygasa dioda sygnalizująca pracę) i dopiero jak przestanie przygasać, to wyciągałem i plik jest nagrany poprawnie. Natomiast pendrive 64 GB nie ma żadnej diody. Pod Windows, oba pendrive można było odłączyć zaraz po bezpiecznym usunięciu, nawet po nagraniu dużej ilości danych.

1

No to w takim razie zrób eksperyment - po odnotowaniu zostaw pena w USB na 20 minut i potem dopiero wyjmij.

1

Wpisz w konsoli: "sync" i poczekaj do pojawienia się promptu shella. Potem dopiero wyjmij pendrive.

0
cerrato napisał(a):

No to w takim razie zrób eksperyment - po odnotowaniu zostaw pena w USB na 20 minut i potem dopiero wyjmij.

Zrobiłem ten eksperyment i dane nagrały się poprawnie.

vtx napisał(a):

Wpisz w konsoli: "sync" i poczekaj do pojawienia się promptu shella. Potem dopiero wyjmij pendrive.

Będę pamiętać na przyszłość. Po co tak system tam utrudnia sprawę? Pamiętam dobrze czasy, gdy popularne były dyskietki. Tam przy nagrywaniu plik był zapisywany na nośniku, co było sygnalizowane dźwiękami pracy napędu i świeceniem diody na nim. Po skończeniu nagrywania napęd przestawał pracować i dioda gasła, w tym momencie można było wyjąć dyskietkę bez szkody dla danych (oczywiście zdarzały się uszkodzone dane, ale z innych powodów). Naprawdę nie da się, żeby z pendrivami było tak samo, tylko muszą być jakieś bufory, synchronizacja, bezpieczne odmontowanie i oczekiwanie na możliwość odłączenia?

1

Nie wiem czy tu może być problem, ani nie jestem Liniuxowcem ale raz piszesz, że chodziło o pendrive'a innym razem, że o czytnik kart SDHC na USB. Czytnik to odrębne urządzenie, które może mieć np. jakiś rodzaj bufora. Ty zapisujesz na czytnik, czytnik mówi przyjąłem dane, ale zapis dokonywany na karcie jeszcze ma miejsce. Dlatego dioda miga.
Być może do Twojego czytnika są inne sterowniki dostępne, które eliminują ten problem.

2

Ogolnie Linuksy mają jakiś bufory. Nie wiem, czy to kwestia jądra, czy jakichś innych ustawień, ale na kilku dystrybucjach tak miałem (aktualnie Mint 20), że podczas kopiowania czegoś na pendrive to najpierw transfer zapierdziela, w kilkanascie sekund dochodzi do 3/4 pliku o objętości paru GB, po czym pasek postępu się zamraża. Pendrive sobie mruga, pasek stoi, po paru minutach już w normalnym tempie całość dochodzi do końca.

Wygląda to, jakby system gdzieś te dane buforowal. Środowisko graficzne nie ma o tym pojęcia - wrzuca dane do jakiegoś strumienia, ktory system obsługuje z wielką szybkością (stąd wrażenie szybkiego działania pendrive na początku), a potem nagle bufor się zapełnia i dalsze kopiowanie czeka, aż się on opróżni.

Jedyna różnica jest taka, że Mint nie pozwala odłączyć urządzenia do czasu aż bufor się opróżni i wszystkie dane realnie trafią na nośnik, a jak widać Ubuntu ma z tym problem.

1
andrzejlisek napisał(a):

Posiadam Ubuntu Linux

W obu komputerach, często, jak nagrywam na pendrive 64GB (mam dwie sztuki i w obu jest ten problem) sformatowany w NTFS

Sprawdź czy podobnie się dzieje jeśli pen jest sformatowany w FAT32 albo exFAT (nie wiem czy Linuksy defaultowo już umiejo w exFAT...)

2

Będę pamiętać na przyszłość. Po co tak system tam utrudnia sprawę? Pamiętam dobrze czasy, gdy popularne były dyskietki. Tam przy nagrywaniu plik był zapisywany na nośniku, co było sygnalizowane dźwiękami pracy napędu i świeceniem diody na nim. Po skończeniu nagrywania napęd przestawał pracować i dioda gasła, w tym momencie można było wyjąć dyskietkę bez szkody dla danych (oczywiście zdarzały się uszkodzone dane, ale z innych powodów). Naprawdę nie da się, żeby z pendrivami było tak samo, tylko muszą być jakieś bufory, synchronizacja, bezpieczne odmontowanie i oczekiwanie na możliwość odłączenia?

Generalnie to w Linuxie jest tak, że używana jest cała dostępna pamięć RAM na bufory i cache dyskowe. Nie pamiętam dokładnie kiedy ale takie podejście pojawiło się w okolicach kerneli 2.4 lub 2.6. Efektem jest to o czym też pisze @cerrato - że początkowo kopiowanie zasuwa bardzo szybko a po dojściu do pewnego momentu (zapełnienia RAM-u) nagle zwalnia bo już nie ma miejsca na buforowanie i rzeba poczekać aż dotychczasowo zbuforowane dane zostaną zrzucone na nośnik. A to podejście wynikało z tego że pamięci RAM taniały i ludzie coraz więcej jej mieli w kompach i żal było nie wykorzystać jej jako bufor żeby leżała odłogiem. Odnośnie pytania - czemu system utrudnia sprawę - to raczej ułatwia :) A to dlatego, że dana aplikacja nie musi oczekiwać na zakończenie operacji I/O na dysku bo system odbiera od niej prawie tyle danych ile ma wolnego RAM-u. Aplikacja w tym momencie może sobie biec dalej a nie być zamrożona operacjami I/O (operacje I/O są dosyć istotne i są blokujące) i user ma ogólne wrażenie większej szybkości działania aplikacji. Odczyty i zapisy w większości dużych OS-ów są buforowane. Nawet taki DOS go miał w SMARTDrive'ie. Używanie DOS-a bez SMARTDrive'a to była męczarnia.

Poza tym system operacyjny mając bufory i cache jest w stanie pogrupować sobie pojedyncze zapisy np. w jeden większy blok danych i zapisać go na nośniku za jednym razem. Wyobraź sobie, że program zapisuje po 100 bajtów kilkaset razy bez buforowania - kernel musiałby te kilkaset razy uzyskać dostęp do nośnika, a tak może sobie te żądania zapisu pogrupować w większe kawałki i w mniejszej ilości cyklu zapisu zrzucić je na dysk.

Co do stacji dyskietek - to problem był taki sam pod Linuxem - trzeba było odmontować dysk i poczekać aż bufory zostaną zrzucone na nośnik (odmontowanie wymusza zrzut buforów na dysk bo odmontowanie jest operacją blokującą). Teoretycznie można było wyciągnąć dyskietkę bez odmontowania - ale efekt był taki jak ty masz. Jedyną różnicą jest chyba obecność tak jak piszesz diodki na napędzie floppy - bo nie wszystkie pendrive USB ją mają.
Być może rozwiązaniem byłoby zmniejszenie ilości RAM przeznaczonej na bufory i cache, ale tak z głowy to nie przypomnę sobie jak się to w kernelu ustawiało i czy w ogóle teraz jest to dostępne do ustawienia.

A tak swoją drogą to bez cache-owania i buforowania operacji I/O to niejedna osoba wkurzyła by się - dlaczego ten Linux tak wolno listuje katalogi albo tak wolno wczytuje/zapisuje pliki. Dodatkowo odczyty plików można wykonywać w trybie z wyprzedzeniem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0