Názory k článku Optimalizace práce s SSD disky v Linuxu
-
Bilbo (neregistrovaný)
Jo, s menší technologií (25 nm) bohužel kromě zvyšování kapacit i klesá životnost, o čemž výrobci raději mlčí(mlží). Něco se zlepšuje s lepšími algoritmy pro wear levelling, něco se zlepšuje tím, že se v disku dá více místa (např. 64 GB disk se prodá jako 40 GB a 24 GB je volné místo jako náhrada za bloky co přestaly fungovat - zvnějšku se to tváří normálně jako 40 GB SSD) ale pro použití kdyb se hodně zapisuje na disk to není ...
Těch "až 5 milionů zápisů" je nesmysl, realita je jinde.
Např. Intel uvádí živnotnost SSD 5 let při přepisu 20 GB denně. U 40GB disku to znamená během 5 let asi 1000 přepsání. Tedy nic moc... -
x (neregistrovaný)
Tady nejaka cisla s dlouhodobejsiho provozu, nicmene jeste s 34nm
http://marc.info/?l=dragonfly-commits&m=130203562024119&w=2
neco malo i zde
http://leaf.dragonflybsd.org/mailarchive/users/2011-04/msg00010.html
http://leaf.dragonflybsd.org/mailarchive/users/2010-05/msg00142.html
http://leaf.dragonflybsd.org/mailarchive/users/2010-12/msg00009.htmlale nejvice toho clovek najde zde
http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache§ion=ANY
vcetne detailu o technologii a jejich problemech, zminky o tech novych 25nm atd. Ne vse sice vyuzitelne na Linuxu, ale asi porad nejlepe sepsane pro praxi
-
cavo (neregistrovaný)
urcite odporucam. ja mam disk dovezeny z usa od septembra 2009. jedna sa o ocz vertex 64GB. bezim na ubuntu, aktualnu instalaciu mam uz asi rok. samotny boot po login trva asi 7 sekund, co je asi polovica toho, co trva POST. po prihlaseni mam hned plochu a procak ako aj disk nic nerobi. mam stary NB toshiba m100-222 - nemam dovod menit.
ked obcas musim nieco spravit na pocitacoch surodencov, co maju windowsy - 2 x XP a 1 x vista, je to hrozne. ja neviem, ako na tom dokazu pracovat. brat po zapnuti NB caka 2 min, kym mu nabehne browser sledujuc LEDku disku. zmoze sa akurat na zafrflanie, ze mu treba preinstalovat system. skutocne obdivujem ich trpezlivost, menej uz obdivujem ich efektivitu prace.
nie som nejako slepo zaujaty, keby to neslo podstatne rychlejsie, tak to zahodim.
-
Nomen (neregistrovaný)
Když nahlédneš do specifikací SSD WD SilikonEdge Blue, najdeš tam mj. i následující informaci o životnosti:
64 GB model ... 17,5 GB/den
128 GB model ... 35 GB/den
256 GB model ... 70 GB denMyslím, že můžeme s klidným svědomím předpokládat, že
1. se tyto hodnoty vztahují k tříleté záruce,
2. ponechali si ještě nějakou rezervu.http://www.wdc.com/en/products/products.aspx?id=90
Nevěřím, že bys tohle překročil na běžném systémovém disku.
Pro datové úložiště obvykle tak velký výkon nepotřebuješ a oceníš spíš lepší cenu za 1 GB u konvenčních disků.
Ideálem se tedy v současnosti zdá být malý SSD pro systém: IMHO 16 GB bohatě stačí, 32 GB je fajn rezerva, 64 GB už je skoro zbytečných (ale třeba máš vyšší nároky, u mě kompletní systém zabírá asi 4 GB). A k tomu konvenční disk pro
/home, případně RAID pro/srv.Parametrem
noatimenic nezkazíš, stejně tak přesměrováním/tmpdo ramdisku - to se běžně používá i na konvenčních discích. Samozřejmě ti v případě paranoie nic nebrání přesměrovat do ramdisku i/var/tmp,/var/run,/var/lock, případně i/var/log, nebo dle vlastní libosti další. Ale v běžném nasazení to vzhledem k výše uvedeným objemům zápisu bude zbytečné. -
vadimo (neregistrovaný)
Mám k článku tri pripomienky.
1. /tmp;
Ak nemáme v počítači RAM pamäť na rozdávanie, tak namiesto tmpfs sa može použiť zram. Je to komprimovany(lzo) ramdisk. Rýchlostný efekt bude rádovo taký istý až na ten rozdiel, že si uštríme miesto v RAM. Tak isto je možné tento zram použiť aj na swap. Zram je v novších jadrách, v starších pod starým nazvom compcache (tu sa dá použiť len ako swap, aj inak sa konfiguruje).
Nejaké info o nastavení je tu: https://compcache.googlecode.com/hg/README
Výsledky z používania(compcache) tu: http://code.google.com/p/compcache/wiki/Performance2. Firefox;
Pokiaľ sa používa /tmp tak po reboote sa údaje vymažú :-(3. Filesystem;
Ak chceme znížiť počet zápisov na disk a zrýchliť aj jeho výkon a trošku ho "nafúknuť", môžeme použiť súborový systém btrfs s voľbou compress=[lzo gzip]. Filesystem použije transparentnú a inteligentnú komprimáciu, nekomprimuje súbory, pri ktorých by bol výsledok zanedbatelný. Lzo komprimácia je možná len od jadra 2.6.37 a nie je kompatibilná so staršími jadrami(starším btrfs).
Benchmark: http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo_2638&num=1 -
Yenya (neregistrovaný)
Na flash/ssd discich je nejhorsi, ze z duvodu rovnomerneho opotrebeni (wear leveling) delaji uvnitr sebe jeste jedno preadresovani bloku. Tohle preadresovani by mohlo umoznit dost efektivni fungovani filesystemu, pokud by jadro melo pristup k informacim, jak na konkretnim disku funguje. Bohuzel to ale z disku nijak nejde vycist.
Nektere flash disky delaji to, ze jeden blok (viditelny z OS) muze byt treba na 12 ruznych fyzickych mistech, ktera se jen cykli. Takze kdyz jsem treba na takovou flash zkousel dat soubor do ktereho se intenzivne zapisovalo, odeslo mi po kratke dobe 12 stejne velkych skupin bloku :-(
Jine flash disky treba maji optimalizaci typu "predpokladejme ze na disku je standardni rozdeleni a filesystem FAT, chovejme se tedy jinak k blokum kde ma byt FAT tabulka(*) a jinak ke zbytku".
Docela dobry popis wear-leveling algoritmu (i s animacemi jak to funguje) byl nedavno na LWN: http://lwn.net/Articles/428584/.
-Yenya
(*) Vim ze "FAT tabulka" je neco jako "CD disk", ale presto si myslim ze na tom miste je ten pojem srozumitelnejsi nez proste "FAT", coz muze byt i oznaceni celeho filesystemu.
-
Polish (neregistrovaný)
Mohli bychom sice sektory jednoduše zvětšit na 512 KB, ale tím bychom neuvěřitelně plýtvali místem, protože každý soubor by pak měl nejméně 512 KB a jeho velikost by se vždy pohybovala v násobcích této hodnoty.
Myslim, ze na linuxovych filesystemech jdou delat bloky do velikosti stranky, takze 4KB.
Pr. pro ext4 :
-b block-size Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. -
zzxx (neregistrovaný)
clanok ok az na sekciu "Méně zápisů a vyšší výkon". Tam su uplne bludy a redaktor si dovolil citovat z clanku, ktory je mimo realitu a vypocty uvadzane na tejto stranke su zcestne. Redaktor si tieto informacie bud nijako neoveril alebo si tendencne vybral taky clanok, z ktoreho vychadza, ze SSD disky nemaju problem so zivotnostou. Pritom je to u SSD diskov asi najvecsi problem.
Ktory SSD disk vydrzi 5 milionov zapisov a k tomu aj MLC disk? Dnesne MLC SSD disky (34nm a 25nm) vydrzia zhruba 3000-5000 zapisov. Pri tomto pocte zapisov a urcitom zatazeni disku, disk nevydrzi ani do konca zaruky.
Pri zapisoch ako sa uvadzaju v clanku by MLC disky odisli v priebehu par tyzdnov podla toho kolko nahradneho miesta bude mat disk pre premapovanie vadnych blokov a ako ma dany vyrobca vyladene funkcie ako wear leveling a podobne funkcie na predlzenie zivotnosti.
80MB/s to je zhruba 7TB/den. Pri kapacite disku 64GB by to znamenalo zhruba 70000 prepisov celeho disku ak by sme chceli na disk zapisovat takouto rychlostou. Dnesny MLC SSD disk by to neprezil ani den. SLC disk by par dni vydrzal. To ratam idelany stav, kde dochadza ku kontinualnemu prepisu celeho disku. Velmi zalezi aj ake su to data, ci je ich mozne komprimovat pred zapisom.
Problematika SSD diskov nieje jednoducha tema.
SSD je vyborna vec ale este uplne nedospela a caka ju pechod na iny typ pameti. -
Vladki (neregistrovaný)
Tak nejak mne napada, kam si SSD disky ukladaji informace o tom kam premapovali jake sektory pri wear levellingu. Predpokladam, ze taky na flash aby prezily vypnuti systemu. No a v tom pripade to bude nejvice prepisovana cast flash pameti, ktera odejde jako prvni a s ni i cely disk. Nebo napada nekoho finta jak to vyresit?
-
To je DOBRÁ otázka! :-) Odpověď neznám, ale taky mi to vrtá hlavou. Zkuste mrknout do tohoto datasheetu:
http://www.sst.com/dotAsset/40312
a hledejte třeba "flash file system". Zjistíte, že přesně to sladké tajemství tam nenapsali :-DDocela rovnoměrný wear leveling s distribuovanými metadaty mají Linuxové filesystémy určené pro holé Flash čipy, jako třeba JFFS2 nebo LogFS.
http://en.wikipedia.org/wiki/JFFS2
http://en.wikipedia.org/wiki/LogFS
Vespod je holá flashka, svrchu se to váže rovnou do vrstvy VFS = nikde z toho nekouká blokové zařízení.
Cenou za rovnoměrnost opotřebení je nižší výkon. Počítám, že něco takhle složitého by asi v SSDčku zapečeno být nemohlo.Historicky zůstává v Linuxu taky implementace vrstvy NFTL/iNFTL, která je "přivázaná za nohu" k dávným flashdiskům M-Systems DiskOnChip. Vespod byl holý DiskOnChip MTD, svrchu se to tvářilo jako blokové zařízení, na kterém šel vyrobit konvenční "diskový" filesystém (třeba ext2). Podrobnosti neznám - ale je to každopádně lepší, než primitivní wear-leveling takymechanismy zaměřené na FAT FS.
-
Izak (neregistrovaný)
TRIM a InterLeaving ... to je OXYMORON ... tak bud ty data smaze a pak je to zapis. Nebo tam ty data necha a zapise je jinam a pak se ale nemazou ....
Tedy max si muze disk nekde zapsat, tyhle data uz jsou neplatna, nech je tam ... a pak je nekdy prepise ... v tom pripade by ale nefungovala metoda jak otestovat fce trimu ;-))
-
Lukas (neregistrovaný)
Ta metoda nebude fungovat at tak nebo tak. Ne kazdy disk pri trimu data "nuluje", nektere disky vraceji stejna data, jine muzou vracet nejaky garbage, nebo stabilni hodnoty (ale nemusi to byt zrovna nula).
To zda disk data opravdu "nuluje" je mozne zjistit z:
/sys/block/<device>/queue/discard_zeroes_dataale ani tak neni zaruceno ze to opravdu udela. Jednak existuje jeste /sys/block/<device>/queue/discard_granularity a jednak SSD disky jsou jeste porad neskutecne kramy, ktere nedelaji to co maji.
A ja asi nemam chut, silu ani cas komentovat vsechny nepravdy a polopravdy v podobnych clancich :)
-
Lukas (neregistrovaný)
A taky, pouzivat mount option "discard" mi neprijde jako idealni napad. U vetsini disku co jsem videl je patrny obrovsky ubytek vykonu (viz. http://people.redhat.com/lczerner/discard/ext4_discard.html) zvlaste kdyz to neni uplne nutne (viz. predhozi odkaz) a obzvlastne kdyz jiz mame v jadre FITRIM (ext4,ext3,xfs,btrfs?) a v util-linux-ng fstrim, ktery je mozne nechat spoustet z cronu ...
-
Lukas (neregistrovaný)
Sam jste prece psal ze po nekolika mesicich pouzivani jste si ubytku vykonu "nevsiml" a to ja pokladam za subjektivni pocit, ktery je ovsem irelevantni. Pokud mate nejaka cisla tak sem s nimi. Pointa byla v tom, ze to co se vam "zda" nemusi byt tak uplne realita. Urcite jsem to nemyslel jako urazku.
-
Zdá se, že o věci něco víte :-) Nepatrně mi vrtá hlavou jedna otázka, v souvislosti s "nulováním": točivé disky ve factory clean stavu jsou "popsané samými nulami". Kdežto smazaná flashka je "samé 0xFF", tj. samé binární jedničky. Zápis znamená, že se některé jedničky přepíšou na nulu (zpátky na jedničku už to pak nejde, leda novým smazáním celého erase blocku). Aspoň tahle logika funguje u NOR flashek (BIOS apod.). Nevím jak u NAND (interně je to stejně, ale nevím jak na vnějším rozhraní). Resp. by mě zajímalo, jak se chová ATA disk, jak ukáže smazaný erase block - jestli surové samé jedničky, nebo jestli to letmo invertuje na samé nuly... Na jedné CF kartě, která realokovala nultý erase block, byly vidět samé jedničky.
-
Lukas (neregistrovaný)
To je neco co bohuzel nejsem schopen posoudit, nejsem clovek pres hardware :). Kazdopadne standard mluvi jasne, bud po discardu vraci same nuly, nebo pevne definovanou hodnotu, nebo puvodni hodnotu coz ale predstavuje bezpecnostni riziko. Dalsi moznost je vrazeni nejakych garbage hodnot, ale to si nejsem jist zda je standardizovane chovani. To co dela firmware bohuzel nevim a ani vedet nemuzu protoze to vetsinou spada do know-how vyrobcu :)
At tak nebo tak, idealni stav je pokud po trimu vraci same nuly, proto je to taky neco co linux kernel exportuje do user space.
-
Podle mě si to v této rovině zase tolik neprotiřečí :-)
Když TRIM označí konkrétní erase block jako volný, tak si ho SSDčko může rovnou smazat, nebo cinknout pro pozdější smazání, aby se v konečném důsledku dostal do interního "poolu volných erase blocků", do kterých lze přímo zapisovat bez čekání na smazání - takže následující zápis proběhne svižně (nemusí čekat na mazání, možná nemusí ani přednačítat erase block, pokud je mapování sektorů na erase bloky jemnější). Finta je v tom, udržovat si co největší pool volných předsmazaných erase bloků.Prakticky, pokud jsem to správně pochopil, je problém v tom *kdy* přesně provést ten výmaz erase bloku, protože mazací operace je každopádně docela časově náročná. SSDčka, která to provádí *hned* v rámci vyřizování příkazu TRIM, typicky zaznamenávají díky příkazu TRIM výrazný úbytek průchodnosti (nad rámec vlivu flushování NCQ fronty). A pokud SSDčko provádí mazání vyTRIMovaných erase bloků "až později když je klid", tak pokud do toho přijde třeba i jenom čtecí transakce na dotyčný kanál (čip?) NAND flash, může to znamenat citelné zdržení - možná je to u čtení dokonce subjektivně znatelnější než u zápisu (write-back cache leccos skryje). To je cena za rychlý zápis nebo "trvale mladé SSDčko".
-
haplo602 (neregistrovaný)
totalne zly clanok. bol by som rad, keby si autor nabuduce overil o com keca.
SSD disk pozna 2 velkosti blokov:
1. citanie vie adresovat po 4KB ako kazdy iny bezny disk
2. zapis vie adresovat len po 512KB ako bolo spomenute v clankuToto prebieha interne, OS o tom nema ani tucha, dokonca aj TRIM funguje len po 512KB blokoch a FS to posiela podla fs blokov (bezne 4KB), takze SSD disk si toto musi prislusne nazbierat a prelozit na internu adresaciu.
Co sa tyka zivotnosti, nove NAND MLC bunky maju zivotnost 3000 zapisov. Sice to je pomerne dost pre bezne pouzivanie, ale trosku intenzivnejsia praca s diskom im drasticky znizujezivotnost. Aj ked pre bezneho pouzivatela to bude stacit na par rokov.
-
> 1. citanie vie adresovat po 4KB ako kazdy iny bezny disk
> 2. zapis vie adresovat len po 512KB ako bolo spomenute v clanku
>Na ATA rozhraní, pokud vím, je 512B sektor pro čtení i zápis. Na tom se shodneme. 4 kB sektor v souvislosti s disky se vyskytuje jenom u novějších modelů WD a jedná se o interní formát na plotnách, navenek je pořád 512B.
Pokud si přečtu třeba tohle:
http://www.ccs.neu.edu/home/pjd/papers/hotstorage09.pdf
tak interně to vypadá, že NAND flash vyžaduje čtení či zápis o velikosti "NAND Flash stránky" (vlastně se jedná o řádek), která má podle uvedeného PDF typickou velikost 2 nebo 4 kB. Ovšem *mazat* lze pouze celý erase-block naráz (třeba 512 kB). Osobně bych nepokládal rovnítko mezi zápis a mazání - pokud si disk vede nějaká metadata o alokaci uvnitř erase-blocků, tak by teoreticky nemělo být potřeba mazat při každém zápisu celý dotčený erase block. Teprve když se disk dostane do fáze, kdy nemá jinou možnost než read-modify-erase-write, tak se to rovnítko mezi zápisem a mazáním samo vynoří. -
Kar (neregistrovaný)
Díky za článek, určitě je tam řada zajímavých nápadů. Jen k té životnosti SSD - mohu se dozvědět zdroj, který uvádí životnost řádově miliomy zápisů? Hledal jsem a nenašel. Dle všechno, co výrobci sporadicky uvádí, vychází na počet zápisů na několik tisíc. Vypadá to, že v článku došlo omylem k přihození tří řádů navíc.
-
1) erase block size vetsiny SSD disku je 128K, 512K mozna u EFD...
2) mount -o discard,defaults neni moc stastne, fedora potom ignoruje to discard - vetsina FS ale uz dneska SSD zarizeni detekuje a discard zapne sama
3) noatime se uz moc nepouziva, default pro nove filesystemy je relatime a ten se smi pouzivat i s SSD
4) opotrebeni SSD disku bych naprosto zanedbal, zivotnost je vynikajici aniz by clovek data premistoval, navic premistenim do pameti clovek prijde o data pri rebootu (pokud si neporesime synchronizaci v shutdown skriptu...), pokud se da napr. cache firefoxu na disk tak je zase podstatne pomalejsi (kdyz uz mame to SSD... :)Nejlepsi vec co jsem pri provozovani SSD udelal byl prechod na ext4 a zapnuti laptop mode (resp. zvyseni intervalu pro flush na disk).
Dalsi uzitecny tip - pokud jste provozovali SSD s vypnutym TRIM, tak neni od veci pred instalaci cely disk oTRIMovat rucne. To jsem delal hdparmem pres security erase a trvalo to par minut.
U modernich distribuci by ale normalni uzivatel nemel na nastaveni vubec sahat, s SSD se pocita.
-
No teda, trochu plkate...
nejdriv reknete: "U modernich distribuci by ale normalni uzivatel nemel na nastaveni vubec sahat, s SSD se pocita"
pak reknete: "to neni o distribucich ale o verzi kernelu, vfs, fs a default mount options"
a nakonec prohlasite: "ext3 i ext4 mely defaultne zapnuty TRIM uz pred rokem, nebudu zkoumat jestli ty patche jsou i ve vsech distribucich, ale u tech desktopovych o tom nepochybuji :)"
Ale napr. Ubuntu 10.10 nema TRIM defaultne zapnuty, i kdyz ma kernel ktery TRIM podporuje.
-
Zdravíčko vespolek,
ten článek mi přijde poněkud nekritický... Příkaz ATA TRIM je z definice (dle standardu) nezařaditelný do NCQ fronty, pročež před každým jeho podáním disku musí bloková vrstva čekat, až se NCQ fronta zcela vyprázdní. Prakticky se tak chová jako tvrdá bariéra. A co hůř, u první generace SSDček (podle toho co našel Google někdy v roce 2009) mohl TRIM trvat *hodně* dlouho - třeba až stovky ms = "SSD si šel dát kafe" (reálně něco mazal a k tomu prováděl jakousi "garbage collection"). Nevím jak u aktuálních modelů SSD a verzí firmwaru.
Svého času jsem někde četl povzdech/shrnutí jakéhosi kernelového vývojáře (už to nedokážu najít) který doslova došel k závěru, že lepší a jednodušší než ATA TRIM je nakonec žádný TRIM nepoužívat, a "pasti read-modify-write" se vyhýbat inteligentnějším slučováním zápisových operací + flagem "přepis na místě". Netuším, jak to nakonec v Linuxu implementovali, jaký je aktuální stav... a jenom doufám, že si ten závěr pamatuju dobře.
Dneska jsem dokázal vygooglit tohle výživné vlákno z LKML (dva různé archivy téhož):
http://lkml.org/lkml/2009/8/16/159
http://thread.gmane.org/gmane.linux.kernel/876737/focus=42383
...a z něj taky volně cituji v prním odstavci.V článku mi dále chybí zmínka, že není dobré na flashdisk swapovat, točit na něm velký objem logů, mailů apod.
BTW, ten problém s příkazem TRIM ("nejlepší TRIM je žádný TRIM") mi dost připomíná nedávný vývoj okolo implementace bariér v blokové vrstvě - ačkoli se jedná zjevně o nesouvisející problém...
http://lwn.net/Articles/400541/Ohledně zmíněného zarovnávání oddílů a "block groups" na velikost erase bloku: jak se dá u konkréního SSD tenhle parametr zjistit? Je na to nějaký ATA příkaz / registr? Umí to hdparm nebo třeba smartctl? Nebo je potřeba hledat v dokumentaci od výrobce SSD? Nebo je jediná šance SSD otevřít, zjistit použité Flash čipy, a koukat do *jejich* datasheetů? Jasně, docela rozumný praktický přístup je, nasadit to od oka na nějakou radši vyšší mocninu dvou, a hotovo :-) "ztratit" 512 kB na začátku 40GB SSD, to asi není velký problém...
Ještě mě zaujala jedna věc: v LBA režimu jistě není problém naadresovat ~100 PB, nicméně BIOSová tabulka rozdělení (pro kterou potřebujete hlavy a sektory) funguje jenom do cca 2 TB, a to ještě za předpokladu 255H/63S. Pokud pro BIOS (aby se z disku dalo bootovat) dosadíme 32H*32S, (= cylindr velký 1k sektorů), vychází z toho maximální velikost disku nějakých 64M sektorů = 32 GB? Navíc mám pocit, že BIOS by tu geometrii stejně nevzal (trval by na nějakých *svých* hodnotách CHS/LBA/LARGE). Pak mi přijde rozumnější, pokud SSD beztak nebude bootovatelné, použít ho jako "dangerously dedicated" (nerozdělené). A dál už stačí jenom nalinkovat velikost clusteru nebo "block group" nebo jak se tomu říká ve Vašem filesystému...
-
Kdyz si clovek precte tento clanek a pak nasledne diskusi k nemu, tak musi zakonite dojit k nazoru, ze bud autor vubec nevi o cem mluvi, nebe se SSD disky chovaji kazdemu uzivateli nejak jinak. protoze se nektere nazoru doslova vylucuji.
Jinymi slovy: Neexistuje jednotny nazor ani na to, jak nastavit resp. optimalizovat a zda vubec SSD disk, alespon na desktopu pro bezne pouziti.
To je teda dost tristni situace... nemate take ten dojem???
-
Já bych to tak černě neviděl :-) SSDčka jsou obecně výborná pro read-mostly provoz s vysokou náhodností "seek positions". Pokud máte v mixu větší množství zápisů, tak je třeba mít se na pozoru. Taky je co do rychlosti zápisu výrazný rozdíl mezi různými kategoriemi ATA SSD - od levných CF karet (náhodný zápis třeba 10 IOps) přes nějakou střední třídu (solidní noname), po špičkové značkové SSD třeba od Intelu (náhodný zápis 900 IOps) - pro srovnání běžná točivá Barracuda má náhodný zápis nějakých 75-90 IOps.
My se tady už jenom tlučeme čepicema nad nuancemi jak ladit geometrii FS proti SSD (resp. jak přesně formulovat potřebnou trojčlenku), jestli je TRIM k něčemu nebo ne - ale to jsou spíš takové drobnosti na okraj. Základní vlastnosti SSD nikdo nezpochybňuje.
-
hajoucha (neregistrovaný)
Ahojda, omlouvám se, asi jsem opravdu natvrdlý, ale jak to tedy je v mém případě se zarovnáním?
# fdisk -S 32 -H 32 /dev/sdaCommand (m for help): p
Disk /dev/sda: 80.0 GB, 80026361856 bytes
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5779bbcaDevice Boot Start End Blocks Id System
/dev/sda1 63 2008124 1004031 82 Linux swap / Solaris
/dev/sda2 * 2008125 2200904 96390 83 Linux
/dev/sda3 2200905 156296384 77047740 83 LinuxCommand (m for help): ^C
Kde jsou v daném případě ty avizované 512KB bloky? -
No... řekl jste fdisku na příkazové řádce, jakou geometríí má na disk pohlížet. Ale tabulka rozdělení zůstala v původním stavu, protože jste ji zatím nezměnil/nesmazal/nevytvořil znovu - a to že první oddíl začíná na sektoru s LBA adresou 63 znamená, že tabulka rozdělení počítá s klasickými 63 sektory na stopu (nultá stopa zůstala prázdná s výjimkou MBR, první oddíl je zarovnaný na začátek stopy č.1). Pan Krčmář měl na mysli, že ten fdisk poštvete na "factory clean" SSD (má v MBR samé nuly, tj. tabulku rozdělení prázdnou) a oddíly teprve následně fdiskem vytvoříte. Pokud přijmeme zarovnání na 512 kB = 1k sektorů = 1 cylindr, tak první oddíl by měl začínat na sektoru č.1024.
-
Já se přidám:-)
<b>RE: Ujistěte se ještě, že první oddíl začíná na sektoru dělitelném číslem 512.</b>
Který sektor, nebo spíš které číslo sektoru není dělitelné 512 :-) ?Źádný SSD disk sice nemám, (tohle je jeden z posledních IDE disků), ale stejně by mě zajímalo, jak to je.
fdisk -lu /dev/hdaDisk /dev/hda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xfa3ffa3fDevice Boot Start End Blocks Id System
/dev/hda1 * 63 208844 104391 fd Linux raid autodetect
/dev/hda2 208845 2184839 987997+ 82 Linux swap / Solaris
/dev/hda3 2184840 60789959 29302560 fd Linux raid autodetect
/dev/hda4 60789960 976768064 457989052+ fd Linux raid autodetect
-
Jan (neregistrovaný)
Dost mě udivuje, že tu ještě nikdo nezmínil GPT fdisk aneb gdisk. S ním jsem si rozparceloval SSD úplně v pohodě, sám se stará o zarovnání a používá moderní GUID Partition Table.
Jinak SSD mám 64 GB, což je u mě systém + /home, prostě vše kromě objemných multimediálních dat a tak se mi to zdá optimální. Mám zapnuto discard a noatime (není důvod to nepoužívat i pro HDD). Systémové logy, IRC logy i cache prohlížeče jsem nechal na SSD, pro nenáročný desktop je to podle mě vyhovující řešení. HDD tímto zůstává úplně potichu pokud z něj zrovna netahám nějaké to video. Po několika měsících jsem nezpozoroval snížení rychlosti čtení či zápisu na disk, ale občas se mi zdá, jako by přístupová doby trochu "lagovala", třeba otevření jednoho malého souboru není okamžité. Ještě to budu muset trochu prozkoumat, myslím si, že dřív to nedělalo.
-
Tohle píšu z hlavy, tak doufám, že to dám správně:
Originál, na který reaguji:> Jeden cylindr tak bude mít 1024 bajtů, a protože fdisk rozděluje
> disky v násobcích 512 cylindrů, budou nám vycházet ideálně velké
> bloky. Poté si vytvořte oddíly tak, jak jste zvyklí.
>
> Ujistěte se ještě, že první oddíl začíná na sektoru dělitelném číslem 512.Moje verze:
"Jeden cylindr tak bude mít 1024 sektorů (á 512B = 512 kB), a protože linuxový fdisk zarovnává oddíly by default na celé cylindry (= v násobcích 512 kB), budou nám vycházet ideálně velké oddíly zarovnané na cylindr = erase block. (Windowsový fdisk zarovná první oddíl na stopu.)
Ujistěte se ještě, že každý oddíl začíná na sektoru dělitelném číslem 1024."
Výše uvedené počty předpokládají historickou standardní velikost ATA sektoru = 512B, která podle mého dodnes naprosto převažuje.
Nové točivé disky WD mají/nemají sektor o velikosti 4 kB. Interně 4 kB, ale navenek to překládají na 512B, což je prča zejména ve chvíli, kdy na tom vytvoříte BIOS partition table s geometrií 255H/63S, což pak není soudělné se 4kB=8S...
Sektory o "nativní" velikosti 4 kB jsem si zatím vyzkoušel jenom na RAIDech (PCI/SCSI/SAS/FC) - a vespod byly stejně vždycky disky s 512B sektorem. A používal jsem to spíš pro Windowsy, protože různým součástkám v Linuxu 4kB sektor moc pod fousy nešel.
Jinak 4 kB je klasická velikost paměťové stránky v Linuxu - proto taky 4 kB je tuším nejmenší reálná velikost block-layer transakce. Vlastně by to šlo s 4kB sektory na blokovém zařízení hezky dohromady. Ale ATA disky to podle mého zatím reálně neumí - disky WD umí maximálně sdělit operačnímu systému, který o tu informaci případně stojí, že je vhodné zarovnávat na 4 kB - ale velikost sektoru na rozhraní ATA zůstává 512B.
-
Konečně všeříkající článek !! V podstatě sem měl půl té konfigurace již vygooglenou. Osobně používám již přes rok Kingston SSD V+ 128 Gb a k plné spokojenosti. Podle "palimpsest" mám pořád stejně rychlé čtení jako když jsem ho kupoval. Myslím si, že dnes je již trh s disky jinde než před rokem a vůbec bych neváhal ! Nárust výkonu je enormní !
-
... za velmi povedený článek. Mě osobně na SSD disky nahlodala už přednáška na minulém LinuxAltu. Žel bohu zatím mě odrazuje poměrně vyšší pořizovací cena (SSD SATA 128GB Kingston přes 4000 kč, HD SATA 500 GB 1100 - 1200 kč) :-( Takže ještě chvíli počkám, věřím, že než se se cena trochu sníží, určitě bude počet maximálních zápisových cyklů mnohem větší... :)
-
List (neregistrovaný)
Koncem minuleho roku jsem se zabyval spolu s kolegy SSD disky, nase vysledky a laborovani jsou sepsany zde: http://support.zcu.cz/index.php/Public:Svamberg/SSD
Vse bez zaruky, ale par zajimavosti zvlaste v odkazech stoji za precteni. -
tvrdoleb (neregistrovaný)
Je možné nějak naklonovat stávající root oddíl na nově koupený SSD, aniž bych to musel přeinstalovávat?
Představoval bych si to tak, že- připojím SSD
- zarovnám podle článku
# fdisk -S 32 -H 32 /dev/sda
# mke2fs -t ext4 -E stripe-width=128 /dev/sda1
Nebo nevím, jestli by to pro mě udělalo grafické udělátko z Mandrivy 2010.2? - "nějak" naklonuju stávající root na SSD - prosím poraďte jak?
(naklonoval by se i MBR?) - změním záznam v fstab (resp. překlikám to v diskdrake)
- rebootnu a mám to - systém nabíhá z SSD, starý root na točivém disku můžu použít na něco jiného
-
Andrej Podzimek (neregistrovaný)
SSD zatím není použitelné řešení, které by stálo za řeč. Mechanický disk lze za zlomek ceny používat bez sebemenších omezení, bez nečekaných změn výkonu (k horšímu) a bez neustálého strachu o data. Proč bych měl přemýšlet, jestli si zkompiluju kernel dvacetkrát nebo jednou??? Počítač slouží člověku, ne člověk počítači! Proč bych měl vůbec uvažovat o tom, že by disk mohl v průběhu morální životnosti počítače selhat? To se u mechanického disku prostě nestane.
Nejdůležitější postřehy shrnuje tento článek: http://www.zive.sk/disky-ssd-o-com-sa-nehovori/sc-3-a-292570/default.aspx Zejména závislost výkonu a opotřebení na zaplnění SSD je naprosto absurdní průšvih, který je sám o sobě jasným důvodem SSD nepoužívat. A že prý dražší SSD tímto neduhem netrpí? Opravdu? Kde je to napsáno? Že by snad v těch pověstných, dosud nezveřejněných a matematicky nepříliš solidních, zato však zázračných algoritmech pro wear leveling, které prý v těch drahých SSD (už konečně opravdu) jsou? :-D No tak to je opravdu výsměch.
Za zlomek ceny jednoho SSD jsem si koupil čtyři pevné disky. RAID5 odolá výpadku jednoho z nich (nesrovnatelně méně pravděpodobnému než u SSD), rychlost kontinuálního čtení a zápisu je srovnatelná s novým SSD a nesrovnatelně vyšší než u měsíc používaného SSD, kapacita je víc než desetinásobná ve srovnání s SSD za stejnou cenu... Fakt nevím, k čemu je SSD.
Takový flashdisk na USB zřídkakdy vydrží víc než 5 přepsání. Po nekonečných reklamacích (mp3 přehrávač, dva flashdisky -- to všechno selhalo po několika přepisech) jsem přešel výhradně na opravdové disky. I mp3 přehrávač mám diskový. Je to smutné, protože pohyblivé součástky nejsou dvakrát elegantní. Ale je to jediná technologie, která opravdu funguje a která není jen podvod na zákaznících. 99% lidí, kterým selže flashdisk, se na reklamaci vybodne a raději si koupí jiný. (A přesně tohle výrobci chtějí.) Drtivé většině lidí ovšem neselže, protože na něm přenášejí tak málo dat, že ani nikdy nepřepíšou všechny fyzické bloky. Jenže má-li tato béčková technologie nahradit pevný disk, situace je najednou zcela jiná.
Řeči o tisících přepsání jsou plané sliby, kterým se nelze než zasmát. Už proto, že mechanický disk jich vydrží nesrovnatelně víc. (Není to paradox?) A jestli stále ještě někdo tvrdí, že čipy v SSD jsou něco zcela jiného než flashdisk, pak asi jen věří pohádkám.
Já pohádkám nevěřím. A moc se těším na dobu, až budou SSD existovat. Zatím neexistují. To, co se prodává pod názvem SSD dnes, by zasloužilo zamést na smetiště dějin.
-
Lael Ophir (neregistrovaný)
RAID z HDD sice má slušné kontinuální čtení a zápis, ale nijak nepomáhá náhodnému čtení a zápisu. Přitom při interaktivní práci se systémem oceníte nejvíc právě to náhodné čtení. Kliknete na ikonu, a začnou se nahrávat spousty souborů (executable, knihovny, nastavení). HDD je v tu chvíli velmi pomalý, SSD naopak báječně rychlé. Další výhody SSD: mechamická odolnost (oceníte u notebooku), nízká spotřeba, nízká hmotnost. A problém s počtem zápisů? Pokud se takového problému vůbec dočkáte, tak prostě váš disk jednoho dne začne mít bad blocks. Jenže to uvidíte včas, a vždy se to bude týkat jen bloku, který právě zapisujete. Co už je úspěšně zapsané, to pak i přečtete. Naopak když odchází HDD, máte problémy se čtením kdysi úspěšně zapsaných dat.
USB flash disky mi zatím bez problému vydržely roky, a těch přepsání byla dlouhá řada. Jako FS používám FAT32 a NTFS.
-
Andrej Podzimek (neregistrovaný)
Jak už jsem psal, důvod k náhodnému čtení podle mě ve skutečnosti neexistuje.
a) binárky + knihovny + data pro GUI:
Tohle může zajistit vhodný preload mechanismus v distribuci už při startu systému, aby bylo vše k dispozici v cache v RAM. Dnešní RAM je tak levná, že je škoda ji nevyužít pořádně. To řeší veškeré klikání na ikony. Jasně, start je pak delší a otázka je, jak dobře je tohle použitelné na notebooku. Ale já notebook většinou uspávám, tedy data buď zůstanou v RAM, nebo se (při uspání na disk) načtou znovu efektivně a sekvenčně ze swapu. Myslím, že při dobré konfiguraci je velká RAM + pevný disk účelnější než SSD, hlavně proto, že RAM má mnohem širší možnosti využití.b) kompilace spousty malých zdrojáků:
Napřed se ovšem rozbalí tarball. Malé zdrojáky se efektivně a téměř sekvenčně zapíší na disk a navíc zůstanou v RAM. Tedy při kompilaci už se nic náhodně seekovat nemusí. Výstup kompilace se opět zapisuje efektivně standardními mechanismy filesystému.Nízká spotřeba, mechanická odolnost a nízká hmotnost jsou vlastnosti, na které se velmi těším. Jakmile budou SSD existovat, rozhodně si takové médium pořídím, právě pro tyto vlastnosti. Zatím ale SSD neexistují.
Podle mě se u SSD žádných bad blocks nedočkáte. Vady se projeví tak, že přístup k některým blokům bude trvat celé vteřiny. Nebude možné přečíst některé soubory a podivné půlhodinové prodlevy při startu systému rozhodně nejsou příjemným zážitkem. Notebook, na kterém jsem tohle viděl, rozhodně nebyl z nejlevnějších a rozhodně nepatřil mezi první modely s SSD.
Když odchází HDD, poznáte to s rozumným předstihem:
* podle počítadla realokovaných bloků ve S.M.A.R.T. (nenulové)
* podle toho, že SMART test (smartctl -t long) selžeKdyž odchází SSD, nepoznáte s rozumným předstihem prakticky nic.
Já jsem na flashdiscích používal kromě NTFS (s vypnutým indexováním, samozřejmě) především Reiser4, Btrfs a ZFS. Co do výkonu byl asi nejlepší ten první (ale taky toho umí mnohem méně než dva posledně jmenované). Bohužel životnost nikdy nebyla valná a vždy jsem se relativně brzy dostal do stavu, kdy se zapisuje rychlostí 3 kB/s a přečtení některých soubovů trvá desítky minut. Přitom se jednalo o řádově měsíc používání s občasnými zálohovacími operacemi typu hg pull; hg update -- tedy nic, coby přepisovalo všechny bloky.
-
Whill (neregistrovaný)
Ale no tak. SSD má sice své dětské nemoci, ale takový popis je maximálně tendenční, více k tomu snad ani není co. To RAID pole je sice super, ale na jeho schopnosti v sekvenčním čtení v praxi s*re pes. Pokud nekopíruju denně gigabajty filmů tam a zpět, je mi nějaký RAID z výkonnostního hlediska úplně na nic. Nejčastější operací je náhodné čtení malých bloků dat a to je to, co dnes brzdí jakýkoli počítač s HDD a ať má RAID jaký chce, nepomůže mu to nijak. Zde je SSD za všech okolností mnohonásobně rychlejší, ale to se jaksi taktně úplně zapomnělo zmínit, že? ... A přemýšlet kolikkrát zkompiluju jádro opravdu netřeba, ale dnes má holt každý tendenci SSD v různých článcích furt rozfrcávat a mnohdy s hromadou převzatých bludů odjinud a tak se vesele pletou pojmy s průjmy a vnikají různé za vlasy přitažené dojmy a obavy. Možná by obecně všem neškodilo méně nad tím laborovat a více to normálně používat.
No a ty flashky, to snad ne. 5 přepisů, no to určitě, proč ne hned dva třeba, to by bylo do té demagogie lepší číslo, ne? Mě ještě neodešla ani ta poslední reklamní (jiné jsem snad ani neměl). Karty do mobilu a MP3 to samé. Mám hromady SD karet do foťáku X krát přepisovaných a fungují jako nové (a ještě dlouho budou).
-
Andrej Podzimek (neregistrovaný)
Pokud chci rychlé čtení malých bloků, koupím si spoustu RAM (na žádném stroji nemám pod 8 GB) a zajistím si vhodný preload, který je v té či oné podobě dostupný v podstatě ve všech distribucích.
Neznám situaci, kdy by čtení malých bloků bylo potřeba neustále. Binárky a knihovny? Ty ošetří RAM a preload. A pokud jde o kompilaci, u které se čte spousta malých souborů, *napřed* se přece rozbalí archiv -- tedy všechny malé soubory se téměř sekvenčně zapíší na disk a především zůstanou i v RAM, protože jí je prostě dost. Takže ani tady není důvod ke čtení spousty malých bloků. Nějak mi tedy uniká důvod, proč mi má záležet na údajně rychlé odezvě SSD.
Odezva SSD je rychlá v prvních měsících. Jakmile se vyskytnou první vadné bloky (což na sebe nenechá dlouho čekat), nastane naprosté zoufalství s přístupovou dobou řádově desítek sekund k některým důležitým souborům. A nedá se s tím nic udělat, kromě vyhození SSD oknem. SSD tedy není za všech okolností rychlejší než disky...
Flashdisk mi už selhal tolikrát, že bych ho v podstatě nechtěl ani zadarmo jako reklamní předmět. A to jsem na něm nekompiloval kernel. :-) Stačí tam jen párkrát nakopírovat nějaký hodně košatý adresářový strom. Wear-leveling pak totálně selže a poškozené bloky způsobí, že se z toho nedá pořádně číst a rychlost zápisu klesne téměř na nulu. Jenže místo aby ten flashdisk nějak rozumně hlásil „ano, jsem v háji, reklamuj mě“, jen mlčí a neříká nic. Uživatel může například půl dne čekat a spekulovat, zda ta data ještě uvidí či nikoliv. Takovou technologii zkrátka používat nechci.
Karty ve foťáku v podstatě slouží k přidávání souborů velmi podobné velikosti, které se ve velké většině případů po přidání nepřepisují. Věřím, že u nich wear-leveling funguje o něco lépe a vydrží tedy déle.
-
Jsem prekvapen, ze tu nikdo nezminil wiper.sh z projektu hdparm:
http://sourceforge.net/projects/hdparm/files/
Jedna se o shellovy skript, ktery z filesystemu zjisti aktualne nealokovane bloky a ty pak vsechny najednou vyTRIMuje. Tento "manualni" pristup sice neni tak elegantni, jako discard, ale zase nema zadne negativni vedlejsi ucinky (zpomaleni). Funguje i na namontovanem fs, ale pro klid duse je nejjednodussi jednou za mesic nabootovat treba do Live CD z flashky, na kterou se prihodi wiper.sh a promaznout vsechny fs na SSD. -
LuKo (neregistrovaný)
Dobrý den,
v článku jsem se dočetl, že disk (teoreticky) vydrží 50 let neustálého zápisu. Avšak v jedné z diskuzí pod produktem na czc.cz jsem se dočetl, že někde zkoušeli dát SSD disk do zatíženého databázového serveru a disk vydržel jen 14 dní. Momentálně řeším problém s databází, kam mi každou vteřinu přichází cca 100 relativně malých záznamů, které se nijak dál nemodifikují, pouze se ukládají a následně podle potřeby čtou. Čtení však za mohutného chroupání stávajícího HDD trvá desítky vteřin. Jaký je Váš názor? Zachrání mě SSD disk jednak rychlostí přístupu k datům a jednak svou výdrží, aby neodešel po 2 měsících provozu? Díky. -
tyctor (neregistrovaný)
mne s povodnym mkfs z clanku nechcel bootovat kernel (3.0.6)
tu som nasiel volbu "stride":
http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux-E stride=128,stripe-width=128
zopakoval som cely postup a kernel nabootoval...
-
radun (neregistrovaný)
SSD mám skoro dva roky a už bych si na normální disk nejspíš nezvyk; trvalo mi to víc jak rok než jsem se ke koupi odhodlal -- pořád jsem se přesvědčoval v tom, že to nemá smysl, když ten notebookovej hdd je docela rychlej --, po instalaci jsem se musel trochu za to svoje konzervativní smýšlení stydět. Rychlost naběhnutí rázem spadla z jedné minuty na třicet vteřin, ale i výdrž notebooku se dostala ze čtyř a půl hodiny na dobu šesti hodin -- na stejnou dobu, jako když byl novej. Prostě jsem si chrochtal a jsem spokojen dodnes.
Jen to kryptování. Byl jsem zvyklý mít oddíl kryptovaný. Sice jsem si po koupi SSD říkal, že zas tak moc se nestane, když nebude, ale to jsem asi neměl, protože co čert nechtěl, po třech tejdnech jsem nes disk na reklamaci -- přesněji na výměnu samozřejmě i s daty jako emaily a některými hesly.
Nevíte někdo jestli už neexistuje nějaké rozumné řešení? -
zd.valek (neregistrovaný)
Myslím, že by zde mělo zaznít i jak je to s podporou TRIMu v jednotlivých systémech souborů. Ext4 to umí od jádra 2.6.33 mám dojem, btrfs to taky umí, ale co ostatní? ext3, ext2, vfat, ntfs-3g, ........
Na internetu člověk najde i deset let staré informace, je pak problém dohledat ty aktuální (vím, neumím moc hledat).
Napište kdo to ví, prosím.
