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

4.4.2013 16:37 | Přečteno: 1403× | LittleServer |

Další hrátka je, kolik lze na souborový systém zapsat dat, jak „surových“, tak v drobné struktuře. A také jak to s „neuklízením“ meta-dat.

Pro všechny testy souborové systému (dále jen FS) bylo použito toto nastavení:

ext3     -b 4096
ext4     -b 4096
xfs      -b 'size=4096'
btrfs    -s 4096
reiserfs -b 4096 -q
jfs      -q #z man-u: „The default block size is 4096.“ 
ntfs     -c 4096
vfat     

U vfat jsem nepoužil '-S 4096', je to trochu nefér, ale obvykle se to nepřestavuje a bylo by to moc „špatné“, některé hodnoty uvedu v textu.
Byl použit RAID10 přes 4 disky s výslednou velikostí zařízení 42GiB. Na distribuci CentOS 6.4 (plně aktualizované k 2013-04-02) a kernelu 2.6.32, tedy FS btrfs je v nevýhodě, jak svou „novostí“, tak (asi) podpora v novějších kernelech je lepší (co tak sleduji a čtu).

Jak si po sobě souborové systému uklízí.
Že některé FS, jako například ext3/4 při vyprázdnění adresáře neuvolňují místo použité pro meta-data sem tam někoho překvapí. Nejedná se o mnoho místa, ale pokud se smaže opravdu rozsáhlá datová struktura, je to vidět.

Toto místo je opět pro meta-informace využito, takže se nejedná o ztracený prostor, nýbrž o rezervovaný. Testy jsem provedl jak zápisem struktury 1×, tak vícekrát (s předchozím smazání) a výsledky byly identické, takže všechny FS plně znovu-použijí dané místo bez nějakých ztrát.

Test vytvořil v adresáři 24000 souborů a 4000 adresářů a následně je smazal a porovnal volné místo před a po.
První graf zobrazuje neuvolněné místo a druhý jen pro informaci dobu trvání.


vfat -S 4096: hodnota je 131105b (≈128 KiB), což je už docela hodně, ale čas se zkrátil na 0.18 sec.

Popravdě mě trochu zaskočila ta „fat-ka“.

Zápis surových dat - kolik se tam vleze
Jednoduchý zápis 1 GiB souborů pomocí:
dd if="/dev/shm/1GiB-file" of="${testpath}.${cnt}" bs=1048576 conv=sync
a sečtení kolik byte se zapsalo.
První graf zobrazuje kolik dat se podařilo zapsat, pro lepší orientaci je to uvedeno i v procentech, druhý graf ukazuje jak to dlouho trvalo a třetí co to během testu žralo (CPU čtyřjádro HT, tedy 12.5% = jeden proces na plno). Zjištění zatížení CPU probíhá jako minule, pomocí mpstat -1 -1 v druhém procesu a v grafu je zobrazena průměrná hodnota.



vfat -S 4096: hodnota je 41.97 GiB a čas se lehce zkrátil na 200.1 sec.

Evidentně už po tomto je jasné, že btrfs nebudeme asi používat z důvodů nenáročnosti na prostředky a když hlídáme každý MiB. Jinak bych řekl, že o žádné překvapení se nejedná, jen snad, že ext3 je znatelně pomalejší než ext4 při zápisu surovějších dat.

Zápis struktury dat - kolik se tam vleze
Je to opakování předchozího, ale vytváří se tříúrovňová struktura a různá velikost souborů.
Struktura se tvoří takto (pro lepší představu ):

#!/bin/bash

#arguments: file in, oyt path
thepath="$2"
infile="$1"

if [ -z "$thepath" ]; then
  echo "Error arguments 1"
  exit 3
fi
if [ -z "$infile" ]; then
  echo "Error arguments 1"
  exit 3
fi

stop=0
amount=0
files=0
dirs=0
file="${thepath}/xxx"
function fillit(){
  if [ "$stop" -eq "0" ]; then
    for ((i=0;i<$3;i++)); do
      files=$(($files+1))
      val="$(dd if="${infile}" of="${4}-${i}" conv=sync bs=$1 count=$2  2>&1 | grep copied | awk '{print $1}')"
      ret="$?"
      if [ -z "$val" -o "$val" -eq "0" ]; then
        val="$(dd if="${infile}" of="${4}-afewbytesmore" conv=sync bs=1 2>&1 | grep copied | awk '{print $1}')"
        if [ -n "$val" -a "$val" -ne "0" ]; then
          amount="$(($amount+$val))"
        fi
        stop=1
        break
      fi
      amount="$(($amount+$val))"
      if [ "$ret" -ne "0" ]; then
        stop=1
        break
      fi
    done
  fi
}

function getrndstr(){
  tr -dc "[:alpha:]" < /dev/urandom | head -c $1
}

x=0
while [ "$stop" -eq "0" ]; do
  file="$thepath"
  fillit  999887  38   1 "$file/$(getrndstr 100)${x}9"
  str="$(getrndstr 7)"
  file="$thepath/${str}${x}"
  mkdir "$file" > /dev/null 2> /dev/null
  if [ "$?" -ne "0" ]; then
    stop=1
    break
  fi
  dirs=$(($dirs+1))
  base1="$file"
  for ((j=0;j<9;j++)); do
    x=$(($x+1))
    fillit  987654  17   4 "$base1/$(getrndstr 55)${x}8"
    str="$(getrndstr 9)"
    file="$base1/${str}${x}"
    mkdir "$file" > /dev/null 2> /dev/null
    if [ "$?" -ne "0" ]; then
      stop=1
      break
    fi
    dirs=$(($dirs+1))
    base2="$file"
    for ((k=0;k<13;k++)); do
      x=$(($x+1))
      fillit  951357   10  12 "$file/$(getrndstr  5)${x}7"
      str="$(getrndstr 9)"
      file="$base2/${str}${x}"
      mkdir "$file" > /dev/null 2> /dev/null
      if [ "$?" -ne "0" ]; then
        stop=1
        break
      fi
      dirs=$(($dirs+1))
      x=$(($x+1))
      fillit        1  113   4 "$file/$(getrndstr 95)${x}1"
      fillit      305    1  16 "$file/$(getrndstr 25)${x}2"
      fillit      613    1  16 "$file/$(getrndstr  7)${x}3"
      fillit      970   10  16 "$file/$(getrndstr  9)${x}4"
      fillit      998   16  13 "$file/$(getrndstr 15)${x}5"
      fillit   965173    1  30 "$file/$(getrndstr 33)${x}6"
      if [ "$stop" -ne "0" ]; then
        break
      fi
    done
    if [ "$stop" -ne "0" ]; then
      break
    fi
  done
  x=$(($x+1))
done
echo -e "$amount\t$dirs\t$files"

exit 0

První graf je opět kolik se podařilo zapsat a jsou opět uvedena i procenta, což nyní doplním i o informaci, že 1 % ≈ 430 MiB.
Pro lepší představu je zde opět graf jak dlouho zápis trvá a kolik souborů a adresářů se podařilo vytvořit.




vfat -S 4096: hodnota je 38.97 GiB [90.8 % ≈ 3GiB nevyužito] (Adresářů: 305; souborů: 30061), což u že opravdu málo, ale čas se hodně zkrátil na 288.9 sec.

Závěr:

• Uklízení si po sobě, bez nutnosti použití fsck, či znovuvytvoření prázdného vyčištěného adresáře, dopadlo tak jak jsem očekával, jediná fakta mě trochu zaskočila. Nicméně „neuklizený“ prostor je znovupoužitelný a není ho mnoho, než aby stálo za to se tím zabývat.
• Zápis „surových“ dat či struktury, je velmi obdobný, jen u fat-ky je drobný rozdíl v tom kolik se toho tam vleze (pominuli skutečnost, jak byla nastavena).
• Jak už jsem naznačil, btrfs určitě nepoužijeme pokud nás zajímá každý MiB (ono mít a nemít 2GiB na 42GiB může být docela rozdíl) pokud nebudeme nasazovat nějakou deduplikaci.
  Pro slabší stroje s vyšším zatížením FS, to taky s btrfs nebude zrovna výhra, 13% rozdíl oproti xfs na této sestavě mi přijde už docela velký.
• Použít ntfs pokud nechceme zatěžovat CPU, by mohlo vypadat jako dobrý nápad .
  Mimo jiné po zaplnění ntfs jsem vždy dostal příjemné hlášení:

  Message from syslogd@stroj at datum ...
   kernel:do_IRQ: 3.132 No irq handler for vector (irq -1)

  .
• Pokud nás opravdu zajímá kolik se tam celkem vleze nebo jak je to rychlé, tak si můžeme podle těchto kritérií zvolit, ale obvykle je to spíše zvyk, nebo jiné funkce FS, či vlastní zkušenosti, protože parametry rychlost či kolik se tam vleze nejsou až tak rozdílné.

Příště, ale za nějaký čas, to bude o ukládání (hodně) velkého množství malých souborů, vyhledávání a mazání, kde už FS budou pravděpodobně generovat větší rozdíly…

       

Komentáře

[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é…