Fedora 43 workstation (laptop) hetente egyszer rettenet belassul

Red Hat, Fedora, CentOS

Sziasztok!

Kb 2 hete frissítettem 42-ről 43-ra. Teljesen tiszta új telepítéssel. Volt jó adag szemét már a gépen, de igazából működött rendesen. 

Amióta viszont a 43 van fennt, azóta már minimum a 3. alkalom, hogy egyik pillanatról a másikra belassul a gép. Hiába kapcsolok ki mindent, chrome, IDE (pl vscode, phpstorm, stb), docker meg egyebek, nem lehetett megoldani. Nyomozgattam chatgpt-vel, kb az volt az eredmény, hogy ezt is azt is lőjem ki,de igazából semmi hasznos infó nem volt belőle. Nem javult. Reboot után is lassú volt, a boot és belépés percekig eltartott.

Aztán ahogy jött az egész egyszercsak minden helyrejött.

Ezt minimum 2x csinálta már.

Ma volt a 3. eset, most annyival volt másabb, hogy most reboot után úgy tűnik helyrejött.

Nem telepítettem fel semmi olyat ami eddig nem volt fenn az előző verziókban.

Nem tudom, hogy nálam van elbénázva valami vagy más is belefutott e ebbe.

 

glib2-vel kapcsolatban találtam korábban infót, hogy lassít és akkor downgradeltem.

Most ahogy nézem vannak friss bejegyzések megint, hogy másnál is van lassulás.

Tud valaki megoldást erre?

  • 1611 megtekintés

( denton | 2025. 11. 29., szo – 16:41 )

Agyalok azon, hogy más disztrót választok, mert ez a gyakori release meg kísérletezés se az igazi.

2 éve ubuntu desktopot próbáltam, de 1 hét alatt összeomlott valami miatt, lehet azóta az is jobb már. (egyébként parancssorban ubuntu párti vagyok)

Mint linuxot mondja még sokmindenki.

A Linux Mint már már unalmasan stabil desktop. Semmi izgalmas update:) Ez a legrosszabb benne. A default kikapcsolt snap is visszakapcsolható könnyedén és akkor van egy csomó windows program ami snap csomagként telepíthető. Pár éve már megy ez a snappeljünk be minden gyakran használt windows tool-t projekt. Így nagyon egyszerűen telepíthető egy Total Commander például snap-pel mindenféle winetrick állítgatás nélkül. Az általuk fejlesztett Cinnamon desktop is jobb mint az Ubuntu alap destkopja. 

Ha egy kis kalandra vágynál, akkor meg ott a Gentoo. Minden a te gépeden fordul le, így nemcsak stabil, de (ha ma ennek van még értelme) gyors is lesz. A fordításoktól nem kell megijedni, mert az emerge csomagnév parancs használata pont olyan egyszerű, mint Debian/Ubuntu alatt az apt install csomagnév, vagy Fedora alatt a dnf install csomagnév. 

Ha sietnél és mégsem várnál ki (PC-től függően) 15 perc - 1,5 órát egy Libreoffice forrásból telepítésére fordítással, akkor van emerge --getbinpkg libreoffice így egyből bináris települ nagyjából ugyanúgy pillanatok alatt mint Fedoran vagy Mint-en. USE flag-eket sohasem kell állítgatnod ha nem akarod vagy Ovelay-eket sem kell használni. Viszont ezek olyan lehetőségeket nyitnak meg, amik más Linux disztribúción nem léteznek. 

Arch Linux nagy divat még mostanában. De ott éppen a stabilitás probléma néha. Ez az ára annak, hogy mindig minden nagyon friss verzióból van. Bár az AUR miatt sokan forrásból építkeznek, hiányoznak belőle a Gentoo USE flag-jeihez fogható finomhangolási lehetőségek, illetve Overlay-ek sincsenek. Ha a Fedora nem szimpi Arch-ot sem ajánlanám. 

Amit az Arch-ról írtál az úgy ahogy van, nem igaz. Tizenplussz éve használom, soha nem volt stabilitási probléma vele. Az AUR-ból való telepítések esetén történő fordítások pedig ugyanígy finomhangolhatóak, van make.pkg amiben beallíthatod az USE flag opciókat, az Arch wiki helyenként konkrétan a Gentoo handbook aktuális részét linkeli be, a hogyan optimalizálj részben. Simán ajánlanám Fedora helyett, a csomag kezelés az rpm/dnf lassúsága után felüdülés lesz.

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. /  "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

Nincs igazad, hamis próféta vagy! Jézus egyedül a Gentoo linuxon keresztül sugározza szeretetét az ő nyílt forráskódú jámbor híveire! :)

*mindez csak utalás Umberto Eco új hitvitákról szóló ikonikus írására:)

Szóval vannak valid pontjaid, még eretnekként is:) aláírom, hogy a pacman érezhetően gyorsabb, mint a dnf, bár a DNF5-tel ez most sokat javult.

A stabilitás kapcsán viszont szerintem mást értünk ezen a fogalom alatt. Te mint 10+ éves veterán, rutinból kezeled azokat a helyzeteket (manual intervention required), amik egy átlagfelhasználónál simán rendszerösszeomlásnak minősülnének. Az Arch definíció szerint bleeding edge, ami magában hordozza a törés kockázatát egy Debian Stable-hez, de még akár egy Fedorához képest is, ahol a csomagok tesztelése szigorúbb release kapukon megy át.
Aki 10+ éve használ Archot, az tudja, hogy frissítés előtt el kell olvasni a híreket a főoldalon, tudja, hogyan kell chroot-olni és helyreállítani a rendszert, ha egy glibc vagy python frissítés eltör valamit. Egy kezdőnek vagy átlagos Fedora-felhasználónak a "stabilitás" azt jelenti: "Soha nem kell a motorháztető alá néznem". Arch-nál ez nem garantált. Ezt illene belátni. 

A makepkg.conf és az AUR valóban ad teret az optimalizálásra (-march=native), és az Arch Wiki tényleg a világ egyik legjobb dokumentációja lett (miután a gentoo-wiki-t elvitte szerverestől a végrehajtó). De azért a Gentoo USE flag rendszere, ahol globálisan vagy csomagonként deklaratívan kapcsolhatsz ki/be funkciókat és függőségeket, nem csak fordítási opciókat, hanem egy másik szintű granularitást ad.

Ráadásul ott van a Gentoo Overlay rendszere, aminek Arch alatt nincs valódi strukturális megfelelője. Az AUR, bármilyen hatalmas és hasznos is alapvetően egy ömlesztett, vadnyugati szkriptgyűjtemény. Ezzel szemben az Overlay-ek dedikált, témára szabott, karbantartott fiókok (pl. audio, science, vagy egyedi fejlesztői repók), amiket tisztán, a csomagkezelőbe integrálva lehet kezelni, priorizálni vagy maszkolni. Ez a fajta strukturált külső forráskezelés hiányzik az Arch-ból.

Te, mint Gentoo veterán (én is az vagyok, még mielőtt) olyan feature-ket hiányolsz az Arch-ból, amit egy átlagfelhasználó sosem fog hiányolni, főleg Fedoráról jőve.

Egy kezdőnek vagy átlagos Fedora-felhasználónak a "stabilitás" azt jelenti: "Soha nem kell a motorháztető alá néznem". Arch-nál ez nem garantált. Ezt illene belátni. 

Ez pedig egyszerűen nem igaz. Akárhányszor futottam neki a Fedorának, mindig, minden egyes alkalommal jött valami olyan update (verzión belül!) ami miatt be kellett néznem a motorháztető alá. Ehhez képest Arch-on tényleg soha nem kellett komolyabban szívnom semmivel - mármint azokon kívül, amik garantált szívást jelentenek minden Linux platformon, pl nvidia driverek -, talán egyszer volt egy komolyabb kalandom a kernellel, de az is megoldódott azzal, hogy felraktam az LTS kernelt. Amit egy átlag Fedora felhasználó lát az Arch-ból - pláne, ha távol tartja magát a 5-10 telepítéssel rendelkező AUR csomagoktól - az pont ugyanazt a stabilitást adja meg, vagy még jobbat is, mint amit a Fedora tud.

Ráadsul az Archnak már vannak "stabilabb" forkjai is, pl Manjaro, amit még jobban tesztelnek. Plusz, az Archnak is van már nem-rolling ága, ami stabilnak kikiáltott verziókat freezel a rendszercsomagokból.

Szóval, a lehetőségek végtelen tárháza van, ha az ember nem a kulcslyukon benézve próbálja kitalálni a dolgokat, hanem összeszedi a bátorságát és kinyitja az ajtót. Aztán belépsz vagy sem, ez már rajtad múlik.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Mohamed baszasson seggbe egy tevével ha valaha is prófétai babérokra törnék.

2025-ben 2 db olyan manuális beavatkozást igénylő eset volt, ami átlagfelhasználót érint, abból az egyik már feltételes (akkor, HA X11-el használsz KDE Plasma-t). A másik egy firmware csomag manuális felülírását igényelte (nvidia-firmware) ami nálam speciel nem volt szükséges, pedig a desktop gépemben nvidia vga van, telepítve és használva van a csomag. Simán frissítettem, felülírta, nem kellett beavatkoznom. A többi 4 db nem átlagjózsi felhasználási körét érintette, tehát nem kell vele foglalkoznia. Mellesleg ha átlagjózsi, akkor neki ott a pamac grafikus csomagkezelő, ami szól ha manuális beavatkozást igényló eset fordul elő, szóval nem kell frissítés előtt az archlinux.org-ra "rohangálnia".

 

Pár hete jóanyám ~15 éves pc-jében megfrömedt a táp és vitte magával az alaplapot, megzizzentve közben az ssd-n lévő xubuntu fájlrendszerét. Megpatkoltam hogy a képei, stb meglegyenek, de mentés után inkább újrahúztam neki az aktuális LTS-t, ahogy a művelt xp-s mondja, kapott egy CeanInstall-t. Na ezzel csak egy délutánnyit szívtam, mert az ubuntu által szállított Xorg csak és kizárólag az 1024x768-at volt hajlandó beállítani felbontásnak, minden hivatalos megoldás, Xorg.conf, xorg.confd mágia csődöt mondott, a végén bash scriptet kellett írnom és bebaszni autorunba hogy login után 3 másodpercel fusson le és kényszerítse ki a helyes felbontást. Fedora-t eszemben sem jutott volna rárakni, azon a gépen egy snap ubuntu frissítés is 10 percig tartott, nem győztem a francba levakarni róla az egész snap förmedvényt. A gép nem kompatibilis wayland-al, már csak ezért sem próbálkoznék rajta Fedora-val. Hogy miért Xubuntu? Mert beaktiváltam rajta az Ubuntu Pro-t, így 2032-ig nem kell a gépet dist-upgrad-elni, automata frissítést bekapcsoltam, így ha hónapokig nem nézek rá (a pc-re, nem anyámra), akkor is van egy Windowsnál jóval biztonságosabb, "friss", 98%-ban gondozásmentes rendszere.

 

Fedora-nál nem kell a motorháztető alá nézni átlagjózsinak? Persze, amennyiben pl nem akar megnézni egy videót, M$ fontokat használni, zárt drivert, stb, amikhez emlékeim szerint Fedora-n külső repot- kell felvenni, HERETIC TERMINÁL HASZNÁLATÁVAL!!!44 /HERETIC . RPM Fusion a neve, emlékeim szerint.

Az arch wiki konkrétan a Gentoo wiki Safe CFLAGS fejezetére küld el, nem merül ki a (-march=native) lehetőségben, szálkezelést, alapértelmezett tömörítők beállítását, mi több cseréjét is lehetővé teszi. A makepkg használatával akár az egész rendszert újrafordíthatod, mintha Gentoo-n "tolnál" egy emerge world-öt. A pacman és a makepkg együttes beállításával pedig egész Gentoo szerűen megvalósítható a csomagkezelés testreszabása, mit, hogyan, honnan frissítsen, mihez ne nyúljon, stb. Nem egészen valósítja meg teljes valójában a Gentoo "újrafordítom a pilincka lófaszt is mert így gyorsabb lessz 0.0000000000001 s-al és biztonságosabb" életérzést, de ha szeretsz sajtreszelővel rejszolni, megoldható. Csak természetesen felesleges.

A Gentoo Overlay rendszere valóban olyan egyedi megoldás, amire Arch alatt nincs alternatíva, csak ugye feljebb átlagjózsiról beszélgettünk, akinek ha Gentoo-t mutatsz, kereszteket vetve sikítva fog menekülni.

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. /  "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

( Raynes v | 2025. 11. 29., szo – 17:24 )

Ubuntura semmiképp ne válts, tanuld meg ezt megoldani azon a disztrón, amin most vagy.

Amikor belassul, nézegesd top, htop (folyamat és kernelszálak is legyenek listázva benne, default ez ki van kapcsolva), iotop, lsof kimeneteket, hogy mi okozza, I/O, CPU, memóriahiány, melyik folyamat, melyik szála.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Én például kimondottan kedvelem a Fedorát, de azt látom hogy vannak jól sikerült kiadásai, és rosszul sikerültek. Általában a páros számúak a jobbak, ezért is maradtam 42-őn, nem rakom fel a 43-at.

Persze volt időszak az elmúlt években, amikor épp' negatív spirálban volt a Fedora, nagyon új dolgokkal kísérleteztek inkább kevesebb mint több sikerrel. Ezeket eleve kihagytam. Ezen időszakokban nálam az OpenSuSE meg a Mageia az alternatíva, azok is beváltak.

( pepelopez | 2025. 11. 29., szo – 17:28 )

fstrim? mondjuk nálam nem okozz lassulást

nem mindig a fájlrendszerben van a para, mármint van, hogy g..i lassú és semmi mozgás nincs benne. gpt-vel néztük a trim-et is, de nem volt semmi extra.

tiltottam ipv6-ot is, valaki írta, hogy az a para. de nem jó, most is lassul. tiszta gáz. valszeg gnome-nál van valami. de htop-ban is ugrál minden.

2.25-ös a load most, de mondjuk 16 szálon nem kéne annyira szenvedjen.

( denton | 2025. 12. 02., k – 08:07 )

Egyik ismerős azt mondta, hogy ő direkt az utolsó pillanatban frissít az úk disztróra, valszeg én csesztem el azzal, hogy az újat telepítettem fel a 42-es helyett. Mondjuk megvallom nem néztem meg, hogy most jött épp ki.

Valszeg visszarakom a 42-est., hiba volt frissíteni.

( NevemTeve | 2025. 12. 02., k – 08:29 )

Tipikus hibaokok: lemezhely, systemd, (anti)virus.

( locsemege v | 2025. 12. 02., k – 09:57 )

Ugye nem túl szerencsés érvelés a worksforme. Három számítógépemen használok Fedora 43-at, az egyiken Intel 4200, a másik kettőn AMD Ryzen 7 CPU-val - az AMD-sek egyike desktop, a másik notebook -, semmi baj a sebességével, a load 0.36 most épp, a CPU usage 1 %. Mindez úgy, hogy az egyik gépen RAID1-ben vannak a háttértárak, két SSD és két HDD. Munkára, szórakozásra egyaránt használom őket.

Vannak háttérfolyamatok, amelyek ideiglenesen eszik a CPU-t és a háttértár sávszélességét - iowait -, de ez sem okoz érzékelhető lassulást. Az fstrim, updatedb, mandb ilyen folyamatok, de akár a dnf-automatic is, ha megengeded neki a háttérben történő frissítést.

Mit jelent az, hogy lassú? Lehet valami hálózatspecifikus dolog, névfeloldási probléma? Mert gvfs samba eléréssel kínlódok, de ott nem a gép lassú, vélhetően névfeloldás timeout-ra várás van.

Az sem világos, miért csináltál tiszta telepítést. Persze nyilván nem ez okozza a bajt. Én utoljára Fedora 18-at telepítettem tisztán, azóta a jelenleg futó Fedora 43-ig mindig csak frissítettem, közben cseréltem alatta hardware-t és disk layout-ot is.

Értem, hogy csak használni akarod, nem szögelni, de ez egy nagyon rossz hozzáállás. Mindegyik disztribúció nagyjából ugyanazokból a nyílt forrású komponensekből építkezik, bár van, hogy ugyanarra a feladatra az egyik ezt, a másik azt használja, ha ugyanazt, azt is eltérő konfigurációval. Mondjuk lesz, amivel most elégedett vagy, aztán ott majd lesz más problémád. Jó volna inkább kideríteni, mi a baja, aztán megjavítani.

Lassú lehet kevés RAM és swap-elés miatt, vagy memory leak-es software miatt akár.

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

( SPYFF v | 2025. 12. 02., k – 12:15 )

Debian sid/experimentalon vagyok évek óta, két emlékezetesebb lassulásom volt az elmúlt hónapokban:

  1. Az egyik egy bizonyos tracker-miner daemon volt, de ez egy régi, időről időre előbukkanó probléma. Hiába lövöd ki, respawnol.
  2. A másik pedig egy Nautilius bug volt: ha megnyitottam egy fájlkezelő ablakot, egy kattintás után fullosan elkezdte pörgetni a CPU-t. De ha csak megnyitottam és nem bántottam, kicsit hosszabb időn belül akkor is.

Viszont ezek login után jöttek elő. Ami talán login előtt is gondot okozhat, az egy törött Gnome extension. Próbáld esetleg letiltani összes Gnome extensiont ha még nem lenne. Lassuláskor látsz valami magas I/O vagy CPU használatot htopban? Esetleg a perf top hogy néz ki, nincs valami maszkolatlanul pörgő interrupt?

( imbuszkulcs | 2025. 12. 02., k – 14:45 )

Esetleg ssd trim? Ha 0 lesz a hasznos I/O a diszken, az is beokoz a mai disztróknak.

( denton | 2025. 12. 02., k – 16:27 )

Megint elkezdte. (bocs, hogy így külön írok és nem kommentek alatt)

Most elkaptam pár dolgot, talán mégis fájlrendszerben lesz a gond. (fs a gyengém)

iotop alatt most épp 28M-os írás volt, máskor 100MB-los olvasás is volt. A chrome alatt mennek.

gpt-vel nézve:

 

sudo btrfs filesystem df /
Data, single: total=130.01GiB, used=119.84GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=3.00GiB, used=1.97GiB
GlobalReserve, single: total=306.72MiB, used=0.00B

 

Köszi, ez nagyon fontos adat, és már ebből látszik is a probléma gyökere:

⚠️ A Metadata tele van!
Metadata, DUP: total=3.00GiB, used=1.97GiB  →  ~66%


Ez még nem 100%, de BTRFS-nél a metadata 70% felett már folyamatos flush / reclaim / blockgroup-mozgatást indít, ami pontosan azokat a btrfs-endo-write, flush-btrfs-* kworker folyamatokat okozza, amiket a screenshoton láttál.

 

Fut chrome rendesen, most épp több phpstorm példány, dockerből több komolyabb projekt, lens desktop a háttérben, stb.

(42 alatt nem volt gond amúgy, ott is ezek voltak)

 

Most azon agyalok, hogy esetleg btrfs-ről ext4re átállni, gpt szerint az jobb ennél a felhasználásnál, de fene tudja okosat mond e.

Most már "csak" 2 a load, előbb 5 felett volt. (nyugiban 0.3 körüli). Elswappelt 1GB-ot is. (16GB RAM van a gépben és 16 szál)

Milyen infó lenne

Ja, hogy btrfs. Nem ismerem, de évekkel ezelőtt sikítva menekültem tőle valamilyen kellemetlen tapasztalat miatt. Az xfs pedig úgy mozgatta a fejet, hogy zenélt a HDD-m.

Linuxon kizárólag ext4-et használok. Jó, nyilván az EFI FAT, ha már az a szabvány, illetve a swap az meg swap, de a normál fs-ek mind ext4-ek.
 

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

SSD-t nézted, hogy mit mond magáról (smartctl vagy bármi)? Nekem már "csak" 88% a total host write alapján számolt élettartam, de olyan 90% körül kezdődően kegyetlenül be tud lassulni, amikor sokat írok rá és közben 60-65 °C fölé melegszik (gondolom valami önvédelem miatt lassítja magát).

https://iotguru.cloud

Amikor meg kell mondani, hogy hova telepítsed, akkor a jobb felső sarokban van 3 pöttyös kis setup gomb.

https://us1.discourse-cdn.com/fedoraproject/original/3X/7/4/74e41f13e162718db821c5085d98dba899b3d9fe.jpeg

ott katt a storage editoros menüre.

Azon belül manuálisan tudsz particionálni. (boot, efi és a többi)

Ha minden ok és jók a mount pointok is, akkor visszatérve az előző oldalra engedi a telepítést a létrehozott particiókra.

Netinstallt használtam, Xfce-t választottam, s emlékeim szerint nem így nézett ki a telepítő, ellenben nem tartom kizártnak, hogy nekem is volt három jelentéktelennek tűnő pöttyöm. Vacakul érzem magam, mert az ismerősömnek btrfs-re tettem a Fedora 43-at. :(

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

Ezt a három sarokba eldugott pöttyöt soha nem vettem volna észre, én sem tudtam fájlrendszert választani a 42-es telepítésekor. Viszont az automatika pont jól belőtte az igényeimet így nem panaszkodom. Később utána olvastam ennek a btrfs-nek, és látok benne fantáziát, az elmúlt fél évben semmi gondom nem volt vele. (Mondjuk magamtól nem is választottam volna, csak hát a Fedora most kvázi kötelezővé tette).

Ha btrfs, az tényleg lassulhat be, ha snapshotot csinál épp. Amúgy nem rossz fájlrendszer az, de ha ez a tudása neked nem kell, kikapcsolhatod rajta. Az ext4-gyel mindenképp jobban járnál, az tényleg baromi gyors, mert nincs benne egy csomó ilyen extra funkció, meg COW, meg egyebek, amik lehúznák a teljesítményét.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Azért szerintem nem annyira overhead nélküli. Főleg, ha sok adatot kell menteni, annál el tudom képzelni, hogy lassíthat. Esetleg fstrim service vagy valami hasonló. Nyilván pontos kimenetek híján csak találgatni tudunk a nagyvilágba.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Azért szerintem nem annyira overhead nélküli.

Hát pedig.

Főleg, ha sok adatot kell menteni, annál el tudom képzelni, hogy lassíthat.

Mikor kell sok adatot menteni? A snapshot nem mozgat semmilyen adatot sehova. Minden, ami ki van írva, az CoW fájlrendszeren immutable, snapshot esetén kap a fájlrendszer egy marker-t (konkrétan lesz egy root block pointer másolat), ami kb. jelzi, hogy adott timestamp előtt tartson meg minden amúgy is immutable adatot és amikor módosít, akkor az új adat kiírása után nem törlődik a régi (amúgy felülírt) adat, mert arra mutat még referencia. Oszt ennyi. A snapshot készítése majdnem nulla I/O igényű és utána az írás is majdnem nulla I/O többlet-igényű, mert úgyis új blokkot írna, a snaphot törlése pedig csak egy root block pointer törlése, és utána minden, amire az adott fa mutat, írható területté válik (zero reference block).

Esetleg fstrim service vagy valami hasonló.

Az se I/O igényes, egyszerűen közli a fájlrendszer az SSD-vel, hogy milyen range az, ami "üres".

https://iotguru.cloud

Snapshottal nincs tapasztalatom. Tetttem már fel disztrót, pl. Fedora, ami btrfs snapshotos volt, én ott nem tapasztaltam lassulást, de csak teszttelepítés volt, nem sok adattal.

fstrim-ről viszont tudom, hogy lassíthat, nálam most jelenleg a FAT32-es boot partíciót nagyon lassan veszi a kézi fstrim szkript, meg régebben az f2fs-sel még lassabb volt. btrfs-t viszont még nem próbáltam trimmelni, mármint kézileg, hogy mérni tudtam volna. Azért az ext4 trimmelési ideje se valami villámgyors, ha sok adat van az adott felcsatolt partíciókon, eltart egy jó pár másodpercig nálam egy 2 terás NVMe SSD-n, igaz ezt a háttérben csinálja, lassulást közben más folyamatoknál nem tapasztaltam.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Úgy értve, hogy az én fő rendszeremen nem állítottam be ezt. Természetesen vannak disztrók, amik tolják ezt, de ott meg nem volt rendszeres a használat, meg alig volt adat az adott rendszeren, nem is nagyon volt mit snapshotolnia a rendszernek.

Rugózhatsz rajtra, de itt te is csak találgatsz, amíg a kért kimeneteket nem csatolja be a kolléga, biztosan akkor tudunk.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

( msandor v | 2025. 12. 02., k – 16:38 )

A megjelenés hétvégéjén frissítettem, de nem futottam bele hasonlóba (6 éves laptopon).

( kerozoli v | 2025. 12. 02., k – 16:58 )

Ami a kereséshez indexeli a fájlok tartalmát is az szokta még esetleg megölni időről időre (nekem 43 ra váltáskor az okozott egy ideig gondot de most elmúlt)

( locsemege v | 2025. 12. 02., k – 21:56 )

Ma telepítettem egy oprendszer nélküli számítógépre Fedora 43-at. Azon nagyon megütköztem, hogy a telepítőben nem lehet disk layout-ot csinálni kedvünkre, mint régen, illetve nem lehet filerendszert választani, mint régen. Persze, ha van időm, rescue módban boot-olva a telepítő pendrive-ról megágyazok neki, kialakítom a layout-ot, majd utána telepítek - feltéve, ha a telepítő felismeri -, de most siettem, szóval btrfs került az ismerősöm gépére. Szegény...

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

Igen. :( Elég kellemetlen, hogy kiszedték a telepítőből. Lehet, ki kellene próbálnom virtuális gépen, hogy ha kialakítom a disk layout-ot, ext4-re formázok, akkor a telepítő azt csinálja-e, amit szeretnék.

Saját gépeimen azért nem gond, mert nagyon régóta csak upgrade-elek, az filerendszerek maradnak.

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

Lehet, ha előre kiosztod a partíciókat. Régebben 1GB ext4 /boot volt a kötelező, most azonban 2.14 GB a gyári default, adtam neki 3-at. :-)
Az /boot/efi-nek meg kell a boot flag, másként nem enged tovább hiába fat32-re formázol. Flag nélkül vfat-nek veszi a telepítő.
Plasma liveból próbáltam gyorsba. KDE partíció managerrel operáltam.

:-) 

( BehringerZoltan | 2025. 12. 02., k – 23:43 )

Na de Linus is megmondta, h a RAMok mennek tönkre és nem a szoftver bugzik, úgyhogy vegyetek folyton új RAMokat a gépbe!

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Van ezzel a szó nélküli cserével némi ellentmondás! Linus szerint a kékhalálok is non-ecc ramok miatt lehettek. Ezt ő mondta a szájával. 
Nekem sem rémlik h lett volna dolgom valaha hibás rammal. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Van pedig.., valamivel gyakrabban fordul elő mint proci-meghibásodás. - Kb. 30 év alatt, 50 munkagépes, "workstation" kategóriában cserélnem kellett 4-5-ször meghibásodás miatt. (Esetemben leginkább Samsung típusokat ért el e végzet. - Igazsághoz tartozik, bőven 10 év felett napi 10 órában használt gépekről, - gondolom, leginkább érintett tápegységekről, alaplapi kondenzátorokról is szó van ilyenkor.) A "kékhalálok" 2005 után elkerültek, - egyszerűen olyannal, a 90-es években, leginkább 95-98-as Win és DOS-korszakban kellett mérkőznöm talán utoljára.

(Ezen az időtávon meghibásodott Procira.., - egyre emlékszem...)

:)

Egyszer én is találkoztam döglött rammal. Fordítva tuszkoltam be a foglalatba, egy több mint 3 órás kínlódással egybekötött gépépítés után.

Máig nem értem hogyan sikerült a művelet, viszont szépen füstölt. Azt hiszem még megvan valahol.

Még nincs aláírásom.

( csucsu | 2025. 12. 03., sze – 09:05 )

a 43-ra váltás után érezhetően felgyorsult a Vivobook-om. Sajnos a hibernálásba néha belefagy. AMD proci...

( denton | 2025. 12. 03., sze – 13:33 )

https://i.imgur.com/J8Pqb1L.png

Már több mint fél órája ezt csinálja, váltogatva, mikor melyik app van felül. Most épp 407M-val ír.

Szerintem ez megdöglött, már naponta többször csinálja.

ma újratelepítek ext4-el.

átgondolom majd a többi disztrót is, de nyilván mindegyiknél vannak előnyök és hátrányok is.

( influencer | 2025. 12. 03., sze – 21:18 )

Denton, te aztán tudod, hogy kell veszélyesen élni... friss Fedóra, brtfs... extrém sportokat is csinálsz?

Ne értsd félre, tud nagy eséllyel működni, csak előfordul, hogy nem. Én évente 2 napot szívtam a Fedora hasonló dolgaival, aztán váltottam a lentiekre és többet nem volt ilyen. 

Sok mindent ajánlottak. Az Ubuntu a Fedóránál stabilabb, de csak az lts változatot javaslom, és azt is kb 1-2 évvel a friss után frissíteni az újra. Még jobb az Xubuntu, ha az is elég. Ennél még jobb az alap Debian grafikus felülettel. Mármint nekem elég. 

Ext4 legyen mindenhol ahol lehet, és ezzel sem lesz gond.

Az Ubuntu a Fedóránál stabilabb

Ez egy nehezen értelmezhető mondat. Más a Linux kernel egy Ubuntuban, mint egy Fedorában? Már persze, ha azonos verzió. Vagy más a Midnight Commander?

Mindig Fedorát használok és stabilan működik. Az a gyanúm, btrfs Ubuntun is csuklana. Tehát nem a Fedora a probléma, hanem a btrfs.

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

Más a Linux kernel egy Ubuntuban, mint egy Fedorában? Már persze, ha azonos verzió.

Igen, mert az Ubuntu és a Fedora más-más patchkészlettel szállítja őket. De amúgy nem azonos verziók sem. Lehet olyan patch a Fedorában, ami még nincs jól kitesztelve, vagy nagyon új még, ami az Ubuntuban benne sincs.

Még a Gentoo-ban is másabb ugyanaz a verziós kernel, mint a Fedorában. Ettől disztribúció a diszribúció, hogy nem mindenki halálpontosan ugyanazokat a csomagokat szállítja. Akkor csak egy nagy Linux userland lenne. 

Munkahelyen mindig Ubuntut használok, és stabilan működik. Pedig nálunk diszk titkosítástól kezdve minden is van. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

A kernel eleve nem ugyanaz a verzió, az aktuális Fedorában jellemzően frissebb van, és más konfig is. A programok is jellemzően frissebbek, ami frissebb hibákat is jelent, tehát a stabilitás mindenképpen eltérő lesz. A 'nem a Fedora a probléma, hanem a btrfs' jó kijelentés, ha egyszer a Fedora default btrfs filerendszerrel települ :) Nekem van Debianon btrfs partíció, igaz, nem gyilkoltam sokat, de nem volt vele problémám, tehát még ez sem biztos.

Őszinte leszek, valamit benéztem, mert azt hittem, hogy régebbóta kiadták már a 43-at. Bár, igazából nem mondom, hogy nem váltottam volna ha tudom, hogy kb 1 hónapja adták ki. Nem volt vele ilyen tapasztalatom. Azt olvastam, hogy Fedora a kísérlet, de jóhiszeműen úgy gondolkodom, hogy azért adják ki az új verziót mert működik. De nem :D

Igazából 2 éve használok desktop linuxot. Előtte csak windowson dolgoztam, linux pedig csak szerver szinten fordult elő nálam. Szóval még gyűjtöm a tapasztalatokat.

Ext4 ok, tegnap este újrahúztam mindent. Most bikagyors. Délre érkezik az alzaboxba 2x16GB ram, az is segít majd kicsit.

(Ubuntuval kezdtem 2 évvel ezelőtt amúgy. Ahogy írtam feljebb másnak is, kb 2 hét alatt összeomlott. Akkor váltottam Fedorára.)

( hunluki | 2025. 12. 04., cs – 10:20 )

Nem fogsz vele sokra menni, de nekem eddig works4me a 43-as. AMD 6600H miniPC 32 giga rammal, semmi extra. Annyi volt hogy wine-t törölnöm kellett mert valami konflikt megakadályozta az upgradet, leszedtem, upgrade, rápróbáltam az összes játékomra és minden ment ahogy eddig. Talán 2-3 napig volt olyan gondom hogy sleepbe ha lement akkor ott maradt de valamelyik frissítés javította, azóta nem tudok belekötni.

Pedig titkon szeretnék opensuse tumbleweedre váltani de olyan kényelmesre belaktam a rendszert hogy amíg nincs valami dealbreaker ok addig nem szánnék rá egy percnél se többet.

( Fisher v | 2025. 12. 04., cs – 13:17 )

Szóval, amit én csinálnék: amikor meglassul, akkor vmstat 2

fisher@s3:~$ vmstat 2
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0 160156 335572  14192 479144   13   22   272    34  998    1  6  2 91  0  1  0
 0  0 160156 335564  14192 479156    0    0     0     0  972  132  1  1 98  0  1  0
 0  0 160156 335564  14200 479156    0    0     0    40  993  156  1  0 99  0  0  0
 0  0 160156 331468  14200 479156    0    0     0   206 1042  148  1  1 98  0  1  0

A memória része gondolom egyértelmű.

A si/so: swap aktivitása, a so mocoroghat attól is, hogy a kernel igyekszik kirámolni dolgokat a memóriából, hogy legyen elég cache/buffer/mittomén.

A bi/bo: mennyit szöszöl a diskkel (nagyon pongyolán foglamazva). Ha lassuláskor itt pörögnek a számok, akkor teker a disk (az eseteben, ha jól láttam mindent, nem ez a helyzet)

Jön az érdekes, a cpu, és abból is a wa. Ha ez itt magas (függ attól is, hogy mennyi a magok száma), akkor sokat vár valamire. Diskre, hálózatra valamire. Én kb. arra tippelek, hogy itt lesz a bibi, és szintén vakon az ssd "miatt", pl. fut trim vagy bánat tudja hogy mi.

Az st, gu az esetedben nem kéne hogy tényező legyen. A sy és cs se valószínű hogy játszik majd. Ha az us magas, az "jó", de ne szaladjunk előre.

Ez így 2 %-os CPU kihasználtság mellett roppant érdekes kérdés. A cikk szerint gyorsít, bár gondolom, az eredménye miatt, azaz nem lesz kupleráj az ext4 filerendszeren. Az mennyiben izgalmas kérdés, ha a hulladék idő egy részét rendrakással tölti? Ha viszont állandóan 97 % körül van a CPU kihasználtságod, alulméretezted a számítógépedet a feladathoz. Ha meg olyan, mint a C forráskód fordítása, akkor meg semmi baj azzal, ha valamivel osztozik még a CPU-n.

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

Ez neked amúgy miért jó?

Ez tök fasza olyan szerver alá, ami amúgy is eldobható, nincs crash recovery, nincs reboot, ha megbotlik, akkor terminálódik az egész a fájlrendszerrel együtt. Minden más esetben antipattern, adott esetben lesz egy inkonzisztens fájlrendszered, ami nem tud helyreállni crash után.

https://iotguru.cloud

( denton | 2025. 12. 14., v – 12:37 )

Újra előjött a probléma, ext4-es fs-el is. 32GB ram-al.

nem fut az fstrim elvileg.

kezdem unni.

Nem tudom, 42 alatt nem volt ilyen, pedig nyúztam rendesen a gépet.

gpt-vel végignézettem egy csomó dolgot, arra jutott, hogy nincs terhelve a disk, nincs terhelve a cpu (ilyenkor 2-es loadon fut amikor ez a szar van, egyébként 0.5 alatt lenne). Néztük a cpu frekvenciát, elsőnek úgy tűnt, hogy beragadt 400MHz-n, de kiderült, hogy fals infó volt és az is oké. Az fstrim állítólag oké, be van kapcsolva, de waitingben van. Gyanakodott a gnome-ra, de már a reboot elején is belassul ilyenkor, így nem valószínű. Próbáltam amúgy gnome classic-al is, de nem javította meg.

Kernel downgrade-t javasol, de nem sok kedvem hozzá.

Fix: mármint több kernelt egymás mellett.

Nekem Lenovo x280-nal volt problémám, de nem lassult, hanem sűrűn lemerevedett pár másodpercre. Jelenkezett Ubuntuval is és Fedora Workstationnel is. Logokban nem találtam erről semmit. Letiltottam BIOS-ban a Wireless WAN-t, az ujjlenyomat olvasót, a Bluetooth-t és a Thunderbolt. Valamelyiktől megszűnt a probléma.

$ grep -c egy$ word.list
100