@#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?

@#18 Hogyan mondjam el neked, azt, amit nem lehet (ez egy dal szövege..). Szóval, akkor vélem, hogy:
A tegnap jött frissítést te telepítetted és megoldotta nálad a problémát. :-)
Részemről sincs harag.

#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.

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.

#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...

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.

#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?

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).

#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.

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?

#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ó ]”

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.

#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).

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.

#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

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!

 

#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.

#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.

 

 

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

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

#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

 

 

 

 

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

#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.

 

 

#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.

#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