abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 19:55 | Zajímavý software

    smenu, nástroj pro příkazový řádek pro generování možností a potvrzení výběru, dospěl do verze 1.0.0.

    Ladislav Hagara | Komentářů: 0
    dnes 19:11 | Bezpečnostní upozornění

    Byla potvrzena zranitelnost CVE-2021-46778 aneb SQUIP (Scheduler Queue Usage via Interference Probing) v procesorech AMD s mikroarchitekturou Zen 1, Zen 2 a Zen 3. Detaily v publikovaném paperu.

    Ladislav Hagara | Komentářů: 0
    dnes 13:33 | Nová verze

    Turris OS, operační systém pro síťová zařízení Turris postavený na OpenWrt, byl vydán v nové verzi 5.4. Přehled novinek a diskuse v diskusním fóru.

    Ladislav Hagara | Komentářů: 0
    dnes 13:11 | Nová verze

    Byla vydána nová stabilní verze 5.4 (aktuálně 5.4.2753.28) webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 104.0.5112.83. Přehled novinek v příspěvku na blogu. Vivaldi Mail byl povýšen na verzi 1.1.

    Ladislav Hagara | Komentářů: 0
    včera 23:33 | Bezpečnostní upozornění

    Intel vydal 27 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20220809 mikrokódů pro své procesory. Ta řeší INTEL-SA-00657. Jedná se o bezpečnostní chybu ÆPIC Leak aneb CVE-2022-21233.

    Ladislav Hagara | Komentářů: 1
    včera 20:22 | Nová verze

    Byla vydána nová verze 2022.3 průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.

    Ladislav Hagara | Komentářů: 0
    včera 18:11 | Nová verze

    Byla vydána nová major verze 4.0 programovacího jazyka a vývojového prostředí Processing. Ke stažení na GitHubu. Přehled novinek na wiki.

    Ladislav Hagara | Komentářů: 0
    včera 09:00 | Komunita

    Konference OpenAlt 2022 proběhne o víkendu 17. a 18. září na FIT VUT v Brně. Přednášky lze přihlásit do 15. srpna.

    Ladislav Hagara | Komentářů: 0
    včera 08:00 | Zajímavý článek

    GNOME Web (Epiphany) přichází s podporou rozšíření, která jsou kompatibilní s rozšířeními ve Firefoxu. Více v článku WebExtensions v Epiphany (GNOME Web) na MojeFedora.cz.

    Ladislav Hagara | Komentářů: 1
    včera 07:00 | IT novinky

    Ve Vancouveru probíhá konference a výstava SIGGRAPH 2022 (Special Interest Group on Computer Graphics and Interactive Techniques) věnována počítačové grafice. Řada firem představuje své novinky. Intel například představil profesionální grafické karty Arc Pro A50, A40 a A30M (Mobile).

    Ladislav Hagara | Komentářů: 0
    Audioknihy ve srovnání s knihami tištěnými (papírovými nebo elektronickými) poslouchám
     (31%)
     (2%)
     (6%)
     (60%)
    Celkem 159 hlasů
     Komentářů: 1, poslední 8.8. 21:17
    Rozcestník

    Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs

    1.9.2010 12:01 | Přečteno: 7445× | linux | Výběrový blog | poslední úprava: 1.9.2010 13:00

    Už delší dobu jsem zvažoval jak vyřešit doma problémy s nedostatkem místa a nonstop přístupem k audiovizuální knihovně. Od prvních úvah o HTPC jsem se přes out-of-the-box NAS řešení dopracoval až k tomu, že nahradím můj starý a minimálně používaný PC takovým hybridem mezi NASkou, domácím serverem a příležitostným desktopem. Volba z důvodu spotřeby padla na Intel Atom s ION chipsetem. Jako úložná média bude obsahovat dva SATA disky 750GB a 1,5TB. Je jasné, že výkon takového stroje dokáže značně ovlivnit i práce s disky a proto jsem se rozhodl otestovat současné filesystémy, abych vybral pro mé potřeby pokud možno ten nejlepší.

    Předem uvádím, že na testu nijak nebazíruji. I díky jiným testům, které jsem na webu našel je mi jasné, že neexistuje univerzálně správný a 100% vypovídající test, takže to berte spíš jako podělení se o zkušenost než cokoliv jiného. Testy samoté probíhaly na PC s Athlon XP 2500+, 2GB RAM, s několika různými disky z nichž jeden Seagate SATA 40GB jsem vyhradil pro testování. Před každou serií testů byl proveden restart PC a formát partition na příslušný FS. Samozřejmě jsem před testy vypnul KDE a jiné potenciální nařušitele klidu a míru, aby CPU mohl veškeré své drahocené zdroje propůjčit probíhajícím testům. Testovalo se na jádře 2.6.35.4 s Reiser4 patchem na Debian 6.0 Squeeze i386. Pro mountování všech systémů byly použity výchozí volby, pouze u Ext3 a Ext4 jsem použil 'data=writeback'. Meření bylo prováděno pomocí GNU Time. Každý test jsem 3x zopakoval, aby byly výsledky alespoň malinko věrohodné.

    Test 1 - Rozbalení aktuálního jádra 2.6.35.4 z bz2 archivu, zdroj na jiném disku cíl na testovacím. [tar, bzip2]

    Test 2 - Změna pořadí audiostop filmu v mkv (cca 9GB), zdroj na jiném disku cíl na testovacím. [mkvmerge]

    Test 3 - Překopírování rozbaleného jádra z kroku 1 do jiného adresáře. [cp]

    Test 4 - Smazání původního rozbaleného jádra z kroku 1. [rm]

    Test 5 - Smazání vygenerovaného mkv souboru. [rm]

     

    Výsledky dopadly takto:

     


    Test1

    Test2 Test3 Test4 Test5
    time [m:s] cpu [%] time [m:s] cpu [%] time [m:s] cpu [%] time [m:s] cpu [%] time [m:s] cpu [%]
    JFS Pass1 01:29,50 64 02:54,40 73 01:08,30 6 00:14,03 6 00:00,89 1
    Pass2 01:29,18 64 02:59,00 71 01:10,11 6 00:13,24 6 00:01,19 0
    Pass3 01:26,31 65 02:53,71 77 01:26,24 6 00:16,61 5 00:01,19 1
    XFS Pass1 01:58,41 50 02:57,32 73 01:39,05 5 01:18,94 4 00:00,03 94
    Pass2 01:59,78 50 03:00,29 71 01:36,56 6 01:21,12 4 00:00,03 93
    Pass3 01:58,92 50 02:56,80 73 01:41,00 5 01:16,53 5 00:00,03 97
    Ext4 Pass1 01:01,81 92 02:54,03 78 00:12,78 37 00:02,68 62 00:00,75 99
    Pass2 00:59,38 96 02:54,68 77 00:13,29 34 00:01,83 81 00:00,78 99
    Pass3 00:58,96 96 02:50,13 82 00:08,92 51 00:01,75 98 00:00,74 99
    Reiser4 Pass1 01:05,26 93 03:13,42 68 00:34,84 65 00:08,07 99 00:00,06 91
    Pass2 01:03,16 96 03:11,61 69 00:32,58 69 00:07,86 99 00:00,05 89
    Pass3 01:03,86 96 03:13,11 67 00:32,76 67 00:08,22 99 00:00,06 92
    Btrfs Pass1 01:13,09 91 03:27,91 63 00:21,43 53 00:11,98 94 00:00,23 98
    Pass2 01:14,55 91 03:30,20 62 00:21,54 54 00:12,93 93 00:00,23 99
    Pass3 01:11,67 91 03:36,49 63 00:25,06 46 00:09,85 99 00:00,21 99
    Ext3 Pass1 01:07,19 85 03:07,47 79 00:24,43 20 00:01,31 97 00:00,56 97
    Pass2 01:07,73 85 03:08,37 78 00:24,06 20 00:01,26 98 00:00,63 99
    Pass3 01:11,67 80 03:08,81 79 00:26,43 19 00:01,36 99 00:00,62 99

    Jak je vidět, celkově nejléve si vedla Ext4. V prvních třech testech zvítězila, i když v případě druhého jen velmi těsně s XFS a JFS. Ve třetím testu pak válcovala všechny FS. Až ve čtvrtém testu ji dokázala o malý kousek překonat Ext3. V pátém tesrtu pak s přehledem zvítězila XFS, nicméně rozdíly jsou jen v řádu setin vteřiny. Hodnocení využití procesoru je diskutabilní, nicméně dovolím so říct, že hodnoty nejsou nijak extrémní a v zásadě vyšší zátěž je vykoupena vyšší rychlostí prováděného úkolu. I když jsem byl povětšinou zastáncem XFS, po tomto výsledku dám na domácí NAS raději Ext4, která se jeví pro mé užívání vhodnější.

           

    Hodnocení: 100 %

            špatnédobré        

    Anketa

    Jaký FS upřednostňujete?
     (9 %)
     (53 %)
     (11 %)
     (9 %)
     (1 %)
     (9 %)
     (4 %)
     (0 %)
     (3 %)
    Celkem 257 hlasů

    Obrázky

    Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs, obrázek 1

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    1.9.2010 12:06 JJ
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Urob prehladne grafy, pls :)
    rudiik avatar 1.9.2010 12:36 rudiik | skóre: 16 | blog: rudiikuv miniblog
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Spachal jsem jeden rychly graf, vzdy nejlepsi vysledek FS v danem testu. Bohuzel rozlisovaci schopnost u pateho testu je nulova :-) Vecer pripadne muzu doplnit podrobneji pro kadzy test, pokud by byl zajem.
    KDE 2.0 .. KDE 3.5.10 -> KDE 4.1 .. KDE 4.4.5 -> E17 Alpha/Beta -> Trinity 3.5.12 -> GNOME 2.30 -> KDE 4.6.5
    1.9.2010 12:17 Trained.Monkey | skóre: 12 | blog: monkey
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Mozna by stalo za to udelat paralelni testy. Tedy spustit rozbalovani jadra 100x a sledovat ktery FS drive skonci.
    1.9.2010 12:36 Semo | skóre: 45 | blog: Semo
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Ak sa nemylim, ze cpu% znamena to, co si myslim, tak zataz CPU napr. pri rozbalovani kernel stromu bude samozrejme 10x vacsia pri procese, ktory trval 10x mensiu dobu. Nema ziaden vyznam merat cpu%, ale kernel time procesu (rovno z vystupu time, nebrat iba real).
    If you hold a Unix shell up to your ear, you can you hear the C.
    rudiik avatar 1.9.2010 12:58 rudiik | skóre: 16 | blog: rudiikuv miniblog
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Ano CPU se zda byt presne tohle, alespon jak ho vraci time. To je take duvod proc nijak vyrazneji vysledku CPU nehodnodtim. Ohledne casu, byl bran kompletni cas provadene operace, protoze mne jako uzivatele zajima za jak dlouho to realne bude ne jak dlouho se s tim bude parat kernel nebo userspace. Time bezel ve verbose modu a pouzil jsem hodnoty 'Percent of CPU this job got' a 'Elapsed (wall clock) time (h:mm:ss or m:ss)'.
    KDE 2.0 .. KDE 3.5.10 -> KDE 4.1 .. KDE 4.4.5 -> E17 Alpha/Beta -> Trinity 3.5.12 -> GNOME 2.30 -> KDE 4.6.5
    1.9.2010 13:39 Semo | skóre: 45 | blog: Semo
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    protoze mne jako uzivatele zajima za jak dlouho to realne bude ne jak dlouho se s tim bude parat kernel nebo userspace.

    To ma naposledy zaujimalo na Didaktiku M. Odkedy mame multitasking, tak sa nepozeram na rozbalovanie jadra, ale vratim sa na ten terminal, az je hotovo a medzitym robim nieco ine. A otazka je, kolko medzitym stihnem "ineho". Pripadne ak pri kompilacii jadra zozerie skoro cele CPU len pohyb po fs, tak je prdu, ze ten pohyb je v absolutnom case o 20% rychlejsi ako iny fs (pretoze ten viac povedzme macha hlavickami), pri ktorom ale okrem pohybu zvladne CPU aj kompilovat (v case, ked caka na hlavicky). Takze cela kompilacia bude rychlejsia. Preto kernel-time ma vypovedaciu hodnotu, kdezto %cpu skoro ziadnu.
    If you hold a Unix shell up to your ear, you can you hear the C.
    1.9.2010 15:19 Let_Me_Be | skóre: 20 | blog: cat /proc/idea/current | Brno
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Na stolni pocitac jedine JFS. Skvela odolnost vuci vypadkum (elektrika, hard freeze). Vykon je velmi dobry.
    Linked in profil - Můj web - Nemůžete vyhrát hádku s blbcem. Nejdřív vás stáhne na svoji úroveň a pak ubije zkušenostmi.
    kotyz avatar 1.9.2010 16:12 kotyz | skóre: 25 | blog: kotyzblog | Radnice
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    LOL, prej skvela odolnost proti vypadkum! mel sem jfs jenom tri dny a jeste sem se rad vracel k ext3. za tu kratkou dobu sem mel asi 5 vypadku (dedek vyhodil svyma mocnyma strojema hlavni jistic) a z toho se mi asi 2x nebo 3x ztratili data (smazalo se nastaveni kdecek, konfiguracni soubory byly vynulovany). tohle se mi za nekolik let pouzivani ext3 stalo maximalne 1x nebo dokonce vubec. takze bych si nedelal o jfs zadny velky iluze (sice nemusi bejt chyba v nem, ale v tom jak si kdecka ty svy konfiguraky obhospodarujou, ale s ext3 to takovy problemy nedela). jinak ten vykon byl slusnej, to jo, toho sem si za tu kratkou dobu taky vsim, ale ty prazdny konfiguraky me vadili ...
    Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
    alblaho avatar 1.9.2010 20:40 alblaho | skóre: 17 | blog: alblog
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    To jsou ty osobní nevypovídající zážitky:-)

    Myslím, že nejlepší je jít do nejobyčejnější, nejvíce nasazované a tím pádem nejotestovanější volby. Dnes je to Ext4.

    Výhodou Ext4 je slušná rychlost. Já mám na starých instalacích roky ReiserFS, protože byl oproti Ext3 viditelně rychlejší. Nikdy nezaváhal, ale na novou instalaci bych ho nikomu nedoporučil pač je odsouzen k zániku.

    Taky používám LVM. Ext4 je dobré, že se umí zvětšit bez unmountu a zmenšit. Ale z tohoto pohledu je pro mě zajímavé Btrfs, nicméně jsem konzervativní.
    kotyz avatar 1.9.2010 21:58 kotyz | skóre: 25 | blog: kotyzblog | Radnice
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    ext4 trpel stejnym problemem, kvuli delayed allocation, v ubuntu na to meli nejakej patch do jadra kterej menil defaultni chovani a ostatni to pak myslim taky prevzali. a asi uz to ted funguje dobre, protoze sem uz dlouho necet zadny stiznosti ohledne toho ...
    Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
    Heron avatar 1.9.2010 22:07 Heron | skóre: 53 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    trpel stejnym problemem

    EXT4 žádný problém v tomto směru neměl. To jen některé programy nesprávně spoléhaly na chování, které poskytoval pouze jeden jediný fs (v té době ext3) a pouze v jednom konkrétním nastavení (joural_data_ordered, commit=5). Jiný FS toto nedokumentované a v podstatě nezamýšlené (do 5s byla data, ne jen metadata, na disku) chování neměl a nemá a samotný ext3 v jiném nastavení (např. writeback, commit=600).

    kotyz avatar 1.9.2010 22:48 kotyz | skóre: 25 | blog: kotyzblog | Radnice
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    uzivatele nezajima (me to taky nezajimalo, byl sem nasranej ze to musim vsechno nastavovat znova) co za to muze, proste sou data fuc a s ext3 se mu to nestavalo ...

    spolehali na to, ze ext3 byl snad v kazdy distribuci default a i to data ordered bylo default. a liny programatori si na to zvykli a na budouci problemy bylo zadelano. a je snazsi vymenit fs nez kupu programu bez kterejch nemuzu zit (pokud je vubec za co je menit).

    btw, jaka je v tyhle veci situace dneska? uz na to programy nespolehaji?
    Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
    Limoto avatar 1.9.2010 22:50 Limoto | skóre: 32 | blog: Limotův blog
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs

    Spíš se FS patřičně "přiškrtily"

    Heron avatar 2.9.2010 07:53 Heron | skóre: 53 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs

    Pokud mě paměť neklame, tak musely být splněny podmínky:

    1. Tvrdý pád OS, nejčastěji z důvodu chybného HW
    2. Blbě napsaná aplikace, co si není schopná ošetřit zápis důležitých dat na disk (a volání jádra na to jsou)
    3. Konkrétní FS s konkrétním nastavením

    ad 1. Snad k tomu netřeba nic dodávat. Pokud někdo přijde o data vlivem padajícího HW, na vině je HW.

    ad 2. Dobře napsané programy nespoléhají na nedokumentované chování a pokud data na disku potřebují, tak si to zařídí. Což je odpověď na tvoji poslední otázku. Např. aplikace typy DB toto řeší dnes a denně. Pokud vyhovuje ACID, tak po úspěšném příkazu COMMIT tam ta data najdeš bez ohledu na to, co se s PC děje dál.

    ad 3. Pokud někdo ("vývojář" aplikace) spoléhá (v podstatě to nemůže ani ovlivnit) na nějaký konkrétní fs s konkrétním nastavení, je jen dobře, že přijde o data. Mimochodem, v žádné normě není napsané, jak se má FS zachovat v případě špinavého odpojení. Pokud by se vytvořil nový čistý, tak ano, je to v pořádku.

    Co nastalo. První dva body se snad ani neřešily (no Teo se k tomu vyjádřil na svém blogu) a jenom se udělal patch do jádra. Chjo. Takže takyprogramátoři teď mohou prasit vesele dál a když někdo přijde o data na jiném FS, tak za to samozřejmě může ten jiný FS. Tohle je cesta do pekla. To už můžeme rovnou mountovat s volbou sync.

    a liny programatori si na to zvykli a na budouci problemy bylo zadelano. a je snazsi vymenit fs nez kupu programu bez kterejch nemuzu zit (pokud je vubec za co je menit)

    Proč měnit. Ti "programátoři" mohou na místo, kde "řeší" to přejmenování souboru (změna metadat) vložit nějaké volání sync a mají po starostech. Osobně bych předpokládal, že už to mají hotové.

    kotyz avatar 2.9.2010 18:41 kotyz | skóre: 25 | blog: kotyzblog | Radnice
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    a kdo je donuti tam to volani vlozit? mam si to snad vsechno delat sam (ikdybych to snad umel, tak by se mi do toho zrovna dvakrat nechtelo)? a v tech kdeckach 3.5.10 (ktery se budu snazit podrzet na disku co nejdyl to pujde) uz to asi nikdy nikdo opravovat nebude ...
    Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
    9.9.2010 16:22 Atom321 | skóre: 20
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs

    Nemají a nemohou. Ti "Programátoři" to tak měli a fungovalo to dobře. Ovšem, mocný hekr Teo pak v ext3 zprasil implementaci fsync(). Náběh aplikací, toto volání používalo, trval děsivě dlouho. Ovšem, chování fsync() na ext3 odpovídá normě, takže to dodnes nikdo neopravil. "Programátoři" aplikací (KDE, Firefox) byli nuceni to nějak řešit. Využili vedlejších vlastností obvyklých u Linuxových filesystémů, aby ten problém obešli.

    Následně velký Teo v ext4 zcela nesmyslně upřednostnil rychlejší práci s dočasnými soubory před bezpečným uložením dat a tyto vedlejší vlastnosti (opět v souladu s normou) změnil.

    Když ho uživatelé upozornili na vzniklé problémy, zaštítil se alibisticky normou a arogantně všechno svedl na chudáky aplikační programátory. Později až pod hrubým nátlakem nasraného davu to konečně opravil. Ovšem, svou chybu nikdy neuznal a ve stejném duchu dodržování norem bez ohledu na okolní realitu pokračuje dál, takže se máme na co těšit.

    9.9.2010 16:24 Atom321 | skóre: 20
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    uf, oprava: "...aplikací, toto volání používalo..." => "...aplikací, které toto volání používaly..."
    2.9.2010 08:55 Aleš Kapica | skóre: 51 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Nikdy nezaváhal, ale na novou instalaci bych ho nikomu nedoporučil pač je odsouzen k zániku.
    Ale co to blábolíš? Reiserfs s námi bude ještě pěkně dlouhou dobu. Pravděpodobně si ho pleteš s Reiser4, co není v jádře a který zcela jistě nahradí Btrfs.
    1.9.2010 21:17 Let_Me_Be | skóre: 20 | blog: cat /proc/idea/current | Brno
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Nevim jestli to dela i KDE 4, ale stare KDE ty konfiguraky pri aktualizaci vzdy mazalo, takze kdyz pak filesystem udelal rollback ty soubory proste neexistovaly.
    Linked in profil - Můj web - Nemůžete vyhrát hádku s blbcem. Nejdřív vás stáhne na svoji úroveň a pak ubije zkušenostmi.
    kotyz avatar 1.9.2010 22:00 kotyz | skóre: 25 | blog: kotyzblog | Radnice
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    ale u ext3 s defaultnima volbama (ordered mode) to nebyl problem. a holt ty aplikace na to spolehaly a urcite na to nektery spolehaji dodnes. a kdyz to nedostanou a dojde k vypadku tak je pak zle nedobre ...
    Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
    Nicky726 avatar 2.9.2010 00:58 Nicky726 | skóre: 56 | blog: Nicky726
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Ano dělá. Docela jsem se divil, jaká všechna SELinux oprávnění musí mít KDE programy nad svými konfiguráky, aby běžely.
    Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
    1.9.2010 15:22 mike
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Uz nejaky cas resim v podstate totez (takove to domaci "HTPC" na kolene). Vykonnost fs jsem nijak nezkoumal. Chtel jsem tam prdnout ext3/4 nad soft mirror raidem (mdadm) nad 5400 pomalyma-uspornyma tusim Seagaty. Clovek prece jen o tu muziku a filmy nechce prijit, .... (Diskuzi o Raid+mdadm+mirror,atd.. nechme stranou, jde mi o neco jineho)

    ALE: pri hratkach s MythTV jsem zjistil, ze to asi neni vhodne usporadani, protoze MythTv nahrava na co koukate (ziva telka). A to v kombinaci s RAIDem + Ext3/4 nedopadalo vubec dobre. Disky vydavaly opravdu nehezke disky. Chyby zadne. Vykon jsem nemeril, ale bylo jasne, ze takhle tedy ne.

    Bohuzel uz si nepamatuji dalsi detaily, ale po nejakem zkoumani jsem presel na JFS, ktere melo nejakou vlastnost (mozna se musela zapnout ci postelovat), ktera chovani disku, resp. pristup k nim vyrazne vylepsila.

    Samozrejme jde o aplikacni problem (MythTV), vse ostatni jelo uplne normalne. Souvisi to se zpusobem jak MythTv pracuje ( blabla kruhovy buffer blabla... vic si nepamatuju :-)).

    Takze vzhledem k tomu, ze neni neobvykle v linuxovych koncinach provozovat MythTv na HTPC, tak tady je ma zkusenost a navrh na zarazeni MythTv do testovani FS. Evidentne ma pomerne specificky pristup k veci. Pripominam, ze to bylo pri nahravani videa nebo pri zive TV (je totiz nahravana take). Taky je mozne, ze v novych verzich MythTV uz to nejak poresili... Mozna, ze je to spis problem mirror soft raidu... nebo problem ext3/4... Ja to naposledy zkousel pred 3/4 rokem....jen jsem si na to vzpomenul, kdyz jsem videl ten titulek... nic vic... klidne me ignorujte jako neskodneho blazna... :-D

    1.9.2010 17:30 Roger
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    LiveTV se nahrava kvuli timeshiftu - nekde se da nastavit, jak moc mista to ma zabirat.
    6.12.2010 19:03 Kaa
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    To uz se nenastavuje nejmin od 0.21. Ring buffer uz davno neni. Live se flaka do souboru dle EPG stejne jako nahravky .. vyhodu to ma v tom, ze kdyz dodatecne zapnu Rec, tak to z live spadne do nahravek, zmeni se jen atribut.
    1.9.2010 20:41 pozortucnak | skóre: 21 | blog: vecny_windowsar
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Nevíte jak velkou výkonnostní ztrátu představuje u ext3/4 data=journal?

    Potřebuji nějaké datové úložiště které by rychle startovalo(takže pokud možno žádný fsck) a které by vydrželo několik restartů za sebou...

    Btrfs jsem vyloučil jako příliš experimentální, zfs přes fuse - to by výkonnostně dobré nebylo... a nakonec mě napadlo zkusit ext3/4 s data=journal...
    Jsem mimořádně obtížný případ
    gtz avatar 1.9.2010 21:25 gtz | skóre: 27 | blog: gtz | Brno
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Disky budete dávat do mirroru? nebo budou jen sólo? Dnešní kvalita těchto velkých disků stojí někdy za pendrek. Pokud budou sólo pro jistotu bych radil použít nějaké disky určené pro servery (RE nebo ES). Já bych asi na data volil nějaký FS, který se dá v případě nějaké havárie bezpečně obnovit v Linuxu. Právě u EXT4/XFS jsou tyto obnovy na pár dlouhých večerů.
    - nejhorší jsou trpaslíci ... Ti Vám vlezou úplně všude
    1.9.2010 21:41 pozortucnak | skóre: 21 | blog: vecny_windowsar
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Disky budou sólo. S ext4 nemám žádné zkušenosti...

    Stejně bych asi rád zůstal u ext3... Co je pravdy na tom že kontrola integrity dat je u ext4 rychlejší?

    Ono zas o tolik nejde, je o počítač sloužící jako datové úložiště, s běžícím motion a časem s TV kartou vysílající do sítě...
    Jsem mimořádně obtížný případ
    Limoto avatar 1.9.2010 22:47 Limoto | skóre: 32 | blog: Limotův blog
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Co je pravdy na tom že kontrola integrity dat je u ext4 rychlejší?

    Je to pravda a je to znát ;-)

    gtz avatar 1.9.2010 23:44 gtz | skóre: 27 | blog: gtz | Brno
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Ono zas o tolik nejde, je o počítač sloužící jako datové úložiště

    pokud půjde jen o nějaký NAS, tedy jen o nějaké úložiště, pak bych se klonil k EXT3. V případě nějakého průseru - pádu disků apod. kdy by se musely data nějak obnovovat u EXT4/XFS je to na hodně dlouho a spolehlivě se struktura neobnoví. Problém je i, pokud na EXT4/XFS náhodou něco smažete a pak zjistíte, že to budete potřebovat pak je to celkem problém. U EXT3 se to nějak dá obnovit.
    - nejhorší jsou trpaslíci ... Ti Vám vlezou úplně všude
    Limoto avatar 1.9.2010 22:48 Limoto | skóre: 32 | blog: Limotův blog
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs

    Dík za test.

    2.9.2010 21:36 Non_E | skóre: 24 | blog: hic_sunt_leones | Pardubice
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Jaké bylo nastavení jednotlivých filesystémů? Zajímá mě, co se z fs a disku dá vytáhnout maximálně, ne defaultně.
    Only Sith deals in absolutes.
    Bedňa avatar 25.9.2010 01:15 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs
    Ja osobne verím jedine stres testom, tie napodobujú reálnu prevádzku. Pred možno dvoma mesiacmi tu niekto na taký test hodil link. Ja z ReiserFS (nie Reiser4) som mal niekoľkonásobne lepšie výsledky ako ext4. Bez urážky test jednoúčelových operácií nemá z reálnou prevádzkou nič spoločné a ani žiadnu výpovednú hodnotu. Pozriem či som do tej diskuzie prispel ak áno, hodím sem link.
    KERNEL ULTRAS video channel >>>

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.