Fórum Root.cz

Hlavní témata => Server => Téma založeno: Petr Kratochvíl 03. 03. 2016, 16:48:41

Název: ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Petr Kratochvíl 03. 03. 2016, 16:48:41
Zdravím,

koupil jsem klasický 8 TB SATA disk, vytvořil mdadm RAID 1, v něm dm-crypt/LUKS, v něm ZFS pool verze 23 (kvůli kompatibilitě se ZFS-FUSE), vytvořil několik subvolume a nastavil [dedup=on,compression=gzip,checksum=on,atime=off]. Přidal jsem cache a log na SSD disku. Disk jsem téměř celý zaplnil celkem řádově miliony souborů a desítky snapshotů. Software je Linux Mint 17.1 s jádrem 3.13.0-37-generic, k ZFS přistupuji přes ubuntu-zfs (http://zfsonlinux.org/) a používám zfs-auto-snapshot.

Zlobí zápis na disk přes "ZFS on Linux" (http://zfsonlinux.org/). Při ukládání většího souboru přes rsync, cp, dd, ... se nejprve ukládá rychlostí kolem 40 MB/s cca 400 MB a pak se na několik minut ukládající proces pozastaví a takto střídavě pořád dokola. V příkazu top je vidět velká aktivita disku a procesu myslím z_wr_iss. Nepříjemné je to, že při tom pozastavení procesu jsou pozastaveny všechny procesy, které provádí zápis na pool nebo nějakou náročnější operaci s poolem. Toto pozastavení zápisů na několik minut dělá problémy např. při stahování souboru z internetu. Mám podezření na zaplnění cca 400 MB bufferu v RAM, který pak blokuje zápis na pool dokud se nevyprázdní na fyzický disk, což probíhá rychlostí kolem 1 MB/s. Lze nějak velikost tohoto bufferu snížit?

Podobně se chová i mazání snapshotů, při kterém dochází k údajné zátěži systému ("load") kolem 100 a po několika hodinách mazání přestává být systém ovladatelný na dálku a je nutný hardwarový restart. Ukládání většího souboru se pokaždé úspěšně dokončí střídáním dvou fází zmíněných výše, v dlouhodobém průměru rychlostí kolem 1 MB/s, ohledně které mám podezření na zpomalení deduplikací, což bych ještě akceptoval.

Zkusil jsem implementaci ZFS-FUSE, ale kromě toho, že postrádá některé funkce (např. mountování snapshotů), jiné zlobí (např. záhadný problém s oprávněními, kde pomohl chown na uživatele, který ale již byl nastaven), tak navíc mám špatné zkušenosti se stabilitou. Asi po hodině používání najednou adresáře s daty na ZFS začaly házet chybu myslím "Transport endpoint is not connected". Na druhou stranu data zapisoval plynule rychlostí cca 1 MB/s.

Zvažoval jsem přechod z Linux Mint nebo Debian-based OS obecně na OpenSolaris, ten je ale kvůli Oracle "discontinued". Zvažuji proto přechod na nástupce jménem OpenIndiana, ale byla by to celkem velká změna a nevím, jak moc kvalitní je implementace ZFS v OpenIndiana.

Dříve jsem používal Btrfs, ale chybí mu např. in-band deduplikace a také pokus o zapnutí quota systému na plném 8 TB disku běžel několik dní s pozastavením všech zápisů na disk, následovaným vynuceným hw restartem. Naštěstí data poškozena nebyla.

Právě v tomto okamžiku čekám už 2 hodiny na smazání jednoho snapshotu, po úspěšném nebo neúspěšném dokončení budu moci zjistit k problémům výše na požádání detaily.

Doporučte prosím buď řešení zmíněného "buffer" problému s Native ZFS na Linuxu a nebo spolehlivou implementaci ZFS na kterémkoliv open-source OS a nebo jiný souborový systém s funkcemi ZFS. Potřebuji spolehlivost a co největší plynulost zápisu a čtení, není prioritou rychlost. Zkusím pozastavit vytváření snapshotů utilitou zfs-auto-snapshot, ale myslím, že už jsem to jednou marně zkusil. Navíc k pozastavení zápisů na pool dochází spíše po zaplnění cca 400 MB bufferu než periodicky např. každé 4 minuty.

Pokud máte zkušenosti s něčím zmíněným výše na několika TB disku nebo poli s miliony nebo více souborů, budu za ně rád.

Děkuji za přečtení delšího textu, nechtěl jsem vynechat nic podstatného.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: trubicoid2 03. 03. 2016, 16:54:08
jenom ten zacatek uz je divnej: mdadm-raid1 na nem LUKS na nem ZFS
melo by byt bez mdadm, disky jsou dva? na kazdej disk zvlast LUKS se stejnym klicem/passphrase a nad nimi ZFS-RAID1
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: trubicoid2 03. 03. 2016, 17:00:43
a myslím problém bude s tou deduplikací, kolik máš ram? máš l2arc? já měl deduplikaci jen na 4T (půlka plná) zapnutou a s 16GB RAM to dělalo velmi velké problémy, musel jsem deduplikaci vypnout.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Kolemjdoucí 03. 03. 2016, 17:07:05
Není to disk který byl podezřele levný kvůli tomu že používá SMR (shingled magnetic recording)? Zápis na takové disky prostě je po zaplnění jejich cache pomalý a nedá se s tím nic dělat, za to ZFS nemůže...
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Petr Kratochvíl 03. 03. 2016, 17:13:40
jenom ten zacatek uz je divnej: mdadm-raid1 na nem LUKS na nem ZFS
melo by byt bez mdadm, disky jsou dva? na kazdej disk zvlast LUKS se stejnym klicem/passphrase a nad nimi ZFS-RAID1

Je to jen 1 disk o kapacitě 8 TB. Mám v úmyslu kapacitu navyšovat přikupováním 8 TB disků dle finančních možností a přitom upgradovat RAID 1 na RAID 5, resp. RAID 6. Proto jsem vytvořil 1 diskový RAID už na začátku (vím, zní to divně). Pokud bych na fyzický disk umístil rovnou zašifrovaný ZFS pool, nedokázal bych ho po přikoupení disků zkonvertovat na mdadm RAID 5, resp. RAID 6.

Bojím se mít každý disk šifrovaný zvlášť a až na tom ZFS RAID, protože jednak ZFS RAID moc neumím a pak nevím, zda umí funkce jako mdadm včetně konverze RAID 5 na 6 (resp. RAIDZ na RAIDZ2) nebo dokonce naopak, obzvláště v nativní Linuxové open-source implementaci "ZFS on Linux". Trochu se také bojím abych omylem nezapomněl některý z disků "dešifrovat" a nezkusil v tom stavu zfs import.

Máte na některém OS dobré zkušenosti s RAIDZ a RAIDZ2 včetně konverze mezi nimi?
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Petr Kratochvíl 03. 03. 2016, 17:20:29
a myslím problém bude s tou deduplikací, kolik máš ram? máš l2arc? já měl deduplikaci jen na 4T (půlka plná) zapnutou a s 16GB RAM to dělalo velmi velké problémy, musel jsem deduplikaci vypnout.

Mám sice jen 4 GB RAM, ale swap 16 GB je téměř vždy prázdný. Jsem si vědom, že by to mohlo zpomalovat zápis na disk, ale rozhodně jsem nečekal problémy s plynulostí zápisu. Matně si vzpomínám, že vypnutí dedup nepomohlo, ale mohu to zkusit po příštím restartu (mazání snapshotu stále běží).

L2ARC je téměř 100 GB, pokud se nemýlím a je společně s logem na SSD disku:

Kód: [Vybrat]
                                            capacity     operations    bandwidth
pool                                     alloc   free   read  write   read  write
---------------------------------------  -----  -----  -----  -----  -----  -----
all                                      6,95T   304G     94      0   237K  1,45K
  dm-name-all                            6,95T   304G     94      0   237K  1,35K
logs                                         -      -      -      -      -      -
  ata-CT250BX100SSD1_1532F00A52C0-part6      0    80M      0      0    137     95
cache                                        -      -      -      -      -      -
  ata-CT250BX100SSD1_1532F00A52C0-part5  1,19G  96,6G     62     32   151K   174K
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Petr Kratochvíl 03. 03. 2016, 17:28:15
Není to disk který byl podezřele levný kvůli tomu že používá SMR (shingled magnetic recording)? Zápis na takové disky prostě je po zaplnění jejich cache pomalý a nedá se s tím nic dělat, za to ZFS nemůže...

Zní to zajímavě, děkuji. Leč hned po koupi jsem provedl nějaké testy, při kterých sekvenční zápis byl podstatně rychlejší než 1 MB/s. Každopádně primárně řeším plynulost zápisu. Aby ten ZFS pool neměl každou chvíli na několik minut pozastavené veškeré zápisy. Potřebuji aby šlo na pool kdykoliv zapisovat, i kdyby nízkou rychlostí.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Mirek Prýmek 03. 03. 2016, 19:01:51
Zní to zajímavě, děkuji. Leč hned po koupi jsem provedl nějaké testy, při kterých sekvenční zápis byl podstatně rychlejší než 1 MB/s.
Disk nemůže zapisovat rychlostí 1MBps, máš tam něco zatraceně špatně.

Být tebou, řeším vrstvu po vrstvě - prvně rychlost zápisu na holý disk (bez jakéhokoliv FS), potom s další vrstvou, s další vrstvou...

Mám trochu podezření na to, jestli ti ten LUKS jede přes AES-NI... 1MBps by byl sice dost málo i bez ní, ale jeden z hlavních podezřelých to je.

Každopádně primárně řeším plynulost zápisu. Aby ten ZFS pool neměl každou chvíli na několik minut pozastavené veškeré zápisy. Potřebuji aby šlo na pool kdykoliv zapisovat, i kdyby nízkou rychlostí.
Pokud ti to opravdu zapisuje rychlostí 1MBps a data tam hrneš rychleji, tak se tohle prostě nevyhnutelně stane, co jiného by se mělo stát? Buffer by bobtnal donekonečna...

Bojím se mít každý disk šifrovaný zvlášť a až na tom ZFS RAID, protože jednak ZFS RAID moc neumím a pak nevím, zda umí funkce jako mdadm včetně konverze RAID 5 na 6 (resp. RAIDZ na RAIDZ2) nebo dokonce naopak, obzvláště v nativní Linuxové open-source implementaci "ZFS on Linux".
Rozhodně potřebuješ RAID na úrovni ZFS, jinak se zbytečně připravuješ o jeho vlastnosti a zbytečně to kombinuješ s další vrstvou, která nic neví o datech nad ní. Je to špatně a nedělej to tak.

Přidávat disky po jednom v ZFS nejde, musíš si buď dopředu připravit scénář, který pro ZFS funguje, nebo se musíš připravit, že v určitém stádiu budeš muset všechna data odlít pryč a vytvořit nový pool.

Není to nic, co by ses musel kdovíjak učit. Stačí si to prostě vyzkoušet na par loop-devicech...

Zvažoval jsem přechod z Linux Mint nebo Debian-based OS obecně na OpenSolaris, ten je ale kvůli Oracle "discontinued". Zvažuji proto přechod na nástupce jménem OpenIndiana, ale byla by to celkem velká změna a nevím, jak moc kvalitní je implementace ZFS v OpenIndiana.
Určitě o několik řádů kvalitnější než na Linuxu :)

Nicméně pokud se ti nechce do Solarisích klonů, na FreeBSD už je ZFS mnoho let a je už slušně vychytané.

a myslím problém bude s tou deduplikací, kolik máš ram? máš l2arc? já měl deduplikaci jen na 4T (půlka plná) zapnutou a s 16GB RAM to dělalo velmi velké problémy, musel jsem deduplikaci vypnout.

Mám sice jen 4 GB RAM
NO WAY!

Citace
A general rule of thumb is 1 GB of RAM for every 1 TB of storage. If the deduplication feature is used, a general rule of thumb is 5 GB of RAM per TB of storage to be deduplicated.
https://www.freebsd.org/doc/handbook/zfs-advanced.html

...čili máš desetkrát míň RAM než je na tolik dat doporučeno.

Citace
, ale swap 16 GB je téměř vždy prázdný.
Se swapem to imho nemá co dělat.

Citace
L2ARC je téměř 100 GB, pokud se nemýlím a je společně s logem na SSD disku:
L2ARC je read cache, která se použije jenom v případě, že čteš data, která nejsou nacachovaná v RAM. Pokud z poolu nečteš, nepoužije se ani 1B L2ARC :) Takže s tvými problémy se zápisem to nijak nesouvisí.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Mirek Prýmek 03. 03. 2016, 19:06:39
compression=gzip
Gzip je špatná komprese. Pokud tvoje verze ZFS podporuje něco jiného, použij to v tomhle pořadí:

LZ4 > LZJB > GZIP
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Petr Kratochvíl 03. 03. 2016, 19:58:34
Zní to zajímavě, děkuji. Leč hned po koupi jsem provedl nějaké testy, při kterých sekvenční zápis byl podstatně rychlejší než 1 MB/s.
Být tebou, řeším vrstvu po vrstvě - prvně rychlost zápisu na holý disk (bez jakéhokoliv FS), potom s další vrstvou, s další vrstvou...
Ok, mohu zkusit zápis náhodných dat na blokové zařízení na kterém je nyní ZFS. Napřed bych zazálohoval třeba 10 GB na jiný disk, přepsal je náhodnými daty a pak původní data vrátil. Tím by se předpokládám nemělo nic stát, když to zařízení nebude používané a dám si pozor na to, co zadávám za parametry. Co zkusit dál pokud zjistím, že ta rychlost je podstatně vyšší a hlavně plynulá?

Mám trochu podezření na to, jestli ti ten LUKS jede přes AES-NI... 1MBps by byl sice dost málo i bez ní, ale jeden z hlavních podezřelých to je.
Jak bych prosím mohl zjistit?

Každopádně primárně řeším plynulost zápisu. Aby ten ZFS pool neměl každou chvíli na několik minut pozastavené veškeré zápisy. Potřebuji aby šlo na pool kdykoliv zapisovat, i kdyby nízkou rychlostí.
Pokud ti to opravdu zapisuje rychlostí 1MBps a data tam hrneš rychleji, tak se tohle prostě nevyhnutelně stane, co jiného by se mělo stát? Buffer by bobtnal donekonečna...
Představme si uzavřenou nádrž na vodu, do které velkým jednosměrným horním otvorem vodu přiléváme a druhým malým otvorem dole vytéká. Pokud tuto nádrž naplníme, voda odtékat nepřestane, akorát se nám bude dařit ji přilévat stejnou rychlostí, jakou odtéká. Nestane se, že by najednou vůbec nešla přilévat až do doby, kdy bude nádrž prázdná. Představoval bych si, že data do plného bufferu půjdou přidávat stejnou rychlostí, jakou se z něj zapisují na fyzický disk.

Bojím se mít každý disk šifrovaný zvlášť a až na tom ZFS RAID, protože jednak ZFS RAID moc neumím a pak nevím, zda umí funkce jako mdadm včetně konverze RAID 5 na 6 (resp. RAIDZ na RAIDZ2) nebo dokonce naopak, obzvláště v nativní Linuxové open-source implementaci "ZFS on Linux".
Rozhodně potřebuješ RAID na úrovni ZFS, jinak se zbytečně připravuješ o jeho vlastnosti a zbytečně to kombinuješ s další vrstvou, která nic neví o datech nad ní. Je to špatně a nedělej to tak.
Ok, tuto zkušenost respektuji. Chtěl bych se zeptat, připravuji se o nějaké jiné vlastnosti než jen výkon? A mohu se na RAIDZ a RAIDZ2 spolehnout v Linuxových implementacích "ZFS on Linux" a "ZFS-FUSE"? A umí už ZFS konverzi RAIDZ na RAIDZ2?

Přidávat disky po jednom v ZFS nejde, musíš si buď dopředu připravit scénář, který pro ZFS funguje, nebo se musíš připravit, že v určitém stádiu budeš muset všechna data odlít pryč a vytvořit nový pool.
A právě proto jsem chtěl RAID řešit přes mdadm, aby přidávat disky bylo možné.

Není to nic, co by ses musel kdovíjak učit. Stačí si to prostě vyzkoušet na par loop-devicech...
Děkuji za povzbuzení. Nějak takto jsem se loni trénoval v práci s mdadm RAIDy.

Zvažoval jsem přechod z Linux Mint nebo Debian-based OS obecně na OpenSolaris, ten je ale kvůli Oracle "discontinued". Zvažuji proto přechod na nástupce jménem OpenIndiana, ale byla by to celkem velká změna a nevím, jak moc kvalitní je implementace ZFS v OpenIndiana.
Určitě o několik řádů kvalitnější než na Linuxu :)
Takže předpokládám správně, že implementace ZFS v OpenIndiana vychází z implementace v OpenSolaris? Funguje na OpenIndiana hardware bez problémů a lze doinstalovat KDE či xfce? Vyvíjí se vůbec aktivně OpenIndiana?

Nicméně pokud se ti nechce do Solarisích klonů, na FreeBSD už je ZFS mnoho let a je už slušně vychytané.
Aha, to je dobré vědět, děkuji. Jen na tom nechápu: Myslel jsem, že Linux je rozšířenější než FreeBSD či OpenIndiana, tj. software by měl být pro Linux obecně lépe odladěný. Je to jinak?

Mám sice jen 4 GB RAM
NO WAY!
Why? Snížení rychlosti bych chápal, ale vážné narušení plynulosti zápisu moc nechápu.

Citace
A general rule of thumb is 1 GB of RAM for every 1 TB of storage. If the deduplication feature is used, a general rule of thumb is 5 GB of RAM per TB of storage to be deduplicated.
https://www.freebsd.org/doc/handbook/zfs-advanced.html

...čili máš desetkrát míň RAM než je na tolik dat doporučeno.
...čili mám desetkrát míň RAM než je na tolik dat doporučeno. Chápu tím vysvětlení zápisu 1 MB/s, ale ne problémů s plynulostí.

Citace
, ale swap 16 GB je téměř vždy prázdný.
Se swapem to imho nemá co dělat.

Citace
L2ARC je téměř 100 GB, pokud se nemýlím a je společně s logem na SSD disku:
L2ARC je read cache, která se použije jenom v případě, že čteš data, která nejsou nacachovaná v RAM. Pokud z poolu nečteš, nepoužije se ani 1B L2ARC :) Takže s tvými problémy se zápisem to nijak nesouvisí.
Hashe používané při deduplikaci se při čtení nijak necachují? Dokáži si představit situace, kdy by se to hodilo.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Petr Kratochvíl 03. 03. 2016, 20:16:32
compression=gzip
Gzip je špatná komprese. Pokud tvoje verze ZFS podporuje něco jiného, použij to v tomhle pořadí:

LZ4 > LZJB > GZIP
Používám ZFS verze 23 kvůli kompatibilitě se ZFS-FUSE kdyby se objevily nějaké vážné problémy se ZFS on Linux. Ta umí LZJB a GZIP, ale neumí LZ4.

LZJB je lepší než GZIP? Jak jsem již uvedl, o rychlost mi moc nejde, proto upřednostňuji efektivitu komprese, která by měla být u GZIP obvykle lepší než u LZJB.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Mirek Prýmek 03. 03. 2016, 20:49:09
LZJB je lepší než GZIP? Jak jsem již uvedl, o rychlost mi moc nejde, proto upřednostňuji efektivitu komprese, která by měla být u GZIP obvykle lepší než u LZJB.
Jo, tak pokud ti nejde o výkon a jde o kompresi, tak pak gzip. Můžeš zvážit i jinou úroveň - gzip-7, gzip-8... ale rozdíly jsou malé a CPU penalizace je velká. Záleží na tobě, musíš si sám udělat benchmarky, co ti bude vyhovovat.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: technik007 03. 03. 2016, 20:58:46
Zdravim,
mam se ZFS filesystemem par let zkusenosti. Taky jsem se dostal do takove patove situace s nizkym vykonem.
Vykon muze zlepsit dodatecna ssd cache, ale na zacatku byla zvolena v tomto pripade nevhodna kombinace mdadm + luks + zfs.

1) mdadm:
ZFS umi raid 1, takze mdadm je zbytecna mezivrstva, ktera muze za urcitych podminek snizovat vykon. ZFS mirror ma vyzkouseny. Pri cteni se pouzivaji oba disky najednou, takze lze ziskat az dvojnasobny vykon. U zapisu samozrejme ne, data se zapisuji do obou najdenou. Pokud se pri cteni zjisti, ze jeden disk "nestiha", tak se zacne balancovat vykon mezi disky, tzn. system zacne pozadovat vice dat z mene zaneprazdneho.

2) ZFS fuse: "fuse" verze bohuzel je vzdycky pozadu za "normalni" verzi a clovek tim prichazi o posledni opravy. Navic fuse implementace z principu ma nizsi prioritu a tim horsi vykon nez filesystem pridany do kernelu.

3) deduplikace: s 8TB na ni bohuzel nemas dostatek pameti. Taky jsem s ni koketoval, po problemech s vykonem jsem ji vypnul, ale i pak obcas jsem mel problemy, kdyz se zacly cist deduplikovane data ( 8GB RAM a 4TB disk). Taky scrub celeho disku se na deduplikovanych datech brzdil moc.

Takze po mych zkusenostech bych dopurucil, smazat jeden z disku (jestli jsem pochopil spravne, tak mate mirror a ten je o minimalne dvou discich), samozrejme pokud je pole konzistentni. Doporucuji na nem nedelat nic a scrubnout ho. Bude to trvat rekl bych den, dva. A pak, jestli je pole konzistentni, vypnout system, zapojit jenom jeden z disku, ten smazat, vytvorit na nem luks particii, na ni pak novy zfs filesystem pouze s kompresi - zpomenout na dedup !!!! , vypnout pc, zapojit oba disky, po zapnuti prekopirovat data mezi disky, pak znicit puvodni zfs pole. Pak novy luks, a pridat k nove vytvorenemu filesystemu mirror disk. No a pak se kochat, jak se data kopiruji.

Mohl bych do rozvest i do prikazu a i bez vypinani pc (data safety feature).
Takze zaverem znova: ne deduplikaci !!! a fuse-zfs ? a mit starou verzi s old bugama? To ne, to vazne ne. Zadne kompromisy !
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Mirek Prýmek 03. 03. 2016, 21:07:27
Ok, mohu zkusit zápis náhodných dat na blokové zařízení na kterém je nyní ZFS. Napřed bych zazálohoval třeba 10 GB na jiný disk, přepsal je náhodnými daty a pak původní data vrátil. Tím by se předpokládám nemělo nic stát, když to zařízení nebude používané a dám si pozor na to, co zadávám za parametry. Co zkusit dál pokud zjistím, že ta rychlost je podstatně vyšší a hlavně plynulá?
No to je hodně velká prasárna. Můžeš to udělat, pokud 1. tam nemáš data, na kterých ti záleží, 2. budeš přesně vědět, co děláš, 3. nebudeš to dělat na "klidném", ale na úplně odpojeném FS, to znamená "zpool export ...". Každopádně ale potřebuješ vyzkoušet i ty další vrstvy.

Jak bych prosím mohl zjistit?
LUKS jsem nikdy nepoužíval, takže přesnou radu nechám na kolegy. Obecně musíš mít podporu AES-NI v jádře (měla by být běžně) a LUKS musí používat šifru, kterou AES-NI podporuje.

Představme si [...] Představoval bych si, že data do plného bufferu půjdou přidávat stejnou rychlostí, jakou se z něj zapisují na fyzický disk.
Není tak úplně důležité, co si představujeme, ale jak to reálně funguje ;) ZFS je dost složitá věc samo o sobě a ty mu tam přidáváš ještě dvě vrstvy navíc, takže jak se to reálně chová nejseš imho vůbec schopnej odhadnout.

Ok, tuto zkušenost respektuji. Chtěl bych se zeptat, připravuji se o nějaké jiné vlastnosti než jen výkon?
Připravíš se o všechny vlastnosti, které využívají toho, že ZFS ví, co jsou živá data, zatímco mdraid to neví. Čili stoprocentně si způsobíš to, že při výpadku bide probíhat resilvering celého disku, zatímco ZFS by resilverovalo jenom živá data.

Předpokládám, že se připravíš i o nějaké optimalizace zápisu, ale to neumím pozitivně říct, je to jenom odhad.

A mohu se na RAIDZ a RAIDZ2 spolehnout v Linuxových implementacích "ZFS on Linux" a "ZFS-FUSE"? A umí už ZFS konverzi RAIDZ na RAIDZ2?
Já osobně bych se na ZFS on linux nespoléhal vůbec :) Na FreeBSD se to ladilo fakt roky a pořád ještě to není úplně bullet-proof, ale je to produkčně použitelný. ZFS on Linux bych na produkci nedal (ale to je každého věc, čemu bude důvěřovat a čemu ne).

A právě proto jsem chtěl RAID řešit přes mdadm, aby přidávat disky bylo možné.
Nejsem si jistý, jestli si významně pomůžeš. Musel bych si sepsat konkrétní postup přidávání disku a jejich propagaci do zpoolu, teď z hlavy to nedokážu říct, jak dobře to půjde.

Takže předpokládám správně, že implementace ZFS v OpenIndiana vychází z implementace v OpenSolaris? Funguje na OpenIndiana hardware bez problémů a lze doinstalovat KDE či xfce? Vyvíjí se vůbec aktivně OpenIndiana?
Solaris ani jeho klony jsem nikdy nepoužíval, takže bohužel neporadím.

Aha, to je dobré vědět, děkuji. Jen na tom nechápu: Myslel jsem, že Linux je rozšířenější než FreeBSD či OpenIndiana, tj. software by měl být pro Linux obecně lépe odladěný. Je to jinak?
Je to tak co se týče aplikačního software. Co se týče samotného OS, tak je všechno odladěné tak, jak to výrobce odladí :) A ZFS prostě pochází ze Solarisu, takže nejlíp funguje tam. Pak slušně funguje na FreeBSD, protože se tam už dlouho ladí ... no a pak je všechno ostatní.

...čili mám desetkrát míň RAM než je na tolik dat doporučeno. Chápu tím vysvětlení zápisu 1 MB/s, ale ne problémů s plynulostí.
V IT je spousta věcí, které nechápu ;) Pokud jdeš nedoporučovanou cestou, nesmíš se divit ničemu.

Hashe používané při deduplikaci se při čtení nijak necachují? Dokáži si představit situace, kdy by se to hodilo.
:) Myslím, že autoři ZFS jsou znalostmi nad námi o tolik světelných let, že si určitě dokáží představit ledacos, o čem se nám ani nesní :) Jde o to, jak a proč je to implementované, ne jak si to my dva laici představujeme jako Hurvínek válku :)
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Trubicoid2 03. 03. 2016, 21:08:53
a myslím problém bude s tou deduplikací, kolik máš ram? máš l2arc? já měl deduplikaci jen na 4T (půlka plná) zapnutou a s 16GB RAM to dělalo velmi velké problémy, musel jsem deduplikaci vypnout.
j

Mám sice jen 4 GB RAM, ale swap 16 GB je téměř vždy prázdný. Jsem si vědom, že by to mohlo zpomalovat zápis na disk, ale rozhodně jsem nečekal problémy s plynulostí zápisu. Matně si vzpomínám, že vypnutí dedup nepomohlo, ale mohu to zkusit po příštím restartu (mazání snapshotu stále běží).

L2ARC je téměř 100 GB, pokud se nemýlím a je společně s logem na SSD disku:

Kód: [Vybrat]
                                            capacity     operations    bandwidth
pool                                     alloc   free   read  write   read  write
---------------------------------------  -----  -----  -----  -----  -----  -----
all                                      6,95T   304G     94      0   237K  1,45K
  dm-name-all                            6,95T   304G     94      0   237K  1,35K
logs                                         -      -      -      -      -      -
  ata-CT250BX100SSD1_1532F00A52C0-part6      0    80M      0      0    137     95
cache                                        -      -      -      -      -      -
  ata-CT250BX100SSD1_1532F00A52C0-part5  1,19G  96,6G     62     32   151K   174K

Vono je to divný, ale jak mi to padalo při zapnuté deduplikaci, tak byl swap prázdnej, jak u tebe. L2arc trochu pomoh a po přidání ram jsem mohl naklonovat data bez duplikace a stará zrušit a tím se to vyřešilo.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Trubicoid2 03. 03. 2016, 21:25:01
Ještě mě napadá, že může být problém se zarovnáním na 4k bloky. Hlavní problém bude ta deduplikace, ale zarovnání by taky mělo být.

Musí být zarovnaný partice, pak ten mdadm RAID, pak LUKS a nakonec i ZFS. Je to otrava, ale dělá se to většinou jen jednou. Nejlíp zarovnat třeba na 4MB, pro jistotu.

https://support.mayfirst.org/wiki/disk_alignment

http://wiki.illumos.org/display/illumos/ZFS+and+Advanced+Format+disks

Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Petr Kratochvíl 06. 03. 2016, 01:46:30
Ještě mě napadá, že může být problém se zarovnáním na 4k bloky. Hlavní problém bude ta deduplikace, ale zarovnání by taky mělo být.

Děkuji za tip. Každopádně více než rychlost nyní řeším hlavně plynulost zápisu a aby bylo možné mazat snapshoty. Ano, může to spolu souviset.

Aktualizuji informace:

Zjistil jsem, že na ubuntu-zfs (nativní ZFS) cca po 1 dni přestal fungovat OS kvůli OOM aneb došla volná fyzická RAM.

Plynulost zápisu se výrazně zlepšila a nejproblematičtější snapshot se podařilo během 5 hodin smazat potom, co jsem včera odinstaloval ubuntu-zfs (nativní ZFS) a nainstaloval ZFS-FUSE. Akorát zlobí nepochopitelně oprávnění (soubor vlastní uživatel krato, nelze ho otevřít, provedu "chown krato" a už ho lze otevřít), nelze mountovat snapshoty (obchází se klonováním na nový volume) a když jsem se pokusil přihlásit do KDE s domovským adresářem na ZFS, tak ZFS-FUSE dost ošklivě spadl:

Kód: [Vybrat]
rsync: write failed on "/w/videa/cinema-20100908-2000.avi": Software caused connection abort (103)
rsync error: error in file IO (code 11) at receiver.c(389) [receiver=3.1.0]

Kód: [Vybrat]
server ~ # zpool list
connect: Spojení odmítnuto
Please make sure that the zfs-fuse daemon is running.
internal error: failed to initialize ZFS library

Jiné OS jsem zkusil, na doporučení zde FreeBSD a OpenIndiana (nástupce OpenSolaris). FreeBSD mi nesedlo a OpenIndiana zatím ve VirtualBoxu píše při "zpool import" něco o chybném vdev. Nevím, zda to není zmatené tím, že pool byl vytvořen v debian-like Linuxu, tj. s /dev/disk/by-id/<něco> místo /dev/dsk/<něco> atd. Asi to ještě zkusím nativně z Live flash.

Zkusím OpenIndiana nativně, podívám se na velikosti bloků a pak už dál nevím. Na velkou RAM nejsou finanční prostředky a navíc není jistota, že by na plynulost zápisu pomohla.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Petr Kratochvíl 06. 03. 2016, 02:10:47
Ještě doplním:

Po restartu přeinstalováno zpět na nativní ubuntu-zfs a spuštěno kopírování. To se po cca 470 MB pozastavilo ačkoliv to nevypadá, že by byl nedostatek volné RAM:

Kód: [Vybrat]
top - 02:04:58 up 3 min,  5 users,  load average: 1,77, 0,57, 0,21
Tasks: 914 total,   2 running, 912 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,8 us,  6,9 sy,  0,0 ni, 47,5 id, 44,8 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   4048168 total,  2257116 used,  1791052 free,    83540 buffers
KiB Swap: 16980988 total,        0 used, 16980988 free.  1039824 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                               
 6383 root       1 -19       0      0      0 D   8,5  0,0   0:02.98 z_wr_iss                                                                                             
 6723 root      20   0   25732   2356   1140 R   2,0  0,1   0:00.15 top                                                                                                   
  371 root      20   0       0      0      0 S   1,3  0,0   0:00.44 l2arc_feed                                                                                           
 6681 root      20   0       0      0      0 S   1,0  0,0   0:00.23 kworker/0:3                                                                                           
   61 root      20   0       0      0      0 S   0,3  0,0   0:00.41 kworker/0:2         
...
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Mirek Prýmek 06. 03. 2016, 08:40:25
FreeBSD mi nesedlo
V čem ti nesedlo? Bude to pravděpodobně jenom nezvyk...
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Trubicoid2 06. 03. 2016, 15:06:15
Tak ten dedup pořád nemáš vypnutej?
Kód: [Vybrat]
zpool list| grep dedupVono nestačí to jen vypnout, to se vztahuje na nově zapsaný data pouze. Tedy je potřeba vypnout, všechny data zazálohovat, smazat a nahrát znova. Bych zrovna udělal to zfs znova, bez mdadm a se zarovnáním. Stejný to je s kompresí, když přepneš na lz4, tak to platí jen pro nově zapsaná data.

Jinak možná blbne hw disku? Stál by za to ho prověřit jednak smartem a pak vlastní zfs
Kód: [Vybrat]
zpool scrub all
Taky ten disk je dost plnej, není to tím?
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Petr Kratochvíl 06. 03. 2016, 17:39:53
Tak ten dedup pořád nemáš vypnutej?
Kód: [Vybrat]
zpool list| grep dedupVono nestačí to jen vypnout, to se vztahuje na nově zapsaný data pouze. Tedy je potřeba vypnout, všechny data zazálohovat, smazat a nahrát znova. Bych zrovna udělal to zfs znova, bez mdadm a se zarovnáním. Stejný to je s kompresí, když přepneš na lz4, tak to platí jen pro nově zapsaná data.
Dedup při zápisu je jedním z hlavních důvodů, proč jsem přešel z Btrfs na ZFS.

Jinak možná blbne hw disku? Stál by za to ho prověřit jednak smartem a pak vlastní zfs
Kód: [Vybrat]
zpool scrub all
Disk byl hned po koupi pro jistotu zkontrolován přes "badblocks -w". Díky za tip na zpool scrub. Je se obávám, že výsledek budu vědět až za několik dní nebo týdnů.

Taky ten disk je dost plnej, není to tím?
To je jeho účel. Potřebuji aby fungoval i plný.

Přemýšlel jsem o návratu k Btrfs, ale nějak mi s ním nefungoval nástroj na deduplikaci (bedup?), která se navíc provádí jen na již uložených datech (na dedup při zápisu se pracuje) a navíc mám strach z nezralosti, viz některé bug fixy a vylepšení teprve v nedávné době, viz https://btrfs.wiki.kernel.org/index.php/Changelog , konkrétně např.:
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 06. 03. 2016, 17:46:00
Disk byl hned po koupi pro jistotu zkontrolován přes "badblocks -w". Díky za tip na zpool scrub. Je se obávám, že výsledek budu vědět až za několik dní nebo týdnů.
Opakuju: tohle není normální situace, máš tam něco velmi špatně.

To je jeho účel. Potřebuji aby fungoval i plný.
Opět špatný předpoklad/požadavek.

Citace
You need to keep free space in your pool. It's mainly for copy-on-write actions and snapshots. Performance declines at about 85% utilization. You can go higher, but there's a definite impact.
http://serverfault.com/questions/511154/zfs-performance-do-i-need-to-keep-free-space-in-a-pool-or-a-file-system

Ty chceš prostě vlastnosti Ferrari a rozpočet máš na Wartburga, to nikdy fungovat nebude. Nemůžeš chtít desítky terrabajtů, postupně přidávat disky za běhu, deduplikovat a jánevímcoještě a honit to na kdovíjaké plečce se 4GB RAM. To prostě nejde, smiř se s tím. Buď to udělej pořádně, nebo to nedělej vůbec, tímhle způsobem nemá smysl se o to snažit.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: trubicoid2 06. 03. 2016, 21:21:51
ta deduplikace potřebuje 20GB RAM na každý TB dat (http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe), teda v tvým případě je třeba kolem 160GB RAM jen na deduplikaci

pokud tolik RAM nebudeš mít, nebude to fungovat, systém bude padat a je třeba to vypnout

na btrfs ta offline deduplikace zase nevyžaduje RAM, navíc jestli děláš hlavně snapshooty, tak oni nebudou na btrfs ze začátku zabírat místo, jako by byly deduplikovaný

záleží, co chceš dělat
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: technik007_cz 06. 03. 2016, 22:02:13
Ještě mě napadá, že může být problém se zarovnáním na 4k bloky. Hlavní problém bude ta deduplikace, ale zarovnání by taky mělo být.
Zjistil jsem, že na ubuntu-zfs (nativní ZFS) cca po 1 dni přestal fungovat OS kvůli OOM aneb došla volná fyzická RAM.

Dosla pamet ?
Zkus to zachranit timhle:

echo "# Min 512MB / Max  512MB RAM limit
options zfs zfs_arc_min=536870912
options zfs zfs_arc_max=536870912" > /etc/modprobe.d/zfs.conf
update-initramfs -k all -u

Muzes i treb limit 1GB, popripade v atributech zfs dej primarycache=none.
Primary cache je v RAM, vykon pujde rapidne dolu, proto doporucuju SSD cache aspon 32GB.

Prokopirovat data na novy pool bez deduplikace.
Jak bylo zminovano nekolikrat, nemas na to RAM.
Sam jsem byl v teto situaci mrznuti, zatuh systemu pri kopirovani, musel jsem to vyresit prekopirovanim vsech dat na novy pool.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Vladimír Drgoňa 06. 03. 2016, 22:03:52
a myslím problém bude s tou deduplikací, kolik máš ram? máš l2arc? já měl deduplikaci jen na 4T (půlka plná) zapnutou a s 16GB RAM to dělalo velmi velké problémy, musel jsem deduplikaci vypnout.

Mám sice jen 4 GB RAM, ale swap 16 GB je téměř vždy prázdný. Jsem si vědom, že by to mohlo zpomalovat zápis na disk, ale rozhodně jsem nečekal problémy s plynulostí zápisu. Matně si vzpomínám, že vypnutí dedup nepomohlo, ale mohu to zkusit po příštím restartu (mazání snapshotu stále běží).

L2ARC je téměř 100 GB, pokud se nemýlím a je společně s logem na SSD disku:

Kód: [Vybrat]
                                            capacity     operations    bandwidth
pool                                     alloc   free   read  write   read  write
---------------------------------------  -----  -----  -----  -----  -----  -----
all                                      6,95T   304G     94      0   237K  1,45K
  dm-name-all                            6,95T   304G     94      0   237K  1,35K
logs                                         -      -      -      -      -      -
  ata-CT250BX100SSD1_1532F00A52C0-part6      0    80M      0      0    137     95
cache                                        -      -      -      -      -      -
  ata-CT250BX100SSD1_1532F00A52C0-part5  1,19G  96,6G     62     32   151K   174K

Pozerám na výpis. Ak je log partícia veľká 80MB, tak sa veľmi rýchlo zaplní a ďalší zápis drhne. Osobne mám na serveri 4GB log a videl som ho zaplnený viac ako zpolovice.
Dedup je fajn, ale so 4GB RAM na ňu rovno zabudni. Mne zabíjala server so 16GB RAM, deduplikovaných dát bolo menej ako 1TB.
ZFS obsadí všetku voľnú pamäť, pokiaľ nemá nejaké špeciálne nastavenia. Vo FreeBSD je to vfs.zfs.arc_max, v Linuxe podobne: zfs_arc_max.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: Mirek Prýmek 06. 03. 2016, 22:59:31
Pozerám na výpis. Ak je log partícia veľká 80MB, tak sa veľmi rýchlo zaplní a ďalší zápis drhne.
Áááá, dobrej postřeh, toho jsem si ani nevšimnul, nenapadlo by mě, že někdo bude na ssd vyhrazovat 80MB :) To by dost stálo za zkoušku ten ZIL odstranit, jak to s výkonem pohne. Může to udělat za běhu, takže pohoda.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: technik007_cz 07. 03. 2016, 14:58:43
Ja jsem mel log cache par mega a stacilo to. Tady opravdu se nejdriv dela a pak keca jak v hospode?
"Ta cache je tak mala a tak ji smazeme..."
To opravdu si neumite najít v dokumentaci k cemu tam je?
Jste amateri a nikdy na problém takhle neprijdete  :D !
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Vladimír Drgoňa 07. 03. 2016, 18:39:34
Ja jsem mel log cache par mega a stacilo to. Tady opravdu se nejdriv dela a pak keca jak v hospode?
"Ta cache je tak mala a tak ji smazeme..."
To opravdu si neumite najít v dokumentaci k cemu tam je?
Jste amateri a nikdy na problém takhle neprijdete  :D !
Koľko je pár mega? 10MB? 20MB? Minimálna partícia v zfs môže mať 64MB.
 Log(ZIL) alebo cache (L2ARC)? Sú to pre mňa 2 odlišné partície. Každá má zmysel, každá je určená na niečo iné a spolu sa dopĺňajú.
Podľa dokumentácie Oracle by som ju navrhoval zvýšiť na 2GB, vychádzam z použitej RAM:
Osobne používam ZFS už viac ako 5 rokov, 4 roky ju mám na produkčnom serveri takže viem o čom píšem. Nemám na čo prichádzať, je úplne jasné, že v takej konfigurácii nemôže dedup nikdy seriózne fungovať. Pri zápisoch do 1MB/s by to možno fungovalo, ale pri plne obsadenom HDD určite nie.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 07. 03. 2016, 18:44:46
Log(ZIL) alebo cache (L2ARC)? Sú to pre mňa 2 odlišné partície. Každá má zmysel, každá je určená na niečo iné a spolu sa dopĺňajú.
Přesně tak. L2ARC může být libovolně malá a může se klidně i porouchat, nic se neděje. ZIL je přesný opak - porouchat se nesmí (obsahuje ještě na disk nezapsaná data) a velikost musí mít dostatečnou podle toho, kolik se na disk (maximálně) zapisuje. Pokud se na ZIL nedá zapisovat v dostatečném množství a rychleji než na samotný disk, postrádá smysl a degraduje výkon.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: P 07. 03. 2016, 23:21:58
kde zacat? napriklad tym, ze mas malo RAM. ze pouzivas kus softu, ktory nevidel poriadny vyvoj a testovanie poslednych 7 rokov. ze ocakavas luxus rolls roycu za cenu trabanta z druhej ruky.

ako plan, preinstaluj na posledny solaris (11.3), pridaj druhy disk, vypni dedup a zapni zrkadlo. potom pridaj RAMku (vela RAMky, kopec RAM). kym nevycerpas moznost pridavat RAM, nepridavaj zbytocne ZIL a L2ARC.

potom sa vrat, poradime  8)
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Petr Kratochvíl 07. 03. 2016, 23:44:56
kde zacat? napriklad tym, ze mas malo RAM.
Vadí u implementace ZFS on Linux, u implementace ZFS-FUSE je pro mé potřeby RAM dostatečná (zápis je plynulý, velký snapshot se smaže), avšak tato implementace je bohužel nestabilní.

ze pouzivas kus softu, ktory nevidel poriadny vyvoj a testovanie poslednych 7 rokov.
ZFS on Linux určitý vývoj má i loni a letos a funkce jsou na úrovni ZFS verze 28. Asi tím máš na mysli fixování málo chyb.

ze ocakavas luxus rolls roycu za cenu trabanta z druhej ruky.
Na to jsem si v Linuxu už celkem zvykl. Včetně Linuxu samotného.

ako plan, preinstaluj na posledny solaris (11.3), pridaj druhy disk, vypni dedup a zapni zrkadlo. potom pridaj RAMku (vela RAMky, kopec RAM). kym nevycerpas moznost pridavat RAM, nepridavaj zbytocne ZIL a L2ARC.
Dedup při zápisu nebo alespoň offline ber jako požadovanou funkci. Jinak bych se rovnou mohl vrátit k Btrfs.

S tím zrcadlem to nechápu. Plánuji celé úložiště v RAID 5 nebo 6 přes mdadm nebo ZFS, ne mirror.

Čemu vadí L2ARC na SSD disku? Neměl by naopak urychlovat čtení?

potom sa vrat, poradime  8)
Neboj, nikam neodcházím 8)
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 07. 03. 2016, 23:47:36
Čemu vadí L2ARC na SSD disku? Neměl by naopak urychlovat čtení?
Ale míň než RAM. P se ti snažil říct, že dokud můžeš, máš přidávat RAM. Až když nemůžeš, dávat SSD.
Název: Re: ma ty prostoto!
Přispěvatel: hugochavez 08. 03. 2016, 00:17:16
Není to disk který byl podezřele levný kvůli tomu že používá SMR (shingled magnetic recording)? Zápis na takové disky prostě je po zaplnění jejich cache pomalý a nedá se s tím nic dělat, za to ZFS nemůže...

Zní to zajímavě, děkuji. Leč hned po koupi jsem provedl nějaké testy, při kterých sekvenční zápis byl podstatně rychlejší než 1 MB/s. Každopádně primárně řeším plynulost zápisu. Aby ten ZFS pool neměl každou chvíli na několik minut pozastavené veškeré zápisy. Potřebuji aby šlo na pool kdykoliv zapisovat, i kdyby nízkou rychlostí.

Docetl jsem az sem a dal uz vazne nemuzu. :-o
Pripada mi ze chces provozovat jadernou elektrarnu ale nenamahal jsi se cokoliv si o jejim provozu zjistit a ted tam chodis jako slepej bez hole a divis se coze se to kolem deje za roztodivny veci....
Takze- pokud to myslis se ZFS vazne (a chces z nej mit uzitek namisto frustraci, zklamani a casem pravdepodobne i totalni ztraty dat), tak ti VRELE DOPORUCUJU abysis doplnil vzdelani a neco si o tom nacet'. Nejsou to texty primo o ZFS na Linuxu nybrz na FreeBSD platforme konkretne jde o FreeNAS = muzes to brat jako prvni tip na funkcni OS na kterem se da spolehlive provozovat ZFS a skladovat hromady dat, tak jak jsi o to zadal ;o) Jsem si skoro jistej ze princip a logika ZFS na Linuxu a FreeBSD se prilis lisit nebude= je to porad ZFS, a kdyz uz mluvime o logice tak ta je u ZFS  DIAMETRALNE ODLISNA od jinych file-systemu a je treba to vzit do uvahy pri navrhovani systemu jinak se 100%ne spalis. Jen pro ilustraci je VELMI PODSTATNE JAKY DRUH DAT/SLUZEB chces provozovat. Bude hodne klientu cist/zapisovat do databazi anebo budou jen pasivne streamovat videa do svych koncovych zarizeni?? Mas 10Gb sitovku a jde ti o velky prutok dat pri r/w (=mirroring) anebo chces mit mega-jistotu ze neprijdes o data i kdyz ti kleknou 2 disky z 5ti?? (RaidZ2) To vsechno hraje roli.
Takze pro zacatek doporucuju zacit jakousi bibli pro dummies :o)

https://forums.freenas.org/index.php?threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/
Dole si vyber z tech 3 linku format k sosnuti. BTW povsimni si uplne dole tech 2 odkazu: "Hardware recommendations • RAID5/RAIDZ1 is dead" ;o)
Sepsal to admin FreeNAS fora na zaklade narku, dotazu a zklamani uzivatelu :o))))
Jsou tam polopaticky vysvetlene zaklady navrhovani ZFS poolu/Vdev a ceho se vyvarovat..... dedup je jedna z tech veci ;o)
pak se muzes presunout na drobet hard-core studium:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide

https://www.ixsystems.com/whats-new/2015/09/30/freenas-worst-practices/

Spousty zajimavyho se dozvis i tady:
http://doc.freenas.org/9.3/freenas.html#

Napr. info ktere ti evidentne chybi:
" The best way to get the most out of your FreeNAS® system is to install as much RAM as possible. The recommended minimum is 8 GB of RAM. The more RAM, the better the performance, and the FreeNAS® Forums provide anecdotal evidence from users on how much performance is gained by adding more RAM.

Depending upon your use case, your system may require more RAM. Here are some general rules of thumb:

    If you plan to use ZFS deduplication, ensure you have at least 5 GB RAM per TB of storage to be deduplicated.
    If you plan to use Active Directory with a lot of users, add an additional 2 GB of RAM for winbind’s internal cache.
    If you plan on Using the phpVirtualBox Template, increase the minimum RAM size by the amount of virtual memory you configure for the virtual machines. For example, if you plan to install two virtual machines, each with 4GB of virtual memory, the system will need at least 16GB of RAM.
    If you plan to use iSCSI, install at least 16GB of RAM, if performance is not critical, or at least 32GB of RAM if performance is a requirement.
    If you are installing FreeNAS® on a headless system, disable the shared memory settings for the video card in the BIOS.

If your system supports it and your budget allows for it, install ECC RAM. While more expensive, ECC RAM is highly recommended as it prevents in-flight corruption of data before the error-correcting properties of ZFS come into play, thus providing consistency for the checksumming and parity calculations performed by ZFS. If you consider your data to be important, use ECC RAM. This Case Study describes the risks associated with memory corruption.

If you don’t have at least 8GB of RAM, you should consider getting more powerful hardware before using FreeNAS® to store your data. Plenty of users expect FreeNAS® to function with less than these requirements, just at reduced performance. The bottom line is that these minimums are based on the feedback of many users. Users that do not meet these requirements and who ask for help in the forums or IRC will likely be ignored because of the abundance of information that FreeNAS® may not behave properly with less than 8GB of RAM

Myslim ze pokazdy kdyz tam pisou FreeNAS tak si muzes dosadit ZFS a bude to presny.
Dalsi zasadni vec je ze ZFS se nesnasi s HW Raidem= ZFS je RAiD sam o sobe a potrebuje PRIMY kontakt na zelezo jinak se o5 zacnou dit roztodivny veci. Proto pokud deska defaultne podporuje RAiD je potreba v BiOSU to zmenit na JBOD. Stejne tak se nedoporucuje zaplnovat pool na vic nez 80%, kombinovat ruzne velikosti/rychlosti/vyrobce  disku protoze logika s jakou ZFS rozhazuje/optimalizuje rozmistovani dat je -jak zmineno vyse- uplne jina nez u konkurencnich FS, atd atd. Je toho hodne co si clovek musi o ZFS nastudovat ale odmenou je pak naprosto famozni, megastabilni system ktery muze roky slouzit stylem "set it and forget it"!  :o))))
Neni divu ze Oracle na tom rejzuje neskutecny $.
ZFS_101_aka_ZFS_is_Cool_and_Why_You_Should_Be_Using_It_by_Dru_Lavigne
(prednaska vyvojarky)
https://www.youtube.com/watch?v=OIuWAxkceBY
a tady je k tomu slideshow:
http://www.slideshare.net/dlavigne/scale2014
ZFS Feature Overview  https://www.youtube.com/watch?v=R9EMgi_XOoo 
Ultimate ZFS Overview | TechSNAP 28  (zacina 28m35s)  https://www.youtube.com/watch?v=0Ug1qCXvZDg
a na zaver trocha srandy jak se provadi "alternativni komprese disku" ala ZFS  :o))))  https://www.youtube.com/watch?v=CN6iDzesEs0

Enjoy!
PS: jen pro orientaci par udaju o mem ZFS systemu.
deska http://www.asrockrack.com/general/productdetail.asp?Model=C2750D4I#Specifications
4x8GB ECC RAM, 5x1TB WD RED (kvuli spotrebe) nastaveny jako RaidZ2 s kompresi LZ4 + full disk encryption Geli  (FreeBSD default crypto protoze Oracle-crypto nelze kvuli copyrightu pouzit) Sifrovani probiha HW AES-NI ktere deska podporuje.
Rychlosti: upload/zapis z Linux Mint na FreeNAS =4GB soubor zacne tlacit 33MB/s ale rychle to spadne na cca 21-22MB/s a ty pak drzi =je znat ze ty disky nejsou rychlootackovy a nestihaj, navic se pocitaj hashe bloku a hashe samotnych hashu a data se rozhazujou na 5 disku soucasne. Download uz je jiny kafe=cca 60MB/s. ZFS pool je namountovanej na Linux pres NFS. Sambu nepouzivam a tipuju ze rychlosti by byly o poznani nizsi. Jinak trafik jde pres 1Gb switch a pfSense router (ten ma taky 1Gb sitovku) protoze server je na jiny LAN nez noutas, coz by ale nemelo mit zasadnejsi vliv na rychlost....... Takze asi tak :o)
Název: Re: ma ty prostoto!
Přispěvatel: Mirek Prýmek 08. 03. 2016, 00:41:51
Download uz je jiny kafe=cca 60MB/s. ZFS pool je namountovanej na Linux pres NFS. Sambu nepouzivam a tipuju ze rychlosti by byly o poznani nizsi. Jinak trafik jde pres 1Gb switch a pfSense router (ten ma taky 1Gb sitovku) protoze server je na jiny LAN nez noutas, coz by ale nemelo mit zasadnejsi vliv na rychlost....... Takze asi tak :o)
Tech 60MBps bude asi spis tim NFSkem nebo siti, ne? Kdybys to pustil lokalne do /dev/null, tak ti to da urco vic, ne?
Název: Re: ma ty prostoto!
Přispěvatel: hugochavez 08. 03. 2016, 03:27:15
Download uz je jiny kafe=cca 60MB/s. ZFS pool je namountovanej na Linux pres NFS. Sambu nepouzivam a tipuju ze rychlosti by byly o poznani nizsi. Jinak trafik jde pres 1Gb switch a pfSense router (ten ma taky 1Gb sitovku) protoze server je na jiny LAN nez noutas, coz by ale nemelo mit zasadnejsi vliv na rychlost....... Takze asi tak :o)
Tech 60MBps bude asi spis tim NFSkem nebo siti, ne? Kdybys to pustil lokalne do /dev/null, tak ti to da urco vic, ne?
Taky se mi to zdalo malo, ale jelikoz vsechno co potrebuju chodi OK tak sem to moc neresil. Ono i streamovani BlueRaye si nerekne o vic nez nejakych 50MB/s takze ani s tim trable nebyly. Tezko rict cim to je- tipoval bych to na neoptimalizovanej RaidZ protoze 5 disku je kravina= ma to bejt mocnina dvou cili pro muj setup 4 anebo 8. Jenze ja mel misto jen na 5max a 4 semi zdalo malo kdyz 2 obetuju na redundancy.....  :o/ Na druhou stranu tady vyvojar FreeBSD mluvi o tom ze ma 4+2disky v RaidZ2 (https://www.youtube.com/watch?v=F5btWTDtPuA#t=53m10s) a read/write speed mu dava 715MB/s..............s tim ze ale jeho LAN je pouze gigabitova takze mu je to stejne k h... kdyz neprotlaci kabelem vic nez 125MB/s . Na druhou stranu nerika nic o tom JAKY tam ma disky a jelikoz tendle typeq je silenec cosi stavi 90TB servery tak by me ani neprekvapilo ze tam vrazil naky SSDka anebo 11k rpm Raptory :o))))) Ja tam mam cerveny 5.4k sracky od WD kde 1 disk uz po mesici provozu zacal vypisovat "2 vadne sektory". Je ale fakt ze dalsi uz za skoro 2 roky nonstop-provozu nepridal, takze to taky neresim.  Ja sem premejslel ze udelam nakej iPerf test ale znas to -clovek resi problem az kdyz ho zacne tlacit :o))))))) takze sem se k tomu zatim nedokopa :o) Jaky rychlosti z toho tlacis ty? a s jakyma HDD??
Název: Re: ma ty prostoto!
Přispěvatel: Mirek Prýmek 08. 03. 2016, 08:53:28
Jaky rychlosti z toho tlacis ty? a s jakyma HDD??
Nemam nikde srovnatelnou kombinaci. Na serverech mam bud jenom dva disky v mirroru, nebo vic, ale bez šifrování. Ale co si matně pamatuju, tak GELI s AES-NI by mělo dávat víc než disky a ty WD RED dají taky určitě kolem 100MBps. Hashe ti procesor rozhodně nevytíží, takže tam bych úzký hrdlo taky nehledal a čtení z víc disků by mělo dávat víc než z jednoho...

Schválně zkus přímo na tom stroji pustit přes sysutils/dd_rescue nějakej zaručeně nenacachovanej soubor do /dev/null, kolik ti to hodí.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 08. 03. 2016, 09:04:42
Na 4-diskovým RAIDZ-1, SATA disky WDC WD5002ABYS-02B1B0 7200RPM, bez L2ARC, bez šifrování, deska obstarožní supermicro, Xeon E5405@2.00GHz, FreeBSD 10:

Kód: [Vybrat]
# dd if=ubuntu-14.04-server-amd64.iso of=/dev/null bs=1M
564+0 records in
564+0 records out
591396864 bytes transferred in 3.092000 secs (191266773 bytes/sec)

# dd if=/dev/ada0 of=/dev/null bs=1M count=564
564+0 records in
564+0 records out
591396864 bytes transferred in 5.133316 secs (115207569 bytes/sec)

Při druhém spuštění - nacachováno v RAM:
Kód: [Vybrat]
# dd if=ubuntu-14.04-server-amd64.iso of=/dev/null bs=1M
564+0 records in
564+0 records out
591396864 bytes transferred in 0.190847 secs (3098798373 bytes/sec)
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 08. 03. 2016, 09:27:34
Pro srovnání: nevím proč ne úplně excelentní diskovej výkon dostávám od entry-level proliantů:

HP ProLiant ML310e Gen8, Xeon E3-1220 V2 @ 3.10GHz, 2 Disky MB1000GCEEK v mirroru, 7200 RPM, FreeBSD 10

Kód: [Vybrat]
# dd if=sda3.ntfsc of=/dev/null bs=1M
9106+1 records in
9106+1 records out
9548841713 bytes transferred in 100.955159 secs (94584980 bytes/sec)

# dd if=/dev/ada0 of=/dev/null bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes transferred in 4.085543 secs (128327620 bytes/sec)

P.S. tohle je ale fileserver, který je teď normálně v produkci, takže za úplnýho klidu by snad dal víc, ale co mám tak zkušenost, o moc víc ne.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Vladimír Drgoňa 08. 03. 2016, 10:04:11
Tiež sa pripájam k tomu, že 60MB/s je málo. Urobil som si test na WD-RED mirrored, výsledok je tu
Kód: [Vybrat]
[root@doma /usr/home/vlado/virtual]# dd if=GentooDistcc-disk1.vmdk of=/dev/null bs=1M
15468+1 records in
15468+1 records out
16219504640 bytes transferred in 55.183598 secs (293918940 bytes/sec)
[root@doma /usr/home/vlado/virtual]# dd if=GentooDistcc-disk1.vmdk of=/dev/null bs=1M
15468+1 records in
15468+1 records out
16219504640 bytes transferred in 38.742893 secs (418644644 bytes/sec)#

Urobil som 2 pokusy, partícia má recordsize = 1M, secondarycache = metadata, keďže sú na nej iba disky virtuálnych strojov. Procesor je obyčajný core i3-3220T, je tam 16GB RAM a pod kapotou FreeBSD-10.2.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 08. 03. 2016, 10:10:30
(293918940 bytes/sec)
Ty potvoro, jaktože ti to dává tolik!? ;)

Nemohl's mít ten soubor částečně nacachovanej? Ta rychlost a malej rozdíl mezi prvním a druhým pokusem tomu nasvědčuje.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 08. 03. 2016, 10:13:29
Ajo, secondarycache... Na čem ji máš?

EDIT: beru zpět, cachování metadat přece nemůže dát tolik. Záhada! :)
Název: Re: ma ty prostoto!
Přispěvatel: Petr Kratochvíl 08. 03. 2016, 12:38:56
Takze pro zacatek doporucuju zacit jakousi bibli pro dummies :o)

https://forums.freenas.org/index.php?threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/

Děkuji za tipy a odkazy. Snad se budou hodit nejen mě.

Stihl jsem si zatím projít prezentaci "FreeNAS Guide" z odkazu výše, ale příliš nových informací jsem se z ní nedozvěděl. Např. nějaké doporučení kolik disků dávat do RAIDZ2 vdev. Zda nepřijdu o data když se v poolu za chodu dočasně odmlčí několik disků najednou (např. výpadek jednoho zdroje napájecího několik disků, ...). Zda použít na ZFS vždy celý fyzický disk a nebo vytvořit MBR/GPT a na tom ZFS partitionu.

Mám si tedy se ZFS hrát na Oracle Solaris nebo FreeBSD (nebo FreeNAS)? Kdybych chtěl mít počítač schopný sloužit jako datové úložiště i jako desktop. Našel jsem, že pro Solaris neexistuje Plex a Chromium a naopak pro FreeBSD existuje VirtualBox jen přes port, také jsem v něm nenašel grub a češtinu kvůli uživatelům, ale mohu se mýlit.

Je lepší šifrovat přes GELI nebo použít šifrování v ZFS (jelikož Solaris 11 umí ZPOOL verze 37)?

Bylo by něco špatného na myšlence nainstalovat Oracle Solaris 11, vytvořit ZPOOL verze 37, zapnout v ZFS šifrování a rozšiřovat pool v budoucnu přidávám paranoidně raději 4 diskových RAIDZ2 vdevů (2+2 redundance)?
Název: Re: ma ty prostoto!
Přispěvatel: Lol Phirae 08. 03. 2016, 12:43:48
Mám si tedy se ZFS hrát na Oracle Solaris nebo FreeBSD (nebo FreeNAS)?

No, hlavně bych doporučil přestat si hrát s tou deduplikací. Z hlediska HW nároků je to zcela nepoužitelné.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: trubicoid2 08. 03. 2016, 13:12:33
v RAIDZ2 se můžou bez vlivu na data odmlčet disky dva (aka RAID6) v RAIDZ1 jeden (aka RAID5)

partice jsou potřeba třeba kvůli jiným OS (widle), aby disk nechtěly pořád formátovat a kvůli bios/efi aby z toho mohli bootovat, jestli nepotřebuješ, tak to tam dávat nemusíš, výhoda je, že odpadá kontrola zarovnání partic

podle mě to ZFS nejde takhle rozšiřovat: jeden disk > mirror > raidz2 (to zase jde v btrfs), v zfs budeš muset data zazálohovat a pole znovu vytvořit

Název: Re: ma ty prostoto!
Přispěvatel: Mirek Prýmek 08. 03. 2016, 13:33:57
Mám si tedy se ZFS hrát na Oracle Solaris nebo FreeBSD (nebo FreeNAS)?
Solaris je komerční placený produkt. Existují free klony, ale jsou málo používané, takže třeba tady nečekej, že ti s tím někdo poradí. FreeNAS je FreeBSD+UI specializovaný na NAS. Možná mají nějakých pár svých extra patchů, které se pak později dostanou do upstream FreeBSD, nevím, jak moc rychle a jestli vůbec. Je to od firmy https://www.ixsystems.com která se na ukládání dat specializuje, má i spešl odladěný HW a komerční podporu. Komerční varianta FreeNAS se jmenuje TrueNAS. S oficiálním hw to není úplně levná záležitost, ale mělo by to být velmi kvalitní.

Kdybych chtěl mít počítač schopný sloužit jako datové úložiště i jako desktop.
Každý desktop je "datové úložiště". Záleží, co od toho chceš a jaký na to máš rozpočet.

naopak pro FreeBSD existuje VirtualBox jen přes port
Není to "jen" přes port. Porty jsou standardní způsob, jak se ve FreeBSD instaluje software třetích stran.

, také jsem v něm nenašel grub
FreeBSD má krásný, čistý a jednoduchý způsob bootování, který je o deset levelů lepší než Grub, nedejmatkopřírodo Grub2. Pokud ho i přesto chceš, k dispozici je: http://www.freshports.org/sysutils/grub2/ Ale Důrazně bych to nedoporučoval.

a češtinu kvůli uživatelům, ale mohu se mýlit.
"čeština" je široký pojem a moc nechápu, jakou češtinu potřebují uživatelé úložiště :)

Je lepší šifrovat přes GELI nebo použít šifrování v ZFS (jelikož Solaris 11 umí ZPOOL verze 37)?
Geli je technologie FreeBSD. Šifrování v ZFS je technologie Solarisu. Ani na jednom systému není oboje.

Bylo by něco špatného na myšlence nainstalovat Oracle Solaris 11, vytvořit ZPOOL verze 37, zapnout v ZFS šifrování a rozšiřovat pool v budoucnu přidávám paranoidně raději 4 diskových RAIDZ2 vdevů (2+2 redundance)?
Nic špatného na tom není, pokud to tak chceš dělat a splňuje to tvoje představy.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Petr Kratochvíl 08. 03. 2016, 13:35:22
v RAIDZ2 se můžou bez vlivu na data odmlčet disky dva (aka RAID6) v RAIDZ1 jeden (aka RAID5)
Ok. Hypoteticky: Mám pool s 2 vdev. Každý vdev má 4 disky v RAIDZ2, všechny 4 připojené na jeden zdroj napájení. Na chodu odejde jeden z těch dvou zdrojů, disky zůstávají funkční. Vypnu PC, vyměním zdroj, zapnu PC. Všech 8 disků je stále funkčních. Bude pool opět fungovat nebo jsem přišel o data?

partice jsou potřeba třeba kvůli jiným OS (widle), aby disk nechtěly pořád formátovat a kvůli bios/efi aby z toho mohli bootovat, jestli nepotřebuješ, tak to tam dávat nemusíš, výhoda je, že odpadá kontrola zarovnání partic
Super, thx. Zatím partice vytvářím, zarovnání raději ještě nějak zkontroluji.

podle mě to ZFS nejde takhle rozšiřovat: jeden disk > mirror > raidz2 (to zase jde v btrfs), v zfs budeš muset data zazálohovat a pole znovu vytvořit
Měl jsem na mysli hypoteticky: mám 4 disky v RAIDZ2 vdev. Přidám za rok další 4 disky v RAIDZ2 vdev. A za dva roky dalčí 4 disky v RAIDZ2 vdev. Vím, že vdev nelze rozšiřovat o disky (rozdíl oproti mdadm), ale pool o vdev by jít rozšířit měl, dokonce přidaný vdev může mít libovolnou kapacitu (např. zakoupené větší disky než doposud).
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 08. 03. 2016, 13:41:43
Ok. Hypoteticky: Mám pool s 2 vdev. Každý vdev má 4 disky v RAIDZ2, všechny 4 připojené na jeden zdroj napájení. Na chodu odejde jeden z těch dvou zdrojů, disky zůstávají funkční. Vypnu PC, vyměním zdroj, zapnu PC. Všech 8 disků je stále funkčních. Bude pool opět fungovat nebo jsem přišel o data?
Pokud odejde napájení, tak disk zmizí. Pokud zmizí celý vdev, umřelo celé pole. Co přesně se pak stane, to záleží na tom, co tam máš za aplikace. Ale v principu je to velmi rizikový stav, podobný tomu, kdybys měl dva disky v RAID0 a z jednoho z ničehožnic vytáhl kabel.

Měl jsem na mysli hypoteticky: mám 4 disky v RAIDZ2 vdev. Přidám za rok další 4 disky v RAIDZ2 vdev. A za dva roky dalčí 4 disky v RAIDZ2 vdev. Vím, že vdev nelze rozšiřovat o disky (rozdíl oproti mdadm), ale pool o vdev by jít rozšířit měl, dokonce přidaný vdev může mít libovolnou kapacitu (např. zakoupené větší disky než doposud).
Takhle by to jít mělo, ale prakticky jsem to nikdy nepoužil, snad kolegové poradí.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Vladimír Drgoňa 08. 03. 2016, 17:44:43
(293918940 bytes/sec)
Ty potvoro, jaktože ti to dává tolik!? ;)

Nemohl's mít ten soubor částečně nacachovanej? Ta rychlost a malej rozdíl mezi prvním a druhým pokusem tomu nasvědčuje.

 Za rýchlosť vďačím podľa mňa viacerým skutočnostiam:

Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 08. 03. 2016, 19:27:39
recordsize=1M. Keď som to skúšal pred rokom na klasike (128kB), dostal som z diskov asi polovičný výkon -  teraz nehľadá sektory ale číta
To by mohlo být ono. Ale hodí se jenom někde :(

partícia je pakovaná lz4.
To mám taky všude. Při dnešních flákajících se procesorech má lz4 smysl asi skoro všude.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Vladimír Drgoňa 08. 03. 2016, 20:36:46
recordsize=1M. Keď som to skúšal pred rokom na klasike (128kB), dostal som z diskov asi polovičný výkon -  teraz nehľadá sektory ale číta
To by mohlo být ono. Ale hodí se jenom někde :(


Samozrejme používam ho na virtuálne médiá - pri lz4 už z princípu nikdy nebude sedieť zarovnanie virtuálnych sektorov fyzicky na zfs, teoreticky by sa to mohlo riešiť cez recordsize=4k a bez kompresie, ale vyskúšal som recordsize=1M s tým, že zfs si tieto nezrovnalosti bude riešiť v RAM a podľa mňa to funguje.
Ďalej je to vhodné pre veľmi veľké multimédiá (30GB mkv a podobne)

partícia je pakovaná lz4.
To mám taky všude. Při dnešních flákajících se procesorech má lz4 smysl asi skoro všude.

Samozrejme ju mám tiež všade, snáď okrem /ROOT, nepoužívam ju ani na multimediálny obsah, ktorý radšej skonvertujem na x265. Ten mi prehrá každý prehrávač, dnes už aj televízor.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Mirek Prýmek 08. 03. 2016, 20:52:23
Samozrejme ju mám tiež všade, snáď okrem /ROOT, nepoužívam ju ani na multimediálny obsah, ktorý radšej skonvertujem na x265. Ten mi prehrá každý prehrávač, dnes už aj televízor.
Na domácím NASu jsem se s tím nepáral, nechal to zapnuté globálně a na filmech mi to dává compressratio=1.00, na mp3kách 1.01 :) Ono to asi ničemu nevadí, ta režie s dekompresí je tam asi nicotná, úzký hrdlo je tak jako tak disk nebo síť a těch pár wattů na procesoru se stejně u mě ztratí v neefektivitě zdroje, takže sere pes :)
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Petr Kratochvíl 21. 03. 2016, 03:00:45
Řešení

Kód: [Vybrat]
echo 4000000 > /sys/module/zfs/parameters/zfs_dirty_data_max
Sice neřeší rychlost zápisu, ale řeší problém uvedený v předmětu, tj. problém, že "ZFS pozastavuje zápis po zaplnění bufferu". Velikost tohoto "dirty bufferu" je u ZFS on Linux defaultně 10% velikosti fyzické RAM, viz read-only parametr zfs_dirty_data_max_percent. Parametr zfs_dirty_data_max naštěstí přenastavit lze. V mém případě byl defaultně nastaven na 4 GB RAM * 10% = cca 400 MB. Nyní mám přenastaven na 4 MB, které se po zaplnění vyprázdní za cca 4 sekundy. Uvědomuji si kromě výhod i nevýhody, jsou hezky popsané na http://blog.delphix.com/ahl/2014/tuning-openzfs-write-throttle/ , kde jsou navíc uvedeny i další tuningové tipy.

Výběr OS

Snad chápu správně, že pokud od souborového systému chci co nejvíce funkcí a co největší spolehlivost, tak jedinou správnou volbou je ZFS. Nyní řeším na jakém OS ZFS úložiště postavit. Nejvíc narážím na nekompatibilitu šifrování v různých OS. V Linuxu se používá cryptsetup, ve FreeBSD/FreeNAS je to geli a v Oracle Solaris umí šifrovat ZFS samo o sobě, ale jedná se o proprietární řešení. Jenže každá z těchto metod funguje jen v jednom OS, takže po zašifrování ZFS bych už OS nemohl změnit. Nebo se mýlím? Rád bych použil Oracle Solaris, OpenIndiana nebo FreeNAS, ale nejlépe se šifrováním kompatibilním s Linuxem. Možná bych to měl buď zkusit nastudovat sám a nebo zde založit jako nové téma.
Název: Re: ma ty prostoto!
Přispěvatel: hugochavez 27. 03. 2016, 03:38:20
Download uz je jiny kafe=cca 60MB/s. ZFS pool je namountovanej na Linux pres NFS. Sambu nepouzivam a tipuju ze rychlosti by byly o poznani nizsi. Jinak trafik jde pres 1Gb switch a pfSense router (ten ma taky 1Gb sitovku) protoze server je na jiny LAN nez noutas, coz by ale nemelo mit zasadnejsi vliv na rychlost....... Takze asi tak :o)
Tech 60MBps bude asi spis tim NFSkem nebo siti, ne? Kdybys to pustil lokalne do /dev/null, tak ti to da urco vic, ne?

Zdravim, nemel jsem moc casu a pak jsem byl zas par dni pryc takze jsem se k tomu dostal az ted. Ale jak se rika:  "better late than never"  :)
Takze: udelal sem naky mereni a tady sou vysledky:

 read-speed ISO cca 1.5GB
[root@freenas /mnt/v1/ftpdataset]# ls                                           
Mint.iso        film.mkv
                                                       
[root@freenas /mnt/v1/ftpdataset]# dd if=Mint.iso of=/dev/null bs=1M           
1430+0 records in                                                               
1430+0 records out                                                             
1499463680 bytes transferred in 0.630275 secs (2379062558 bytes/sec) =2268 MB/s
 

  read-speed film 2.5GB                                 
[root@freenas /mnt/v1/ftpdataset]# dd if=film.mkv of=/dev/null bs=1M           
2321+1 records in                                                               
2321+1 records out                                                             
2433767817 bytes transferred in 1.018480 secs (2389607717 bytes/sec) =2278 MB/s


  write-speed  samy nuly       
[root@freenas /mnt/v1/ftpdataset]# dd if=/dev/zero of=testfile bs=1M count=3072
3072+0 records in                                                               
3072+0 records out                                                             
3221225472 bytes transferred in 2.740776 secs (1175296850 bytes/sec) =1120 MB/s

 write-speed nahodne generovany data 3GB soubor
[root@freenas /mnt/v1/ftpdataset]# dd if=/dev/random of=testfile2 bs=1M count=30
72                                                                             
3072+0 records in                                                               
3072+0 records out                                                             
3221225472 bytes transferred in 67.902145 secs (47439230 bytes/sec) =45 MB/s


 read-speed nahodne generovany data 3GB soubor
[root@freenas /mnt/v1/ftpdataset]# dd if=testfile2 of=/dev/null bs=1M           
3072+0 records in                                                               
3072+0 records out                                                             
3221225472 bytes transferred in 1.358899 secs (2370466971 bytes/sec) = 2260 MB/s


vysledky PO VYPNUTI lz4 komprese pri stejnych testech:

 write-speed  samy nuly
[root@freenas /mnt/v1/ftpdataset]# dd if=/dev/zero of=testfile bs=1M count=3072
3072+0 records in                                                               
3072+0 records out                                                             
3221225472 bytes transferred in 5.448013 secs (591266106 bytes/sec) =563MB/s coz je cca polovina toho co dava zapnuta komprese- cili komprese ma u dat k tomu vhodnych velky smysl.

 write-speed nahodne generovany data 3GB soubor           
[root@freenas /mnt/v1/ftpdataset]# dd if=/dev/random of=testfile2 bs=1M count=30
72                                                                             
3072+0 records in                                                               
3072+0 records out                                                             
3221225472 bytes transferred in 67.952542 secs (47404047 bytes/sec) =45MB/s coz je totozne s vysledkem pri zapnute kompresi a potvrzuje to starou poucku ze nahodna (tedy i dobre sifrovana) data uz dale komprimovat nelze :o)


CTENI pri vypnute kompresi:

  3GB dat ze samych nul         
[root@freenas /mnt/v1/ftpdataset]# dd if=testfile of=/dev/null bs=1M           
3072+0 records in                                                               
3072+0 records out                                                             
3221225472 bytes transferred in 1.368314 secs (2354156990 bytes/sec) =2245MB/s

nahodne generovana data 3GB soubor
[root@freenas /mnt/v1/ftpdataset]# dd if=testfile2 of=/dev/null bs=1M           
3072+0 records in                                                               
3072+0 records out                                                             
3221225472 bytes transferred in 1.362045 secs (2364991872 bytes/sec) =2255MB/s


a jeste pro zajimavost:
[root@freenas /mnt/v1/ftpdataset]# dd if=Mint.iso of=/dev/null bs=1024         
1464320+0 records in                                                           
1464320+0 records out                                                           
1499463680 bytes transferred in 11.164927 secs (134301252 bytes/sec) =128MB/s

takze disky ctou a pisou tak jak maj a problem je nekde jinde.
Zkusil sem FTP:  down 80MB/s a up cca 60MB/s

Taxem udelal par testu:
iPerf pres router z noutase na FreeNAS:

iperf -c 172.x.x.x -P 1 -i 1 -m -p 5001 -f M -t 10
------------------------------------------------------------
Client connecting to 172.x.x.x, TCP port 5001
TCP window size: 0.07 MByte (default)
------------------------------------------------------------
[  3] local 192.168.x.x port 43031 connected with 172.x.x.x port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  61.4 MBytes  61.4 MBytes/sec
[  3]  1.0- 2.0 sec  60.0 MBytes  60.0 MBytes/sec
[  3]  2.0- 3.0 sec  58.8 MBytes  58.8 MBytes/sec
[  3]  3.0- 4.0 sec  60.0 MBytes  60.0 MBytes/sec
[  3]  4.0- 5.0 sec  59.2 MBytes  59.2 MBytes/sec
[  3]  5.0- 6.0 sec  59.6 MBytes  59.6 MBytes/sec
[  3]  6.0- 7.0 sec  60.2 MBytes  60.2 MBytes/sec
[  3]  7.0- 8.0 sec  58.4 MBytes  58.4 MBytes/sec
[  3]  8.0- 9.0 sec  58.6 MBytes  58.6 MBytes/sec
[  3]  9.0-10.0 sec  59.2 MBytes  59.2 MBytes/sec
[  3]  0.0-10.0 sec   596 MBytes  59.5 MBytes/sec
[  3] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
Done.
---------------------------------------------------------
 coz je tech 60MB/s co uz jsem nameril driv   >:(
Taxem nahodil iPerf server na pfSense a zkusil zmerit lajnu JEN od noutase k routeru a vyslo mi tohle:

iperf -c 192.168.x.x -P 1 -i 1 -m -p 5001 -f M -t 20
------------------------------------------------------------
Client connecting to 192.168.x.x, TCP port 5001
TCP window size: 0.02 MByte (default)
------------------------------------------------------------
[  3] local 192.168.x.x port 58274 connected with 192.168.x.x port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  40.5 MBytes  40.5 MBytes/sec
[  3]  1.0- 2.0 sec  39.0 MBytes  39.0 MBytes/sec
[  3]  2.0- 3.0 sec  38.9 MBytes  38.9 MBytes/sec
[  3]  3.0- 4.0 sec  39.0 MBytes  39.0 MBytes/sec
[  3]  4.0- 5.0 sec  39.1 MBytes  39.1 MBytes/sec
[  3]  5.0- 6.0 sec  39.5 MBytes  39.5 MBytes/sec
[  3]  6.0- 7.0 sec  38.9 MBytes  38.9 MBytes/sec
[  3]  7.0- 8.0 sec  39.8 MBytes  39.8 MBytes/sec
[  3]  8.0- 9.0 sec  38.6 MBytes  38.6 MBytes/sec
[  3]  9.0-10.0 sec  39.2 MBytes  39.2 MBytes/sec
[  3] 10.0-11.0 sec  39.0 MBytes  39.0 MBytes/sec
[  3] 11.0-12.0 sec  39.0 MBytes  39.0 MBytes/sec
[  3] 12.0-13.0 sec  39.5 MBytes  39.5 MBytes/sec
[  3] 13.0-14.0 sec  38.8 MBytes  38.8 MBytes/sec
[  3] 14.0-15.0 sec  38.8 MBytes  38.8 MBytes/sec
[  3] 15.0-16.0 sec  39.1 MBytes  39.1 MBytes/sec
[  3] 16.0-17.0 sec  39.8 MBytes  39.8 MBytes/sec
[  3] 17.0-18.0 sec  40.1 MBytes  40.1 MBytes/sec
[  3] 18.0-19.0 sec  40.0 MBytes  40.0 MBytes/sec
[  3] 19.0-20.0 sec  40.0 MBytes  40.0 MBytes/sec
[  3]  0.0-20.0 sec   787 MBytes  39.3 MBytes/sec
[  3] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
Done.
............z cehoz jsem ponekud jelen protoze to je jeste min nez kdyz sel trafik PRES router a jeste dal na server.
Takze jsem zkusil zmerit prutok od routeru (client) primym kabelem na FreeNAS (kde posloucha server):

Client connecting to 172.x.x.x, TCP port 5001
TCP window size: 65.0 KByte (default)
------------------------------------------------------------
[  8] local 172.x.x.x port 57411 connected with 172.x.x.x port 5001
[ ID] Interval       Transfer     Bandwidth
[  8]  0.0-10.3 sec   391 MBytes  38.1 MBytes/sec

coz je taky dost tragicky a i vysledek jaxi postrada logiku.....
Nakonec jsem propojil noutas s FreeNASem natvrdo/naprimo kabelem a vysledek byl 102MB/s down a 63MB/s up. NFS pri tomhle setupu davalo jen o malo mensi hodnoty, takze vic z toho asi nevymacknu, coz je divny protoze vsechny sitovky po ceste jsou 1Gb/s Intel (a ty bejvaj dobry) s vyjimkou NICu na noutasu=ten sem taky hned od zacatku podezrival, protoze to je Realtek coz je proslavena sracka, ktera vesla ve znamost napr. tim ze  po chvili max zatizeni jde do kolen a zacne masove ztracet pakety => TCP retransmission a bandwidth jde tim padem do zadeke.... (proto taky vyvojari z PfSense durazne varujou pred cimkoliv od Realteku )
Tady se ale zda ze je v tom Realtek nevinne. Nezda se ani ze by iPerf ukazoval kraviny, zkusil sem spojeni na verejnej 40Gb/s iPerf server v USA a tlacilo to 12MB/s coz zhruba odpovida kdyz moje lajna je 100Mb/s.....
Any ideas ladies and gentlemen??  ;D
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: hugochavez 27. 03. 2016, 04:05:39
FreeBSD mi nesedlo
V čem ti nesedlo? Bude to pravděpodobně jenom nezvyk...
Mozna nezkusil http://www.pcbsd.org/
Jeto FreeBSD s desktopem kde jde vsechno naklikat jako ve Widlich...... Ja to provozoval nekdy pred 5-6ti lety a byl to rychlej stabilni system, kde se dalo nastavit vsechno mozny, akorat tenkrat nebylo jiny prostredi nez KDE a na to ja sem si nikdy nezvyk'........ jenze od ty doby tam pridali 3 ruzny volby navic +vyrobili svuj vlastni desktop Lumina a ted jak koukam od verze 10 uz to umi i Cinnamon  https://community.spiceworks.com/topic/424715-pc-bsd-10-to-include-cinnamon-desktop   Takze asi neni co resit. jo a BTW v defaultu to podporuje ZFS u kteryho je zaruka ze BUDE  FUNGOVAT  :)
viz: PC-BSD or PCBSD, is a trademarked Unix-like, desktop-oriented operating system built upon the most recent releases of FreeBSD. It aims to be easy to install by using a graphical installation program, and easy and ready-to-use immediately by providing KDE SC, LXDE, Xfce, and MATE as the desktop environment. It provides official binary Nvidia and Intel drivers for hardware acceleration and an optional 3D desktop interface through KWin, and Wine is ready-to-use in running Microsoft Windows software. PC-BSD is able to run Linux software,[3] in addition to FreeBSD ports, and it has its own package management system that allows users to graphically install pre-built software packages from a single downloaded executable file, which is unique for BSD operating systems. -->(cili stejnej styl jako  .exe u  Widli akorat tady se tomu install-souboru rikaj  .pbi , 2 x kliknes a je nainstalovano. Myslim ze to ma i repo softu ala Linux)
Anebo si pockat na Ubuntu, tady vyhrozujou ze v Aprilovym LTS vydani by to melo defaultne umet ZFS  :)
http://arstechnica.com/gadgets/2016/02/zfs-filesystem-will-be-built-into-ubuntu-16-04-lts-by-default/

PC-BSD supports ZFS, and the installer offers disk encryption with geli so the system will require a passphrase before booting.  https://en.wikipedia.org/wiki/PC-BSD
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: hugochavez 27. 03. 2016, 04:16:58
recordsize=1M. Keď som to skúšal pred rokom na klasike (128kB), dostal som z diskov asi polovičný výkon -  teraz nehľadá sektory ale číta
To by mohlo být ono. Ale hodí se jenom někde :(


Samozrejme používam ho na virtuálne médiá - pri lz4 už z princípu nikdy nebude sedieť zarovnanie virtuálnych sektorov fyzicky na zfs, teoreticky by sa to mohlo riešiť cez recordsize=4k a bez kompresie, ale vyskúšal som recordsize=1M s tým, že zfs si tieto nezrovnalosti bude riešiť v RAM a podľa mňa to funguje.
Ďalej je to vhodné pre veľmi veľké multimédiá (30GB mkv a podobne)

Nerek' bych ze video v .mkv se ti povede jeste dale zkomprimovat pres lz4, zrovna tak mp3...........
Videa jsou obecne uz tak zkomprimovany na kost takze tam uz dalsi prostor neni....... Jak pravi klasik: "z ho.na bic neupletes"  Zkus to uvidis  ;)
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: hugochavez 27. 03. 2016, 05:13:38
v RAIDZ2 se můžou bez vlivu na data odmlčet disky dva (aka RAID6) v RAIDZ1 jeden (aka RAID5)

partice jsou potřeba třeba kvůli jiným OS (widle), aby disk nechtěly pořád formátovat a kvůli bios/efi aby z toho mohli bootovat, jestli nepotřebuješ, tak to tam dávat nemusíš, výhoda je, že odpadá kontrola zarovnání partic

podle mě to ZFS nejde takhle rozšiřovat: jeden disk > mirror > raidz2 (to zase jde v btrfs), v zfs budeš muset data zazálohovat a pole znovu vytvořit
Jestli sem ho spravne pochopil tak chtel "zapnout v ZFS šifrování a rozšiřovat pool v budoucnu přidávám paranoidně raději 4 diskových RAIDZ2 vdevů (2+2 redundance)?"  v budoucnu rozsirovat pool pridavanim dalsich VDEV v konstelaci 4disky v RaidZ2 coz samozrejme jde. Dokonce jeto doporucovane reseni a ziska tim 2nasobnou rychlost a polovicni dobu pri "resilveringu" (pri 3 x vdev ziska 3nasobnou rychlost atd) Obecne plati zasada ze KAZDY VDEV SE STARA O SVOJI VLASTNI REDUNDANCI. Na to je potreba myslet - cili pri tomhle reseni mu muzou v kazdym vdev (anebo jak ja rikam hezky cesky v kazde vetvi) kleknout 2 disky a neprijde o data, coz je pomerne OK reseni. NEDOPORUCUJE se skladat vdev z vice nez 10-12ti disku. Sance ze kleknou 2 disky z 12ti je evidentne vyssi nez ze kleknou 2 ze 4 napr. Zaroven je potreba mit na pameti ze kdyz vadnej disk vyhodime a provadime resilvering toho novyho taxe ze VSECH ostatnich disku nonstop cte a dostavaj se tim pod nadstandartni zatez. Coz je duvod proc se RaidZ1 povazuje za nebezpecny reseni= je mnohem vetsi sance (obzvlast kdyz jsou vsechny HDDs ze stejny vyrobni serie) ze novy disk jeste "nedostal vsechny data od kolegu" ale zaroven pod zatezi uz klekne dalsi disk= tim jde cely pool do kytek. Obzvlast kdyz je nekdo kamikaze a postavi si vdev z 50ti disku..... To pak muze resilvering trvat i nekolik tydnu a je skoro tutovka ze behem takove doby zvyseneho tlaku chcipne  i dalsi HDD.
 Pocet vdev naproti tomu neni omezen, takze je optimalni tvorit vice vdev s mensim poctem disku.

Jina moznost (a nee zrovna lacina) jak zvysit kapacitu v RaidZ2 je, ze postupne vymenime vsechny disky ve STAVAJICIM vdev, cili odpojit (softwarove!) 1 kus nahradit o jinym s vyssi kapacitou a provest resilvering dat. To same s druhym diskem atd. Je zajimave ze kapacita po celou dobu tehle operace zustava stale puvodni a cely efekt se projevi az PO VYMENE POSLEDNIHO disku za vetsi, kdy SKOKOVE naroste velikost celeho poolu.  :)  To je jedna z libustek ZFS systemu ktera mnohe uzivatele zaskoci.

Treti moznost je udelat dalsi vdev a do nej dat treba "zrdcadla" (staci pak i 2disky) =urcite by to fungovalo ale takove combo se obecne nedoporucuje protoze pak dochazi k penalizaci rychlosti = zrcadla nectou tak rychle jak by mohla protoze je "tahne ke dnu" RaidZ kterej je vzdycky o neco pomalejsi nez mirroring......
Tady je docela zajimavej pokec s vyvojarem ZFS https://www.youtube.com/watch?v=B_OEUfOmU8w#t=30m01s  kde popisuje jaka prekvapeni muze clovek zazit pri opravdu velkych poolech.
A tady je zajimavej+kriticky psanej clanek  o nevyhodach/omezenich ZFS systemu pro domaci NAS
http://louwrentius.com/the-hidden-cost-of-using-zfs-for-your-home-nas.html
Pokud jde o fakta tak pisatel evidentne vi o cem mluvi (sam provozuje 2 ZFS servery) takze jako shrnuti/pouceni je to dobry cteni, osobne ale jeho uvahy a rady povazuju za bezcenne tim spis ze doporucuje druhym lidem jakou by si meli poridit redundaci/bezpecnost svych dat (aniz by je vubec znal) a pritom vychazi ze svych vlastnich subjektivnich uvah...... Navic kdyz tam doporucuje komercni Synology (jejichz NASy nedavno celily ransomware utokum) a QNAP taxi rikam jestli ten clanek nebyl dokonce zaplacenej.....
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: hugochavez 01. 04. 2016, 23:17:51

Aha, to je dobré vědět, děkuji. Jen na tom nechápu: Myslel jsem, že Linux je rozšířenější než FreeBSD či OpenIndiana, tj. software by měl být pro Linux obecně lépe odladěný. Je to jinak?
[/quote]
Nerekl bych ze Linux je rozsirenejsi nez BSD, jen je asi znamejsi protoze ruzny klony BSD nejsou tolik videt i kdyz se pouzivaj vsude mozne v enterprise resenich = telekomunikace, banky, CERN, ty velke teleskopy v Chile pouzivaj BSD compy pro adaptivni optiku, NASA a urcite bys nasel i par BSD kousku na ISS vesmirny stanici  :) Vono totiz kdyz krouzis 100km nad zemi a ses zavislej na pristrojich tak je dost blby abys kazdou chvili musel resit "blue screen of death"  ;D Mimochodem rozhlidni se jak jsou rozsireny Widle- a opravdu nevim jestli se da mluvit o odladenosti......
BTW v OSX od Applu taky "koluje dost BSD krve" https://en.wikipedia.org/wiki/History_of_OS_X#/media/File:Unix_history-simple.svg  Rozsireni systemu nemuze byt meritkem odladenosti - ta se odviji od toho jaka je komunita vyvojaru, jak spolu dokazou interagovat a komunikovat......
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: hugochavez 01. 04. 2016, 23:31:36
Zdravim,
mam se ZFS filesystemem par let zkusenosti. Taky jsem se dostal do takove patove situace s nizkym vykonem............
.......3) deduplikace: s 8TB na ni bohuzel nemas dostatek pameti. Taky jsem s ni koketoval, po problemech s vykonem jsem ji vypnul, ale i pak obcas jsem mel problemy, kdyz se zacly cist deduplikovane data ( 8GB RAM a 4TB disk). Taky scrub celeho disku se na deduplikovanych datech brzdil moc.
..........
Prakticka poznamka: pokud admin naplanuje scrub disku tak ze se "prekryje" s naplanovanou probihajici "deduplikaci" tak system spolehlive zamrzne.
Mezi BSD devs probihaly debaty proc tomu tak je ale myslim ze to dosud nevyresili.
Staci ale tyhle 2 operace proste rozhodit v case a problemu se tak elegantne vyhnout.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: hugochavez 02. 04. 2016, 00:00:44
Hashe používané při deduplikaci se při čtení nijak necachují? Dokáži si představit situace, kdy by se to hodilo.
v RAMce bezi tabulka kde se porovnavaj hashe stavajici s hashema ctenych bloku aby se zjistilo zda soubory nejsou identicke.......... a to je duvod toho pozadavku min 5GB RAM na 1TB storage.
Tohle muze byt i duvod te kolize kdyz se potka dedup se scrubem= scrub cte+analyzuje podle hashu zda je soubor konzistentni+nasledne opravuje podle dat z jinych disku tak aby sedel checksum. Dedup hashuje+porovnava+maze duplikovane soubory+prepisuje pointer ukazujici na dany soubor. Pokud tohle zacnou delat soucasne je celkem ocekavatelny ze se casem "zacnou hadat" a system nasledne zamrzne.
Neni bez zajimavosti ze ZFS umi porovnavat data "bit po bitu"  :)  myslim ale ze to je volitelna ficura a nedela to defaultne vzdycky pri nalezeni 2 identickych files)  Da se to zapnout.
Název: Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk
Přispěvatel: hugochavez 02. 04. 2016, 00:14:43
Ještě mě napadá, že může být problém se zarovnáním na 4k bloky. Hlavní problém bude ta deduplikace, ale zarovnání by taky mělo být.

Děkuji za tip. Každopádně více než rychlost nyní řeším hlavně plynulost zápisu a aby bylo možné mazat snapshoty........
.......... a nejproblematičtější snapshot se podařilo během 5 hodin smazat potom, co jsem včera odinstaloval ubuntu-zfs (nativní ZFS) a nainstaloval ZFS-FUSE. Akorát zlobí nepochopitelně oprávnění (soubor vlastní uživatel krato, nelze ho otevřít, provedu "chown krato" a už ho lze otevřít), nelze mountovat snapshoty (obchází se klonováním na nový volume) a když jsem se pokusil přihlásit do KDE s domovským adresářem na ZFS, tak ZFS-FUSE dost ošklivě spadl......

 Na velkou RAM nejsou finanční prostředky a navíc není jistota, že by na plynulost zápisu pomohla.
Snapshot u ZFS znamena jedine = data jichz se snapshot v danou chvili tyka dostanou "visacku" NEMAZAT-NEPREPISOVAT!   :)  nic vic se s nima nedeje= zustavaj tedy dal na disku. Jelikoz sou takto "zamrazena" jsou vhodna k back-up exportu nekam jinam.  Spousta lidi si ale mysli ze snapshot je nejakej zpusob zalohovani a paxi lamou hlavu PROC jim sakra nektery soubory nejdou smazat........   ;D
PS: Snapshot jak ho dela ZFS je velmi efektivni proto ze i pri pomerne velkem a zaplnenem datasetu jeho vytvoreni trva radove zlomky sekund.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: hugochavez 02. 04. 2016, 00:39:17
Jinak možná blbne hw disku? Stál by za to ho prověřit jednak smartem a pak vlastní zfs
Kód: [Vybrat]
zpool scrub all
Disk byl hned po koupi pro jistotu zkontrolován přes "badblocks -w". Díky za tip na zpool scrub. Jen se obávám, že výsledek budu vědět až za několik dní nebo týdnů.
Pokud muzu doporucit soft na recovery dat a analyzu stavu disku (klidne i novych = i ty uz jsou plny defektnich bloku) tak me se osvedcilo tohle https://en.wikipedia.org/wiki/SpinRite 
Napsal to pred lety Steve Gibson coz je takovej malej genius a SW funguje dost dobre i jako "udrzbar sektoru" na soucasnych SSD (pouzit level2 !! NEE level 4)
v pripade ze disk je hodne poskozen, zkousi soft cist stejny bit az 2.000x pri ruznych pozicich hlavy cimz se HDD hodne zahreje =ma sice zabudovanou teplotni stopku, ale podle kapacity a stupne poskozeni nekdy muze cteni dat presto trvat tydny pripadne mesice a nekdy je nutne dat disk v prubehu recovery jeste do lednice  :)
Stoji $90 a za tech 10let co ho pouzivam me jeste nikdy zadnej HDD neprekvapil tim ze by nahle  kleknul..... Ten soft to ukaze pomerne v predstihu pripadne dokaze zrekonstruovat data z disku kterej UZ KLEKNUL..... pokud tedy u nej neodesel motor protoze s tim zadnej SW nic udelat nemuze.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: hugochavez 02. 04. 2016, 00:56:13
Log(ZIL) alebo cache (L2ARC)? Sú to pre mňa 2 odlišné partície. Každá má zmysel, každá je určená na niečo iné a spolu sa dopĺňajú.
Přesně tak. L2ARC může být libovolně malá a může se klidně i porouchat, nic se neděje. ZIL je přesný opak - porouchat se nesmí (obsahuje ještě na disk nezapsaná data) a velikost musí mít dostatečnou podle toho, kolik se na disk (maximálně) zapisuje. Pokud se na ZIL nedá zapisovat v dostatečném množství a rychleji než na samotný disk, postrádá smysl a degraduje výkon.
male upresneni ohledne L2ARC:
ZFS provides a read cache in RAM, known as the ARC, to reduce read latency. FreeNAS® adds ARC stats to top(1) and includes the arc_summary.py and arcstat.py tools for monitoring the efficiency of the ARC. If an SSD is dedicated as a cache device, it is known as an L2ARC and ZFS uses it to store more reads which can increase random read performance. However, adding an L2ARC is not a substitute for insufficient RAM as L2ARC needs RAM in order to function. If you do not have enough RAM for a good sized ARC, you will not be increasing performance, and in most cases you will actually hurt performance and could potentially cause system instability. RAM is always faster than disks, so always add as much RAM as possible before determining if the system would benefit from a L2ARC device. If you have a lot of applications that do large amounts of random reads, on a dataset small enough to fit into the L2ARC, read performance may be increased by adding a dedicated cache device using Volume Manager. SSD cache devices only help if your active data is larger than system RAM, but small enough that a significant percentage of it will fit on the SSD.

 As a general rule of thumb, an L2ARC should not be added to a system with less than 64 GB of RAM and the size of an L2ARC should not exceed 5x the amount of RAM.

In some cases, it may be more efficient to have two separate pools: one on SSDs for active data and another on hard drives for rarely used content. After adding an L2ARC, monitor its effectiveness using tools such as arcstat. If you need to increase the size of an existing L2ARC, you can stripe another cache device using Volume Manager. The GUI will always stripe L2ARC, not mirror it, as the contents of L2ARC are recreated at boot. Losing an L2ARC device will not affect the integrity of the pool, but may have an impact on read performance, depending upon the workload and the ratio of dataset size to cache size. Note that a dedicated L2ARC device can not be shared between ZFS pools.
viz. http://doc.freenas.org/9.10/freenas_intro.html?highlight=deduplication#zfs-primer

Jinak kdyz ted koukam na svuj FreeNAS tak ukazuje:
ARC size Cur=22.7GB Avg=22.95G Max=23.4G Min=22.68G
L2ARC nemam
celkova osazena RAM je 32GB

Název: Re: ma ty prostoto!
Přispěvatel: hugochavez 02. 04. 2016, 01:18:48
Mám si tedy se ZFS hrát na Oracle Solaris nebo FreeBSD (nebo FreeNAS)?
Solaris je komerční placený produkt. Existují free klony, ale jsou málo používané, takže třeba tady nečekej, že ti s tím někdo poradí. FreeNAS je FreeBSD+UI specializovaný na NAS. Možná mají nějakých pár svých extra patchů, které se pak později dostanou do upstream FreeBSD, nevím, jak moc rychle a jestli vůbec. Je to od firmy https://www.ixsystems.com která se na ukládání dat specializuje, má i spešl odladěný HW a komerční podporu. Komerční varianta FreeNAS se jmenuje TrueNAS. S oficiálním hw to není úplně levná záležitost, ale mělo by to být velmi kvalitní.
TrueNAS je enterprise reseni https://www.ixsystems.com/servers/ 
a pro SOHO pouziti maj FreeNAS mini https://www.ixsystems.com/freenas-mini/
kterej je taky moc povedenej a ted koncem Aprila by meli zacit prodavat 8bay-FreeNAS mini.
Ja ten mini chtel kdysi koupit jako hotovy reseni ale v EU to nikdo neprodava a z USA by jen shipping vysel na $200 +DPH+CLO a to me odradilo kdyz cela krabice stala bez disku $1k. Taxem vygoogloval ze ceho to maj smontovany a postavil sem si to sam -ale nemam to tak hezky  :'(
Jinak velky plus techle lidi od iXsystems je ze stavej "storage reseni na miru" =vyzpovidaj zadavatele co na tom chce provozovat za typ dat a jaky objemy a rychlosti a jeho ocekavani atd a podle toho navrhnou reseni a daj to dohromady. Navic je vyhoda ze to delaj ty samy lidi co pisou ten software takze i kdyz jim pak zavola zakaznik/uzivatel s konkretnim problemem tak ten kdo zvedne tlf vi o cem je rec..........na rozdil od spousty jinejch firem kde userovi natlacej hotovej server z regalu a kdyz zavola za tejden na support taxi akorat udela kolecko od 1 debila k druhymu.....
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Lol Phirae 02. 04. 2016, 10:31:55
Pokud muzu doporucit soft na recovery dat a analyzu stavu disku (klidne i novych = i ty uz jsou plny defektnich bloku) tak me se osvedcilo tohle https://en.wikipedia.org/wiki/SpinRite 

Kristova noho!!!

(http://www.kitsch-slapped.com/wp-content/uploads/2011/01/1950-snake-oil-is-wonderful-stuff.jpg)
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: hugochavez 02. 04. 2016, 14:06:19
Pokud muzu doporucit soft na recovery dat a analyzu stavu disku (klidne i novych = i ty uz jsou plny defektnich bloku) tak me se osvedcilo tohle https://en.wikipedia.org/wiki/SpinRite 
Kristova noho!!!

 :) jestli mas nejakou konstuktivni kritiku ci info taxem s tim! Jsem samy ucho!  :)

(https://earloftaint.files.wordpress.com/2012/06/ears.jpg)

Clovek se vzdycky muze dozvedet neco zajimavyho a opravit si nazor.
Osobne si nemyslim ze by Gibsonovi slo o $, tim spis ze nabizi ze kazdy muze KDYKOLIV ten soft "vratit" a dostane svy $ zpet. Osobne jsem to tenkrat koupil spis abych podporil jeho tydenni podcast https://www.grc.com/securitynow.htm kterej mi hodne dal a kteej on delaj "na kolene a za svy" a ani nechtel zadny donations. Casem jsem zjistil ze ten SW funguje dost dobre na mizerny SSDka = OCZ mi vzdycky fungovaly par mesicu po fresh install a paxe system zacal obcas sekat, grafika obcas "kouzlila" atd. HW byl stejnej a Linux OS taky, takze to podle me bylo "chcipanim memory cells", projel sem to tim SW a problem na par mesicu zmizel. To je moje osobni zkusenost. To bylo ovsem pred lety, SSD se od ty doby dost zlepsily. Muj znamej zase nemoh najet Widle= nemoh se dostat ke svy praci protoze je fotograf. Tenhle soft mu pomoh' a pak radsi zacal vsechno hned zalohovat+vymenil disk.
Takze "take it or leave it"  :)
Mimochodem Gibson vetsinu softu co za ty roky napsal dal na net jako freeware, takze to rozhodne neni chlap kterej je posedlej penezma.
Posledni jeho pocin je napr. tohle  https://www.grc.com/never10.htm
 coz je "Never 10 is an easy to use utility which gives users control over
whether their Windows 7 or 8.1 will upgrade itself to Windows 10"
coz napsal jako reakci na to jakym zpusobem vnutil M$ jeho kamaradce upgrade na W10 o kterej ona nikdy nezadala a pak "protoze se ji tam vsechno zmenilo" z nej byla nestastna....
Hint: tady o tom mluvil v utery v podcastu https:/twit.tv/shows/security-now/episodes/553?autostart=false a k dnesnimu dni tam vidim  80k downloads  :)  nezda se ze by lidi jeho softu neverili  ;)
http://www.infoworld.com/article/3049165/microsoft-windows/steve-gibsons-never10-vs-josh-mayfields-gwx-control-panel.html
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Lol Phirae 02. 04. 2016, 17:26:55
:) jestli mas nejakou konstuktivni kritiku ci info taxem s tim! Jsem samy ucho!  :)

Zkus Google.

Pro toho "experta" nemam slušné slovo. Krom podobných snake-oil sraček produkuje ještě FUD (https://www.grc.com/x/ne.dll?bh0bkyd2) typu "OMG, tvůj počítač odpovídá na ping, tvůj firewall nefunguje a hackeři dostanou!!!", "reverzní DNS záznam je strašně nebezpečný" a myslí si, že když budu packety dropovat místo rejectu, tak se počítač stane neviditelným a nikdo se o něm nedozví.

 ::) ::) ::)
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: hugochavez 03. 04. 2016, 03:18:19
:) jestli mas nejakou konstuktivni kritiku ci info taxem s tim! Jsem samy ucho!  :)

Zkus Google.

Pro toho "experta" nemam slušné slovo. Krom podobných snake-oil sraček produkuje ještě FUD (https://www.grc.com/x/ne.dll?bh0bkyd2) typu "OMG, tvůj počítač odpovídá na ping, tvůj firewall nefunguje a hackeři dostanou!!!", "reverzní DNS záznam je strašně nebezpečný" a myslí si, že když budu packety dropovat místo rejectu, tak se počítač stane neviditelným a nikdo se o něm nedozví.

 ::) ::) ::)

no oznacil's ten soft za podvod taxem se ptal proc a mam si to sam vygooglovat.  :) prima!

pokud jde o "nebezpecny reverse DNS" musis si uvedomit KDY ten text byl psanej= cca 10 let zpatky.
A nesnazi se tam o nic jinyho nez vysvetlit beznymu americkymu BFU ze kdyz brouzda po netu tak NENI ANONYMNI  :) protoze existuje jakysi reverzni DNS zaznam ktery ukazuje jeho IP pres kterou se da dostat k jeho ISP ci primo zjistit geolokaci viz.

 "It may be used to uniquely identify you on the Internet. In that way it's like a "supercookie" over which you have no control. You can not disable, delete, or change it.................... we wanted to make you aware of this possibility. Note also that reverse DNS may disclose your geographic location."

Zaroven muze tahle IP prozradit i uzivatelovo "account ID" coz mozna souvisi se zpusobem jakym ISP administruji svy zakazniky v USA= nevysvetluji jim nic o IP adresach apod. ale reknou jim ze kdyz volaj na support kvuli vyuctovani anebo zapojeni/blokovani sluzeb taxe maj zahlasit "cislem uctu" = account ID (odvozene ale v realu od jejich IP pokud ISP neprovozuje DHCP) coz muze byt vy/zneuzito. Napr tim ze sousedovi odhlasis internet protoze te sere vecny stekani jeho psa, anebo mu priobjednas naky Xtra sluzby a oni mu to mileradi zapnou vzdyt prece uvedl spravny account ID)
Takze nic hlubsiho v tom nehledej.

Pokud jde o dropovani ping paketu namisto reject- urcite to neni koser podle "internetove bible" ale ono kdyz nechces aby te nekdo z netu otravoval tak co myslis ze je lepsi? Delat "ze tam nejsi" anebo na kazdy jeho zavolani odpovidat??   :) 

Za sebe muzu rict ze taky nemam zajem odpovidat kdejakymu Cinanovi kterej mi pinga moji verejnou IP (takze taky dropuju pakety) a ani nemam zajem aby mi nekdo scanoval porty.......staci ze semi kolem FW kazdou chvili vometa Google a Baidu...

Jinak kdyz uz jsme u portu, tam co linkujes nahore je ShieldsUp coz je moznost "zvenku" si nechat oskenovat ktery porty jsou open/closed +popis co jsou zac. To mi prijde jako uzitecna vec, sam jsem ji X-krat pouzil kdyz sem neco predelaval na FW a chtel sem se ujistit "ze je zvenku zavreno".
Ale zase! Spustil tu sluzbu pred X lety = v dobe kdy si lidi hromadne nosili z kramu domu router-vetes za par $ ktera navic mela v defaultu aktivovany PlugNplay. A uz tenkrat byla hromada Widli zavirovana a uz tenkrat si trojani a vselijakej bordel otvirali pres PnP porty tak aby botmaster moh' z IRC lip takovej zombie PC komandovat.
Povedomi o internetu a jeho fungovani bylo tenkrat vicemene nulovy..... v 1 z tech podcastu dokonce tvrdil ( a ja nemam duvod mu neverit) ze situace byla tak tragicka ze ze svyho PC videl C-disky Widlaku patricich pod stejnej LAN segment u jeho ISP....!

Jinak muzu te ubezpecit ze clovek kterej->>

Gibson started working on computers as a teenager, and got his first computing job with Stanford University's artificial intelligence lab when he was 15 years old. He studied electrical engineering and computer science at the University of California, Berkeley.

si je urcite vedom toho ze dropnutim ping paketu se pocitac nestava na netu neviditelnym   ;)

https://en.wikipedia.org/wiki/Steve_Gibson_%28computer_programmer%29

https://www.grc.com/sqrl/sqrl.htm

Takze asi tak.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: Lol Phirae 03. 04. 2016, 11:53:05
no oznacil's ten soft za podvod taxem se ptal proc a mam si to sam vygooglovat.  :) prima!

Jo. Vygoogluj. Definitivně zničit už poškozený disk nekonečnými pokusy o čtení/zápis zvládneš i bez jeho snake-oil utility za 90 dolarů nebo kolik za tu podvodnou sračku chce. Takhle nikdo data recovery nedělá. Krom toho, ten křáp ustrnul vývojem asi před 15 lety, v době, kdy se dal dělat low-level formát z BIOSu. Dnes nic takového samozřejmě není možné a to, co eventálně mohlo kdysi snad něco dělat, je skutečně akorát snake-oil dobrý k definitivnímu doražení nakřáplého disku.

Pokud jde o dropovani ping paketu namisto reject- urcite to neni koser podle "internetove bible" ale ono kdyz nechces aby te nekdo z netu otravoval tak co myslis ze je lepsi? Delat "ze tam nejsi" anebo na kazdy jeho zavolani odpovidat??

Tak já to tady pastnu celý, tu jeho kokotinu:

Citace
Ping Reply: RECEIVED (FAILED) — Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet. Most personal firewalls can be configured to block, drop, and ignore such ping requests in order to better hide systems from hackers. This is highly recommended since "Ping" is among the oldest and most common methods used to locate systems prior to further exploitation.

Když budu pakety dropovat, tak tomu útočníkovi je jasné, že ne že ten počítač neexistuje, ale naopak to, že je za firewallem, protože kdyby tam ten počítač nebyl, tak místo toho dostane od routeru před ním normální odpověď ICMP Destination Unreachable (net unreachable/host unreachable - Type 3 Code 0/1).

si je urcite vedom toho ze dropnutim ping paketu se pocitac nestava na netu neviditelnym   ;)

To je možné, nicméně ten nesmysl furt cpe chudákům, co si - jak jsi správně napsal - jen chtěj zvenku otestovat, jestli jim ten firewall funguje. Permanentně jim ten nesmysl už přes 15 let cpe přes ten jeho Shields-Up který se rozšířil jako mor. Přes 15 let první věc, co potom BFU udělá, je to, že vleze na diskusní fórum výrobce firewallu a začne řvát "Oh noes, your firewall is POS, my computer not stealth, you suck!!!111!".

Je mi úplně jedno, jak je ten test starej, buď ať to aktualizuje nebo ať to vypne místo šíření FUD. Dement.
Název: Re:ZFS pozastavuje zápis po zaplnění bufferu
Přispěvatel: hugochavez 04. 04. 2016, 04:58:48
no oznacil's ten soft za podvod taxem se ptal proc a mam si to sam vygooglovat.  :) prima!

Citace
Jo. Vygoogluj. Definitivně zničit už poškozený disk nekonečnými pokusy o čtení/zápis zvládneš i bez jeho snake-oil utility za 90 dolarů............. Takhle nikdo data recovery nedělá. Krom toho, ten křáp ustrnul vývojem asi před 15 lety, v době, kdy se dal dělat low-level formát z BIOSu............co eventálně mohlo kdysi snad něco dělat, je skutečně akorát snake-oil dobrý k definitivnímu doražení nakřáplého disku.


Ten soft byl od zacatku myslenej jako "refreshing the surface" protoze disk controller si casto chybu uvedomi az kdyz uz data nejdou vubec precist= pozde. Navic muze dochazet k tzv. bit-rot =uhnivani bitu, coz je problem ktery napr. resi ZFS pravidelnym SCRUBem. Tenkrat ZFS nebyl takze napad donutit disk "cist jednou za cas VSECHNY bity" byl v tehdejsi dobe prulomovej. A zrejme to fungovalo lip nez cokoliv jinyho na trhu. Druhy ukol byl dostat data z disku kterej je na pokraji smrti "za kazdou cenu"=  a Gibson se tim nikdy netajil ze pokud je disk v klinicky smrti a pouzije se na nej SpinRite jako instance posledni zachrany jak vydolovat data, tak to budou asi taky posledni data ktery vubec poskytne a pak adios amigos!
Coz ale kazdej kdo nema jinou zalohu celkem rad akceptuje. Je ale fakt ze ten soft ve vyvoji zaostal takze napr. uz nezvlada disky s velkyma kapacitama. Anebo -i kdyz by mu melo bejt fuk jakej 'tam nahore" beha OS tak presto nedokaze udelat test na mym NASu kde je 5x1TB a vsechny jsou full encrypted v geli. Trva 45min nez vubec nacte CO a KOLIK tam je disku. Az se k tomu dostanu udelam naky screenshots a pisnu Gibsonovi co on nato. Solo sem ty disky nezkousel.
Dalsi vec kterou mnozi povazujou za vaznej nedostatek je ze nezachranuje data rovnou nekam jinam ale uklada horko tezko precteny bity zpet na medium ktery je stejne jednou nohou v hrobe....
Na druhou stranu napr. level4 povazuju za docela dobrej test kvality= zasifrujes celej disk napr. pomoci TC a pak se vsechny bity ctou, flipnou a zapisou a znovu prectou flipnou a znova zapisou. Paxe udela analyza kolik je vadnejch sektoru. Nekdy jeto tragedie uz u novyho disku. No a jak rikam snake-oil ne-snake-oil na "surface=refresh" SSDcek semito osvedcilo naramne. Nerikam ale ze neexistujou lepsi softy. -ty ale budou asi za jiny $  ;)  Ten soft proste JE 15let starej.
BTW dela na novy verzi, mela by bejt ready ted v lete. A kazdej kdo uz licenci ma ze stary verze taxi sosne novou gratis- a takhle to prej bude navzdy = tomu chlapovi skutecne nejde o prachy.

Citace
Když budu pakety dropovat, tak tomu útočníkovi je jasné, že ne že ten počítač neexistuje, ale naopak to, že je za firewallem, protože kdyby tam ten počítač nebyl, tak místo toho dostane od routeru před ním normální odpověď ICMP Destination Unreachable (net unreachable/host unreachable - Type 3 Code 0/1).


Jo to mas pravdu ale jaxem uz psal- ber to jako osvetu smerovanou pred 15ti lety beznymu americkymu BFU. Tam nemuzes resit naky routery a ICMP hlasky  :D


Citace
To je možné, nicméně ten nesmysl furt cpe chudákům, co si - jak jsi správně napsal - jen chtěj zvenku otestovat, jestli jim ten firewall funguje. Permanentně jim ten nesmysl už přes 15 let cpe přes ten jeho Shields-Up který se rozšířil jako mor. Přes 15 let první věc, co potom BFU udělá, je to, že vleze na diskusní fórum výrobce firewallu a začne řvát "Oh noes, your firewall is POS, my computer not stealth, you suck!!!111!".

Tak ono ze psousta uzivatelu rve na vyrobce FW ze vyrabej PoS neni az zas tak od veci   ;D Je to v podstate popis realnyho stavu. BTW nedavno si tydlety vykukove zkouseli prolobovat u FCC takovy regule ze by v podstate zarizli firmware jako DD-WRT, Tomato atd.
Ale jinak mas v podstate pravdu. Ale jaxem psal uz driv- tenkrat to byl Wild West (teda nee ze by sme se od ty doby kdovijak posunuli) a napr. Shields-Up byla reakce na totalni komercni sracko-routery ( a sme zas u toho PoS)  ktery oteviraly pres DEFAULTNE AKTIVOVANY PnP (=aby to vsechno fungovalo hned po zapnuti a BFU jim nevolali na support protoze support stoji $ a nezbylo by pak na vejvar pro akcionare) porty do interfernetu jaxi kde jaka kravina anebo trojan v LANu zamanul a v GUI se to tomu chudaku uzivateli ani nezobrazilo!! A mam dojem ze dodneska takovou prasecinu nektery "profesionalni" vyrobci routeru lidem vesele prodavaj. Pak neni jina moznost nez aby externi porty proskenoval nekdo jinej=mene blbej.

Citace
Je mi úplně jedno, jak je ten test starej, buď ať to aktualizuje nebo ať to vypne místo šíření FUD. Dement.

 :) Ber to tak ze to delal ve svym volnym case a provozoval za svy $ na svym zeleze (a upload bandwith neni dodneska v USA nijak levna zalezistost= soudruzi u Netflixu by ti mohli vypravet jak je kdejakej Comcast vykuk chce podojit), takze "darovanemu koni na zuby nesahej"  :)
Ale aktualizovat by ten svuj web 1x za cas mel.........uz mu to rikalo vic lidi......
Název: Re: ma ty prostoto!
Přispěvatel: hugochavez 04. 04. 2016, 05:23:48
Citace
PS: jen pro orientaci par udaju o mem ZFS systemu.
deska
 http://www.asrockrack.com/general/productdetail.asp?Model=C2750D4I#Specifications 
4x8GB ECC RAM, 5x1TB WD RED (kvuli spotrebe) nastaveny jako RaidZ2 s kompresi LZ4 + full disk encryption Geli  (FreeBSD default crypto protoze Oracle-crypto nelze kvuli copyrightu pouzit) Sifrovani probiha HW AES-NI ktere deska podporuje.

Pokud se nekdo nechal inspirovat a planuje pouzit stejnej typ desky anebo ten druhej typ se 4-jadrem (jinak ale identickej) tak je dobry vedet ze ta deska ma zvlastni uchylku= trva klidne i 40-50 sekund nez vubec nabehne BIOS  :o  do ty doby black screen a vypada to jako by deska byla defektni. To sem si taky ze zacatku myslel taxem zagoogloval a zjistil sem ze nektery Amici vratili i 2 desky jako vadny nez jim u 3ti doslo ze proste neskutecne pomalu nabiha. Jinak s ni problemy uz pak nejsou. Otazka je jestli je chytry delat mix Intel+Marvell nez tam prsknout vsechno od Intelu.

PS: typ se 4jadrem pouzivali donedavna iXsystems do svyho FreeNASmini reseni  https://www.ixsystems.com/freenas-mini/  ale ted uz tam davaj standartne 8mi jadro.