Solid-State Drive v openSUSE
Před časem mě oslovil jeden velký test SSD, který přinesl téměř šokující výsledky. Vítězný disk měl seek pod 0,15ms a rychlostí čtení přes 200MB/s konkuroval dvěma VelociRaptorům v RAID 0. Posledním faktorem byla relativně příznivá cena pod 4000 Kč s DPH za 30GB model a tak už nic nebránilo tomu nasadit ho jako systémový disk.
Jedná se o SSD OCZ Vertex Turbo Series 30GB 64MB Cache a protože u těchto MLC disků se maximální počet přepisů jedné buňky pohybuje v řádu statisíců, ukážeme si jak v openSUSE prodloužit jeho životnost s použitím správného nastavení souborového systému Ext3.
Disk se sice sám o sobě snaží pomocí technologie Wear levelling počet zápisů do stejné buňky velkou měrou eliminovat, přesto nesprávným nastavením filesystému se může jeho výkon a hlavně životnost rapidně snížit. Zde je několik možností jak tomu předejít:
1. Úprava fstab souboru
- filesystem table říká systému jak pracovat s diskovými oddíly a vysvětluje mu kam a jakým způsobem je má připojovat. Proto do /etc/fstab přidáme několik parametrů, které ovlivní chování systému vůči SSD:
- noatime - zakáže úpravu informací o posledním přístupu k souboru.
- nodiratime - zakáže úpravu informací o posledním přístupu ke složce.
- data=writeback - změní způsob zacházení se žurnálem souborového systému na rychlejší metodu.
- nobh - snaží se zabránit asociaci počátečních adres bufferu (pouze pro "writeback" mód).
výsledný zápis pak vypadá takto:
/dev/disk/by-id/ata-OCZ_VERTEX-TURBO_202B960A7RM94280ELSX-part1 / ext3 noatime,nodiratime,nobh,data=writeback 1 1
/dev/disk/by-id/ata-OCZ_VERTEX-TURBO_202B960A7RM94280ELSX-part2 /home ext3 noatime,nodiratime,nobh,data=writeback 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/disk/by-id/ata-WDC_WD3200KS-00PFB0_WD-WCAPD1646323-part1 /home/djs_core/data ext3 defaults 1 2
2. Použití parametru "noop" pro I/O scheduler
- ve výchozím režimu používá Linux elevator tak, aby optimalizoval čtení i zápis z klasické rotující diskové plotny. Protože SSD disky žádné pohyblivé části nemají, je tato funkce zbytečná a snižuje jeho výkon. Proto pokud máte v pc pouze SSD disk(y), můžete přidat parametr elevator=noop přímo do Grubu. V opačném případě je potřeba přidat tento parametr jen pro SSD, aby neovlivnil chování ostatních disků. Toho lze docílit přidáním příkazu:
echo noop > /sys/block/sda/queue/scheduler
do souboru:
/etc/init.d/boot.local
kde sda je disk, kterému chceme parametr přidat (může být sdb, sdc, ..., záleží na vašem zapojení a nastavení v BIOSu)
3. Použití tmpfs v RAM
- přesunem často zapisovaných systémových adresářů do virtuálního souborového systému tmpfs získáme jak vyšší výkon, tak zároveň ušetříme disk velkého množství zbytečných zápisů. Jednoduše do výše uvedeného souboru /etc/fstab přidáme několik nových řádků:
tmpfs /tmp tmpfs noatime 0 0
tmpfs /var/log tmpfs noatime 0 0
tmpfs /var/tmp tmpfs noatime 0 0
tímto přemístíme adresáře /tmp, /var/log a /var/tmp do RAM. Jedinou nevýhodou může být ztráta logů a dočasných souborů při restartu nebo vypnutí pc v těchto adresářích.
4. Pokud to jde, nepoužívejte SWAP oddíl
- pokud máte dostatečnou velikost RAM, není potřeba používat swap vůbec, případně vytvořte swapovací oddíl na jiném odkládacím disku. Pokud ani to není možné, alespoň snižte potřebu kernelu využívat swap pomocí příkazu:
sysctl -w vm.swappiness=10
5. Využívejte SSD jen jako systémový disk
- na ukládání osobních dat a multimédií (dokumenty, hudba, video, fotografie, atd.) je vhodnější klasický mechanický SATA disk (vzhledem k ceně za GB a životnosti). Díky tomu pak na operační systém, programy a hry v mnoha případech stačí 30GB disk.
6. Indexace
- také je dobré zvážit použití jakékoli služby používající indexaci beagle/tracker apod.
Závěr
- reálný výkon tohoto disku pak zjistíme pomocí programu hdparm příkazem:
hdparm -Tt /dev/sda
v mém případě výsledky dopadly takto:
Timing cached reads: 8794 MB in 2.00 seconds = 4400.30 MB/sec
Timing buffered disk reads: 528 MB in 3.01 seconds = 175.63 MB/sec
Osobní pocit z nárůstu celkového výkonu pc díky téměř nulovému seeku a velké rychlosti čtení disku je minimálně o 100% větší. Start openSUSE i s kompletně načteným grafickým prostředím Xfce je do 22s od inicializace BIOSu. Rychlost spouštění aplikací je téměř okamžitá (Firefox - 1s, Blender - 1s, GIMP - 2s, Ooo - 2s, ...). Hodně to připomíná práci s RAM diskem.
Někdo by mohl namítnout, že žurnálovací systém souborů není pro SSD zcela vhodný, ale po úpravě výše uvedených parametrů a přečtení tohoto článku možná změníte názor ;)
--
...do you want to make your dreams come true? Wake up!
http://www.djscore.org




read-modify-write
Napsal uživatel Neznámý (neověřeno) dne 10. Září 2009.http://www.linuxfoundation.org/news-media/blogs/browse/2009/02/aligning-filesystems-ssd’s-erase-block-size
Pekne shrnuti. Jenom
Napsal uživatel limit_false (neověřeno) dne 10. Září 2009.Pekne shrnuti.
Jenom nerozumim proc nepouzit nejaky log-structured filesystem, treba NILFS2? Protoze seeky jsou velice kratke, pomuze to zivotnosti disku, plus maji nejake dalsi vyhody - podpora snapshotu primo ve FS bez nutnosti preruseni operaci, jednodussi recovery po crashi systemu (protoze data se neprepisuji, nybrz appenduji).
Mozna by nebylo spatny srovnat rychlost ext3 vs NILFS2. Podle benchmarku uvedenych v tomhle clanku NILFS2 vypada hodne dobre: http://www.linux-mag.com/id/7345/2/
NILFS2 vypadá dobře, pokud
Napsal uživatel djs_core dne 10. Září 2009.NILFS2 vypadá dobře, pokud bude čas a nové jádro vyzkouším ho a doplním článek o výsledky. Díky za tip ;)
--
...do you want to make your dreams come true? Wake up!
http://www.djscore.org
NILFS2
Napsal uživatel tricqster (neověřeno) dne 29. Listopad 2009.wow, to by bolo super, neviem sa dockat. :)
nejaky predpokladany termin? a bude aj navod? pretoze NILFS chcem skusit aj ja, ale zatial neviem ako.
NILFS2 je pro openSUSE
Napsal uživatel djs_core dne 29. Listopad 2009.NILFS2 je pro openSUSE dostupný jako modul pro kernel v repozitáři: http://download.opensuse.org/repositories/filesystems/
Nicméně po dlouhém rozhodování pro a proti, v tuto chvíli zatím zůstanu u Ext4.
--
...do you want to make your dreams come true? Wake up!
http://www.djscore.org
Diky
Napsal uživatel strnous dne 09. Září 2009.Strucne, jasne a uzitecne. Primouval bych se za vlozeni i do Wiki.
Snad je jedina poznamka k umisteni /var/log na tmpfs, ktere lze doporucit spise pro odladene systemy s minimem zasahu, kdy nehrozi potreba pripadneho debugovani problemu a uzitecnost logu zde ulozenych je tedy dramaticky nizsi.
Michal Strnad
/var/log z tmpfs na disk
Napsal uživatel tuxmartin (neověřeno) dne 10. Září 2009.Nebo /var/log z tmpfs kazdych treba 5 minut a pri rebootu zapsat na disk.
Disk by se tak nenicil a je docela pravdepodobne, ze clovek neprijde o vsechny logy.
Souhlasím, myslel jsem, že
Napsal uživatel djs_core dne 09. Září 2009.Souhlasím,
myslel jsem, že to vystihne tato věta:
Jedinou nevýhodou může být ztráta logů a dočasných souborů při restartu nebo vypnutí pc v těchto adresářích.
Každopádně, díky za doplnění ;)
--
...do you want to make your dreams come true? Wake up!
http://www.djscore.org