Het grote ZFS topic

[MikeVM]

Verwijderd schreef op woensdag 12 december 2012 @ 18:46:
Mijn advies: investeer niet meer in oudere systemen op basis van DDR2. Blijf bij wat je hebt, of koop een nieuw platform met goedkoper spul zoals 32GiB DDR3 voor 120 euro. Je huidige hardware kun je uitstekend gebruiken voor een systeem wat niet 24/7 draait, dan heb je veel minder last van de relatieve onzuinigheid van dit platform. Q6600 is inderdaad ook minder zuinig en uiteindelijk heb je een hoge idle power, veel hoger dan een nieuw platform. Voor een 24/7 systeem valt een nieuw platform dus te overwegen.

Je kunt echter prima wachten tot het nieuwe Intel Haswell platform wat idle nog zuiniger zou zijn. Met name de mobiele Intel Haswell zou idle veel en veel zuiniger moeten zijn door nieuwe energiebesparende technieken. Tot factor 20 lagere idle power is gewoon geweldig. Nog wel afwachten of het daadwerkelijk te koop wordt, of alleen OEM-spul wordt zoals zo vaak bij zuinige hardware.

Quote van Anand:

[...]

ik ga even een Watt-meter aan mijn server hangen, nu er nog alle disks in hangen, deze avond gaan de helf van de disks naar een andere server.. (Testserver ZFS)

spijtig ondersteund de nieuwe server Atom maar maximaal 8GB DDR3..

[ebia]

Eindelijk m'n disk terug van de RMA en gaan spelen met m'n NAS. Heb 6 Deskstar 5k3000 disken gehangen aan een AMD Brazos bordje met 16 GB geheugen. Nu zit ik een beetje met tegenvallende performance. Of ik nu Raid-z of Raid-z2 gebruik, ik zit ongeveer rond 45~50 Mb/s op zowel read als write. Dit met ZFSguru, op een SMB share.

Is dat een beetje de te verwachten snelheid, of zit er nog iets niet goed? Het lijkt erop alsof de performance gecapped wordt op de CPU, want die staat bij lees of schrijfacties continue boven de 100%, geheugengebruik is nihil. Iemand een idee?

[krijn1985]

Ik heb ook een brazos bordje met 16GB geheugen. Zie hier mijn posts met test resultaten en dingen die ik geprobeerd heb. Waarschijnlijk is deels mijn desktop de bottleneck. Uiteindelijk gebruik ik nu SMB. Niet veel tests meer gedaan maar haal wisselende resultaten tussen de 25 MB/s (vooral klein bestanden zoals foto's) tot ongeveer 80 MB/s (vooral grote bestanden volgens mij).

[ Voor 1% gewijzigd door krijn1985 op 13-12-2012 00:31 . Reden: typo's ]

[sloth]

Welk brazos bordje heb je precies? Er is een verschil tussen een C60 en een E350 bv.

Staat compressie uit?

Heb je je netwerk (nics, bekabeling, switch/router) al als bottleneck uitgesloten? Kan je ook eens testen met ftp met een grote buffer size (bv. 64k)?

Verder is FreeBSD (icm ZFS) in vergelijking met Windows op basis met mijn ervaringen een pak langzamer.
Tussen een Windows 7 bak en windows 7 op m'n C60 haal ik ~100MB/s via SMB, terwijl dat met ZFSguru slechts 55MB/s is.

[krijn1985]

Ik heb deze dus op E350.

Ik heb bekabeling eigenlijk niet gewisseld. Kan ik binnenkort nog even proberen. Router (WRT320n) heb ik in zoverre uitgesloten dat deze qua load niet op zijn limiet zat, wat bij mijn vorige router (WRT54GL) wel de bottleneck was. Als ik deze iets overclockte haalde ik hogere snelheden op mijn 100Mbit verbinding.

Ik heb niks met ftp getest, gebruik het namelijk niet. Als het standaard in Freebsd zit kan ik daar wel even naar kijken nog. Met windows 7 heb ik niet getest, enige windows 7 apparaat dat ik heb is een oude laptop met een 100Mbit netwerkkaart.

[Verwijderd]

FireDrunk schreef op woensdag 12 december 2012 @ 19:08:
If it sounds to good to be true... It usually is..

Dat dacht ik ook. Toch zijn er wel aanleidingen om te veronderstellen dat het mobiele Haswell-platform inderdaad grote winsten gaat boeken op gebied van idle power. Zo is de VRM-stroomvoorziening nu in de chip geïntegreerd. Nog een factor minder waar moederbord/systeembouwers de mist in kunnen gaan. Het wordt nu een sterk-geïntegreerde SoC en zou je een dergelijk kaal platform vergelijken met een kaal SandyBridge platform kan een dergelijke energiebesparing wellicht wel waargemaakt worden.

De eerste drie balkjes van dit plaatje kloppen namelijk aardig naar mijn idee:



Meer achtergrondinformatie:
http://www.anandtech.com/...ls-haswell-architecture/3

Ik ben wel enthousiast, maar wel bang dat dit platform en diens power savings onbereikbaar zal worden voor desktops. Maar desnoods koop ik een laptop en sloop ik hem enkel voor het mobiele Haswell-platform. Als een dergelijk grafiekje zou kloppen en een high-end systeem rond de 1W idle kan lopen superkaal, dan heb ik dat er wel voor over. Het voornaamste argument is dat met dergelijk energieverbruik je een nuttig systeem altijd kunt laten draaien omdat het vrijwel geen energie meer verbruikt. Dat maakt de economische levensduur van het product veel langer. Want nu vervangen we een oud maar goed platform zoals Q6600 enkel vanwege energieverbruik; met 1W idle valt dat argument weg en kun je dergelijke hardware voor meerdere decennia nuttig inzetten.

ebia schreef op donderdag 13 december 2012 @ 00:10:
Eindelijk m'n disk terug van de RMA en gaan spelen met m'n NAS. Heb 6 Deskstar 5k3000 disken gehangen aan een AMD Brazos bordje met 16 GB geheugen. Nu zit ik een beetje met tegenvallende performance. Of ik nu Raid-z of Raid-z2 gebruik, ik zit ongeveer rond 45~50 Mb/s op zowel read als write. Dit met ZFSguru, op een SMB share.

Is dat een beetje de te verwachten snelheid, of zit er nog iets niet goed? Het lijkt erop alsof de performance gecapped wordt op de CPU, want die staat bij lees of schrijfacties continue boven de 100%, geheugengebruik is nihil. Iemand een idee?

Laat meer benchmarks zien! Bijvoorbeeld de ZFSguru pool benchmark, en een iperf benchmark. Bedenk dat als je via het netwerk via Samba simpele kopiëeracties doet, je lokale schijf heel goed de bottleneck kan zijn. Kijk dus ook eens naar de HDD LED op je client PC.

Dat 100% CPU is niet direct reden tot zorg aangezien ZFS burst writes doet. Dus de disk activiteit wordt om de zoveel seconden in bursts (transacties) gedaan waarbij gedurende korte tijd de disks (en CPU) volop belast kunnen worden. Dat wil nog niet zeggen dat dit ook je bottleneck is. En zelfs als dat wel zo is, kan dat komen door hoog interrupt usage (kun je zien in top output of via de ZFSguru status output). Hoge interrupts kun je oplossen met een commando als:

ifconfig re0 polling
(vanaf ZFSguru 9.1-004 systeemversie)

[ Voor 30% gewijzigd door Verwijderd op 13-12-2012 02:51 ]

[MikeVM]

MikeVM schreef op woensdag 12 december 2012 @ 19:11:
[...]
ik ga even een Watt-meter aan mijn server hangen, nu er nog alle disks in hangen, deze avond gaan de helf van de disks naar een andere server.. (Testserver ZFS)

spijtig ondersteund de nieuwe server Atom maar maximaal 8GB DDR3..

het verbruik is 177Watt idle, zonder enige besparingsmaatregelen, de spindown van de HDD's in ubuntu staan nog altijd op de standaard instellingen..

dit is met 13 disks, en 1 SSD

Q6600
p5q
8GB Ram DDR2
GT210 videokaart (wat zou dit verbruiken?)

het maximum verbruik is bijna 600 Watt, terwijl ik maar een 300 Watt voeding heb, is dit normaal?
tijdens het booten kom ik makkelijk boven de 300Watt

nu alle ongebruikte disks eruitgehaald en opnieuw gemeten.
dit zijn 8 disks waarvan een 5tal WDGreens zijn.
hierdoor is het idle verbruik gezakt naar 127Watt.

dit is nog steeds 250 euro per jaar (klopt dit?)
dit lijkt me gewoon veel te veel, misschien ook eens booten zonder disks en dan meten?

[ Voor 15% gewijzigd door MikeVM op 13-12-2012 22:38 ]

[ebia]

Verwijderd schreef op donderdag 13 december 2012 @ 02:24:
[...]
Laat meer benchmarks zien! Bijvoorbeeld de ZFSguru pool benchmark, en een iperf benchmark. Bedenk dat als je via het netwerk via Samba simpele kopiëeracties doet, je lokale schijf heel goed de bottleneck kan zijn. Kijk dus ook eens naar de HDD LED op je client PC.

Dank voor de input. Lokale disk op de client kan de bottleneck als het goed is niet zijn (SSD). Gaat in Samba om een grote (4 GB) ISO waarmee ik de kopieeracties uitprobeer. Benchmarks laten het volgende zien:

code:

ZFSguru 0.2.0-beta8 (9.1-004) pool benchmark
Pool            : pool (10.9T, 0% full)
Test size       : 8 GiB
normal read : 988 MB/s
normal write    : 130 MB/s
I/O bandwidth   : 2 GB/s

ZFSguru 0.2.0-beta8 (9.1-004) pool benchmark
Pool            : pool (10.9T, 0% full)
Test size       : 64 GiB
normal read : 277 MB/s
normal write    : 126 MB/s
I/O bandwidth   : 2 GB/s

C:\>iperf -c 10.0.0.15 -i 1 -w 8K
------------------------------------------------------------
Client connecting to 10.0.0.15, TCP port 5001
TCP window size: 8.00 KByte
------------------------------------------------------------
[156] local 10.0.0.7 port 56014 connected with 10.0.0.15 port 5001
[ ID] Interval       Transfer     Bandwidth
[156]  0.0- 1.0 sec  53.7 MBytes   450 Mbits/sec
[156]  1.0- 2.0 sec  53.7 MBytes   450 Mbits/sec
[156]  2.0- 3.0 sec  53.2 MBytes   447 Mbits/sec
[156]  3.0- 4.0 sec  53.4 MBytes   448 Mbits/sec
[156]  4.0- 5.0 sec  53.6 MBytes   450 Mbits/sec
[156]  5.0- 6.0 sec  53.6 MBytes   450 Mbits/sec
[156]  6.0- 7.0 sec  53.3 MBytes   447 Mbits/sec
[156]  7.0- 8.0 sec  52.1 MBytes   437 Mbits/sec
[156]  8.0- 9.0 sec  53.6 MBytes   450 Mbits/sec
[156]  9.0-10.0 sec  53.8 MBytes   451 Mbits/sec
[156]  0.0-10.0 sec   534 MBytes   448 Mbits/sec

C:\>iperf -c 10.0.0.15 -i 1 -w 64K
------------------------------------------------------------
Client connecting to 10.0.0.15, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[156] local 10.0.0.7 port 56009 connected with 10.0.0.15 port 5001
[ ID] Interval       Transfer     Bandwidth
[156]  0.0- 1.0 sec   109 MBytes   912 Mbits/sec
[156]  1.0- 2.0 sec   110 MBytes   926 Mbits/sec
[156]  2.0- 3.0 sec   111 MBytes   929 Mbits/sec
[156]  3.0- 4.0 sec   109 MBytes   914 Mbits/sec
[156]  4.0- 5.0 sec   109 MBytes   914 Mbits/sec
[156]  5.0- 6.0 sec   109 MBytes   911 Mbits/sec
[156]  6.0- 7.0 sec   109 MBytes   914 Mbits/sec
[156]  7.0- 8.0 sec   109 MBytes   914 Mbits/sec
[156]  8.0- 9.0 sec   108 MBytes   910 Mbits/sec
[156]  9.0-10.0 sec   108 MBytes   903 Mbits/sec
[156]  0.0-10.0 sec  1.06 GBytes   914 Mbits/sec

C:\>iperf -c 10.0.0.15 -i 1 -w 128K
------------------------------------------------------------
Client connecting to 10.0.0.15, TCP port 5001
TCP window size:  128 KByte
------------------------------------------------------------
[156] local 10.0.0.7 port 55997 connected with 10.0.0.15 port 5001
[ ID] Interval       Transfer     Bandwidth
[156]  0.0- 1.0 sec   111 MBytes   934 Mbits/sec
[156]  1.0- 2.0 sec   111 MBytes   931 Mbits/sec
[156]  2.0- 3.0 sec   111 MBytes   930 Mbits/sec
[156]  3.0- 4.0 sec   111 MBytes   931 Mbits/sec
[156]  4.0- 5.0 sec   109 MBytes   916 Mbits/sec
[156]  5.0- 6.0 sec   110 MBytes   919 Mbits/sec
[156]  6.0- 7.0 sec   108 MBytes   908 Mbits/sec
[156]  7.0- 8.0 sec   108 MBytes   906 Mbits/sec
[156]  8.0- 9.0 sec   109 MBytes   914 Mbits/sec
[156]  9.0-10.0 sec   108 MBytes   907 Mbits/sec
[156]  0.0-10.0 sec  1.07 GBytes   919 Mbits/sec

Dat 100% CPU is niet direct reden tot zorg aangezien ZFS burst writes doet. Dus de disk activiteit wordt om de zoveel seconden in bursts (transacties) gedaan waarbij gedurende korte tijd de disks (en CPU) volop belast kunnen worden. Dat wil nog niet zeggen dat dit ook je bottleneck is. En zelfs als dat wel zo is, kan dat komen door hoog interrupt usage (kun je zien in top output of via de ZFSguru status output). Hoge interrupts kun je oplossen met een commando als:

ifconfig re0 polling
(vanaf ZFSguru 9.1-004 systeemversie)

Interrupts komen op 20% tijdens file transfer, dus dat lijkt me mee te vallen.

Nog een paar kopieeracties gedaan via SMB:

code:

/tmpfs
84 MB write
71 MB read

/pool/share
46 MB write
69 MB read

/pool/share (na uitvoeren van ifconfig re0 polling)
42 MB write
76 MB read

Zeker de read snelheden zijn stukken beter dan gisteren, erg vreemd want behalve een herinstallatie heb ik niks bijzonders gedaan (geen andere configuratie gebruikt zoals de voorgaande keer).

Toch weet ik nog niet helemaal zeker of ik wel de performance haal die ik zou kunnen. De benchmarks wijzen uit dat mijn disken sneller kunnen, en volgens mij kan ik concluderen dat mijn netwerk ook prima hogere snelheden aankan. De tmpfs wordt al een beetje twijfelachtig, maar haalt nog wel goede schrijfsnelheden. Maar wanneer het er dus echt op neerkomt valt het toch wat tegen.

Volgende stap, waar ik nu ff geen tijd voor heb, is een NFS share mounten op m'n macbook (hangend aan ethernet) en eens kijken wat NFS doet...Ook voor de grap even met SSH geprobeerd, maar daar kwam ik niet verder dan 6 MB per seconde schrijven...

[krijn1985]

Waarschijnlijk zie ik iets over het hoofd maar hoe kan ik een extra user (dus naast ssh) toegang geven via ssh?
Ik had in eerste instantie Allowusers = usernaam toegevoegd aand /etc/ssh/sshd_config, maar daarna leek inloggen met ssh niet meer te werken. Dus die regel heb ik weer weggehaald.
Toen heb ik geprobeerd toegang te krijgen tot ssh door pw usermod username -G ssh te doen. Maar dit leek ook niet te werken.
id username geeft: uid=1001(username) gid=1000(share) groups=1000(share),44(ssh)

Het password wat ik moet gebruiken is toch hetzelfde als bij mijn samba shares? Of klopt deze veronderstelling niet.

Het is waarschijnlijk iets simpels wat ik over het hoofd zie, maar kom er even niet uit.

edit: dit is dus onder zfsguru 0.2.0 -beta8 (freebsd 9.1)

[ Voor 4% gewijzigd door krijn1985 op 14-12-2012 00:55 ]

[Verwijderd]

@ebia: probeer in je /boot/loader.conf of via System->Tuning->Advanced eens de min_pending en max_pending op 1 te zetten, dan te rebooten. Dat zou je ZFS scores moeten verbeteren. Kun je zeggen hoeveel?

@krijn1985: waarom wil je een nieuwe SSH login account? Normaliter log je in via ssh, en dan kan je worden wie je wilt met 'su' ofwel switch user. Meerdere SSH inlog accounts hoeft niet persé te zijn wat je wilt bereiken; maar ik weet ook niet precies wat je doel is. Als je dat echt wilt, is dat:
pw useradd nieuwesshlogin -G wheel
Of je edit het /etc/group bestand en voegt achter wheel een komma en de username toe. Alleen gebruikers lid van de groep wheel mogen namelijk 'root' worden met 'su'. Inloggen via SSH kan met alle gebruikers die een wachtwoord hebben, dus als je enkel wilt inloggen via ssh is dit genoeg:
pw useradd nieuwesshlogin
passwd nieuwesshlogin

Maar nogmaals: ik vraag me af wat je precies wilt bereiken. Je hebt namelijk maar één login account nodig. Hoe meer accounts des te onveiliger in theorie. Passwords van UNIX user accounts zijn absoluut NIET hetzelfde als Samba passwords. Dat zou extreem onveilig zijn. Wees je voorzichtig met wat je doet, dat je niet je server open zet voor jan en alleman? Gebruikersaccounts zonder wachtwoord mag je niet mee inloggen zo is standaard geconfigureerd in de sshd_config. Dat was waarschijnlijk je probleem.

[FireDrunk]

Passwords van UNIX user accounts zijn absoluut NIET hetzelfde als Samba passwords. Dat zou extreem onveilig zijn.

Je bedoeld, ze zijn by default niet hetzelfde. En roepen dat dat persé onveilig is, is ook een beetje overdreven...

Samba heeft gewoon een optie die heet user password sync. Dat zorgt er voor dat als je je UNIX password veranderd, dat je SMB password gewoon mee wijzigt.

Onder veel linux distro's ook gewoon de default volgens mij. En onder Windows, kan het niet eens anders... Dus zeggen dat dat persé onveilig is, is erg overdreven...

Tegenwoordig is PAM integratie de beste optie volgens velen:

http://www.samba.org/samb...HOWTO-Collection/pam.html

[ Voor 10% gewijzigd door FireDrunk op 14-12-2012 10:27 ]

[Verwijderd]

Nouja waar ik bang voor ben is dat als je mounted Samba shares hebt en je ript het wachtwoord of de two-way hash, je dan ook toegang tot het systeem kunt krijgen. Ik weet inderdaad niet hoe de beveiliging van SMB/CIFS werkt, maar in elk geval in het verleden was het een koud kunstje om via een paar files de NT beveiliging en passwords te rippen (l0ftcrack?). Als dat zou betekenen dat je ook gelijk via SSH kan inloggen, zou ik dat geen veilig systeem vinden.

Verder wordt vaak afgeraden om hetzelfde wachtwoord/string in meerdere hashes op te slaan zonder verschillende salt te gebruiken. Maar je hebt wel gelijk dat dergelijke security-zorgen eerder voor serieuze (bedrijfs-)beveiliging van toepassing zijn en véél minder voor thuisgebruikers, waar beveiliging meer bedoeld is om je zusje uit je pr0n-directory te houden.

[krijn1985]

Ik heb dus een extra user aangemaakt voor mijzelf om zo toegang tot de personal share vanmijzelf te verwezenlijken. De nas hangt aan een router waarop huisgenoten ook op wifi zitten. Nu zullen ze niet zo snel een verborgen share vinden, maar kan sowieso geen kwaad om hiervoor een password te gebruiken. Nu wil ik dus met rsync vanaf mijn windows laptop (gebruik hiervoor licielrsync) mijn documenten naar mijn nas kunnen backupen. Nu had ik het getest met rsync en mijn username werkt. Echter nu wil ik dus dat het ook via ssh kan (deels om te testen of dit sneller werkt) vandaar dat ik dus mijn username ssh toegang wilde geven.

Als ik dus via de webgui een user heb aangemaakt met een password is dit dus alleen voor SMB? En bestaat dit account dus niet als zodanig useraccount op mijn NAS als dat ik in ubuntu een SMB account zou aanmaken?

Wanneer het voor mij dus goed werkt, wil ik dus ook mijn ouders een rsync mogelijkheid geven om zo hun bestanden offsite te backuppen naar mij en ik mijn bestanden naar hun. Ik was in de veronderstelling dat SSH + Rsync beter loopt (weet niet precies meer waarom ik dit idee heb). Nu zullen mijn ouders (en broertje) waarschijnlijk wel met openvpn verbinding moeten maken met mijn netwerk alvorens ze bij mijn NAS kunnen.

Misschien moet ik toch eerst testen of ssh nodig is als ze via openvpn op mijn netwerk zitten en of het eventueel sneller werkt dan met alleen rsync. Ik had namelijk in eerste instantie een test gedaan vanaf mijn laptop naar mijn ubuntu desktop met rsync en daarbij ging de transfer van een 100MB file naar mijn gevoel sneller (met ssh dus) dan dat het nu naar mijn NAS ging (zonder ssh)

edit: stel dat ik dus mijn ouders + broertje via ssh toegang wil geven hoeven zij natuurlijk geen root te kunnen worden. Het gebruik van het ssh account is dan natuurlijk niet zo slim. Misschien moet ik toch nog wat meer lezen over ssh, freebsd user accounts en security.

[ Voor 7% gewijzigd door krijn1985 op 14-12-2012 10:42 ]

[Verwijderd]

Rsync heeft ook een eigen protocol, dan loopt het alleen niet over SSH. Aan de ene kant veiliger omdat je dan niet een echt user account weggeeft waar mensen kunnen inloggen op je systeem (en vrij veel kunnen doen ook als normale user). Aan de andere kant onveiliger omdat rsync zelf geen encryptie toepast; via het internet zou dat minder veilig zijn. Dat kun je dan weer oplossen door een VPN tunnel te gebruiken zoals met OpenVPN.

Als je een user account aanmaakt via ZFSguru web-interface, krijg je een echt UNIX account zonder wachtwoord (daarmee kun je NIET inloggen via netwerk en ook niet via shell vanwege '/sbin/nologin' shell). Er wordt wel een Samba-wachtwoord gegeven en het account wordt met Samba (smbpasswd) geactiveerd.

[krijn1985]

Dus ik zou als ik met mijn account ssh wil gebruiken dus passwd username moeten uitvoeren en een password toekennen (makkelijkst is dan eigenlijk zelfde te nemen als SMB).
Ik zou dus voor mijn ouders en broertje beter een rsync user kunnen aanmaken (al vraag ik me af wanneer dan een eventueel password ingevoerd moet worden, aangezien ik bij mijn test gister niet het password nodig had dat ik in rsync.secrets had aangegeven) en ze via Openvpn laten backuppen?

Wanneer openVPN niet gaat lukken is het dus wel verstandig ssh te gebruiken? (dit betekent jammer genoeg wel dat ik idd gelijk mijn NAS toegankelijk maak via internet)

In ieder geval bedankt voor de antwoorden CiPHER.

[Verwijderd]

Als het via internet loopt inderdaad OpenVPN / SSH gebruiken. VPN wil zeggen dat je via het internet een LAN-connectie maakt. Via die lan connectie met een eigen IP (10.6.x.x bijvoorbeeld) kun je dan onbeveiligde applicaties zoals rsync gebruiken, die dan beveiligd worden door OpenVPN.

Voordeel van OpenVPN is dat je een vage poort kunt kiezen (47546 ofzo) waar je op inlogt met je OpenVPN client (Windows, Linux, alle OS) zodat alle belangrijke poorten zoals Samba of SSH of HTTP voor de ZFSguru web-interface niet direct zichtbaar zijn. Je hebt dan dus maar één poortforward nodig en dat is een heel stuk veiliger.

Rsync kan ook werken met authenticatie; zie 'man rsyncd.conf' en kijk naar auth users en secrets file.

[FireDrunk]

Dat kan nog wel makkelijker... Je kan via SSH ook poort-forwarden...
Maar RSYNC via SSH is toch ook prima?

Bovendien kan je ook gewoon de SSH poort veranderen? Of je nou heel OpenVPN installeert (met veel gekloot... TUN/TAP shit enzo...) of even SSH herconfigureert zodat het een andere poort gebruikt...

_{nano /etc/ssh/sshd.conf}

[krijn1985]

Ik had dus inderdaad usernam:test in rsync.secrets file gezet (zo uit mijn hoofd, zit nu niet thuis en op dit moment heeft OpenVPN nog af en toe kuren) en in mijn rsync.conf voor een bepaalde module dus die user toegevoegd (als het goed is). Echter wanneer ik dus connect met username@ip-adres::test werd er helemaal nergens om een username gevraagd.

Ik denk dat ik dus uiteindelijk username niet aan ssh ga toevoegen en dus inderdaad met OpenVPN + rsync users ga werken.

OpenVPN draait op dit moment op mijn router, heeft echter nog wat kuren lijkt het. Waarschijnlijk wordt mijn VPN lan toch niet goed doorgelinkt naar mijn thuis lan.

edit:
@Firedunk: ik heb op dit moment toch al OpenVPN draaien op mijn router (mocht uiteindelijk 3 gebruikers teveel worden kan ik natuurlijk weer switchen naar SSH). Is op dit moment nog TUN omdat Android volgens mij nog geen TAP ondersteunt. Het jammer van TUN is dat het goed routen van verkeer volgens mij bij mij nog niet helemaal goed is gegaan. Soms kom ik wel bij mijn interne netwerk en soms niet, kan ook zijn dat mijn router het gewoon niet aankan.

[ Voor 26% gewijzigd door krijn1985 op 14-12-2012 11:31 ]

[FireDrunk]

Als je DD-WRT hebt kan je toch gewoon PPTP VPN maken? Dan kan je met de native VPN client van Android naar je router connecten.

(maar dat is erg offtopic, dus dat moet ergens anders).

[krijn1985]

Offtopic: @Firedunk: ik heb uiteindelijk voor OpenVPN gekozen omdat zover ik vergelijkings info vond het veiliger is en sneller/beter kan omgaan met hogere latencies.

Maar bedankt voor alle info. Ik ga nu eerst maar eens aan de slag met rsync goed instellen en testen zodat dit lekker werkt. Kan ik daarna mijn persoonlijke data ook naar NAS verhuizen en hiermee gaan syncen inplaats van mijn ubuntu desktop (kan deze ook op standby/uit). Als dat eenmaal goed is ingesteld kan ik snapshots via cronjob gaan instellen.

Nog even een snel vraagje: Ik laat op dit moment maandelijks een scrub uitvoeren (gaat om een raid-z met 3 x 2TB schijven) op dit moment staat er ongeveer 800GB aan data op. Moet ik dit vaker doen? Of juist minder vaak? Ik lees nogal verschillende dingen, de een zegt iedere week (consumer HD's) andere zeggen dat 1 keer in de maand meer dan genoeg is.

[Verwijderd]

Maandelijks een scrub lijkt mij prima. Elke 3 weken zou denk ik een mooie balans zijn. Bedenk verder dat gegevens die je leest (in elk geval op RAID-Z) altijd al gechecked wordt. Dat geldt alleen niet voor mirrors dacht ik.

[FireDrunk]

Verwijderd schreef op vrijdag 14 december 2012 @ 12:19:
Maandelijks een scrub lijkt mij prima. Elke 3 weken zou denk ik een mooie balans zijn. Bedenk verder dat gegevens die je leest (in elk geval op RAID-Z) altijd al gechecked wordt. Dat geldt alleen niet voor mirrors dacht ik.

ZFS Data Integrity
For ZFS, data integrity is achieved by using a (Fletcher-based) checksum or a (SHA-256) hash throughout the file system tree.[35] Each block of data is checksummed and the checksum value is then saved in the pointer to that block—rather than at the actual block itself. Next, the block pointer is checksummed, with the value being saved at its pointer. This checksumming continues all the way up the file system's data hierarchy to the root node, which is also checksummed, thus creating a Merkle tree.[35] When a block is accessed, regardless of whether it is data or meta-data, its checksum is calculated and compared with the stored checksum value of what it "should" be.

De data integrity check staat los van je RAID level. Zelfs op een single disk werkt het gewoon.
Er word eerst gekeken of er nog een kopie van het bestand is (dmv copies=2/3) als die er niet is, probeert hij de mirror en dan de eventuele RAID engine (RAIDZ)

[ Voor 6% gewijzigd door FireDrunk op 14-12-2012 12:44 ]

[Verwijderd]

Checksum ja, maar niet redundancy. Parity wordt volgens mij gecontroleerd als je RAID-Z leest; het zou namelijk geen voordeel hebben zoals RAID5 om deze over te slaan. Maar bij mirrors kan dat niet het geval zijn omdat een mirror bij read I/O voordeel heeft boven een single disk. Dat kan alleen als disk2 andere gegevens inleest dan disk1. Dan kun je niet 'on the fly' de redundancy controleren.

Kortom, als je een mirror draait en je leest een groot bestand, kan het zijn dat corruptie op één van beide disks onopgemerkt blijft, daarvoor moet je een scrub draaien. 50/50 kans zeg maar. Want disk1 leest andere data dan disk2; ze lezen niet dezelfde data. Bij RAID-Z wordt de parity block dan niet overgeslagen, waardoor ZFS deze wel on-the-fly kan controleren. Zou je dus bij RAID-Z familie alle files inlezen, dan zou dat gelijk staan als een scrub.

Ik weet het niet 100% zeker, maar volgens mij klopt bovenstaande wel. Ik kan het trouwens controleren met geom_nop, daarbij kun je kunstmatig read errors of corruptie introduceren. Handig voor testdoeleinden.

[ Voor 7% gewijzigd door Verwijderd op 14-12-2012 12:51 ]

[FireDrunk]

Verwijderd schreef op vrijdag 14 december 2012 @ 12:51:
Checksum ja, maar niet redundancy. Parity wordt volgens mij gecontroleerd als je RAID-Z leest; het zou namelijk geen voordeel hebben zoals RAID5 om deze over te slaan. Maar bij mirrors kan dat niet het geval zijn omdat een mirror bij read I/O voordeel heeft boven een single disk. Dat kan alleen als disk2 andere gegevens inleest dan disk1. Dan kun je niet 'on the fly' de redundancy controleren.

Kortom, als je een mirror draait en je leest een groot bestand, kan het zijn dat corruptie op één van beide disks onopgemerkt blijft, daarvoor moet je een scrub draaien. 50/50 kans zeg maar. Want disk1 leest andere data dan disk2; ze lezen niet dezelfde data. Bij RAID-Z wordt de parity block dan niet overgeslagen, waardoor ZFS deze wel on-the-fly kan controleren. Zou je dus bij RAID-Z familie alle files inlezen, dan zou dat gelijk staan als een scrub.

Ik weet het niet 100% zeker, maar volgens mij klopt bovenstaande wel. Ik kan het trouwens controleren met geom_nop, daarbij kun je kunstmatig read errors of corruptie introduceren. Handig voor testdoeleinden.

Wat je zegt klopt niet. De checksum word namelijk niet realtime berekend, maar zit permanent opgeslagen in het filesystem ( zie het verhaal over de metadata tree). Zodra er dus data van disk 1 gelezen is, word de checksum gevalideerd. Als die niet klopt, dan pas hoeft hij disk 2 aan te spreken.

Je hebt dus wel meer Read IO's, maar zodra er iets fout gaat, moeten beide disks even hetzelfde block lezen.

Je verwart parity met een checksum, een parity is geen checksum, maar een soort par2 filetje..
Checksums zijn Fletcher (of SHA256), en dat is veeeel kleiner (paar Bytes maar).

ZFS is nog beter dan je al dacht
Scrubben is dus eigenlijk alleen maar nodig voor data die je HEEL lang niet aanraakt...

[ Voor 8% gewijzigd door FireDrunk op 14-12-2012 12:57 ]

[Verwijderd]

Maar ik heb het niet over checksums, maar over redundancy. Het heeft met elkaar te maken, maar volgens mij begrijpen we elkaar verkeerd.

Ouderwets RAID5 read met 3 disks
1. lees blok A van disk1
2. lees blok A van disk2
3. parity wordt niet gelezen, in plaats daarvan leest disk3 alvast data van blok B van een volgende I/O request die gequeued is

ZFS RAID-Z read met 3 disks
leest van alle drie de disks, inclusief de parity. RAID-Z kan namelijk niet gebruikt worden om disk3 in de tussentijd wat anders te laten doen, wat bij RAID5 wel kan. Zonder dit te weten ga ik er vanuit dat RAID-Z dus ook de parity leest, en deze valideert. Dit kan ik wel even testen...

Bij mirrors wordt zoals jij zegt pas dezelfde data gelezen als een checksum fout gedetecteerd wordt. Maar standaard dus niet. Zou dezelfde redundante blok op disk2 die wordt overgeslagen dus corruptie bevatten, bljift dit onopgemerkt bij een normale leesopdracht (50/50 kans) terwijl dit wel wordt opgemerkt bij een scrub. In die zin is een scrub bij mirrors dus nuttiger dan alles lezen, terwijl dat bij RAID-Z niet uit zou mogen maken.

CiPHER start zijn server om tests uit te voeren.

[FireDrunk]

Dat verhaal van die ouderwetse RAID5 engine trek ik zelfs in twijfel. Niet alle RAID5 engines doen dat volgens mij. Uit mijn ervaring haal ik even op dat ik nog NOOIT een RAID5 setup heb gezien, die read performance heeft van 3 disks als deze maar uit 3 devices bestaat. Er word namelijk altijd een full-stripe gelezen, omdat de parity niet altijd op een vaste plek staat (die wisselt namelijk per keer van device).

Daarom weet de traditionele RAID5 engine helemaal niet welke data van welke disk de parity IS... Hierdoor moet hij altijd de hele stripe lezen, en de parity wegmieteren.

RAID-Z heeft al die gegevens in metadata volgens mij, en kan daarom juist wél een hogere read performance halen, omdat hij vooruit kan plannen.

Wat jij zegt over mirrors klopt wel, maar de checksum word dus wel gevalideerd, alleen word deze gevalideerd tegen de data van de disk aangehouden van welke de data daadwerkelijk gelezen is.

ZFS kan dus altijd garanderen dat de data die je daadwerkelijk geleverd krijgt, altijd 100% consistent is. En inderdaad, op de disk waarvan NIET gelezen is, kan bit rot zitten. Deze word inderdaad pas gezien bij een scrub.

Preventief scrubben maakt dus eerlijk gezegd niet uit, want zodra je de data leest, kom je de fout toch wel tegen.

[krijn1985]

Ik moet toegeven dat ik de technische kant van het verhaal niet helemaal volg maar heb er toch een vraag/opmerking over:

Preventief scrubben maakt dus eerlijk gezegd niet uit, want zodra je de data leest, kom je de fout toch wel tegen.

Is hierbij dan niet alsnog de kans dat wanneer bepaalde data zeer lange tijd niet is aangeraakt op allebei de disks bit rot is opgetreden? Of denk ik hier nu te simpel over? Of moeten we deze kans als zo klein zien dat deze "verwaarloosbaar" is?

[FireDrunk]

In theorie heb je gelijk, maar inderdaad de kans dat op 2 disks op dezelfde sector ongedetecteerd errors zijn is in mijn ogen erg klein. Dus voor die 100% zekerheid moet je dus inderdaad regelmatig scrubben.

Als je rekent met de officiële UER van een disk (meestal 2^16) krijg je dus bij 2 disks, een kans van 1 op 2^17, en bij drie disks, een kans van 2^18.

Als alle disks 2^18 UER hadden, hadden we nu minder problemen gehad...
Nadeel is dan ook wel, dat deze statistieken nogal eens uit de lucht gegrepen blijken te zijn.

[Verwijderd]

FireDrunk schreef op vrijdag 14 december 2012 @ 13:11:
Dat verhaal van die ouderwetse RAID5 engine trek ik zelfs in twijfel. Niet alle RAID5 engines doen dat volgens mij. Uit mijn ervaring haal ik even op dat ik nog NOOIT een RAID5 setup heb gezien, die read performance heeft van 3 disks als deze maar uit 3 devices bestaat. Er word namelijk altijd een full-stripe gelezen, omdat de parity niet altijd op een vaste plek staat (die wisselt namelijk per keer van device).

Toevallig heb ik geom_raid5 op de pijnbank gelegd voordat ik met ZFS aan de slag ging, en ik weet dat dat daar wel zo werkt. Volgens mij doen veel RAID5 engines dat ook zo.

Dat kun je simpelweg controleren door naar de sequential read te kijken. Als de parity wordt meegelezen, kan deze nooit hoger zijn dan de STR snelheid van N-1 disks. Dus aangenomen dat een disk 100MB/s doet, kan RAID5 met 3 disks ofwel 200MB/s lezen als het parity leest, ofwel max. 300MB/s lezen als het van alle 3 disks exclusief parity leest.

Alleen dat laatste klopt niet helemaal; die 300MB/s haal je namelijk nooit. Waarom? De parity wordt wel keurig overgeslagen en de 'parity disk' (distributed maar je begrijpt wat ik bedoel) leest dus alvast de volgende blok uit, maar dat betekent wel dat het om de zoveel tijd een blok moet overslaan. Dat overslaan betekent dat het mechanische gedeelte niet altijd nuttig gebruikt kan worden. Bij SSDs heb je dat probleem niet.

Hetzelfde probleem komt voor bij mirrors. Theoretisch kun je bij mirrors net zo snel lezen als van RAID0, héél theoretisch dan want als je dit probeert loop je tegen hetzelfde probleem aan: disk2 wil dan een plek overslaan en alvast de volgende blok lezen, maar dat elke keer overslaan zorgt wel dat de disk maar 50% van de tijd effectief data kan lezen van het mechanische medium. Althans bij kleine blok groottes. Pas bij veel grotere blok groottes kan de schijf seeken en haal je bijna dezelfde STR snelheid als een RAID0. ZFS doet dat naar alle waarschijnlijkheid, want RAID1 read komt aardig dicht in de buurt van RAID0.

RAID-Z heeft al die gegevens in metadata volgens mij, en kan daarom juist wél een hogere read performance halen, omdat hij vooruit kan plannen.

Juist RAID-Z kan geen voordeel halen uit de 'parity disk' omdat RAID-Z werkt zoals een RAID3. Elke I/O request wordt uitgesmeerd over alle disks (ex parity) dus je kunt de parity disk wel iets anders laten doen, maar effectief win je daar niets bij. RAID5 wel omdat die de parity disk een eigen I/O request kan laten lezen.

Wat jij zegt over mirrors klopt wel, maar de checksum word dus wel gevalideerd, alleen word deze gevalideerd tegen de data van de disk aangehouden van welke de data daadwerkelijk gelezen is.

ZFS kan dus altijd garanderen dat de data die je daadwerkelijk geleverd krijgt, altijd 100% consistent is. En inderdaad, op de disk waarvan NIET gelezen is, kan bit rot zitten. Deze word inderdaad pas gezien bij een scrub.

Dat was dus exact mijn punt. Bij mirrors is het 50/50 kans dat je on-disk corruptie niet detecteert omdat per blok maar van één bron/disk wordt gelezen, pas als die blok niet overeenkomt met de checksum, wordt de tweede bron/disk aangesproken.

Als mijn theorie hierboven klopt, dan betekent dit dat een volledige read van alle data (bijvoorbeeld met rsync) bij een mirror dus niet gelijk is aan een scrub, terwijl bij een RAID-Z dat wel gelijk is aan een scrub, omdat ook de parity wordt gevalideerd. Dat laatste weet ik niet zeker en hoop ik te kunnen controleren met wat testjes...


Update
Wat betreft dat laatste lijk ik geen gelijk te hebben:

code:

dT: 1.002s  w: 1.000s  filter: gpt
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    0      1      1     32    0.7      0      0    0.0    0.1| gpt/seagate1
    0      1      1     32    0.8      0      0    0.0    0.1| gpt/seagate2
    0      1      1     32    0.6      0      0    0.0    0.1| gpt/seagate3
    0      0      0      0    0.0      0      0    0.0    0.0| gpt/seagate4
    0      2      2     96    4.2      0      0    0.0    0.8| gpt/seagate5

Je ziet hier dat gpt/seagate4 wordt overgeslagen. Seagate5 doet extra werk waarschijnlijk omdat het metadata moet inlezen om de checksum te kunnen valideren. Aangezien de schijf hiervoor moet seeken, duurt dit ook langer (4.2ms versus 0.7ms gemiddeld voor de andere disks).

Als ik gelijk had gehad, zou seagate4 ook meegedaan hebben. Soms zie ik inderdaad alle 5 disks bezig, maar waarschijnlijk omdat de metadata voor die leesactie zich dan op die schijf bevindt.

Mijn voorlopige conclusie is dus dat een scrub altijd nodig is om zeker te zijn dat er geen corruptie aanwezig is op de disks. Simpelweg alle gegevens inlezen met rsync is dus niet voldoende om die maximale zekerheid te krijgen, natuurlijk al wel vrij veel zekerheid; maar niet maximale zekerheid.

[ Voor 15% gewijzigd door Verwijderd op 14-12-2012 13:47 ]

[FireDrunk]

Die conclusie kunnen we inderdaad met zekerheid zeggen, zowel qua theorie, als praktijk. Om 100% zekerheid te hebben over bitrot is een Scrub gewoon vereist.

Wat betreft die performance, ben ik eerlijk gezegd wel heel benieuwd.

Wat nou als je een queue depth van meer dan 1 zou hebben, zou dan inderdaad die seagate4 wel aan het werk gaan, of word die bewust niet meegenomen, omdat die express overslagen word vanwege de parity.

Met andere woorden: Is je VDEV zo slim om vooruit te lezen als het RAIDZ gebruikt, of deelt het de IO alleen in volgorde (soort NCQ) of ook echt op per disk.

[ Voor 15% gewijzigd door FireDrunk op 14-12-2012 13:51 ]

[Verwijderd]

Dat is inderdaad de mogelijkheid. Maar de potentie tot performance-gain is vrijwel afwezig; omdat de overige disks dan op achterstand staan. Om dat uit te testen wordt erg moeilijk... Dan kun je denk ik nog beter naar de ZFS code kijken. Alleen ben ik niet goed genoeg om die te kunnen lezen. Gila misschien wel...

[vso]

- Kan ik met ZFS tiered storage bereiken? dus bv mijn "actieve" data en " passieve data" verplaatsen tussen 2 volumes ?
- Een hoe goed werkt de dedupelicatie van zfs? (block of file?)
- wat is de status van ZOL (kan ik dit ook dus op Linux ipv BSD?)

De reden dat ik dit vraag is dat: ik heb nu x aantal VM's op mijn Hypervisor draaien, als ZFS block deduplicatie doet. kan ik in ieder geval (hopenlijk) 1 of 2 SSD's gebruiken van relatief kleine grote(s)
immers de Virtual disks op van het OS bevat veel overeenkomstige data.

Tiered storage is meer dat mijn "minder actieve" data schijven wat meer naar "idle" toe gaan

[matty___]

dacht dat dedup op block werkt.

[FireDrunk]

@vso, Dedup is idd op block niveau, maar verwacht geen wonderen, het moet aan nogal wat voorwaarden voldoen volgens mij voordat je de resultaten hebt zoals jij ze misschien wil hebben. Er is echt maar 1 tip, lees je GOED in voor je er aan begint. Soms is compressie nog beter dan dedup word wel eens gezegd. Juist omdat dedup een gigantische hoeveelheid geheugen nodig heeft (Enkele gigabytes per terabytes dacht ik gelezen te hebben, en dat zelfs BOVENOP je gewone geheugen...)

ZFS heeft geen Tiered storage zoals jij wil denk ik, daar moet je iets anders voor gebruiken.
ZOL heeft naar mijn weten al die functies.

@CiPHER, ik zit het hier eens te proberen, maar zie als ik netjes 1 DD commando uitvoer, met 128k block size en 1 count (1 stripe dus) 8 van mijn 10 disks actief worden.

Doe ik 2 DD commando's, zie ik AL mijn disks actief worden, tegelijkertijd, en allemaal ongeveer evenveel data afhandelen. Dat is natuurlijk geen bewijs, omdat er in 1 seconde van iostat -v / zpool iostat cumulatief alles gewoon bij elkaar opgeteld word.

Als je mij op de exacte sourceode wijst, kan ik het misschien wel lezen. (Ik kan C wel lezen, en C++ begrijp ik prima.)

Edit:

/*
33 * Checksum vectors.
34 *
35 * In the SPA, everything is checksummed. We support checksum vectors
36 * for three distinct reasons:
37 *
38 * 1. Different kinds of data need different levels of protection.
39 * For SPA metadata, we always want a very strong checksum.
40 * For user data, we let users make the trade-off between speed
41 * and checksum strength.
42 *
43 * 2. Cryptographic hash and MAC algorithms are an area of active research.
44 * It is likely that in future hash functions will be at least as strong
45 * as current best-of-breed, and may be substantially faster as well.
46 * We want the ability to take advantage of these new hashes as soon as
47 * they become available.
48 *
49 * 3. If someone develops hardware that can compute a strong hash quickly,
50 * we want the ability to take advantage of that hardware.
51 *
52 * Of course, we don't want a checksum upgrade to invalidate existing
53 * data, so we store the checksum *function* in eight bits of the bp.
54 * This gives us room for up to 256 different checksum functions.
55 *
56 * When writing a block, we always checksum it with the latest-and-greatest
57 * checksum function of the appropriate strength. When reading a block,
58 * we compare the expected checksum against the actual checksum, which we
59 * compute via the checksum function specified by BP_GET_CHECKSUM(bp).
60 */

Uh, wacht... Dit betekend dus, dat als je zelf de checksum op iets anders zet, die hardwarematig via je CPU gedaan kan worden. De CPU belasting dus met SPRONGEN omlaag gaat

Uh, waaorm is dat nog niet zo met de nieuwe i5's met hun hardwarematige AES?

[ Voor 44% gewijzigd door FireDrunk op 14-12-2012 14:44 ]

[enormhi]

FireDrunk schreef op vrijdag 14 december 2012 @ 14:32:
@vso, Dedup is idd op block niveau, maar verwacht geen wonderen, het moet aan nogal wat voorwaarden voldoen volgens mij voordat je de resultaten hebt zoals jij ze misschien wil hebben. Er is echt maar 1 tip, lees je GOED in voor je er aan begint. Soms is compressie nog beter dan dedup word wel eens gezegd. Juist omdat dedup een gigantische hoeveelheid geheugen nodig heeft (Enkele gigabytes per terabytes dacht ik gelezen te hebben, en dat zelfs BOVENOP je gewone geheugen...)

Dedup vraagt inderdaad een hoop geheugen. Echter lopen de getallen een beetje uiteen. De een zegt 5GB per TB data en de andere zegt 1GB. Het is in ieder geval zo dat je een hoop nodig hebt.

[matty___]

beetje dit format:
http://www.zfsbuild.com/2...specs-and-parts-pictures/

[vso]

FireDrunk schreef op vrijdag 14 december 2012 @ 14:32:
@vso, Dedup is idd op block niveau, maar verwacht geen wonderen, het moet aan nogal wat voorwaarden voldoen volgens mij voordat je de resultaten hebt zoals jij ze misschien wil hebben. Er is echt maar 1 tip, lees je GOED in voor je er aan begint. Soms is compressie nog beter dan dedup word wel eens gezegd. Juist omdat dedup een gigantische hoeveelheid geheugen nodig heeft (Enkele gigabytes per terabytes dacht ik gelezen te hebben, en dat zelfs BOVENOP je gewone geheugen...)

ZFS heeft geen Tiered storage zoals jij wil denk ik, daar moet je iets anders voor gebruiken.
ZOL heeft naar mijn weten al die functies.

Het gaat me vooral om "virtual OS" disks . totaal praten we over ongeveer 500GB "real data" 6 a 7 VM's deduped hoop ik dat dit minder als 80gb deduped is .. de rest van de data volume(s) zou ik het nieteens activeren .. maar ja stel dat 1 OS disk 60Gb is .. moet ik het volume waar dedupe actief is .. 200GB groot maken en "word dat" wanneer mogelijk dedupe(d) .. of tijdens het op de volume copieren gaat ZFS al kijken of het dubbel is?

ZFS heeft caching, wat eigenlijk veiliger is dan een tiered storage (omdat de data ook op de Storage bliijft) .. maar hoe beheersbaar is deze cache .. ? hoe weet ik dat als ik hiervoor 32 of 64GB voor alloceer dat het ook daadwerkelijk benut word?


O en hoe is de samenwerking tussen HDD powerdown en ZFS (oftewel is ZFS energie zuinig(er) of juist niet ?

[FireDrunk]

500GB -> 80GB gaat je niet lukken, ik heb ergens verhalen gelezen dat je best-case-scenario iets van 50% verkleining mag verwachten.

Dedup werkt achteraf, dus je maakt een volume van 200GB aan, je schrijft de eerste VM er op, en zodra je de tweede VM er bij zet, gaat ZFS periodiek kijken of er blokken hetzelfde zijn, en deze naar elkaar referencen. Dit het Reclaimen. Je ziet dus heel langzaam de reclaimed bytes teller oplopen. Dat is je 'winst'.

[enormhi]

Zijn er niet twee versies van deduplication? Post-process zoals FireDrunk hem omschrijft, maar er is toch ook inline deduplication ("realtime")?

[u_nix_we_all]

AFAIK is de-dup inline bij ZFS. Dat reclaimen is nieuw voor mij.
Ik heb hier wat Nexenta documentatie waarin expliciet gemeld wordt: Only applies to newly written data.

Houdt wel rekening met RAM-gebruik voor de DDT (DeDupTable), dat kan nog aardig oplopen.

Edit: 270 bytes per referenced block, om precies te zijn.

[ Voor 10% gewijzigd door u_nix_we_all op 14-12-2012 16:17 ]

[enormhi]

Dat dacht ik ook inderdaad.

Hier nog even een stuk over deduplication (correct me if I'm wrong) uit mijn documentatie van ZFS.

• Voor optimale performance wil je de DDT (DeDupTable) opslaan in RAM.
• Hoe groter de DDT hoe langzamer write performance. (Tenzij opgeslagen in RAM)
• Elke ‘entry’ in DDT is ongeveer 320 Bytes aan memory per block.
• DDT grootte afhankelijk van block size. Block size afhankelijk van soort data (kleine of grootte files).
o ZFS gebruikt een variabele block size tussen 512 bytes en 128K, afhankelijk van bestandsgrootte.
• ZFS blocks berekenen: Raad het gemiddelde block size. Deel vervolgens de verwachte storage capaciteit door gemiddelde block size.
o In de meeste gevallen van mixed data, zoals user home directories, kun je uitgaan van 64K block size.
o 5TB aan opgeslagen data met gemiddelde block size van 64K:
 5TB gedeeld door 64K blocks = 78125000 blocks.
 78125000 * 320 bytes = 25GB DDT grootte.
• ZFS moet ook andere data in RAM opslaan, ARC (metadata en cached block data).
o Limiet van ZFS ARC cache voor metadata (waaronder de DDT) is ¼ van RAM.
o Wil je de totale DDT in RAM opslaan dan moet je dus 4× zoveel RAM hebben. (Voor het bovenstaande voorbeeld dus 100GB voor de DDT tabel).
o Voor andere metadata (zoals block pointers en caching data) is ook nog RAM nodig.
• RAM “Rules of thumb:”
o Voor elke TB aan data 5GB aan DDT data. (64K block size).
o Dit komt ongeveer uit op 20GB aan RAM per TB pool data + extra voor andere metadata + OS/applicatie RAM.

[FireDrunk]

Ik roep wel reclaimed, maar ik ben in de war met compression...

Compression ratio	2.50 (31.50GiB reclaimed)

Op 1 van mijn backup volumes Dit is een filesystem waar elk uur een file op gezet word met de inhoud van mijn ontwikkel webserver.

Toch een aardig ratio

[ Voor 3% gewijzigd door FireDrunk op 14-12-2012 16:27 ]

[vso]

FireDrunk schreef op vrijdag 14 december 2012 @ 15:19:
500GB -> 80GB gaat je niet lukken, ik heb ergens verhalen gelezen dat je best-case-scenario iets van 50% verkleining mag verwachten.

Dedup werkt achteraf, dus je maakt een volume van 200GB aan, je schrijft de eerste VM er op, en zodra je de tweede VM er bij zet, gaat ZFS periodiek kijken of er blokken hetzelfde zijn, en deze naar elkaar referencen. Dit het Reclaimen. Je ziet dus heel langzaam de reclaimed bytes teller oplopen. Dat is je 'winst'.

Thx Reclaimen, nu ja ligt eraan hoe "specifiek" ik dat kan instellen (ik ga er nu uit per volume) ..
op "folder" niveau is ideaal want ik dan kan ik doelgericht dedupen.

Overgens dan is de 500 naar 80GB wel mogelijk .. block is file onafhankelijk,
- stel ik maak 6 Virtual disks aan van 60GB = 320GB totaal.
* reclaimed = 1 a 2 MB (immers bevat geen data)
- windows install met alle updates =20 GB (clonend naar alle Disks)
* reclaimed is 24GB (de 4GB is eigenlijk de verschillen per Disk)


De best case scenario waar je naar refereert is gebasseerd op totale data + diverse "aannamens".
- mijn bulk data is bijvoorbeeld 3 TB, deduplicatie hierop als het effect heeft is 10% at best .. de meeste winst ga ik halen op dit gebied is bv " periodieke compare utillities voor foto's en andere data maar voornamelijk zelf door mijn data te baggeren.. houd ik deze data "deduplicated" .. hieraan een paar GB geheugen aan "verspillen is dom".
- bedrijfsleven is ander verhaal, winst ligt daar hoger op Fileservers omdat mensen graag "fysiek" het bestand ergens willen plaatsen en delen .. ipv linkjes te sturen naar het bestand. Daarom heeft deduplicatie vaan 20% to 40% winst .. en scheelt snel Gigabytes. Daar wil je juist alles op 1 san en (user/groep/share data)

Meest deduplicatie data is dus OS / software denk BV aan citrix servers die ISCSI booten vanaf een SAN.
die ISCSI luns (of virtual Disks) zijn vaak identiek (of behoren te zijn) en daar is je winst 95% of hoger..
zeker als je alle "temp" data logging/caching data naar een seperate disk kan trappen.
Reken maar eens uit een OS disk is ongeveer 60 tot 80 GB, je hebt 40 servers .. de echte data op disk is 30 tot 40GB, er zit geen "user" data op de disk (profiel, of user shares) 40x40gb = 1.600 GB deduped zou dit 40GB (1x 1 OS Disk) + delta(unieke data) (39x1GB= 80GB zelfs als je 10% (4gb) unieke delta per disk berekend kom je op 156GB + 40gb = 206 GB.

Hier moet je echter wel een "ruime overhead" in mee nemen dus ipv 10% unieke delta = 25% tot 50% wel handig .. dit puur omdat groei/krimp verhaal te faciliteren .. en wat is het verschil kwa kosten van hiervan ?

Combineer dit met een Tiered storage (kortweg hoe vaker "accessed" des te meer hoort het op een sneller medium) Tiering is meer dat als je "deduplicatie" volume ook min of meer kan groeien/krimpen zonder ten koste te gaan van je SSD volumes ..

In dit geval kan je best 206 GB deduplicated hebben, maar Tiered staat 40% misschien op SSD en 60% op HDD (ZFS zou het dus in je cache moeten belanden) ..In theorie.

[FireDrunk]

In theorie kan je inderdaad alles wat jij zegt met deduplication, maar ik heb juist real-world stats gezien, en daar bleek juist uit, dat het helemaal nog niet zo makkelijk is om die waardes te halen...

http://christopher-techni...rformance-real-world.html

Hier laat iemand bijvoorbeeld zien, dat 1.25x Dedup ratio, hem 20x performance kost.

[ Voor 31% gewijzigd door FireDrunk op 14-12-2012 16:40 ]

[vso]

FireDrunk schreef op vrijdag 14 december 2012 @ 16:34:
In theorie kan je inderdaad alles wat jij zegt met deduplication, maar ik heb juist real-world stats gezien, en daar bleek juist uit, dat het helemaal nog niet zo makkelijk is om die waardes te halen...
http://christopher-techni...rformance-real-world.html
Hier laat iemand bijvoorbeeld zien, dat 1.25x Dedup ratio, hem 20x performance kost.

Zo te lezen heeft tie niet echt slim aangepakt .. dus ook niet zo verwondelijk dat die performance hit heeft.
Deplicatie wil je doen op vrij statische data, die niet veel wijzigt .. dus OS + applicatie installatie minus de caching/temp data (tenzij het cached updates zijn) .. is het deduplicatie waardig .. moment dat je het ook activiveerd voor data wat je zelf weet dat "uniek is" ben je IMHO niet slim bezig. (wat deze gast dus wel doet blijkbaar) ..

[u_nix_we_all]

vso schreef op vrijdag 14 december 2012 @ 16:50:
[...]

Zo te lezen heeft tie niet echt slim aangepakt .. dus ook niet zo verwondelijk dat die performance hit heeft.
Deplicatie wil je doen op vrij statische data, die niet veel wijzigt .. dus OS + applicatie installatie minus de caching/temp data (tenzij het cached updates zijn) .. is het deduplicatie waardig .. moment dat je het ook activiveerd voor data wat je zelf weet dat "uniek is" ben je IMHO niet slim bezig. (wat deze gast dus wel doet blijkbaar) ..

Niet alleen zijn DDT , maar ook 4x120GB L2ARC die zijn tables in ram bijhoudt, en dan klagen dat het niet performt met 24 GB RAM
Met zo'n systeem (25 TB opslag, 4 L2ARC en 2 ZIL SSD's) zou ik eens beginnen met 48GB, en dan kan dat nog best krap zijn.

[FireDrunk]

Zo zie je maar. Het kan wel, maar denk er goed over na. Eerlijk gezegd denk ik dat het in the end goedkoper is om meerdere systemen te bouwen dan om 1 heel dik systeem te maken met dedup...

[u_nix_we_all]

FireDrunk schreef op vrijdag 14 december 2012 @ 17:58:
Zo zie je maar. Het kan wel, maar denk er goed over na. Eerlijk gezegd denk ik dat het in the end goedkoper is om meerdere systemen te bouwen dan om 1 heel dik systeem te maken met dedup...

Dedup gaat per zpool, dus je zou meerdere zpools kunnen maken, en alleen dedup gebruiken waar dat nut heeft. Maar het performanceprobleem van die gast lijkt me eigenlijk meer veroorzaakt door te weinig geheugen voor zoveel L2ARC en dat vertraagt dan de dedup-lookups

[u_nix_we_all]

Oh shit. Ik wil hier een mirror van 2x2TB upgraden naar een mirror van 2x3TB disks..... 1 van die 2TB disks is brak, en heb ik uit de mirror gehaald (detach). Die is brak en wegens wat gekloot moest die al resilveren, en dat schiet niet op.
Dus een pool van een enkele 2 TB disk.
Toen wilde ik een 3TB erbij zetten als mirror, en die heb ik geadd, ipv attach
Nu heb ik dus een 5TB raid0, en die 3 TB kan ik er niet zomaar weer afhalen.

Ah well, de data staat er nog op. Nu maar een nieuwe pool aanmaken op de ander 3TB disk, en kopieren. Dan kan de 5TB gedestroyed en ik de 3TB mirroren. En dan wel met attach anders ben ik echt screwed

[analog_]

u_nix_we_all schreef op vrijdag 14 december 2012 @ 20:14:
Oh shit. Ik wil hier een mirror van 2x2TB upgraden naar een mirror van 2x3TB disks..... 1 van die 2TB disks is brak, en heb ik uit de mirror gehaald (detach). Die is brak en wegens wat gekloot moest die al resilveren, en dat schiet niet op.
Dus een pool van een enkele 2 TB disk.
Toen wilde ik een 3TB erbij zetten als mirror, en die heb ik geadd, ipv attach
Nu heb ik dus een 5TB raid0, en die 3 TB kan ik er niet zomaar weer afhalen.

Ah well, de data staat er nog op. Nu maar een nieuwe pool aanmaken op de ander 3TB disk, en kopieren. Dan kan de 5TB gedestroyed en ik de 3TB mirroren. En dan wel met attach anders ben ik echt screwed

Ik ken de miserie waarbij je fout na fout maakt. Ik denk dat zodra je met cruciale data bezig bent, dat je voor dat je iets onderneemt telkens een paar minuten moet nadenken over wat de gevolgen zijn (of dat je toekomstige opties hierdoor al uitsluit). Vaak overloop ik dan met een collega/vriend de situatie en de fix, pas als er zeker geen alternatief is voeren we wat uit.

[u_nix_we_all]

analog_ schreef op vrijdag 14 december 2012 @ 20:17:
[...]

Ik ken de miserie waarbij je fout na fout maakt. Ik denk dat zodra je met cruciale data bezig bent, dat je voor dat je iets onderneemt telkens een paar minuten moet nadenken over wat de gevolgen zijn (of dat je toekomstige opties hierdoor al uitsluit). Vaak overloop ik dan met een collega/vriend de situatie en de fix, pas als er zeker geen alternatief is voeren we wat uit.

Tja, in mijn werk ben ik ook erg van stappenplan uitwerken op testomgeving, opties evalueren, rollback scenario's etc.

Maar dit is mijn eigen NAS-je Och, ff disken vervangen, doe ik wel ff

[Borromini]

u_nix_we_all schreef op vrijdag 14 december 2012 @ 20:14:
Oh shit. Ik wil hier een mirror van 2x2TB upgraden naar een mirror van 2x3TB disks..... 1 van die 2TB disks is brak, en heb ik uit de mirror gehaald (detach). Die is brak en wegens wat gekloot moest die al resilveren, en dat schiet niet op.
Dus een pool van een enkele 2 TB disk.
Toen wilde ik een 3TB erbij zetten als mirror, en die heb ik geadd, ipv attach
Nu heb ik dus een 5TB raid0, en die 3 TB kan ik er niet zomaar weer afhalen.

Ah well, de data staat er nog op. Nu maar een nieuwe pool aanmaken op de ander 3TB disk, en kopieren. Dan kan de 5TB gedestroyed en ik de 3TB mirroren. En dan wel met attach anders ben ik echt screwed

Heb hetzelfde aan de hand gehad, ik vind dat er echt wel een meldinkje zou mogen komen van 'are you sure you wouldn't rather attach the device instead of adding it' ofzo. Ook wat tijd mee kwijtgespeeld hier

[sloth]

Ik maak gebruik van ZFSguru 0.2-beta8 LiveCD op een usbstick. Zover ik begrijp is deze niet voor embedded gebruik bedoeld, waardoor de levensduur voor flash geheugen een probleem kan vormen.

Hoe lang houdt een standaard 4 GB usb stick het uit vooraleer deze stuk is? Ik kwam dit topic tegen met uitleg over hoe je writes kan verminderen, maar dit ziet er zowel gedateerd als erg complex uit.

[ Voor 5% gewijzigd door sloth op 14-12-2012 22:17 ]

[u_nix_we_all]

Oh, en over de performance-drop met een (te) vol zfs:
Kopieren van data gaat met ca 85 MB/s , behalve de laatst toegevoegde dingen, daar dropt het naar 15 MB/s
Dat stond voor 90% vol (toen ik die 3TB disk nog niet toegevoegd had )

Dus wacht niet te lang met disken toevoegen als het volloopt

[Ultraman]

u_nix_we_all schreef op vrijdag 14 december 2012 @ 20:14:
Oh shit. Ik wil hier een mirror van 2x2TB upgraden naar een mirror van 2x3TB disks..... 1 van die 2TB disks is brak, en heb ik uit de mirror gehaald (detach). Die is brak en wegens wat gekloot moest die al resilveren, en dat schiet niet op.
Dus een pool van een enkele 2 TB disk.
Toen wilde ik een 3TB erbij zetten als mirror, en die heb ik geadd, ipv attach

Ik schrijf meestal eerst mijn stappenplannetje uit alvorens ik dit soort "cruciale" dingen ga doen.
En vaak schrijf ik de commando's ook gewoon uit en zet ze onder elkaar.

Soms ga ik zelfs nog een stap verder.
Zo heb ik hier een migratie van single 2TB (50% vol) -> 1.5T+1.5T(=3T) bijna geheel met een gescript gedaan. De data oorspronkelijk naar een disk van 2TB gebackupped, en ik had al 3 x 1.5TB in bezit.
Twee losse scriptjes, de eerste maakte de nieuwe pool op twee 1.5TB schijven (striped), kopieerde de data en draaide een scrub.
Tijdens het scrubben heb ik met de hand nog even wat directories nagelopen.
Het tweede script sloopte de 2T pool, zero fillde de 2TB disk, maakte de nodige partities aan op de 2TB en overgebleven 1.5TB disks, voegde ze toe als mirrors van de verschillende 1.5TBers. Waarna ZFS lekker ging resilveren.

Dat eerste script heeft gedraaid terwijl ik bij kennis was, maar na het starten van het tweede script ben ik lekker naar bed gegaan en de volgende morgen was het hele zaakje klaar.
Je moet het jezelf zo makkelijk en comfortabel mogelijk maken natuurlijk

[ebia]

Verwijderd schreef op vrijdag 14 december 2012 @ 07:06:
@ebia: probeer in je /boot/loader.conf of via System->Tuning->Advanced eens de min_pending en max_pending op 1 te zetten, dan te rebooten. Dat zou je ZFS scores moeten verbeteren. Kun je zeggen hoeveel?

Heb deze settings aangepast, maar mocht niks baten.

Ik heb nog even iSCSI geprobeerd en NFS. De performance van beiden is wel iets hoger, maar niet echt veel (paar MB hooguit).

Misschien zijn dit gewoon de meest degelijke scores die ik kan halen met het systeem? Of spreekt jouw gevoel dat tegen? Ik gebruik een Asus C60M1-L bordje.

(Ik zie wel bij SMART errors op één disk de cable error op 3 staan, de dagen ervoor stond die nog op 2).

[ Voor 7% gewijzigd door ebia op 15-12-2012 11:25 ]

[sloth]

Ik haal met mijn C60 ongeveer 55MB/s read vanaf een pricewatch: Western Digital Green WD20EARS, 2TB. Schrijven gaat met 60MB/s. Beide resultaten via CIFS en de laatste ZFSguru beta.

Je moet voor de grap eens testen met CIFS in windows. Met een kale W7 install haal ik 100MB/s tussen de C60 en een andere PC met windows 7 op.
Mogelijke oorzaken:
-De C60 CPU heeft zgn. "Turbo Core technology" die een tijdelijke verhoging van de kloksnelheid naar 1,33Ghz mogelijk maak. FreeBSD kan hier mogelijk niet mee overweg, terwijl uit mijn tests blijkt dat in windows hij wel schakelt naar 1,33Ghz
-Er zijn grote optimalisaties voor het SMB protocol in Windows waardoor de snelheid op low end hardware veel hoger is
-De driverondersteuning is veel beter in Windows, waardoor de hardware efficiënter kan werken tov FreeBSD.

Wat je verder nog kan proberen en wat hier hogere waardes geeft:

-Heb je polling ingeschakelt voor de onboard nic? Dit kan je doen door ifconfig re0 polling in een terminal te doen. Als je nogmaals ifconfig invoert zou je polling tussen de beschikbare options moeten zien.
-Cool & Quiet en C6 in je bios uitzetten.

[Xudonax]

Ik heb al een stuk terug gelezen, maar ik kan niets vergelijkbaars vinden. Ik kom namelijk iets "vreemds" tegen als ik ZFS on Linux gebruik in combinatie met 4 Sandisk Cruzer Fit USB sticks van 8GByte. Ja, ik weet het, dit levert niets op aan prestaties maar het voldoet om te testen. Ik wacht nog op de echte disks en controller.

Wat ik tegen kwam is dat als ik een 512MiB bestand naar mijn ZFS pool met compressie schrijf (dd if=/dev/zero of=test.bin bs=8M count=64) de bestanden slechts 512 byte zijn. Dat dit komt door de compressie lijkt me niet meer dan logisch, maar de compressratio is hiervoor 1.00x, onafhankelijk van de compressie. Dit terwijl de compressratio voor mijn gevoel minstens 1048567.00x (1M) zou moeten zijn. En volgens mij is dit niet de manier om sparse files te maken, want dat doe je AFAIK door enkel aan het einde van het bestand te schrijven...

Kan iemand dit verklaren?

[FireDrunk]

Probeer eens het sync commando uit te voeren.

[Xudonax]

Hmm, dat is hier wel nodig ja... Nu staan ze er wél volledig op. Vreemd, toen ik een patroon van 0x00 0xFF schreef vanuit een programma verscheen het wel meteen op de schijven. Blijft alleen nog over dat de compressratio op 1.00x blijft staan.

code:

$ ls -hal
total 3.5K
drwxrwxrwt 2 root    root       3 Dec 15 15:50 .
drwxrwxrwt 7 root    root       7 Dec 15 14:48 ..
-rw-rw-r-- 1 patrick patrick 512M Dec 15 15:50 test.bin

$ sudo zfs get compressratio usbtank/lzjb
[sudo] password for patrick: 
NAME          PROPERTY       VALUE  SOURCE
usbtank/lzjb  compressratio  1.00x  -[

$

[FireDrunk]

Is compressie niet reclaim naderhand?

[ Voor 25% gewijzigd door FireDrunk op 15-12-2012 15:59 ]

[Xudonax]

Dat heb ik niet gemerkt met de rest... En dit is enkel met een hele zooi 0 bytes, met mijn andere testpatroon (0x00 0xFF) waren de compressratio wel meteen zichtbaar...

[Verwijderd]

zfs create usbtank/newfilesystem
zfs set compression=lzjb usbtank/newfilesystem
dd if=/dev/zero of=/usrtank/newfilesystem/zerofile.000 bs=1M count=100
sync
zfs get compressratio usbtank/newfilesystem

Doe dat eens

[Xudonax]

Helaas:

code:

patrick@mediasystem:/usbtank/lzjb
$ sudo zfs create usbtank/newfilesystem
[sudo] password for patrick: 
patrick@mediasystem:/usbtank/lzjb
$ sudo zfs set compression=lzjb usbtank/newfilesystem
patrick@mediasystem:/usbtank/lzjb
$ sudo dd if=/dev/zero of=/usbtank/newfilesystem/zerofile.000 bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0211658 s, 5.0 GB/s
patrick@mediasystem:/usbtank/lzjb
$ sudo sync
patrick@mediasystem:/usbtank/lzjb
$ sudo zfs get compressratio usbtank/newfilesystem
NAME                   PROPERTY       VALUE  SOURCE
usbtank/newfilesystem  compressratio  1.00x  -
patrick@mediasystem:/usbtank/newfilesystem
$ sudo du zerofile.000 
1   zerofile.000

Ik begin toch te denken dat dit misschien een bugje in ZFS on Linux is

[ Voor 5% gewijzigd door Xudonax op 15-12-2012 17:08 ]

[MikeVM]

MikeVM schreef op donderdag 13 december 2012 @ 21:11:
[...]

het verbruik is 177Watt idle, zonder enige besparingsmaatregelen, de spindown van de HDD's in ubuntu staan nog altijd op de standaard instellingen..

dit is met 13 disks, en 1 SSD

Q6600
p5q
8GB Ram DDR2
GT210 videokaart (wat zou dit verbruiken?)

het maximum verbruik is bijna 600 Watt, terwijl ik maar een 300 Watt voeding heb, is dit normaal?
tijdens het booten kom ik makkelijk boven de 300Watt

nu alle ongebruikte disks eruitgehaald en opnieuw gemeten.
dit zijn 8 disks waarvan een 5tal WDGreens zijn.
hierdoor is het idle verbruik gezakt naar 127Watt.

dit is nog steeds 250 euro per jaar (klopt dit?)
dit lijkt me gewoon veel te veel, misschien ook eens booten zonder disks en dan meten?

met 13 disks: 177Watt
met 8 disks : 127Watt
(5x2TB; 3x3TB) >>> ( 5WDGreens + 3 Samsungs)
zonder disks (enkel bootSSD: 95 Watt

best wel opmerkelijke cijfers.. 5oude disks verbruiken 50 Watt
8 nieuw disks verbruiken 30 Watt

dus ik kan iedereen aanraden om zo weinig mogelijk disks te draaien van zo groot mogelijke capaciteit..

[analog_]

Kleine aanpassing voor topic start over Nexenta, want dat klopt nu absoluut niet.
Nexenta
Nexenta is een OpenSolaris derivaat met IllumOS kernel (de huidige open ontwikkeling vanuit OpenSolaris) met een ubuntu userland waardoor het voor debian en ubuntu gebruikers allemaal vertrouwd overkomt. OpenIndiana is de directe competitie welke traditioneel op ZFS vlak beter presteerd.
NexentaStor
Het bedrijf achter Nexenta heeft een NAS/SAN product gebouwd op basis van Nexenta, NexentaStor. Deze komt met een gebruiksvriendelijke webinterface (die groene ). Er is een gratis versie beschikbaar (na registratie) waarbij je maximaal 18TB netto kan gebruiken en SAN plugins mist zoals :HA, syncronisatie met CDP, VMware integratie, ...

De betaalde variant is vooral interessant voor de iets grotere MKB/KMO waar er gebruik wordt gemaakt van bijvoorbeeld SBC, clusters. De plugins zijn goed geprijsd in vergelijking met de meeste SAN alternatieven echter te duur om de competitie aan te gaan met syncronised local storage oplossingen (Veeam, Hyper-V, VMware VSA), die je vaak al bezit vanwege backup of kleine failover omgeving licenties.

Ik ben momenteel ook bezig met het opstellen van hardware advies volgens drie profielen, een ideetje dat volgens mij al eens in het topic heeft gestaan. Volg mee en geef input.

[ Voor 36% gewijzigd door analog_ op 15-12-2012 20:37 ]

[Durandal]

Xudonax schreef op zaterdag 15 december 2012 @ 17:08:
Helaas:

code:

patrick@mediasystem:/usbtank/lzjb
$ sudo zfs create usbtank/newfilesystem
[sudo] password for patrick: 
patrick@mediasystem:/usbtank/lzjb
$ sudo zfs set compression=lzjb usbtank/newfilesystem
patrick@mediasystem:/usbtank/lzjb
$ sudo dd if=/dev/zero of=/usbtank/newfilesystem/zerofile.000 bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0211658 s, 5.0 GB/s
patrick@mediasystem:/usbtank/lzjb
$ sudo sync
patrick@mediasystem:/usbtank/lzjb
$ sudo zfs get compressratio usbtank/newfilesystem
NAME                   PROPERTY       VALUE  SOURCE
usbtank/newfilesystem  compressratio  1.00x  -
patrick@mediasystem:/usbtank/newfilesystem
$ sudo du zerofile.000 
1   zerofile.000

Ik begin toch te denken dat dit misschien een bugje in ZFS on Linux is

Edit: Bijna goed. Het blijkt een feature te zijn

Compression ratio is incorrect when writing file with 0x00 bytes

[ Voor 3% gewijzigd door Durandal op 15-12-2012 22:42 ]

[Xudonax]

Dat is een issue welke ik dus aangemaakt had En op zich is het heel geen verkeerd gedrag van ZFS, maar je moet het maar net weten

[Durandal]

Zo goed had ik dus ook weer niet opgelet... Effe uitkijken met nul-data dus, maar goed om te weten.

[Xudonax]

Zo leer je nog eens wat

[ebia]

sloth schreef op zaterdag 15 december 2012 @ 11:59:
Ik haal met mijn C60 ongeveer 55MB/s read vanaf een pricewatch: Western Digital Green WD20EARS, 2TB. Schrijven gaat met 60MB/s. Beide resultaten via CIFS en de laatste ZFSguru beta.

Ok, zo gek zijn mijn resultaten met SMB dan toch weer niet. Weet ik in ieder geval waar ik ongeveer vanuit mag gaan.

Wel heb ik nog eens NFS getest van m'n ESXi host... daar haal ik slechts een bedroevende 6 MB/s bij seq. schrijven, met seq. lezen tik ik daar wel de 60 MB/sec aan. Heel raar die lage schrijf snelheden, heb het zowel als ik met de datastore browser in vSphere gewoon wat ISO's overgooi, maar ook in een VM met twee disken gemount (één lokaal en dus één via NFS op de NAS).

Polling maakt helaas niet veel uit. Ik zal later nog eens dat cool 'n quiet uitzetten.

[fluppie007]

Probeer ik een Rsync tutorial te volgen (http://arjanwooning.nl/ee...e-rsync-internet-met-ssh/). Blijkt ssh-copy-id niet te werken onder FreeBSD.
Moet ik nu manueel dat filetje op de andere server krijgen? Of bestaat er een FreeBSD interpretatie van dit commando?

[Meauses]

Ik heb de laatste tijd met een schijf in mijn raidz pool wat problemen. FreeNAS 8.0.4 geeft aan dat er een current pending sector is. Normaliter zou ZFS hier goed mee omgaan, maar in dit geval lijkt dat niet zo.

Daarom zit ik er aan te denken de schijf te vervangen. Ik heb op dit moment 3x2TB Samsung F4's.
Als ik die ene schijf wil vervangen voor een andere 2TB, waar moet ik dan opletten? De Samsungs zijn nu namelijk een stuk duurder dan een ander merk schijven. En wil uiteindelijk de schijf die overblijft in gaan zetten als backup zodat ik daarna mijn raidz1 pool om kan zetten naar een raidz2 met 6 schijven. Voor meer veiligheid en meer opslagruimte.

[Verwijderd]

Schijf vervangen voor één pending sector? Dat moet je dus gewoon niet doen. Wat zijn de problemen waar je tegenaan loopt? Of enkel dat je een pending sector hebt? Op wat voor controller zijn je schijven aangesloten? Heten je schijven 'ada' qua device name?

Ik denk namelijk dat er helemaal niets aan de hand is. Als je geen 'een' bad sector hebt, die niet weggaat na een scrub van je pool, dan bevindt deze bad sector zich in een gebied waar ZFS nog geen data heeft opgeslagen. ZFS zal deze sector automatisch overschrijven zodra het die ruimte in gebruik gaat nemen, en dan is het 'probleem' automatisch opgelost en verdwijnt die bad sector.

Bij systemen die ik gebouwd heb is dit een veelvoorkomend verschijnsel. Waarschijnlijk omdat de schijven aan background surface scanning doen en dus onleesbare sectoren detecteren op plekken waar al geruime tijd niets is geschreven. Dan is het niet zo vreemd dat deze onleesbaar wordt.

Schijf vervangen zal lastig zijn; je zult hem namelijk moeten vervangen met een andere type schijf; de Samsung F4EG is niet meer leverbaar enkel de Seagate versie die gewoon flink verschillend is. Ik zou dat niet doen, tenzij je wel moet. Post je SMART data eens van de 'probleemschijf' en geef eens een goede probleembeschrijving.

[FireDrunk]

Hmm, ik kwam erachter dat je bestaande data kan laten analyseren door het commando:

zdb -s [poolnaam]

Deze doet dan een analyze over de geschatten hoeveelheid winst met deduplication. Met dit getal kan je dus uitrekenen hoeveel geheugen je nodig zou hebben om het daadwerkelijk te doen.

Helaas voor mij:

[root@NAS /home/ssh]# zdb -S bigpool
Killed: 9

Heb ik met 16GB geheugen, zelfs te weinig om de analyse te doen
Iemand nog op zoek naar ECC geheugen? Ik wil liever 32GB geheugen, dan ECC

[ Voor 9% gewijzigd door FireDrunk op 16-12-2012 13:33 ]

[Ultraman]

fluppie007 schreef op zondag 16 december 2012 @ 04:09:
Probeer ik een Rsync tutorial te volgen (http://arjanwooning.nl/ee...e-rsync-internet-met-ssh/). Blijkt ssh-copy-id niet te werken onder FreeBSD.
Moet ik nu manueel dat filetje op de andere server krijgen? Of bestaat er een FreeBSD interpretatie van dit commando?

Gewoon de SSH key even met de hand toevoegen aan de authorized_hosts (en optioneel de key toevoegen aan jouw ssh-agent)?
Is weinig FreeBSD specifiek aan, noch bestaat out-of-the-box dat commando op alle Linux distributies.
Heeft ook weinig met ZFS te maken verder.

[ Voor 11% gewijzigd door Ultraman op 16-12-2012 13:27 ]

[u_nix_we_all]

FireDrunk schreef op zondag 16 december 2012 @ 11:32:
Hmm, ik kwam erachter dat je bestaande data kan laten analyseren door het commando:

zdb -s [poolnaam]

Deze doet dan een analyze over de geschatten hoeveelheid winst met deduplication. Met dit getal kan je dus uitrekenen hoeveel geheugen je nodig zou hebben om het daadwerkelijk te doen.

Helaas voor mij:

[root@NAS /home/ssh]# zdb -S bigpool
Killed: 9

http://www.c0t0d0s0.org/a...-ZFS-Dedup-Internals.html
Heb ik met 16GB geheugen, zelfs te weinig om de analyse te doen
Iemand nog op zoek naar ECC geheugen? Ik wil liever 32GB geheugen, dan ECC

Ik vond dit stukje wel een goed overzicht geven van wat dedup doet.

Ik weet niet of bij dat scannen ook een tijdelijk soort DDT opgebouwd wordt, En dan loop je al snel tegen de cap van metadata in arc aan, standaard 25% van je max-arc ....

Edit... Doh, die link postte je al, overheen gelezen..... maar precies dat dus

[ Voor 3% gewijzigd door u_nix_we_all op 16-12-2012 13:55 ]

[ebia]

vso schreef op zondag 16 december 2012 @ 15:50:
[...]
De 8 windows VM's krijgen 50 tot 100GB OS-disk storage toegewezen oftewel 800GB dit zou dan 1 tank worden met dedupe geactiveerd zijn. ik verwacht een de compressie 100GB als uiteindelijk resultaat heeft. Er van uitgaande dat 1 windows OS 30 tot 50GB is.

Dit houd wel in dat ik op VM niveau alle "unieke data zoveel mogelijk naar een andere virtual disk mik zoals bv user profiles/swap, temp, en sommige cache (browser) maar niet bv windows update(s) of antivirus updates)

Gaat dat wel werken? ZFS kan immers niet in je VMDK kijken, en dus zien waar de duplicate data staat. En op block-niveau lijkt het me al helemaal lastig...

[ Voor 70% gewijzigd door ebia op 16-12-2012 16:00 ]

[vso]

u_nix_we_all schreef op zondag 16 december 2012 @ 13:51:
Ik vond dit stukje wel een goed overzicht geven van wat dedup doet.

Ik weet niet of bij dat scannen ook een tijdelijk soort DDT opgebouwd wordt, En dan loop je al snel tegen de cap van metadata in arc aan, standaard 25% van je max-arc ....

Edit... Doh, die link postte je al, overheen gelezen..... maar precies dat dus

zeer intressant !! ook de ZFS -S "check" ..of dedupe zin heeft.


Waar ik aan zit te denken is volgende setup: 4x3TB(mag ook 4TB) in raid 10, 2x SSD a 64GB of 128GB
Ram 4GB (max) (24GB ram in totaal 20GB voor VM)

De SSD's worden ingezet als "cache/zil/log" dus eigenlijk niet voor "storage" de ruimte die ik nodig heb is "max" 5 a 6 TB de rest van de space mag van mij als "niet bruikbaar" gemarkeerd worden .. oftewel ik ga voor een ouderwetse raid10 setup,
De 8 windows VM's krijgen 50 tot 100GB OS-disk storage toegewezen oftewel 800GB dit zou dan 1 tank worden met dedupe geactiveerd zijn. ik verwacht een de compressie 100GB als uiteindelijk resultaat heeft. Er van uitgaande dat 1 windows OS 30 tot 50GB is.
Dit houd wel in dat ik op VM niveau alle "unieke data zoveel mogelijk naar een andere virtual disk mik zoals bv user profiles/swap, temp, en sommige cache (browser) maar niet bv windows update(s) of antivirus updates)
De overige 5,2 TB is pure "storage" tank zonder deduplicatie, Compressie heeft ook weinig zin omdat de winst ik niet "terug" zie in de VM laag.
niet geheel onbelangrijk, waar laat ik de Linux/BSD distro ? ik hoop dat ik dit op de 5.2 TB ZFS kan parkeren. (iets wat met ZOL wellicht lastig word)

Echte "storage" heb ik maar 3 a 4 TB op dit moment in gebruik, 50GB is wat echt nodig heb (en dus online backup) 50GB extra is "handige extra data" de rest is gewoon "fun to have" dus ik heb aardig wat schuif ruimte.

Betreft RAM vermoed ik gewoon dat 4GB gewoon te weinig is, hoewel ik makkelijk 8GB of 10GB voor ZFS zou kunnen alloceren. Liever krap inschalen, doe ik ook met mijn VM's zodat ik veel "speel" ruimte heb.

Het hoofdoel is Performance winst, Xen op freebsd als Domain 0 (host) + vga,usb,sound had de insteek van ZFS + Xen, Kort verteld: Xen + ZFS(freebsd) was een NoGo .. ZOL was & ben ik nog niet erg happig op. gezien de development op dat gebied. En FreeBSD het gebrek aan xen ondersteuning. Mijn grootse "probleem" is dat ik graag zonder al te veel moeite "rescue" operatie kan uitvoeren als door mijn getweak de Xen laag uitgaat. En niet 20 hoepels en een pinguin moet offeren voordat ik verder kan.

offtopic:
De uitdaging van mijn setup is dat ik 2x ATI grafische kaarten, passthrough naar de VM en bijbehorende randapparatuur (usb ramplank,muis en sound) Xen was op dat moment het enige Hypervisor product die dat kon.

Nu draai ik met 8 disks (2 voor OS) en 6 in raid5 setup .. en ik moet zeggen de performance is zeer acceptabel, alleen sneller is uiterraard beter

kwa hardware is het een Intel mobo, i7 980 (6core@3.3ghz) 24 gb ram (wellicht een upgrade?? max is geloof ik 64gb 1 van de weinige mobo's waarvan de fabrikant die spec's meegeeft) de sata controller is 3Gbp/s wat IMHO meer dan zat is. gezien dat IRL ik hooguit 1% dit nodig heb (of 10% van de tijd dat hij 24/7 aanstaat)

Goed ik zit dus al een tijd tegen een major rebuild aan te hikken, wat is jullie advies na dit hele verhaal?

[ Voor 0% gewijzigd door vso op 16-12-2012 15:50 . Reden: quote verduidelijkd ]

[vso]

ebia schreef op zondag 16 december 2012 @ 15:29:
[...]


Ondertussen heb ik nog wat meer ingelezen, en zie ik zo nu en dan mensen op de forums met identieke problemen. Zou mogelijk iets met een nieuwe NFS implementatie te hebben in FreeBSD 9, anderen beweren weer dat het te maken heeft met de manier waarop ESXi omgaat met NFS (iets sync ofzo). (Dat terwijl NFS van m'n macbook ook niet echt vlot gaat).

Ga nu even beginnen vanaf scratch met ZFSguru in ieder geval. Even alle disken wipen, en daarna verse installatie zonder poespas. Als het dan nog niet lukt weet ik het ook even niet meer. Heb weinig behoefte aan een tussenlaag als iSCSI...

Misschien dan maar m'n workstation voorzien van een M1015, en m'n NAS-kastje als een DAS aansluiten op m'n WS. Geen ZFS meer dan, dat is wel weer jammer.

ESX en NFS is altijd nog problematisch geweest, ISCSI is de betere weg om te gaan daar zitten echt performance verschillen tussen. NFS vs ISCSI maakt kwa setup ook geen meter uit. Iscsi heeft als voordeel dat je een Disk/raid volume gewoon "raw" kan aanbieden. ipv /media/disk-vhd-server.img (van 4gb oid)

Vergeet btw ook niet dat je netwerk componenten van NAS en "server" en zeer marginaal je switch ook invloed hebben. Ik heb zeer veel gelazer gehad met QNAP TS410 omdat de marvel chip die erin zat gewoon niet genoeg throughput kon leveren die zat aan zijn "max" (op 6MB/s) Smallnetbuilder reviewed NAS systemen en je doet er wellicht wijs aan om eens te checken waar jou "limiet" zit met je NAS dan kan je achterhalen of het inderdaad een "config probleem is"
Zo kwam ik erachter dat ik eigenlijk al tegen mijn limiet aan zat te hikken.

Wat ZFS zo lastig maakt is dat je (naar mijn beleving) zoveel dingen moet "weten" en van te voren een goed plan moet opzetten. On the fly je installatie en draaien kan zeer brakke resulaten opleveren.

Misschien dat mijn eigen "natte vinger werk' zo van .. hele disk allocaten ipv de kleinste disk te pakken, "beschikbare ruimte" delen door 4k (sectorsize oid) dus 954.232.435B / 4 = 238558108,75 en dus 238558108 * 4 = 954.232.432 op alle 4 de disks te gebruiken .. dat dit enorme impact (20 tot 50%?) heeft gehad op mijn performance Inplaats van 1 to 5% die ik verwachte ?

Daarnaast had ik het geduld ook niet om bv 1 a 2 weken te wachten totdat een cache opgebouwd is..

offtopic:
wist je dat je IPv4 MTU size (default 1500) ook nog leuke impact heeft, en dat bij IPv6 dit tot gigabytes kan gaan? .. oftewel overgaan indien mogelijk IPv6 wellicht ook nog een winst kan opleveren .. (theoretisch?)

in ieder geval je MTU gelijk trekken op (managed switch) en de systemen wel handig is

[FireDrunk]

Over je offtopic verhaal, dat is toch gewoon Jumbo Frames? Vrij bekend verhaal?

[vso]

FireDrunk schreef op zondag 16 december 2012 @ 16:41:
Over je offtopic verhaal, dat is toch gewoon Jumbo Frames? Vrij bekend verhaal?

deels, Jumbo-frames is waar het "bekend" van is echter als je NFS/ISCSI praat dan heeft de default MTU size ook invloed. Zie het beetje als het bitrot verhaal.. alleen als je er heftig "gebruik" van maakt merk je het ..
Jumbo frames overgens vraag ik me af of het echt "nut" heeft net zoals TLER gezien dat je met veel "als dit dan " te maken hebt. Terwijl default MTU zeker wel nut heeft omdat netwerk breed gelijk te zetten zeker als je interne netwerk veel IO heeft.

Jumboframes is niks anders als je MTU van 1500 naar 7xxx tot 9000 te zetten (ligt aan de kaart die niet hoger kan dan ?, net zoals raid setup .. de kleinste disk "regeert")

[ Voor 11% gewijzigd door vso op 16-12-2012 17:02 ]

[FireDrunk]

Uh, de default MTU van heel IPv4 is toch 1500 op lokale netwerken? (Soms wat meer/minder vanwege vendors die headers wel meerekenen, en anderen die het niet doen, maar in principe zit dat hooguit op 1450-1505).

[ebia]

vso schreef op zondag 16 december 2012 @ 16:18:
[...]
ESX en NFS is altijd nog problematisch geweest, ISCSI is de betere weg om te gaan daar zitten echt performance verschillen tussen. NFS vs ISCSI maakt kwa setup ook geen meter uit. Iscsi heeft als voordeel dat je een Disk/raid volume gewoon "raw" kan aanbieden. ipv /media/disk-vhd-server.img (van 4gb oid)

Mijn grootste bezwaar tegen iSCSI is dat je weer afhankelijk bent van een ander FS en dat je daarmee dus portabiliteit kwijtraakt. Ik wil gewoon gemakkelijk bij al m'n files kunnen, of dit nu vanuit m'n Windows bak is, vanaf m'n ESXi VM's of vanuit lokale VM's op m'n Windows bak. Of het nu gaat om Windows of Unix clients, met een SMB of NFS kun je dat makkelijk voor elkaar krijgen.

Als je met iSCSI gaat werken krijg je (in geval van ZFS) een file system bovenop een ander file system (wat ZFS in zekere zin ook is). Daarnaast kan het gedonder op leveren je iSCSI target te mounten op meerdere platforms, denk aan een NTFS partitie op een Linux doos en het gedoe wat daarmee gepaard gaat als read-only en bestandsrechten die niet kloppen.

Tot slot is iSCSI niet 'eerlijk' richting Windows over file transfers. Terwijl Windows zegt "klaar" staat het ding nog volop in de achtergrond te kopieren. Dat kan weer zorgen voor fouten, die ik juist zo graag wil tegengaan.

Vergeet btw ook niet dat je netwerk componenten van NAS en "server" en zeer marginaal je switch ook invloed hebben. Ik heb zeer veel gelazer gehad met QNAP TS410 omdat de marvel chip die erin zat gewoon niet genoeg throughput kon leveren die zat aan zijn "max" (op 6MB/s) Smallnetbuilder reviewed NAS systemen en je doet er wellicht wijs aan om eens te checken waar jou "limiet" zit met je NAS dan kan je achterhalen of het inderdaad een "config probleem is"
Zo kwam ik erachter dat ik eigenlijk al tegen mijn limiet aan zat te hikken.

Mijn netwerk is vrij plat om het zomaar te zeggen. Zowel mijn WS als de NAS hangen aan de gigabit switch van mijn Netgear router. Zoals ik al een tijdje terug poste haal ik prima snelheden met iPerf en ook tussen andere clients onderling (die overigens nu allemaal uitstaan voor zover dat nog impact had kunnen hebben).

Ik wilde maar eigenlijk één ding bereiken, en dat was gewoon die gigabit lijn vol kunnen leegtrekken. Meer niet, en dat leek met prima kunnen met een RAID, veel geheugen en een dual core procje. Maar blijkbaar is de realiteit toch iets anders.

Tot overmaat van ramp geeft mijn WS nu trouwens crashes (3 binnen een uur), moet nog even kijken wat het probleem is (waarschijnlijk SSD bootdisk stuk). Gelukkig staat m'n data (ondanks dat ik dus nog ZFS niet werkende heb) veilig, maar vervelend is het wel. Eerst al m'n aandacht nu daarop, daarna weer op de NAS.

[FireDrunk]

Juist om die reden gebruik ik geen iSCSI, je kan niet meer zomaar bij je files, en bent compleet afhankelijk van VMFS / iSCSI.

Met NFS kan ik mooi snapshots maken, die mounten in ZFSguru, en de backups gewoon als files tussen snapshot en datastore kopieren.

En dat iSCSI echt veel sneller is dan NFS valt ook wel mee. Het scheelt marginaal een paar procent op je netwerk traffic, maar meer ook niet. NFS is file-based en iSCSI is block based, beide hebben voor en nadelen.

[analog_]

ebia schreef op zondag 16 december 2012 @ 17:10:
[...]

Tot slot is iSCSI niet 'eerlijk' richting Windows over file transfers. Terwijl Windows zegt "klaar" staat het ding nog volop in de achtergrond te kopieren. Dat kan weer zorgen voor fouten, die ik juist zo graag wil tegengaan.

[...]

Dat kan je oplossen door de drive cache van je iscsi volume af te zetten (systeem eigenschappen, ik denk performantie tab van je volume). Over jumbo frames is het allang bekend daar volledig voordeel aan te hebben dat natuurlijk heel je netwerk stack het moet ondersteunen (of tenminste alles tussen je start- en end-point). Als een switch op 1500 ingesteld staat zal hij zelf een 9000 frame in 6 kleinere opdelen, dit is immers een standaard mechanisme op layer 2.

Dat IPv6 sneller is dan IPv4 is ook al academisch papers bewezen met name voor kleinere pakketten vanwege de kleinere TCP header (dan IPv4) en daardoor dus ook de relatief grotere impact op pakketten met een kleine payload. Ging de IPv6 MTU niet tot 64k?

[vso]

ebia schreef op zondag 16 december 2012 @ 17:10:
[...]

Mijn grootste bezwaar tegen iSCSI is dat je weer afhankelijk bent van een ander FS en dat je daarmee dus portabiliteit kwijtraakt. Ik wil gewoon gemakkelijk bij al m'n files kunnen, of dit nu vanuit m'n Windows bak is, vanaf m'n ESXi VM's of vanuit lokale VM's op m'n Windows bak. Of het nu gaat om Windows of Unix clients, met een SMB of NFS kun je dat makkelijk voor elkaar krijgen.

Tja we vergelijken redelijk appels met peren ISCSI is "disk" terwijl NFS al op File niveau is.
Dat gezegd te hebben alle tests/ervaring die ik heb vind ik ISCSI beter "portable" dan NFS ligt er ook aan waar je bestanden vanaf vandaan bied. Samba/NFS/Win file server

Dit lijkt me een wellus / nietus waarvan beide gelijk/ongelijk hebben.

Als je met iSCSI gaat werken krijg je (in geval van ZFS) een file system bovenop een ander file system (wat ZFS in zekere zin ook is). Daarnaast kan het gedonder op leveren je iSCSI target te mounten op meerdere platforms, denk aan een NTFS partitie op een Linux doos en het gedoe wat daarmee gepaard gaat als read-only en bestandsrechten die niet kloppen.

Dit heeft meer met je Filesystem te maken ext4/ntfs en vmfs, waarbij vmfs als enige clusteraware is.(onder windows een quorem disk geloof ik) per definitie is het niet handig ISCSI te mounten op meerdere systemen. dat is weer het voordeel van een Fileserver (zoals NFS)

Tot slot is iSCSI niet 'eerlijk' richting Windows over file transfers. Terwijl Windows zegt "klaar" staat het ding nog volop in de achtergrond te kopieren. Dat kan weer zorgen voor fouten, die ik juist zo graag wil tegengaan.

zoals analog_ aangeeft inderdaad dat "vinkje" aan/uit .. overgens die fouten heb je alleen met een power out en dus een UPS verhelpt dat (of dat vinkje )

Ik wilde maar eigenlijk één ding bereiken, en dat was gewoon die gigabit lijn vol kunnen leegtrekken. Meer niet, en dat leek met prima kunnen met een RAID, veel geheugen en een dual core procje. Maar blijkbaar is de realiteit toch iets anders.

Dat dacht ik dus ook en kwam tot de zelfde conclusie .. voornamelijk ligt het in het end-to-end verhaal. Mijn conclusie is voor perfomance veel tweaken (vallen en opstaan) of een kant en klare nas oplossing.

Dankzij chiper werd me duidelijk dat theorie en praktijk aardig wat leeswerk/testen (en dus veel $$$ kost)
maar goed we komen er wel

Suc6 met je WS

FireDrunk schreef op zondag 16 december 2012 @ 17:04:
Uh, de default MTU van heel IPv4 is toch 1500 op lokale netwerken? (Soms wat meer/minder vanwege vendors die headers wel meerekenen, en anderen die het niet doen, maar in principe zit dat hooguit op 1450-1505).

zoiets geloof ik wel ja .. zo jammer dat de standaard niet "de standaard" is ..

[Durandal]

vso schreef op zondag 16 december 2012 @ 15:50:
niet geheel onbelangrijk, waar laat ik de Linux/BSD distro ? ik hoop dat ik dit op de 5.2 TB ZFS kan parkeren. (iets wat met ZOL wellicht lastig word)

ZOL kan booten van een ZFS pool.

[ Voor 17% gewijzigd door Durandal op 17-12-2012 21:15 ]

[vso]

Durandal schreef op maandag 17 december 2012 @ 21:14:
[...]

ZOL kan booten van een ZFS pool.

thx

[ebia]

Heb nog eens goed nagedacht over de performance issues die ik heb, en heb besloten dat ik eigenlijk FreeBSD vanaf scratch wil installeren en dus zelf mijn ZFS pools wil gaan beheren, alsmede alle software die erop staat, etc.

Wie hebben dat nog meer gedaan, en wie kan me wat vertellen over zijn ervaringen, tips, etc?

[Borromini]

Ik ben van ZFSGuru naar Debian GNU/kFreeBSD (nog altijd native ZFS) naar Debian GNU/Linux met de ZFS on Linux (LLNS) code gegaan. De pools kan je in principe exporteren en importeren. Ze worden ook automatisch aangekoppeld in Debian (al dien je bij GNU/Linux wel te zorgen dat de ZFS service wordt gestart tijdens het opstarten). Het beheer op zich is redelijk rechttoe-rechtaan - zpool status zal je in principe de nodige info geven, en geeft ook de commando's die je dient uit te voeren om bv. je pool of een schijf terug online te brengen of te vervangen. Alleen het zpool add/attach verhaal is tricky (ben ik zelf ook ingestonken).

Heb ook scriptje geschreven dat tweewekelijks draait, een scrub uitvoert op m'n pools en daarna checkt of er fouten vastgesteld werden, en zoja, een mailtje stuurt voor de pool die fouten vertoont.

[ Voor 13% gewijzigd door Borromini op 18-12-2012 00:43 ]

[onox]

Borromini schreef op dinsdag 18 december 2012 @ 00:42:
Heb ook scriptje geschreven dat tweewekelijks draait, een scrub uitvoert op m'n pools en daarna checkt of er fouten vastgesteld werden, en zoja, een mailtje stuurt voor de pool die fouten vertoont.

Op FreeBSD kan je dat makkelijk doen door in /etc/periodic.conf te zetten:

daily_scrub_zfs_jepoolnaam_threshold=14
daily_scrub_zfs_pools="jepoolnaam"
daily_scrub_zfs_enable="YES"

Eventueel kan je ook nog toevoegen:

daily_status_zfs_enable="YES"

[Zorc]

Borromini schreef op dinsdag 18 december 2012 @ 00:42:
Ik ben van ZFSGuru naar Debian GNU/kFreeBSD (nog altijd native ZFS) naar Debian GNU/Linux met de ZFS on Linux (LLNS) code gegaan.

Wat was voor jou de reden om naar ZFS onder Linux te gaan? Ik wil binnenkort ook over naar een ZFS (mirror) oplossing voor mijn belangrijkste data. Tot op heden vertrouw ik dat toe aan raid1 (linux), uiteraard met aanvullende backups.
De ZFS FUSE port heb ik nooit als goede oplossing gezien maar ik kijk inmiddels ook al een tijdje met een schuin oog naar de ZFS kernel module. Ik twijfel echter nog of ik daar mijn data al aan wil toevertrouwen.
FreeBSD heb ik geen ervaring mee maar lijkt momenteel toch een betere keus voor ZFS. Van de andere kant biedt Linux voor mij het voordeel van een vertrouwde omgeving...

Ik zou ook nog kunnen kijken naar Solaris11, echter ik begreep dat Oracle nu geen sourcecode van nieuwe aanpassingen aan ZFS vrij geeft (of dat dat nog niet zeker is) en dat die dus uit de pas gaan lopen met de huidige v28 versie van ZFS?

ZFSGuru sprak mij in eerste instantie wel aan om mee te beginnen echter toen ik wat meer ging rondneuzen op de website kreeg ik zo mijn twijfels over de toekomst, nauwelijks documentatie, embedded installatie schijnt al tijden "stuk" te zijn, en de nodige posts over inactieve/verdwenen leaddevelopper etc en er is geen downloadable source met de optie om de images volledig zelf te builden. Om die redenen neig ik nu meer naar NAS4Free. Helaas zit daar voor zover ik zie een wat meer gestripte FreeBSD als basis onder en is het minder gefocussed op ZFS alleen.
Misschien toch maar een 'normale' FreeBSD install overwegen of onder linux experimenteren, dilemma's dillema's

[syl765]

@ebia

Wij gebruiken bare metal FreeBSD voor onze NAS oplossingen.
Die GUI's zijn allemaal leuk, maar er is niks zo fijn om gewoon met een terminal je server te kunnen beheren. Ik heb dan toch een beter gevoel de boel onder controle te hebben omdat ik weet wat ik doe. Met een GUI moet je eigenlijk maar weer afwachten of het vinkje dat je zet ook daadwerkelijk doet wat je wilt.

ESXi in combinatie met FreeBSD, ZFS en NFS is een no go.
Performance is gewoon niet goed te krijgen.

6 MB is een beetje de max.
Je moet voor de grap maar eens een iso of virtuele machine van je ESXi host naar de store zenden.
Dan halverwege het volgende commando geven
# zfs set sync=disabled jou/zfs/dataset

Dan opeens heb je performance die bijna gelijk is aan ISCSI.
Echter is de kans op data corruptie zeer groot aanwezig.
Dit is dus geen optie.

Wil je FreeBSD met ZFS gebruiken voor je ESXi hosts, dan zul je de machines toch op een ISCSI target moeten zetten.

Ik ben het helemaal met je eens dat ISCSI je behoorlijk kan beperken.
Ook ik vond het fijn om direct de data te kunnen manipuleren zonder gebruik te hoeven maken van de ESXi tools.
Echter is NFS en ESXi geen gelukkige combiantie op FreeBSD.
Wij gebruiken ISCSI voor de ESXi hosts, de rest doen we met samba.
Alle platte data staat dus op de NAS en word gedeeld door samba.

Zodra NFS zonder een disabled sync werkt met FreeBSD en ZFS dan stappen we direct terug.

Ik weet eigenlijk niet of openindiana of nexenta ook last heeft van de combinatie NFS en ESXi.
Wij hebben er voor gekozen gewoon bij FreeBSD te blijven. Dit omdat we gewoon heel erg veel kunnen met FreeBSD en ISCSI ondanks de nadelen het verders prima doet.

@Zorc
Gelukkig heb ik dat distro hoppen al heel lang achter mij gelaten
In de tijd van RedHat Suse enz konden we maar geen goede distro vinden die alles deed wat we wilden.
Na vele distro's te hebben geprobeerd zijn we op een gegeven moment bij FreeBSD gekomen, en we hebben toen besloten dit te gebruiken.
Tot nu toe hebben we er nog alles mee kunnen doen wat we gepland hadden.
Probeer gewoon FreeBSD 9.1 (komt elk moment uit als het goed is) met ZFS.
Leer het systeem, en je hoeft niet echt meer op zoek naar alternatieven.

gr
Johan

[ Voor 13% gewijzigd door syl765 op 18-12-2012 09:38 ]

[FireDrunk]

Met een ZIL/SLOG heb je daar allemaal geen last van... Ik haalde gewoon >60MB/s op NFS op ZFS.

[Borromini]

Zorc schreef op dinsdag 18 december 2012 @ 09:19:
[...]


Wat was voor jou de reden om naar ZFS onder Linux te gaan? Ik wil binnenkort ook over naar een ZFS (mirror) oplossing voor mijn belangrijkste data.

Een gigantische PEBKAC eigenlijk Ik dacht dat eS-ATA niet werkte onder FreeBSD, tot ik dus GNU/Linux opnieuw installeerde... En daar werkte het evenmin op. Terwijl ik wist dat het perfect werkte op dezelfde setup met Arch Linux. Dus ben ik toch maar in het BIOS gaan kijken (ding draait headless dus was weer gerommel). En jawel... Ik had hotplugging capabilities voor de eS-ATA-poort uitgeschakeld >_>.

Waarschijnlijk werkte het dus wel netjes onder FreeBSD, maar ondertussen is het kwaad al geschied. Daarnaast kon ik niet direct een equivalent voor hdparm vinden, en powersaving op FreeBSD lijkt ook geen hot topic (maar ik kan me natuurlijk vergissen - ik ken 0,0 van *BSD). Ik ben een stuk vertrouwder met Linux en de hacks die ik op dat platform ken zorgen ervoor dat mijn server toch best zuinig draait.

Ik heb lang getwijfeld om überhaupt naar ZFS te migreren gewoon omdat er erg veel tijd in zou kruipen, en BSD zou nog een extra leercurve geweest zijn. Debian is ook nieuw voor me maar een stuk makkelijker in gebruik (en functioneler out of the box) dan Arch, moet ik zeggen.

Tot op heden vertrouw ik dat toe aan raid1 (linux), uiteraard met aanvullende backups.
De ZFS FUSE port heb ik nooit als goede oplossing gezien maar ik kijk inmiddels ook al een tijdje met een schuin oog naar de ZFS kernel module. Ik twijfel echter nog of ik daar mijn data al aan wil toevertrouwen.
FreeBSD heb ik geen ervaring mee maar lijkt momenteel toch een betere keus voor ZFS. Van de andere kant biedt Linux voor mij het voordeel van een vertrouwde omgeving...

Zelfde dilemma hier. Ik gebruik de laatste RC van ZFS on Linux en mijn grootste vrees was prestaties - maar dat zit wel snor, ik haal 100 MBps bij een scrub of een resilver, en dat komt aardig in de buurt van het maximum van mijn 5400 RPM schijven denk ik. Qua stabiliteit heb ik ook geen klachten.

FreeBSD is ongetwijfeld een goede keuze, ik heb zelf als compromis voor Debian GNU/kFreeBSD gekozen. Zeker interessant, aangezien het GNU userland is met dan de FreeBSD-kernel (en dus native ZFS) en extra's die nodig zijn om die kernel te laten draaien (geen GNU libc bv.).

Mijn gebruiksscenario (twee pools met elk eS-ATA disk als mirror) werkt in ieder geval netjes. ZFS zet de schijven niet automatisch op 'offline' heb ik de indruk als ik ze verwijder, maar dat kan ook manueel gebeuren. Ik ben nog geen fouten tegengekomen met de ZFS-implementatie (wel al checksum errors bij de bestanden ).

ZFSGuru sprak mij in eerste instantie wel aan om mee te beginnen echter toen ik wat meer ging rondneuzen op de website kreeg ik zo mijn twijfels over de toekomst, nauwelijks documentatie, embedded installatie schijnt al tijden "stuk" te zijn, en de nodige posts over inactieve/verdwenen leaddevelopper etc en er is geen downloadable source met de optie om de images volledig zelf te builden.

Cipher heeft de ontwikkeling overgenomen en is erg responsief, dus daar is niks mis mee imho. Het is wel zo dat als je buiten de lijntjes wil kleuren een custom setup interessanter is volgens mij (ik had bv. rtorrent als torrent client, ZFSGuru biedt Transmission aan, en ik word niet vrolijk van die client jammer genoeg).

Ik zou Debian GNU/kFreeBSD testen als compromis . Draait stabiel.

[syl765]

@ firedunk
Wij kregen de performance ook met een ZIL/LOG device niet boven de 10MB.
Wat gebruik jij voor de ZIL/LOG en hoe ziet dat er uit in de pool?

gr
Johan

[FireDrunk]

Ik heb 2 SSD's gebruikt om mijn pool te versnellen. Ik heb een 10*2TB RAIDZ2 Pool.
Eerste SSD was een Intel Postville G2, maar omdat deze ook als L2ARC werd gebruikt, werd de sequentiele doorvoersnelheid gebottlenecked tot 70MB/s (maximale write speed van de SSD).

Later heb ik een Samsung 830 gepakt, en daarmee trok ik gewoon de gigabit lijn dicht.

[syl765]

Jij hebt dus een L2ARC en een ZIL?
Rare vraag misschien maar mag ik de output zien van jou zpool status ?

gr
Johan

[matty___]

FireDrunk schreef op dinsdag 18 december 2012 @ 09:50:
Ik heb 2 SSD's gebruikt om mijn pool te versnellen. Ik heb een 10*2TB RAIDZ2 Pool.
Eerste SSD was een Intel Postville G2, maar omdat deze ook als L2ARC werd gebruikt, werd de sequentiele doorvoersnelheid gebottlenecked tot 70MB/s (maximale write speed van de SSD).

Later heb ik een Samsung 830 gepakt, en daarmee trok ik gewoon de gigabit lijn dicht.

Zou je niet ook zonder ssd beetje fatsoenlijke performance moeten hebben?.