Dotaz: ZFS kapacita při raidz2

[Vladimír Pilný]

Dobrý den,

zkoušíme přejít na Debianu 6 na ZFS (aktuální build ZFS on Linux). Doposud jsme používali 12 x 3TB HDD (tj. 36 TB, 32,7 TiB) v RAID-6 poli (mdadm) a JFS. Využitelná kapacita takového oddílu byla 30,0 TB (27,3 TiB). Což je v pořádku (36 - 6 TB).

Když z těch 12 celých disků vytvoříme zpool typu raidz2 (což má odpovídat RAID-6, redundance 2 disků ověřena), tak zpool list píše SIZE 32.5TB a po přimountování celého zpoolu je velikost oddílu 26,8 TB (24,4 TiB).

Pokud vytvoříme zpool z 10 HDD bez redundance raidz variant, je výsledná kapacita 29,4 TB (26,8 TiB). Což je rozumnější velikost. A obdobné testy s mnohem menšími disky (loopback zařízení) dávají i v raidz režimech také mnohem menší procentuální ztrátu kapacity.

Kam se tedy podělo těch 2,9 TiB v případě raidz2 režimu? Opravdu má ZFS u velkých disků tak velkou režii (~10 %) nad rámec samotné redundance paritních disků a nejde s tím něco udělat? Děkuji.

Odpovědi

[JanM]

K té "režii" nic nenapíšu, ale v každém případě počítejte ještě s doporučením udržovat využití kapacity pole tak do 80 %, v opačném případě bude klesat rychlost zápisu (tuším), neb použitý mechanismus Copy On Write bude mít více potíží najít souvislé volné bloky čili hlavičky budou létat nad diskovými plotnami jak lesní včelky...

[anonym]

ZFS ma hodne ruznych metadat, v ramci konzistence dokonce v nekolika kopiich (dataset metadata ve 2, pool metadata ve 3), vsechno vcetne checksumu (nevim jestli se "rezervujou" predem nebo az pri alokaci). prave diky checksumum a kopiim (a dlouhym cislum, 128bit FS) jsou i block pointery dlouhe, takze je potreba vic gang blocku (indirect block pointer)

druha vec co "ubira" vyrazne kapacitu je princip jak se chova k neuplnym stripum - parita se dela pro kazdy objekt (soubor), takze v raidz2 s malymi soubory je rezie 8KB na soubor, coz je vyrazne vic nez 1/6 disku

Proste ZFS jako takove neni delane na to aby vyuzilo kazdy zbytecek mista nebo vykonu, je delane na to ze kdyz si koupim velke enterprise pole za spoustu penez tak mi nebude data samovolne casem ztracet

zkusil bych se spis zeptat na webu ZoL, tam lidi vedi jak to vypada on-disk

[Vladimír Pilný]

Aha, takže je to prostě vlastnost ZFS a nejde to nějakým přepínačem poladit, obdobně jako např. výchozí % rezervovaných bloků u ext oddílů?

Co mě však mate, je dost podivná závislost velikosti výsledného oddílu oproti kapacitě vstupních disků pro různý počet HDD. Udělal jsem pokus ještě s 8 a 10 HDD a procentuálně to vychází následovně (2 paritní disky vždy odečteny):
8 HDD ... 92,98 %
10 HDD ... 93,61 %
12 HDD ... 89,31 %

Varianta s 8 malými vstupními disky (2GiB loopback) pak má 97,41 % očekávané kapacity. A to je zvláštní nepoměr oproti 92,98 % u identicky konfigurovaných 3TB disků. Malé zpooly se od velkých snad nemůžou lišit ničím víc, než hloubkou úrovní indirect block pointerů, ne?

Jinak všechny oddíly byly prázdné a tudíž způsob a místo obsazené soubory v tuto chvíli neřeším.

Nejvíc mě ale překvapilo, že se o tomto jevu nikde nepíše.

[lertimir]

Nepracuji ze ZFS tak jen obecnější odhad. ZFS je značně komplexní file system, který provádí významné optimalizace, všechny optimalizace v takových systémech směřují ke spolehlivosti a rychlosti, ne k efektivitě ukládání. Myslím, množství dat, které ZFS ukládá a zpracovává na optimalizaci není lineární s používanou kapacitou, ale mocnina je vyšší než 1, do nějakého poměru. Podobně požadavky na operační paměť jsou pro efektivní běh ZFS také větší než např. u linuxových ext filesystémů. Mimochodem kolik paměti máte pro takového pole?

[Vladimír Pilný]

32 GB, zvažujeme nasazení na dalším 12 diskovém serveru s 16 GB.

[Vladimír Pilný]

Na ZoL jsem konečně našel někoho, kdo přehledně popisuje stejný jev https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups=#!topic/zfs-discuss/foHyK7br0Fk

Vysvětlení je jen částečně, ale bohužel směřuje k domněnce, že ztracená kapacita není v ZFS využita efektivně, ale jako odpad posledního stripu nad velikost ZFS bloku.

[lertimir]

No to je podle mne dobrá zpráva. Protože když provedete ZFS nad 10 nebo 18 disky pro RAID 6 dostanete 100% využití kapacity bez ztrát. A v podstatě je to jen o tom jaké koupíte řadiče disků. Je to jen informace, nedá se to plácat zcela jakkoliv, ale pravidla jsou pochopitelná.

[Vladimír Pilný]

Bohužel to je složitější o to, že nezáleží jen na počtu disků, ale i jejich kapacitě, viz mé testy s menšími loopback zařízeními. Například pro "optimální" počet 10 u 2TB disků nezískáte 100 % kapacity, ale 93,5 %, viz měření Adriana Tsaie.

Docela by mě zajímala, jaká je mezní (maximální) ztráta kapacity v nejhorším možném případě.

ZFS se nám dost líbí, ale designování úložišť s ohledem na počet disků = mocnina dvou + redundantní a ještě závislé na kapacitě tedy jako dobrou zprávu nevnímáme, když hloupý mdadm v RAID-6 využívá vždy 100 % kapacity.

[lertimir]

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%

[Vladimír Pilný]

Děkuji za reakci, nicméně já nerozporuji nic z ostatních vlastností ZFS coby spojení FS a RAID vrstvy, která přináší logicky nemálo výhod. Šlo mi skutečně jen o tu užitečnou kapacitu a zda s tím lze něco dělat, nebo ne.

A stále mi připadá zvláštní, že se o této vlastnosti téměř nikde nemluví. Zřejmě patří ZFS do lepší společnosti, kde se nad promrhanými 10 % kapacity jen velkoryse mávne rukou.

Co se týče výkonu, tak jsme dělali základní testy a náhodné i sekvenční zápisy vypadají skutečně lépe než u ext4/jfs; čtení rychlejší není. Nejdůležitější ale bude chování v reálném prostředí na zaplněnějším poli a to se teprve uvidí.

[lertimir]

Jak jsem psal ZFS nepoužívám, tak přímou radu nemohu dát. Ale očekával bych, že když se zeptáte na stav filesystému s nejvyšší úrovní verbosity, tak vyjeví jaké sektory má na co. A dají se posčítat.

[disposable]

Keďže píšete o zfsonlinux na Debiane, zaujíma ma ako riešite automatický mount. Pokiaľ viem zfs do /etc/fstab dať nemôžete. Ja musím vždy po reštarte môjho home servera ručne zadať "zfs mount -a". Ubuntu má aplikáciu "mountall" ktorá toto obstaráva, ale Debian nič podobné nemá.

[Vladimír Pilný]

ZFS jsme na zkoušku nasadili na 2 servery s Debianem a na každém instalovali zfsonlinux trochu jinak. Na jednom jsem v

/etc/default/zfs

změnil

ZFS_MOUNT='yes'

a funguje to. Na druhém tam onen soubor není, ale

/etc/init.d/zfs restart

zdá se mountování provádí automaticky. Ten druhý server jsme však ještě nemohli restartovat, tak uvidíme.

[Vladimír Pilný]

Tak na druhém serveru bylo potřeba

update-rc.d zfs enable

A už se mountuje automaticky také.

[disposable]

dakujem za tie informacie

[anonym]

pripadne v ZFS nastavit property mountpoint=legacy, a resit pomoci fstab jako vzdycky