Tigu> no jak hodne to zpomaluje bez trimu nevim, pro RW pouzivame akorat MTD a JFFS2 a tam to obdobu toho ma primo ve filesystemu, takze to ani nejde vypnout.

Blackwolf: SSDcka bez trimu jsou po roce a půl nepoužitelné. Pokud máš Trim jak na SSD, tak v OS, pak do toho bez obav investuj. Kup si Intela, ten má garantovanou životnost 5 let. Zálohovat zálohuješ, tak není co řešit. Jen dej pozor na označení retial/bulk/OEM - liší se pár korunama a několika lety záruky. Ještě můžeš jít do kingstonu, ten má rebrandovaný Intely. nekupovat staré Kingstony, měly problém s FW a bez patche to občas posílalo disk do křemíkového nebe. Ještě se netváří špatně OCZ, ale tam si za kvalitu poměrně připlatíš (mají různé řady).

Ihaha: no bez TRIMU to chodit bude, ale po roce a půl to klesne pod rychlost standardních disků.

TRIM se hodi kdyz mas dost zaplneny disk..prave aby ten algoritmus proti opotrebeni vedel ze ty data muze beztrestne prepsat...

Wolferine> no tak ono to bude chodit i bez toho TRIMu, ono je otazka co vlastne pri tom ATA commandu SSD udela, technicky si muze ono uvolnene misto predmazat aby mel pak rychlejsi zapis, neco to taky muze usetrit pri premapovavani sektoru (pokud vi ze je prohazovanej sektor smaznutej tak se nemusi kopirovat).
Ale principialne musi byt schopny SSD chodit i pokud TRIM nedostava, je to mineno jako vypomoc tomu algoritmu premapovani. Je jenom otazkou casu kdy zjisti ze by se hodila i dalsi vypomoc a neco tam zase dodelaji - treba oznacovani ktere sektory obsahuji casto zapisovana data (alokacni tabulky a podobne veci) a ktere se moc nemeni.
Jinak pouziti TRIM ma jednu zasadni vadu, pokud se na danej sektor ten prikaz posle tak uz ho neobnovite nijak. U normalniho disku se nikdy sektor nemazal, vzdy se jenom prepisoval, takze dokud se to neprepsalo tak slo z disku vytahonut i fragmenty smazanych souboru (dokonce i v okamziku kdy doslo treba k poskozeni alokacni tabulky). Tady se ten sektor opravdu fyzicky smaze (nastavi na obvykle 0xFF).

Blackwolf> no neco nam beha na CF kartach, ale mame na tom RO filesystem protoze linux docela tezce nese kdyz se tomu utrhne napajeni bez radnyho ukonceni. Co se tyce rychlosti cteni tak nam to brzdi sbernice, CF umi vic nez da radic v tom embedded zarizeni. SWAP to nema, pro SSD disky/CF atd to neni dobra volba, lespi je koupit vic RAM (vyjde to i levnejc). Logy a podobne ukladame do MTD NAND FLASH mountnutou jako RW na JFFS2. Kluci to bezne vypinaji za chodu a nevim o tom ze by se neco ztratilo, akorat to pak pri startu vzdycky nadava ze v nekterych blocich nesedi CRC nebo ze jsou prazdny ale nesmazany. Vadny bloky se nam zatim neobjevili (pouzivaji to zatim cca rok). Jo a jeste zapis je o neco pomalejsi nez cteni, ale pozna se to jenom pokud to kopirujes fyzicky pomoci DD, pri bezny praci to neni znat.

Muzu se zkusit kolegy zeptat jestli s normalnim SSD do SATA neco zkousel, ale asi zatim ne (mozna mel neco pujcenyho na testovani).

Mě by spíš zajímaly reálné zkušenosti - jak to funguje si dohledám sám :))
Prostě jak dlouho to vydrží při běžném pracovním používání, jestli to je za dva roky kaput, nebo třeba za pět, nebo se to může posrat po půl roce atp.
Pokud bych to používal tak stejně jen do desktopu na programy (OS a programy na SSD a dva normální disky na data), ale prostě by mě zajímaly reálné zkušenosti.

Ihaha:
podpora os je potreba pro trim
http://en.wikipedia.org/wiki/TRIM

wolferine: ne primo fat, mluvil jsem o obdobnych tabulkach ktere maji vsechny file systemy.

Jo a jeste jedna poznamka, kopie casti alokacni tabulky se obvykle drzi v RAM aby k ni mel OS co nejrychlejsi pristup. Z toho duvodu taky Win nenabehnou z NTFS disku pokud mate min jak 64mega RAM - nevejde se tam mirror MFT

Bluefox> no prave tohle resi ty algoritmy v radici toho SSD. Funguje to tak ze to dynamicky premapovava logicke sektory (ty ktere vidi PC) na fyzicke sektory (tak jak jsou zapsane ve FLASH. Fragmentace jako takova prilis nevadi protoze vybavovaci doba FLASH je v podstate nula - je vicemene jedno jestli ctete data zasebou nebo nahodne (neplati tak uplne pro NAND ale stejne budete vzdy cist nejmin 512byte takze je to jedno). Problem je v tom ze ten prepoctovy algoritmus musi byt schopny co nejrychleji vypocitat kde aktualne data jsou. V realu se totiz data neprepisuji ale zapisuji se do prazdneho sektoru a meni se mapovani. Tim ze se takhle prohazuji sektory se zajisti ze se opotrebuji vsechny sektory stejne. Jinak by se sektory kde je umistena alokaci tabulka (FAT, MFT, ext zurnal) opotrebovali hodne rychle. Je pak otazka FW SSD aby si tohle osefoval, jak presne to dela nevim a jentak to nekde nenajdete protoze je to vyrobni tajemstvi vyrobce. Ale podobny system meli uz CF karty protoze se umi chovat jako klasicky ATA disk. Posleze se tyhle algoritmy taky staraji o nahradu vadnych sektoru FLASH - specialne u NAND je to nutnost protoze tam vadne sektory jsou uz od vyroby (taky je tam kuli tomu vic mista nez je kolik je jmenovita kapacita). Co se tyce podpory OS tak SSD to nepotrebuje, mapovani probiha na pozadi a OS o nem ani nevi. Neco jineho jsou v linuxu takzvana MTD zarizeni coz je primo mapovana FLASH. Tam ten radic chybi a rovnomernost opotrebovani si resi specialni filesystem (JFFS,YAFS..).
Co se tyce zivotnosti tak to bude porad nekde kolem 10000 az 100000 zarucench cyklu zapis/mazani, ale obvykle to vydrzi vic.

on jeste nekdo pouziva fat?