ZFS pozastavuje zápis po zaplnění bufferu

[Petr Kratochvíl]

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).

[Reklama]

[Mirek Prýmek]

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í.

[Vladimír Drgoňa]

(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:

• 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
• partícia je pakovaná lz4. Nemalo by tam byť veľa voľného miesta, pretože je dynamicky alokovaný - ale i tak z platní prečíta menej dát ako je skutočnosť.

[Mirek Prýmek]

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.

[Vladimír Drgoňa]

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.

[Reklama]

[Mirek Prýmek]

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

[Petr Kratochvíl]

Ř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.

[hugochavez]

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 )

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 )


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?? 

[hugochavez]

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

[hugochavez]

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 

[hugochavez]

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.....

[hugochavez]

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"  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......

[hugochavez]

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.

[hugochavez]

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.

[hugochavez]

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........   
PS: Snapshot jak ho dela ZFS je velmi efektivni proto ze i pri pomerne velkem a zaplnenem datasetu jeho vytvoreni trva radove zlomky sekund.