27
-
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. :) -
#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 -
kvp #17 "Emiatt érdemes volna ha továbbra egy blokk az SSD-ben "szektor" is lenne. Még a mai, nagy merevlemezeknél is ez a méret 512 byte."
Minden meghajtonak van egy nativ szektormerete es minden filerendszernek van egy nativ blokkmerete. HDD-k eseten a szektormeret altalaban 512 byte es a blokkmeret ennek tobbszorose. SSD-k eseten a szektormeret altalaban tobb mint 512 byte viszont neha a blokkmeret ennel kisebb. Jol beallitani a formazasnal lehet, mivel ha tul kis blokkmeretet hasznalunk, akkor foloslegesen kopik a tarolo, ha nagyobbat akkor viszont tul kis file-ok eseten sok helyet pazarlunk el. Kopas szempontjabol az idealis ha a blokkmeret megegyezik a szektormerettel. Elofordulhat, hogy igy viszont akar 64KB-os is lehet egy blokk, ami apro file-ok eseten nagy pazarlassal jar.
"Az oprendszer pedig mind a mai napig a CHS-LBA címzést használja,"
Az LBA logikai cimzest jelent, tehat ilyenkor a rendszer nem foglalkozik azzal, hogy az adott szektor pontosan hol is van, csak megadja a linearis sorszamat.
"Már csak azt nem értem, hogy hogy a lótúróba képes különböző kisméretű fájlokat egy blokkba rakni az SSD vezérlő"
Mondjuk a blokkmeret 4KB, a valodi szektormeret pedig 64KB (de ezt az ssd 512 byte-nak mutatja). Ekkor egy valodi szektorba akar 16 darab 4KB-nal kisebb file-t is be lehet pakolni.
A cikkben emlitett lassulas akkor johet letre, ha tul sok blokk van mar a replacement listan es ezt az ssd vezerlo aramkore nem asszociativ hanem szekvencialis modon vizsgalja. Alternativakent csinalhatnak jobb vezerlo aramkort, vagy jelezhetnek hibas szektort is (aminek a kezelese a mai filerendszerek eseten a teljesitmeny szempontjabol eleg bizonytalan kimenetu lenne).
Ha nem akarunk ilyet latni, akkor filerendszer blokkmeret = valos szektormeret. A valos szektormeretet pedig a memoria chipek es a vezerlo aramkor adatlapjarol lehet megtudni. Ebben a konfiguracioban sokkal tovabb birja egy SSD lassulas nelkul. Bar van par olyan eset, amikor a sok kis egymas melle (egy szektorba) pakolt file jol is johet (pl. ha egyszerre kell felolvasni oket, mint pl. rendszerinditaskor), csak ha igy taroltuk az adatokat, akkor ne nagyon modositgassuk oket. A tiszta megoldas a szektormeret csokkentese lenne, vagy legalabb a valos meret megadasa a disk info adatok kozott, hogy az os megfeleloen tudjon reagalni. -
TH448 #16 Mintha erős csúsztatások lennének ebben a cikkben...
Nincs olyan fájlrendszer, ami kiküszöböli a töredezettséget. Gondolom, itt az ext3 járhatott a cikkíró fejében. Az NTFS is pl. 20% szabad hely fölött elhanyagolható töredezést termel.
Meg mi az, hogy archiválja ezt az állapotot? Nem írhatok rá, vagy mi? Akkor meg végképp nem értem, mi ebben a probléma, ha telepítek oprendszert, először az telerakja kis fájlokkal, ok, ekkor lassulhat, de aztán ne töredezettségmentesíts, ennyi. Vagy időnként rakd újra az oprendszert... -
szombi #15 Emiatt érdemes volna ha továbbra egy blokk az SSD-ben "szektor" is lenne.
Még a mai, nagy merevlemezeknél is ez a méret 512 byte.
Az operációs rendszer(akár windóz, akár linux) nem képes a szektorméretnél kisebb egység megcímzésére.
Ha hozzáfűzöl a fájlhoz, az egész érintett blokk újraírásra kerül. Évtizedek óta így van!
Szerintem jó ötlet, hogy az SSD vezérlője nem azt a fizikai területet használja,
amit az oprendszer ténylegesen megcímez, hanem címfordít és egyenletesen terheli a blokkokat.
Azonban ez nem mai találmány. Már a 30 megás vinyók esetében is címfordítás történt a vinyó-vezérlőben,
mert a külső cylinder-ekben jóval több szektor kapott helyet, mint a belsőkben.
Az oprendszer pedig mind a mai napig a CHS-LBA címzést használja, holott már rég nem fizikai helyet címez meg.
Ráadásul a mai, "pörgettyűs" merevlemezeknél párszáz sávonként helyet kap egy-két tartalék sáv.
Normális S.M.A.R.T. esetén a keletkező badsectorok kivonódnak a forgalomból, helyüket a tartalék veszi át.
Már csak azt nem értem, hogy hogy a lótúróba képes különböző kisméretű fájlokat egy blokkba rakni az SSD vezérlő?????
Az SSD egyetlen dolga a tárolás, hogy láthatja azt, melyik fájl mit takar??????? -
dez #14 De, a technológia hibája is!
Tudni kell, hogy a flash-memória valójában az EEPROM-ok egy fajtája. A fő különbség az adat-szervezésben van. Az EEPROM-ok akár byte-onként is törölhetők és újraírhatók, de mivel ez lassú folyamat, a flash-t a nagyobb sebesség érdekében máshogy szervezték: blokkok vannak, melyek egy művelettel törölhetők, és az írás sem byte alapú, hanem egy egész sorozat írható egyszerre (chipen belüli pufferből).
Ugyanez vissza is tud ütni, ti. a külön törlésre azért van szükség, mert nem kapcsolgathatók a bitek csak úgy ide-ida, mint egy ramnál! Ez csak az egyik irányban tehető meg egy adott byte/szó tetszőleges bitjeire. Ha épp az ellenkező irányba kellene billenteni, akkor bizony először egy törlést kell eszközölni. Sima EEPROM esetén csak az adott byte, flash esetén egy egész blokk törlésre kerül ilyenkor (nem lehet kisebbet)! Ezután az eredeti adatban elvégezni a változtatást, majd az egészet visszaírni... (Ha nincs máshol üres blokk.) Remélem, érthető.
Tehát, a sorrend, a legjobb esettől a legrosszabbig:
1. Üres (előzőleg törölt, inicializált) blokkokba kell írni.
2. Nem üresek, de érvénytelen az eredeti adat. (Törölni kell a blokkokat, de aztán csak a céladatot beírni.)
3. Nem üres blokkokba, érványes adatok mellé kell beékelni az új adatot... (Eredeti adatot átírni máshová, törölni, majd beírni az új adatot, adott esetben az eredetivel együtt.)
Mindhárom lehetőségnek van két további al-esete: nagy file-ok vs. kis file-ok. Utóbbiakkal dolgozni a legrosszabb. Szóval, ha sok kis file-lal dolgozunk, írjuk és törölgetjük (érvénytelenítjük) őket, akkor hamar elfogynak az érintetlen blokkok, és jöhet a nagy adat-kavarás...
Persze ezt az egészet lehet a lehetőségekhez képest okosabban kezelni, vagy éppen még tovább rontani a helyzeten. -
gettoharcos2 #13 összességében pedig , hát hogyismondjam, khmm.. a winyó egy ósdi gőzgép egy SSD-hez képest ... az SSD-k kevesebett fogyasztanak és sokkal inkább bírják a rázkódást/ütést, notebookokban sokkal masszívabbak. -
gettoharcos2 #12 "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"
azért az a 25 mega/sec sem olyan rossz, ráadásul egy SSD-nél nincsen a random seek-eknél pozicionálási idő , ami sok kis fájl megkeresése esetén winyónál mindig lényeges késedelmet jelent egy SSD-hez képest még és így összességében egy 50 Mb/sec-es winyó közelíti meg a 25 Mb/sec-es SSD-t... -
OscarX #11 mindennapi használatban teljesen bevált linux alatt. kellően gyors, zajtalan. tesztek egyáltalán nem érdekelnek. ha valami nem klappol úgyis érzi menetközben az ember. -
barii #10 amúgy aki használ SSD-t linuxon, érdekelnének a tapasztalatok. nem teszt, csak feeling -
barii #9 nos ez nem a technológia hibája, hanem a fájlrendszeré. az meg ugyebár az operációs rendszeré. de hogy ne csak fröcsögjek, hozzá tenném, hogy az NTFS-t nem tartom rossz fájlrendszernek, még sosem veszett el róla adatom fájlrendszer hibájából, de ezek szerint SSD-re nem jó. éppen ezért talán nem ártott volna mégiscsak kifejleszteni azt az új fájlrendszert, amit már a Vistába beígértek. Tegyük fel, hogy a win7 megél akkora kort, mint az XP. Szerény véleményem szerint (ami amúgy nem mérvadó:D) akkoriban már az átlag felhasználó is simán használna SSD-t, hacsak ez meg nem gátolna. Azt eg nem hinném, hogy hiphopp, egy Service packba bele varázsolnák :D
minden esetre azért ez kicsit ciki -
JTBM #8 Ezen az OS tud maj segíteni. Az OS-nek fel kellene ismernie az SSD-t és csak egyszer szabadna írnia a legtöbb esetben.
Olyan file, ami gyakran változik, pl. log, beállítás, stb., a HDD-re kellene hogy menjen.
Szóval a megoldás az OS kezében van és per pillanat az OS nincs felkészülve az SSD kezelésére.
Ha meg lesz majd oldva az SSD megfelelő kezelése, akkor tényleg nagyot lök majd a PC-k teljesítményén. -
barii #7 ext4... ennyi:D -
hodobaj #6 Egyszere a 2 megoldás lenne a legjobb az oprendszer amit jobb esetben 1,5 évente újra telepítünk vagy még ritkábban az mehetne SSD-re a gyorsabb olvasás miatt a többi cucc meg a HDD-re. -
Alvarez999 #5 Meg azt is, hogy pl. az XP a bootolási idő jelentős részét azzal tölti, hogy vár a mindeféle eszközökre. Pedig vannak már olyan megoldások, hogy a kevésbé fontos eszközöket később inicializálja, ezáltal hamarabb végez a boottal. De az sem rossz megoldás, hogy kikapcsoláskor újraindít és hibernál, ezzel is komolyan gyorsítja a bootot. -
Viszpi #4 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. Most ha ténylegesen 3-ára is csökken hosszútávon az SSD tempója (amit kétlek, ha van lassulás akkor is szoftveresen vagy hardveresen fognak javítani rajta hogy ne legyen annyira drasztikus) de még 3-ad akkora tempóval is érezhetően gyorsabb marad. SSD-t nem nagy háttértárnak vesznek az emberek. Arra ott van két SATA II-es vinyó raidben, ami szekvenciális olvasásnál olyan átlag 80-120 MB/secet tud, az meg elég... -
Alvarez999 #3 Szarból nem lehet várat csinálni, az alapvető baj a flash NAND technológiával van. 10,000 ciklus az MLC és kb. 100,000 ciklus az SLC chipeknél nagyon kevés. Az Intel által is alkalmazott (és továbbfejlesztett) wear levellingre nem lenne szükség, ha a memóriacellák nem használódnának el olyan kevés ciklus után. -
#2
Egyszóval: szívás.
Többel: látszik, hogy még nagyon gyerekcipőben jár ez a technológia (is).
-
Szefmester #1 ha valaki csinált ilyen tesztet akkor lehet mégis előfordulnak.. másrészt ahogy a teszteket nézem, többnyire tömörítés, konvertálás, másolás nagy- és kisméretű filokkal.. szal tényleg nem használ ilyet a felhasználó :D