[special]

@BoGyesz: szerintem jellemzõbb a standby, de nincs statisztikám. leslie arra utalt, hogy a hibernálás a memória mennyiségétõl és kihasználtságától függõen akár 4 GB írást is jelenthet az SSD számára, ami fogyasztja az írási ciklusok számát, vagyis fárasztja a NAND chipek celláit. ez tény, de egy jóféle ssd-nél szerintem ez nem okothat gondot, hacsak nem tényleg sok memória van a gépben és naponta sokszor hibernáljuk, mondjuk tízszer.

a gyártók által használt ökölszabály egyébként az, hogy 5 éven keresztül napi 20 GB írást kell kibírnia egy PC SSD-nek.

[leslie]

Idézet: BoGyesz - Dátum: 2010. 03. 18. 10:13

Leirnad, hogy miert nem ildomos? A notikat altalaban hibernalni szoktak es akkor az ssd-vel szerelt tipusoknak problemaja lehet? Nem kotozkodni akarok csak nem hallottam meg ezt.

Elfáradnak a cellák, hamarabb.

[Sparow2]

Idézet: special - Dátum: 2010. 03. 18. 10:20

@BoGyesz: szerintem jellemzõbb a standby, de nincs statisztikám. leslie arra utalt, hogy a hibernálás a memória mennyiségétõl és kihasználtságától függõen akár 4 GB írást is jelenthet az SSD számára, ami fogyasztja az írási ciklusok számát, vagyis fárasztja a NAND chipek celláit. ez tény, de egy jóféle ssd-nél szerintem ez nem okothat gondot, hacsak nem tényleg sok memória van a gépben és naponta sokszor hibernáljuk, mondjuk tízszer.

a gyártók által használt ökölszabály egyébként az, hogy 5 éven keresztül napi 20 GB írást kell kibírnia egy PC SSD-nek.

Azaz 35 TB írást kell bírnia.

[BoGyesz]

Utána olvastam a témának és szűkítettem a keresést az elmúlt egy évre, mivel folyamatosan fejlődnek az SSD-k. Azt kell, hogy mondjam, hogy nem kell félni még napi töbszöri hibernálás esetén sem, hogy hamar elhasználódik a meghajtó.

A Toshiba termékleírása szerint az átlag felhasználók 1.4-5.2GB/nap adatot használnak, ez kibővítve hibernálással és folyamatos autosave-el 2.4-9.2GB/nap. Egy Toshiba 128GB-os MLC SSD öt éves író kapacitása 80 Terabyte, ami kb. 45GB/nap adagra jönne ki. Olyan környezetben, ahol sokkal nagyobb kapacitásra van szükség, oda az SLC SSD meghajtókat ajánlják, amik 128GB tárhely mellett napi 500GB-ot, 256GB és 500GB tárhely mellett pedig 1 és 2TB napi használatot bírnának öt év alatt.
forrás

Ez pedig egy érdekes MSDN blog írás arról, hogy Windows 7 miként támogatja és kíméli az SSD meghajtókat: blog

[avman]

Idézet: BoGyesz - Dátum: 2010. 03. 18. 13:46

Utána olvastam a témának és szűkítettem a keresést az elmúlt egy évre, mivel folyamatosan fejlődnek az SSD-k. Azt kell, hogy mondjam, hogy nem kell félni még napi töbszöri hibernálás esetén sem, hogy hamar elhasználódik a meghajtó.

A Toshiba termékleírása szerint az átlag felhasználók 1.4-5.2GB/nap adatot használnak, ez kibővítve hibernálással és folyamatos autosave-el 2.4-9.2GB/nap. Egy Toshiba 128GB-os MLC SSD öt éves író kapacitása 80 Terabyte, ami kb. 45GB/nap adagra jönne ki. Olyan környezetben, ahol sokkal nagyobb kapacitásra van szükség, oda az SLC SSD meghajtókat ajánlják, amik 128GB tárhely mellett napi 500GB-ot, 256GB és 500GB tárhely mellett pedig 1 és 2TB napi használatot bírnának öt év alatt.
forrás

Ez pedig egy érdekes MSDN blog írás arról, hogy Windows 7 miként támogatja és kíméli az SSD meghajtókat: blog

nekem ezzel a napi ennyi gb írással a tárolókapacitás függvényében csak egy gond van, éppenséggel egy 30-40 gigás ssd-n szabad hely szerintem 10 giga vagy alatta. máris lehet elosztani az elvi gyári adatot kapásból monnyuk néggyel, mert annyival kevesebb szabad cella van, amit folyamatosan újraírhat... vagy folyamatosan pakolgatja ide-oda a már meglévő adatokat az oprencer? ezt kizártnak tartom. de lehet van erre valami program, hasonló mint a defrag. a kevesebbet használt cellákat felszabadítja, a sokat használtakra meg ritkán változó adatot pakol. ennek lenne értelme. hm, utána is nézek.

[EV6]

Idézet: avman - Dátum: 2010. 03. 18. 14:40

nekem ezzel a napi ennyi gb írással a tárolókapacitás függvényében csak egy gond van, éppenséggel egy 30-40 gigás ssd-n szabad hely szerintem 10 giga vagy alatta. máris lehet elosztani az elvi gyári adatot kapásból monnyuk néggyel, mert annyival kevesebb szabad cella van, amit folyamatosan újraírhat... vagy folyamatosan pakolgatja ide-oda a már meglévő adatokat az oprencer? ezt kizártnak tartom. de lehet van erre valami program, hasonló mint a defrag. a kevesebbet használt cellákat felszabadítja, a sokat használtakra meg ritkán változó adatot pakol. ennek lenne értelme. hm, utána is nézek.

Nem kell ehhez program, ezt a műveletet az SSD saját wearleveling logikája csinálja ELVILEG, és olyan helyekre pakol ELVILEG, amit nem is látsz, mert redundancia, nem a tényleges kapacitás része.

[leslie]

Idézet: EV6 - Dátum: 2010. 03. 18. 14:53

Nem kell ehhez program, ezt a műveletet az SSD saját wearleveling logikája csinálja ELVILEG, és olyan helyekre pakol ELVILEG, amit nem is látsz, mert redundancia, nem a tényleges kapacitás része.

A kollega felvetése jogos, nyilván a belső vezérlés csak a szabad helyen tud gazdálkodni. Ez van, nyilván így már más a leányzó festése. Nagyobbat kell venni...

[special]

@leslie: "A kollega felvetése jogos, nyilván a belsõ vezérlés csak a szabad helyen tud gazdálkodni. "

ez egyáltalán nem szükségszerû. karbantartó üzemmódban miért ne tudná átpakolni a többnyire olvasott fájlokat a fáradtabb blokkokba? hogy mi a mai valóság, más kérdés, ennek tényleg utána kellene menni...

[avman]

egyelőre a diskeeper-t nézegetem, mint defrag. progit, mert van valami hiperfaszt funkció direkt ssd-hez, meg egy csomó más. állítólag növeli a teljesítményt, én ezt monnyuk nem tapasztaltam. igazából intelliwrite iaac ibizgentyű okosságok meg a hozzátartozó marketingbullshit az van dögivel, konkrétumot nem találok...
bár nem ide tartozik, de ez az infó meg jól is jött, mert mellékesen annyit sikerült kiderítenem, h a bitlocker encrypt után a trim-el együttműködik. ellenben a truecrypt és a többi meg ugye magától nem (gyk. mountol, nem látni miatta üres részt, illetve amit töröl az ember, felül is írja rögtön. ezt már egyszer kiderítettem, h gyk. értelmetlenné válik miatta a trim.

Szerkesztette: avman 2010. 03. 18. 17:37 -kor

[avman]

Idézet: EV6 - Dátum: 2010. 03. 18. 14:53

Nem kell ehhez program, ezt a műveletet az SSD saját wearleveling logikája csinálja ELVILEG, és olyan helyekre pakol ELVILEG, amit nem is látsz, mert redundancia, nem a tényleges kapacitás része.

najó, de szerintem csak a veszélyes elhasználódás után helyez át adatokat magától. engem az érdekel, h van-e olyan defrag jellegű progi, ami vizsgálja, h mely cellák hányszor voltak felülírva, és a szerint osztja el bizonyos időközönként az adatot úgy, h azért nagyjából egyenletes terhelést kapjanak a cellák. ugye az sem jó, ha gyakran fut, mert az maga felülírás, de ha évekig ugyanazt azt a 10-20% szabad helyet használja, akkor szerintem valahol meg kellene előzni ezt az egészet még az előtt, h a wear leveling eléri a kritikus szintet. illetve, ugye valahogy akkor már úgy kellene elosztani, h az esetlegesen sokszor felülírt helyekre egy idő után ritkán változó adatállomány kerüljön.

Szerkesztette: avman 2010. 03. 18. 17:47 -kor

[special]

@avman: "engem az érdekel, h van-e olyan defrag jellegû progi, ami vizsgálja, h mely cellák hányszor voltak felülírva, és a szerint osztja el bizonyos idõközönként az adatot úgy, h azért nagyjából egyenletes terhelést kapjanak a cellák."

van ilyen progi, az EV6 által is említett SSD firmware. csak neki van információja a NAND chipek blokkjainak állapotáról, így csak õ tud bevatkozni. egyébként folyamatosan figyeli a terheltséget, és annak függvényében választhatja ki, hogy melyik szabad blokkba ír. a másik kérdés, hogy a nem igen használt, de foglalt blokkokból áthelyezi-e a fáradtabbakba az adatokat magától. szerintem ez egy ésszerû feltételezés, de a megerõsítéshez fel kell hajtani valami mérnököt. megpróbálom.

[leslie]

Idézet: special - Dátum: 2010. 03. 18. 15:48

ez egyáltalán nem szükségszerû. karbantartó üzemmódban miért ne tudná átpakolni a többnyire olvasott fájlokat a fáradtabb blokkokba? hogy mi a mai valóság, más kérdés, ennek tényleg utána kellene menni...

Erre max egy gyártó tudna válaszolni. De nem hinném, hogy kikotyognák, mi a szitu.

[zed01]

Nekem a W7 foglal egymagában a programokkal együtt vagy 40 GB-ot, akkor a Linuxnak sem ártana hely. Egy 120 GB-os SSD-vel már ellennék, úgy hogy a flacokat, mkv-kat, avi.kat, játékokat, biztonsági mentéseket, stb-ket a merevlemezen hagynám.

De a 40 GB-os SSD nagyon karcsú.

[didyman]

Idézet: zed01 - Dátum: 2010. 03. 22. 00:33

Nekem a W7 foglal egymagában a programokkal együtt vagy 40 GB-ot, akkor a Linuxnak sem ártana hely. Egy 120 GB-os SSD-vel már ellennék, úgy hogy a flacokat, mkv-kat, avi.kat, játékokat, biztonsági mentéseket, stb-ket a merevlemezen hagynám.

De a 40 GB-os SSD nagyon karcsú.

Lehet azért sokat karcsúsítani a W7-en is, de azért érdekes, mi foglal 40GB-ot. Játékok?

[didyman]

Idézet: avman - Dátum: 2010. 03. 18. 17:44

Möhö

A wear leveling egy SSD-n mindenféle szoftveres rétegen felülálló történet, a hardver közvetlen magánügye. SSD-nél gyakorlatilag nem tudod fizikailag lekövetni (merevlemeznél sem igazán, pl. egy SMART által tett áthelyezést követően a logikai cím marad ugyanaz, de az adott szektor már nem "a helyén", hanem a tartalék területen lakik, na így tudom neked megfogni a lényegét ), hogy pontosan melyik cellába kerülhet a 45213. szektor, azt az elektronika intézi maga. Ahogy merevlemezeknél, úgy itt is van egy "logikai" cím (miért ne hívjuk LBA-nak), amit az oprendszer például lát, és van egy fizikai cím, amit az SSD maga kezel, zártkörűen. A kettő között egy elég bonyolult, de logikus összeköttetés van, többféle, egymásra épülő hozzárendelési tábla, amit az SSD egy erre fenntartott helyen tárol és itt történik az elhasználódás függvényében a fizikai címek átírása. Ha érdekel, kifejtem bővebben, de pár részletnek még utána kéne nézzek azt hiszem.
Ebből a megoldásból következik, hogy a wear leveling algoritmus a telítettségtől teljesen függetlenül képes tenni a dolgát, a fájlrendszer konzisztenciáját nem fogja érinteni a működése, ha már meglévő adatot helyez át. Apropó, a wear leveling nem csak a kritikusan sokat írt területeken avatkozik be, hanem folyamatosan tart karban és igyekszik az írási ciklusokat azonos átlagos szinten tartani. Ezek miatt a klf. szoftveres buherák, bár nagyon hangzatosak, sokat nem érnek, de talán még ronthatnak is a helyzeten, szükségtelen írási ciklusok beiktatásával. Mivel a wear leveling abszolút pontos működése titok és gyártónként esetleg nagyban eltérhet, ezért nem hiszem, hogy jó ötlet ezt egy erről semmit sem tudó szoftverrel befolyásolni próbálni.

Szerkesztette: didyman 2010. 03. 22. 08:27 -kor

[bogdan]

IdézésEbbõl a megoldásból következik, hogy a wear leveling algoritmus a telítettségtõl teljesen függetlenül képes tenni a dolgátbocs, de ebbol ilyen nem kovetkezik! max a lehetosege, hogy az ssd a hatterben folyamatosan pakolgasson. de valoban pakolgat, vagy csak igy hisszuk?

[bogdan]

ez a quote milyen ganyul nez mar itt ki? hm..

[didyman]

Idézet: bogdan - Dátum: 2010. 03. 22. 08:53

IdézésEbbõl a megoldásból következik, hogy a wear leveling algoritmus a telítettségtõl teljesen függetlenül képes tenni a dolgátbocs, de ebbol ilyen nem kovetkezik! max a lehetosege, hogy az ssd a hatterben folyamatosan pakolgasson. de valoban pakolgat, vagy csak igy hisszuk?

Szerinted vajon mennyire valószínű, hogy nem pakolgat, ha a lehetősége csuklóból adott és a megoldás eleve a fájlrendszer szintje felett áll?

[didyman]

Idézet: bogdan - Dátum: 2010. 03. 22. 08:54

ez a quote milyen ganyul nez mar itt ki? hm..

Nálam meg nem. Szerintem a motorba épített, vagy AI által létrejött bogdan-extension lehet a tettes https://forum.hwsw.h...tyle_emoticons/default/tongue_2.gif

[bogdan]

szerintem nem valoszinu, hogy sokat pakolgat.

de most tippelest jatszunk, vagy valami bizonyosat tudunk? raadasul mi koze ahhoz, hogy kovetkezik-e valami logikailag, vagy sem.