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
- 1847 megtekintés
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
- A hozzászóláshoz be kell jelentkezni
Én azt olvastam, hogy a nagy memória lapok (vagy mi?) az oka, illetve a 64-bites címzés.
Linux Mint 64-bit w/ Cinnamon
- A hozzászóláshoz be kell jelentkezni
Ubuntu 16.10-el én is szoktam hasonlókat tapasztalni.
- A hozzászóláshoz be kell jelentkezni
LMGIFY volt mar? https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1208993
ui: az igazi kerdes az, hogy desktopra szant disztribucio (tipikusan: Ubuntu) miert szerverre optimalizalt beallitasokkal telepul (lasd meg vm.swappiness, a BT egerem teljesen hasznalhatatlan volt a default 60-as beallitassal).
- A hozzászóláshoz be kell jelentkezni
Hidd el, jó sokat keresgéltem.
Linux Mint 64-bit w/ Cinnamon
- A hozzászóláshoz be kell jelentkezni
De most akkor mukodik neked a vm.* parameterek allitgatasa vagy sem? Eddig mit probaltal, milyen eredmennyel?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
:thumbs up:
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Jó példája a nautilus-ban a "progress pie", egy csomó ideig ott virít az eszköztáron.
- A hozzászóláshoz be kell jelentkezni
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/
- A hozzászóláshoz be kell jelentkezni
Igen, úgy tűnik. Vagy csak a folyamatprioritások miatt, mivel az X nagyobb prioritással fut, mint az mc, nem tud annyi erőforrást megzabálni. (tipp) A Nemo (nautilus) viszont az X-ben fut ugye.
Linux Mint 64-bit w/ Cinnamon
- A hozzászóláshoz be kell jelentkezni
Ezt erőst kétlem, de nézz közben top-ot, s ki fog derülni. Az mc az őt tartalmazó terminálon együtt X-en van, legalább is vélelmezem, hogy nem váltottál karakteres konzolra.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Valóban. Csak tipp volt.
Linux Mint 64-bit w/ Cinnamon
- A hozzászóláshoz be kell jelentkezni
É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/
- A hozzászóláshoz be kell jelentkezni
A D-Busnak ehhez köze sincs. FYI.
- A hozzászóláshoz be kell jelentkezni
Mi a cpu ütemeződ?
- A hozzászóláshoz be kell jelentkezni
zsigmond@kisszoba ~ $ cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
Linux Mint 64-bit w/ Cinnamon
- A hozzászóláshoz be kell jelentkezni