USB pendrive-ra másolástól szaggató rendszer

Fórumok

Sziasztok!

Amióta a jelenlegi helyemen dolgozok, gyakran van szükségem pendrive-ra, hogy itthonról vigyek be rajta dolgokat. Egy TOSHIBA USB 3.0-ás pendrive lenne az.
Na már most az volna a gond, hogy amikor írok adatokat a pendrivera - nagy fájlokról van szó - és teszem azt mindezt Nemo-ból csinálom, akkor a rendszer kegyetlenül belassul. Gyakran 100% cpu használat is észrevehető. Kövezzetek meg, de egy sima pendriveos másolás nem szabadna, hogy kikészítse a rendszert, nem? Most újítottam gépet, ez már USB 3.0-as lappal is ilyen, de ha USB 2.0-ás portra dugtam a régi gépen, akkor is ugyan ez volt, tehát nem az interfész a probléma.

ExFat fájlrendszert használok, mivel Windowsos gépekkel cserélek fájlokat. FAT32-nél sincs különbség.
Van, hogy az elején szuper gyorsan indul a másolás, majd visszalassul kb 8MiB/s -ra a sebesség és rendesen szaggat minden... az egérkurzor, a programok.
Olvastam valahol, hogy ez egy linuxos bug és a memóriakezeléshez van némi köze, de valódi megoldást nem találtam.

Egyetlen workaround, ha nyitok egy terminált és midnight commanderrel másolok. Ez nem túl kényelmes, de legalább működik.

Van bárkinek valami ötlete? Kernel fordítósdi meg ilyesmi nem játszik, túl macera. (egyszer olvastam egy ilyet)

# Linux Mint 18.1 + kernel 4.8

Hozzászólások

Van, hogy az elején szuper gyorsan indul a másolás, majd visszalassul kb 8MiB/s -ra

Persze, hiszen az elején RAM-ba másolsz, a disk cache-t eteted. Utána kezdi a kernel kitolni a a mass storage eszközre.

Ugyan nem tudom, mi a jelenség oka, de arra tippelek, hogy az USB driver blokkolós, amíg busy a device, vár rá a driver, viszont az kernelben van, s nem adja vissza a CPU-t. De csak egy halvány tipp.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kipróbáltam a vm.*-os cuccot. Kicsit felemás. Először 60MB/s -al kezdte. Aztán újrakezdtem, akkor nyomta a szokásos 8MB/s-ot. Egy darab beakadás volt, mikor épp a böngészőt gördítettem, de lehet az az oldal miatt volt. Viszont a másolás... a folyamatjelző megy 3mp-ig... áll egy darabig, majd ismét megy 3mp-ig... mint ha gondolkodna, vagy akadozna a másolás. De majd mindjárt másolgatok még... kitesztelem alaposan.
Szerk.: Úgy tűnik, igen, megoldja. Köszönöm!

Linux Mint 64-bit w/ Cinnamon

Ez természetes. Először az alkalmazás sokat tud másolni, a kernel RAM-ba, disk cache-be teszi. Közben elkezdi kiírni 8 MB/s-mal. Az elején látszólag gyors, mert például 1 GB-ot nagyon gyorsan be tud másolni disk cache-be. Amikor a kernel úgy dönt, hogy nem növeli a cache méretét, már csak olyan sebességgel tudod etetni a cache-t, ahogy a másik végén ürül. Mint egy nagy FIFO. Viszont lehet, hogy a kernel kiír mondjuk 100 MB-ot a cache-ből úgy, hogy az alkalmazástól nem vesz át semmit. Ekkor azt tapasztalod, hogy elakadt. Aztán mondjuk hirtelen átvesz egy 100 MB-os blockot, ekkor meg úgy tűnik, hogy egy pillanatra nagyon gyors.

A vége is érdekes. Az alkalmazás szerint elkészült, már lehet, hogy be is zártad az alkalmazást, de a kernel a cache-ből még írja ki, ami ott van. Lehet, hogy az utolsó 1 GB-ot még. Ezért nem szabad kivenni a pendrive-ot umount nélkül. Persze ilyenkor hiába mondasz neki umount-ot, lehet, hogy csak 5 perc múlva tér vissza azzal, hogy leválasztotta a kötetet. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyetlen workaround, ha nyitok egy terminált és midnight commanderrel másolok.

Azaz terminálban elfogadható a sebesség? Lehet, hogy csak a grafikus fájkezelőkkel van probléma?

________________________________________
https://sites.google.com/site/eutlantis/

Én arra gondolok, hogy a grafikus fájlkezelő alatt egy "böhöm" szoftveres infrastruktúra (D-bus stb) van, és másoláskor ennek nagy az overhead-je, illetve nagy a "hibasűrűsége", míg az mc csak a kijelzéshez használ X-et és a tényleges másolást "közvetlenebbül" végzi.

Jó lenne tesztelni, hogy a cp -r vagy rsync -av parancsok terminálban hogyan muzsikálnak.

________________________________________
https://sites.google.com/site/eutlantis/