Citace Původně odeslal DOC_ZENITH Zobrazit příspěvek
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).