Administrace komentářů

Jednak se omlouvám, že mluvím o něčem, co moc neznám, ale efektivita by měla záviset primárně od velikosti ZFS bloku. Pokud byste definoval ZFS bloky na malou velikost mělo by se využití zlepšit.

mdadm sice využije 100%, ale moje zkušenosti ukazují, že i na RAID 5 je velmi pomalý ve všech situacích, kdy na file systému se pracuje s čímkoliv menším než je velkost stripu RAIDu a ještě je třeba, aby ten datový objekt byl zarovnaný se stripem. Protože když budu zapisovat jeden 4k blok do raidu 5 tak nejdříve musí načíst ten blok který budu přepisovat, načíst paritní blok, udělat XOR všech tří bloků (starý XOR nový XOR stará parita = nová parita) a zapsat nový blok a paritní. (pokud je v paritním bloku čistá parita), čím více bloků do stripu píšu, tím víc bloků musím číst z různých disků a tím mi to trvá déle, protože všechny disky musí "seekovat" jak čtení tak zápis. Pouze v případě, že zapisuji celý strip nemusím z toho stripu nic dopředu číst, ale čím mám více disků, tím více musím naráz napsat, abych měl plný strip, a taky bych měl začít psát na začátku stripu.

mdadm stripy nijak neřeší, dokonce ani nedá file systému nad sebou info, že je něco jinak než prostý disk. Takže soubory na začátku stripu nezačínají, file systém bloky nijak neoptimalizuje a náročnější operace celé pole rozdrnčí, ale propustnost je nízká. A RAID 6 je z výkonového pohledu horší než RAID 5.

Očekával bych vazbu optimalizace ZFS RAIDu přimo na blokovou strukturu filesystému a odtud zdroje ztrát a zase je to otázka výkonu proti efektivitě. Pokud je to zálohovací server tak to asi důležité není, ale pokud tam bude nějaká produkce, tak bych zkoušel testy výkonu. Jen tak mimochodem (je to sice zcela jiná kategorie) pro můj domácí server, kde mám 4x1,5TB v madadm RAID 5, když se spustí zalohovací program BackupPC, který zálohuje ostatní domácí systémy pomocí rsync, tak faktická rychlost je dost nízká pro inkrementální backupy a přitom zobrazení přes atop popisuje vytížení na /dev/sdx skoro na 100%