Het grote ZFS topic

[Dennisik]

Verwijderd schreef op zaterdag 03 augustus 2013 @ 03:35:
Er zit een bug in beta8 waardoor je geen SLOG devices kan toevoegen. Beetje irritant maar gefixed in de komende build en je kunt desnoods even downgraden naar beta7 waar de bug niet in zit. Maar via de command line is het ook zo gepiept natuurlijk.

De installatieprocedure geeft wel duidelijk aan of deze geslaagd is of gefaald is. De output van het installscript is daarbij slechts een extra. Maar die melding is ook in beta9 weg omdat je niet de enige bent die het als een error zag. Toch staat er bovenaan duidelijk of het successful was of dat er iets fout ging.

Verder vind ik je snelheden prima in orde? Het is natuurlijk zo dat je met 6 disks in RAID-Z geen optimale configuratie draait; 6 disks in RAID-Z2 zou wel optimaal zijn. Verder heb je 4K optimalisatie toegepast bij het aanmaken van je pool? Of je pool 4K optimaal is kun je zien op de Pool pagina als je je pool aanklikt, staat in het overzicht halverwege de pagina.

Heb slog device via de CLI al toegevoegd, dat was zo gedaan.
Het was mijn fout, omdat ik de installatie al stopte omdat ik de error zag.

Snelheden zijn zeker prima in orde, 2x zoveel als ik had gehoopt. Het is inderdaad geen optimale configuratie, maar er zit slechts 1GB uplink op. Dus daar maak ik mij niet druk over.

Ik heb 4K op alle devices aangezet en ook voor pool inderdaad.

Zojuist /boot/loader.conf gevonden, daar kunnen we leuk in spelen om te kijken of we de performance kunnen verhogen. Blijft een zeer tof OS!

Test size : 32 GiB
normal read : 600 MB/s
normal write : 404 MB/s
Alvast 2 doelen gehaald.

#vfs.zfs.l2arc_noprefetch=0
#vfs.zfs.l2arc_write_max=26214400
#vfs.zfs.l2arc_write_boost=52428800

Verbeterd read iets, maar write wat minder. Weinig effect iig.
Test size : 32 GiB
normal read : 613 MB/s
normal write : 385 MB/s

[Dennisik]

Ik wil ntfs-3g installeren om ntfs te mounten. Speed van standaard command is zeer laag.

Nu heb ik via Subversion /usr/ports & /usr/src & /usr/doc helemaal gedownload en up to date gekregen.
http://www.freebsd.org/do...handbook/ports-using.html

Nu run ik het command
cd /usr/ports/sysutils/fusefs-ntfs
make install clean

Krijg ik dit als output:

code:

[root@zfsguru /usr/ports/sysutils/fusefs-ntfs]# make install clean
===>  Installing for fusefs-ntfs-2012.1.15
===>   fusefs-ntfs-2012.1.15 depends on executable: mount_fusefs - not found
===>    Verifying install for mount_fusefs in /usr/ports/sysutils/fusefs-kmod
===>  fusefs-kmod-0.3.9.p1.20080208_11 Integrated into base.
*** [install] Error code 1

Stop in /usr/ports/sysutils/fusefs-kmod.
*** [run-depends] Error code 1

Stop in /usr/ports/sysutils/fusefs-ntfs.
*** [install] Error code 1

Stop in /usr/ports/sysutils/fusefs-ntfs.

Wat doe ik fout?

[FireDrunk]

Je moet de ports tree gebruiken die past bij zfsguru.

Deinstalleer alles wat je via de ports tree hebt geinstalleerd, en installeer de ZFSguru Ports service vanuit de webinterface, dan krijg je versies van applicaties die bij ZFSguru passen.

Als je dat niet doet krijg je bijvoorbeeld kernel mismatches (en Fuse vind dat inderdaad niet grappig )

[Dennisik]

FireDrunk schreef op zaterdag 03 augustus 2013 @ 18:26:
Je moet de ports tree gebruiken die past bij zfsguru.

Deinstalleer alles wat je via de ports tree hebt geinstalleerd, en installeer de ZFSguru Ports service vanuit de webinterface, dan krijg je versies van applicaties die bij ZFSguru passen.

Als je dat niet doet krijg je bijvoorbeeld kernel mismatches (en Fuse vind dat inderdaad niet grappig )

Port service kan ik niet installeren via de webinterface.
Omdat ik versie 9.1-006 draai.

/usr/doc/port/ports verwijderd met rm -rf
Draai nu portsnap fetch && portsnap extract

Dit is al de 2de keer in 8u dat die onverwacht reboot.

Waarbij ik dit als error krijg:

code:

===>  Installing for fusefs-ntfs-2012.1.15
===>   fusefs-ntfs-2012.1.15 depends on executable: mount_fusefs - not found
===>    Verifying install for mount_fusefs in /usr/ports/sysutils/fusefs-kmod
===>  fusefs-kmod-0.3.9.p1.20080208_11 requires the userland sources to be installed. Set SRC_BASE if it is not in /usr/src.
*** [install] Error code 1

Stop in /usr/ports/sysutils/fusefs-kmod.
*** [run-depends] Error code 1

Stop in /usr/ports/sysutils/fusefs-ntfs.
*** [install] Error code 1

Stop in /usr/ports/sysutils/fusefs-ntfs.
[root@zfsguru /usr/ports/sysutils/fusefs-ntfs]#

Installeer ik vervolgens met svn checkout https://link/base/head /usr/src

Dan is het deze error geworden:

code:

[root@zfsguru /usr/ports/sysutils/fusefs-ntfs]# make install clean
===>  Installing for fusefs-ntfs-2012.1.15
===>   fusefs-ntfs-2012.1.15 depends on executable: mount_fusefs - not found
===>    Verifying install for mount_fusefs in /usr/ports/sysutils/fusefs-kmod
===>  fusefs-kmod-0.3.9.p1.20080208_11 Integrated into base.
*** [install] Error code 1

Stop in /usr/ports/sysutils/fusefs-kmod.
*** [run-depends] Error code 1

Stop in /usr/ports/sysutils/fusefs-ntfs.
*** [install] Error code 1

Stop in /usr/ports/sysutils/fusefs-ntfs.

[ Voor 64% gewijzigd door Dennisik op 03-08-2013 19:25 ]

[FireDrunk]

Dat kan niet, zoals ik al zeg. Je moet eerst Fuse installeren voor je NTFS-3g kan draaien. En om Fuse te installeren heb je waarschijnlijk de Kernel Source nodig en de Ports tree die bij zfsguru passen.

Als je die niet kan installeren omdat je 9.1-006 draait, zul je of *ALLES* moeten updaten (dus ook je kernel) of je moet downgraden naar 9.1-005.

Ik zou niet weten hoe je anders Fuse gecompiled krijgt.

In principe moet je dus *NOOIT* portsnap fetch && portsnap extract gebruiken onder zfsguru!

offtopic:
Tenzij je precies weet wat je doet...

[ Voor 16% gewijzigd door FireDrunk op 03-08-2013 20:01 ]

[Dennisik]

FireDrunk schreef op zaterdag 03 augustus 2013 @ 20:00:
Dat kan niet, zoals ik al zeg. Je moet eerst Fuse installeren voor je NTFS-3g kan draaien. En om Fuse te installeren heb je waarschijnlijk de Kernel Source nodig en de Ports tree die bij zfsguru passen.

Als je die niet kan installeren omdat je 9.1-006 draait, zul je of *ALLES* moeten updaten (dus ook je kernel) of je moet downgraden naar 9.1-005.

Ik zou niet weten hoe je anders Fuse gecompiled krijgt.

In principe moet je dus *NOOIT* portsnap fetch && portsnap extract gebruiken onder zfsguru!

offtopic:
Tenzij je precies weet wat je doet...

http://zfsguru.com/forum/generalchat/253

Mooi advies dan.

Ik wou het gebruiken om ntfs mount sneller te laten werken, ik doe wel lokaal. Als goed is heeft sabnzbd en dergelijke dit niet nodig, dus hoef ik het ook niet te installeren.

Thanks voor het advies!

[ Voor 11% gewijzigd door Dennisik op 03-08-2013 20:10 ]

[FireDrunk]

Aj, daar is Jason inderdaad een beetje de mist mee ingegaan. Wat hij waarschijnlijk niet wist is dat Fuse een kernel module is, en daarom nogal versiegevoelig is.

Je kan het prima vanuit de portstree installeren, maar dan moet je wel de goede portstree hebben.

[Dennisik]

FireDrunk schreef op zaterdag 03 augustus 2013 @ 20:11:
Aj, daar is Jason inderdaad een beetje de mist mee ingegaan. Wat hij waarschijnlijk niet wist is dat Fuse een kernel module is, en daarom nogal versiegevoelig is.

Je kan het prima vanuit de portstree installeren, maar dan moet je wel de goede portstree hebben.

Helaas beschik ik nog niet over voldoende kennis, ach zolang sab/couch en dergelijke prima draait dan vind ik het prima. Ik zal dan op een test ZFS server even gaan experimenteren ermee.

[FireDrunk]

Ik zal eens een VM inrichten met 9.1-006, dan kan ik even voor je uitzoeken hoe het moet.

[Dennisik]

FireDrunk schreef op zaterdag 03 augustus 2013 @ 20:14:
Ik zal eens een VM inrichten met 9.1-006, dan kan ik even voor je uitzoeken hoe het moet.

Doe niet teveel moeite met dit weer!

Het was slechts een tijdelijke makkelijke oplossing, helaas niet gelukt. Dan doen we even anders, het is slechts eenmalig.

[FireDrunk]

Och, het is leerzaam

offtopic:
En zo warm is het hier niet, maar 28c ofzo

[Dennisik]

http://dl.dropboxusercont...ouchpotato_on_ZFSguru.pdf

http://zfsguru.com/forum/softwarepackages/168

Hier zeggen ze ook dat je portsnap moet gebruiken voor o.a. Sabnbzd en dergelijke. Die zijn toch wel vrij belangrijk voor wat ik er mee wil doen.
Ben benieuwd of het postprocessing script draait van Sickbeard op ZFSguru.

[ Voor 11% gewijzigd door Dennisik op 03-08-2013 20:25 ]

[FireDrunk]

Als je even geduld hebt, komen de services weer vrij, en kan je die hele meuk via het menu van ZFSguru installeren.

[Dennisik]

FireDrunk schreef op zaterdag 03 augustus 2013 @ 20:36:
Als je even geduld hebt, komen de services weer vrij, en kan je die hele meuk via het menu van ZFSguru installeren.

Ah dat zou nice zijn!

[FireDrunk]

Ik heb 9.1-006 geinstalleerd. Inderdaad een beetje erg erg erg erg erg erg, ennuh, erg jammer dat er geeneen service werkt...

(nog) een ego domper voor ZFSguru...

[Dennisik]

FireDrunk schreef op zondag 04 augustus 2013 @ 11:28:
Ik heb 9.1-006 geinstalleerd. Inderdaad een beetje erg erg erg erg erg erg, ennuh, erg jammer dat er geeneen service werkt...

(nog) een ego domper voor ZFSguru...

Voor enkel en alleen storage vind ik ZFSguru zeer goed, alles buiten dat wil niet echt lukken.

Als het binnen enkele weken wel lukt om sabnzb erop te krijgen, is dat het wachten waard. Anders ga ik terug naar 005 versie, al moet dat uiteraard dan weer niet ten koste van de performance.

[Kriss1981]

FireDrunk schreef op zaterdag 03 augustus 2013 @ 20:00:

In principe moet je dus *NOOIT* portsnap fetch && portsnap extract gebruiken onder zfsguru!

offtopic:
Tenzij je precies weet wat je doet...

Ik ga altijd als volgt te werk:

1. FreeBSD core updaten:
   code:
   

   # freebsd-update fetch
   # freebsd-update install

2. FreeBSD source:
   code:
   

   # svn checkout http://svn0.eu.FreeBSD.org/base/releng/9.1/ /usr/src

3. Ports Tree:
   code:
   

   # portsnap fetch extract

Daarna installeer ik alles (applicaties, drivers, kernel-modules) en ik heb nog nooit problemen ondervonden.

[FireDrunk]

Dan heb je mazzel gehad...

[Kriss1981]

Ik begrijp niet waarom

Wanneer ik deze stappen gelijk na elkaar uitvoer, dan zijn alle pakketten het meest recent. Dit zou toch geen problemen hoeven opleveren?

[HyperBart]

Hmmmm, er heeft een of andere Tweaker (oooooooh FireDrunk ) dat toen ook eens gedacht en geprobeerd maar dat bokte ergens zwaar...

Voor de geïnteresseerden: ik heb hier op dit moment 6 x 3TB Hitachi Ultrastars "op overschot" waar ik nu even wat fun benchmarks mee aan het doen ben, voornamelijk omtrent de performance degradatie na het volschrijven van de disks.

GODVER zeg, ik had die disks per 2 op elkaar LANGS de kast, dus in plain air gelegd. Zitten ze allemaal boven de 60 graden. Wat een heethoofden zijn dat zeg

[ Voor 59% gewijzigd door HyperBart op 04-08-2013 15:32 ]

[Dennisik]

Kriss1981 schreef op zondag 04 augustus 2013 @ 13:39:
[...]


Ik ga altijd als volgt te werk:

1. FreeBSD core updaten:
   code:
   

   # freebsd-update fetch
   # freebsd-update install

2. FreeBSD source:
   code:
   

   # svn checkout http://svn0.eu.FreeBSD.org/base/releng/9.1/ /usr/src

3. Ports Tree:
   code:
   

   # portsnap fetch extract

Daarna installeer ik alles (applicaties, drivers, kernel-modules) en ik heb nog nooit problemen ondervonden.

Kan je hierna dan direct ook sabnzd en dergelijke installeren?

Door in de juiste make een make install clean uit te voeren?

[Kriss1981]

Dat kan zeker. Alleen is dit volgens een aantal personen "heel gevaarlijk". Ik weet nog steeds niet waarom.

[FireDrunk]

Het is niet gevaarlijk, het is alleen zo dat je ports gebruikt die voor een andere versie bedoelt zijn dan ZFSguru heeft.

Bedenk dat je bijvoorbeeld applicaties gaat compilen die tegen andere versies van Perl en Python zijn gecompiled. Standaard heeft ZFSguru versies voor python/perl die voor FreeBSD 9.1-RELEASE zijn, niet voor 9.1-CURRENT of 10.0-CURRENT. De ports tree houdt hier niet zomaar rekening mee.

Je moet dus bij het installeren van applicaties uit de ports tree goed opletten of de dependencies die je gebruikt ook installeerbaar zijn.

Zo kan je PHP niet updaten, want dan krakt ZFSguru.

[Kriss1981]

Ah ok. Nu is het duidelijk.

Zoals ik al eerder aangaf heb ik zelf nog geen problemen ervaren, met mijn werkwijze. Ik draai zelf zfsguru sinds de start van het project en heb altijd alles middels de ports tree gecompiled. Wel heb ik ervaren dat bij het gebruik van packages, compatibility issues kunnen ontstaan.

[FireDrunk]

Precies, en als je redelijk normale packages gebruikt is dat allemaal niet zo'n probleem. Libc is bijvoorbeeld prima backwards compatible dus werkt vaak wel.

Het word pas lastig als je programma's gaat draaien die afhankelijk zijn van de kernel (zoals Virtualbox). Als je dat wil updaten, ben je wel even zoet.

Tenzij je altijd alles up-to-date houdt, dan is het weer niet zo'n groot probleem.
Daar kan je iets als portmaster voor gebruiken. Maar ook dat vereist enig inzicht en hoe het allemaal werkt.

[ Voor 23% gewijzigd door FireDrunk op 04-08-2013 18:13 ]

[Dennisik]

Kriss1981 schreef op zondag 04 augustus 2013 @ 15:36:
Dat kan zeker. Alleen is dit volgens een aantal personen "heel gevaarlijk". Ik weet nog steeds niet waarom.

Ah oke, dan ga ik eens experimenteren in een VM met dezelfde versie. Voordat ik het op de echte server doe.

[Compizfox]

FireDrunk schreef op zondag 04 augustus 2013 @ 16:14:
Het is niet gevaarlijk, het is alleen zo dat je ports gebruikt die voor een andere versie bedoelt zijn dan ZFSguru heeft.

Een andere versie van wat? Van FreeBSD?

Bedenk dat je bijvoorbeeld applicaties gaat compilen die tegen andere versies van Perl en Python zijn gecompiled.

Eh wat, ports compilen die al zijn gecompiled?

Standaard heeft ZFSguru versies voor python/perl die voor FreeBSD 9.1-RELEASE zijn, niet voor 9.1-CURRENT of 10.0-CURRENT. De ports tree houdt hier niet zomaar rekening mee.

Maar je update je basesystem ook niet.

Ik houd mijn system altijd gewoon up-to-date via de ports en heb nog nooit problemen ondervonden, en ik snap ook niet waarom ik problemen zou moeten ondervinden.

Als je gelijk hebt, dan zouden precies dezelfde problemen onder vanilla FreeBSD toch ook voor moeten komen? Ik snap de rol van ZFSGuru in je uitleg niet.

[ Voor 19% gewijzigd door Compizfox op 04-08-2013 19:09 ]

[FireDrunk]

Het gaat niet een hele versie verschil, het gaat om een verschil in world versie (gcc / pkgng / clang / python / perl / PHP )
Ports zijn niet gecompiled... packages zijn al gecompiled...

[ Voor 51% gewijzigd door FireDrunk op 04-08-2013 19:35 ]

[rikadoo]

even een klein vraagje, ik heb een ESXi server, en nu wil ik ZFSGURU installatie starten, maar als ik de ISO laad dan krijg ik niet de melding of ik ZFSGURU lokaal wil installeren maar ik krijg:

Dit is zowel via vmware als via vsphere (esxi)



voorheen had ik een installatie ISO en die vroeg wel of ik het wou installaren, ik heb versie: ZFSguru-LiveCD-0.2-beta8-amd64-normal

Als ik wel verder ga ,optie 1 kies, met ZFS dan krijg ik de vraag 'Enter full pathname of SHELL or RETURN for /bin/sh:'

Doe ik nu iets verkeerd?

[ Voor 5% gewijzigd door rikadoo op 04-08-2013 20:04 ]

[FireDrunk]

Hoe groot is je ISO, en welk type besturingssysteem heb je aan de VM gegeven?
Welk type ISO Emulatie staat ingesteld bij de VM?

[rikadoo]

Ik had aangegeven FreeBSD 64Bit, virtual device node staat op IDE. Als je dat bedoeld. Heb hem nu even lokaal via VMware.

De ISO is 301MB, heb ik gewoon van de ZFSGURU site gedownload

Net even FreeNAS gedownload met de zelfde instellingen opgestart en daar kan ik wel gewoon installeren.

Nu ZFSguru-0.1.8-livecd-amd64 gedownload en die start wel gewoon op en ik kan hem zonder probleme installeren.

[ Voor 59% gewijzigd door rikadoo op 04-08-2013 20:55 ]

[Compizfox]

FireDrunk schreef op zondag 04 augustus 2013 @ 19:32:
Het gaat niet een hele versie verschil, het gaat om een verschil in world versie (gcc / pkgng / clang / python / perl / PHP )

Ik snap niet precies wat je bedoelt te zeggen...

Ports zijn niet gecompiled... packages zijn al gecompiled...

Dat is precies wat ik zeg. Echter, jij had het over "ports compilen die al zijn gecompiled".

[FireDrunk]

Het moest zijn "gelinkt"

[fonsoy]

Ik heb een schijf toegevoegd aan ZFSguru die ik eerst als externe harde schijf gebruikte voor een Windows systeem. De schijf is daardoor met NTFS geformatteerd.

Mijn aanname was om deze simpelweg in de machine te zetten, en vervolgens te formatteren, en te gebruiken in een van mijn ZFS pools. Op deze wijze werken, werkt altijd onder Windows.

Ik krijg de volgende foutmelding bij de poging tot de volgende handeling 'zero write partition area';

Failure: execution failed for command: /usr/local/www/zfsguru//scripts/format_disk.sh da5
Notice: command output:
Formatting disk da5...dd: /dev/da5: Operation not permitted

Iemand een idee waarom ik 'geen toestemming' heb om de schijf te 'wissen'?

[Dennisik]

Hoe heb je de schijf gemounted?

Wss met mount ntfs -t /dev/sda /temp? Dan is die alleen read-only.

Met ntfs -3g mount je hem met volledige rw rechten.

[Dennisik]

Wil ik mijn data nog beter beschermen door raidz1 en vooral ZFS te gebruiken. Is een tijdelijke 2TB waar data slechts 3 dagen op stond kapot gegaan, dacht 2 TB aan data

Heb trouwens wat performance tests gedaan om te kijken wat de rol van geheugen was, hier de resultaten:

Met 12GB

ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark
Pool : pool-storage (10.9T, 42% full)
Test size : 32 GiB
normal read : 538 MB/s
normal write : 347 MB/s

Test size : 32 GiB
normal read : 529 MB/s
normal write : 248 MB/s

Test size : 64 GiB
normal read : 499 MB/s
normal write : 231 MB/s

Met 8GB

ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark
Pool : pool-storage (10.9T, 42% full)
Test size : 32 GiB
normal read : 499 MB/s
normal write : 305 MB/s

Test size : 32 GiB
normal read : 497 MB/s
normal write : 347 MB/s

Test size : 64 GiB
normal read : 495 MB/s
normal write : 302 MB/s

Met 4GB

ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark
Pool : pool-storage (10.9T, 42% full)
Test size : 32 GiB
normal read : 262 MB/s
normal write : 297 MB/s

Test size : 32 GiB
normal read : 248 MB/s
normal write : 318 MB/s

Test size : 64 GiB
normal read : 253 MB/s
normal write : 302 MB/s

Conclusie:

Verschil tussen 12/8 en 4GB is zeer goed te zien in read speeds. Met write is het verschil er amper eigenlijk. Ben eigenlijk meer benieuwd waarom write over het algemeen sneller is met 8GB dan met 12GB. Ik denk dat te wijten valt aan enige inconsistentie m.b.t. het testen, want als ik de top speeds vergelijk met write tussen 8GB en 12GB zijn die wel hetzelfde.

Wel mooi om te zien in die zin, dat 1GB per disk voldoende is. Ik heb 8 disks, de winst met 12GB is niet extreem groot, read hooguit 30MB meer.

[ Voor 36% gewijzigd door Dennisik op 05-08-2013 10:35 ]

[FireDrunk]

Meer geheugen levert vooral meer caching op, als je dus data meerdere keren leest, zal je veel sneller uitkomen. Write caching is toch maximaal een paar honderd MB (vanwege de default transaction settings). Met tuning zou je nog wat kunnen spelen om preciezer je geheugen te gebruiken, maar dat is echt een pokke werk...

Ik heb hier 16GB in mijn server, en ga binnenkort terug naar 8, want het maakt toch niets uit. (4*4TB RAIDZ)

[Dennisik]

FireDrunk schreef op maandag 05 augustus 2013 @ 10:29:
Meer geheugen levert vooral meer caching op, als je dus data meerdere keren leest, zal je veel sneller uitkomen. Write caching is toch maximaal een paar honderd MB (vanwege de default transaction settings). Met tuning zou je nog wat kunnen spelen om preciezer je geheugen te gebruiken, maar dat is echt een pokke werk...

Ik heb hier 16GB in mijn server, en ga binnenkort terug naar 8, want het maakt toch niets uit. (4*4TB RAIDZ)

Met deze wetenschap had ik inderdaad ook genoeg gehad aan 8GB. Ach, het heeft iig geen nadelen als het erin zit.

[Tsurany]

Neem aan dat wanneer je honderden gigabytes aan het schrijven bent het geheugen eigenlijk niet meer uit maakt? Een GB of 12 aan cache is dan niet zo relevant meer.

[Dennisik]

Tsurany schreef op maandag 05 augustus 2013 @ 11:20:
Neem aan dat wanneer je honderden gigabytes aan het schrijven bent het geheugen eigenlijk niet meer uit maakt? Een GB of 12 aan cache is dan niet zo relevant meer.

Hangt beetje vanaf wat voor data je schijft. Random of Seq is een groot verschil.
Maar als goed is niet nee, daarnaast is de toevoer nu de enige bottleneck met slechts 1x1GB.

[Compizfox]

FireDrunk schreef op zondag 04 augustus 2013 @ 23:52:
Het moest zijn "gelinkt"

Ook dan staat mijn punt nog steeds, want linken doe je na het compilen. Ports compileer en link je pas als je "make" intikt.

[ Voor 11% gewijzigd door Compizfox op 05-08-2013 15:06 ]

[rikadoo]

Goed volgende probleem, ik heb nu een server met ESXi 5.1 geinstalleerd, nu wil ik via vSphere ZFSGURU gaan installeren, dit lukt tot het menu waar ik via de webbased verder kan. ik krijg geen menu, aangezien ik nog een beginneling ben met ESXi doe ik vast iets verkeerds met de netwerk instellingen in vSphere. ik heb de server via 1 netwerk kabel doorgestuurd naar mijn switch, daar achter zit mijn PC en de hoofdkabel naar de modem. Ik maak op mijn hoofdcomputer verbinding met de ESXi server via het IP en vSphere. Hoe kan het dat ik geen IP krijg? Mocht er een screenshot nodig zijn van bepaalde instellingen hoor ik het graag.

[Dennisik]

Hoe zijn de netwerk settings van je ESXi, alles standaard? Want dan heeft je vSwitch gewoon een directe uplink naar je modem.

Als je in je VM ifconfig doet, krijg je een IP adres te zien?
Of dhclient voor dhcp request, eventueel static en dan in hetzelfde LAN/VLAN.

LAN/VLAN settings goed?

[ Voor 9% gewijzigd door Dennisik op 05-08-2013 21:34 ]

[rikadoo]

Bij ESXi staat alles standaard, het ip is daar 192.168.1.20. Iedere PC in mijn netwerk krijgt een adres met 192.168.1.xx.

Ik heb in vSphere een Virtual aangemaakt en de installatie start ik op via een CD waar ZFSGURU opstaat.

Zodra alles doorlopen is krijg ik dat blauwe menu te zien, met Detect IP maar daar blijft http://0.0.0.0 staan.

Mijn settings zijn in vSphere niet meer standaard denk ik, aangezien ik het 1 en ander geprobeerd hebt. Ik zal even een screen maken van hoe de vSwitch nu is.

http://imageshack.us/a/img5/7963/jq91.jpg

[analog_]

Het zou moeten werken met VLAN ID all omdat VLAN 0 dan ook door gestuurd wordt. Verzet het anders eens naar vlan 0.
@hieronder, de vmkernel loopt los van de vswitch, aangezien hij de kernel wel kan bereiken zou het eigenlijk die settings moeten kopieren naar de vswitch. Ik heb zelf recentelijk pas de 4095 All ontdekt en in gebruik. Ik gebruik thuis echter geen untagged dus ik weet niet wat het gedrag hierop is.

[ Voor 56% gewijzigd door analog_ op 05-08-2013 21:58 ]

[Dennisik]

vmnic 0,2,3 kan je in principe eruit halen. Ook VLAN ID kan je het beste uitschakelen, geen idee of die een standaard vlan id untagged.

Heb je in de VM zelf al een ifconfig gedaan? Want die 0.0.0.0 kreeg ik ook te zien.

Ik denk dat het in VMware gewoon goed staat, maar dat je even in je shell van je VM een ifconfig moet doen om te kijken welk IP je hebt. Anders even static IP adres aanmaken en dan hoor je er ook gewoon bij te kunnen komen.

[rikadoo]

Ik heb nu VLAN uitgezet (op none) en de overige netwerk op unused.

als ik in de shell ifconfig doet krijg ik idd een ip te zien en als ik daarheen navigeer zie ik idd de setup van ZFSGURU. Een bug van ZFSGURU?

Settings nu:
http://imageshack.us/photo/my-images/96/3w3z.jpg/

ZFSGURU:
http://imageshack.us/photo/my-images/823/v9ac.jpg/

Lijkt te werken nu....

Nu maar eens kijken hoe ik de volledige HDD`s kan gebruiken in ZFSGURU en goed instellen in vSphere.

[ Voor 12% gewijzigd door rikadoo op 05-08-2013 22:11 ]

[webfreakz.nl]

Kwam dit artikel tegen:

http://www.anandtech.com/...fessional-storage-market/

Op pagina 4 wordt verwezen naar:

For those who are not convinced that the small startup Amplidata is onto something: Intel and Dr. Sam Siewert of Trellis Logic explain in this paper why it can even be mathematically proven that the Reed-Solomon based erasure codes of RAID 6 are a dead end road for large storage systems. The paper concludes:

http://www.intel.com/cont...plidata-storage-paper.pdf

Heb het nog niet helemaal gelezen, doe ik morgen wel.

[Johnnygo]

Heeft iemand eigenlijk al eens de linux versie van zfs geprobeerd? Ik heb nu een linux (Ubuntu 12.04) server draaien en wil de storage upgraden naar zfs.
En als ik dan later wil switchen naar bv zfsguru. Kan ik dan de onder linux aangemaakte zfs pool gewoon meenemen?

[FireDrunk]

Ja maar je wil geen zfs draaien op Ubuntu 12.04, pak liever 13.04 of zelfs 13.10

[mkroes]

FireDrunk schreef op dinsdag 06 augustus 2013 @ 10:52:
Ja maar je wil geen zfs draaien op Ubuntu 12.04, pak liever 13.04 of zelfs 13.10

Want??

Heb hier 2 ubuntu servers draaien met zfs, versie 12.04.2 LTS. Werkt naar behoren..
Maar doe er dan ook weinig spannends mee. Draaien puur voor zfs met samba shares.

Maar ben toch benieuwd waarom geen 12.04?

[FireDrunk]

Oude kernel, werkt de nieuwste versie van zfs wel goed dan?

[Habana]

Verwijderd schreef op vrijdag 02 augustus 2013 @ 14:27:
Klik op de disk op Disks->Advanced. Als je disk ada heet hoor je daar APM te kunnen instellen. Instellen op 254 betekent headparking uitschakelen, dan loopt de Load Cycle Count (LCC) niet meer op. Dit moet je mogelijk wel doen bij iedere boot. Je kunt bij de nieuwe ZFSguru systeemversie 9.1-006 in de /etc/rc.conf instellen welke disks automatisch op APM 254 moeten worden ingesteld bij iedere boot.

Twee maal Neen, ieder geval niet met mijn vijf stuks WD20EARX,
ada0 - PC= 101 - LCC= 9259 - lifetime 19 Days
ada1 - PC= 65 - LCC= 9008 - lifetime 15Days
ada2 - PC= 43 - LCC= 8266 - lifetime 11Days
ada3 - PC= 97 - LCC= 38405 - lifetime 2.2 years ( beiden probleemloos gebruikt in Synology 211+)
ada4 - PC= 101 - LCC= 38246 - lifetime 2.2 years

Uiteindelijk maar een bootable WDidle3 USB stick aangemaakt en van de eerste drie de LCC uit gezet,
hetgeen bij de twee oudere HDD's waarschijnlijk al door de Synology is gedaan tijdens de install destijds.
Voor als nog werkt het naar behoren en geen oplopende LCC meer.

[Keiichi]

Ik bouw binnenkort een NAS met ZFS. Dit doe ik met harde schijven van verschillende types, maar gelijke grootes.

Naar alle waarschijnlijk heeft 1 schijf 4k sectors. (andere 512bytes). Gaat dit problemen opleveren als ik de pool me ashift=12 aanmaak? Ik heb al wel begrepen dat ashift=9 op 4k sectors een performance hit geeft, maar kan nergens terugvinden of dit anders ook zo is.

[Xudonax]

Andersom is dit niet zo, aangezien 4kb een veelvoud van 512b is. Moet helemaal goed gaan dus!

[mkroes]

FireDrunk schreef op dinsdag 06 augustus 2013 @ 15:53:
Oude kernel, werkt de nieuwste versie van zfs wel goed dan?

Heb eerlijk gezegd geen idee welke versie er nu precies draait... Zal dit zsm even voor je nakijken..

Draai dus zpool versie 5000 met zfs filesystem versie 5. Dit alles werkt bij mij wel naar behoren.
Maar zoals gezegd, doe ik er niet echt wat spannends mee.

[ Voor 23% gewijzigd door mkroes op 07-08-2013 17:19 . Reden: info ]

[Tsurany]

Ik wil actief de dataset functionaliteit uit FreeNAS gebruiken om makkelijk permissions te beheren. Is er een reden om dit niet te doen? Zitten hier nadelen aan? Compatibiliteit met bijvoorbeeld NAS4Free of ZFSGuru?

[u_nix_we_all]

mkroes schreef op woensdag 07 augustus 2013 @ 17:08:
[...]

Heb eerlijk gezegd geen idee welke versie er nu precies draait... Zal dit zsm even voor je nakijken..

Draai dus zpool versie 5000 met zfs filesystem versie 5. Dit alles werkt bij mij wel naar behoren.
Maar zoals gezegd, doe ik er niet echt wat spannends mee.

Volgens mij wordt pool versie 5000 nog niet op alle platformen ondersteund, ik dacht dat zfsguru het nog niet had, maar geplanned voor de komende release ?

Ik ben er sowieso nog niet helemaal uit hoe dat met die fork naar de 5000-serie zit. Gaan alle opensource distro's daar naartoe ? Is compatibiliteit met Oracle v29 en hoger helemaal uitgesloten ivm closed source ?

Voorlopig houd ik mijn main datapool nog even op v28, dat werkt goed voor mij.

[Xudonax]

Volgens mij word er vanuit de community niet gedacht dat Oracle ZFS hoger dan v28 ooit nog uit gaat brengen. Hierom is de community naar pool versie 5000 gegaan, in deze versie zitten features voor zover ik weet met flags geïmplementeerd. Ik denk zelf dat het idee is dat alle opensource implementaties hierheen gaan, omdat Oracle nou eenmaal Oracle is Aka, Oracle gaat waarschijnlijk niets/nauwelijks meer iets vrijgeven hiervan.

[webfreakz.nl]

ZFS versie voor Oracle Express 11 is 33.

[u_nix_we_all]

webfreakz.nl schreef op woensdag 07 augustus 2013 @ 21:47:
ZFS versie voor Oracle Express 11 is 33.

Klopt, maar ik denk dat Xudonax met uitbrengen bedoelt als opensource.
Ik zal me eens gaan verdiepen in die flags en versie 5000, want ik denk niet dat ik ooit de closed source versies zal gaan gebruiken voor thuis-opslag.

[Xudonax]

Ik bedoelde inderdaad als opensource versie ja, sorry voor de onduidelijkheid

En volgens mij is de closed source versie (natuurlijk icm Solaris/Oracle Express) ook niet echt goedkoop... Anders had ik het nog een kans gegeven, maarja

[mca2]

ik heb een setup met 4 PATA-disks waarvan drie in een Raid-Z1 onder FreeBSD, is het ook mogelijk die drie disks uit te zetten? 95% vd tijd staat mijn server namelijk te niksen en dan is wat energie besparing welkom.

[Xudonax]

Ik weet niet precies hoe dat op FreeBSD zit, maar op Linux kan ik (welliswaar voor SATA schijven) een spindown timer instellen met hdparm. Als je schijven dat niet ondersteunen kun je eens kijken of je met hdparm de APM waarde kunt instellen, dit heeft eenzelfde effect, maar dan minder gecontroleerd door jou

[webfreakz.nl]

Ik wist wel dat het over de opensource ZFS versies ging, maar had niet verwacht dat er nog op mijn bericht gereageerd zou gaan worden

[Durandal]

FireDrunk schreef op dinsdag 06 augustus 2013 @ 15:53:
Oude kernel, werkt de nieuwste versie van zfs wel goed dan?

Maar het is wel een LTS

Hier ook ZFS on Linux, Ubuntu 12.04LTS server, 10 disks RaidZ2.

Draait al driekwart jaar als een huis. Werkt dus prima.
Ik heb net mijn eerste gecrashte disk en wacht op de RMA, maar verwacht van de kant van ZFS geen problemen als ik de vervanger er in steek.

Ik ben er niet helemaal meer zeker van maar ik heb geloof ik de kernel geupgrade met een dist-upgrade omdat de oude kernel een probleem had met de disks in spindown te brengen. Zwerft ergens nog een post van rond hier.

[FireDrunk]

Mja ok, LTS is inderdaad wel beter, maar ik verwacht(te) niet dat het ZoL team oudere kernels lang blijft supporten.

[Durandal]

Tja, je moet toch ergens van uitgaan. Elk jaar een nieuwe server opbouwen zie ik ook niet zitten. Ik hoop toch eigenlijk op drie jaar.
Als de ZoL lui er mee kappen heb ik geen probleem tot er een probleem komt, en dan kan ik altijd nog upgraden naar de volgende LTS.

[FireDrunk]

* FireDrunk is ondertussen bezig met het proberen werkend te krijgen van ZFSguru onder Hyper-V!

De Hyper-V integration services zijn er nu voor FreeBSD 9.1

Ik wil eens kijken of de Paravirtual SCSI Controller van Microsoft een beetje goed werkt icm ZFS.
Wie niet waagt, die niet wint!

[batsma]

laat het ff weten, draai nu nog ubuntu met ZoL. leuke webinterface zou wel handig zijn. het probleem waar ik tegenaanliep met freeBSD was de nic vanuit hyper-v

[pierce]

FireDrunk schreef op donderdag 08 augustus 2013 @ 16:02:
* FireDrunk is ondertussen bezig met het proberen werkend te krijgen van ZFSguru onder Hyper-V!

De Hyper-V integration services zijn er nu voor FreeBSD 9.1

Ik wil eens kijken of de Paravirtual SCSI Controller van Microsoft een beetje goed werkt icm ZFS.
Wie niet waagt, die niet wint!

Zit net even te testen met zfsguru in hyperv, maar gaat alles behalve soepel....
je moet eerst een lecagy nic toevoegen vervolgens pakt freebsd dhcp niet goed, pas na een ifconfig down/up werkt de lan connectie weer, maar weer alleen binnen het eigen subnet...
Statisch IP werkt uiteindelijk wel, nu eerst even updaten naar de laatste versie en daarna de Hyper-V integration services downloaden en installeren.

Overigens vind ik HyperV sowieso een prut product... 't is dat het hier nog in een POC omgeving draait..

[mkroes]

Tsja, ieder zijn eigen mening. Voor wat ik er mee wil doen werkt het voor mij goed. Vind trouwens dat ze met Hyper-V 3 toch wel een mooie inhaalslag hebben gemaakt.

Maar zou wel mooi wezen als ZFSguru ook onder hyper-v wil draaien. Is toch wel wat makkelijker qua management.

[pierce]

mkroes schreef op donderdag 08 augustus 2013 @ 21:09:
Tsja, ieder zijn eigen mening. Voor wat ik er mee wil doen werkt het voor mij goed. Vind trouwens dat ze met Hyper-V 3 toch wel een mooie inhaalslag hebben gemaakt.

Maar zou wel mooi wezen als ZFSguru ook onder hyper-v wil draaien. Is toch wel wat makkelijker qua management.

HyperV 3 is absoluut een verbetering tov eerdere versies, maar vergeleken met vsphere heeft het nog steeds een hoop in te halen. We zijn aan het kijken of we onze vsphere omgeving deels of in zijn geheel kunnen vervangen door HyperV en hebben daar nu een POC voor draaien. Maar zeker als je vpshere gewend bent wordt je echt niet blij van HyperV... Overigens is dit puur een financiele aangelegenheid, er is namelijk geen enkele andere reden te bedenken waarom je zou willen overstappen...
Als je het dan al virtueel wilt draaien, gebruik dan gewoon esxi

Anyway, ik ga van het weekend en volgende week nog nog wel even verder testen. Vooralsnog gaat het niet echt soepel, zfsguru wil de netwerkinstellingen niet onthouden en dhcp werkt al helemaal voor geen meter. Nog even uitvogelen of dat aan zfsguru of aan (de legacy nic van) Hyperv ligt.

[ Voor 7% gewijzigd door pierce op 08-08-2013 22:25 ]

[mkroes]

Hyper-v is inderdaad een stuk goedkoper als vsphere. Helemaal wanneer je omgeving voornamelijk uit windows servers bestaat.

Heb thuis destijds ook voor hyper-v gekozen. Zit nog wel eens te twijfelen of ik de overstap nog eens moet maken naar het andere kamp. Maar ach, zolang alles naar behoren werkt.

[mca2]

Xudonax schreef op woensdag 07 augustus 2013 @ 22:53:
Ik weet niet precies hoe dat op FreeBSD zit, maar op Linux kan ik (welliswaar voor SATA schijven) een spindown timer instellen met hdparm. Als je schijven dat niet ondersteunen kun je eens kijken of je met hdparm de APM waarde kunt instellen, dit heeft eenzelfde effect, maar dan minder gecontroleerd door jou

hdparm bestaat niet in FreeBSD, ook niet als port helaas.

[FireDrunk]

Onder FreeBSD heb je ofwel camcontrol voor IDE/SATA/AHCI, of de spindown utility voor SCSI/SAS.

[Neptunus]

Wat vinden jullie van dit artikel: https://calomel.org/zfs_raid_speed_capacity.html
Met name het stuk: To compress, or not to compress, that is the question

[u_nix_we_all]

Neptunus schreef op vrijdag 09 augustus 2013 @ 09:56:
Wat vinden jullie van dit artikel: https://calomel.org/zfs_raid_speed_capacity.html
Met name het stuk: To compress, or not to compress, that is the question

Ik denk niet dat je de resultaten van de bonnie++ benchmark kunt vergelijken met compressie met echte data. Hangt wel een beetje van de data af, maar met bijv. video of muziek haal je nooit die ratio 1:8 die hij op die bonnie++-data haalt, dus IMHO een onzinnige test.

edit: Verder wel een aardig artikel, interressant wat hij schrijft mbt onboard sata etc.

[ Voor 7% gewijzigd door u_nix_we_all op 09-08-2013 10:21 ]

[HyperBart]

Eigenlijk nooit bij stilgestaan, maar ik zie, buiten het verhoogde gebruik in CPU geen grote nadelen. Het is eigenlijk simpel dat het geniaal is: verklein het aantal bits dat je van spindles moet halen, want dat is toch factor XX trager dan verwerkingssnelheden van CPU's en geheugen anno 2013...

Ik zou het wel niet aanzetten op een vNAS. Fysiek zou het me geen reet boeien omdat het dan een geïsoleerd systeem is met dedicated resources.

To compress, or not to compress, that is the question

The short answer is yes, you should look into compression. The command "zfs set compression=lzjb tank" will enable compression on the "tank" pool. The long answer is also yes, but you want to be aware of the positives and negatives to make an informed decision.

Drives in general are really, really slow. The system wastes a significant amount of time just waiting to get data to and from the hard drives. The main argument against compression on the fly is it uses CPU time when reading or writing to the array and also adds latency. If you have been using computers for a while you might remember "Stacker" from the 1990's. Ideally, we want the system to contact the drives as little as possible because they are so slow.

Compression can reduce the amount of blocks the drive needs to access and the result is faster speeds at the cost of CPU time. What you gain is less blocks read or written to for even moderately compressible files meaning you have effectively increased the aerial density of the drive platters. Compression allows the drive heads to move over a smaller area to access the same amount of data.

The developer of ZFS made lzjb compression and it is the default compression algorithm in FreeBSD 9.1. lzjb is very efficient and uses very few resources for the job that it does. Take note that ZFS and compression use multiple CPU cores so the more cores and the faster they are the faster compression will be. With lzjb compression enabled, the system will use around 50% more CPU time to compress and uncompress files compared to handling raw data. On average lzjb will compress data to a maximum of 2x to 3x.

In our tests we show single drive reads go from 150MB/sec to 1,174MB/sec of compressed Bonnie++ test data with lzjb. Even compressed files like bzip2, zip, mp3, avi, mkv and webm will not waste much CPU time as lzjb is a very inexpensive compression method.

In FreeBSD 10 CURRENT (built with DEBUG, INVARIANT, MALLOC and WITNESS disabled) both lzjb and lz4 are available in ZFS. LZJB is fast, but LZ4 is faster with 500MB/sec compression and 1.5GB/sec decompression speeds. This makes LZ4 50% faster on compression and 80% on decompression compared to LZJB. You may need to use "zpool set feature@lz4_compress=enabled poolname" to enable lz4 on your pool as lz4 is not backwards compatible with non-lz4 versions of zfs.

LZ4's performance on incompressible data is equally impressive. LZ4 achieves higher performance by incorporating an "early abort" mechanism which triggers if LZ4 can not reach a minimum compression ratio of 12.5%. LZ4 is perfect for admins who would like to use compression as a default option for all pools. Enabling LZ4 on all volumes means compression will be used where appropriate, while making sure the algorithm will not waste CPU time on incompressible data and reads will not incur a latency penalty due to transparent decompression. Just incredible.

The following table shows a few raid types without compression and then with lzjb and lz4 compression enabled. Bonnie++ tests use database like files which compress fairly well. You will notice as we add more physical disks, compression makes less of an impact on performance. In fact, with lz4 compression we max out read and write speeds with only three disks in raidz (raid5). Our suggestion is to enabled compression on all arrays because the amount of throughput you gain outweighs the CPU usage and you get to compress data which can save space.

Nu ik die pagina wat zat door te lezen valt me ook iets op. Er wordt vaak geroepen dat als je een NAS thuis bouwt, dat je het beste de onboard SATA poorten kan gebruiken...

In het artikel they beg to differ:

All SATA controllers are NOT created equal

The performance of your RAID is highly dependent on your hardware. If you are using the motherboard SATA connectors, they are not going to perform as well as a SATA expander or a dedicated raid card. Just because the SATA port says SATA 6 and comes with fancy cables does not mean the port can actually move data quickly. The onboard chipsets are normally the cheapest silicon the manufacturer can get away with. This sentiment is true for most of the substandard on motherboard network ports too. Sad, but true.

On mailing lists and forums there are posts which state ZFS is slow and unresponsive. We have shown in the previous section you can get incredible speeds out of the file system if you understand the limitations of your hardware and how to properly setup your raid. We suspect that many of the objectors of ZFS have setup their ZFS system using slow or otherwise substandard I/O subsystems. We hope to clear up some of those misconceptions.

Here we test the SATA throughput of the exact same Western Digital Black 2TB SATA6 (WD2002FAEX) spinning hard drive and Samsung 840 PRO 256GB SSD on three(3) different interfaces using FreeBSD. We look at the SATA 6 Gbit/s port of a common gaming motherboard by Asus, a Supermicro server motherboard and an LSI MegaRAID raid card. All machines have at least a six(6) core CPU and 16 gig of ram. According to Western Digital the Black series 2TB (WD2002FAEX) should be able to theoretically sustain 150MB/sec sequential read and writes. The Samsung 840 Pro is rated at 540MB/sec reads and 520MB/sec writes. Notice the throughput between motherboard based SATA ports (sata 3 versus sata 6) and a dedicated card.

1x 2TB a single drive - 1.8 terabytes - Western Digital Black 2TB (WD2002FAEX)

 Asus Sabertooth 990FX sata6 onboard ( w= 39MB/s , rw= 25MB/s , r= 91MB/s )
 SuperMicro X9SRE sata3 onboard      ( w= 31MB/s , rw= 22MB/s , r= 89MB/s )
 LSI MegaRAID 9265-8i sata6 "JBOD"   ( w=130MB/s , rw= 66MB/s , r=150MB/s )

1x 256GB a single drive - 232 gigabytes - Samsung 840 PRO 256GB (MZ-7PD256BW)
 Asus Sabertooth 990FX sata6 onboard ( w=242MB/s , rw=158MB/s , r=533MB/s )
 LSI MegaRAID 9265-8i sata6 "JBOD"   ( w=438MB/s , rw=233MB/s , r=514MB/s )


# The raw bonnie output on FreeBSD 9.1

1x 2TB   a single drive  1.8 terabytes (Asus Sabertooth 990FX on board SATA6)
  Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
  Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
  zfsASUS         80G           39139   11 25902  8            91764    8 122.1   2
  Latency                       4015ms     3250ms              2263ms     443ms

1x 2TB   a single drive  1.8 terabytes (Supermicro X9SRE on board SATA6)
  Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
  Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
  zfsSuper        80G           31342   6 22420   4            89085    4 180.6   1
  Latency                       4709ms    4699ms               1263ms     568ms

1x 2TB   a single drive  1.8 terabytes (LSI MegaRAID 9265-8i JBOD SATA6)
  Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
  Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
  calomel.org     80G           130325  23 66041  11           150329   8 144.8   6
  Latency                       12251ms    5102ms              1381ms     611ms

1x 256GB a single drive - 232 gigabytes (Asus Sabertooth 990FX on board SATA6)
  Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
  Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
  calomel.org     80G           224826  42 158018  30           533094  38  3788  49
  Latency                        3736ms    1422ms               652ms   26953us

1x 256GB a single drive - 232 gigabytes (LSI MegaRAID 9265-8i JBOD SATA6)
  Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
  Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
  calomel.org     80G           438424  70 233976  41           514946  29  3807  57
  Latency                       70402us    1714ms               770ms   28608us

[ Voor 90% gewijzigd door HyperBart op 09-08-2013 10:36 ]

[FireDrunk]

Bij dat tweede stuk zeggen ze heel leuk JBOD, maar ik denk eerlijk gezegd dat het DRAM cache op de controller nog wel gewoon gebruikt word in JBOD modus... Een 9265-8i is echt GEEN goede controller voor ZFS... Dat ding heeft 1GB DRAM cache aan boord...

Daarom zijn onboard SATA poorten echt nog steeds beter, want die liegen niet...

[ Voor 14% gewijzigd door FireDrunk op 09-08-2013 12:53 ]

[Tsurany]

Kan je compression on the fly aan en uit zetten of enkel bij het aanmaken van een volume?

[FireDrunk]

Je kan het on-the-fly aan en uitzetten, maar eenmaal gecompresste data blijft gecompressed.

[Xudonax]

Voor mij is compressie niet echt een vraag, het staat gewoon overal aan (ja, zelfs op de pool waar mijn VMs staan). Ik heb er genoeg profijt van om het zo te laten, en enige vertraging in de VMs heb ik niet echt last van (in ieder geval geen merkbare vertraging). Alle pools waar primair tekst (txt, doc, pdf etc.) staat heb ik vrolijk gzip-9 als compressie gegeven, de rest is eigenlijk allemaal lzjb. Ik heb alleen geen idee hoeveel winst het nu precies oplevert

[FireDrunk]

Xudonax schreef op vrijdag 09 augustus 2013 @ 13:37:
Voor mij is compressie niet echt een vraag, het staat gewoon overal aan (ja, zelfs op de pool waar mijn VMs staan). Ik heb er genoeg profijt van om het zo te laten, en enige vertraging in de VMs heb ik niet echt last van (in ieder geval geen merkbare vertraging). Alle pools waar primair tekst (txt, doc, pdf etc.) staat heb ik vrolijk gzip-9 als compressie gegeven, de rest is eigenlijk allemaal lzjb. Ik heb alleen geen idee hoeveel winst het nu precies oplevert

root@NAS:~ # zfs get compressratio datapool/data
NAME           PROPERTY       VALUE  SOURCE
datapool/data  compressratio  1.00x  -

[enthernal]

wat onboard sata poorten betreft, wat hij daar zegt klopt, maar de vraag is (en de redenen waarom men het aanraad) of je er wel iets van merkt zolang je gewoon op 1Gbps netwerk zit? Het antwoord daarop is neen, zelfs met een gewone onboard sata controller haal je makkelijk de snelheidslimiet van je netwerkkaart met een goede disk, of kom je toch zeer dicht in de buurt. Met RAIDZ is het zelfs peanuts om zo'n lijntje vol te trekken. Waarom zou je dan zoveel geld in een controller steken? Enkel als je een verbinding hebt die sneller dan 1Gbps is begint een controller interessant te komen

[Tsurany]

Ik ben nu veel data aan het overpompen en schijven en geheugen worden tot op hun limiet gebracht en CPU heeft nog genoeg over. Ik neem aan dat 50% cpu usage slechts 50% usage van een enkele core is? If so, meer dan genoeg over. Zo niet, core extra toewijzen en alsnog ruimte voor compressie.
Als ik het aan zet, wordt de huidige data dan ook compressed?

[Xudonax]

Alle bestaande data blijft uncompressed. Wat je kunt doen is alle huidige data verplaatse (mv) naar een nieuwe map, en dan kopiëren (cp -Rfv) naar waar het vandaan komt. Op deze manier word het wel gecomprimeerd.

Daarnaast is het 50% extra CPU usage, en geen keiharde 50% Dus als ZFS nu ~4% gebruikt, word het dan ~6%. Eigenlijk kost compressie tegenwoordig niet heel veel meer, zeker niet de varianten die op bestandssystemen gebruikt worden. Iets als LZMA of 7z is natuurlijk een ander verhaal

[FireDrunk]

enthernal schreef op vrijdag 09 augustus 2013 @ 13:49:
wat onboard sata poorten betreft, wat hij daar zegt klopt, maar de vraag is (en de redenen waarom men het aanraad) of je er wel iets van merkt zolang je gewoon op 1Gbps netwerk zit? Het antwoord daarop is neen, zelfs met een gewone onboard sata controller haal je makkelijk de snelheidslimiet van je netwerkkaart met een goede disk, of kom je toch zeer dicht in de buurt. Met RAIDZ is het zelfs peanuts om zo'n lijntje vol te trekken. Waarom zou je dan zoveel geld in een controller steken? Enkel als je een verbinding hebt die sneller dan 1Gbps is begint een controller interessant te komen

De benchmark die ze daar doen is klets, je kan een 9265-8i nooit vergelijken met een onboard sata controller, dat is gewoon scheef vergelijken. Die LSI controller heeft 1GB geheugen die hij ook daadwerkelijk gebruikt vor die ene disk, je onboard controller heeft dat niet.

Dat Intel's SATA controller sneller is dan die van AMD (7-series vs 990FX zoals in die post vergeleken worden) wist ik al langer. Er is een poos terug nog iemand geweest en die had 6 SATA3 SSD's tegelijk aangesloten op beide platformen, en daar kwam uit dat de Intel overal beter presteren per poort gemiddeld dan de AMD SATA3 tegenhanger.

Dus zelfs al zegt AMD dat het 6*SATA3 doet, dan *haal* je het nog niet eens...

[Anteros]

Ik vind het idee van compressie wel een interessante eigenlijk. Ik heb het zelf nu uitstaan, maar vraag me af of er (nu?) meer mensen compressie (gaan) gebruiken? Mijn i5 eet eigenlijk altijd uit zijn neus en doet dus alles (downloaden, parren, repareren, uitpakken, streamen, etc) met gemak. Iets harder werken voor de compressie is niet zo erg. Ben benieuwd naar jullie mening.

Verder kan je compressie alleen aanzetten/wijzigen van de datasets. Niet van een volledige pool. Of zie ik nu iets over het hoofd?

[Tsurany]

Xudonax schreef op vrijdag 09 augustus 2013 @ 14:58:
Alle bestaande data blijft uncompressed. Wat je kunt doen is alle huidige data verplaatse (mv) naar een nieuwe map, en dan kopiëren (cp -Rfv) naar waar het vandaan komt. Op deze manier word het wel gecomprimeerd.

Dat is inderdaad nog een optie, heb dat helaas net juist gedaan om alle media (de grote bestanden) op een aparte dataset te krijgen

Daarnaast is het 50% extra CPU usage, en geen keiharde 50% Dus als ZFS nu ~4% gebruikt, word het dan ~6%. Eigenlijk kost compressie tegenwoordig niet heel veel meer, zeker niet de varianten die op bestandssystemen gebruikt worden. Iets als LZMA of 7z is natuurlijk een ander verhaal

True, maar gaat er meer om dat ik op dit moment nog aardig wat ruimte over heb dus zelfs een verdubbeling mogelijk zou zijn.

[onox]

Anteros schreef op vrijdag 09 augustus 2013 @ 18:41:
Verder kan je compressie alleen aanzetten/wijzigen van de datasets. Niet van een volledige pool. Of zie ik nu iets over het hoofd?

Alleen op datasets volgens mij. Maar dat is niet zo'n probleem. Je kan makkelijk een dummy dataset aanmaken die dan weer echte datasets bevat. Bijv. ospool/ROOT met -o mountpoint=none -o compression=on en daarna maak je bijv. aan ospool/ROOT/root en ospool/ROOT/root/var, beide met een -o mountpoint. Hetzelfde truckje kun je dan doen met ospool/HOME of ospool/DATA waarbij je bijv. geen compression toepast.

[pierce]

pierce schreef op donderdag 08 augustus 2013 @ 22:21:
[...]

Anyway, ik ga van het weekend en volgende week nog nog wel even verder testen. Vooralsnog gaat het niet echt soepel, zfsguru wil de netwerkinstellingen niet onthouden en dhcp werkt al helemaal voor geen meter. Nog even uitvogelen of dat aan zfsguru of aan (de legacy nic van) Hyperv ligt.

Freenas lijkt dezelfde netwerkproblemen als ZFSguru in HyperV te hebben

• dhcp werkt wel, min or meer, maar pas na een ifdown/up
• default route werkt niet met dhcp, alleen statisch config
• bij een statisch config moet je ook eerst ifdown/up uitvoeren voordat de default route actief is

En zo kan ik nog wel even doorgaan...

zal dus wel de lecagy nic van hyperv, al dan niet icm freebsd, zijn. Niet echt handig, want zo wordt het downloaden van de guest tools ernstig bemoeilijkt, en de normale nic werkt niet out of the box.
En nu heb ik nog steeds niet de tools gedownload

[FireDrunk]

Dat ligt allemaal inderdaad aan de legacy NIC. Met de paravirtual controller zou het moeten werken. De drivers daarvoor moet ik nog werkend krijgen. Kreeg compilatie fouten...

[HyperBart]

Vraagje: ik heb nu, omwille van performance problemen, even al mijn data verhuisd naar een 6 x 3TB RAIDZ2 pool door middel van ZFS snapshots en send/receive.

Nu moet uiteindelijk de data "ooit" terugkomen naar mijn eigen drives. Nu was ik van plan om compression aan te zetten op het destination FS en ik vraag me af of het mogelijk is om snapshots te senden receiven en onderwijl compression aan te zetten op het gespecifieerde aan te maken dest FS? Het bron-FS is non compressed...

[ Voor 7% gewijzigd door HyperBart op 12-08-2013 16:28 ]

[Snow_King]

HyperBart schreef op maandag 12 augustus 2013 @ 16:23:
Vraagje: ik heb nu, omwille van performance problemen, even al mijn data verhuisd naar een 6 x 3TB RAIDZ2 pool door middel van ZFS snapshots en send/receive.

Nu moet uiteindelijk de data "ooit" terugkomen naar mijn eigen drives. Nu was ik van plan om compression aan te zetten op het destination FS en ik vraag me af of het mogelijk is om snapshots te senden receiven en onderwijl compression aan te zetten op het gespecifieerde aan te maken dest FS? Het bron-FS is non compressed...

Zo ver ik weet zal de data dan non-compressed aan komen op het dest FS. Bij een send/receive doe je een 1:1 kopie van het filesystem.

Je zal op het source FS de bestanden dus eerst moeten rewriten zodat ze compressed zijn.

Script maken dat doet:
- File lezen
- File weer weg schrijven

Dan is de source compressed.

[FireDrunk]

Zojuist even opgezocht, het ligt er aan of op het parent filesystem de property specifiek gewijzigd is.

Dus:

Root A - Compressie Uit
Sub filesystem A - Compressie expliciet uit
Sub filesystem B - Compressie expliciet aan
Sub filesystem C - Inherit aan

Root B - Compressie expliciet Aan

ZFS Send Receive -> Sub A van Root A -> Root B blijft compressie dus uit.
ZFS Send Receive -> Sub B van Root A -> Root B blijft compressie dus aan.
ZFS Send Receive -> Sub B van Root A -> Root B veranderd compressie.

[calyptus]

Even info voor mensen die nog iets van Dennisik verwachten, hij is zaterdag overleden door een moto-ongeluk.

CiPHER: speciaal topic geopend omtrent het overlijden van Dennisik: Condoleance DennisIk.

[ Voor 36% gewijzigd door Verwijderd op 12-08-2013 23:28 ]

[FireDrunk]

calyptus schreef op maandag 12 augustus 2013 @ 18:14:
Even info voor mensen die nog iets van Dennisik verwachten, hij is zaterdag overleden door een moto-ongeluk.

Wow, like a bomb shell... Is daar een topic voor?

[DennusB]

calyptus schreef op maandag 12 augustus 2013 @ 18:14:
Even info voor mensen die nog iets van Dennisik verwachten, hij is zaterdag overleden door een moto-ongeluk.

Jezus. Dat meen je niet!! Mag ik vragen hoe je aan die info komt?

[calyptus]

DennusB schreef op maandag 12 augustus 2013 @ 18:24:
[...]


Jezus. Dat meen je niet!! Mag ik vragen hoe je aan die info komt?

ander forum waar we allebei op zaten.

http://forum.dutchbodybui...rust-zacht-maatje-346658/