SSD a výběr vhodného souborového systému

5.3.2009 23:30 | Přečteno: 1990× | Diskuze | poslední úprava: 5.3.2009 23:41

Ahoj, chystám se koupit Asus EEE PC 900A, který používá 16GB SSD. Uvažuji o vhodném souborovém systému aby se SSD moc neopotřebovával. Notebook bude sloužit jako lepší konzole pro SSH a web, když jsem na cestách. Sice mám "dospělý" notebook, ale ten je velký a bojím se o něj - obsahuje moc citlivých dat, i když jsou šifrovaný, nemusím je tahat všude.

Vím, že flash disky postupně umřou na příliš velký počet zápisů na jedno místo. Proto taky existují souborové systémy jako je jffs2 nebo ubifs, které je ale možné použít jen v případě přímého přístupu k paměti. SSD disky ovšem přímý přístup k paměti neumožňují a dané souborové systémy pro ně nemají smysl.

Po přečtení článku na CDR o SSD a jejich opotřebovávání jsem dospěl k závěru, že asi na disk vrazím ext2, budu ho připojovat jen pro čtení a vše co se zapisuje budu strkat na SD kartu (dočasné soubory prohlížeče, nastavení WM a podobně). Protože bude mít počítač 1GiB RAM, strčím temp do RAMky. SD karta je levná a vyměnitelná.

Prosím majitele SSD případně rovnou EEEčka o informaci jestli a jak řešili výběr soubrového systému. Máte někdo zkušenost s šifrováním disků/SD karet na stroji s CPU Intel Atom? Jde mi o to jestli je to aspoň trochu použitelné. Zajímají mě praktické informace, ale i teoretické nápady Dík.

PS: jak vůbec řeší velcí výrobci HW (SUN, EMC a podobné firmy) opotřebení SSD v případě masivních zápisů, když nabízejí tyto disky pro databázové servery/disková pole?        

Komentáře

[Nicky726]

Taky by mě zajímalo...

Četl jsem, že btrfs by měl mít režim pro SSD.

[Zdeněk Burda]

Koukal jsem na něj, ale zatím o nasazení neuvažuji (není stabilní a prověřený - v tomto směru jsem docela konzarva) Není mi jasné, jak by mohl obejít tu debilní logiku zadrátovanou přímo v SSD.

[grim]

>> Notebook bude sloužit jako lepší konzole pro SSH a web, když jsem na cestách.

Proc teda neuvazujes o nasazeni btrfs? V tak spatnem stavu asi nebude, aby te nechal ve stychu. A i kdyby nahodou, prijdes jenom o par bookmarku apod a to se da resit napr pomoci Slaxu (nebo jineho live-cd/flash) umisteneho na stejne flashce, kam bys ukladal docasne soubory. (Tj nemusis nosit nic navic, obsazovat dalsi USB apod.)

 

[Zdeněk Burda]

Jak jsem psal, jsem trochu konzervativní. Notebook bude pracovní nástroj a nechci se pouštět do podobných experimentů pokud nemají nějaký významný přínos a v btrfs ho nevidím.

[Shadow]

On je hlavně problém v tom, že různé flash paměti mají různý wear leveling (některé ho nemají vůbec, jiné ho mají tak aktivní, že ve výsledku natolik zfragmentuje diskový prostor, že se veškeré operace drasticky zpomalí a pomůže jen ATA SECURITY ERASE). Navíc u většiny flash pamětí se člověk nedostane k takovým věcem jako specifikace wear levelingu nebo třeba taková základní věc jako velikost erase bloku. A jak se bude takový systém chovat v situaci, kdy bude de facto dělat druhý wear leveling? Neudělá pak na takovém médiu ještě větší maglajz?

[Grunt]

yaffs? A vůbec.

[Zdeněk Burda]

Četl jsi celý text případně i ten odkazovaný článek na CDR?

SSD disky mají uvnitř na pevno zadrátovnou logiku, kterou (pravděpodobně) nelze z venku ovlivnit - standardní souborové systémy používané na klasické flash disky s raw přístupem nelze efektivně použít (pokud mě někdo přesvědčíte o opaku, budu jen rád).

[pht]

Ovšem ta logika by měla poskytovat nějaké rozptýlení zátěže napříč všemi buňkami, i když máte opakované přístupy na jeden blok. Takže žurnálu bych se nebál, spíše se podívejte třeba na zarovnání bloků vůči buňkám.

[Grunt]

Četl jsi celý text případně i ten odkazovaný článek na CDR?

Abych pravdu řekl tak ne, ale Vy jste na tom pravděpodobně stejně, protože mimo jiné jsou v tom odkazu nějaké souborové systémy určené pro SSD. Kdyby jste se doklikal k Flash file system, tak by jste si třeba mohl přečíst, že pro SSD je doporučen mimo jiné FS od Sunu ZFS a pod tím vypsána kopa funkcí, které ani nechci vědět jak fungují.(To samé je doporučováno v samotném článku o SSD discích) Osobně dost dobře nechápu o co Vám vlastně jde. Pokud o minimalizování zápisů na ten SSD, tak se doporučuji zajímat o cache writeback. Normálně se dá nastavit čas v /proc po kterém se budou zapisovat data z cache v paměti zpět na uložiště. Docela bych se divil, kdyby někdo neudělal ugly hack na úplné vypnutí této funkce a jediný způsob jak zapsat data na disk by byl ručním zasláním synchronizačního příkazu(příkaz sync, třeba před vypnutím počítače).

[Grunt]

A nebo vůbec můžete používat ramfs. Pak mi ale nějak uniká smysl uložiště.

[Zdeněk Burda]

Četl jsem toho dost, i tu odkazovanou stránku. K odkazované stránce o FFS jsem se doklikal, ale neviděl jsem tam nic relevantního. TrueFFS a ExtremeFFS mi nepřipadly jako vhodné souborové systémy pro mé nasazení.

ZFS je zajímavý souborový systém, ale myslím, že v Linuxu (a ještě na root) to nebude to pravé.

[Shadow]

Tak, mám EEE 701čku, kde jsem na SSD vrazil nešifrovaný systém a ext3 s použitím volby commit, abych těmi zápisy do žurnálu moc nepotřebovával SSD (SSD disky mají wear leveling, takže to takový problém není). Zkoušel jsem i ext2, ale zavrhl jsem jej po jednom zamrznutí Éčka, kdy mi pak z filesystému zmizelo několik souborů (mezi tím i některé binárky), takže ext2 ano, ale spíše jen read-only nebo se ujistit, že systém nezamrzne a vždy bude korektně ukončen.

Šifruji 16GB SDHC kartu, a tam mám opět ext3. Dočetl jsem se, že s jistou pravděpodobností má ta příslušná karta též wear leveling, tak doufám, že je to pravda. Jinak zajištění konzistence dat při výpadcích je pro mne podstatnější než jednou za uherák koupit novou SDHC kartu. Šifrování běží v pohodě, použitelné to je. A vaše Éčko bude podstatně méně výkonnější než to, které mám já. Pokud je to možné, doporučuji šifrovat spíše /home (samozřejmě i swap, pokud je použit, a /tmp na tmpfs) a root nechat nešifrovaný. Je to o něco rychlejší. Ale asi nijak dramaticky ap okud se obáváte opakovaného přístupu útočníka k vašemu laptopu (a související nahrání rootkitu), klidně šifrujte i root, neměla by to být nějak extrémně velká brzda.

Samozřejmě, tmpfs na /tmp, pokud chcete root read only, tak dle potřeby i /var/log, /var/tmp (nejlépe symlink /var/tmp -> /tmp), /var/lock, /var/run, apod., lze omezit maximální velikost daného tmpfs parametrem size, ale to asi víte. V routeru mám CF kartu, kde je Debian a všechny souborové systémy z CF se mountují pouze read-only (dá se tak i snadno dělat upgrade přes síť, prostě přepíšu celou kartu a rebootnu). Pokud budete dělat něco takového, bude třeba nějak vyřešit /etc/mtab, což jsem já vyřešil symlinkem na /proc/mounts. Není to čisté řešení, ale zatím to funguje. Detaily jsem stručně popsal v blogu (mimochodem, web běží u vás).

Díval jsem se také na aufs jako nástupce unionu, v Debianu jsou balíky i návody, ale nakonec jsem do toho nešel. V případě routeru jsem šel cestou nejmenšího odporu, tedy mountování read only a na ostatní je tmpfs s omezením velikosti (málo ramky, žádný swap).

[Kvakor]

Pouzivam podobne reseni v HTPC (jen misto CF karty je tam IDE SSD modul), ale pri mensich upravach premounotvavam na r/w, upravim a zase zpet na r/o.

Mimo rozdelovani zapisu na urovni filesystemu (aufs, unionfs) je to jeste mozne delat na urovni blokoveho zarizeni - bud pres devmapper, nepo pres cowloop. Druhe ma tu vyhodu, ze na drzeni zmen staci "deravy" (sparse) soubor, kdezto devmapper potrebuje proste dve stejne velka blokova zarizeni (ale za to je rychlejsi a je v jadre uz od 2.6).

[Shadow]

Zajímavé, díky za tip.

[Zdeněk Burda]

Blog přečtu, ro root fs jsem už párkrát nastavoval, takže to zvládnu Pokud nenajdu lepšířešení, tak asi všechny zápisy skutečně nasměruju na SD kartu. Až bude vyřešeno, tak to někam sepíšu.

[cthulhu]

SUN/EMC je možná nabízí, otázkou je jejich aktuální prodejnost, současná cena FC disků je již tak dost masakrozní. K vylepšování počtu přepisů a optimalizacím dochází na obou frontách jak u vendora disků, tak u filesystemu (ZFS), pomocí ZFS checksumů se navíc předejde hodně nepříjemnostem. Použití SSD může být rozumným kompromisem cena/výkon pouze jako ZFS cache (L2ARC/ZIL) a výsledky - zdá se - nejsou vůbec špatné. viz. např.  blogs.sun.com/brendan/entry/test.

[cthulhu]

nicméně - člověk míní, krize mění. současný trend je naprosto opačný a místo hi-end hraček za šílené peníze (což SSD - u serverů se bavíme  předpokládám o SLC technologii - stále je) se dost často použije raději hromada low-end SATA disků..

[bubak]

Dej /tmp a ostatni adresare do ramky (tmpfs).

[radekkk]

na notebooku na SSD Transcend 32GB používám ext2 a no problemo, je to svižný. já bych tohle moc neřešil...

[a7dfa]

Ext4 udajne umi fungovat i bez zurnalu, zkousel to nekdo?

[Tom K]

Umi, funguje, je vyrazne rychlejsi (v metadata operacich). Nechtel bych videt, co se stane az jednou spadne napajeni/jado/neco_jineho, takze radeji se zurnalem.

[filbar]

Já používám Fedoru 10 s šifrovaným ext3 a jede mi to celkem v pohodě až na pomalé zápisy při aktualizacích a swap samozřejmě nepoužívám.

[Jardík]

SSDéčka nepodporují DMA? To musí být strašně pomalý hnus, zkoušel na tom někdo FullHD film? Mně nestíhá procesor ani s DMA, natož bez něj.

[Grunt]

SSDéčka nepodporují DMA?

Jaký by k tomu měly důvod?

[Jardík]

No já nevím, autor v zápisku psal:

SSD disky ovšem přímý přístup k paměti neumožňují a dané souborové systémy pro ně nemají smysl.

A nebo jsem blbej a autor tím myslel něco jiného (?).

[Jendа]

IMHO se tím přímým přístupem do paměti myslí přímo přístup k buňkám SSD, tzn. bez interní implementace wear-levelingu...

[Jardík]

Aha

[Zdeněk Burda]

Přesně tak, měl jsem rovnou napsat jaká paměť

[Kvakor]

Nove ho podporuju, DMA je jen otazka radice, ne media. Jak SSD umi cist rychleji nez 16MB/s (limit PIO4), tak urcite podporuje DMA.

[Miloslav Ponkrác]

Mám pocit, že u SSD je problém snad i v tom, že kernel na to není moc připraven. Že situace, kdy každý disk je hloupý souvislý blok sektorů bez nějakých dalších vlastností není příliš ideální. To je problém všech dnešních os.

Zatím SSD různě kamufluje a uhýbá tomu blbému požadavku, že se má tvářit jako magnetický disk. Jeho řadič se snaží různě emulovat vlastnosti disku, zároveň trochu kešovat pro SSD většinou často zcela nevhodné požadavky z kernelu, zároveň přemapovávat zápisy tak, aby nebyly často na jednom místě.

Podle mého je téměř jedno, co tam dáte za fs, protože kombinace kernel + řadič SSD + SSD z toho stejně udělá paskvil. Možná, že trojice fat/fat32/exfat je zcela nejvhodnější už proto, že řadič s tímto fs počítá a vše se projektuje na tyto fs.

Dokud nebude SSD řadič téměř holý a dokud kernel nebude mít překopány přístupy ke storage, tak bych z toho nedělal vědu, protože naprosto jakýkoli fs nic moc nezlepší. Kernel stejně bude házet na SSD nevhodné požadavky a řadič se bude snažit z toho něco udělat.