Ssd

[Petrik]

Zkusim sem napsat par postrehu, ktere jsem vygooglil za poslednich par dni, protoze se chystam do meho noveho (jeteho) notebooku ibm X41 dat misto disku 8GB CF 266x Pretec.

1) wear levelling skutecne zpusobuje vnitrni fragmentaci, tak jak to je popsano ve znamem clanku na cdr.cz.

2) wear levelling zatim nemuze fungovat prilis dobre a to z toho duvodu, ze SSD netusi, ktera data jste vymazali a ktera ne, takze pokud se stane, ze do kazdeho bloku neco zapisete (at uz najednou, nebo postupne), tak tim wear levelling vpodstate konci, protoze prestoze jste vy rekli vasemu FS, ze ty a ty data ma vymazat, tak on je samozrejme nevymaze, ale jen zahodi zaznam k nim vedouci nebo tak neco (podle FS). Dulezite je, ze SSD o tom nema (a zatim ani nemuze mit) ani paru, takze musi brat vsechny bloky jako obsazene, cimz nemuze efektivne provadet wear leveling. Mozna to neni uplne presne jak jsem to popsal, ale princip je asi jasny. Toto resi novy ATA TRIM prikaz, kterym v budoucnu (az bude implementovan vyrobci SSD a OS+FS) FS primo rekne SSD, ktere bloky muze uvazovat jako prazdne a pouzit je pro wearlevelling. Jako prvni by jej mel udajne implementovat intel do FW svych X25 SSD, v linuxu by jiz mel udajne byt, anebo se chysta.

3) pouziti SSD v linuxu: jako nejrychlejsi FS pro SSD se zda byt novy ext4, ktery navic umoznuje nepouzivat journal a presto je znatelne rychlejsi a lepsi nez stary ext2 (=ext3 bez journalu). Zasadni je predevsim pouziti noatime u mountu, dale hodne pomuze pouziti noop IO planovace, pripadne vypnuti barrier. Barrier spolu s vypnutim journalu dramaticky zvysuje pravdepodobnost ztratu dat po nahlem vypadku ci rebootu, prvni vsak zvysuje rychlost, druhy predevsim opotrebeni SSD a zaroven snizuje vnitrni fragmentaci. journal se da take umistit na jine medium, pokud je k dispozici. Dulezite by rovnez melo byt zarovnani diskoveho oddilu tak aby odpovidalo velikosti bloku SSD (FS aligning). Dale se doporucuje presunout /tmp /var/log a podobne adresare do tmpfs, tedy do ramdisku. Linux kernel by mel jit donutit k agresivnejsimu cachovani zapisu (ala flashpoint nize), ale k tomu jsem se jeste nedostal. Pokud v linuxu nepotrebujete z SSD bootovat a chcete mit jen jeden diskovy oddil, je mozne udelat FS primo na SSD blockdevice (mkfs.ext4 /dev/sdX - vedeli jste o tom nekdo) bez jakeholi partitionovani, FS pak bude vzdy zarovnany (aligmented).

4) ve windows lze pouzit SW FlashPoint, ktery pro prvni disk v systemu vytvori 32MB writeback cache, ktera dramaticky zrychluje predevsim nahodny zapis u SSD bez cache, ale samozrejme zvysuje ryziko ztraty dat. Dale je mozne vytunit windows skrz registry pro mensi pocet zapisu na disk (ntfs volby a pod).Rovnez se doporucuje udelat cluster aligment.

5) mnoho lidi si stezuje, ze pri pouzivani firefoxu na SSD bez cache dochazi k vytuhavani systemu. To je zpusobene castym ukladanim diskove cache, ta se tedy doporucuje ukladat pouze do RAM.

par zajimavych odkazu:
http://blog.loxal.net/2009/04/tuning...ance-with.html tuning ext4
http://forums.fedoraforum.org/showthread.php?t=215109 generic linux tuning
http://thunk.org/tytso/blog/2009/02/...se-block-size/ filesystem aligning v linuxu
http://thunk.org/tytso/blog/2009/02/...ized-for-ssds/ some notes about ATA TRIM
http://forum.thinkpads.com/viewtopic...hpoint#p506347 vliv cluster aligment a flashpointu na vykon
http://www.thinkwiki.org/wiki/Compact_Flash_boot_drive nejake povidani mimo jine o CF do X40/X41


doufam ze to alespon nekomu pomohlo. Az dorazi flashka a notebook, dam vedet nejake postrehy.

UPDATE: Pro win se doporucuje FAT32 misto NTFS kvuli absenci journalu, na druhou stranu v NTFS lze pouzit kompresi, ktera teoreticky muze byt prinosem.