Vlákno názorů k článku
256 GB SSD od Samsungu od Yenya - To 2.4x rychlejsi je podhodnoceno, a to tak...

To 2.4x rychlejsi je podhodnoceno, a to tak ze dost. 2.4x rychlejsi je mozna tak pri mereni
sekvencniho prenosu, coz se ale dela v minimu pripadu. V realnem provozu disk dela v podstate nahodne operace. Kdyz pocitam ze disk udela dneska tak 130-150 operaci za sekundu a dobry filesystem je schopen do disku cpat rekneme 64 KB velke requesty, tak mam maximalne 9.6 MB/s[*].
Zatimco u toho SSD predpokladam je uplne jedno odkud ctu a porad mam tech 200-300 MB/s, cili minimalne 20x rychlejsi prenos, ne 2.4x rychlejsi.

Jeste je teda otazka, jestli tenhle disk ma nejaky flash translation layer v sobe, nebo na nem musi
byt specialni filesystem pro flash pameti, aby se rychle neznicily nektere bloky.

-Yenya

[*] overeno iostatem na ftp.linux.cz - ani ext3, ani XFS, ani JFS pri realne zatezi (stovky uzivatelu stahujicich data pres FTP) neudelaji vic, spis je vykon disku tak okolo 5 MB/s.

Velikost I/O requestu přece nemusí být omezená (alespoň ve Vistě není). Počet pohybů hlav zase zmenšuje NCQ. No a kopírování v rámci jednoho disku mi generuje okolo 40-60MB/sec (čtení+zápis), pokud nejde o velmi malé soubory.

U toho FTP serveru je podle mě spíš otázkou síťové spojení.

To samozřejmě ano. Vždyť také při kopírování velkého souboru je rychlost vyšší. A pochopitelně s velmi malými soubory rychlost klesá. Jednak kvůli seekům hlavy HDD, a potom kvůli narůstajícímu overheadu FS.

40-60 MB/s ano, ale jen sekvencni operace jednoho procesu. Pokud tech operaci je vic paralelne a pridaji se k tomu i metadatove operace, jde rychlost i prumerna velikost I/O operace fakt rapidne dolu.

U FTP serveru neni otazkou sitove spojeni. iostat ukazoval ze ty disky mely 100 % casu co delat(*), a presto z nich lezlo kolem tech 5 MB/s. Pristupova doba disku 8 ms je opravdu zhruba tech 125 operaci za sekundu, vic ne.

-Yenya

(*) dost co delat - i delka fronty operaci byla netrivialni. NCQ by tomu nepomohlo,
operacni system (teda aspon Linux :-) dokaze ty pozadavky tridit lepe, protoze ma k dispozici prehled o vetsi fronte pozadavku, o jejich casove kriticnosti, a obecne i vic pameti k dispozici nez ma disk cache. NCQ poskytuje jen velmi male zrychleni - v podstate jde jen o to, aby disk dopredu vedel kam s hlavickou dale v okamziku, kdy nacetl pozadovane sektory do sve cache, ale jeste je cele neodvysilal host adapteru.

To dost záleží na kvalitě FS, a na velikosti cache. A samozřejmě i na velikosti I/O requestu.

NCQ samozřejmě pomůže. OS nemá přehled o geometrii disku, a neřeší ji. V principu tedy může nechat číst na přeskáčku data ze začátku a konce plotny, což bude pomalé. NCQ dovede ty požadavky provést mimo pořadí, a tak snížit potřebu seekování. A jak správně říkáte, seekování je drahé.

Mimochodem můžete zkusit přimontovat disky s flagem noatime. Vyhnete se zápisu zbytečných změn v metadatech. Navíc mám za to, že když provedete přístup k souboru /a/b/c/d/e/file.ext, tak se snad přepisuje i access time všech těch adresářů. Ovšem sázet se nebudu, a hledat se mi to nechce.

Vsechny SSD disky AFAIK maji wear-leveling, cimz rozkladaji zapisy na ruzne bloky.
Pak je jeste zasadni rozdil mezi MLC (levnejsi, cca 10000 prepisu) a SLC (drazsi, vic nez 100000 prepisu).
Mam takovy pocit, ze tohle ma i vetsina CF karet, protoze to je vlastne IDE disk, jen s jinym konektorem.

Tak tak.
Ale jeste by me zajimalo, kolik prepisu ma jeden blok na klasickem disku, protoze kazdy uvadi chyby v hodinach provozu.

Praveze blok na klasickem disku se neopotrebovava prepisem - magneticka vrstva
je porad stejna. No a pri prumerne zivotnosti 3 roky to muze byt 150 requestu za sekundu x 3 x pocet sekund za rok docela dost.

-Yenya