XFS vs. JFS

22.9.2006 03:20 | Přečteno: 3248× | bash |

Ked som minuly tyzden menil disk povedal som si dam tam XFS (predtym JFS), ani neviem preco, len tak na skusku. Po nainstalovani (archlinuxu) sa mi zdalo ze KDE nabieha nejako dlho. Tak mi to nedalo a skusil som to otestovat.
Test prebiehal na SATA disku Maxtor 250GB 16MB cache, prepnuteho do rezimu SATA lebo SATAII nemam na doske. Data som cital z /dev/hda2 a zapisoval na /dev/sda2. Disk som po kazdej zmene naformatoval a ArchLinux na novo nainstaloval.
Nechcel som si to nechat pre seba, lebo mozno to niekomu pomoze.

Tu su moje merania, ktore ma velmi prekvapili:

Velke subory (37 files 14 GB size):
     Zapis
XFS: 6:05
JFS: 6:09

Male subory (6517 files 247 MB size):
     Zapis/2x*    Mazanie (rm -fr)
XFS: 1:01(0:49)   0:22
JFS: 0:35(0:09)   0:01

*udaj v () je zopakovanie bez restartu.

Testy prebiehali prikazom: time rsync -av /mnt/zdroj /ciel
Zatazenie CPU bolo cca o 3-5% nizsie u JFS.

Vsetko som testoval 3x po restarte, a vysledy sa lisili +- 1-2 sec pri kopirovani. No bol som dost prekvapeny, tak som si dal opat JFS a KDE nabehlo zasa rychlo. Co ma vsak prekvapilo ze XFS tak dlho maze male subory.        

Komentáře

[Mikos]

Když už si byl u toho, nechceš do toho porovnání přidat reiserfs 3.6 (případně i reiser4)?

[Ivanhoej]

Reiser 4 nema arch v instalacnom CD podporu tak ten asi nie, a co viem stale nie je ani vo vanilla jadre.

[David Watzke]

Co ma vsak prekvapilo ze XFS tak dlho maze male subory.

To není žádná novinka, XFS je práci s malými soubory nevhodný. Zato třeba 10GB soubor smaže tak hrozně rychle, že nechápu...

[Libor Klepac]

staci smazat jeden hardlink, ne? ;)

[Michal Vyskočil]

Mám XFS a KDE nabíhá rychle. Je fakt, že mazání například zdrojáků jádra se dost protáhne . Ale nechceš test doplnit o rychlost čtení? Protože ta je z hlediska startu KDE kritická.

[Michal Čihař]

Pěkný test, ale nepřevažuje náhodou v reálném použití spíš čtení, které vůbec není zmíněno?

[Martin]

Moc zajímavé. A ještě lepší by to bylo, když bys test rozšířil o připomínky výše ;o)

Uvažuju, co dám na laptop za FS. Dřív jsem to tak neřešil, podle mě to při běžné práci nemusí hrát nějakou závratnou roli, prostě jsem použil ext3, protože se mi nechtělo číst ty flejmy ;o), ale teď jsem se trošku zajímal o to, který FS by byl nejlepší z hlediska úspory energie. Přece jenom je to laptop a práce s diskem na výdrž baterie má určitý vliv... na fóru Archu jsem četl zmínky, že je na laptopy vhodný JFS, ale to je FS, o kterém prakticky nic nevím...

[Ivanhoej]

Ospravedlnujem sa ze som test neurobil i na citanie a vobec kopec veci, ale aj tento mi zabral par hodin, a reiser a ext, proste na to uz nebolo casu.

Na notebook by som dal JFS koli dvom veciam, je asi jeden z najrychlejsich a ma najnizsiu zataz CPU (to som cital aj v inych testoch) a Notas na vlastne UPS takze tam je vhodny i XFS(nedoporucuje sa bez UPS, koli vysokemu cachovaniu)

Ked mi pride nejaky dalsi disk skusim test rozsirit o reiser, ext3 a citanie. Mazanie velkych suborov nemalo zmysel merat, lebo bolo okamzite, no na ext3 by bolo pravdepodobne najdlhsie. Na Reisera3 sa par ludi stazovalo(dokonca sa to stalo kolegovi) ze po zaplneni na 100% FS odisiel s tym ze sa niekedy dal obnovit. Dalej strasne dlho sa montuje, v tomto smere je jednicka XFS, no je to nepodstatny udaj)

[Mikos]

Já měl reiserfs 3.6 zaplněný na 100% již mnohokrát a nikdy se mu nic nestalo Takže bych to typoval na další z FUDů co obvykle někteří o reiserfs rádi šíří (nebo na nějakou chybu z dávné minulosti, která už x let neplatí). Jak už sem psal v jiné diskuzi, tak u mě se naopak reiserfs ukazuje dlouhodobě nesrovnatelně spolehlivější než ext3.

[Martin]

Není třeba se omlouvat. Uvědomuju si, že by to zabralo dost času... řekl jsem to spíš tak z legrace :o) Pokud by jsi ale ten test mohl někdy později rozšířit, bylo by to samozřejmě super...

OK, tak já tedy na radu zkušenějšího vyzkouším na tom notebooku JFS. Díky za doporučení. Přinejhorším budu mít o zkušenost navíc ;o)

[kouby]

Taky se připojuji k žádosti o provedení testu také pro čtení dat.

[fakenickname]

Jen tak nevím proč už půl roku mám XFS a je docela v pohodě. Ještě jsem (díky bohu) nezaznamenal žádný průšvih. Ale jestli je to tak jak říká tak se příště asi přikloním k druhé možnosti -- JFS.

[Ivanhoej]

XFS je super, neni dovod ho nepouzit, len je trosku pomalsi, co na desktope kde je kopec malych suborovo moze zdrzovat. Na server ak ma UPS by som XFS dal alebo ext3 ak UPS nema.

[Snilard]

Tak trochu nechápu proč u volby fs záleží na záložním zdroji.
Proč je to důležité?

[Michal Vyskočil]

XFS cachuje spousty dat v RAM. Při výpadku napájení je u něj pravděpodobnost, že budou data zničená, vyšší, než u jiných filesystémů.

[Snilard]

A to xfs nema zurnal? Jak jsou na tom xt3 a reiserfs s cachovanim?

[Heron]

Ale má. To jsou jen takové urban stories . Stejně tak spousta lidí výhrady k reiserfs jen proto, že kdysi dávno na jedné řadě jader 2.4.x.

Jak je na tom reiser s cachováním nevím, ale u ext3 si lze (mimo jiné) nastavit commit time (default 5s).

Všechny tyto volby ovšem ovlivňují spíše zápis, rychlost čtení (a z disku se více čte než zapisuje) ovlivní hlavně rychlé vyhledávání daného souboru (s tím souvisí použitý způsob ukládání metadat) a fragmentace.

[Mikos]

To nejsou žádné urban legendy, XFS na počítači bez UPS je prostě sebevražda Není to chyba toho filesystemu, je to prostě a jednoduše jeho vlastnost s kterou se musí počítat. Na počítač s UPS (a bez žádných hardwarových problémů kvůli kterým by bylo potřeba občas restartovat) je to naopak výborná volba.

Co se týče reiserfs, tak ten se naopak u mě dlouhodobě ukazuje na vícero počítačích jako mnohem odolnější k výpadkům proudu/tvrdým restartům než ext3 (viz tahle nedávná diskuze). IMHO je to z tohoto hlediska nejodolnější FS vubec...

[neal_cz]

Potvrzuji. Měl jsem XFS na notebooku a párkrát jsem dojel s baterkou nadoraz. Vždy jsem byl po následném nastartování nemile překvapen poškozenými obsahy některých souborů -- hlavně /etc/fstab byl pravidelně plný nesmyslů. Přešel jsem na reiserfs pro / a JFS pro /home a takové problémy už mě nepotkávají.

[Mayo]

Ja som s XFS dopadol rovnako. Niektore konfiguraky v /etc po tvrdom restarte boli plne binarnych sr*ciek. Teraz mam Reiser a okrem dlheho mountu (oproti XFS) mi na nom nic nevadi.

[David Watzke]

To nejsou žádné urban legendy, XFS na počítači bez UPS je prostě sebevražda

1, Heron nazval urban legendami to, že XFS nemá žurnál, nikoliv to, že je trochu citlivější na výpadky, ale to asi víš (v takovým případě nechápu tvou reakci).

2, Není to sebevražda, naopak je to výborná volba pro oddíl, na kterém jsou (mají být) velké soubory. Ne každý 100× denně tvrdě resetuje počítač. Děkuji mnohokrát.

[Mikos]

1.) Tak to sem ten jeho příspěvek špatně přečetl/pochopil. Já z toho vyrozuměl že za urban legendu považuje citlivost XFS k tvrdym restartum/výpadkum proudu (což opravdu urban legend néni).

2.) Na některém hardwaru se tvrdým restartům prostě nevyhneš. Navíc to jestli bude nějaký výpadek proudu také nemůžeš ovlivnit. Takže XFS opravdu jedině na spolehlivém hardwaru s UPS, jinak to za sebevraždu vskutku považuji (pokud ti tedy záleží na datech, jestli ne tak je to jedno ).

[David Watzke]

1.) Tak to sem ten jeho příspěvek špatně přečetl/pochopil.

Indeed.

2.) Na některém hardwaru se tvrdým restartům prostě nevyhneš. Navíc to jestli bude nějaký výpadek proudu také nemůžeš ovlivnit. Takže XFS opravdu jedině na spolehlivém hardwaru s UPS, jinak to za sebevraždu vskutku považuji (pokud ti tedy záleží na datech, jestli ne tak je to jedno ).

Výpadky proudu jsou tu jen párkrát za rok a rozhodně ne 100× denně... Vím, může stačit i to. UPS si taky chystám koupit - opravdu nejen kvůli XFS

[xxxxxxxx]

+1

[Michal Kašpar]

Ma. Jak souvisi zurnal s tim, jestli fs pri vypadku proudu nabori data?

[Snilard]

N myslel jsem, ze zurnal tam je aby se do nej ukladalo, co se provedlo v poslednich nekolika operacich, aby se to dalo provest znova treba po vypadku proudu, nebo podobne neprijemnosti.
Asi jsem se mylil. K cemu je teda zurnal dobry?

[Michal Kašpar]

Žurnál (tedy tak jak je implementován ve většině fs, ext3 má možnost žurnálovat i data, což už se tu jednou s drobným flejmem probíralo) je dobrý k tomu, že udrží konzistenci metadat (tedy "řídících" struktur fajlsystému) nikoli dat. Po pádu tedy není nutné provádět zdlouhavý fsck, ale pouze se podle něj provedou/odrolují poslední rozdělané operace. To, že to může znamenat kompletní zrušení obsahu souborů, což je to, co většinu lidí zajímá nejvíc, je věc druhá.

[Jiří Němec]

Při použití JFS jako rootu hlavně nezapomeňte v grubu na parametr ro. Jinak se můžete při nekorektním vypnutí pěkně divit.

[kouby]

To je snad vychozi nastaveni pri instalaci, ne?

[guns]

no tak to mi je diva, ze pri JFS je vyhoda dlhsej vydrze baterky /dovody spominane vyzsie/ .. len by ma zaujimalo ci to clovek vazne pociti, alebo je to ako u cyklistov kde sa haadaju o 2 gramy na pedaloch...

[kouby]

Asi bude take hodne zalezet na rezii cteni a zapisu z/na disk. Kdyz ten notebook pouze jenom pobezi, obcas si spustite par programu a nebo si pouze prohlizite internetove stranky, tak to asi poznat neni..

[Ivanhoej]

Jaj, to som zabudol ze z JFS(a aj XFS) nie je dobre bootovat, teda davat ako hlanu / particiu. Ja som tak dal JFS a len 2x som nabootoval a potom uz nie.

Cize treba disk rozdelit na /boot / a swap /boot staci 25-30 MB. Uz som to tu raz na ABC pisal ale pre istotu to zopakujem:

A prikladam original doporucenie:

GRUB and JFS

Alhough technically possible, the combination of GRUB with JFS is problematic. In this case, create a separate boot partition (/boot) and format it with Ext2. Install GRUB in this partition.

GRUB and XFS

XFS leaves no room for stage1 in the partition boot block. Therefore, do not specify an XFS partition as the location of the boot loader. This problem can be solved by creating a separate boot partition that is not formatted with XFS.

Este par veci je tu: http://www.djack.com.pl/Suse9hlp/ch08s04.html

[Martin]

Dobře, že jsi to řek, zrovna jsem se chystal pustit do instalace :o)

[Michal Čihař]

S XFS není problém pokud je Grub v MBR.

[Ivanhoej]

Aj JFS mi v gentoo kernel slapalo, ale asi ma na to nejaku zaplatu, lebo v archu ani za pana. Naco riskovat idealne je pouzit to tak ak sa to doporucuje. /boot / swap.

[Zdeněk Štěpánek]

Nerekl bych, GRUB v Debianu se mi na / na XFS proste nenainstaloval Daval jsem ho samozrejme dop MBR, kam jinam, to bych nenabootoval. Tak mam kousek nejakej ext3 nebo jak se tomu nadava.

Zdenek

[Mikos]

Mít samostatnou boot partition považuji za samozřejmost ať používám jakýkoliv sebelépe podporovaný filesystem.

[diverman]

Taky jsem to tak praktikoval...a zjistil jsem, že je to naprosto zbytečný.

[Michal Kubeček]

Samostatná partition pro /boot má smysl jen v několika přesně vymezených případech, jinak je naprosto k ničemu. Rozhodně to není žádná samozřejmost.

[happy barney]

nefunguje grub, funguje lilo ... preco pouzivat nieco co nefunguje ?

[Mikos]

Fuj, lilo, to ještě neumřelo? :-P

[David Watzke]

Je sice pravda, že mi grubí shell jednou zachránil zadek od toho, abych musel jít do liveCD a opravovat grub.conf, ale lilo taky posloužilo dobře...

[podlesh]

Neumřelo a neumře, dokud s ním bude méně problémů než s grubem.

[Mikos]

Já měl tedy vždycky méně problémů s grubem Ale držím se zásady že na boot by měl mít člověk samostatnou partition

[David Watzke]

Ale držím se zásady že na boot by měl mít člověk samostatnou partition

No to teda neměl, je to naprostá zbytečnost...

[Libor Klepac]

jednou jsem zkousel nejake veci a napsal jsem si takovyhle skript ...nevim, jestli ma nejakou vypovidaci hodnotu ;) ... a vysledky jsem nekam potratil

#!/bin/sh


DIRS=50
SDIRS=$DIRS
FILES=5

DEV1=/dev/sda7
MP1=/mnt/pokus/1

DEV2=/dev/sdb7
MP2=/mnt/pokus/2

mount_dir()
{
        mount $DEV1 $MP1
        cd $MP1
}

umount_dir()
{
        cd ..
        echo -n "umount "
        D1=`date +"%s"`
        umount $MP1
        D2=`date +"%s"`
        D=$((D2-D1))
        echo "$D s"
}

rsync_dir()
{
        mount $DEV2 $MP2

        echo -n "rsync "
        D1=`date +"%s"`
        rsync -a -r --delete . $MP2
        D2=`date +"%s"`
        D=$((D2-D1))
        echo "$D s"
        rm -rf $MP2/*

        umount $MP2
}

test_dir()
{

        mount_dir

        echo -n "vytvoreni "
        D1=`date +"%s"`
        for i in `seq 1 $DIRS`; do
                for j in `seq 1 $SDIRS`; do
                        mkdir -p "$i/$j"
                        for f in `seq 1 $FILES`; do
                                dd if=/dev/zero of="$i/$j/$f" count=1 bs=100k > /dev/null 2>&1
                        done
                done
        done

        D2=`date +"%s"`
        D=$((D2-D1))

        echo "$D s"

        umount_dir
        mount_dir
        rsync_dir
        umount_dir

        mount_dir

        echo -n "smazani "
        D1=`date +"%s"`
        rm -rf *
        D2=`date +"%s"`
        D=$((D2-D1))

        echo "$D s"

        umount_dir
}

mkfs.ext3 $DEV1 > /dev/null 2>&1
echo "--------EXT3"
test_dir

mkfs.ext3 $DEV1  > /dev/null 2>&1
tune2fs -O dir_index $DEV1  > /dev/null 2>&1
fsck.ext3 -Dfy $DEV1  > /dev/null 2>&1
echo "--------EXT3 dir_index"
test_dir

mkfs.xfs -f $DEV1  > /dev/null 2>&1
echo "--------XFS"
test_dir

mkfs.reiserfs -f $DEV1  > /dev/null 2>&1
echo "--------REISER"
test_dir

[Libor Klepac]

jeste tam asi chybi mkfs.nejakyfs -f $DEV2 nekde na zacatku rsync_dir (asi jsem to radsi po ukonceni pokusu umazal ;)

[Ivanhoej]

ok test citania by som mal, urobim to ked bude volny disk.

Poradte pripadne nieco lepsie:

time find . -type f -exec cat '{}' ';' > /dev/null

No a este by som potreboval nieco jednoduche na vytvorenie x suborov o y velkosti.

nieco cez dd asi, mozno to niekto ma hotove.

[David Watzke]

Poradte pripadne nieco lepsie:

time find . -type f -exec cat '{}' ';' > /dev/null

Tady je lepší

time find -type f -print0 | xargs -0 cat &>/dev/null

Nebude tolikrát spouštět cat; mělo by to být rychlejší...

[Mikos]

A uvědomuješ si, že maximální počet argumentů na příkazové řádce je omezený? Pokud je tedy těch souborů hodně, tvoje řešení by nefungovalo, kdežto to jeho ano. Teda jestli se nepletu a xargs ten limit nějak neobchází, ale o tom pochybuju

[podlesh]

Samozřejmě že xargs limit zná a pustí cat tolikrát, kolikrát je to nutné. To je konekckonců jeden z hlavních důvodů jeho existence.

[Mikos]

Tak to jsem rád, to jsem žil docela dlouho v omylu

[David Watzke]

Pokud je tedy těch souborů hodně, tvoje řešení by nefungovalo, kdežto to jeho ano. Teda jestli se nepletu a xargs ten limit nějak neobchází, ale o tom pochybuju

Bla bla... vedle

[Ivanhoej]

s xargs je skor problem ak sa berie koniec subora medzera napr. ak ma nazov suboru "Nazov skladby.mp3" a xargs by vzal len nazov, to ale riesi argment -0(--null), ktory hovori ze za koniec nazvu ma pokladat koniec retazca, ale doporucuje sa pouzit s parametreom -print0, ktory mu takto data pripravi.

Takze aj xargs aj -exec budu chodit spolahlivo a rozdiel v rychlosti nebude postrehnutelny a mozno ani nemeratelny, predsa len ten cat potrva niekolkonasobne dlhsie. Ale uznavam je to rychlejsie riesenie no funkcnostou rovnake.

[happy barney]

rozdiel teda bude pekne vidiet, odporucam si to vyskusat.
jednoducho rozdiel fork+exec 1k krat a raz, aj keby kazdy trval len povedzme 10ms ...

[David Watzke]

I když ještě lepší by bylo

cat /dev/sda >/dev/null

ale to je jedno

[Michal Vyskočil]

No, neobešel by se tímto právě ten testovaný filesystém?

[David Watzke]

?

cat /dev/sda1 > /dev/null

[Michal Vyskočil]

No jak chceš testovat výkon filesystému, když budeš pouze sekvenčně číst jednotlivé bajty z disku a vůbec nebudeš přistupovat ke strukturám filesystému?

[David Watzke]

Jo, to je fakt... odvolávám

[sandi]

aku velkost bloku si si na tom xfs nastavil ? xfs umoznuje 512B az 64KiB

source: http://en.wikipedia.org/wiki/XFS

[Ivanhoej]

Pouzil som defaultnu hodnotu teda 4096 bytes (4 KiB).

[imro]

4096 bytes, to su 4KB, ak sa nemylim. Nie je to tak???