2. Fórumok
  3. OS, alkalmazások
  4. Ubuntu Linux
  5. (kiemelt téma)
  • Téma összefoglaló
    Utoljára frissítve: 2023-12-13 05:03

    Fototrend


    Ubuntu Linux Összefoglaló

    Hivatalos Ubuntu dokumentáció



    Amennyiben kérdésed lenne, kérünk, add meg a szükséges adatokat a hiba minél pontosabb leírása mellett:

    -számítógép típusa, hardverek pontos megnevezése (különösképp videókártya, vagy hálózati egységek)
    -a használt rendszer pontos neve, verziója, a grafikus felület
    -mikor és hogyan jelentkezett hiba, mi váltotta ki (program telepítés, frissítés, ...)
    -eddigi próbálkozások a megoldásra (ha voltak ilyenek)

    A hardverinformációkat legegyszerűbben úgy gyűjtheted össze, ha megnyitod a Terminál nevű programot a menüben. Ide írd be a következő parancsokat (mindkettő után nyomj Enter-t):

    lspci
    lsusb

Új hozzászólás Aktív témák

  • #15174 Fire/SOUL/CD félisten Kendek #15038
    Új Válasz #15174
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Fire/SOUL/CD

    félisten

    válasz Kendek #15038 üzenetére

    "Na jó, de az fstrim nem ugyanaz mint a discard csatolási opció."
    Ha ezt valóban kijelentésnek szántad, akkor így van, azaz nem ugyanaz. Ha szánsz rá időt és 5-10x eljátszod ezt(mármint, amit írtál az fstrim-el script futása közben), akkor néha azt fogod tapasztalni, hogy nem történik meg a karbantartás(és az úgy is van "jól").
    Az fstrim (és egyéb hasonló cucc) utólag csak a nem használt blokkokat tudja karbantartani, a TRIM viszont valós-időben lap-szinten tart karban (1 lap 4KiB, 1 blokk meg változó számú lapból áll, mérete változó 256Kib-1Mib közt van általában). Ha egy fájlt törölnek, akkor olyan információk vesznek el, amik hiányában utólag csak blokk-szinten lehet karbantartani(ami pl 1 lap miatt is 256Kib-1MiB írást generál(hat)).

    Ez okozza azt a látszólagos anomáliát, amit fentebb írtam, mert ha a script által létrehozott temp állomány olyan blokkba (is) kerül, ahol más fájl(ok) "darabjai" is megtalálhatóak, akkor az már nem minősül "nem használt blokknak", ahhoz nem nyúlhat(és nem is nyúl) az fstrim. Az, hogy bizonyos idővel mégis karbantartásra kerül a blokk, az nem az fstrim érdeme, hanem az SSD-kbe beépített Garbage Collection funkcióé. (igazából az fstrim inkább Force Garbage Collection vagy egyes (Windows-os) Defrag-ok Consolidate Free Dsik Space funkciójára emlékeztet)

    Gyorsaság kérdése: Ezt igazából nem tudom hova tenni, mert nem tudom ki írta, meg milyen szempontból kellene értelmezni. Én 2 részre szedem a kérdést.

    1. Maga a Linux működése nem lesz gyorsabb vagy lassabb bekapcsolt discard opció mellett sem, mintha csak időközönként lenne futtatva az fstrim
    2. Ha fájlkezelőben törlök egy fájlt, annak a menetéből adódóan természetesen lényegesen lassabb, mint az fstrim, mert ez utóbbi csak "egy parancs", amit az SSD FW-e, vezérlője és NAND-jai hajtanak végre(a belső adatátvitel nem keverendő az OS-t az SSD-vel "összekötő" pl SATA portok sebességével) nagyon gyorsan. De ettől maga az OS megint nem lesz gyorsabb vagy lassabb...

    Windows XP/Vista nem támogatja a TRIM-t, azok alá szoktak Force GC opciós progikat tenni, amik időközönként elindulnak és a háttérben karbantartanak, de W7 vagy újabb esetén erre nincs szükség, mert a TRIM hatékonyan teszi a dolgát (Windows nem tesz különbséget HDD és SSD közt, a TRIM parancsot HDD esetén is küldi)

    Őszintén szólva én nem látok a Linux-ban semmi rációt a TRIM kezelésével kapcsolatban, nem találok semmi fejlesztői infót, hogy miért ezt az időzített/utólagos/több írást generáló megoldást preferálják...

Új hozzászólás Aktív témák