Diit.cz - Novinky a informace o hardware, software a internetu

Diskuse k Náš vlastní SSD Benchmark: představujeme první nástřel

No asi neplanujete vyzkouset, jak presne probiha to ukoncovani zivotnosti z duvodu opotrebenei bunek co? Chapu, ze byste to museli zaplatit a zadny vyrobce Vam na to SSD nepujci, ale mozna by slo udelat sbirku. Jde o to, ze vsude se o tom jen teoretizuje, ale prakticke udaje snad nikdo nema.

+1
-1
-1
Je komentář přínosný?

Plne souhlasim. Sice nejakou predstavu ma asi kazdy, ale marketingove informace vyrobcu se s realitou moc stotoznovat nedaji. Test, ktery by ukazal, jak skutecne umira SSD (vcetne vlivu na system a hlavne jaky je rozdil mezi udavanou a realnou zivotnosti), by byl k nezaplaceni. A myslim, ze s trochou vyjednavani, by treba takovy Intel mohl byt ochotny poskytnout nejake mensi SSDcko na odvareni. Ostatne pokud by nezaujaty zpravodajsky server zjistil a publikoval informaci o tom, ze realna zivotnost jejich SSD je o XY prepisu delsi nez uvadaji, byla by to pro ne reklama k nezaplaceni. A je by to stalo jen vyrobni naklady jednoho SSD (pro kazdou firmu, a tuplem Intel, zanedbatelna castka za reklamu).

+1
+1
-1
Je komentář přínosný?

levné "výprodejové" 32GB SSD stojí okolo litru.

+1
0
-1
Je komentář přínosný?

Zajímavější je to určitě u těch dražších disků, ale 32GB verze může posloužit stejně dobře, jako 120GB (n* větší počet buněk -> n* větší životnost), a i třeba Crucial M4 přijde na 1800, což není taková pálka, a určitě je to reprezentativní kousek pro test "nejrychlejších" SSD, a jejich overtime degradaci.

+1
0
-1
Je komentář přínosný?

Ale to vite, ze nejake ty udaje jsou k dispozici:
http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endu...
Doporucuji k prostudovani vsem zajemcum o SSD.

+1
0
-1
Je komentář přínosný?

Myslím, že je to skvělý počin, nejlepší by bylo, kdybyste takový test vyvinuli a již ho neupravovali, takže všechny disky by byly testovány stejnou metodikou. Databáze disků a chování při testech by byla, myslím, velmi užitečná..

+1
-1
-1
Je komentář přínosný?

Nebo nějaká možnost přepisovat třeba pořád jen 40GB (dejme tomu opakovaná přeinstalace OS), jak se s tím SSD popere.

+1
0
-1
Je komentář přínosný?

s tím se právě popere, pomocí wear levelingu - rozloží interně zátěž na všechny buňky.

+1
0
-1
Je komentář přínosný?

Ještě poznámka: daleko spíše by mě zajímalo, jak se FW disku popere se stavem, který se IMHO vyskytuje nejčastěji: disk skoro plný statických dat a se zbytkem se "usilovně" pracuje. To je totiž dle mých zkušeností nejčastější reálný model použití SSD.

+1
-2
-1
Je komentář přínosný?

Do finalnich grafu bych doplnil svisle cary ukazujici kapacitu prepisovane casti (overflow), at je jasne ktera iterace prave probiha. A mozna udelal trocha hezci grafy - ukazujici hlavne prumer (vyhlazenou krivku), ale i minima/maxima. Nahled poslu redakci mejlem :)

+1
0
-1
Je komentář přínosný?

Lze snadno spočíst: počet zapsaných dat lomeno kapacita disku, horní celá část :P Ale jo, ty čáry by tam klidně mohly být.

Ten rozptyl je určitě zajímavý, protože se s dalšími iteracemi pravděpodobně bude zvyšovat.. Spíš je zajímavější, co daný rozpty způsobuje, jaká režie se v disku děje v který čas, a proč je to tak rovnoměrné.

+1
-1
-1
Je komentář přínosný?

Respektive zvýšení rozptylu poukáže na neefektivnost algoritmu pro výběr oběti.. Při optimálním algoritmu by měl rozptyl být stejný (stejný v poměru ku objemu zapsaných dat).

+1
-1
-1
Je komentář přínosný?

K testu: jak přesně funguje? Viditelný propad je při kompletním zaplnění disku, ale následně je propad stále konstantní.
Tzn. jak dochází k vynucení přepisu? Ten propad totiž vypadá asi jako zdržení: "hele, šéfe, já už jsem plnej, už mi to necpi" "ale prosimtě, klidně něco přepiš, to je jedno" "tak jó"
Pokud tato režie je rovnou přeskočena zápisem typu "piš kam se ti to nejvíc hodí, co tam je mě nezajímá", pak daný propad může být třeba algoritmus LRU nebo wear-leveling, který rozhoduje, kam se to teda zapíše, co je nejlepší přepsat..
To ovšem neukazuje na opotřebení disku, které se začne projevovat až časem na té propadlé křivce. Otázkou je míra zkreslení vnitřní režií disku.

Tehle údaj je podstatný, protože je rozdíl u každého soubou přemýšlet, kam teda s ním, než přeipisovat konkrétní soubory (typicky běh aplikací a systému pracuje s většinou "pro čtení" soubory, a pak nějakými dočasnými soubory, cachování, stránkování, externí sort-merge, .. , cfg soubory, ..) a jen se u nich ptát, jestli prostor, ve kterém jsou, už není moc opotřebený - to musí být rychlejší, než hledat, který prostor na celém disku je nejméně opotřebený. V takovém případě je samozřejmě propad výkonu, propad IOPS daleko menší na stejně opotřebeném disku.

Tzn. ještě jednou: jaký typ režie způsobuje daný propad IOPS po kompletním zaplnění disku? :)

+1
-2
-1
Je komentář přínosný?

V tomhle případě je zrovna propad konstatní, v jiném případě být nemusí a může se to chovat jinak.
K vynucení přepisu dochází ultraprimitivně. Prostě to ten testovací soubor, který to vyrobí, začne přepisovat znovu od začátku, aniž by ho smazal. Nic jako "už jsem plnej" od SSD nedostává (on ho ve skutečnosti nezaplní celý, trochu volného místa nechá, několik (desítek) MB).

Re: "Otázkou je míra zkreslení vnitřní režií disku." - přesně o to v tom testu jde. Dokud je volné místo, zapisuje se, kam je volno. Jakmile dojde, musí začít disk dělat i něco navíc. A o to se právě SSD zpomalí. Mám na tomhle konkrétním SSD vyzkoušeno, že i když se ten testovací soubor smaže a SSD nechá chvilku odpočinout, další takový test začne znovu na nízkých hodnotách (už tam není ta první část, kdy je výkon ještě vysoký).

+1
-1
-1
Je komentář přínosný?

To je dost zvláštní! Znamená to tedy, že dokud má disk volné bloky, tak nepřemýšlí (LRU spí) a jakmile na všech blocích vyroste příznak "used", navždy už pojede algoritmus přemýšlení..

Já teda do těch algoritmů nevidím, ale kdyby to bylo takhle, pak by stačilo jednou za čas projít všechny příznaky (pokud jsou tedy číselné "used n-times"), a všechny je dekrementovat o nejnižší n. pak by mohl zase spát, dokud by mu všechny nuly nezmizely (v tu chvíli by to zase dekrementoval), a snažil by se samozřejmě pracovat tak, aby mu n skákalo mezi 1 a 0 (všechny zapíše na 1 a po zaplnění dekrementuje na 0), což by se projevilo krátkým hlubokým propadem výkonu jednou za kapacitu (teoreticky by to bez propadu mohl dělat ve chvíli, kdy je nevyužit), a ve zbytku času být na maximální rychlosti, postupně se snižující celkovým opotřebením buněk..
Takhle to ale rozhodně nedělá, pokud prostě jednou zapíše a pak nazdar.

Jak to teda dělá? Vidíte do těch algoritmů, když ve Vašem případě je první bod splněn dokonale? :P

+1
+1
-1
Je komentář přínosný?

Do toho, co dělá SSD vnitřně, samozřejmě nevidím. Znáš někoho (nebo nějaký soft), který do toho vidí? Jediné, co vím, je, že se nechá přes SMART zjistit, kolik proteklo SSDčkem dat směrem ven a dovnitř (čtení/zápis). Žiju v domnění, že vnitřní logika je taková, že nikdy nevíš, kam se fyzicky jaká data zapíší, když řeknu třeba "zapiš to na LBA 15456". Jednou to může být tuhle, jindy támhle.

+1
0
-1
Je komentář přínosný?

Bohužel neznám. Otázka nebyla narážka ;) Právě problém je v tom, že se tady pokoušíme (pokoušíte) reverzním inženýrstvím zjistit, jak to vlastně pracuje, a jak tedy aplikace optimalizovat..

Je ale zvláštní, že ten propad je tak vysoký, a tak konstantní.. Asi bych vážně přinejmenším jedno SSDčko zničil (a klidně poskytnu na tento pokus 32 GB Samsung, jenž se ukrýval v mém Lenovu Y580, a jenž jsem si nechával pouze pro možnost ozkoušet Win8, ovšem o tom SSD a jeho specifikacích a kvalitě nemám ponětí). Sranda by byla zničit 3 naprosto stejná SSD a dostat diametrálně odlišné výsledky.. Plus rozdíl mezi růzými SSD stejné, a pak ještě různé technologie, a od každého alespoň 3 kusy (trojnásobná redundance jako za dob prvních počítačů).. To aby někdo z redakce prodal ojetou oktávku.. :D

+1
0
-1
Je komentář přínosný?

Pozn: je to mSata SSD. Ovlivní to test nějakým způsobem?

+1
+1
-1
Je komentář přínosný?

Jen tím, že to nemám kam připojit ;) Desku s mSATA konektorem zrovna nemám.

+1
-1
-1
Je komentář přínosný?

Ani notebook? Bohužel ten svůj potřebuju permanentně aktivní (a OS mám na SSD, nikoliv HDD), jinak bych to prubnul v něm.. Ale ta možnost by tu byla, pokud by test mohl běžet s přestávkami, aniž by jej to ovlivnilo..

+1
-1
-1
Je komentář přínosný?

Ja mam tady DN2800MT (v linuxu ani win64 me tam nejede ta posahana powervr grafika)... tak bych to mohl zapujcit nebo nechat bezet ten vas test..

+1
+1
-1
Je komentář přínosný?

Ten propad může být způsoben tím, že je disk plný (téměř plný). Obsah buňky nelze jen tak přepsat - nejdřív se musí buňka vymazat, a poté zapsat nová data. velikost buňky může být 16KB až 512KB...a kdo ví dneska možná i větší.

Jinak řečeno jestli chci přepsat 1B v souboru, pak se klidně může stát, že se načte do paměti (v SSD) 512KB, vymaže se buňka, a pak se zapíše nový obsah 512KB.....to celé kvůli 1B.

Tohle samozřejmě ovlivňují různé optimalizace na úrovni HW (v SSD).

+1
-1
-1
Je komentář přínosný?

"Mám na tomhle konkrétním SSD vyzkoušeno, že i když se ten testovací soubor smaže a SSD nechá chvilku odpočinout, další takový test začne znovu na nízkých hodnotách"
-WIFT-
Je fakt, že vymazání souboru != inicializace disku....

+1
-1
-1
Je komentář přínosný?

Samozřejmě by to neplatilo v případě, že se nic nepřepisuje, tzn. tam musí zase vyhodnocovat něco jako "LEAST recently used", který přesune na buňky v nejhorším stavu, a odemkne si tak nové buňky v dobrém stavu. Vyhodnocení tohoto a přesun dat jinam opět tento test netestuje, přičemž to se prakticky asi děje v konci životnosti disku nejvíce - statická data už rok sedí na buňce, kam bylo zapsáno jednou, a tempy mezitím vyžraly celý zbytek disku k horní hranici opotřebení.

Koukám, to testování SSD je opravdu komplexní NP-úplný problém :D

+1
-1
-1
Je komentář přínosný?

Gratulujem - podarilo sa vam znova vynajst koleso.
To co ste naprogramovali vie Iometer uz od roku 2001.

+1
0
-1
Je komentář přínosný?

Zkus mi prosím popsat, jak v IOMeteru dojdu k témuž výsledku.

+1
0
-1
Je komentář přínosný?

To je tak, když si někdo ani nepřečte, co se v článku píše...a nebo přečte, ale nepochopí, a pak se k tomu ještě vyjadřuje, což je ta horší varianta...

+1
0
-1
Je komentář přínosný?

Z merani v Iometer sa da spravit priebeh poctu IOPS / MB / MiB od casu, takze vysledok bude rovnaka krivka ako vo vasom pripade s jedinym rozdielom - na x-ovej osi nebude mnozstvo zapisanych dat ale cas.

+1
0
-1
Je komentář přínosný?

Prostudujte si nedávné recenze SSD na anandtechu a pokud vám to z toho nebude jasné, tak se zeptejte těch do psali ty recenze :-)

+1
+2
-1
Je komentář přínosný?

To generate the data below I took a freshly secure erased SSD and filled it with sequential data. This ensures that all user accessible LBAs have data associated with them. Next I kicked off a 4KB random write workload across all LBAs at a queue depth of 32 using incompressible data. I ran the test for just over half an hour, no where near what we run our steady state tests for but enough to give me a good look at drive behavior once all spare area filled up.

I recorded instantaneous IOPS every second for the duration of the test. I then plotted IOPS vs. time and generated the scatter plots below - by Anand Lal Shimpi.

Takze prestudujte si nedavne recenzie na anandtechu vy!

+1
0
-1
Je komentář přínosný?

Škoda, pokus mi nevyšel, budu na to holt muset přijít sám ;). Princip je jasný, dělá to totéž, co dělám já. Já jen tak zkoušel, jestli z tebe třeba nevypadne návod, jak co v tom IOMeteru nastavit a tak, no nic, za pokus mi to ale stálo :).

+1
-1
-1
Je komentář přínosný?

Ahoj WIFT, s navodom samozrejme problem nie je.
Da sa to spravit napr. nasledovne: v Access Specifications si vytvoris worker aky potrebujes, v Test Setup nastavis Run Time kolko potrebujes, nastavis si pocet outstanding I/Os per target a hlavne, pocet Assigned Access Specifications das tolko krat, kolko chces mat hodnot. Takze ak Ti staci testovat 15 minut, nastavis si 15 x worker po 1 minute. Z vygenerovaneho .csv-cka vytiahnes potrebne udaje, spravis graf a mas hotovo. Vysledny graf potom vyzera napr. nasledovne:

http://pc.zoznam.sk/plextor-m5-pro-256gb-ocz-vector-pozna-svojho-premozi...

+1
0
-1
Je komentář přínosný?

To je dobrý, už si s tím hraju (protože čas tlačí, vlastní benchmark počká), ale i tak díky :). Nastavil jsem IOMeter tak, jak si myslím, že by to mělo být, aby to dělalo v zásadě totéž, co by měl dělat ten můj test, a zatím mám podezřele nízké hodnoty, takže to budu asi chvilku ladit, než to bude dělat, co chci ;). Uvidím, k čemu se nakonec přikloním (ten vlastní benchmark by měl být takovým zjednodušením toho, co můžu udělat v IOMeteru - pustím a on to udělá). Bohužel ručnímu Secure Erase se stejně nikdy nevyhnu (to nezautomatizuju ;).

+1
0
-1
Je komentář přínosný?

Takže za návod ještě jednou díky. Asi jsem úplnej debil, ale připadá mi, že IOMeter je nějakej nemocnej. Verze 1.1.0 neumí otevřít konfigurační soubor, kterej sama vyrobila. Takže konfiguráky dělám ve starým IOMeteru 2006.07.27 a testuju v 1.1.0 rc1.

Vyrobím tedy specifikaci (50% random acces, 100% write, 16K) , řeknu, že to chci nechat běžet 30 sekund, nasázím tam těch Access specifikací 240 (tj. trápení SSD po dobu dvou hodin, měření po 30sekundových intervalech), nastavím to na jeden Worker, 32 Outstanding IOs (ať to má grády) a pustím na patřičný disk (nezformátovaný, takže jako device, ne písmeno). Nechám běžet dvě hodiny a pak kouknu na výsledek.
Výsledný CSV soubor obsahuje kombajnmilion věcí, takže dostat z toho jen to, co potřebuju (např. hodnoty "MBps (Decimal)") je docela opruz.

Tady už jsem si musel pomoci a spáchal jsem si jednoduchý cmdlinový nástroj, který mi z toho komplexního IOMeterového výsledku vytáhne do dalšího souboru právě jen to, co chci, tedy třeba ty "MBps (Decimal)" hodnoty. Výsledkem je soubor, kde co každý řádek, co jen a pouze hodnota MBps (Decimal) pro daných 30 sekund (takže to má 240 ryze smysluplných řádků, nic víc). S tímhle souborem je pak vyrobení grafu už srandazápas.

Nakonec asi zůstanu u tohoto řešení, protože IOMeter je přeci jen už profesionálně udělaná věc a měří dost přesně, zatímco ten můj benchmark je spíše orientační. 30sekundové intervaly měření jsou docela v pohodě, kdyby ne, není takový problém to upravit. Jediné, co je škoda, je, že z IOMeteru padají výsledky vztažené na čas (víc by se mi líbilo to vztáhnout na množství zapsaných dat, jako to mám já). Ale to už není tak velký problém ;). Až mě to bude hodně trápit, budu v Benchmarku pokračovat, zatím ho ukládám k ledu.

+1
0
-1
Je komentář přínosný?

Zivotnost SSD testuji napr. na tomhle foru. Vitezi tam myslim Samsung 830, zapsali na nej uz pres 6 PiB (23 000x prepsany cely disk).
http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endu...

+1
0
-1
Je komentář přínosný?

Tak mě napadá, že změnou velikosti souboru by se dala zjistit fyzická velikost buňky - podobně jako se zjišťuje velikost jednotlivých cache CPU z latence. Líbila by se mi informace o velikosti buňky aby se nastavila velikost sektoru file systemu na fyzickou velikost buňky. U flash pamětí se používá velikost buňky od 16KB do 512KB a někde jsem četl i o velikosti 2MB. Jen pro připomenutí - aby se vymazal nějaký obsah na disku, je třeba vymazat vždy celou buňku, zapsat už lze menší množství.

Otázka je nakolik ovlivní výsledek použitý file system. Nepřemýšlel jste nad přímým zápisem na disk? Dalším faktorem je cache ssd.

+1
0
-1
Je komentář přínosný?

Pomalu to speje do faze, kdy veskere usili obetovane zjistovani jak to vlastne funguje mohlo byt radeji investovano do navrzeni otevreneho reseni :)

+1
0
-1
Je komentář přínosný?

Vysvětlení toho "schodu" v grafu (zjednodušeně):
Fáze 1 - všechny buňky jsou po příkazu Secure Erase prázdné - data tečou přímo do prázdných buněk, zapisují se jak přicházejí, je to rychlé, dosahuje se nejvyšších hodnot IOPS.

Fáze 2 - buňky byly už zaplněny a následně smazány - smazané buňky zůstávají však fyzicky stále plné, smazání je jen "kosmetické" označením buňky jako "stale" - data do nich nemohou být zapsána přímo, nejprve se musí:
- všechna ještě nesmazaná data z celého bloku buňek přesunout někam úplně jinam
- teprve pak je celý blok skutečně fyzicky smazán
- a až teprve potom jsou nová data zapsána
Toto zdržení s přesouváním (dané tím, že se nemažou/nejde mazat jednotlivé buňky, ale dělá se to jen po celých blocích buněk) způsobuje ten velký pokles IOPS - schod.

+1
0
-1
Je komentář přínosný?

Napadla mě taková blbina a papír, tabule a diskusní fora snesou ledascos, tak to sem napíšu, kdyžtak mě nekamenujte prosím. :) V podstatě SSD funguje uvnitř podobně jako hotel.

Představte si, že máte hotel s X byty, pošlou vám tam zájezd, který se skládá z několika souborů rodin a ty se vám tam zapíší. Ale po pár dnech některé rodiny odjedou, ale vy do jejich bytů nemůžete ubytovat někoho dalšího, protože máte smlouvu s cestovkou a čekáte na další zájezd. Až ten dorazí, tak teprve ty zbylé co tam ještě byli pošlete dojinam, celý hotel uklidíte a ubytujete novou várku. :)

+1
0
-1
Je komentář přínosný?

Já bych trochu tu vaši metaforu trochu zpřesnil, nemáte hotel, ale ubytovnu pro hnědočechy, z toho plyne, že si nemůžete dovolit jen tak někoho poslat pryč, nýbrž tak maximálně je můžete přestěhovat z patra na patro. A každý ubytovaný Vám před vystěhováním pronajatou místnost trochu zdemoluje a vykrade.

+1
0
-1
Je komentář přínosný?

To ani ne... Spíš tak, že můžete ubytovat, kde máte místo, ale jste hloupí, a po odchozím neuklízíte do doby, než do toho pokoje budete potřebovat někoho dát.
A zákazníka, který tam bydlí celý život, za věrnost pošlete do nějakého chátrajícího pokoje (protože bydlet bude dál rád), abyste pár dalších lidí nalákali na ten nový pokoj...

+1
0
-1
Je komentář přínosný?

Sveho casu me zaujal fio - http://git.kernel.dk/?p=fio.git;a=summary na linuxu. Krome toho, ze si muzete psat scenare podle druhu pouziti vaseho diskoveho pole (v prikladech najdete klasicke scenare iometer apod.), tak se mi libila moznost si na produkcnim serveru "nahrat" prubeh zatizeni i/o subsystemu a pak prehrat na novem diskovem poli nebo cemkoliv jinem. Bojim se, ze pokud dnes zacnete na zelene louce, tak bude prilis dlouho trvat nez vase reseni vyroste z detskych plen (read/write pomer, nahodny/sekvencni pristup, delky front, vetsi pocet ruznych workeru, prace primo nad blokovym zarizeni versus nad filesystemem atd.). Mozna by nebylo od veci hodit ocicko na jiz existujici a vytvorit pouze jednoucelovky na veci, ktere neexistuji.
ad enterprise ssd) podeziram vyrobce, ze to delaji tak, ze oznamuji mensi velikost disku nez je skutecna, cimz si v podstate drzi urcity pocet vzdy predsmazanych bloku, Ani po patem kompletnim prepsani se IOPSy meho disku nezmenili (resp. vramci statisticke chyby).
V kazdem pripade se na vysledek vasi prace tesim.

+1
+1
-1
Je komentář přínosný?

Ad enterprise disky: ty jsou hlavně a zásadně typu SLC. A pak se liší (většinou) použitým čipsetem řadiče.

+1
0
-1
Je komentář přínosný?

No to ale vůbec není pravda, např. Intel zásadně pro enterprise SSD používá MLC HET.

+1
0
-1
Je komentář přínosný?

otázka je, co si pod pojmem "enterprise" představuješ..

+1
-1
-1
Je komentář přínosný?

No např. Intel DC S3700, což v současné době je nejlepší enterprise SSD, viz. recenze na anandtechu http://www.anandtech.com/show/6433/intel-ssd-dc-s3700-200gb-review

+1
+1
-1
Je komentář přínosný?

Na Anandtechu bol hlavne iny zaujimavy test odkaz uz bol nizsie v diskusii. Kde dokazali, ze do urcitej hranice rezervnej oblasti velmi rychlo stupa rychlost zapisu. Optimom je asi 25% vyhradenej pre cinnost disku. Toto ma ten Intel uz v zaklade, co mu urcite dost pomaha.

+1
-1
-1
Je komentář přínosný?

SATA disk že je z enterprise segmentu? Odkdy? ;-)

+1
0
-1
Je komentář přínosný?

Typické 120/240 GB SSD, ať už enterprise nebo ne, má v sobě 8+8 nebo 6+10 ("nahoře+dole") flash čipů po 8/16 GB. To dělá 128/256 GB z kterých uživatel vidí jen 120/240 GB. Zbylé místo je rezervováno pro realokaci "odešlých" bloků. Další "tajné" čipy navíc tam nemají. :)

To že se to ani po pátém přepsání nezměnilo není překvapující. Těch přepisů MLC vydrží kolem 5000, eMLC 20 000 a SLC 100 000. Takže budete muset ještě nějakou chvíli přepisovat. :) Kdyby jste však provedl Secure Erase, tak hned při následném zápisu naměříte vyšší hodnoty IOPS.

+1
-1
-1
Je komentář přínosný?

Tak potom pouzivat particiu mensiu ako je celkovba kapacita SSDcka dava zmysel len v pripade ked si chcem bunky udrzat cerstve dlhsie a oddialit pokles vykonu? Predpokladam ze OS sice da prikaz kam to ma disk zapisat, ale realne sa o to uz postara vnutorna logika disku a ta to moze alokovat aj na miesto ktore by pri platnovom HDD zostalo realne neobsadene?

Ako do toho vstupuje TRIM?

+1
+1
-1
Je komentář přínosný?

Pokud používáte menší oddíl než jaká je kapacita od výrobce, třeba 80GB na 120GB SSD, pak buňky naopak čerstvé nebudou, protože se při procesech spadajících pod write amplification bude přepisovat menší počet buněk než by se mohlo a tedy na každou buňku vyjde víc přepisů. Těch 40GB nechaných ladem nevyužije systém ani logika SSD.

A pokud by jste je pak v budoucnu zpřístupnila, zapisovalo by se do těch 40GB (na teď už 120GB oddílu) přednostně, což by mělo zase dopad na výkon, negativní, protože wear leveling má vyšší prioritu než random writes. Jednoduše: buňky v té původní 80GB oblasti by měly dejme tomu 1000 přepisů a buňky v této nově zpřístupněné oblasti 0. Takže do původní 80GB oblasti by SSD zapisovalo _jen_ při nedostatku místa a jinak by veškerý garbage collection probíhal prakticky jen v rámci té malé 40GB oblasti. A když je k dispozici málo místa (i když jen uměle díky wear levelingu, který upřednostňuje zápis do buněk s nejméně přepisy), tak se musí přesouvat opravdu hodně (heski česki: furt :) ) a tím klesá hodnota IOPS.

A TRIM do nealokovaného (ať už systémem nebo výrobcem) místa nezasahuje a tím se na výkonu v tomto případě nepodepíše.

Správný postup používání SSD je: nikdy nepřekročit cca 65% kapacity. Tím bude mít disk vždy dost místa pro vlastní režii a udržení buněk co nejdéle "svěžích".

Nesprávný postup: zaplnit (i třeba jen jedinkrát) celý disk. Pak už je totiž celý i po smazání dat (zpět na hranici 65% zaplněnosti) nafurt zaplněný. Teda přesněji až do použití Secure Erase, ale to na používaném disku použít nejde, smaže totiž úplně vše a vrátí ho do téměř továrního stavu (informace o vadných a readresovaných sektorech jsou zachovány). Ano Secure Erase je dobré použít před reinstalací OS metodou "načisto". Třeba bootnutím si Live CD/USB Parted Magic (Live USB vyrobí z ISO image Parted Magicu prográmek UNetbootin).

+1
-1
-1
Je komentář přínosný?

Vela testov vyvracia vase tvrdenie o tom, ze nepouzivana particia veci zhorsuje. Nepouzivana particia je nezaplnena oblast a SSD disk neriesi logicke adresovanie. Zaplna nevyuzity priestor podla urcitej vnutornej logiky. Nema vyhradene konkretne bunky pre konkretne particie.
Vase tvrdenie by platilo, len ak by ste na particiu zapisali po jej vytvoreni nejake data, ale ak ju vytvorite a nenaformatujete, tak je to pre disk stale nevyuzite miesto.

+1
+1
-1
Je komentář přínosný?

To by sa dalo ciste teoreticky overit - spravit particiu napr. na 75% disku, zapisat ju plnu, zmazat a zapisat znova. Asi ako test o ktorom je tento clanok. Ciste teoreticky by k poklesu vykonu ako je ukazane na grafe malo dojst az po zapisany stvrtiny suboru, za predpokladu ze tam je linearna zacislost. Takisto rozsirenie particie a otestovanie poklesu IOPS z dovodu snahy radica pouzivat este cerstve bunky by sa dalo zmerat.

+1
-1
-1
Je komentář přínosný?

Napsal si:"Kdyby jste však provedl Secure Erase, tak hned při následném zápisu naměříte vyšší hodnoty IOPS.", Tak to prave nebyla pravda, disk byl zcela novy, kdyz jsem ho zacal testovat a prave ani plnym zaplnenim se mi nepodarilo snizit pocet IOPSu, tedy vycerpat vsechny predsmazane bunky. Jinak SCSI sbernice ma podobny prikaz jako TRIM akorat se to jmenuje jinak, nic takoveho jsem nenastavoval a neverim, ze by to fungovalo out of the box.

+1
-1
-1
Je komentář přínosný?

Nezlobte se, ale tomu prostě nemohu věřit. I ten výše zmíněný "nejlepší z nejlepších" Intel DC S3700 má svůj schůdek.

+1
0
-1
Je komentář přínosný?

Na http://www.anandtech.com/show/6489/playing-with-op se můžete podívat na to, jak závisí velikost toho schůdku na množství nevyužitého místa na disku. S přibývajícím volným místem se schůdek zmenšuje, u Samsung SSD 840 Pro 256GB při 50% nevyužitého místa schod prakticky zmizí, u ostatních SSD nejspíš taky, ale to němaj změřeno.

+1
+1
-1
Je komentář přínosný?

Nedávno začali na anandtechu měřit to samé - jak se s časem mění výkon a jak závisí na zaplnění. A mají to celkem pěkně graficky znázorněno. Viz. http://www.anandtech.com/show/6489/playing-with-op http://www.anandtech.com/show/6363/ocz-vector-review-256gb/5 atd.

+1
+1
-1
Je komentář přínosný?

Ak sa SSD použije ako jediný disk v systéme napr. notebook, takže všetky dáta vrátane tempov a swapu ostanú na ňom, tak jeho životnosť sa používaním bude geometricky znižovať.

Ak vymeníte HDD WD Velociraptor za nový SSD budete skôr ľutovať zbytočne vyhodené peniaze, lebo jediné čo prakticky pocítite je rýchlejší štart Windows.

+1
-1
-1
Je komentář přínosný?

Vymenil som Velociraptor za SSD a lutujem, ze som to neurobil skor. System je neporovnatelne rychlejsi. Praca s virtualnymi strojmi bola predtym utrpenie; teraz ani nespozorujem, ze pracujem na virtuale.
Swap mam pochopitelne na nom a tempy v ramdisku.
Zaruku na disk mam 5 rokov a pravidelne robim zalohy.

+1
-1
-1
Je komentář přínosný?

Pro psaní komentářů se, prosím, přihlaste nebo registrujte.