Het grote ZFS topic

[FireDrunk]

Iemand enig idee hoe je de BTX Loader debugged? Mijn Areca kaart werkt eigenlijk prima, alleen zowel de Intel BIOS als de FreeBSD boot loader kunnen niet overweg met al die boot devices.

Als ik in de controller INT13 support aan zet, probeerd de controller alle devices door te geven als bootable, wat de Intel BIOS niet zo grappig vind. Opgelost door UEFI te gebruiken, dan werkt alles wel. (Wel even ubuntu moeten herinstalleren...)

Nu de FreeBSD VM nog, want deze blijft hangen op het mooie ASCII art logo NA de BTX loader. Hoewel de BTX Loader af en toe ook hangt en sowieso ERG traag is... (soms > 3 minuten...)

Iemand enig idee hoe ik bijvoorbeeld boot devices juist uit kan zetten in die BTX boot loader?

PS: Al deze problemen had ik niet met maar 2 devices aangesloten, dus het ligt verder niet aan de kaart verwacht ik.

[ Voor 7% gewijzigd door FireDrunk op 07-03-2013 23:51 ]

[matty___]

FireDrunk schreef op donderdag 07 maart 2013 @ 23:51:
Iemand enig idee hoe je de BTX Loader debugged? Mijn Areca kaart werkt eigenlijk prima, alleen zowel de Intel BIOS als de FreeBSD boot loader kunnen niet overweg met al die boot devices.

Als ik in de controller INT13 support aan zet, probeerd de controller alle devices door te geven als bootable, wat de Intel BIOS niet zo grappig vind. Opgelost door UEFI te gebruiken, dan werkt alles wel. (Wel even ubuntu moeten herinstalleren...)

Nu de FreeBSD VM nog, want deze blijft hangen op het mooie ASCII art logo NA de BTX loader. Hoewel de BTX Loader af en toe ook hangt en sowieso ERG traag is... (soms > 3 minuten...)

Iemand enig idee hoe ik bijvoorbeeld boot devices juist uit kan zetten in die BTX boot loader?

PS: Al deze problemen had ik niet met maar 2 devices aangesloten, dus het ligt verder niet aan de kaart verwacht ik.

hoeveel devices heb je dan? Heb je ook al de freebsd-stable mailinglist geprobeerd?

[FireDrunk]

12, 10 disks en 2 ssd's. Wel gezocht, en ik vind best wat mensen die problemen hebben met de BTX en zfsloader die traag zijn, maar veel oplossingen worden er niet aangedragen.

Sommigen zeggen dat ze met de upgrade naar 10.0 er geen last meer van hebben.
Maar dat lijkt me een beetje voorbarig icm ZFSguru

[ Voor 86% gewijzigd door FireDrunk op 08-03-2013 10:08 ]

[matty___]

FireDrunk schreef op vrijdag 08 maart 2013 @ 10:07:
12, 10 disks en 2 ssd's. Wel gezocht, en ik vind best wat mensen die problemen hebben met de BTX en zfsloader die traag zijn, maar veel oplossingen worden er niet aangedragen.

Sommigen zeggen dat ze met de upgrade naar 10.0 er geen last meer van hebben.
Maar dat lijkt me een beetje voorbarig icm ZFSguru

kun je in de bios van de areca een optie vinden waarmee de luns al bij het booten worden herkend en die uitzetten.

Dan worden deze pas bij het booten van de kernel gevonden.

[FireDrunk]

De VM moet juist booten van de Areca...

[matty___]

FireDrunk schreef op vrijdag 08 maart 2013 @ 12:20:
De VM moet juist booten van de Areca...

sorry ken je setup niet helemaal en heb geen zin alles terug te lezen.

heb je trouwen als de tip van 10-current geprobeerd? Want als daar iets in zit wat het wel oplost kan dat stuk misschien nog geport worden naar 9

[FireDrunk]

Ik vind het een beetje eng om ZFSguru naar 10.0 te upgraden, er gaan dan vast dingen stuk

Mijn setup:

DQ77MK, 16GB RAM.
Intel Postville 80GB op onboard AHCI controller met Ubuntu 13.04 (dev branch) met KVM.

1 Guest VM met de Areca als passthrough adapter.
op de Areca: 10 * 2TB en 2 * Intel 320 80GB SSD.

De guest moet booten van de SSD's.

[matty___]

FireDrunk schreef op vrijdag 08 maart 2013 @ 12:25:
Ik vind het een beetje eng om ZFSguru naar 10.0 te upgraden, er gaan dan vast dingen stuk

Mijn setup:

DQ77MK, 16GB RAM.
Intel Postville 80GB op onboard AHCI controller met Ubuntu 13.04 (dev branch) met KVM.

1 Guest VM met de Areca als passthrough adapter.
op de Areca: 10 * 2TB en 2 * Intel 320 80GB SSD.

De guest moet booten van de SSD's.

je hoeft toch niets te installeren. boot de usb live disk en kijk of dat goed gaat. Meer hoef je toch niet te doen

en als die toch moet booten van die 2 ssd's. Dan heb je die 10 disks in begin toch helemaal niet nodig voor het booten. Als je plek hebt kun je die op de interne ahci controller zetten en de rest op de areca

[ Voor 15% gewijzigd door matty___ op 08-03-2013 12:30 ]

[FireDrunk]

Maar dan kan ik niet die SSD's native doorgeven aan die VM, dan moet ik emulatie (in de trant van VirtIO ofzo) gaan gebruiken om de SSD's door te geven. En dat wilde ik juist niet

[matty___]

FireDrunk schreef op vrijdag 08 maart 2013 @ 12:43:
Maar dan kan ik niet die SSD's native doorgeven aan die VM, dan moet ik emulatie (in de trant van VirtIO ofzo) gaan gebruiken om de SSD's door te geven. En dat wilde ik juist niet

Dat wist ik niet. en booten vanaf een image dat op de linux host staat? want 2 ssds voor zfsguru lijkt me beetje overkill

[FireDrunk]

Dat zou inderdaad kunnen, maar dan is Root-on-ZFS weer nutteloos.
Bovendien crasht de VM als de SSD waar KVM op draait wegvalt.

De SSD's staan in mirror, en functioneren tegelijkertijd als ZIL en L2ARC.

[ Voor 18% gewijzigd door FireDrunk op 08-03-2013 12:56 ]

[matty___]

FireDrunk schreef op vrijdag 08 maart 2013 @ 12:56:
Dat zou inderdaad kunnen, maar dan is Root-on-ZFS weer nutteloos.
Bovendien crasht de VM als de SSD waar KVM op draait wegvalt.

De SSD's staan in mirror, en functioneren tegelijkertijd als ZIL en L2ARC.

Je data staat toch op de 10 schijven. Dus dat rootonzfs is toch beetje overbodig. UFS met journaled soft-updates heb je eigenlijk voldoende tenzij je iets met snapshots en dat soort dingen wilt gaan doen.

[FireDrunk]

Ben ik het niet mee eens, Root-on-ZFS is toch een bepaalde zekerheid die je hebt. Bovendien zijn ZIL en L2ARC via geemuleerde paden nooit een goed idee.

[matty___]

FireDrunk schreef op vrijdag 08 maart 2013 @ 13:29:
Ben ik het niet mee eens, Root-on-ZFS is toch een bepaalde zekerheid die je hebt. Bovendien zijn ZIL en L2ARC via geemuleerde paden nooit een goed idee.

Welke data bescherm je met root-on-zfs? alleen de freebsd zfsguru installatie en daar schrijf je niet zo gek veel data naartoe. Eens dat je de checksum goodies van zfs niet meer hebt maar dat heeft je KVM host ook niet. dus je loopt bijna hetzelfde risico. Want als ik het goed begrijp loopt je linux host op een single ssd en daarop bouw je dan een zfs instantie.

Zou je niet eerder een ZFS bak moeten hebben die native ZFS draait en die exporteert ZVOLs/NFS naar een andere bak waar de VM's op staan. of praat ik nou onzin?

Waarom de zil op eens een ander path zou moeten hebben is mij niet duidelijk. Als je van een image boot en je de lun detectie bij boot uitzet kun je de ssd's aan de areca laten hangen.

[ Voor 8% gewijzigd door matty___ op 08-03-2013 13:52 ]

[FireDrunk]

Het leuke van Linux, is dat het revert naar een read only file system als je SSD knalt. De processen die draaien zonder lokale disk IO blijven gewoon draaien. Daarmee maak je je ZFS VM dus vrij robuust als het gaat om het crashen van de host. Maar inderdaad, verplicht is het niet.

Ik vond het juist wel tof, dat je zeker wist dat je nooit tegen emulatie problemen aan loopt die mensen veelal hebben met pvscsi, virtio en anderen als het gaat om hun block data.

Dat de KVM BIOS kan booten van een via VT-d doorgegeven kaart mag op zijn minst tof gevonden worden Dat kan (voor zover ik weet) geen enkele andere HyperVisor.

Ik zit er de laatste tijd steeds meer aan te denken om gewoon ZFSonLinux te gaan gebruiken, en mettertijd over te stappen op BTRFS (wat sinds kort ook RAID5/6 support heeft).

Ik snap je zin over ZIL niet zo goed? Ik heb 2 SSD's die allebei een partitie hebben die gemirrored word. Daarnaast hebben ze een ZIL en een L2ARC partitie. Wat heeft dat met paths te maken?

[HyperBart]

Wie neemt er bij zijn volgende ESXi + ZFS build in one dit moederbordje eens?

pricewatch: ASRock 970 Extreme3

http://thehomeserverblog....assthrough-iommu-build-2/

ESXi SATA Passthrough on the ASRock 970 Extreme3

One nice quirk that I have found with the ASRock 970 Extreme 3 is that when you pass through the SATA controller, only 4 of the 5 ports on the board passthrough. The 5th SATA port remains available to the ESXi host for use as a local data store. For me, this is a boon rather than a drawback, since VMs that you passthrough hardware to are not available for VMMotion. So why not store them locally and have ESXi boot off the hard drive? I do have an iSCSI target available for the cluster, also.

[Compizfox]

Wut? Dat bordje heb ik in mijn ESXi server, maar dat wist ik helemaal niet!
Ik heb mijn datastore nu op een losse sil3114. Moet je hiervoor eigenlijk SATA IDE Combined mode juist aan of uit hebben staan? Kan me voorstellen dat dit namelijk de oorzaak hiervoor is.
Die mode zorgt er namelijk voor dat bepaalde poorten AHCI of RAID zijn, en een paar andere weer IDE.

Setup in dat artikel is trouwens bijna precies hetzelfde als wat ik heb.

Achteraf gezien best wel een FFFUUUU-reactie, want ik heb zacht gezegd nogal moeilijk zitten doen om dit probleem, RDMs enzo.

Hoort dit trouwens niet in het Zuinige ESXi-server topic?

EDIT: Dan zou ik dat channel in de vSphere client onder Configuration --> Storage Adapters moeten zien, ook al hangt er geen HDD aan toch?
Dat is niet het geval, ik zie enkel de 4 channels van mijn sil 3114. Maar dat kan misschien dus nog met SATA IDE Combined mode te maken hebben, dat staat nu uit.

[ Voor 135% gewijzigd door Compizfox op 08-03-2013 16:52 ]

[Xudonax]

Ik heb QuickBench eens losgelaten op mijn ZVOL die met iSCSI geëxporteerd word naar mijn Mac (nog steeds voor Final Cut Pro X). De resultaten:

Asynchrone I/O:

code:

Test Cycles: 5 

Transfer Size   Sequential Read   Sequential Write    Random Read      Random Write

   4 KBytes      12.274 MB/Sec     13.747 MB/Sec     12.489 MB/Sec     13.521 MB/Sec
   8 KBytes      18.815 MB/Sec     19.250 MB/Sec     19.657 MB/Sec     19.230 MB/Sec
  16 KBytes      32.893 MB/Sec     21.270 MB/Sec     33.076 MB/Sec     21.212 MB/Sec
  32 KBytes      46.758 MB/Sec     35.623 MB/Sec     47.571 MB/Sec     36.170 MB/Sec
  64 KBytes      64.280 MB/Sec     53.329 MB/Sec     65.267 MB/Sec     53.402 MB/Sec
 128 KBytes      81.306 MB/Sec     71.846 MB/Sec     80.499 MB/Sec     71.530 MB/Sec
 256 KBytes      93.452 MB/Sec     87.215 MB/Sec     92.644 MB/Sec     87.458 MB/Sec
 512 KBytes      100.142 MB/Sec    92.721 MB/Sec     99.775 MB/Sec     92.615 MB/Sec
1024 KBytes      101.880 MB/Sec    95.089 MB/Sec     101.820 MB/Sec    94.841 MB/Sec

Standard Ave     61.311 MB/Sec     54.454 MB/Sec     61.422 MB/Sec     54.442 MB/Sec

Synchrone I/O:

code:

Test Cycles: 5 

Transfer Size   Sequential Read   Sequential Write    Random Read      Random Write

   4 KBytes      12.767 MB/Sec     11.610 MB/Sec     13.410 MB/Sec     11.842 MB/Sec
   8 KBytes      18.213 MB/Sec     17.099 MB/Sec     19.807 MB/Sec     17.091 MB/Sec
  16 KBytes      33.837 MB/Sec     18.406 MB/Sec     34.101 MB/Sec     18.459 MB/Sec
  32 KBytes      47.676 MB/Sec     31.575 MB/Sec     47.855 MB/Sec     31.880 MB/Sec
  64 KBytes      64.610 MB/Sec     48.144 MB/Sec     65.598 MB/Sec     47.991 MB/Sec
 128 KBytes      81.385 MB/Sec     67.331 MB/Sec     81.192 MB/Sec     67.286 MB/Sec
 256 KBytes      93.280 MB/Sec     84.625 MB/Sec     92.766 MB/Sec     82.250 MB/Sec
 512 KBytes      99.701 MB/Sec     90.093 MB/Sec     99.739 MB/Sec     90.361 MB/Sec
1024 KBytes      102.241 MB/Sec    92.819 MB/Sec     101.647 MB/Sec    93.390 MB/Sec

Standard Ave     61.523 MB/Sec     51.300 MB/Sec     61.791 MB/Sec     51.172 MB/Sec

Ik moet zeggen dat deze resultaten me eerlijk gezegd niets tegenvallen, hoewel ik het wél een ietwat vreemd vind dat sequentiële reads en writes net zo snel zijn als de random reads en writes... Dat hoort volgens mij niet echt, of wel?

Ik heb eerlijk gezegd vrij weinig zin om een volledige iozone benchmark te laten lopen, maar als dat betrouwbaardere resultaten oplevert dan is dat misschien wel de moeite waard. Ik ben eigenlijk vooral opzoek naar wat mijn ZFS mirror nu daadwerkelijk kan bereiken over iSCSI Praktisch is het in ieder geval niet meer, want Final Cut Pro draait als een zonnetje nu

[analog_]

Ongerelateerd maar bovenstaande benchmarks tonen dus aan dat er wel degelijk onder gigabit nut is voor SSDs die een gigabit pijp vol aan IO op <64K pompen.

[Compizfox]

Heb je misschien in je iSCSI-target ingesteld dat alle writes synchroon moeten?

[Xudonax]

Euh... Dat zou goed kunnen... De mogelijke opties die ik heb volgens tgtadm zijn:

code:

rdwr    : Use normal file I/O. This is the default for disk devices
aio     : Use Asynchronous I/O
mmap    : Use memory mapping for the backend file

Op dit moment is rdwr in gebruik. Dit is ook "logisch" aangezien ik in principe een disk device aan tgtadm heb gegeven om een iSCSI target van te maken (een ZVOL). Ik zal eens testen met aio en mmap

EDIT: Scratch that, tgtadm staat niet doe dat ik iets anders gebruik dan rdwr. Om eens te kijken naar het verschil tussen mirror en raid-z2 heb ik een ZVOL aangemaakt op mijn raid-z2 set. Eens kijken wat dat oplevert

EDIT2: Dat... scheelt dus echt geen drol

Asynchrone I/O op RAID-Z2:

code:

Test Cycles: 5 

Transfer Size   Sequential Read   Sequential Write    Random Read      Random Write

   4 KBytes      11.630 MB/Sec     13.595 MB/Sec     12.871 MB/Sec     13.235 MB/Sec
   8 KBytes      18.992 MB/Sec     18.982 MB/Sec     19.833 MB/Sec     17.496 MB/Sec
  16 KBytes      32.766 MB/Sec     20.814 MB/Sec     33.741 MB/Sec     20.751 MB/Sec
  32 KBytes      47.448 MB/Sec     34.687 MB/Sec     47.976 MB/Sec     35.623 MB/Sec
  64 KBytes      64.863 MB/Sec     52.866 MB/Sec     65.542 MB/Sec     52.647 MB/Sec
 128 KBytes      81.507 MB/Sec     71.171 MB/Sec     81.076 MB/Sec     71.365 MB/Sec
 256 KBytes      93.053 MB/Sec     86.584 MB/Sec     92.650 MB/Sec     87.190 MB/Sec
 512 KBytes      99.842 MB/Sec     91.465 MB/Sec     99.623 MB/Sec     92.414 MB/Sec
1024 KBytes      102.226 MB/Sec    94.867 MB/Sec     101.709 MB/Sec    94.583 MB/Sec

Standard Ave     61.370 MB/Sec     53.892 MB/Sec     61.669 MB/Sec     53.923 MB/Sec

Synchrone I/O op RAID-Z2:

code:

Test Cycles: 5 

Transfer Size   Sequential Read   Sequential Write    Random Read      Random Write

   4 KBytes      13.257 MB/Sec     11.797 MB/Sec     13.523 MB/Sec     11.767 MB/Sec
   8 KBytes      20.632 MB/Sec     17.252 MB/Sec     20.286 MB/Sec     17.957 MB/Sec
  16 KBytes      34.137 MB/Sec     18.565 MB/Sec     34.767 MB/Sec     19.613 MB/Sec
  32 KBytes      49.290 MB/Sec     32.787 MB/Sec     49.315 MB/Sec     32.988 MB/Sec
  64 KBytes      65.332 MB/Sec     50.121 MB/Sec     66.147 MB/Sec     50.831 MB/Sec
 128 KBytes      81.689 MB/Sec     68.520 MB/Sec     79.699 MB/Sec     68.981 MB/Sec
 256 KBytes      92.589 MB/Sec     84.010 MB/Sec     93.089 MB/Sec     85.033 MB/Sec
 512 KBytes      100.449 MB/Sec    90.779 MB/Sec     99.978 MB/Sec     90.345 MB/Sec
1024 KBytes      102.822 MB/Sec    93.001 MB/Sec     102.350 MB/Sec    92.725 MB/Sec

Standard Ave     62.244 MB/Sec     51.870 MB/Sec     62.128 MB/Sec     52.249 MB/Sec

Ik krijg toch enigszins het idee dat ik een betere testmethode nodig heb dan dit Iemand tips voor een random I/O test programma voor Linux danwel OS X?

[ Voor 81% gewijzigd door Xudonax op 08-03-2013 19:42 ]

[Compizfox]

HyperBart schreef op vrijdag 08 maart 2013 @ 16:03:
Wie neemt er bij zijn volgende ESXi + ZFS build in one dit moederbordje eens?

pricewatch: ASRock 970 Extreme3

http://thehomeserverblog....assthrough-iommu-build-2/

[...]

Verrek, heb nu dus in de BIOS de optie SATA IDE Combined mode aangezet, en inderdaad, er blijven 2 SATA-poorten beschikbaar voor ESXi zelf, als je de controller doorgegeven hebt aan een VM!

Dat maakt de Asrock 970 Extreme3 (natuurlijk ook door de prijs en de aanwezigheid van IOMMU) best wel een ideaal bordje voor ESXi, imho.
Alleen jammer van het hoge stroomverbruik van AMD...

[yeehaw]

Betekent dat dat je drie poorten doorgeeft of vier? Dan zou opzich een AMD build qua aanschaf een stuk goedkoper zijn als je niet meer als 3 disken nodig hebt. Bijvoorbeeld een mirror met hotspare oid.

Met 4 disken zou het helemaal ideaal zijn, omdat je dan zonder extra kaarten een striped mirror kan opzetten.

Ik vraag me alleen af hoe de extra stroomkosten zich verhouden tegen de hogere aanschafprijs van Intel

[Compizfox]

yeehaw schreef op vrijdag 08 maart 2013 @ 21:59:
Betekent dat dat je drie poorten doorgeeft of vier? Dan zou opzich een AMD build qua aanschaf een stuk goedkoper zijn als je niet meer als 3 disken nodig hebt. Bijvoorbeeld een mirror met hotspare oid.

Met 4 disken zou het helemaal ideaal zijn, omdat je dan zonder extra kaarten een striped mirror kan opzetten.

Je hebt 4 SATA-poorten over die je doorgeeft. Uit de manual:

SATA IDE Combined Mode
This item is for SATA3_5 and eSATA3 ports. Use this item to enable or disable
SATA IDE combined mode.

Ik vraag me alleen af hoe de extra stroomkosten zich verhouden tegen de hogere aanschafprijs van Intel

Weet ik niet. Mijn bak (Asrock 970 Extreme3, AMD FX-8120, 4x HDD), doet met 1 HDD actief en 3 spinned down zo'n 78 watt idle.
Ik heb Intel-bakjes gezien die daar minder dan de helft van doen.

[ Voor 9% gewijzigd door Compizfox op 08-03-2013 23:54 ]

[matty___]

Xudonax schreef op vrijdag 08 maart 2013 @ 19:10:
Ik heb QuickBench eens losgelaten op mijn ZVOL die met iSCSI geëxporteerd word naar mijn Mac (nog steeds voor Final Cut Pro X). De resultaten:

welke iscsi client draai je?

[aaahaaap]

Wat is de reden dat mensen hun ZFS server (Solaris, BSD/ZFSGuru, etc) in een VM (zo te lezen eigenlijk altijd VSXi) draaien met passthrough? Welk voordeel heb je hiermee?

[Compizfox]

FreeBSD 9.1 werkt niet met physical RDMs (het beruchte "unsupportable block size 0"-probleem)

[Xudonax]

matty___ schreef op zaterdag 09 maart 2013 @ 01:14:
[...]

welke iscsi client draai je?

GlobalSAN Initiator (deze), de enige betaalbare iSCSI initiator die ik voor OS X kon vinden.... De rest van wat ik kon vinden was minstens 2x zo duur

[yeehaw]

Compizfox schreef op vrijdag 08 maart 2013 @ 23:31:
[...]
Je hebt 4 SATA-poorten over die je doorgeeft. Uit de manual:

[...]


[...]

Weet ik niet. Mijn bak (Asrock 970 Extreme3, AMD FX-8120, 4x HDD), doet met 1 HDD actief en 3 spinned down zo'n 78 watt idle.
Ik heb Intel-bakjes gezien die daar minder dan de helft van doen.

Om hier nog even op terug te komen. Ik heb even twee builds gemaakt met ongeveer vergelijkbare hardware. Echter moet er als het goed is bij de AMD build nog een simpele videokaart bij. Hoe heb jij dat opgelost Compizfox?

AMD-build:

#	Product	Prijs	Subtotaal
1	AMD FX-8350 Boxed	€ 172,95	€ 172,95
1	ASRock 970 Extreme3	€ 66,80	€ 66,80
4	Hitachi Deskstar 5K4000, 4TB	€ 164,94	€ 659,76
1	Fractal Design Define R4 Pearl Black	€ 89,90	€ 89,90
1	Gelid Solutions Tranquillo Rev.2	€ 26,-	€ 26,-
1	Corsair Vengeance CML32GX3M4A1600C10	€ 157,30	€ 157,30
1	Seasonic G-Serie 360Watt	€ 63,99	€ 63,99
1	Samsung 840 series Pro 256GB	€ 199,99	€ 199,99
Bekijk collectie Importeer producten		Totaal	€ 1.436,69

Intel Build:

#	Product	Prijs	Subtotaal
1	Intel Core i5 3470 Boxed	€ 167,-	€ 167,-
1	ASRock B75 Pro3-M	€ 54,90	€ 54,90
4	Hitachi Deskstar 5K4000, 4TB	€ 164,94	€ 659,76
1	Fractal Design Define Mini	€ 78,60	€ 78,60
1	3Ware 3Ware Multi-lane SATA cable CBL-SFF8087OCF-05M	€ 16,94	€ 16,94
1	Silverstone SST-CP06 4x SATA	€ 8,17	€ 8,17
1	Gelid Solutions Tranquillo Rev.2	€ 26,-	€ 26,-
1	Corsair Vengeance CML32GX3M4A1600C10	€ 157,30	€ 157,30
1	IBM ServeRAID M1015 SAS/SATA Controller for System x	€ 118,58	€ 118,58
1	Seasonic G-Serie 360Watt	€ 63,99	€ 63,99
1	Samsung 840 series Pro 256GB	€ 199,99	€ 199,99
Bekijk collectie Importeer producten		Totaal	€ 1.551,23

Dit scheelt in de aanschaf 114 euro en dan moet er nog een videokaart af voor AMD. Dus laten we zeggen dat het 100 euro goedkoper is in aanschaf om een AMD build te maken.

Dat gaat het het qua stroomverbruik als nog niet echt worden. De AMD build gebruikte ongeveer 80 watt idle en de Intel build laten we zeggen ongeveer 40 watt idle. 40 watt x 2 euro per watt per jaar = 80 euro per jaar.

Dan is de Intel build voordeliger als ik dat zo zie. Maar dan is weer de vraag of de octacore FX-8350 sneller is dan de quadcore i5 3470 bij het gebruik van ESXi. Dat kan ik niet zo goed terug vinden.

Dit geld natuurlijk alleen voor een ESXi/ZFS gemixte set-up met vergelijkbare hardware tussen de twee platformen.

Excuus als dit te offtopic is trouwens.

[Xudonax]

Persoonlijk zou ik voor het AMD systeem even een simpele videokaart erin prikken voor de installatie, en die erna weer eruit halen (en terugstoppen in je gewone PC?). Geen reden om een ESXi server constant een videokaart te laten hebben die stroom vreet, wel?

[Compizfox]

@yeehaw: Die AMD-build kan natuurlijk veel goedkoper, als het moet. Je zou ipv een FX-8350 een FX-8120, FX-6100 of FX-4100 kunnen nemen. Bij je Intel build is dit de goedkoopste config met VT-d.

Xudonax schreef op zaterdag 09 maart 2013 @ 09:42:
Persoonlijk zou ik voor het AMD systeem even een simpele videokaart erin prikken voor de installatie, en die erna weer eruit halen (en terugstoppen in je gewone PC?). Geen reden om een ESXi server constant een videokaart te laten hebben die stroom vreet, wel?

Ik heb begrepen dat de meeste desktopmoederborden niet willen POSTen zonder videokaart. Met de Asrock 970 Extreme3 heb ik dat nog niet geprobeerd, ik heb er inderdaad een cheapass los PCI-e videokaartje inzitten.

[enthernal]

bij mijn weten is een videokaart nog noodzakelijk. Er zijn uitzonderingen op de embedded markt, maar bij PC/servers kan je niet zonder enige vorm van videokaart.

[FireDrunk]

Klets, mijn SuperMicro bord heeft zelfs een BIOS optie die "Headless" heet, als ook vele andere borden die ik gezien heb. Die disabled zelfs actief de Intel GPU en boot vrolijk verder.

Vroeger was het veel minder gewoon dan nu, maar er zijn genoeg borden die het tegenwoordig kunnen.
Wel altijd even dubbel checken (maar dat is hetzelfde verhaal als met VT-d, daar moet je ook gewoon 3 keer checken...)

[Compizfox]

Zo'n optie ben ik bij desktopborden nog niet tegengekomen. Mijn Asrock 970 Extreme3 (in mijn server) en mijn Asus P8P67-m Pro (in mijn gamepc) hebben het niet iig.

[Xudonax]

Ik kan me eerlijk gezegd ook niet beter herinneren dan dat borden een "Halt on" optie hebben die je op "None" kunt zetten, en dan gaan ze ook niet klagen over missende videokaarten etc. Niet zo luxe als FireDrunk's SuperMicro bord, maar het functioneerd

[enthernal]

FireDrunk schreef op zaterdag 09 maart 2013 @ 13:56:
Klets, mijn SuperMicro bord heeft zelfs een BIOS optie die "Headless" heet, als ook vele andere borden die ik gezien heb. Die disabled zelfs actief de Intel GPU en boot vrolijk verder.

Vroeger was het veel minder gewoon dan nu, maar er zijn genoeg borden die het tegenwoordig kunnen.
Wel altijd even dubbel checken (maar dat is hetzelfde verhaal als met VT-d, daar moet je ook gewoon 3 keer checken...)

Je haalt wat zaken door elkaar daar. Jouw bord HEEFT wel een GPU, maar je stelt in dat hij die niet gebruikt. Dat is inderdaad steeds vaker mogelijk bij serverborden en dergelijk. Maar dat is iets anders dan een systeem dat helemaal geen GPU heeft. Daar kan je niet eens een bios weergeven om te kiezen

[Verwijderd]

Ik heb regelmatig systemen gebouwd zonder videokaart. Je hoort dan een lange piep en 3x een korte, daarna gaat de POST verder tenzij je 'stop for all errors' in je BIOS hebt ingesteld (waar je F1 of F2 moet drukken enzo).

GPU is dus niet nodig voor de werking van een computersysteem, maar wel erg handig. Soms moet je toch even op de monitor kunnen kijken bij problemen bijvoorbeeld. Nu vrijwel ieder systeem IGP heeft is dit niet echt meer nodig.

aaahaaap schreef op zaterdag 09 maart 2013 @ 01:57:
Wat is de reden dat mensen hun ZFS server (Solaris, BSD/ZFSGuru, etc) in een VM (zo te lezen eigenlijk altijd ESXi) draaien met passthrough? Welk voordeel heb je hiermee?

Eerst dacht ik dat ESXi mensen in staat stelden een workstation van hun server te maken. Maar nee, eigenlijk alleen maar om wat extra VMs redelijk deftig te kunnen draaien. Het ZFS gedeelte is dus maar een klein onderdeel van hun server, waarbij de VMs kennelijk belangrijk genoeg zijn om alles op zijn kop te gooien.

Zelf ben ik iemand die ZFS liever zonder virtualisatie draait, en wellicht dan minder deftige virtualisatie-engine gebruiken voor die paar VMs die men er misschien bij wilt. Dat voorkomt een heeeeeeeeleboel potentiële issues en hoofdpijn. Dat gezegd ben ik niet tegen virtualisatie; maar er is nog een hele lange weg te gaan voordat dit werkt zoals men mag verwachten.

Sommigen kiezen de middelweg door hun VMs in een aparte ESXi server onder te brengen, terwijl de storage op een dedicated ZFS systeem wordt gedraaid. Zo'n setup is minder foutgevoelig en gemakkelijker te onderhouden IMO, maar velen willen geen twee servers.

[HyperBart]

Verwijderd schreef op zaterdag 09 maart 2013 @ 14:53:
Eerst dacht ik dat ESXi mensen in staat stelden een workstation van hun server te maken. Maar nee, eigenlijk alleen maar om wat extra VMs redelijk deftig te kunnen draaien. Het ZFS gedeelte is dus maar een klein onderdeel van hun server, waarbij de VMs kennelijk belangrijk genoeg zijn om alles op zijn kop te gooien.

Nou nou "op zijn kop zetten" is toch ook een heel stukje overdreven vind ik. Je moet gewoon de juiste technologie gebruiken, namelijk VT-d om een kaart door te geven, geen onboard controller. Wie heeft er daar problemen mee onder ESXi? Ik heb nog van niemand negatieve ervaringen gelezen met ESXi + VT-d en ZFS...

ESXi is gewoon een oerstabiel platform en biedt gebruikers de mogelijkheid om geheugen te overprovisioneren, altijd leuk voor labjes. Tel daarbij de heel kleine footprint en het "set and forget" verhaal en dan ga je wel snel overstag. Dat vind ik zo zo zund van Windows met een Hyper-V rol, de lijst met patches, updates en hotfixes die je moet installeren is op zijn zachtst gezegd "ellenlang".

Tweakers moeten gewoon inzien dat ze niet overal kunnen op insnijden om dan een werkende oplossing te krijgen. Een extra kaartje à la M1015 is in mijn ogen gewoon essentieel... Als men dat niet inziet, en men wil voor een dubbeltje op de eerste rij zitten... Tja, dan krijg je vodden...

Dat gezegd zijnde: mijn bordje draait al TIJDEN superstabiel en ik heb geen problemen met ZFSguru als VM en mijn M1015 via VT-d doorgegeven...

[ Voor 14% gewijzigd door HyperBart op 09-03-2013 17:31 ]

[matty___]

Xudonax schreef op zaterdag 09 maart 2013 @ 09:03:
[...]


GlobalSAN Initiator (deze), de enige betaalbare iSCSI initiator die ik voor OS X kon vinden.... De rest van wat ik kon vinden was minstens 2x zo duur

Jammer dat Apple nog steeds geen initiator mee levert. Doet Win7 toch wel beter in dat opzicht.

[Xudonax]

matty___ schreef op zaterdag 09 maart 2013 @ 20:07:
[...]

Jammer dat Apple nog steeds geen initiator mee levert. Doet Win7 toch wel beter in dat opzicht.

Eens. Vanaf Windows XP kun je een gratis initiator downloaden en installeren. Ik was voor OS X eerst aan het kijken of ik iets met XSan kon doen, maar ik had er op dat moment geen enkele ervaring/kennis van. Het is schijnbaar niet bedoeld voor zoiets, en draait alleen over fibre channel

[Dadona]

Verwijderd schreef op zaterdag 09 maart 2013 @ 14:53:
Eerst dacht ik dat ESXi mensen in staat stelden een workstation van hun server te maken. Maar nee, eigenlijk alleen maar om wat extra VMs redelijk deftig te kunnen draaien. Het ZFS gedeelte is dus maar een klein onderdeel van hun server, waarbij de VMs kennelijk belangrijk genoeg zijn om alles op zijn kop te gooien.

Zelf ben ik iemand die ZFS liever zonder virtualisatie draait, en wellicht dan minder deftige virtualisatie-engine gebruiken voor die paar VMs die men er misschien bij wilt. Dat voorkomt een heeeeeeeeleboel potentiële issues en hoofdpijn. Dat gezegd ben ik niet tegen virtualisatie; maar er is nog een hele lange weg te gaan voordat dit werkt zoals men mag verwachten.

Sommigen kiezen de middelweg door hun VMs in een aparte ESXi server onder te brengen, terwijl de storage op een dedicated ZFS systeem wordt gedraaid. Zo'n setup is minder foutgevoelig en gemakkelijker te onderhouden IMO, maar velen willen geen twee servers.

Ik heb drie opstellingen:
-Twee losse systemen, één als NAS (ZFSguru) en één met ESXi en diverse VMs, data op de VM
-Éen all-in one systeem (in aanbouw): ESXi met de NAS (ZFSguru) gevirtualiseerd en andere VMs
-Één all-in-one systeem met ZFSguru als host, VMs middels virtualbox en data op de host
De derde opstelling is momenteel mijn primaire opstelling. Probleem is dat VirtualBox werkt, prima is, maar de prestaties niet echt goed lijken te zijn. Ik moet wel zeggen dat het vertrouwen ook een hele stevige deuk heeft opgelopen dat een VM de hele NAS onderuit kan trekken. Dit maakt dat mijn eerst genoemde opstelling de opstelling is die echt het veiligheidsnet moet vormen en zal blijven.
De andere all-in one is eigenlijk geen eerlijk vergelijk, veel sneller (processorkracht), maar die heeft VT-d, om de schijven door te kunnen voeren naar ZFSguru.

[Verwijderd]

HyperBart schreef op zaterdag 09 maart 2013 @ 17:29:
Nou nou "op zijn kop zetten" is toch ook een heel stukje overdreven vind ik.

Haha, ja dat laatste zinnetje deed het hem hè..

Nee serieus, ik wil ESXi niet afzeiken; voorlopig is dat wel de meest deftige bruikbare virtualisatie. Maar.... klopt het ook weer niet een beetje dat virtualisatie soms best lastig kan zijn met allerlei combinaties van factoren? ESXi wil dit, ZFS wil dat, FreeBSD wil zus en je BIOS wil zo.... Je kunt tegen een heleboel dingen aanlopen die soms heel lastig te identificeren zijn en waar je een tijd lang zoet mee kunt zijn.

Zelf heb ik in mijn eigen ervaring geleerd dat vaak het beter is om zo min mogelijk risicofactoren te hebben binnen je systeem. Dus hoe minder plekken waar iets fout kan gaan, des te beter. De complexiteit is je vijand. Die maakt problemen latig te lokaliseren en te verhelpen. Hoe simpeler het apparaat, des te meer binair de 'werkt wel' / 'werkt niet' verhouding. Met een complex apparaat ligt dat vaak veel subtieler met soms problemen die niet makkelijk te reproduceren zijn.

Ik heb natuurlijk al onderhand best wat users gehad met allerlei problemen. In veel van die gevallen wil je dan kunnen uitsluiten of het aan ESXi ligt bijvoorbeeld. Dan moet je alsnog weer 'native' kunnen draaien zonder virtualisatie.

Maar ik geloof ook best dat het voor heel veel mensen gewoon goed werkt hoor. En vaak als men wat issues heeft, zijn er workarounds (bijvoorbeeld soms een Intel NIC kopen) of andere oplossingen. Echter, aangezien ESXi toch uit de proprietary-wereld komt kan dat soms gaan bijten met open source OS zoals BSD. Zo krijg je compatibliteitsproblemen met RDM en FreeBSD 9.1 maar er zijn meer van datsoort puntjes. Vaak werken combinaties het best die door de primaire achterban van een project wordt gebruikt.

Zelf kijk ik erg uit naar BHyVe maar vooral Xen onder FreeBSD. BHyVe is een nieuwe hypervisor voor BSD platform. Kan nu nog enkel BSD booten en nog erg alpha. Maar een nieuw project specifiek voor BSD is potentiëel interessant. Xen ken je natuurlijk wel en kan ook heel deftige virtualisatie bieden. Maar de ondersteuning van operating systems is nog erg summier. Zo kan FreeBSD nu nog geen Xen host (dom0) zijn, maar daar wordt dus wel aan gewerkt en zou zijn intrede kunnen doen in FreeBSD 10.

Tegen die tijd hoop ik dat virtualisatie en ZFS nóg beter samengaat. Vooral minder problemen en sexy virtualisatie dus het liefst waarbij ZFS op het host systeem kan draaien. Dus wellicht over een jaartje een ZFS + FreeBSD + Xen dom0 + Xen domU guest Windows/Linux en dan kunnen gamen op je ZFS server?

Dadona schreef op zaterdag 09 maart 2013 @ 22:56:
Probleem is dat VirtualBox werkt, prima is, maar de prestaties niet echt goed lijken te zijn. Ik moet wel zeggen dat het vertrouwen ook een hele stevige deuk heeft opgelopen dat een VM de hele NAS onderuit kan trekken. Dit maakt dat mijn eerst genoemde opstelling de opstelling is die echt het veiligheidsnet moet vormen en zal blijven.

VirtualBox crasht trouwens ook wel eens mijn Windows box. Vooral als ik de VM's nachts aanlaat gaat het zo nu en dan eens mis met een klassieke BSOD. Systeem draait verder heel stabiel met honderden dagen uptime.

Kortom, hypervisors die op kernel-niveau draaien hebben de potentie om je hele systeem onderuit te trekken. Dat geldt ook voor ESXi. Maar vast mede vanwege omdat ESXi zo'n lichte hypervisor is en geen volledig OS kan het qua complexiteit beperkt blijven en na veelvuldig testen en feedback is daar nu een vrij stabiel product uitgekomen.

Zodra Xen op FreeBSD werkt lijkt het mij leuk een ZFS benchmarksessie te doen onder diverse hypervisors met dezelfde hardware. Tegen die tijd maak ik daar binnenkort een apart topic voor. Wellicht dat andere mensen ook wel willen mee-benchmarken met een standaard testmethode, dan kunnen we nog een mooie vergelijking maken.

PS. mooie usericon heb je

[FireDrunk]

Ik verwacht ook meer van BeHyver dan van Xen. Xen is een beetje aan het doodbloeden, omdat het gewoon weinig fatsoenlijke management tools heeft. Bovendien ligt de officele Xen installatie CD mijlenver achter met zijn Xen versie als dat de development branches van bijvoorbeeld Ubuntu doen. Het zal dan wel stabiel zijn, maar feature en performance wise mag je nog even wat inleveren.

Wat dat betreft is KVM gewoon echt bloedsnel (en in mijn ervaring ook veel sneller dan ESXi). Een Ubuntu VM boot in KVM in ongeveer 1-1.5 seconde. (Ja dat lees je goed...)

Dat zie ik geen enkel ander platform doen... Maar ook KVM heeft weer een groot nadeel dat het weinig goede management tooling heeft. Red Hat heeft een dijk van een webinterface geschreven met RHEV maar die kost je een support contract...

Wat dat betreft is het integreren van ZFS in virtualisatie inderdaad lastig. Maar aan de andere kant. Als *ALLE* virtualisatieplatformen eens een fatsoenlijke true-AHCI controller zouden implementeren, zou je al die problemen niet meer hebben. Maar mensen staren zich blind op enterprise naampjes als "Paravirtualized SCSI controller" en "LSI SAS Controller". Wat eigenlijk kletskoek is, want waarom zou je in vredesnaam virtueel een SAS controller willen IN je VM?

Die gedachtegang heb ik nooit begrepen... KVM heeft een AHCI implementatie (alsook VirtualBox) maar deze zijn niet zo stabiel als dat je zou willen...

[yeehaw]

Compizfox schreef op zaterdag 09 maart 2013 @ 12:57:
@yeehaw: Die AMD-build kan natuurlijk veel goedkoper, als het moet. Je zou ipv een FX-8350 een FX-8120, FX-6100 of FX-4100 kunnen nemen. Bij je Intel build is dit de goedkoopste config met VT-d.

Ja, maar volgens de tweakers review zijn de 2 processoren die ik gekozen had ongeveer gelijk aan elkaar.

Zie: reviews: AMD FX-8350: hoop aan de horizon?

[FireDrunk]

Maar als we heel eerlijk zijn heb je aan een Celeron G1610 al zat voor een ZFS build. De CPU is niet vaak de bottleneck, alleen als je encryptie of compressie toepast eigenlijk.

Enige reden dat we altijd de specifieke Intel build voorstellen (i3-3330, 3470, of 3550) is VT-d support.
Dat heeft verder niets met performance te maken.

Als Intel een G1610 met VT-d uitbrengt, zou ik zelfs mijn CPU inwisselen waarschijnlijk...

[ Voor 20% gewijzigd door FireDrunk op 10-03-2013 12:02 ]

[Dadona]

Verwijderd schreef op zondag 10 maart 2013 @ 01:20:
[...]
Kortom, hypervisors die op kernel-niveau draaien hebben de potentie om je hele systeem onderuit te trekken. Dat geldt ook voor ESXi. Maar vast mede vanwege omdat ESXi zo'n lichte hypervisor is en geen volledig OS kan het qua complexiteit beperkt blijven en na veelvuldig testen en feedback is daar nu een vrij stabiel product uitgekomen.

Potentie is één, maar dat er nu ook daadwerkelijk mensen tegaan lopen...
Maar goed, VirtualBox en ESXi zijn eigenlijk ook totaal verschillende beestjes. En ik heb verder eigenlijk niets slechts te zeggen over VirtualBox, voor mij heeft het nu toch al jaren goed gewerkt. Maar inmiddels komen er toch wel wat eisen en wensen bij waarin VirtualBox dan toch tekort schiet.

Ik blijf het wel jammer vinden dat ik de Asus C60M1-I (fanless Brazos) het niet weet te redden onder *nix (temperatuur en performance). Anders was het een ideale basis om je NAS en server te splitsen, goedkoop en laag verbruik.

PS. mooie usericon heb je

Het moest gedaan worden. Toch inmiddels wel de stille, betrouwbare kracht.

[Compizfox]

FireDrunk schreef op zondag 10 maart 2013 @ 12:02:
Maar als we heel eerlijk zijn heb je aan een Celeron G1610 al zat voor een ZFS build. De CPU is niet vaak de bottleneck, alleen als je encryptie of compressie toepast eigenlijk.

Enige reden dat we altijd de specifieke Intel build voorstellen (i3-3330, 3470, of 3550) is VT-d support.
Dat heeft verder niets met performance te maken.

Als Intel een G1610 met VT-d uitbrengt, zou ik zelfs mijn CPU inwisselen waarschijnlijk...

Inderdaad, dat is ook mijn punt

Het mooie van AMD is dat die goedkopere Bulldozertjes zoals de pricewatch: AMD FX-4100 Black Edition ook AMD-Vi hebben, terwijl bij Intel VT-d support pas begint bij de pricewatch: Intel Core i5 3330 Boxed (zie prijsverschil)

[FireDrunk]

Maar de moederborden met amd-vi support zijn niet echt goedkoper dan intel varianten...

[Compizfox]

Nee dat klopt, zowel voor Intel als AMD geldt dat ook budgetbordjes het wel hebben. (niet allemaal, maar ze zijn er wel)

Voor Intel heb je bijvoorbeeld de pricewatch: ASRock B75 Pro3-M
En voor AMD de pricewatch: ASRock 970 Extreme3, en er was er ook nog één van Gigabyte als ik me niet vergis.

[Mafketel]

Ben bezig met een migratie van opensolaris naar zfsguru... En dat gaat niet helmaal soepel.
Het lijkt erop omdat het een amd platform is (sempron140) dat ik acpi throtling moet uitzetten. Anders blijft dat ding na enige tijd (30s tot 10minuten) hangen.
oftewel deze variabele zetten tijdens de boot en als je dan draait in je loader.conf het altijd uitzetten.
hint.acpi_throttle.0.disabled= 1

Waarbij ik mij dus het volgende ging afvragen.
Je hebt de boot gpt partitie, en een boot directory onder je filesysteem. Hoe zijn deze aan elkaar gerelateerd?

Leest de bootcode die in de bootgpt parttitie staat de loader.conf en andere dingen uit de boot directory onder het filesysteem?

Of is de boot dir een "link" naar de bootgpt parttitie?

of nog wat anders, zoals bij het afsluiten een sync?

anyway, problem solved for now, nu op naar alle services, users en andere dingen die op de opensolaris server draaien ook op freebsd zien te laten werken.

p.s. hij throttled overigens nog wel volgens de status pagina

64-bit single core AMD Sempron(tm) 140 Processor - Running at 800 MHz
( scales from 800 MHz to 2700 MHz )

[ Voor 9% gewijzigd door Mafketel op 10-03-2013 15:01 ]

[sloth]

Hoe zit het eigenlijk met de ontwikkeling van ZFSGuru?

Op het forum zie ik dat jullie nieuwe services beschikbaar stellen, in totaal 52.
Toegegeven, er zitten interessante nieuwe services bij, maar ik begrijp niet waarom jullie je op dit soort 'randactiviteiten' richten als de 'core' nog veel verbetering kan gebruiken die m.i. prioritair zijn.
2 dingen waar ik spontaan aan denk: een embedded release en beter rechtenmanagement voor SMB shares.

[FireDrunk]

CiPHER heeft ooit eens gezegd volgens mij, dat services meer is waar mensen op zitten te wachten.
Het word daarmee meer een concurrent van FreeNAS en Nas4Free.

[Verwijderd]

Services zijn inmiddels geen randactiviteiten meer, maar een kernargument van ZFSguru. ZFSguru wil meer zijn dan enkel een 'saaie NAS' maar meer een modulair multi-purpose server OS. De toegankelijkheid van (grafische) services is één van de manieren waarop ZFSguru zich probeert te onderscheiden.

Het werk zit hem ook niet in de services zelf, maar in de build environment die nodig is om dat soort services van de band te laten rollen. Zaken als dependencies, buildscripts, uploadscripts, guru-database management moest allemaal ontwikkeld worden en bijgeschaafd.

Op dit moment is Jason nog bezig met het bijschaven van de grafische services. Met name wordt het draaien van een grafische schil veel lichter met veel minder packages benodigd. De dependencies worden ook aangepakt. En dan komen er nieuwe builds voor 9.0, 9.1 en 10.0.

Daarnaast was Jason al heel ver met de volgende web-interface; beta9. De core features die deze release zo bijzonder maken - drag and drop Samba usermanagement - zijn al af en werken volgens mij prima. In de samba backend moet nog wat dingen gebeuren maar deze release kun je wel binnen een maand verwachten.

Na de beta9 is de 0.2 final in zicht. Daar is Jason ook mee bezig, met het bouwen van een nieuwe website en verbeteringen aan het forum, wiki, bugreporting enzovoorts zou het project en de community ook beter voorzien moeten worden.

Maar de echt grote plannen vind ik het meest interessant, daar kan of mag ik nog niet teveel over zeggen.

[Mafketel]

Bovendien rechten managment voor smb shares lijkt mij beter te regelen door windows tools of swat of samba4 te installeren.
Buiten 3tb boot drive en oracle is samba4 een reden voor mij om zfsguru eens te proberen.
Overigens heb ik lang lang geleden(2006) een tijdje een bsd server gedraaid.

[FireDrunk]

Niks 'mogen' zeggen over features, is echt zo'n kul, dat stamt uit de tijd dat je dat niet deed omdat andere bedrijven dan je ideeën gingen jatten. Maar in een tijd van open sources software is het juist goed om je ideeën te spuien, dan kunnen mensen uit de community juist goede inbreng leveren over hoe services/features er uit moeten zien.

Als je features pas op het laatst bekend maakt, maak je het stereotype nerd alleen maar erger.

Iemand die op zijn zolderkamertje zit te verzinnen hoe software van anderen er uit moet zien, zonder met de buitenwereld te communiceren.

Maak nou gewoon een goede roadmap en zet deze tot versie 1.0 gewoon online. Bijschaven kan altijd...

/rant

[FDMK]

Waar zfsguru zich imo negatief in onderscheid is het niet bieden van AD integratie. Dat zou het samba rechtenbeheer toch echt veel makkelijker maken. Zeker wanneer je jezelf als concurrent van freenas en nas4free wegzet.

[ Voor 19% gewijzigd door FDMK op 10-03-2013 16:17 ]

[Verwijderd]

De roadmap met features komt gewoon online, die had ik hier al eens gepost trouwens:
Verwijderd in "Het grote ZFS topic"

En er zijn redenen om nog niet alle kaarten op tafel te gooien. Het gaat daarbij heus niet om gewone features maar meer een richting/concept.

Zelf vind ik vooral interessant die features die de community in staat stellen om aan ZFSguru verder te werken. Zo is het de bedoeling dat je in ZFSguru zelf bijvoorbeeld services kunt ontwikkelen, panels kunt schrijven, vertalingen maken, nieuwe themes ontwikkelen maar vooral ook documentatie aanvullen. Kortom, dan is het makkelijker om wat terug te doen voor ZFSguru in de vorm van kleine updates. Net zoals wikipedia of zelfs tweakers.net pricewatch fungeert: toch minstens een groot deel van alle wijzigingen komen niet van de crew maar van de leden.

[Dadona]

Ik snap jouw opstelling wel FireDrunk, maar draai het eens om. Als je openheid van zaken geeft over de toekomst dan is het ook nooit goed. Dan gaan mensen ook voortdurend zeuren over wanneer feature X uit 0.8.2 nu eindelijk komt, of die niet naar voren gehaald kan worden, ..

[Verwijderd]

Ik wil FireDrunk ook wel begrijpen. Op dit moment kan en doet de community van ZFSguru nog heel weinig en dat is zonde. Meer betrokkenheid betekent ook dat ZFSguru een nieuwe dimensie krijgt waarin de community serieus wordt genomen en mee kan beslissen over sommige zaken.

Aan de andere kant; ZFSguru is geen project zoals FreeNAS waar een heel team en een bedrijf daarachter is verbonden. Mensen die in loondienst zijn en een flinke duit centen hebben om een project uit de grond te timmeren. ZFSguru is het tegenovergestelde hiervan.

Maar is dat niet vreemd, dat een enkel persoon (Jason; die trekt toch echt de kar van ZFSguru) zomaar een heel team voorbij kan streven op bepaalde punten? Jullie draaien vast geen ZFSguru omdat het zo slecht is vergeleken met FreeNAS. Kennelijk kan ZFSguru zelfs nu al voor de eerste stabiele release al best wat mensen binden door de unieke opzet, unieke features en in mijn ogen goed toekomstperspectief. Bij FreeNAS weet je wat je krijgt: een zeer goed uitontwikkeld maar eigenlijk ook vrij ambitieloos OS. Meer van hetzelfde; je weet wat je krijgt. FreeNAS krijgt dan niet de bijzondere features die ZFSguru wel heeft. FreeNAS werkt met DJango en NAS4Free werkt met NanoBSD. Beide ben ik niet kapot van. ZFSguru heeft eigenlijk alles zelf gedaan: zelf een smb.conf parser, een rc.conf parser, istgt.conf parser en ga zo maar verder. Alles aan ZFSguru is zelf ontwikkeld hoofdzakelijk door één person. Dan vind ik dat toch zeker knap en hoewel dat ook nadelen heeft, betekent het wel dat Jason echt wel wat kan en best goede ideeën heeft over hoe iets ontworpen zou moeten worden.

Wat FireDrunk zegt over in een donker kamertje aan een project werken; is dat niet zo de meeste grote projecten van de grond komen? Dat er toch een kerngroep is of zelfs gewoon lead-developer, die zich in redelijke stilte ontfermt over de écht grote features, terwijl de rest zich over de details mag bemoeien? Of wil je zeggen dat de kern van ZFS ook open en bloot in de community is ontwikkeld? Volgens mij is dat niet zo; men ontwikkeld het in klein gezelschap en via een blogpost mag de buitenwereld er kennis van nemen. Die kernfeatures en fundamentele pijlers wil je niet door teveel mensen laten uitvoeren; dan krijg je misschien verwatering. Misschien is het beter de kern van een project door een klein groepje uit te laten voeren.

Dat gezegd: ik en zeker ook Jason staan zeker open voor feedback van anderen. Dus zet vooral uiteen hoe jij graag wilt welke richting ZFSguru naartoe gaat. Ik ben benieuwd.

[analog_]

Jij kent je publiek beter dan ik, maar reken er maar niet op de community veel opneemt. Je krijgt online van 1% bezoekers reacties (forum/comments) een nog kleiner deel zal willen werken aan zfsguru (ie. BSD wat een enkeling kent). Degene die de skillset hebben zullen immers zeer waarschijnlijk liever het zelf DIY vanaf freebsd vanilla.

[Verwijderd]

Volgens mij hebben jullie ook wel de skills, maar toch draaien velen van jullie een kant en klaar NAS OS. Waarom is dat?

Je hebt natuurlijk wel gelijk dat de community niet zomaar aan core features gaat werken; maar je kunt helpen op vele manieren. Een how-to schrijven over hoe je jouw ZFSguru server gebruikt of hebt opgezet bijvoorbeeld is enorm nuttig en best goed te doen zoals VictorB heeft laten zien. Maar ook het meeschrijven van documentatie is iets wat community heel goed kan. Een wiki aanvullen met specifieke informatie. Maar ZFSguru wil juist de kant op van geïntegreerde documentatie. Daar zijn ook wat wilde ideeën over. Bijvoorbeeld dat je via de ZFSguru web-gui de help pagina's kunt aanvullen of comments kunt plaatsen - in elk geval iets in die richting. Dat is best leuk want al die kleine toevoegingen van iedereen maakt toch bij elkaar wel een belangrijke toevoeging.

Wat jij zegt is weer het tegenovergestelde wat ik hoor van anderen, dat ZFSguru veel meer open source moet worden en meer een community project waarbij er geen centrale leiding meer is. Dat gaat denk ik niet goed werken; omdat het ontwikkelen van ZFSguru core features niet iets is waar veel mensen affiniteit voor hebben laat staan de tijd en toewijding die hiervoor nodig is. Ik ben in elk geval erg blij dat Jason met zijn drive aan ZFSguru blijft werken, dan weet je in elk geval dat je nog meer mooie dingen kunt verwachten in de toekomst. Wat kunnen we nou van FreeNAS of NAS4Free verwachten? Wees eerlijk. Ik denk meer van hetzelfde: goed uitontwikkelde kernfeatures maar geen echte ambities. Bovendien gebouwd rondom frameworks die redelijk gedateerd zijn, terwijl ZFSguru eigenlijk alle kanten op kan.

Ik heb in elk geval nog geen spijt van mijn bijdragen aan ZFSguru. Ik vind het enorm gaaf die kleine rebelse projecten met veel potentie. Beter dan de logge projecten die redelijk ambitieloos voortborduren op wat ze al hebben, maar de kern blijft hetzelfde met alle inherente nadelen. Ik vind FreeNAS persoonlijk niet 'sexy'. Hoe denken jullie hierover?

[Compizfox]

-

[ Voor 98% gewijzigd door Compizfox op 10-03-2013 20:15 ]

[aaahaaap]

Dadona schreef op zaterdag 09 maart 2013 @ 22:56:
[...]
Ik heb drie opstellingen:
-Twee losse systemen, één als NAS (ZFSguru) en één met ESXi en diverse VMs, data op de VM
-Éen all-in one systeem (in aanbouw): ESXi met de NAS (ZFSguru) gevirtualiseerd en andere VMs
-Één all-in-one systeem met ZFSguru als host, VMs middels virtualbox en data op de host
De derde opstelling is momenteel mijn primaire opstelling. Probleem is dat VirtualBox werkt, prima is, maar de prestaties niet echt goed lijken te zijn. Ik moet wel zeggen dat het vertrouwen ook een hele stevige deuk heeft opgelopen dat een VM de hele NAS onderuit kan trekken. Dit maakt dat mijn eerst genoemde opstelling de opstelling is die echt het veiligheidsnet moet vormen en zal blijven.
De andere all-in one is eigenlijk geen eerlijk vergelijk, veel sneller (processorkracht), maar die heeft VT-d, om de schijven door te kunnen voeren naar ZFSguru.

Is je hele host (ZFSguru dus in dit geval) onderuit gegaan door een Virtualbox guest? Wat gebeurde er precies? Dat is namelijk niet echt wenselijk

FireDrunk schreef op zondag 10 maart 2013 @ 10:42:
Wat dat betreft is KVM gewoon echt bloedsnel (en in mijn ervaring ook veel sneller dan ESXi). Een Ubuntu VM boot in KVM in ongeveer 1-1.5 seconde. (Ja dat lees je goed...)

Dat zie ik geen enkel ander platform doen... Maar ook KVM heeft weer een groot nadeel dat het weinig goede management tooling heeft. Red Hat heeft een dijk van een webinterface geschreven met RHEV maar die kost je een support contract.../quote]
Ik heb dezelfde ervaring met KVM, stukken sneller dan Virtualbox/Hyper-V, enkel ESXi heb ik nog nooit geprobeerd.

Wat voor soort interface zou je willen? virsh/virt-manager op Linux werkt perfect. Alleen integratie met ZFS is er niet (wel met LVM op Linux), mis je dat?
SmartOS heeft hier vmadm voor, wat wel integreert met ZFS.

FireDrunk schreef op zondag 10 maart 2013 @ 10:42:
Wat dat betreft is het integreren van ZFS in virtualisatie inderdaad lastig. Maar aan de andere kant. Als *ALLE* virtualisatieplatformen eens een fatsoenlijke true-AHCI controller zouden implementeren, zou je al die problemen niet meer hebben. Maar mensen staren zich blind op enterprise naampjes als "Paravirtualized SCSI controller" en "LSI SAS Controller". Wat eigenlijk kletskoek is, want waarom zou je in vredesnaam virtueel een SAS controller willen IN je VM?

Die gedachtegang heb ik nooit begrepen... KVM heeft een AHCI implementatie (alsook VirtualBox) maar deze zijn niet zo stabiel als dat je zou willen...

Dit snap ik niet helemaal Wat zou het voordeel zijn van een degelijke AHCI-controller in alle virtualisatieplatforms?

[edit: typo]

[originng]

FireDrunk schreef op zondag 10 maart 2013 @ 10:42:
Maar ook KVM heeft weer een groot nadeel dat het weinig goede management tooling heeft. Red Hat heeft een dijk van een webinterface geschreven met RHEV maar die kost je een support contract...

De upstream versie van RHEV heet oVirt en draait offcieel op Fedora en officieus op CentOS. Is op het moment bij versie 3.2 en heeft een zogenaamde All-In-One oplossing waarbij managment en VMHost gecombineert zijn. Komt zo een 3.2.x patch release en dan hopelijk ook officieel support voor el6 naast F18.

Zie verder ook http://www.ovirt.org

Joop

[Compizfox]

aaahaaap schreef op zondag 10 maart 2013 @ 20:19:
[...]
Dit snap ik niet helemaal Wat zou het voordeel zijn van een degelijke AHC-controller in alle virtualisatieplatforms?

Dat guests er goed mee overweg kunnen

Als je in ESXi RDM gebruikt om je HDDs door te geven aan je storage-guest, emuleert ESXi 5.1 een LSI MTP SAS controller. FreeBSD 9.1 kan daar dan weer niet goed mee overweg.

[Midas.e]

Ikzelf ga binnekort met ZFSGuru een simpele san voor kantoor klaar maken. Alleen kijk ik nogal tegen alle extra services van ZFSGuru op. Ik had liever ZG clean en simple gehad voor de job van een SAN/NAS device. Nu wil ik eigelijk het liefst een schone build gaan maken van ZFSGuru met alleen de basis onderdelen erin voor een SAN. Ervaring met het builden in freebsd heb ik ivm PFsense. maar ik zie niet echt veel informatie op de site voor het maken van een build omgeving van ZFS etc.

[Compizfox]

Je hoeft die services natuurlijk niet te installeren als je ze niet nodig hebt.

[Verwijderd]

Dat is nu juist het hele punt, andere NAS platforms komen volgens mij wel met een heleboel voorgeïnstalleerd. Bij ZFSguru eigenlijk alleen Samba en een webserver. De rest moet je met de services addons doen, zoals iSCSI, FTP, Appleshare enzovoorts. Zo hoef ik dat mac-spul niet te draaien omdat ik geen mac heb.

Gebruik wel een firewall zoals pf. Die is heel gemakkelijk te gebruiken in FreeBSD en valt toch onder de beste FOSS packet-firewall voor UNIX. Zelfs traffic shaping zit al in de kernel van ZFSguru dus je kunt het zo gaan gebruiken. Beperk dan ook poort 80 of althans de poort waar lighttpd op draait tot een of meerdere vertrouwde IP adressen.

@aaahaap: een AHCI controller emuleren is natuurlijk veel beter omdat AHCI een spec is en geen specifieke drivers nodig heeft. Zo kun je om die reden gewoon TRIM en APM functies gebruiken, maar nog belangrijker heb je dan geen gezeik met problemen zoals nu met ESXi + RDM + FreeBSD 9.1.

Zoals Firedrunk uitlegde heb je dan het probleem dat de geëmuleerde firmware van de geëmuleerde LSI SAS controller door ESXi een lagere versie heeft dan de versie 14 firmware die FreeBSD nieuwe 'mps' driver verwacht. Die mps driver is aangevuld/herschreven met hulp van LSI en geldt als vrij officiëel nu, maar vereist wel dat je de nieuwste firmware op je LSI SAS controller draait. Dat gaat dus niet lukken met dergelijke emulatie.

Ook hier geldt weer mijn principe: hoe minder complex, des te minder kans op irritante problemen.

[FireDrunk]

@Dadona, als developers daar zich iets van aan trokken waren er wel meer features in sommige producten.. Er word echt al heel lang in de ESXi community geschreeuwd om meer hardware support en het booten/draaien van VM's vanaf USB, en dat komt ook nooit, dus ach, het is maar hoe je dev's in elkaar steken.

@CiPHER en Dadona, ik bedoel absoluut niet met mijn post dat ik vind dat er meer mensen aan ZFSguru werken, ik vind het alleen belangrijk dat features zo ontworpen worden (qua look-and-feel en besturing) dat ze ook echt aansluiten bij wat de community graag wil.

Ik vind log management erg belangrijk, snel kunnen vinden wat je nodig hebt, gebruik ik de log manager van ZFSGuru? Niet echt, ding kan niet veel...

Ik vind het kunnen inzien van real time proces statistieken zien erg belangrijk, gebruik ik die feature in ZFSguru? Nee, want je kan niet sorteren, filteren of uberhaupt veel zien, want je moet vaak zelf de pagina refreshen.

Ik vind real time IO performance statistieken inzien belangrijk, gebruik ik die feature in ZFSguru? Nee want dat ding levert niet echt wat je wil weten (per pool, niet per disk) en refresht gruwelijk iritant de hele pagina. Jongens het is 2013... jQuery + AJAX zijn de standaard... Maak dat ding even asynchroon

De Samba instellingen worden VOOR je gekozen, ipv dat je tijdens de installatie wizard iets te kiezen hebt. Je hele pool word 777 gechmod, dat kan je ook niet kiezen.

Allemaal voorbeelden van features/services/ontwerpkeuzes die genomen zijn door 1 dev, met 1 visie.
Bij dat soort dingen moet je echt de community laten spreken, en daaruit de beste ideeen pakken en DIE op je zonderkamertje gaan zitten bouwen.

@aaahaaap, oVirt heeft nog steeds niet dezelfde web interface als RHEV volgens mij? En bovendien heeft oVirt ook een kernel versie uit het jaar nul volgens mij. Schijnbaar is het nog steeds echt te moeilijk om een recente kernel te implementeren. Ik bedoel, zelfs de LTS versies van Ubuntu zitten op 3.2.0 en de recente builds op 3.5.0. Gentoo werkt al jaren met een rolling release, en dat werkt ook zo prima.

@CiPHER
Een van mijn grootste ergernissen op dit moment is het niet fatsoenlijk kunnen patchen en upgraden met ZFSguru. Wat je eigenlijk wil, is een snapshot kunnen maken van je rootpool, alle nieuwste versies van de packages installeren, en een soort self-test runnen. Als die checks allemaal groen geven (automatisch danwel handmatig) verwijder je je snapshot en worden de wijzgingen permanent.

Security zoals die nu in ZFSguru zit is outdated (http ipv https), vreemd (ssh user -> su), en onlogisch (op ip basis? mijn router staat al geen 192 vanaf internet toe...).

Als je zegt dat ZFSguru kaal en zonder services komt, heb je zeker gelijk, en dat is ook zeker goed. Een nadeel is weer, dat je niet de native upgrade systemen van FreeBSD kan gebruiken om nieuwe versies van packages kan installeren... Een grote ergernis is altijd dat SabNZBd de hele tijd zeurt dat er een update is, maar ik hem niet kan updaten...

Verhaal over AHCI: Alles alle virtualisatieplatformen eenzelfde True-AHCI controller implementeren zijn VM's (inclusief ZFS-wise) transporteerbaar tussen platformen zonder dat enige vorm van diskproblemen ala corruptie en/of incompatibiliteit optreden.

KVM heeft een true-AHCI implementatie, maar die heb ik zelf alleen getest in een oudere kernel (3.2.0) en die schijnt toch erg goed te zijn in de nieuwere kernels (3.8.0)

Ik zit er zelf aan te denken om een minimalistische Gentoo installatie te maken met daarop een miniscule KVM schil voor VM's. Waarom? Scheiding van applicaties en verantwoordelijkheden. Zo wil ik geen Sickbeard, CouchPotato, Headphones en Sabnzbd op mijn ZFSguru draaien, teveel invloed en teveel dependancies die ik niet wil installeren op iets cruciaals als een storage OS. Bovendien is er geen autoupdater voor FreeBSD, en onder Ubuntu zijn er gewoon voor al die packages repo's en worden ze dus omdat Ubuntu zelf al automatisch update, automatisch geinstalleerd.

Vandaar minimaal 1 VM voor al die download troep. 2e verhaal is, dat ik vaak af en toe een OS test, ik heb een ESXi Opteron bakje staan, maar die is 80% van de tijd niet eens aangesloten omdat ik hem alleen tijdens LAN parties gebruik als server. Als er dus een keer een nieuwe versie van een OS is, test ik deze vaak uit op mijn server.

Verder wil ik ook een monitoring oplossing in huis hebben voor wat rapportage van gebruik van storage en netwerk op mijn FreeBSD VM. Ook hier geld weer, dit wil ik eigenlijk gescheiden houden van het OS.

PS:
@CiPHER:
Come to think of it, als je een lijst met dingen hebt die perse moeten werken voor ZFSGuru, wil ik best een self-check script schrijven in bash

[EnerQi]

Allemaal voorbeelden van features/services/ontwerpkeuzes die genomen zijn door 1 dev, met 1 visie.
Bij dat soort dingen moet je echt de community laten spreken, en daaruit de beste ideeen pakken en DIE op je zonderkamertje gaan zitten bouwen.

Krijg je dan niet het probleem dat je een onsamenhangend geheel krijgt? jij wil logs, iemand anders wil downloaden en een andere wil virtualisatie. Sowieso geldt dat bij een rewrite van het programma (elk programma) je het anders aanpakt of schrijft . Iets waar ik op aan het wachten ben, is task manager (0.6 ZFSguru). Kan het nu in FreeBSD? jazeker maar mij ontbreekt de knowhow om dit te doen (en zo dringend is het ook niet )

De ontwikkeling zou sneller mogen gaan, maar Rome is ook niet in 1 dag gebouwd. We kunnen en moeten niet alles tegelijk willen.

[FireDrunk]

True that, maar als je Rome wil bouwen moet je toch echt met meer dan 1 (a 2) dev's bouwen

En juist iets simpels als een goede log viewer kan je best uitbesteden aan iemand uit de community denk ik dan...

Ik heb mij al eens verdiept in de code van ZFSguru om mee te kunnen helpen, maar dan komt mijn volgende ergernis (waar ik niet van hou om van de daken te schreeuwen).

De code is een puinhoop en absoluut niet volgens de huidige standaarden geschreven.
Het zit procedureel in elkaar, en kent eigenlijk geen Object Georiënteerde structuur.
Het is een samenhangsel van pagina's en functie classes die elk wat kunstjes kunnen.

Er zit geen flow in het programma, en het is daardoor niet echt onderhoudbaar of snel te snappen door een derde partij. Hoeveel CiPHER en Jason ook aan die structuur gehecht zijn, het is niet een structuur waar je veel dev's mee uitnodigt om aan mee te werken.

[ Voor 101% gewijzigd door FireDrunk op 10-03-2013 23:36 ]

[Dadona]

aaahaaap schreef op zondag 10 maart 2013 @ 20:19:
[...]
Is je hele host (ZFSguru dus in dit geval) onderuit gegaan door een Virtualbox guest? Wat gebeurde er precies? Dat is namelijk niet echt wenselijk

Ik ben er persoonlijk niet tegenaan gelopen, maar wel twee anderen in deze topic, zie: Aimtastic in "Het grote ZFS topic"

FireDrunk schreef op zondag 10 maart 2013 @ 22:50:
@Dadona, als developers daar zich iets van aan trokken waren er wel meer features in sommige producten.. Er word echt al heel lang in de ESXi community geschreeuwd om meer hardware support en het booten/draaien van VM's vanaf USB, en dat komt ook nooit, dus ach, het is maar hoe je dev's in elkaar steken.

Je hebt aantrekken en er iets mee doen. Het ging mij erom dat sommigen zoveel mogelijk willen proberen dat ze zich er iets van kunnen aantrekken. Maar goed, dit schiet verder niet op, generaliseren enz. We moeten het hooguit over Jason en CiPHER hebben.

Iets anders... We hebben het nu al meerdere malen over ECC gehad en de meningen slaan misschien wat meer naar 'ben niet echt zeker van het nut' en 'je doet het echt om het af te maken'. Kunnen we eens cijfertjes produceren?
Juist met ZFS belast je je geheugen extreem. Dus dan kom je sneller in een situatie dat ECC uitmaakt. Is er een manier dat ECC gevalletjes worden gerapporteerd?

[ Voor 21% gewijzigd door Dadona op 10-03-2013 23:44 ]

[Verwijderd]

ik vind het alleen belangrijk dat features zo ontworpen worden (qua look-and-feel en besturing) dat ze ook echt aansluiten bij wat de community graag wil.

Aansluitend op EnerQi: iedereen wil wat, inderdaad. Maar is het dan zo dat ZFSguru een kant op gaat die mensen niet willen?

Een overzicht van ZFSguru development
Eerst moest de basis goed zijn; disk handling, een welcome wizard, filesystem management. Daarna - toen het project nog grotendeels op HardOCP plaatsvond - wilde men benchmarking. Dus ZFSguru kwam met de Advanced Disk Benchmark die pool configuraties test en daar een grafiek van maakt. Daarna is het project volwassener geworden met een eigen website, en de web-interface geheel herschreven met een totaal nieuwe opzet en eigen stijl. Dit omdat hij niet wilde werken aan iets wat ooit toch weer herschreven zal moeten worden.

Men wilde extra functionaliteit zoals iSCSI en AppleShare, maar Jason wilde geen bloated OS maar iets elegants. Dus eerst veel aandacht aan een service infrastructuur en build management om dit alles ook zonder extreem veel moeite te kunnen produceren elke keer. Dit proces is nog steeds niet helemaal afgerond, maar wel voor 90% inmiddels. Zo kan het updaten van de database nu via een eigen web-interface en komt er ook een unified 'gurudb' waar alle remote data in is verwerkt, in plaats van aparte files.

En nu we weer in het heden spreken, kijken we naar de features die op de roadmap staan: migratie van settings als je een nieuwe systeemversie wilt proberen. Lijkt me een cruciale feature? Gaan veel mensen gebruiken en is ook de basis van de 0.3 feature: de embedded distributie op USB-stick met weinig writes en toch een grafische desktop met tig services kunnen draaien. Daar heb je een goede infrastructuur voor nodig en dat soort dingen ontwikkelen en bedenken kost natuurlijk ook tijd. Maar liever door één goed iemand dan een zwak team die maar wat doet wat makkelijk is.

Kortom, ik zou wel denken dat ZFSguru tot nu toe en in de toekomst werkt aan zaken die de community wilde. De enige controversiële feature is misschien de grafische services. Maar dat dit werkt is vooral omdat de onderliggende build infrastructuur goed op orde is met geneste dependencies en alternatieve dependencies en wat niet al. Toch gebruiken vrij veel mensen de grafische services, aangezien ZFSguru al over de 1.5TB dataverkeer per maand gaat. Dus nu werken aan lichtere grafische packages en dat is pretty much waar we nu zitten. De nieuwe 9.0, 9.1 en 10.0 builds komen uit en daarna wordt de beta9 afgebouwd. Dan zitten we weer een maand verder.

True that, maar als je Rome wil bouwen moet je toch echt met meer dan 1 (a 2) dev's bouwen

Hm, vaak zijn grote projecten toch grotendeels met de inzichten van één iemand gevormd. Denk aan Star Trek, denk aan Steve Jobs, ga zo maar door. Leuk voorbeeld is bijvoorbeeld Zelda waar die Japanse developer toch veel ideeën in heeft verwerkt en toch wel de grootvader is van de series. Hij deed uiteindelijk nog maar 33% ofzoiets terwijl de rest van het team de rest deed. Maar het zijn altijd wel de cruciale punten waar zo'n grandfather dan aandacht aan besteed. Kortom, ik zou willen stellen dat je met één of twee goede developers echt ver kunt komen. Niet dat ik mijzelf daar onder reken, overigens, en Jason valt ook niet in het profiel van een doorsnee programmeur - maar wel in de rol als ontwikkelaar. En daar ligt een subtiel verschil. Ik vind dat hij mooie nieuwe inzichten heeft.

Want verklaar mij eens hoe een project wat uit het niets in een paar jaar een project uit de grond stampt wat kan concurreren met grote commerciële teams? Dat vind ik vrij bijzonder.

[Verwijderd]

Ik vind log management erg belangrijk, snel kunnen vinden wat je nodig hebt, gebruik ik de log manager van ZFSGuru? Niet echt, ding kan niet veel...

Ik vind het kunnen inzien van real time proces statistieken zien erg belangrijk, gebruik ik die feature in ZFSguru? Nee, want je kan niet sorteren, filteren of uberhaupt veel zien, want je moet vaak zelf de pagina refreshen.

Ik vind real time IO performance statistieken inzien belangrijk, gebruik ik die feature in ZFSguru? Nee want dat ding levert niet echt wat je wil weten (per pool, niet per disk) en refresht gruwelijk iritant de hele pagina. Jongens het is 2013... jQuery + AJAX zijn de standaard... Maak dat ding even asynchroon

Haha, mijn punt is gemaakt geloof ik.

Nee serieus, je noemt twee features die vrij basic zijn ontworpen, net als de file browser. Dat zijn 'stubs' - functionaliteit die basaal werkt en makkelijk ontworpen is, klaar om ooit eens herschreven te worden.

Zo ook de Samba functionaliteit in de huidige web-interface, die biedt niet genoeg opties en de management ervan is gaar. Dat gaat niet een beetje bijgepoetst worden, dat is helemaal opnieuw ontworpen met allerlei fanfare. Niet active directory wat sommigen willen, wel simpele permissies die voor een normale sterveling zijn te begrijpen. En ze werken. Drag en drop en het werkt, jippie. Geen gekut. Dat noem ik een échte rewrite. Je zult zien.

De features worden ontworpen naar mate van prioriteit zoals ingeschat door Jason op basis van feedback uit de community.

Dadona schreef op zondag 10 maart 2013 @ 23:40:
Iets anders... We hebben het nu al meerdere malen over ECC gehad en de meningen slaan misschien wat meer naar 'ben niet echt zeker van het nut' en 'je doet het echt om het af te maken'. Kunnen we eens cijfertjes produceren?
Juist met ZFS belast je je geheugen extreem. Dus dan kom je sneller in een situatie dat ECC uitmaakt. Is er een manier dat ECC gevalletjes worden gerapporteerd?

Het is vrij simpel. ZFS zegt dat er checksum errors waren terwijl dat niet zo is op het moment dat ZFS de data corrumpeert door RAM corruptie. Die dat is stap 1. Zodra ZFS de data vervolgens weer terugleest en aangenomen dat er dan even geen RAM-corruptie plaatsvindt, kan die weer worden gecorrigeerd en krijg je dus weer een checksum error in de zpool status output.

Hoe ik heb getest is simpel:

• installeer ZFS met een goede RAM stick, snapshot alles
• draai ZFS met een kapotte RAM stick en ga nepdata aanpassen of genereren. Doe veel I/O.
• later ga met goed RAM draaien en doe een scrub. Je ziet checksum errors voorbij komen die worden gerepareerd zolang je voldoende redundancy hebt.

Mijn kijk hierop is dat ZFS ten minste een vorm van bescherming tegen RAM-corruptie heeft. Het kan corruptie detecteren, dat is al een hele belangrijke feature! Zodra je checksum errors ziet, moet je oppassen. Dan gaat er een belletje rinkelen. Twee is dat ZFS nooit corrupte data aan applicaties zou mogen sturen, maar dat gaat dus niet op voor RAM corruptie. Helaas. Drie is dat ZFS nooit blijvende corruptie zou mogen veroorzaken die niet te corrigeren is.

Dat laatste - permanente datacorruptie - zou denk ik alleen plaats kunnen vinden als je meerdere RAM-corruptie hebt op precies de verkeerde plek. Aangezien ZFS elke keer andere geheugenplekken gebruikt lijkt het me logisch dat:

• als je defect RAM hebt, je dit snel zult zien in de zpool status output
• een enkele bitflip veroorzaakt door je RAM helemaal niet zo kritiek is
• het grootste probleem is end-to-end data integrity; die wordt onteerd omdat er corrupte data aan de applicatie wordt geleverd. Dus ook via samba naar je Windows client die om de data vraagt. Zo kan corruptie naar je backups vloeien, zij het beperkt.
• goed backuppen van ZFS data doe je met zfs send/receive en dan zou je nog steeds bescherming hebben
• vooral met RAID-Z2 denk ik dat je best goede bescherming hebt. Bedenk dat ZFS metadata ook ditto copies heeft en die dus vrijwel immuun is
• mocht een bestand dan toch echt permanent corrupt raken, dan weet je dat tenminste en precies welke file. Als die echt belangrijk was, had je daar een backup van. Belangrijk is dat de filesystem metadata vrijwel altijd blijft werken dankzij ditto copies die je kunt optellen/vermenigvuldigen met je redundancy.

[onox]

Verwijderd schreef op zondag 10 maart 2013 @ 18:41:
Ik heb in elk geval nog geen spijt van mijn bijdragen aan ZFSguru. Ik vind het enorm gaaf die kleine rebelse projecten met veel potentie. Beter dan de logge projecten die redelijk ambitieloos voortborduren op wat ze al hebben, maar de kern blijft hetzelfde met alle inherente nadelen. Ik vind FreeNAS persoonlijk niet 'sexy'. Hoe denken jullie hierover?

Ik vind het sexy als je launchd zou porten naar FreeBSD

Verwijderd schreef op zondag 10 maart 2013 @ 20:56:
Gebruik wel een firewall zoals pf. Die is heel gemakkelijk te gebruiken in FreeBSD en valt toch onder de beste FOSS packet-firewall voor UNIX. Zelfs traffic shaping zit al in de kernel van ZFSguru dus je kunt het zo gaan gebruiken. Beperk dan ook poort 80 of althans de poort waar lighttpd op draait tot een of meerdere vertrouwde IP adressen.

Wat is er aan pf beter dan iptables?

[Dadona]

Verwijderd schreef op maandag 11 maart 2013 @ 00:09:
[...]
Het is vrij simpel. ZFS zegt dat er checksum errors waren terwijl dat niet zo is op het moment dat ZFS de data corrumpeert door RAM corruptie. Die dat is stap 1. Zodra ZFS de data vervolgens weer terugleest en aangenomen dat er dan even geen RAM-corruptie plaatsvindt, kan die weer worden gecorrigeerd en krijg je dus weer een checksum error in de zpool status output.
...

Het gaat mij erom dat er problemen zijn, in het algemeen. Dus inclusief dat er een detectie is dat er bij het wegschrijven al iets foutgaat. Maar inderdaad, dan zou er ook wel een keer wat fout moeten gaan bij het teruglezen.

Maar bedenk, het gaat mij echt om cijfers dat ECC noodzakelijk was (en soms ook niet eens afdoende, volgens een studie). Niet wat voor het gevoel gaande is en of je van mening bent dat iets voldoende is of wat dan ook. En ik wil eigenlijk niet terugvallen op wat ZFS zegt, hoewel het goed klinkt, mist het niet iets?

Ik ben de laatste tijd wat studies tegengekomen over ECC (inclusief eerder al de melding dat er meer geheugen fouten zijn dan gedacht - nogal tegenstrijdig), ZFS en soms ook (heel oppervlakkig) de combinatie. Nu heb ik zelf twee opstellingen met ECC udimm modules. Nu is het geloof ik mogelijk om ook meldingen door te geven als er een correctie heeft plaatsgevonden. Dat zou een stapje kunnen zijn.

[ Voor 9% gewijzigd door Dadona op 11-03-2013 00:32 ]

[Compizfox]

FireDrunk schreef op zondag 10 maart 2013 @ 22:50:
Een nadeel is weer, dat je niet de native upgrade systemen van FreeBSD kan gebruiken om nieuwe versies van packages kan installeren... Een grote ergernis is altijd dat SabNZBd de hele tijd zeurt dat er een update is, maar ik hem niet kan updaten...

Niet? De ports tree bedoel je? Die update ik gewoon altijd met portmaster en dat werkt prima.

[Verwijderd]

@onox: ik ken iptables niet, alleen ipfw en pf. Laatstgenoemde is duidelijk superieur. Geimporteerd uit OpenBSD.

@Dadona: je kunt toch gewoon een checksum programma gebruiken om echt te controleren of ZFSguru niets heeft gemist? Maar als er RAM-corruptie is dan zal je dat vaak toch wel merken doordat de opgeslagen data ofwel de parity ofwel de checksum niet met elkaar overeenkomen. Die parity zie je alleen bij een scrub, de rest zie je ook bij normale access.

Dus als je ZFS corruptie icm defect RAM wilt testen is dat vrij makkelijk denk ik.

[analog_]

Ik heb precies een stormpje gestart. Mijn visie in IT op het moment is een beetje best-of-breed waarbij ik probeer de beste producten (die aan de eisen voldoen) te gebruiken. In het begin probeerde ik al die software op één of aantal hosts te draaien (bv. Win srv en debian). Omdat ik na verloop van tijd merkte dat ik vooral tijd verspil in dingen werkend krijgen onder de b-configuratie (wat betreft, testing/ondersteuning) ben ik daar vanaf gestapt. Sommige pakketen installeren/onderhouden nu eenmaal makkelijker onder os X dan Y, dus zorg ik dan gewoon voor een extra VM en het scheiden van applicaties zorgt ook voor minder gezeik. We werken nu al een twintigtal jaar met dezelfde system-constraints voor package managers en nog slagen we erin een brak systeem op te zetten. Op een gegeven moment moet je dan werkelijkheid aanstaren en ontdekken dat helaas één server met twintig services meer werk betekend dan één ESXi en vijftien VMs met nix/bsd/whatnot.

Daarom ben ik wel blij te horen dat er blijkbaar wel een visie is bij zfsguru en het core gebeuren omdat ik eerlijk gezegd zelf de applicatie uitstapjes een beetje gortig vindt. Ik weet ook dat 'helpen' meer is dan BSD code schrijven, maar dat is het pijnpunt van community. Als ik mij nu nog zou verdiepen in BSD zou ik waarschijnlijk wel wat kunnen doen. Wat ik mij enkel afvraag is in welke mate jullie afstappen van the 'freebsd-way', zoals debian z'n manier heeft. Vyatta, een debian derivaat plugt bijvoorbeeld netjes in op debian en de manier van werken. Je kan er met genoeg tijd/gekut/kernel-headers ook KVM netjes op zn debians op doen. Nu ik wat van je changelog in dit topic lees krijg ik de indruk dat jullie daar soms van afstappen en ik kan je al spijt verzekeren. Het is gemakkelijker mee te gaan met je stroming, of de juiste stroming te herontdekken (andere bsd's ?). Dat zfsguru usb verhaal is bijvoorbeeld iets wat hopelijk onder freebsd al gedaan/getest/gepubliceerd is en één nette configuratie/onderhoud/implementatie van heeft. Ik heb vooral schijt aan wielen heruitvinden zoals het x11/compiz/whatever-canonical-nu-aanbezig is.

Ik heb ook grote liefde voor best-of-breed hybrids zoals ubiquiti netwerk hardware (erg sterk in wifi) en vyatta met hun recente edgerouter (staat in bestelling).

Als je me nu vertelt dat dit zfsguru is, dan is de kans dik dat ik ga overstappen (+eventueel comm work) omdat OI mij helaas niet liev is wat betreft infiniband.

ps. iptables -> shorewall -> firenogwat (gui) -> pf rules. Be green, recycle.

als we toch bezig zijn: linux mint is nog zoiets, meer dan een ubuntu en eigen package repository is het niet, ik vindt mint een onverantwoordelijke reden om een nieuw project te starten omdat je eindigt met dezelfde pakketten te onderhouden en dubbel werk met je initiële fork, zie ook wat er zou gebeuren met mysql en hun nieuwe derivaten, er is niet genoeg community om de volledige code base bij te houden. Blogje schrijven hierover, kan hier uren over doorpraten, iemand koffie regio antwerpen?

[ Voor 12% gewijzigd door analog_ op 11-03-2013 01:43 ]

[Compizfox]

Verwijderd schreef op maandag 11 maart 2013 @ 00:46:
@onox: ik ken iptables niet, alleen ipfw en pf. Laatstgenoemde is duidelijk superieur. Geimporteerd uit OpenBSD.

iptables is de userland 'frontend' voor netfilter, de Linux firewall.
Bestaat dus inderdaad niet in FreeBSD

[Verwijderd]

Ik begrijp best je punt analog_ met afstappen of eigenlijk afdwalen van een bepaald OS. Dat kan op meerdere manieren:

1. Niet de volledige distributie meeleveren, maar gestript. Dit is enkel van toepassing op FreeNAS/NAS4Free en niet op ZFSguru.

2. Kernel en sourcemodificaties ten opzichte van FreeBSD. Ik weet niet hoe dit zit met de overige projecten. ZFSguru heeft een enkele sourcemodificatie; een patch voor AMD Brazos temperatuursensor die nog niet is doorgevoerd in 9.1. En een kernel configuratie met Infiniband, altQ en netwerk polling. Allemaal zaken die vrij onschuldig aan kunnen worden gezet als goede defaults voor een alround NAS platform.

3. Interactie met het besturingssysteem. Volgens mij is dit allang aangepast, maar het was juist FreeNAS die een pool configuratie in een file opsloeg en dat soort eigen foefjes gebruikte. ZFSguru heeft een web-interface die via normale FreeBSD commando's zijn informatie vergaart. Je kunt in sommige gevallen de commando's ook zien en aanpassen desnoods.

4. Manier van gebruik. FreeBSD heeft geen root-on-ZFS installatie; ZFSguru heeft die zelf ontworpen uiteraard gebruikmakende van de ZFS bootfunctionaliteit in FreeBSD. Maar voordat dit allemaal werkt ben je wel een tijd verder en die leerweg is dus al lange tijd gemaakt. Maar dit is dus wel een devatie van de richting waar FreeBSD op gaat. Al hoop ik dat ZFS ooit eens de default wordt, is de nieuwe BSD installer nog steeds op basis van UFS en geen ZFS ondersteuning. Toch jammer. Maar de installatieprocedure van FreeBSD was altijd al het zwakke punt zeker voor beginners en daar heeft ZFSguru natuurlijk wel een hele goede fix voor. Installeren is supereenvoudig. En meerdere installaties kunnen managen en weer terug kunnen gaan naar de vorige install... dat zijn allemaal deviaties.

Ook een embedded distributie heeft FreeBSD niet echt. Hooguit de NanoBSD scripts. Dat zijn vrij ouderwetse UFS-achtige scripts met gestripte BSD en allerlei beperkingen en workarounds daarvoor. Dat soort dingen vinden 'wij' niet sexy. ZFSguru maakt het mogelijk om zelf op te geven welke files/instellingen behouden blijven op je embedded distributie-medium en je kunt zo dus een grafische desktop met wat niet alles onderhouden terwijl je USB-stick geen writes krijgt terwijl alles draait. Welk project kan dat?

---

Maargoed, alleen op dit laatste vlak gaat ZFSguru dus afwijken van FreeBSD. Voor de rest volgt ZFSguru juist heel 'eerlijk' de FreeBSD manier van doen. Zo worden configuratiefiles 'eerlijk' aangepast en kun je zelf handmatige wijzigingen in FreeBSD prima combineren met interacties via de web-interface; dat gaat elkaar niet bijten. Kortom, waar ben je precies bang voor?

[FireDrunk]

Verwijderd schreef op zondag 10 maart 2013 @ 23:50:
[...]


Aansluitend op EnerQi: iedereen wil wat, inderdaad. Maar is het dan zo dat ZFSguru een kant op gaat die mensen niet willen?

Een overzicht van ZFSguru development
Eerst moest de basis goed zijn; disk handling, een welcome wizard, filesystem management. Daarna - toen het project nog grotendeels op HardOCP plaatsvond - wilde men benchmarking. Dus ZFSguru kwam met de Advanced Disk Benchmark die pool configuraties test en daar een grafiek van maakt. Daarna is het project volwassener geworden met een eigen website, en de web-interface geheel herschreven met een totaal nieuwe opzet en eigen stijl. Dit omdat hij niet wilde werken aan iets wat ooit toch weer herschreven zal moeten worden.

Men wilde extra functionaliteit zoals iSCSI en AppleShare, maar Jason wilde geen bloated OS maar iets elegants. Dus eerst veel aandacht aan een service infrastructuur en build management om dit alles ook zonder extreem veel moeite te kunnen produceren elke keer. Dit proces is nog steeds niet helemaal afgerond, maar wel voor 90% inmiddels. Zo kan het updaten van de database nu via een eigen web-interface en komt er ook een unified 'gurudb' waar alle remote data in is verwerkt, in plaats van aparte files.

En nu we weer in het heden spreken, kijken we naar de features die op de roadmap staan: migratie van settings als je een nieuwe systeemversie wilt proberen. Lijkt me een cruciale feature? Gaan veel mensen gebruiken en is ook de basis van de 0.3 feature: de embedded distributie op USB-stick met weinig writes en toch een grafische desktop met tig services kunnen draaien. Daar heb je een goede infrastructuur voor nodig en dat soort dingen ontwikkelen en bedenken kost natuurlijk ook tijd. Maar liever door één goed iemand dan een zwak team die maar wat doet wat makkelijk is.

Kortom, ik zou wel denken dat ZFSguru tot nu toe en in de toekomst werkt aan zaken die de community wilde. De enige controversiële feature is misschien de grafische services. Maar dat dit werkt is vooral omdat de onderliggende build infrastructuur goed op orde is met geneste dependencies en alternatieve dependencies en wat niet al. Toch gebruiken vrij veel mensen de grafische services, aangezien ZFSguru al over de 1.5TB dataverkeer per maand gaat. Dus nu werken aan lichtere grafische packages en dat is pretty much waar we nu zitten. De nieuwe 9.0, 9.1 en 10.0 builds komen uit en daarna wordt de beta9 afgebouwd. Dan zitten we weer een maand verder.


[...]

Hm, vaak zijn grote projecten toch grotendeels met de inzichten van één iemand gevormd. Denk aan Star Trek, denk aan Steve Jobs, ga zo maar door. Leuk voorbeeld is bijvoorbeeld Zelda waar die Japanse developer toch veel ideeën in heeft verwerkt en toch wel de grootvader is van de series. Hij deed uiteindelijk nog maar 33% ofzoiets terwijl de rest van het team de rest deed. Maar het zijn altijd wel de cruciale punten waar zo'n grandfather dan aandacht aan besteed. Kortom, ik zou willen stellen dat je met één of twee goede developers echt ver kunt komen. Niet dat ik mijzelf daar onder reken, overigens, en Jason valt ook niet in het profiel van een doorsnee programmeur - maar wel in de rol als ontwikkelaar. En daar ligt een subtiel verschil. Ik vind dat hij mooie nieuwe inzichten heeft.

Want verklaar mij eens hoe een project wat uit het niets in een paar jaar een project uit de grond stampt wat kan concurreren met grote commerciële teams? Dat vind ik vrij bijzonder.

ZFSguru kan concurreren met andere OS-en om 2 simpele redenen. Het is een full-OS tegenover een nano-OS. En het doet Root-on-ZFS met een installatie wizard ipv met een hele rits ingewikkelde commando's.

Als Ubuntu in de installer ZFS meeleverde, zat ik waarschijnlijk al op Ubuntu als ZFS core.
En ik zit er ook zelfs over te twijfelen om BTRFS te gaan gebruiken.
No offence, maar ik ben zelf niet zo gecharmeerd van FreeBSD

Ik ken in de professionele wereld en in elk project wat ik ooit in mijn leven gezien heb, niet een die echt goed is gegaan terwijl er maar 1 dev aan werkte. Of je moet een dev hebben die echt heel veel hulp vraagt, maar anderen niet mee laat coden.

In je eentje goed werk afleveren is een illusie. Waar gewerkt word, worden fouten gemaakt. Denk aan security lekken, wie gaat de code reviewen? je eigen code is je grootste blinde vlek...
Als Google applicaties kan maken EN ze veilig kan houden met het gebruik van jQuery, wie is die ene dev dan (Jason he ) om te huilen dat het misschien wel kapot gaat? (om maar even een voorbeeld te noemen van zolderkamergedrag...)

Verwijderd schreef op maandag 11 maart 2013 @ 02:02:
*knip*

2. Kernel en sourcemodificaties ten opzichte van FreeBSD. Ik weet niet hoe dit zit met de overige projecten. ZFSguru heeft een enkele sourcemodificatie; een patch voor AMD Brazos temperatuursensor die nog niet is doorgevoerd in 9.1. En een kernel configuratie met Infiniband, altQ en netwerk polling. Allemaal zaken die vrij onschuldig aan kunnen worden gezet als goede defaults voor een alround NAS platform.

Helemaal mee eens, dit vind ik juist een sterk punt! Maak die kernel juist leuk voor veel mensen, als er vanuit de community vraag is naar InfiniBand, lekker erin stoppen. in de toekomst misschien een idee om een autobuildscript te maken dat tijdens install opties aan en uit kan zetten en juist die kernel kan installeren?

3. Interactie met het besturingssysteem. Volgens mij is dit allang aangepast, maar het was juist FreeNAS die een pool configuratie in een file opsloeg en dat soort eigen foefjes gebruikte. ZFSguru heeft een web-interface die via normale FreeBSD commando's zijn informatie vergaart. Je kunt in sommige gevallen de commando's ook zien en aanpassen desnoods.

Het gaat via su/sudo, dat kan je ook doen via jet setuid bit, stukje veiliger

[ Voor 12% gewijzigd door FireDrunk op 11-03-2013 08:59 ]

[Ultimation]

- solved -

[ Voor 94% gewijzigd door Ultimation op 11-03-2013 12:09 ]

[matty___]

FireDrunk schreef op maandag 11 maart 2013 @ 08:54:

Als Ubuntu in de installer ZFS meeleverde, zat ik waarschijnlijk al op Ubuntu als ZFS core.
En ik zit er ook zelfs over te twijfelen om BTRFS te gaan gebruiken.
No offence, maar ik ben zelf niet zo gecharmeerd van FreeBSD

En wat weerhoud je van BTRFS?

[onox]

matty___ schreef op maandag 11 maart 2013 @ 11:41:
[...]

En wat weerhoud je van BTRFS?

En wat is er beter aan BTRFS? Ik hoop niet dat het de git onder de filesystems wordt. Oftewel dat je kernel developer moet zijn om het te snappen. ZFS is ten minste simpel

[FireDrunk]

Wel:

Resizable, overprovisioning
(en natuurlijk omdat het Linux is...)

Niet:

Te beta, nog niet echt performant, en de ssd acceleratie methodes die ze kennen zijn niet zo goed als die van ZIL / L2ARC.

[ Voor 10% gewijzigd door FireDrunk op 11-03-2013 12:24 ]

[onox]

Hoezo wil je Ubuntu gaan gebruiken? Ik dacht dat je meer van Gentoo was Ik gebruik nu zonder problemen ZFS op Gentoo.

[FireDrunk]

Mja, het word of Ubuntu zodat ik SabNZBd native kan draaien (makkelijk met packages en updates, en performt toch het beste) of ik ga voor een hele kale Gentoo en maak een Ubuntu VM met sab er in (iets minder performant, maar wel weer wat veiliger...

Ik heb trouwens wel gemerkt dat Gentoo als host niet per definitie het snelst is, andere OSen hebben aardig wat optimalisaties doorgevoerd voor mijn gevoel...

Om nou ZFS op Linux te gaan draaien, vind ik ook weer een stap te ver... Ik wil eigenlijk tot BTRFS goed werkt bij FreeBSD blijven. (of ZFSonLinux moet echt veel progess maken in de komende maanden...)

[ Voor 19% gewijzigd door FireDrunk op 11-03-2013 12:34 ]

[onox]

FireDrunk schreef op maandag 11 maart 2013 @ 12:33:
Mja, het word of Ubuntu zodat ik SabNZBd native kan draaien (makkelijk met packages en updates, en performt toch het beste) of ik ga voor een hele kale Gentoo en maak een Ubuntu VM met sab er in (iets minder performant, maar wel weer wat veiliger...

Ik heb trouwens wel gemerkt dat Gentoo als host niet per definitie het snelst is, andere OSen hebben aardig wat optimalisaties doorgevoerd voor mijn gevoel...

Om nou ZFS op Linux te gaan draaien, vind ik ook weer een stap te ver... Ik wil eigenlijk tot BTRFS goed werkt bij FreeBSD blijven. (of ZFSonLinux moet echt veel progess maken in de komende maanden...)

Ja je moet wel CFLAGS goed instellen natuurlijk Kun je iets specifieker zijn over welk soort optimalisaties? Mist ZFSonLinux nog enkele grote features?

[FireDrunk]

Vhost NET was onder Gentoo een stuk trager dan onder Ubuntu.

ZFSonLinux heeft dacht ik nog geen hardwarematig support voor de AES functie in je CPU, maar verder kan ik er zo geen bedenken, maar zo heel goed heb ik me eerlijk gezegd ook niet verdiept in ZFSonLinux.

[matty___]

FireDrunk schreef op maandag 11 maart 2013 @ 12:33:
Mja, het word of Ubuntu zodat ik SabNZBd native kan draaien (makkelijk met packages en updates, en performt toch het beste) of ik ga voor een hele kale Gentoo en maak een Ubuntu VM met sab er in (iets minder performant, maar wel weer wat veiliger...

Ik heb trouwens wel gemerkt dat Gentoo als host niet per definitie het snelst is, andere OSen hebben aardig wat optimalisaties doorgevoerd voor mijn gevoel...

Om nou ZFS op Linux te gaan draaien, vind ik ook weer een stap te ver... Ik wil eigenlijk tot BTRFS goed werkt bij FreeBSD blijven. (of ZFSonLinux moet echt veel progess maken in de komende maanden...)

want python installeren en SABNZBd.py uitvoeren is te moeilijk?
natiever dan dit wordt het niet.

[onox]

matty___ schreef op maandag 11 maart 2013 @ 12:50:
[...]

want python installeren en SABNZBd.py uitvoeren is te moeilijk?
natiever dan dit wordt het niet.

Python staat al geïnstalleerd als je Gentoo gebruikt. De package manager is namelijk in Python geschreven.

FireDrunk schreef op maandag 11 maart 2013 @ 12:48:
ZFSonLinux heeft dacht ik nog geen hardwarematig support voor de AES functie in je CPU, maar verder kan ik er zo geen bedenken, maar zo heel goed heb ik me eerlijk gezegd ook niet verdiept in ZFSonLinux.

ZFS v28 heeft toch sowieso geen AES support? Voor AES kun je gewoon GELI (FreeBSD) of LUKS (Linux) gebruiken.

[ Voor 39% gewijzigd door onox op 11-03-2013 12:53 ]

[matty___]

FireDrunk schreef op maandag 11 maart 2013 @ 12:19:
Wel:

Resizable, overprovisioning
(en natuurlijk omdat het Linux is...)

overprovisioning als in meer opslaan dan je ruimte hebt. En dat vind je een plus punt?

[Compizfox]

Overprovisioning van wat, eigenlijk? ZFS volumes kun je ook sparse maken.

En ja, dat kan een voordeel zijn als je meerdere volumes hebt, maar van te voren nog niet weet hoe groot ze zullen worden.

[ Voor 46% gewijzigd door Compizfox op 11-03-2013 13:00 ]

[matty___]

Compizfox schreef op maandag 11 maart 2013 @ 13:00:
Overprovisioning van wat, eigenlijk? ZFS volumes kun je ook sparse maken.

volgens mij bedoelt die dit:

Typically, provisioning storage capacity to multiple users can be inefficient. For example, if 10 users need 10 GB each one, you will need 100 GB of storage capacity. These users, however, very probably won't use most of that storage space. Let's suppose that, on average, they only use 50% of their allocated space: only 50 GB will be used, and the other 50 GB will be underutilized.

Thin provisioning allows to assign to all users combined more storage capacity than the total storage capacity of the system. In the previous case, you could buy only 50 GB of storage, let each users have 10 GB of theorical storage space (100 GB in total), and have no problems, because the 50 GB you bought are enought to satisfy the real demand of storage. And if users increase the demand, you can add more storage capacity. Thanks to thin provisioning, you can optimize your storage investment and avoid over-provisioning.

[FireDrunk]

Je kan je complete filesystem groter maken dan de hele pool van je disks, en live resizen (zowel omhoog als naar beneden). Je bent dus onafhankelijk van de grootte van de disks.

Ook kan je (voor zover ik weet) live je raid level wijzigen.

Dus stel ik heb 10 schijven van 2TB in RAID6 (effectief dus 16TB ruimte) maar ik gebruik maar 10TB, dan kan ik gewoon 3 schijven detachen. Dan maakt hij ze zelf leeg, en verkleint je pool en filesystem.

En dat allemaal in 3 commando's... (of zelfs 1 volgens mij).

[ Voor 6% gewijzigd door FireDrunk op 11-03-2013 13:04 ]

[matty___]

FireDrunk schreef op maandag 11 maart 2013 @ 13:03:
Je kan je complete filesystem groter maken dan de hele pool van je disks, en live resizen (zowel omhoog als naar beneden). Je bent dus onafhankelijk van de grootte van de disks.

Ook kan je (voor zover ik weet) live je raid level wijzigen.

Dus stel ik heb 10 schijven van 2TB in RAID6 (effectief dus 16TB ruimte) maar ik gebruik maar 10TB, dan kan ik gewoon 3 schijven detachen. Dan maakt hij ze zelf leeg, en verkleint je pool en filesystem.

En dat allemaal in 3 commando's... (of zelfs 1 volgens mij).

En dat is reeds jaren lang in productie getest

[FireDrunk]

Dat zeg ik niet Waarom denk je dat ik het NU nog niet gebruik?

[ Voor 58% gewijzigd door FireDrunk op 11-03-2013 13:06 ]

[matty___]

FireDrunk schreef op maandag 11 maart 2013 @ 13:06:
Dat zeg ik niet Waarom denk je dat ik het NU nog niet gebruik?

Maar ik ben het met je eens dat ZFS op het punt van resizen nog wel een inhaalslag te maken heeft.
De block-back-pointer rewrite laat nog op zich wachten en krijg ook geen beeld van of er iemand binnen illuminos groep mee bezig is.

kwam wel dit tegen:
http://zfsday.com/zfsday/zfs-state-of-the-union-matt-ahrens/

[ Voor 11% gewijzigd door matty___ op 11-03-2013 13:30 ]

[FDMK]

Zo ook de Samba functionaliteit in de huidige web-interface, die biedt niet genoeg opties en de management ervan is gaar. Dat gaat niet een beetje bijgepoetst worden, dat is helemaal opnieuw ontworpen met allerlei fanfare. Niet active directory wat sommigen willen, wel simpele permissies die voor een normale sterveling zijn te begrijpen. En ze werken. Drag en drop en het werkt, jippie. Geen gekut. Dat noem ik een échte rewrite. Je zult zien.

Waarom niet? De meesten die nerd genoeg zijn om een eigen nas-OS te draaien ipv synology hebben ook wel een AD en of dergelijke. Waarom dan geen AD ondersteuning zodat je lekker met je DC rechten kan uitdelen over shares.
Dit is voor mij de enige reden om N4F te gebruiken ipv ZFSguru.