Instalace na SSD, co je špatně?

[DOC_ZENITH]

Ja bych naopak rekl, ze TRIM dost ulehcuje zivot WL algoritmu, protoze ten ma k dispozici mnohem vic volnejch erase bloku (nejen spare). Mimo to, kdyz uz je tak velka fragmentace, ze jsou zabrany vsechny spare bloky, nezbejva, nez delat read/erase/write na cely erase bloky, coz rozhodne zivotnosti neprospiva. Lepsi WL algoritmus nejspis takovou fragmentaci nedopusti, nebo to bude nejak hodne drsne optimalizovat, ale to furt nemeni nic na tom, ze cim vic erase bloku ma volnejch, tim lepe muze zapisy/prepisy optimalizovat.

A co je pro životnost horší? Udělat read/erase/write na tom bloku co je zrovna nejmíň opotřebenej, nebo preventivě nechat trimm dělat read/erase naprosto všude kde nejsou aktivně data? Ano pomalejší bude rozhodně možnost 1. Ale možnost 2 dozajista opotřebuje paměťové buňky více.

A co se tyce toho 'dalsiho hintu', tak neni problem sektor zapsat, je problem erase blok (128KB+) smazat - jde smazat jen najednou. A to musis udelat tak jako tak s celym erase blokem, pokud v sektoru, do kteryho chces zapisovat uz nekdy neco bylo.

Toto jsem zrovna moc nepochopil, jde hlavně o to, že OS/řadič vůbec nemá potuchu kam a co se u SSD zapisuje, kde a jakej sektor / cluster leží, to je řešeno jaksi virtuálně řadičem v SSD. Reálně jsou tam ty data naprosto jinak / jinde chaoticky, jejich rozložení ovládá právě ten řadič a aby se buňky používaly rovnoměnrě / co nejméně tak to je ten wear leveling. TRIMM právě umožní jakejsi most mezi samotným SSD, jeho controllerem, řadičem a OS aby právě os věděl jak tam data jsou a mohl je tam optimálně nahrávat = disk bude mít plnou rychlost nebude bržděn řadičem co by to normálně real-time musel hledat/přemisťovat.

Každopdně SSD disk co má read 250 write 150 novej.

Po 1 zero filu : 220 /125
Po 2 zero filu : 180 /105
Po 3 zero filu : 170 /90
Po 4 zero filu : 165 /75
Po 5 zero fillu : 160 /60
( read / write ).

Tak je to bez trimm u intelů obvykle, jak je to s trimm ještě otestováno nemam.

[Fox!MURDER]

A co je pro životnost horší? Udělat read/erase/write na tom bloku co je zrovna nejmíň opotřebenej, nebo preventivě nechat trimm dělat read/erase naprosto všude kde nejsou aktivně data? Ano pomalejší bude rozhodně možnost 1. Ale možnost 2 dozajista opotřebuje paměťové buňky více.

Tys to nepochopil. Ten read/erase/write se musi udelat pokazdy, kdyz zapisujes do sektoru, ve kterym uz nekdy neco bylo. Ale pokud o nejakym erase bloku (nekolik set sektoru) vis, ze je celej prazdnej, muzes ho smazat dopredu[/quote]

Toto jsem zrovna moc nepochopil, jde hlavně o to, že OS/řadič vůbec nemá potuchu kam a co se u SSD zapisuje, kde a jakej sektor / cluster leží, to je řešeno jaksi virtuálně řadičem v SSD. Reálně jsou tam ty data naprosto jinak / jinde chaoticky, jejich rozložení ovládá právě ten řadič a aby se buňky používaly rovnoměnrě / co nejméně tak to je ten wear leveling. TRIMM právě umožní jakejsi most mezi samotným SSD, jeho controllerem, řadičem a OS aby právě os věděl jak tam data jsou a mohl je tam optimálně nahrávat = disk bude mít plnou rychlost nebude bržděn řadičem co by to normálně real-time musel hledat/přemisťovat.

Vsak prave to je ono. TRIM je zpusob, jak radici rict, ze tenhle sektor uz opravdu neni potreba a tudiz data v nem neni potreba uchovavat. Kdyz radic uvnitr SSD vi, ze je erase block nevyuzitej, muze ho celej smazat a pak libovolne vyuzit. Pokud nevi, ze je prazdnej, tak tam data bud musi nechat (i kdyz je to zbytek neceho, co uz je na jinejch mistech davno prepsany), nebo je musi nekam presunout (za predpokladu, ze ten erase blok potrebuje). Coz je oboje jednak pomaly a druhak stejnou vec je potreba pri zapisu kazdyho dalsiho sektoru v erase bloku -> misto aby ho smazal jednou pri trimu, ho smaze a zapise pri zmene kazdejch 512 byte v ramci toho erase bloku (to samozrejme nedela doslova, protoze od toho ma par mega cache).

[Petrik]

Každopdně SSD disk co má read 250 write 150 novej.

Po 1 zero filu : 220 /125
Po 2 zero filu : 180 /105
Po 3 zero filu : 170 /90
Po 4 zero filu : 165 /75
Po 5 zero fillu : 160 /60
( read / write ).

Tak je to bez trimm u intelů obvykle, jak je to s trimm ještě otestováno nemam.

Tohle nebyl intel G2, ze? Ten ma zapis s poslednim FW cca 90-100MB, zato sve cisla drzi i po zapsani 700GB, samozrejme s TRIMem.

Moje zkusenosti po par dnech provozu SSD v DB stroji:
Realne hodnoty IOps cteni a zapisu se podle prefmon (bezi to na W7 kvuli TRIM) pohybuji na maximu cca 8000 IOps, coz je oproti cca 250IOps u velociraptoru docela masakr. Vykon stroje je nyni skoro 100% zavisly na CPU (Phenom II X2 3.1GHz 6MB L3), na disk se ceka jen zcela vyjimecne. MySQL bohuzel umi pro jedno spojeni vyuzit jen jeden thread, takze ten CPU je vazne brzda. Co je dulezite, na disk se neceka ani v heavy read write operacich, kdy se cte a zapisuje zaroven vice mene random a celkovy pocet IOps stoupa k 16kIOps pro jednu frontu, coz jsou cisla, o kterych se zrejme jinym SSD ani nezda. Celkove jsme tedy z SSD nadseni, ted by to chtelo tak 20GHz CPU...nejake napady krome i7?

[DOC_ZENITH]

Kvůli windows asi ne no... heh.. kdyby ne windows, tak na IBM Power gen.7 by se daly postavit trochu jiný stroje.