Fájl mozgatásnál rohamos lassulás

Fórum: 

Néhány napja olvastam, hogy az Ubuntu Mate vezető fejlesztője - Martin Wimpress - segítséget kért egy komoly rendszerhiba megoldására.

A hiba lényege, hogy 1GB körüli másolásnál a rendszer hihetetlenül belassul, ennél nagyobb fájlok mozgatása esetén pedig össze is tud omlani. Kiadtak egy javítást erre (Gnome Virtual File System hiba) és ennek a javításnak a tesztelésére kérték meg a felhasználókat egy weboldalon keresztül.

A kérdésem az, hogy a 18-as Mint-ben tapasztalt e valaki hasonlót, ugyanis nálam pontosan ugyanez történik másoláskor. Mind a 18.1, mint a 18.2 futtatása közben az 1GB-ot meghaladó fájlok másolása kínszenvedés, egy 10 GB-os file áthelyezése akár rendszeren belül, akár külső meghajtóra, lehetetlen, mert lefagy a rendszer.

Kellemetlen, de nagyobb fájlok másolásakor be kell kapcsolnom a Win10-et, mert a Mint-ről nem megoldható.

Jelenleg Linux Mint 18.2 Cinnamon 64-bit fut nálam, asztali környezetben. A kernelre is gondoltam, de a 4.8, 4.10 és a most futó 4.11 alatt is ugyanaz történik.

Tud valaki megoldást erre? Van olyan javító kulcs, amivel a Mint-ben is orvosolható ez a hiba? 

 Egy 1,6 Gb-os filmet külső

 Egy 1,6 Gb-os filmet külső meghajtóra 3 perc 10 másodperc alatt tett át.

A másolási sebesség 110 MB/s indult és a végére már csak 7,5 MB/s volt. Tehát az én másolásom jelentősen lassabb mint keraform tesztje.

Ahogy nő az átmásolandó anyag nagysága úgy romlik rohamosan a másolási sebesség, és ahogy írtam 10GB környékén össze is omlik a rendszer.

A rendszeremet korábban már írtam, de a gép paramétereit nem, így ezt most pótlom:

Linux Mint 18.2 Cinnamon 64-bit
Kernel: 4.11.0-14 generic
Desktop: Cinnamon 3.4.6 Sonya
CPU: Dual core Intel5 7400
Clock: 3GHz x 4
RAM: 8 GB

 

Még egy adalék. Miután átmásolta a filmet a külső meghajtóra, rákattintok a biztonságos eltávolítás-ra és itt kezdődik az igazi rémálom. 5-10 percig végez valamilyen ismeretlen feladatot és addig nem engedi eltávolítani a meghajtót.

Így egy 1,6GB -os film átmásolása 8-13 percet vesz igénybe...

Értékelés: 

0
Még nincs értékelve

Kipróbáltam GNOME Commander

Kipróbáltam Nemo és GNOME Commander alatt is. Sajnos az eredmény ugyanaz. Kb. 1GB-ig hasít, azután hirtelen belassul és onnantól csak vánszorog a másolás.

Értékelés: 

0
Még nincs értékelve
kimarite képe

RE: Fájl mozgatásnál rohamos lassulás

#1 A nagy fájlok másolása miatt lassul a rendszer, a molyolás a másolás végén a szinkronizálás.
Az rsync is megoldás lehet
https://serverfault.com/questions/43014/copying-a-large-directory-tree-l...
vagy más fájlrendszer (példa).
https://github.com/zfsonlinux/zfs/issues/687
Itt is írnak pár dologról:
https://www.zylk.net/en/web-2-0/blog/-/blogs/how-to-copy-files-in-linux-...

Összegezve a nagy fájlok másolásakor jelentkező lassulás
-- a biztonságos másolás megkövetelése miatt van így beállítva
-- a fájlrendszer egyes beállításai befolyásolják (alapvetően nem érdemes ezeket és főleg emiatt piszkálni)
-- lehetséges a dd vagy az rsysnc alkalmazásokra scriptet írni, ha ennyire fontos a sebesség .., mert nagyon nagy fájlokat másolására van igényed. És akkor a cp-t is ide veheted, tesztelve a három megoldás különbségét.
-- továbbá a lemezek sebessége is befolyásolja a másolást.

Érdemes lehet az alábbi parancsra rákeresni pl. a Google-lel (úgy látom, azt már ismered):
-- a kimenettel együtt közlöm

cat /proc/vmstat | egrep "dirty|writeback"
nr_dirty 12264
nr_writeback 5122
nr_writeback_temp 0
nr_dirty_threshold 19093
nr_dirty_background_threshold 9535

Tájékoztatás: bár a Windows talán gyorsabban másol
('mondják', de -úgy látom- nincsen így:
https://social.technet.microsoft.com/Forums/windows/en-US/62a1926b-12ea-...
https://answers.microsoft.com/en-us/windows/forum/windows_10-files/copy-...
https://www.tenforums.com/general-support/7009-file-explorer-extremely-s...)
talán nem annyira pontosan, mint a Linux (és fájl rendszerei). Én így tudom, persze, lehetséges más vélemény is.

-----

Úgy döntöttem, válaszolok. Kaptam egy tanácsot nemrég egy másik fórum összejövetelén ... *. Példa:
Hogyha azt kérdezem, linkelnéd Martin hozzászólását,
és erre kapok egy Google keresési találatot (sort) egyetlen URL helyett,
(https://www.google.com/search?q=Martin+Wimpress+Gnome+Virtual+File+System)
és ezek után még a keresési találatra is cikként hivatkozol (bár, nem hiszem, hogy összevesztünk volna valamikor is, tehát az én hibám biztos nem, hogy ilyen slendrián válaszokat adsz): „Mivel a cikkben 'cut-n-paste move files' szerepel, kipróbáltam, hogy mi van akkor, ha nem másolom, hanem a Kivágás/Beillesztés funkciót használom.
[*] Szóval azt a tanácsot kaptam, hogy ilyen 'stílusú' kérdezőknek egyáltalán ne válaszoljak semmit. És tudod, mit, ... valahol igazuk is van: Amilyen az adjon Isten, olyan a fogadj Isten. Nincs harag.

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Fájlok mozgatásával kapcsolatos tapasztalatomat osztom meg ubuntu 16.04.3-as rendszerrel:
Hálózaton belüli gépről-gépre másoláskor a folyamatjelző tökéletesen szinkronban mutatja a folyamatokat,ugyan ez a helyzet, ha pendrive-ról, vinyóról másolok a gépre,de ha a gépről másolok külső adathordozóra,akkor elöször a 8GB ramomba másol a fájlkezelő, ami villámgyors,majd a memoriából másol a külső adathordozóra,lassan,de a folyamatjelző csak a memóriába másolást mutatja helyesen,a külső adathordozóra másolás kezdetekor már 100%-elkészültséget mutat,holott,csak ekkor kezdi el kimásolni az adathordozóra az adatot.ami hosszú percekig tart.Tehát ha azt meglehetne oldani (úgy mint a windowson), hogy közvetlenül másoljon a-ból b-be,akkor a folyamatjelző végig helyesen mutatná a munkamenetet.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Helyreigazítás

@#10 Igen, mindenben igazad van, a két személy különbözőségére én is rájöttem, de már inkább rányomtam a Kilépés-re ;). Valójában tényleg az a helyzet, hogy az áthelyezés gyors (elvárt) és a másolás lassú. És erre az utánad szóló ad magyarázatot, tehát, hogy nem 'on the fly' történik a másolás, hanem a RAM-ba. A további félreértések elkerülése végett megpróbálok utána nézni megoldásoknak. De ... ha egyes számban hivatkozik a kérdező a cikkre (a kiemelés emiatt), akkor csak tudná linkelni. :-)

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Tovább kutatva a belassulási jelenséget másoláskor, az általam tapasztaltak egybeesnek a neten talált magyarázattal.
32 bites Linux Mint 18.2-es rendszeren 4.4-es kernelnél nem jelentkezik a probléma, 64 bites és újabb kernelekkel már igen.
Tehát kernel szintű a gond,átmeneti megoldásként a cache méret csökkentését javasolták a legtöbben,de ezzel én nem kisérleteztem,gondolom kimarite majd ezt is számba veszi.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

#13 Akkor használd a 4.4-es kernelt. :-)

Csak javasolni tudom a 4.9.x-et, mert -igaz, Debian alatt- teszteltem:
-- 2-7GB másolása/áthelyezése egyaránt: 2-8 perc
-- 10-15GB másolása/áthelyezése egyaránt: 8-12 perc

Másik kernel telepítése innen kiindulva,
http://kernel.ubuntu.com/~kernel-ppa/mainline/
és folytatva pl. a legújabb 4.9.x verziójú kernellel.
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/
(a dpkg-val telepítve ez a kernel verzió verziójában tovább nem frissül!)

-- készítesz egy munkakönyvtárat
(ha még nem létezik ... a saját könyvtáradban)

mkdir tmp

-- belépsz a könyvtárba

cd tmp

-- letöltés
(alábbi három csomagot kell letölteni)

32 bit

wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-image-4.9.46-040946-generic_4.9.46-040946.201708300532_i386.deb
wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-headers-4.9.46-040946-generic_4.9.46-040946.201708300532_i386.deb
wget-c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-headers-4.9.46-040946_4.9.46-040946.201708300532_all.deb

64 bit

wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-image-4.9.46-040946-generic_4.9.46-040946.201708300532_amd64.deb
wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-headers-4.9.46-040946-generic_4.9.46-040946.201708300532_amd64.deb
wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-headers-4.9.46-040946_4.9.46-040946.201708300532_all.deb

-- telepítésük
(a parancs minden .deb végű csomagot telepít a tmp könyvtárban: ugye, csak a három DEB van ott?!)

sudo dpkg --install *.deb

-- megnézed, javítani kell-e valamit

sudo apt-get -f install

-- ha nem, kilépsz a könyvtárból

cd

-- és bezárod a terminált

exit

-- majd a rendszer újraindítása után ezzel a kernellel indítasz.

-- dmesg kimeneteket nézegetsz (van-e valami új 'érdekesség'.
-- ha nem vált be a dolog, akkor érdemes lehet eltávolítani a kernelt.
-- mindezt saját felelősségre teszed.
-- a biztonság érdekében használhatsz Systemback visszaállítási pontot.

-----

Erre még mindig választ várok:
(biztosan mindenki érti, mire gondolok: mert már kezd érdekelni az a 'bizonyos' jelentés. Az egyszer már kért válasz megérkezése előtt nem töröm magam én sem túlzottan a válasz adással, ki hogy érti ..., úgy lesz.)

Néhány napja olvastam, hogy az Ubuntu Mate vezető fejlesztője - Martin Wimpress - segítséget kért egy komoly rendszerhiba megoldására.

A hiba lényege, hogy 1GB körüli másolásnál a rendszer hihetetlenül belassul, ennél nagyobb fájlok mozgatása esetén pedig össze is tud omlani. Kiadtak egy javítást erre (Gnome Virtual File System hiba) és ennek a javításnak a tesztelésére kérték meg a felhasználókat egy weboldalon keresztül.”

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

@#15 Hm ... . Azt nem tudom, mit kérdezősködtök ennyit, ha ott a megoldás. :-)
Azaz a Main tárolóban levő Gvfs csomag bugja ez, és a Proposed (előzetes, néha nem egészen stabil) verzió megoldja, ... és gondolom, majd a Main tárolóban is javítva lesz.

Fel kell venni a Xenial Proposed tárolóját, majd -a leírás szerint- frissíteni a csomagot.

sudo apt update
sudo apt install gvfs/xenial-proposed

Majd újratölteni a Caja fájlkezelőt

caja -q

és kész.

Nálatok ez nem oldotta meg? Próbáltátok?
Mint említettem, nálam szintén MATE, szintén Caja, és sem a másolással, sem az áthelyezéssel semmi gondom. És ez egy Debian Stretch. Bugos az Ubuntu csomag, jelentsük ki. És ennyi. Köszi a linket. Van még kérdés?

Értékelés: 

0
Még nincs értékelve
kimarite képe

Re: Fájl mozgatásnál rohamos lassulás

@#2 Idézet, válaszokkal, tippekkel:

Egy -a Nemo szerint- 4.0 GB-os, és egy 6.0 GB-os filmet másoltam a merevlemezről egy USB-s külső meghajtóra.
A másoláskor a 10.1 GB-os adatmennyiség átmásolásához 5 perc 50 másodperc kellett.
-- előfordulhat az, hogy USB 3.0 csatlakozót használtál?

A mérkőzés állása:
1 percnél 2.0 GB 32 MB/s
2 percnél 3.6 GB 30 MB/s
3 percnél 5.4 GB 29 MB/s
4 percnél 7.0 GB 29 MB/s
5 percnél 8.7 GB 29 MB/s volt.

Ha átlagot számolok, akkor 1 perc alatt 1.8 GB, vagy másképpen 35 másodperc alatt másolt 1 GB-ot.

Ezután ugyanezt a két fájlt átmásoltam a /media/user/Adattár/JDownloads mappából a /home/user/Videók mappába, ekkor az alábbiakat kaptam:
Az átmásolásához 5 perc 55 másodperc kellett!
-- 5 másodperc szerintem nem nagy különbség 10GB másolásakor sem, a másolást a rendszer működése is befolyásolja, továbbá a merevlemez állapota, és gyárilag garantált sebessége.
-- az általam közölt értékeket IDE (P-ATA) HDD-nél mértem, tehát SATA nem volt sehol. Bár ..., bocs, mégsem. Egy külső meghajtóra másoltam a belső IDE-ról, de USB 3.0 csatlakozó ezen a gépen még sehol. Kis gondom, hogy vélhetően a külsó meghajtó tápja -mindeközben, valahol az időben (ma)- megadta magát, mert a LED villog, és nem ég folyamatosan. Van még egy ilyenem, de ez nem jó hír ... . Remélem, nem a lemez adta meg magát, nem túl régi ... .

1 percnél 2.4 GB 40 MB/s
2 percnél 5.0 GB 41 MB/s
3 percnél 8.0 GB 44 MB/s
4 percnél 8.5 GB 36 MB/s
5 percnél 9.0 GB 30 MB/s volt.

Bár a részeredmények itt sokkal jobbak, a másolási sebesség 4 percig sokkal nagyobb, de az utolsó percben nagyon lelassult a másolás, sőt néhány másodpercre többször le is állt a másolt mennyiség növekedése. (Természetesen nem a legvégére gondolok, mert akkor ugye mindig gondolkodik egy kicsi, hogy most mit is csináljon, mert elfogyott a másolni való)
-- nálam nem volt semmilyen gondolkodás.

Szerintem, a Nemo-n (Cinnamon) is segít a proposed gvfs csomag. A megoldást ennyire nehéz volt észrevenni ... vagy csak most néztél rá te is, ahogy rákerestél? Hisz' írtad, három találat volt összesen. Na mindegy.

A segítés nemcsak abban áll, hogy állít valamit a kérdező, és arra én veszettül rákeresek. Hanem, amit kérek, vagyis, amit ő talál, azt ossza meg, tehát a két dolog összefügg a fórum munkában. Igazából nem arról szól a történet sosem, hogy én vagy mi oldjuk meg, hanem arról, hogy közösen. De nem könnyű segíteni sem ... :-)

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Ha valakinél a már emlitett gvfs frissítés nem oldotta meg a problémát (nálam nem oldotta meg),akkor ajánlom az ezen az oldalon leirtakat kipróbálni nálam működik: Transfer “freezes” when writing big files on USB drive
A puffer méretével lehet szabályozni, a másolás sebességét, ha túl kicsi akkor szakaszos lesz a másolás,ha túl nagy akkor az eredeti problémához közelitünk,nekem a 15-20 MB/sec tünik jó kompromisszumnak,ekkor a folyamatjelző végig helyes másolási értékeket, és időket mutat, és a folyamat végén ténylegesen befejeződik a másolás.
Csak az a baj, hogy az igy beállitott pufferméretet nem tudom véglegesiteni,annak ellenére,hogy a nano-ban rendben elmentem, a gép újrainditásakor visszaáll az alap 0 értékre mindkét érték. Ebben kérném a profik segitségét,amit előre megköszönök.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

#21 Szia tonsur, a Proposed tárolós megoldásról olvastál?
A puffer méret fixálásával is foglalkozunk, csak ma eléggé elfáradtam.

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Nem hallottam róla,de kiváncsian várom az ismertetődet.
Viszont ezen az oldalon megtaláltam a pufferméret véglegesitésének a módját:
Low write performance on SLES 11 servers with large RAM
az oldal legalján van a lényeg,hogy a /etc/sysctl.conf fájlban lehet megadni a kivánt értéket,ami az első újrainditás után lép érvénybe.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

#23 Igen, valami ilyesmit írtam volna én is, azaz ugyanott szerkesztgettem volna,

locate sysctl.conf
/etc/sysctl.conf
[..]

s a módszer is ugyanaz. Úgyhogy válasznak is elfogadható a linkelt megoldás, én sem keresem.

Egy embernél jelentkezett a hiba, mely egy bug lehet vagy műszaki ok.
A bug tekintetében írtam választ. Más embernél nincs ilyen jelenség, ráadásul a kérdező eltűnt.

A hatékonyság érdekében a a lemezre írnadó adatok a lemezre történő küldés előtt bekerülnek a gyorsítótárba. Az írás közben várakozó adatok gyorsítótárát "piszkos gyorsítótárnak" hívják. Vannak hangolható beállítások, amelyek befolyásolják, hogy a Linux kernel hogyan kezeli a piszkos gyorsítótárat. ... a túl nagy méretű (8GB méret felett) piszkos gyorsítótárat nehéz átöblíteni, ezért méretének csökkentése szükséges lehet.

Másoknak is érdemes elolvasni, egész jó a fordítása így:
https://translate.google.com/translate?sl=en&tl=hu&js=y&prev=_t&hl=hu&ie...

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Már csak azt kérdezném,hogy a cikkben az ajánlott értékek :
600 MB maximális piszkos gyorsítótár (vm.dirty_bytes = 629145600), és
300 MB háttérfájl (vm.dirty_background_bytes = 314572800)
amennyiben ezektől az értékektől lefelé,vagy felfelé eltérek, milyen következményei lesznek a rendszerre nézve?
Nekem pont a tizede, tehát 60mb piszkos gyorsitótár.és 30 MB háttérfájl értékeknél működik a legjobban a fájlmásolás külső lassú eszközre (pendrive).

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

#25 Két módszer használható:
-- az arány és
-- bájt beállítás (az, amit te próbáltál).
„Ne feledje, hogy egyszerre csak egy módszer (bájt vagy arány) használható.”

Én ezt a leírást próbálnám először (arány módszer) :

vm.dirty_ratio
A piszkos rendszer memória maximális százaléka (alapértelmezett 40).
 
Amikor a memória százalékos aránya meg van téve, a folyamatoknak többet nem szabad írni, amíg a gyorsítótárazott adatok egy részét nem írják ki. Ez biztosítja, hogy az arány érvényesüljön. Önmagában, ami lelassíthatja, észrevehetően, de nem feltétlenül ír. Ha azonban egy alkalmazás olyan nagy mennyiségű adatot ír le, amely még mindig a piszkos gyorsítótárban van, majd kiad egy "szinkronizálási" parancsot, hogy mindent írjon a lemezre, akkor ez jelentős időt vehet igénybe. Ez alatt az idő alatt egyes alkalmazások beragadhatnak vagy lóghatnak. Egyes alkalmazások, amelyeknek időzítői figyelik ezeket a folyamatokat, még azt hiszik, hogy túl sok idő telt el, és meg kell szakítani a műveletet, vagyis "időtúllépésnek".

Ezért nagy memória szervereken ezt a beállítást csökkenteni kell ahhoz, hogy a piszkos gyorsítótár kisebb maradjon. Ez lehetővé teszi a teljes szinkronizálást (flush, vagy commit) hosszú késések nélkül. A 10% -os beállítás (40% helyett) néha megfelelő lehet a teszteléshez, de gyakran még ennél is alacsonyabbra van szükség. A kísérletezés számos megvilágosodhat.

vm.dirty_background_ratio
A piszkos rendszermemória százalékos aránya, amelyen a háttér visszaírása megkezdődik (alapértelmezett 10).
 
A "Háttér" írások elindulnak, hogy az írás még akkor is megtörténjen, amikor az alkalmazás nem kényszeríti a szinkronizálást, és még ha a dirty_ratio még nem érhető el. Ennek a beállításnak az a célja, hogy megóvja a piszkos gyorsítótár túlzott növekedését. Ha a piszkos_ratio-t 10-re csökkentjük, akkor gyakori lehet, hogy a piszkos_háttér-méretet 5-re vagy alacsonyabbra csökkentjük. Hüvelykujjszabály: dirty_background_ratio = a dirty_ratio 1/4 és 1/2 része.
 
Ezek a korlátok a sysctl segédprogrammal figyelhetők meg vagy módosíthatók (lásd a sysctl (8), sysctl.conf (5) man oldalakat). De egyszerűen megfogalmazva ezeket beállíthatjuk (a bootoláskor érvénybe lépve) az /etc/sysctl.conf fájlban, mivel:
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
 
Ha szükséges, a "sysctl.conf" paraméterek "állandó" beállítása helyett azonnal megváltoztathatók, de csak az újraindítás (vagy resetálás) után, a következő példamódszerrel:
echo 10 > /proc/sys/vm/dirty_ratio
echo 5 > /proc/sys/vm/dirty_background_ratio

*****

Szerintem, ha a bájlt módszernél választod, úgy a fizikai RAM méretének 5%-val érdemes kezdeni a dirty_ratio értékének megadásban, majd csökkenteni lefelé az értéket és e beállítás értékének fele legyen minden esetben a dirty_background-ratio értéke.

Nálad mennyi százaléka a RAM-nak a 60MB?

Értékelés: 

0
Még nincs értékelve
tonsur képe

Pufferméret optimalizálása

8GB ram van a gépben,ehhez az ajánlásod szerint 400/200MB lenne a kiindulási érték,de ezeknél az értékeknél még hasonlóan elhúzódik a pendrive-ra másolás mint az eredeti értékek (korlátlan puffer méret alapbeállitás) esetén.
Ha hagyom a 60/30MB-ot,az milyen hátrányokkal jár a rendszer működésében?
Gondolok itt pl egy videoszerkesztőre,ami eleve sok ramot használ,ennek a működését is befolyásolná a pufferméret csökkentése?

Értékelés: 

0
Még nincs értékelve
kimarite képe

Pufferméret optimalizálása

#27 A kernel a feladatokat sorba teszi, ha valamivel 'nem tud előre haladni', úgy az a feladatra szánt idő növekedésével jár.
A kernel cache-n kívül figyelembe kell venni a HDD saját gyorsítótárát is.

Rugalmas működéshez (tipp)
-- csak a vm.dirty_background_ratio értékét csökkentsd (mert ez a cache minimum értéke) és
-- a vm.dirty_ratio értéke maradjon az eredeti, (mert ez a cache maximum értéke, eddig növekedhet igény esetén)
esetleg növeld a RAM méretének 50%-ra,
https://sites.google.com/site/sumeetsingh993/home/experiments/dirty-rati...
netán -legfeljebb- 80%-ra,
https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performanc...
de a nagy értékek akkor jönnek jól, ha lassú adatátviteli sebességgel kényszerülsz írni, pl. SD kártyára

Ha a RAM cache nem elég az alkalmazás műveleteknek, akkor a lapozó terület ('swap') lesz használva, mely
-- nyilvánvalóan lassabb, mint a RAM, így lassulás lesz tapasztalható  RAM használathoz képest.

A RAM működési sebessége nyilvánvalóan és sokkal gyorsabb a HDD működési sebességénél, ezért használják a cache-lésre. (https://stackoverflow.com/questions/27900221/difference-between-vm-dirty...)

Összefoglalva:
-- túl kevés cache nem elég egyes alkalmazások nagyobb igényének, így idő túllépés esetén, akár azoknál akár működésbeli zavarok is észlelhetőek lehetnek
-- túl sok cache a már említett okból (a címben, az eredeti problémát nézve, és az általam említett öblítést) lassulást okozhat. Továbbá bármely műszaki probléma, pl. pillanatnyi áram kimaradás, vagy a RAM bármely esetei problémája a cache-ban várakozó adatok sérülését okozhatja, így azok sikeresen már nem írhatóak át a lemezre: és adatok áthelyezésekor probléma, mert másoláskor megmarad az eredeti. De nemcsak külső adatokat másolsz, hanem belsőket, melyeket az alkalmazások használnak a háttérben.

Kicsit mellébeszélek: gondolhatnál cache eldobásra
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6...
de, ha igen (non-destructive operation), akkor csak/esetleg így,
https://lacyc3.eu/memoria-gyorsitotar-uritese
másrészt ez 'egyáltalán' nem függ össze az eredeti kérdéssel.

Talán erre az alkalmazásra érdemes lehet ránézned:
https://launchpad.net/sysbench

Ki kell próbálni azt a videó szerkesztő alkalmazást, hogy mennyiben változik a viselkedése az új beállításokkal.

Értékelés: 

0
Még nincs értékelve
tonsur képe

Pufferméret optimalizálása

Köszönöm a részletes magyarázatot.
Végigpróbáltam az ajánlott beállitásokat kezdve a vm.dirty_ratio-s százalékos értékekkel,(20/10%,10/5%) amik érzékelhetően nem befolyásolták a rendszer működését,ezért a vm.dirty_bytes = 104857600, és
vm.dirty_background_bytes = 52428800 beállitásnál maradtam, (tehát 100/50MB értékek) ami már jelentős pendrive másolási sebesség gyorsulást eredményezett, és a videoszerkesztő programok is megfelelően működtek.
Hogy érzékeltetni tudjam a javulás mértékét az (usb2-es pendrive-ra másoláskor): eredeti beállitással (vm.dirty_ratio = 20,vm.dirty_background_ratio = 10) a fájlkezelő folyamatjelzője 100%-os elkészültség elérése után még 3 percig másolt a memoriából a pendrive-ra, a módositott értékek után pedig 10 másodpercig, vagyis eredeti beállitásokkal 2+3 percig tartott a másolás, a módositás után pedig 2perc+10másodpercig.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Pufferméret optimalizálása

#29 Szívesen. :-)
Konkrét beállításokat teszt által tudsz kivitelezni, mert a beállítás általában hardver függő.

Én fel szoktam írni a saját beállításokat, azaz szövegfájl(ok)ba jegyzetelek (*.txt). De lehet a 'súgó/kézikönyv' egy Libreoffice dokumentum is. Másrészt legtöbbször a szerkesztés előtt:

-- a konfigurációs fájl eredeti beállításait mentem (másolom), ha rendszerfájl, akkor 'sudo' val

cp /elérési_út/eredeti_fájl /elérési_út/eredeti_fájl.ORIG

azaz

sudo cp /etc/sysctl.conf /etc/sysctl.conf.ORIG

-- továbbá megjegyzést írok a változtatás fölé, a komment (#) használatával, hogy a rendszer ne vegye a megjegyzést beállításnak.

     -- megnyitom szerkesztésre a fájlt (most a nano szövegszerkesztővel)

sudo nano /etc/sysctl.conf

     -- és beleírom a megjegyzést a változtatáshoz - a végén lesz (angolul is lehet)

### Alacsony adat másolás/áthelyezés képesség javítása,
### a puffer méret optimalizálása
# Forrás: Low write performance on SLES 11 servers with large RAM
# https://www.novell.com/support/kb/doc.php?id=7010287
# (https://linuxmint.hu/forum/fajl-mozgatasnal-rohamos-lassulas)
vm.dirty_bytes = 104857600
vm.dirty_background_bytes = 52428800

     -- majd mentem a változtatást és bezárom a szerkesztőt

Ctrl + O és Enter
Ctrl + X

Megj.: A '/proc/sys/vm/dirty_bytes' és a '/proc/sys/vm/dirty_background_bytes' nem szerkeszthetők:
[ A(z) „/proc/sys/vm” könyvtár nem írható ]

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás összefoglaló

Azt hiszem a téma végéhez értünk, igy érdemes összefoglalni a jelenséget és annak orvoslási lehetőségét.
A 64 bites ubuntu alapu rendszerek a rendszermemóriát használják puffernek,ami általában előnyös, de nagyobb fájlok külső adathordozóra való átmásolásánál hátrányos,mert a biztonságos adatátvitel érdekében, miután nagy sebességgel egészben vagy részben (memória nagyságától függöen) bemásolta a memóriába a fájlokat,onnan lassan irja ki a külső adathordozóra, majd másolás végén a szinkronizálás, és ami igazán lassitja a folyamatot, hogy a memóriát meg kell tisztitani a bemásolt adatoktól ami nagyobb memória kapacitás esetén hosszadalmas.
Ezért ezt a kapacitást előre lecsökkentve (mértékét tesztek által az adott hardverhez igazitva) megszüntetjük a memória "piszkos fájlokkal" való telitődését,igy felgyorsitjuk a fájlok másolását.
(az ezt megelöző hozzászólásaimban ennek módját,és mértékét részletesen kitárgyaltam)
Az adott rendszerhez megállapitott adatokat érdemes valamilyen formában elmenteni,hogy esetleges újboli beállitás esetén rendelkezésre álljanak.
Ha valamit nem jól értelmeztem,akkor megkérem kimarite-t,hogy korrigálja.
Köszönöm.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás összefoglaló

#31 Igen, egyetértek.
Annyit még hozzátennék, mint korábban

Rugalmas működéshez (tipp)
-- csak a vm.dirty_background_ratio értékét csökkentsd (mert ez a cache minimum értéke) és
-- a vm.dirty_ratio értéke maradjon az eredeti, (mert ez a cache maximum értéke, eddig növekedhet igény esetén)

tehát, hogy a „vm.dirty_ratio” értéke maradhat az eredeti vagy akár növelhető is, ... mert a lassabb adatátvitelhez (pendrive, SD kártya) a nagyobb puffer lehet szükséges (a maximum érték).

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás - bug

#32 „Annyit még hozzátennék, mint korábban”
-- ez egy kísérletezgetés eredménye .. amit legjobb lenne blogba öntened, és mert
-- .. nem sok köze van ahhoz, hogy az eredeti problémát egy bug okozza.
Jót! :-)

 

Értékelés: 

0
Még nincs értékelve

Sziasztok!

Sziasztok!

2-3 Gb-os álományokat másolva ugyanezt tapasztaltam most 2022-ben. A rendszer Mint 20.3 XFCE, Intel I5 4440 16GB memóriával. Kernel 5.4.0-94, a swappines 60%-ról visszavettem anno 10%-ra, hogy ne az ssd-t írja állandóan, ha már ennyi memória van benne.

Ezek szerint még mindig nincs megoldva ez a probléma? Átolvastam az összes bejegyzést, elég sokminden kínai volt számomra.

Újabb kernel megoldja ezt a hibát? Ez a hiba Ubuntus verziókat érinti, vagy az LMDE-ben is jelentkezik?

Nagyon beletúrni nem akarok a rendszerfájlokba. Fél évente ha kell rászánom a több időt, de érdekel a dolog, hogy egy frissítéssel megoldhatom-e a hibát.  Előre is köszönöm!

 

Értékelés: 

0
Még nincs értékelve

Sziasztok!

#35 Szerintem, itt kéne kapirgálni - ahogy kimarite összegezte: (Fentebb)

Rugalmas működéshez (tipp)
-- csak a vm.dirty_background_ratio értékét csökkentsd (mert ez a cache minimum értéke) és
-- a vm.dirty_ratio értéke maradjon az eredeti, (mert ez a cache maximum értéke, eddig növekedhet igény esetén)

tehát, hogy a „vm.dirty_ratio” értéke maradhat az eredeti vagy akár növelhető is

Nálam (Mint 20.3)

/proc/sys/vm/dirty_background_ratio alapértélmezett értéke: 10 -> (csökkenthető pl. 5-re)

/proc/sys/vm/dirty_ratio alapértélmezett értéke: 20 -> (esetleg növelhető pl. 30-ra (40-re ?)

Értékelés: 

0
Még nincs értékelve
kimarite képe

Sziasztok!

#35 Ahogy nézem a leírásokat, a probléma szempontjából számító tényezők:

  • USB-s eszközre másolás,
  • a fájlrendszer (FAT32, NTFS),
  • a fájlkezelő.

Nálad mik ezek? A Thunart feltételezem, hogy a fájlkezelőd, de a többi?

###

És esetleg nézz rá erre, ha tetszik: Liquorix rendszermag

Értékelés: 

0
Még nincs értékelve
kimarite képe

Sziasztok!

#37 Ui.: a Liquorix-tól még nem érkezett meg az 5.16-os kernel, azt esetleg a MainLine alkalmazással telepítheted. Az alkalmazás értelemszerűen a Linux Minthez jó, az LMDE-hez nem.

Értékelés: 

0
Még nincs értékelve

Sziasztok!

#38 Próbálok sorba menni a tanácsokon. A dirty átírásának lehetőségét a próbálkozások végére hagynám.

Fájlkezelő: Thunar, Nemo és Double Commander, Hdd ext4, erről másolok, USB-s pendrive NTFS, erre másolok.

A Liquorix-ról sajnos még nem hallottam. A linkelt cikket elolvastam. "Idegen" kernelt még nem próbáltam soha. Valószínű azért, mert a GRUB-bal sem vagyok valami nagy haverságban. Ha megnyitom a Kernelek modult még van két ág amire lehet frissíteni és adnak ki javításokat hozzá. 5.11.0-46 2022 februárig támogatott. 5.13.0-25 2022 augusztusig támogatott. Az "újabb kernel megoldja-e a hibát?" kérdésnél ezekre gondoltam elsősorban, csak nem pontosan tettem fel a kérdést. Másolás kezdetén 75-80 MB/s az érték és 1 perc után már csak 30-40 Mb/s és utána fokozatosan lecsökken 10 Mb/s értékre a végén. Ezt most a Nemoval produkálta, múltkor a Thunárral lement 1-3 Mb/s értékre. Nemoval most másoltam először ennyit. Az első kísérletek a Thunárral és Double Commanderrel voltak.  Másolandó mennyiség 4-5 fájl 14-15 giga. Pendrive kiadásánál mindig a következő hibát hozza:

https://imgur.com/jRpdb2W.png

Ilyenkor leállítani sem lehet a gépet. Nem "él" a leállítás ikon.

 

 

Értékelés: 

0
Még nincs értékelve

Sziasztok!

#39 "dirty átírásának lehetőségét a próbálkozások végére hagynám."
Akkor a helyedben a következő kísérletem az lenne, hogy a pendrive-ot nem NTFS-re, hanem
exFAT fájlrendszerre formáznám - és így nézném meg a nagy fájlok másolási sebességét.

Az exFAT fájlrendszert a Windows, és a Linux is tudja kezelni - a max. fájlméret határ sem
okozhat gondot.

Másolás alkalmával, a fájlkezelőben megnyílik egy ablak, mely mutatja a másolás sebességét,
illetve hogy hol tart a másolás.
Ha ez az ablak azt jelzi hogy befejeződött a másolás, (eltűnik az ablak) az még nem jelenti
azt hogy a pendtive-re már nem történik írás - a gyorsítótárból még ezután is történik rá
írás. Ez nagyon jól látszik olyan pendrive-okon, melyeken van visszajelző led. (még villog)

Ha másolás közben terminált nyitsz, és beírod "sync" -> entert nyomsz, akkor a promt
akkor fog visszajönni amikor a másolás ténylegesen befejeződött. (De inkább ezután is várj
még egy kicsit - mielőtt kiadatnád a pendrive-ot.)

Értékelés: 

0
Még nincs értékelve
kimarite képe

Sziasztok!

#39 Ma EXT4 formázású külső HDD-re mentettem át nekem fontos adatokat. Nagyon ritkán esett le a másolási sebesség 10 MB/s környékére. Átlagos sebesség 20-60 MB/s. Az 5.15-ös kernelt használtam, és a Nemo fájlkezelőt. Egyszerre egy könyvtár vagy fájl lett másolva, a többi feladat várakozott.

Nézhetnél kimenetet, hogy I/O hiba van-e (a lemezre vonatkozó írási/olvasási hiba):

dmesg

A szöveges kimenetet az aláírásomban szereplő módon kéne megosztani itt.

Értékelés: 

0
Még nincs értékelve

Sziasztok!

#41 Feltettem az 5.13.0-25 kernelt, nincs változás. Kipróbáltam az exFAT fájlrendszert nincs változás.

dmesg-re válaszolva  i/o-ra pirossal ezt írja ki (ha kell a teljes kimenet felteszem a paste-ra):

[ 1549.613604] Buffer I/O error on dev sdc1, logical block 15145984, async page read
[ 1549.613610] Buffer I/O error on dev sdc1, logical block 15145985, async page read
[ 1549.613612] Buffer I/O error on dev sdc1, logical block 15145986, async page read
[ 1549.613614] Buffer I/O error on dev sdc1, logical block 15145987, async page read
[ 1549.613615] Buffer I/O error on dev sdc1, logical block 15145988, async page read
[ 1549.613617] Buffer I/O error on dev sdc1, logical block 15145989, async page read
[ 1549.613618] Buffer I/O error on dev sdc1, logical block 15145990, async page read
[ 1549.613619] Buffer I/O error on dev sdc1, logical block 15145991, async page read
[ 1549.613816] Buffer I/O error on dev sdc1, logical block 32, async page read
[ 1549.613819] Buffer I/O error on dev sdc1, logical block 33, async page read
[ 1549.671710] usb 3-5: USB disconnect, device number 5
[ 1549.673139] show_signal_msg: 37 callbacks suppressed
[ 1549.673144] Thunar[1402]: segfault at 18 ip 0000558d096ab42b sp 00007ffd66fb53a0 error 4 in thunar[558d09649000+84000]
[ 1549.673158] Code: c7 46 08 00 00 00 00 eb 9b 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 55 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 <48> 8b 47 18 48 85 c0 74 54 48 89 fd 31 ff eb 11 0f 1f 44 00 00 48
[ 1564.370890] [UFW BLOCK] IN=enp2s0 OUT= MAC=d8:cb:8a:1c:10:4a:5c:b1:3e:7a:ac:b8:08:00 SRC=193.39.14.167 DST=192.168.1.66 LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=0 DF PROTO=TCP SPT=443 DPT=57832 WINDOW=0 RES=0x00 RST URGP=0
[ 1908.465680] usb 3-5: new high-speed USB device number 6 using xhci_hcd
[ 1908.615082] usb 3-5: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10
[ 1908.615093] usb 3-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1908.615098] usb 3-5: Product: DataTraveler 3.0
[ 1908.615102] usb 3-5: Manufacturer: Kingston
[ 1908.615106] usb 3-5: SerialNumber: E0D55E6CBC9AE3A1189008C4
[ 1908.618200] usb-storage 3-5:1.0: USB Mass Storage device detected
[ 1908.618562] scsi host6: usb-storage 3-5:1.0
[ 1909.650454] scsi 6:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[ 1909.650864] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 1909.651017] sd 6:0:0:0: [sdc] 30277632 512-byte logical blocks: (15.5 GB/14.4 GiB)
[ 1909.651245] sd 6:0:0:0: [sdc] Write Protect is off
[ 1909.651248] sd 6:0:0:0: [sdc] Mode Sense: 45 00 00 00
[ 1909.651463] sd 6:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 1911.429965]  sdc: sdc1
[ 1911.452083] sd 6:0:0:0: [sdc] Attached SCSI removable disk
[ 1924.799743]  sdc:
[ 1924.978010]  sdc: sdc1

 

 

 

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Sziasztok!

#42 Buffer I/O error on dev sdc1, logical block...

Nézz rá a lemez állapotára a Lemezek alkalmazással.

Értékelés: 

0
Még nincs értékelve

Sziasztok!

#43 Állapotot csak HDD-nél ír ki. A teszt eredménye a következő:

https://imgur.com/9dKVKuX.png

Nem ír problémát. Az eredményt azt nem tudom, hogy jónak számít-e.

Másik pendrive-nál is hasonló a másolás sebessége.

 

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Sziasztok!

#44 Nem a Partíció teljesítménytesztje... kell, hanem a Fájlrendszer ellenőrzése... .

Értékelés: 

0
Még nincs értékelve

Sziasztok!

#45 A fájlrendszert is lehet ellenőrizni, de e mellett a "badblocks"-ot is futtatnám.
- ​sudo badblocks -v /dev/sdx (csak olvasással tesztel) ... természetesen az /sdx 
behelyettesítendő a pen. azonosítójával ... pl. /sdb)
Vagy:
- ​sudo badblocks -v -n /dev/sdx  (írás-olvasás teszt a tartalom megőrzésével)

Értékelés: 

0
Még nincs értékelve

Sziasztok!

#42 Ja, igen, valahogy tesztelni kellene az USB kütyüt, nem sebességre, hanem konzisztenciára, mint fentebb is írták, ha más nem akkor formázni, (nem gyorsformázással), az elvileg kizárja a hibás blokkokat, ha van.

Amúgy nem feltétlenül van felületi hiba, az is lehet, hogy a tápellátás ingadozik, vagy a csatlakozás nem kielégítő, erre utal, hogy leválasztja, majd újra megtalálja, és csatolja.

Eddig a meghajtó hiba.

A másik a Thunar hibájának néz ki, ami nem feltétlenül kapcsolódik a másolási folyamathoz, a hibaüzenet csak arról szól, hogy nem tudja lekezelni a hibát, mert ez az ág nincs lekezelve, 0 pointer-re fut a program. Lehet, hogy pár ciklus után kimászik ebből, de ezt csak a kód elemzésével lehet biztosan kimondani, de nagy az esélye, mert ugye nem fagy le, nem lép ki, ott van, csak marhára belassul.

Ha a meghajtón nincs hiba, meg lehet próbálni simán terminál alatt cp-vel másolni rá egy nagyobb adagot, és mérni, hogy mennyi idő alatt lesz kész (sajnos  sebességet nem mutat, de azt, hogy mikor tér vissza a promt, azt látni.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Sziasztok! | Hard Disk Sentinel Linux: CLI és GUI

#45 De ránézhetsz a HD Sentinel alkalmazással is. A honlapról az Xfce4 terminálos változat is letölthető (csak telepítsd a terminált is): Hard Disk Sentinel Linux: CLI és GUI
( https://www.hdsentinel.hu/hard_disk_sentinel_linux.php )

Értékelés: 

0
Még nincs értékelve

Húzós volt a hét! Ezért nem

Húzós volt a hét! Ezért nem nem válaszoltam idáig. Lemezek programmal csak az egyik USB-s pendrive-ot sikerült letesztelnem a Fájlrendszer ellenőrzésével. Az jó volt. A másiknál valahogy mindig inaktív a parancs. Már az elsőnél is szenvedtem ezzel. Sajnos nem jöttem rá, hogy egyszer hogyan sikerült leellenőrizni. Felcsatolva, lecsatolva is néztem már, de nem "él" a parancs. HDD Sentinel nem ír ki semmit.

https://imgur.com/gWmdecx.png

 

 

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Húzós volt a hét! Ezért nem

#49 Végül, a Lemezek alkalmazással is megnézted a makacs eszközt? A HD Sentinel teszt problémára ránézek.

Értékelés: 

0
Még nincs értékelve

Húzós volt a hét! Ezért nem

#50 Ez a gond vele:

https://imgur.com/LkQHToB.png

2 pendrive-ra másoltam ,mindegyik lassú volt. Az egyiket sikerült valahogy leellenőrizni a lemezek programmal, de ott is ugyanez volt a probléma mint a fenti képen. De egyszer valamiért sikerült megnézni vele, de nem tudom, hogy mit csináltam máskép.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Húzós volt a hét! Ezért nem

#51 Ez a gond vele:
https://imgur.com/LkQHToB.png

... mert NTFS (exFAT) a fájlrendszer.

Próba: telepítés után, a másolás sebessége...?

sudo apt-get install exfat-fuse exfat-utils 

Próba: ha a pendrive EXT4 vagy BTRFS, akkor a másolás sebessége...?

Értékelés: 

0
Még nincs értékelve

Húzós volt a hét! Ezért nem

#52 3 fájlrendszerrel próbáltam. ExFAT, NTFS, EXT4, mindegyiknél ugyanez a jelenség. Erre "exfat-fuse exfat-utils" azt írja, hogy már fennt van a gépen.

Másolás után fél órával mikor leválasztom a pendrive-ot ezt írja ki:

https://imgur.com/2PSSjdR.png

Értékelés: 

0
Még nincs értékelve
kimarite képe

Húzós volt a hét! | original tumblerd killer script

#53 Az alkalmazás az előnézetek láthatóságáért felelős.

Készíts egy szöveges fájlt szövegszerkesztővel (például Geany, Gedit, Kate) tumblerdwatcher.sh néven.

A fájl tartalma ez legyen:

#!/bin/bash
# Tumblerdwatcher v 1.0
# Script to check and kill tumblerd process if a loop is suspected. To be automatically scheduled at user session start.
# Homemade workaround for bug: http://forums.linuxmint.com/viewtopic.php?f=110&t=97079&p=767460&hilit=tumblerd#p554241
# The author has no responsibility for the execution. Feel free to distribute and modify it.
# Advice are welcome to rs2809@yahoo.it.
period=60                  # check period (sec)
process="/usr/lib/i386-linux-gnu/tumbler-1/tumblerd"   # tumblerd binary path
Pcpu=20                     # tolerated cpu usage (%)
Pmem=25                     # tolerated memory usage (%)
mountpath="/media"               # automatic mount point for removable storage
sec=10                     # time limit (sec) for opened file at $mountpath for thumbnail generation
sg="-15"                  # process termination signal (-15 is OK)
logpath="/tmp/Tumblerdwatcher.log"         # log path                     
cat /dev/null > $logpath
exec >$logpath 2>&1
# reset log file
while true
# execute endlessly
do
sleep $period
# wait a set period of time
[[ `ps -ef | grep $process | grep -v 'grep' | wc -l` -eq 0 ]] && continue
# skip to next period if not executing
ps -eo pcpu,pid,pmem,args | grep $process | grep -v 'grep' | while read dpcpu pid dpmem
# catch proccess id, cpu usage and memory usage
  do
  pcpu=`echo $dpcpu | cut -d'.' -f1`
  pmem=`echo $dpmem | cut -d'.' -f1`
  [[ $pcpu -gt $Pcpu ]] || [[ $pmem -gt $Pmem ]] && kill $sg $pid && echo "`date` PID $pid $pcpu/$Pcpu %cpu $pmem/$Pmem %mem" && continue
# if cpu usage or memory usage exceed, kill it and report values in the log file
  [[ `lsof -p $pid | grep $mountpath | wc -l` -eq 0 ]] && continue
# if no opened file by tumblerd at removable storage mountpoint, skip to next period
  lsof -p $pid | grep $mountpath | tr -s ' ' | cut -d' ' -f9 > /tmp/tumblerd.lsof.old
# list opened files
  sleep $sec
# wait for tolerated time limit
  [[ `lsof -p $pid | grep $mountpath | wc -l` -eq 0 ]] && continue
# if no more opened file skip to next period
  lsof -p $pid | grep $mountpath | tr -s ' ' | cut -d' ' -f9 > /tmp/tumblerd.lsof.new
# list opened files again
  for opened_file in `cat /tmp/tumblerd.lsof.old`
# if some file was open before....
   do
     grep $opened_file /tmp/tumblerd.lsof.new && kill $sg $pid && echo "`date` PID $pid ^^^^^^^^^^^^^^^^^^^^^^^^" && continue
# ...and it's still hung open, kill tumblerd
   done
  done
done

Ments ide (ha nincs ilyen elérési út , készítsd el):

~/.local/bin/Tumblerdwatcher/

Tedd futtathatóvá a fájl Tulajdonságoknál.

Nyisd meg az Indítópult alkalmazást, készíts egy új elemet Tumblerdwatcher néven, tedd a késleltetését 10 vagy 12 másodpercre, és kapcsold be. A rendszer újraindítás után fog élni.

Reméljük, ilyen formában is jó lesz, de az idők folyamán szerkesztették, és a megoldáshoz is hozzátettek.

Részletek:
https://wiki.archlinux.org/title/Talk:Thunar

Értékelés: 

0
Még nincs értékelve
kimarite képe

original tumblerd killer script (x86_64) # javítás

#54 A 64 bites rendszerhez alábbi script illik.

Az általam szerkesztett, javított script (ezt használd):

#!/bin/bash
# Tumblerdwatcher v 1.0
# Script to check and kill tumblerd process if a loop is suspected. To be automatically scheduled at user session start.
# Homemade workaround for bug: http://forums.linuxmint.com/viewtopic.php?f=110&t=97079&p=767460&hilit=tumblerd#p554241
# The author has no responsibility for the execution. Feel free to distribute and modify it.
# Advice are welcome to rs2809@yahoo.it.
period=60                  # check period (sec)
process="/usr/lib/x86_64-linux-gnu/tumbler-1/tumblerd"   # tumblerd binary path
Pcpu=20                     # tolerated cpu usage (%)
Pmem=25                     # tolerated memory usage (%)
mountpath="/media"               # automatic mount point for removable storage
sec=10                     # time limit (sec) for opened file at $mountpath for thumbnail generation
sg="-15"                  # process termination signal (-15 is OK)
logpath="/tmp/Tumblerdwatcher.log"         # log path                     
cat /dev/null > $logpath
exec >$logpath 2>&1
# reset log file
while true
# execute endlessly
do
sleep $period
# wait a set period of time
[[ `ps -ef | grep $process | grep -v 'grep' | wc -l` -eq 0 ]] && continue
# skip to next period if not executing
ps -eo pcpu,pid,pmem,args | grep $process | grep -v 'grep' | while read dpcpu pid dpmem
# catch proccess id, cpu usage and memory usage
  do
  pcpu=`echo $dpcpu | cut -d'.' -f1`
  pmem=`echo $dpmem | cut -d'.' -f1`
  [[ $pcpu -gt $Pcpu ]] || [[ $pmem -gt $Pmem ]] && kill $sg $pid && echo "`date` PID $pid $pcpu/$Pcpu %cpu $pmem/$Pmem %mem" && continue
# if cpu usage or memory usage exceed, kill it and report values in the log file
  [[ `lsof -p $pid | grep $mountpath | wc -l` -eq 0 ]] && continue
# if no opened file by tumblerd at removable storage mountpoint, skip to next period
  lsof -p $pid | grep $mountpath | tr -s ' ' | cut -d' ' -f9 > /tmp/tumblerd.lsof.old
# list opened files
  sleep $sec
# wait for tolerated time limit
  [[ `lsof -p $pid | grep $mountpath | wc -l` -eq 0 ]] && continue
# if no more opened file skip to next period
  lsof -p $pid | grep $mountpath | tr -s ' ' | cut -d' ' -f9 > /tmp/tumblerd.lsof.new
# list opened files again
  for opened_file in `cat /tmp/tumblerd.lsof.old`
# if some file was open before....
   do
     grep $opened_file /tmp/tumblerd.lsof.new && kill $sg $pid && echo "`date` PID $pid ^^^^^^^^^^^^^^^^^^^^^^^^" && continue
# ...and it's still hung open, kill tumblerd
   done
  done
done

Bocs.

Értékelés: 

0
Még nincs értékelve

#55 Ugye jól tapasztalom,

#55 Ugye jól tapasztalom, hogy csak a leválasztást oldja meg a script?

Értékelés: 

0
Még nincs értékelve
kimarite képe

#55.1 Vélhetően, azért

#55.1 Vélhetően, azért tartott sokáig a másolás befejezése, mert a tumblerd által foglalt kötetet nem lehet „csak úgy” leválasztani. Így mindkét dolgot megoldja a script.

Értékelés: 

0
Még nincs értékelve

original tumblerd killer script (x86_64) # javítás

#55 Köszönöm szépen, holnap kipróbálom!

Értékelés: 

0
Még nincs értékelve

De hülye ez a címmegadó

De hülye ez a címmegadó módszer...

Mostanában olyasmiket csináltam két notival is, hogy HDD-ről külső HDD-re 100-150 GB adat kimentés, másik noti (SSD-vel) friss telepítés, kimentett adatok felmásolása.

A régi gépeknek csak USB2.0 portja volt, a külső HDD USB3.0. Régi gépről DC-vel mentettem. Ez úgy ment, hogy 20-30 MB/s-el indult, jó ideig, amíg nagy fájlokat kellett másolni, kis ütemben lassult, de amint kis fájlok jöttek sorra, baromira lelassult, úgy pár kB/s-re. Amikor meguntam, rányomtam a szünetre, számoltam 10-ig, újra elindítottam. Ekkor megint gyorsan indult, de ez attól függött, hogy kis fájlok voltak soron, vagy nagyok. Kicsik esetén 8-10 MB/s-re, nagyok esetén meg gyorsabbra. Több alkalommal is rányomtam a szünet + indításra...

A visszamásolás az újabb gépekre Nemo-val ment, (DC még nem volt telepítve). Mivel az újabb gépeknek USB3.0 portjuk volt, ez viszonylag nagy sebességgel / gyorsan ment, itt is volt hasonló ingadozás, de itt nagy értékek körül ingadozott, így nem is avatkoztam közbe, csak figyeltem a státusz csíkot.

Tehát az elméletem az, hogy ez nagy mértékben HW feature. Mármint vannak pufferek amik telítődnek, ha meg folyamatosan jönnek az adatok, akkor nem ürülnek ki. A külső merevlemez hardveres puffere megtelt, oszt nem ürült ki. Meg ugye ez sem úgy megy, hogy csak mennek fel a bájtok a lemezre, mert van CRC ellenőrzés, oszt ha nem stimmel, akkor újra kéri a csomagot. Amikor szüneteltettem a másolást, akkor kiürült a puffer, újra elindítottam, volt hová ömleszteni az adatokat.

Visszamásolás: Visszafele SSD-re mentek az adatok, és USB3.0-án jöttek. Azaz, az SSD az sebesen írt a célhelyre, de ugyanakkor az az adatok is gyorsabban jöttek. Ezért volt némi ingadozás, de ez nem azért volt, mert a HDD gyorsabban nyomta volta cuccot, amivel az SSD nem bírt, hanem inkább fordítva.

Kis fájlok vs nagy fájlok másolása: igazából szerintem itt az allokációs tábla vezetése lehet a kulcs. Ez azért elég nagy adatbázis, amikor egy új fájl kerül felírásra, akkor ebben végig kell nézni, hogy van-e ilyen, mettől meddig, mekkora, mi a dátuma, ha meg felül kell írni, akkor frissíteni az allokációs táblát. Tehát nem mind1, hogy egy 100 MB-s fálj van másolva, vagy 100 db. 1 MB-s fájl.

A Total Commandernek erre külön stratégia beállító felülete van, ahol be lehet lőni, hogy kis fájlokat hogyan pufferelje (saját puffert használ), a nagyokat hogyan, melyek a helyi beépített lemezek, mely logikai egységek vannak u.a meghajtón, melyek külön lemezek. Azaz, ez a probléma nem kizárólag Linux probléma, Windows alatt is létezik. Másképpen, ez túlmutat az operációs rendszeren, az egész HW szinten van lezongorázva.

Értékelés: 

0
Még nincs értékelve
kimarite képe

címmegadó módszer...

#57 Javítva: https://linuxmint.hu/comment/52844#comment-52844

Jelezz vissza, ha nálad is.

ez nagy mértékben HW feature

Igen. És máshogyan megközelítve: a Windows 7-ben még benne volt a biztonságos másolás, azóta már nincs. Fontos az is, tényleg át lett másolva az adat, vagy csak talán... . Ha nincs ellenőrzés (Windows), akkor talán. Ha van ellenőrzés (Linux), akkor biztosan.

Értékelés: 

0
Még nincs értékelve