Vlákno názorů k článku
Ladíme výkon souborových systémů Btrfs, F2FS, EXT4 a XFS
od RDa - Jsem rad ze se potvrdilo byt konzervativnim. EXT4...
-
Ondra Satai NekolaZlatý podporovatelVyladeny, ale skoro nic neumi. (nic = nic z pohledu roku 2013, z pohledu roku 2003 je to velmi schopny FS)
-
Snapshoty k zalohovani mate v LVM, historicky vyvoj neceho je ale lepsi ukladat do verzovaciho systemu.
Kolik % uzivatelu potrebuje resit deduplikaci on-the-fly na urovni souboru/bloku? Temer nikdo. A kdo to potrebuje, muze si zvolit jiny FS, ktery to umi. Zrovna tato operace je hodne pametove a vypocetne narocna (drzet checksumy vsech bloku a vyhledavat v nich zda se neco nezhoduje) takze nema smysl ji cpat do zakladniho FS.
-
Ondra Satai NekolaZlatý podporovatel
Zkousel jsem snapshoty v LVM, zkousel jsem je v ZFS a rozdil v pohodli a pouzitelnosti je extremni.
-
S timhle rozhodne souhlasim, fs je primarne system uloziste dat a to staci. Omacku okolo poresim jinymi nastroji.
Na druhou stranu se mi libi i predstava vseho v jednom, proc ne :-). Bohuzel za sebe mohu rict, ze btrfs pouzivam zhruba 5 mesicu a behem jednoho mesice sel vykon brutalne dolu, brutalne myslim skoro k nepouzitelnosti, jakakoli operace vcetne cteni trvala v minutach, manipulace i v hodinach(mam tam veskery vyvojovy nastroje + desitky zdrojovych kodu open-source projektu pro vyvoj, takze hodne malych souboru + big files instalacni obrazy)
Takze me zatim ani omacka okolo nepresvedci pro jeho seriozni pouziti, samozrejme jsem si pohral s nastavenim mountu, zkousel ruzne cesty tuningu co jsem kde pohledal, nicmene podarilo se mi dostat vykon fs zpet pouze na zhruba 70-80proc puvodniho "cisteho" stavu (pravda je tam radove vice dat nez pri puvodnim testu) To vse na kernelu 3.7.*.Stejne me to nakonec nedalo :D a behem zari jdu testovat jeho vykon znovu, trosku jinak, raid 6 na btrfs vs ext4 s mdadm - 8 disku. Rozhodne postnu vysledky a ne jen s prazdnym systemem, jelikoz btrfs je evidentne citlivy na fragmentaci.
Kazdopadne tomu systemu fandim.
Ladik
-
Lael Ophir (neregistrovaný)
Proč by to tak mělo být? Když FS umí například transparentní kompresi nebo deduplikaci, není důvod aby to zpomalovalo operace, kterých se tato funkcionalita nedotýká. Takže pak máte soubor bez komprese, na kterém je FS rychlý, a soubor s kompresí, kde je pochopitelně pomalejší.
Jako daleko větší problém bych viděl ve věčně se opakujících "radostech" Linuxu typu ztráty souborů při (by default) delayed allocation a ztrátě napájení, různých race conditions, potřeba fsync na ext4 a naopak jeho pomalost na btrfs, ztráta výkonu v tom či onom buildu jádra... On je to odjakživa takový linuxový folklór, a bohužel se to moc nelepší.
-
Program (neregistrovaný)
Prostě to tak je, nic s tím nenaděláte. Výjimkou je snad jen transparentní komprese, tam není důvod, aby brzdila.
Jinak ty Vaše srandičky taky pochází asi z říše pohádek. Když vypadne napájení zrovna, když se nějaký soubor zapisuje, tak prostě je soubor v háji na každém FS, pokud není použit journal na data.
V čem je potřeba fsync na ext4, kde jinde potřeba není? Prostě data musí být uložená a pak se volá fsync, nebo nemusí být uložená a pak se fsync nemusí volat libovolně dlouho.
-
Ondra Satai NekolaZlatý podporovatel
Problem se zapisem/vypadkem proudu castecne resi nejen zurnalovani ale i Copy-on-Write.
-
Max (neregistrovaný)
Lael Ophir je placený agent Windowsu a propaguje Windows všude, kde se dá a na Linux kydá všude hnůj! Nechápu, proč netáhne masturbovat nad těma svýma M$ Widlema někam jinam. Tady jsou Linuxáci a ty nikdy nepředělá. Někdo má hold rád korporace, manipulaci, vymývání mozků a někdo prostě dá přednost SVOBODĚ a Linux je SVOBODA!
-
Ondra Satai NekolaZlatý podporovatel
Lide jako LO jsou uzitecni minimalne v tom, ze te donuti zamyslet se nad tim, co rikaji. Krikem "foo is BAR!" se nepochopis nic.
ČLÁNKY DO MAILU