Hraní s malým serverem IV. - souborové systémy (diskuse)

[Heron]

Moc pěkné. Díky.

Poznámky:

VFAT a NTFS jsi tam dal předpokládám jen pro legraci, nemyslíš to s tím vážně?

K tomu BTRFS. Nedává příliš smysl používat tento FS ve stejném režimu jako ty ostatní fs (tedy uložit data do jednoho systému souborů), jako ty ostatní (ext, xfs, jfs apod.). Naopak, pokud někdo využije ty jeho vlastnosti vycházející z cow (snapshoty), komprese apod., tak zase nepředstavuje až takový problém, že se tam toho vejde o něco méně a trochu víc to sežere cpu.

Ještě k tomuto, z dlouhodobého hlediska opravdu není dobré zaplňovat fs na 99.9%. Extrémně narůstá externí fragmentace. Je lepší nechat FS trochu dýchat -- doporučených 20% volného je dnes asi trochu plýtvání, ale prostě tak nějak.

[Šangala]

Není zač, je to super zábava
S NTFS a vfat jsem vůbec nepočítal, ale na základě tohoto, aniž bych se cítil tím „kdo “ se toho měl chytit, jsem je tam přihodil, ale byl/je to pěkný opruz, protože jsem si neuvědomil, že na fat-ku neuložím 40GiB do jednoho souboru, tak jsem musel ten druhý test upravit (po těch 1GiB souborech) a NTFS se vytváří hnusně dlouho - 285 sec následován ext3 trvajícím jen 6.2 sec. A vážně to s nimi opravdu nemyslím :).
Nicméne mn to nic nestojí, mám na všechny ny ty testy „řešení“ a je to jen o tom mít správné balíčky a dopsat na jedno místo jen vfat či ntfs -c 4096 a je to tam.

[Aleš Kapica]

Autor blogpostu dosud ne-po-cho-pil, že u souborového systému je v dnešní době rychlost čtení a zápisu víceméně marginální hodnotící prvek. Ale on na to časem přijde.

[Šangala]

A co tě k tomu závěru vede (teda k obou závěrům)?

[Aleš Kapica]

Co mě k tomu vede? Dnešní rychlosti pevných disků jsou úplně jinde než před lety. Rozdíly v rychlostech mezi jednotlivými FS nejsou tak markatní, aby stálo za to je vůbec brát v potaz. Jestli kopíruješ data půl hodiny, nebo tři čtvrtě, je už celkem jedno. Mnohem důležitější je jak se daný FS vypořádá s nestandardní situací (chyby na pevném disku), výpadkem napájení, nebo kolapsem stroje. Až při spuštění stroje, během kontroly souborového systému poznáš co je nekonečno a když se přitom objeví nějaká chyba i co znamená, když se řekne, že někomu lepí u zadku. Tyhle pocity jsem zatím zažil ve větší míře pouze u souborových systémů, které v tvém blogpostu vycházejí dobře.

Dlouhé roky jsem k naprosté spokojenosti používal reiserfs, ale pro současné velké disky s ohromným množstvím dat se už nehodí.

[Šangala]

To je ten druhý závěr, k němu můžu dát toto:
Svět je barevnější. Ještě nedávno jsme používali soft., který zpracovával velké množství dat, i velká mezi data generoval a protože to při větších věcech šlo nad rámec běžně používané RAM, bylo/je to řešené tak, že se vše neustále píše na disk a de-facto rychlost výpočtu je nakonec dána rychlostí úložiště a je sakra rozdíl jestli se má na každý výpočet čekat 10 nebo 20 minut (vzal jsem teoretický největší rozdíl, aby to bylo do očí, ale i 10 a 12 min je obrovský rozdíl při práci) a při tom je každému putna co se pak s těmi daty stane - když se to po..re, tak se znovuvytvoří FS a je to.
A ten první závěr?

PS: A díky za informaci kdy konečně poznám nekonečno…, zatím mám jen informace, že je modré a, že je tak velké, že velikost sama ve srovnání s ním vypadá úplně nicotná.

[Miloslav Ponkrác]

Plný souhlas s tím, že rychlost fs považuji za merginální.

Většinou ty skutečně hezké vlastnosti filesystémů, tedy odolnost, spolehlivost, a další jsou v přímé opozici proti rychlosti.

Ale ony jsou věci, které se snadno testují – rychlost něčeho. U kompů a operačních systémů zase do blba lidi testují za jak rychle to nabootuje, což je nezajímavé.

Základní vlastností filesystémů je spolehlivě udržet data.

V řadě testů získám nejrychlejší filesystém tím, že budu kopírovat do /dev/null a test to ani nepozná. Můžu si vytvořit i „best filesystem ever“, který nebude potřebovat ani disk. Zápis bude zahazovat data. A čtení bude produktovat nekonečnou řadu nul. Tento filesystém ve většině rychlostních bencharků s přehledem rychlostně zvítězí a bude jednička.

Benchmarkisté zapomínají, že filesystém má primárně držet data a ostatní je sekundární. Tuhle funkci ale neotestují.

[Šangala]

jak rychle to nabootuje - pro spoustu lidí s NTB velmi důležitý údaj.

Základní vlastností filesystémů - je pro některé aplikací důležité rychle zapsat a rychle přečíst, jejich udržení je nedůležité, proto se používají i RAM disky nebo třeba RAID0 (tyto aplikace jsou sice v menšině, ale existují - pominuli, že v dnešní době je to pomalu už požadavek většiny desktopů, jen na to vlastnící ještě nepřišli).

Ani v jednom testu jsem při zápisu nepoužil /dev/zero, ale náhodná data a při čtení není problém to posílat do /dev/null, to už simuluje zpracování dat tedy aplikaci, tím se právě pozná jak rychle „to“ dáva - je čteno (jinak o žádném čtení tam zmínka není).

Protože je to, tady tak jsem asi taky „benchmarkista“, tak si myslím, že jsem na nic nezapomněl, že je FS na správu/uložení dat je dáno už definicí FS, pokud ji nesplňuje není to FS. Implementace mají různé parametry, a jeden z parametrů je i rychlost, takže je logické, že se také testuje, někoho nezajímá rychlost a někoho nezajímá pohodlí/funkce, někomu je putna kolik se tam toho vejde, někomu je putna jak to zatěžuje CPU a někoho nezajímá spolehlivost (protože spolehlivost většiny FS je daleko za hranicí potřeby).
Testování „funkce držení dat“ dat provede každý test (data se zapíší a data se přečtou).

A k datům obecně a osobní preferenci.
Na desktopu mě zajímá rychlost (protože spolehlivost všech FS je dostatečná), proto mám taky SSD, nebo lze použít i SSD v RAID0, a na spoustě pracovních desktopů jsou přesně takové priority.
Na serveru mě také obvykle nezajímá rychlost, ale spolehlivost či pohodlnost (ale jsou i jiné servery, kde jsou priority obrácené). No a ke spolehlivosti, třeba „křičení“ o experimentu při vytváření FS v někom (i ve mně) neposiluje důvěru v bezpečné uchování dat, takže ten kdo se rozhodne pro takový FS (btrfs), se nerozhodl k jeho použití z důvodů jistoty uchování dat, ale spíše pohodlnosti a funkcionalitě FS. Každý máme své favority (například moji jsou xfs a ext4).

[Aleš Kapica]

..protože spolehlivost všech FS je dostatečná

Kéž bys tak měl pravdu..

[Šangala]

Dobře, a co tě vede k tomu, že není dostatečná, nebo jinak, vyjádři rozdíl spolehlivosti mezi jednotlivými FS.

[Pindal]

Spolehlivost jakéhokoliv filesystému je tak vysoká jak spolehlivé máte zálohy :)

[Šangala]

Tedy typ FS na to nemá vliv .

[psc]

jak rychle to nabootuje - pro spoustu lidí s NTB velmi důležitý údaj.

Jen pro těch pár zoufalců, co ještě neobjevili nebo jim nefunguje hibernace (uspání na disk) :)

[Šangala]

A co ti zoufalci, kteří to objevili a co čekají déle na obnovu z hibernace, než je start OS - stejně tak při vypínání (a třeba ani o tom neví že to tak je).
Na to navazují zoufalci co mají 16GiB RAM a používají ji, power off je 5sec místo čekání na hibernaci, a pak to probouzení…
Pak další zoufalci co používají více OS.
A na konec tady máme zoufalce, co šifrují a chtějí být v klidu.
Jo zoufalství má spoustu podob .

[psc]

Jen dodám, že si k času startu OS připočtěte čas spouštění všech aplikací a případně i jejich rozmístění, otevření souborů se kterýma se pracovalo, nastavení situace kde jsme posledně skončili a pokud možno n nic nezapomenout + opruz s tím spojený

Čemu vadí více OS ?

Jo data na swap oddílu jsou přístupná, ale to je na zvážení každého soudruha jak moc paranoidní vs. línej bude. Fyzickej přístup k počítači i jeho uživateli je už tak jako tak průser Moje paranoia končí na hranici síťové zásuvky..

[psc]

Heh, asi si udělám ten swap šifrovanej. Třeba podle tohodle návodu. Asi jsem se nakazil

[Šangala]

Pokud chceš být opravdu v klidu (a data máš šifrovaná), tak swap musí být šifrovaný taky (nebo ho nemít), a ano pokud chceš hibernovat do šifrovaného swapu, musíš si to nachystat, zatím nevím o tom, že by to nějaká distribuce sama nastavila.

[Heron]

Jen dodám, že si k času startu OS připočtěte čas spouštění všech aplikací a případně i jejich rozmístění, otevření souborů se kterýma se pracovalo, nastavení situace kde jsme posledně skončili a pokud možno n nic nezapomenout + opruz s tím spojený

Jsem možná zoufalec, ale vzhledem k tomu, že čím dál tím víc app se sami od sebe otevírají přesně v tom stavu, v jakém jsem je zanechal, tak tento argument platí také čím dál tím méně. S2D nepoužívám (pravděpodobně by se mi to nevlezlo na disk), občas S2R.

[Šangala]

Kdepak, jak je i níže napsané, aplikace se mají už otvírat tam kde chci (a to i většina i dělá, a na spoustu mám pravidla) a na specifické činnosti jedno-klikem jich otevřu třeba 6 na správných plochách ve správných pozicích.

Čemu vadí více OS - minimálně tomu, že máte společná data (pokud to lze, tak se musí správně nastavit před/po hibernační skripty, jejichž zkalmání m;že mít fatální následky). Nebo že třeba některé OS přepnou něco v BIOS-u.

Jo data na swap oddílu jsou přístupná - ne, je přístupné všechno (dešifrovací klíč je dostupný).
Fyzický přístup k vypnutému počítači se šifrovaným diskem, s dobrým heslem není průser - data jsou v klidu nikdo je nepřečte.

[Heron]

Na to navazují zoufalci co mají 16GiB RAM

Zcela úplně off topic, ale netuší někdo, proč MS W7 po přidání RAM z 4GB na 16GB (na NTB) se vypínají asi tak 20s? Stejně tak na 32GB RAM na desktopu, čekám no skoro těch 40s, než se to vypne. Zdá se, že čím víc RAM ty Widle mají, tak tím je tam cosi na ukončení pomalejší (asi lineárně). Swap samozřejmně nemám. Debian je dole hned, tomu je ta velikost šumák.

[Šangala]

Čím větší RAM a čím větší GRAM tím pomalejší, to je asi „by design“, možná to nějak souvisí z virtuálním mapováním a rezervování adres. Navíc mám podezření, že vše co je v cache se ověřuje při ukončení proti disku. Mám jen 8GiB (swap samozřejmě mám :)) na NTB kde to střídám, a jak start tak vypínání je delší na W7 a stále (jak je zvykem) čas roste a i bez aktualizací, a je to pokaždé jiný čas, asi dle fází měsíce a vlhkosti vzduchu. Debian jde nahoru (od výběru v GRUB) za 12 sec (po přihlašovací obrazovku) + 6(2) sec start desktopu (ale v čase je zahrnuta i 4 sekundová animace, kterou nutně potřebuji, takže fakticky jsou to 2 sec) a dolu za 7 sec.

[Šangala]

Jo a o tom btrfs, se snažím nenápadně naznačovat, že jeho výhody jsou jinde. Plný FS není OK, ale zjisti kolik se tam opravdu vejde, musíš je tam prostě zapsat, a například btrfs je už plný, ale přes free hlásí relativně hodně volných bloků, ale jakýkoliv zápis už zklame.

[Aleš Kapica]

No, Btrfs má řadu vychytávak a jednou z nich je balancing. V případě nouze můžeš dodatečně data překomprimovat a tím získáš volné místo. Naprosto super je snapshotování. Oproti klasickým zálohám je to mnohem rychlejší proces, který nemá žádný vliv na rychlost FS. Co používám Btrfs na velké disky, tak jsem ušetřil hromadu času jenom na pitomé kontrole FS po nekorektním vypnutí stroje.

[Šangala]

Ano komprimaci má a na různých jádru různou nebo neaktivní „by default“ , a další možnosti, a to co popisuješ nejsou zálohy, ale spíš verzování.

[Aleš Kapica]

Viz část věnovanou kompresi a balancování. Pokud jde o snapshotování - tradiční zálohování je již v poslední době zcela mimo realitu. Mnohem praktičtější a v konečném důsledku i použitelnější je právě využití on-line replikovaného diskového prostoru, zálohované na diskové pole do pravidelně snapshotovaných adresářů.

Zrovna dnes jsem řešil věc, která by byla při klasických zálohách velmi zdlouhavá. Údajně zmizel soubor z jednoho virtuálního stroje. Byl na server uploadován, nebo nebyl? A pokud ano, tak proč zmizel? V živém adresáři nebyl, ale jak se ukázalo - v části snapshotů zálohovacího adresáře ano. Zhruba během minuty jsem tak věděl kdy se tam objevil a kdy pravděpodobně zmizel, takže jsme se mohli soustředit rovnou na to proč zmizel.

[Šangala]

Nevím proč mi to odkazuješ…
Ano pokud snapshoty někam přenášíš/replikuješ, tak se už jedná o zálohování, ale prosté vytvoření snapshot-u je jen verzování. A pokud stačí mít data jen redundatní na dvou místech a máš ta místa geograficky oddělená, tak to může být vyhovující způsob zálohování.
A co se vyhledání týče, tak jsem schopen dohledat v řádu sekund až minut i data která jsou zálohována jen třeba do gzip-u bez použití jakéhokoliv nástroje, a stejně tak to umí i sofistikovaný software, to je jeden se základních předpokladů dobře nastaveného zálohování. Jaké se k tomu použijí prostředky není až tak důležité.
O realitě jen vím, že je veškerá připojena k piškotovému dortu… :)

[Aleš Kapica]

To je jednoduché - protože se ti to může někdy hodit 8-) A pokud ne tobě, tak někomu jinému.

Jinak pokud ti jde především o rychlost při zápisu a čtení, tak nemá smysl řešit FS, protože úzké hrdlo je rotační HDD sám o sobě. V takovém případě jedině SSD a nad tím rovnou ext4, který se nezdržuje s kompresí. Případný RAID by ti dělal jen zbytečnou režii navíc. Systémová data a výsledky bych však raději ukládal jinam.

[Šangala]

Tak tedy dík (i za ostatní).
Pokud dáš pomalý FS a rychlý FS na SSD bude, ten rychlý stále rychlejší, takže to má smysl stále smysl řešit. O RAIDU jsem nic nepsal, ale RAID0 to celkem jistě zrychlí.

[Aleš Kapica]

Víš, podobné hrátky jako ty jsem absolvoval zhruba měsíc před tebou. Viz můj blogpost NFS sync a Btrfs. V něm ale nenajdeš žádné tabulky a grafy, protože jak už jsem zmínil - úzké hrdlo je především rotační disk. RAID to může (ale nemusí) trochu vylepšit. Ovšem rozhodně ne RAID0. Ten je podle mne (sám o sobě) v době 4TB disků pasé, protože představuje reálné riziko ztráty dat.

[Šangala]

Nevím co ti na to má říct, snad „šířeji a barevněji“.
Rotační disk a FS nesjou vedle sebe, ale za sebou a pokud je rozdíl ve výkonu FS 10 %, prostě tam stále lze získat 10%.
A věř mi RAID0 je dobrá věc.

[Heron]

Nooooo, to není tak úplně...

Pro SSD s miliony IOPS (ano, domů si to ještě nějaký ten pátek nikdo z nás nepořídí), tak tam jsou úzkým hrdlem právě současné FS, které pořád jaksi stále počítají s tím, že se pod nimi cosi točí. Takže FS bude nutno přepsat (napsat nové), tak, že se odprostí od optimalizací pro HDD a naopak se přichystají na obrovské počty paralelních operací.

[Aleš Kapica]

Jo. V tom s tebou souhlasím. Zrovna Btrfs se hodí víc pro rotační disky. Koncept tzv. "tančících" stromů, se totiž podle mě zrovna pro SSD moc nehodí. Používám Btrfs jak nad rotačními disky, tak i experimentálně nad SSD. A totéž platí i pro reiserfs. FAT a NTFS nepovažuji vůbec za smysluplné FS, ale ext systémy svou koncepcí vyhovují principu SSD lépe.

Otázkou ovšem je, jak tomu bude do budoucna, protože spoustu věcí u SSD začíná řešit firmware, takže některé optimalizace souborových systémů pro použití s SSD disky ztrácejí pozvolna smysl. Bohužel takový je trend - optimalizovat firmware pro použití SSD a hybridních disků v systémech, co mají "hloupé" FS.

[Luk]

F2FS Výsledky hovoří celkem jasně.

[Šangala]

Opravička místo free mělo být df.

[Aleš Kapica]

Jen bych doplnil údaje pro moje pole. FS Btrfs, velikost 3,7TB, volných 132GB (zaplněno 97%). Plán - nahradit 2TB za 4TB disky, které jsou zatím nechutně drahé. Pak přejít na Btrfs v módu raid6. Data by už přibývat neměly, takže volná kapacita poslouží pro pravidelné snapshoty.

[psc]

Pěkné, muselo to dát celkem práci. Nechi rýpat, jen příště prosím dodržovat pořadí v grafech v průběhu celého článku.
Díky

[Šangala]

Ani to moc práce nebylo, jen to pustím, možná ty grafy pak učesat nebo vytvořit, ale jak je mám tak při opakování (to je jediný zádrhel, většinou na něco poprvé/podruhé… zapomenu nebo přehlídnu) je to OK, bo si generuji výstup a do Calc-u to načítám jako linkovaný sešit, takže se jen dá aktualizovat linkovaná data…
Ad. pořadí (rýpání je motor pokroku…), každý blok (test) má jedno pořadí a to vždy dle prvního grafu (tedy toho, co jsem chtěl primárně zjistit), přišlo mi to tak správně, možná není, ale jinak bych to musel nechat „bez pořadí“ a mám rád to rád hezky poskládané…