Gyurkity Péter

Intel: nincs szó az SSD-k belassulásáról

Egy friss teszt szerint az SSD-meghajtók idővel sokat vesztenek írási sebességükből, ami komoly gondot jelenthet a felhasználóknak. Az Intel szerint erről a valós életben nincs szó, ám azért egyeztetnek a tesztelőkkel.

A PC Perspective által nemrégiben közölt részletes teszt azzal az eredménnyel zárult, hogy az Intel saját X25-M jelzésű meghajtója egy idő után drasztikus mértékben belassul, ami főleg a flashmemória "fáradását" megelőzni hivatott vezérlőnek, valamint az általa használt szoftvernek köszönhető. A teszt komolyan veszélyeztette az SSD-k imázsát, ezt pedig a gyártó nem hagyhatta szó nélkül.



A lap állítása szerint az eredetileg 70 MB/s-os írási sebesség idővel akár 25 MB/s alá csökkenhet, ami a hagyományos merevlemezeknél is lassabb, így tehát a mindennapokban az új technológia nem igazán jelent előrelépést az elődökhöz képest. A problémát az jelenti, hogy az írások számát csökkentő algoritmus (amely logikai blokkokat alkalmaz a meghajtó fizikai, valós blokkjai helyett, olykor több kisebb fájlt használva egy-egy blokk kitöltéséhez) miatt az operációs rendszer nem tud mit kezdeni az állományok töredezettségével, hiszen azt csak a vezérlő látja a maga valóságában. A meghajtó egy idő után megőrzi, "archiválja" ezt az állapotot, az állományok töredezettségén tehát nem igazán lehet javítani.

Amennyiben az operációs rendszeren belül szánjuk rá magunkat a töredezettségmentesítésre, ezzel csak tovább rontunk a helyzeten, hiszen ez rövid idő alatt ementálit csinál a meghajtóból - nem véletlenül található meg a figyelmeztetés minden SSD mellett, amely a lépés veszélyeire hívja fel figyelmünket (más kérdés, hogy használhatnánk éppenséggel olyan fájlrendszert, amely megelőzi a töredezettség kialakulását, ez azonban a Windows platformon továbbra is álom marad). Az Intel azonban tagadja, hogy a valós életben ilyen súlyos lenne a helyzet. Szerintük a tesztelők által alkalmazott szintetikus megoldások a mindennapokban nem fordulnak elő, így a felhasználók sem találkoznak majd a komoly lassulással. Némi sebességvesztés mindazonáltal jelentkezhet, ez azonban a hagyományos merevlemezeket is érinti, ahogy lassan megtelnek a meghajtók.

A cég azért kapcsolatba lépett a lap munkatársaival, igyekezvén pontos információkat szerezni az általuk felhasznált megoldásokról - amennyiben ezt szükségesnek vélik, sor kerülhet az említett meghajtók firmware-frissítésére, ehhez azonban először is további adatok kellenek.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • dez #27
    (A helyi viszonylat alatt nem kimondottan az sg-t értettem.)
  • dez #26
    "Ne általánosíts. :)"

    Nem úgy értettem, hogy nincs ember, aki értené (már rajtam kívül). :P
    Csak ezt már kb. harmadszor írtam le, szerintem érthetően, de valahogy nem sok látszatja van, már helyi viszonylatban. Mindenki ugyanazt fújja tovább. Úgy látszik, ez a mindenki fújja a magáét (én is) játék. :)

    "Az első az, hogy több kisebb blokk törlése hosszabb ideig tart, mint egy ugyanannyi adatot tartalmazó nagyobb blokké. Ez a fő ok."

    Igen. Nem azért, hogy "villogjak" vele, de ezt már én is írtam. Mármint egyenesen következik abból, hogy egy kisebb és egy nagyobb blokk törlése ugyanúgy egy adott, vagy legalábbis kis eltérést mutató hosszúságú művelet.

    A másik, amit írtál, érdekes és hasznos, de (sajnos) a legtöbben már elriadnak ilyen mélységű tárgyalástól, és hát nem is annyira lényeges. Na persze minden ralatív, a Mari nénit bizonyára az sem érdekli, amit én írtam, de szerintem annyit azért "lehet tudni" a flash-memóriákról.
  • Alvarez999 #25
    "A fő gond az, amit a #14-esben írtam, de valahogy nem fogják az emberek. :)"

    Ne általánosíts. :)

    Azt nem árt még tudni, hogy miért csak a szektormérettel lehet játszani, és miért nem lehet a blokkméretet csökkenteni. Első ránézésre ui. úgy tűnhet, hogy egy kisebb blokkmérettel megoldódnának a gondok, pedig dehogy. Itt két tényező is szerepet játszik.

    Az első az, hogy több kisebb blokk törlése hosszabb ideig tart, mint egy ugyanannyi adatot tartalmazó nagyobb blokké. Ez a fő ok.

    A másik az, hogy a chipben lévő töltésszivattyú (charge pump) által leadott feszültség (amivel a törlés történik) nem változtatható szabadon, mert az írási/törlési folyamat nem indul el egy adott feszültség alatt. Ha csak kisszámú byte-ot törlünk, akkor a töltésszivattyú feszültsége alig esik, emiatt az egyes cellákba több töltést kényszerítünk bele, ami hamarabb telíti elektronokkal a lebegő gate szigetelő rétegét, ezáltal kevesebb törlés/írási ciklust visel el az adott cella. Ha egyszerre több byte-ot törlünk, akkor nagyobb mértékben csökken a töltésszivattyú feszültsége (persze még mindig elég nagynak kell lennie ahhoz, hogy az elektronok átalagutazzanak a potenciálgáton), így kevesebb elektron reked a szigetelő rétegben. Vannak olyan flash chipek, amelyeknél választható byte vagy page alapú törlés. Ezeknél komoly mértékben függ az élettartam (endurance) attól, hogy byte vagy page erase módszerrel törlünk, az arány másfél-kétszeres is lehet.

    Azt a tévhitet is el lehet felejteni, hogy az SSD-knél nem kell odafigyelni a hűtésre. Ha egy SSD 25 C fokon x számú ciklust bír el, akkor 60 C fokon ennek kb. csak a felét, nulla C fokon viszont a másfélszeresét.
  • dez #24
    (Ha kisebb a szektorméret, mint a blokkméret, akkor megmarad a lehetőség, hogy van olyan blokk, amiben van egy szektorméretnyi szabad hely, amikor is nem kell törölni az egész blokkot, csak be kell írni az adatot. Mondjuk egy idő után [sok kisebb file írkálá-törölgetés után] elfogynak az ilyen szabad [korábbi blokk-inicializálásból maradt] helyek, és a kisebb szektorméret sem ment meg a blokk-törölgetéstől, azaz a belassulástól.)
  • dez #23
    Ja, és nem feltétlenül jó ugyanakkorára (v. nagyobbra, tehát nem kisebbre) állítani a szektorméretet, mint a blokkméret, mert akkor a szektor írása egy teljes blokk-törlést+visszaírást von maga után [*], mivel a vezérlő nem nagyon fogja állandóan hasonlítgatni, hogy mi változott (ahhoz először mindig be kellene olvasnia az ott lévő adatot).

    * Kivéve, ha van szabad blokk, mert akkor oda kerül át az adat, mert úgy gyosabb az egész.

    Szóval, mint látható, itt a legfontosabb blokkos műveletekből eredő overhead minnél kisebbre szorítása és a wear-levelling; a töredezettség másodrangú. (Az első kettő eleve növeli a töredezettséget.)
  • dez #22
    Ha egy flash-mem blokkba több file adata is belekerülhet (kisebb a file-rendszer szektormérete), akkor azért nem teljesen mindegy a dolog, mert ezekre a blokkokra külön kell indítani az olvasási folyamatot is. Igaz, még így is sokkal gyorsabb a dolog, mint vinyóknál.

    A fő gond az, amit a #14-esben írtam, de valahogy nem fogják az emberek. :)
  • szombi #21
    Nem tudom miért ez a nagy felhajtás a töredezettség körül, mikor az SSD-nél
    gyakorlatilag nincs fejpozicionálási idő, és emiatt bármilyen sorrendben kiolvashatók a blokkok.
    Ha egy szektor 64kByte - os, az már naon gáz, vezérlő elektronikától függetlenül.
    Szal legyen 4 kByte, NTFS-nél az az alap, és mindenki örül. :)
  • arty #20
    "Jó csak azt is számításba kéne ám venni, hogy egy oprendszer bootjánál az SLC-s SSD sebessége kb 6-8x gyorsabb egy mezei SATA II-es vinyónál."

    Ez szimplán nem igaz. Gyakorlatban nem gyorsabb 6x egy "windows boot" SSD-ről, mint egy jó winyóról. Nagyságrendi különbség nincs, így ha 2 nagyságrendet romlik az SSD sebessége 1-2 év alatt, akkor az lesz JELENTŐSEN lassabb bootra is.
  • waterman #19
    olyan nincs, hogy egy filerendszer ne töredezzen. gondolj csak bele, egy nagyobb file-t letöröltsz, helyette beír oda egy kisebbet, meg még marad egy kis hely. azt a kis helyet is ki kell használni. lehet csinálni background rutin-t, hogy szépen néha pakolja egy helyre a nagyon sok darabból álló kis fileokat. az ssd-ken is ennek kéne lennie, hogy szépen ő maga a háttérben elintézi a nagyfokú töredezést. meg lehet eleve úgy tervezni egy filerendszert, hogy pár százalékos töredezettséggel még optimálisan képes működni.
    itt egy link az Ext4 filerendszer újdonságairól. a 10. pontban az online defragmanentation résznél esik szó róla, hogy ez is töredezik, de lesznek olyan eszközök, amivel például egy darab filet is lehet majd töredezettség mentesíteni, vagy a bootoláshoz szükséges fileokat egy helyen tarthatja a rendszer, defragmentálva.
  • barii #18
    úgy tudom az ext4 teljesen kiküszöböli