Het grote ZFS topic

[jan99999]

http://support.apple.com/...locale=en_us&locale=en_us

[DrFlash]

FireDrunk schreef op maandag 08 juli 2013 @ 16:24:
Mwoh, watvoor schijven zijn het?

2tb's verschillende merken, maar allemaal de energiezuinige versie.

[FireDrunk]

Je kan je ZFS parameters nog wat tunen door de logbias te veranderen, en de txg timeout te verkorten.

[Farmie]

Ik heb enkele vraagjes ivm met mijn ZFS systeem.

Ik draai nu ZFSGuru met 5x 3TB (WD Green ZRX) in RaidZ. Met welke tooltjes kan je het best read en write speeds testen? Ik heb al iets geprobeerd met "iozone", maar ik geraak er niet echt wij uit. Kan je dit uberhaupt op het systeem zelfs testen of gaat dit enkel in praktijktests (kopieren overe SAMBA/NFS/FTP,...)? Momenteel beschik ik wel enkel over een 100Mbit switchtje.

Een andere vraag is of het mogelijk is om je ZFS schijven te gebruiken in een andere distributie (bv. Nas4Free); zodat ik bv. de schijven zou kunnen loskoppelen, een andere distributie installeren op mijn aparte SSD die ik als bootdevice gebruik, en dat de RaidZ gewoon wordt herkend in het nieuwe systeem?

Hoe zit het met de "services" in Nas4Free zoals Transmission client, FTP server,... In ZFSGuru ben ik hier niet zo tevreden over.

[Verwijderd]

Performance testen kan met de benchmarks die in ZFSguru zitten. Kijk eens bij Pools->Benchmark.

Je kunt je pool gebruiken (importeren) in andere NAS appliances die ZFS ondersteunen, zoals Solaris, Linux, NAS4Free, FreeNAS enzovoort. In sommige gevallen moet je dan wel wat dingen doen, zoals bij Solaris waar je de GPT partities moet instellen op Solaris type. Maar bij NAS4Free hoeft dat niet. NAS4Free, FreeNAS en ZFSguru zijn alle drie gebaseerd op FreeBSD; hetzelfde operating system.

Services in NAS4Free kan ik je niet mee helpen; geen idee. Wat is er mis met Transmission in ZFSguru?

[Farmie]

Transmission kan de download folder niet vindenn, aanpassen gaat ook niet. Er staat daarover ook een topic op het forum van ZFSguru. Ik heb al wat zelf gaan proberen aanpassen in de configs, maar zonder veel verandering.
Andere applicaties installeren lukt soms niet. Owncloud shell bestand heb ik manueel moeten aanpassen, de downloadlocatie die in de config staat bestaat niet meer, en er is daar ook geen errorafhandeling. Ik heb dan maar manueel de laatste versie van owncloud geinstalleerd, maar dat heb ik ook maar half werkend gekregen.
ProFTPd en PureFTP heb ik ook nog niet werkend gekregen vanuit ZFSGuru.
Ik ben mij nu wat meer aan het verdiepen in FreeBSD om manueel applicaties toe te voegen en te beheren; maar het zou leuker zijn moest alles via we web gui te beheren zijn.

[Verwijderd]

Zal het binnenkort zelf nog eens gaan proberen, ik draai nu een iets oudere versie. Maar voor zover ik weet is ZFSguru wel het enige NAS OS wat heel gemakkelijk extra applicaties laat installeren. Bij andere projecten heb je soms maar een handjevol aan extra services of plugins die ook met beperkingen worden geïnstalleerd, zoals FreeNAS die alles in een jail doet. Maar probeer anders NAS4Free eens en kijk of je daar de services die jij wilt wel gemakkelijk werkend kunt krijgen.

[FDMK]

Ik weet niet meer waar het staat of hoe ik het heb gevonden maar drukken die extra services bij ZFSguru zwaar op de performance bij bijvoorbeeld een G1610 en een setup zonder compressie of dedup?

[Verwijderd]

Nee. Je kunt prima veel services gebruiken. Natuurlijk heb je wel sommige services die zwaarder zijn, bijvoorbeeld SABnzbd. Maar zo'n Intel-chip is prima krachtig genoeg; die G1610 is echt geen prutding maar best een goede chip. Veel waar voor je geld. Dus ik zou zeggen: maak je niet zo druk om CPU-performance. Meestal komt het aan op de hoeveelheid RAM-geheugen wat soms onvoldoende is om het maximale uit de hardware te halen.

[Verwijderd]

Nou cypher, ik merk anders dat mijn storage beperkt wordt door de cpu: tijdens benchen draait mijn e2620 op 100%. En dan haal ik maar 700-800mBs. Ook scrubs, vmcloning ed laten mijn cpu langere tijd op 80 a 100% draaien. Terwijl de 2620 toch echt geen kleine jongen is. Zfs maakt overigens wel mooi gebruik van multicore: alle 8 treads die ik toeken aan mijn zfs machine zijn altijd evenredig belast.

[FireDrunk]

Je hebt je ZFS VM virtueel? Dat scheelt aanzienlijk in de efficientie van ZFS heb ik gemerkt.
Waar een VM doorgaans 100% belasting kan hebben, heeft dezelfde setup fysiek misschien maar 60-70% belasting.

[Verwijderd]

Zelfs dat vind ik nog hoog, want het enige cpu belastende op zfsguru is gzip1 compressie op mijn filesystem voor vm`s.

Maargoed, in de zomervakantie ga ik eens kijken hoe het geheel onder solaris draait. Wellicht dat ik dan ook gebruik kan maken van zfs encryptie als de cpu belasting daarop lager ligt

[Verwijderd]

Verwijderd schreef op dinsdag 09 juli 2013 @ 16:51:
Nou cypher CiPHER , ik merk anders dat mijn storage beperkt wordt door de cpu: tijdens benchen draait mijn e2620 op 100%.

Waar zie je die 100% dan precies? Als dat op de statuspagina is, dan betekent 100% een average load van 1.00. Dat betekent niet dat je processor vol belast wordt, zeker niet als je meerdere cores hebt. Je kunt daar bijvoorbeeld ook 800% zien staan bij 8 threads die bezig zijn op volle toeren. Je kunt wel met 'top' kijken naar de cpu idle percentage. Ook zie je daar waaraan je CPU besteed wordt: user (applicaties zoals Samba), system (waaronder ZFS), interrupt (voor je I/O controllers e.d.) en idle.

Jouw e2620 is een 6-core op 2GHz dus 100% is daar gemakkelijker bereikt. Ik zou het erg vreemd vinden als je alle 6 de cores voltrekt bij normale sequential load, zonder gebruik van virtualisatie of speciale features als compressie/dedup.

Maargoed, in de zomervakantie ga ik eens kijken hoe het geheel onder solaris draait. Wellicht dat ik dan ook gebruik kan maken van zfs encryptie als de cpu belasting daarop lager ligt

Bedenk wel dat Solaris met ZFS encryptie alleen softwarematige encryptie op één CPU core ondersteunt. Dat is dus niet erg snel, zeker niet erg geschikt om overal encryptie op te enablen. FreeBSD en dus ook ZFSguru ondersteunen multi-core software encryptie en AES-NI accelerated hardware encryptie middels GELI. Dat is dus veel sneller/beter dan wat Solaris biedt. Jouw CPU ondersteunt volgens de Intel Ark ook AES-NI. Dat betekent dat je vrijwel zonder vertraging de encryptie kunt gebruiken.

[ Voor 26% gewijzigd door Verwijderd op 09-07-2013 17:29 ]

[Verwijderd]

Dit leek mij best interessant voor backupdoeleinden, maar helaas wordt Windows niet ondersteund. Zijn er andere alternatieven die wel op Windows werken?

[FireDrunk]

Als in? Filesystems van hetzelfde caliber?

[Verwijderd]

FireDrunk schreef op dinsdag 09 juli 2013 @ 21:34:
Als in? Filesystems van hetzelfde caliber?

Iets dat iets meer zekerheid geeft dan NTFS. Ik ben een beetje bang dat er een moment komt dat al mijn nette backups corrupted blijken en dat mijn data naar de eeuwige invoervelden is vertrokken.

[FireDrunk]

ReFS is er, maar dat komt nog niet echt in de buurt van ZFS.

[Q]

Verwijderd schreef op dinsdag 09 juli 2013 @ 21:38:
[...]

Iets dat iets meer zekerheid geeft dan NTFS. Ik ben een beetje bang dat er een moment komt dat al mijn nette backups corrupted blijken en dat mijn data naar de eeuwige invoervelden is vertrokken.

Wat is de context? Waarom bouw je niet een NAS op basis van ZFS en share je dat file system niet via SMB/CIFS?

[Verwijderd]

Q schreef op dinsdag 09 juli 2013 @ 23:01:
Wat is de context? Waarom bouw je niet een NAS op basis van ZFS en share je dat file system niet via SMB/CIFS?

De context is een PC die gebouwd is als workstation, dagelijkse bak en een klein beetje gamegebeuren. Redundancy valt te bereiken door meerdere schijven te gebruiken, maar ik begin me meer en meer te realiseren dat je zonder het te merken alsnog zuur kunt zijn als je controller scheef is gegaan of je geheugen niet helemaal fris meer is en ik-weet-niet-hoe-lang corrupte data naar je backups is geschreven. Daar kom je dan vaak pas achter op het moment dat je ze nodig hebt.

Een NAS bouwen behoort momenteel niet echt tot de mogelijkheden, financieel en qua fysieke ruimte. Gezien er ook maar één computer aan zou hangen is het misschien ook wat overdadig.

[Verwijderd]

CiPHER, ik heb nog eens het geheel doorgemeten, en kom toch echt bijna consequent aan de 75-80% load volgens vcenter:


De grap is alleen dat wanneer ik top -P doe, de load gemiddeld rond de 45-50% is. Hiervan is 40-45% system, en 5% interrupts. Maar zelfs dat vind ik veel, als ik kijk naar de behaalde resultaten:


Ik heb bij de benchmark verder geen dedup/compress aangezet.

Het enige wat me wél is opgevallen: is dat de snelheid achteruit is gegaan sinds ik de 2TB schijven op heb genomen in de pool Data. (10x2&10x4). Eerst haalde ik ca 1GB/s read met enkel de 4TB schijven. (Het betrof wel een lege array destijds). Verder staat ashift=12 aan, en ik vermoed dat mijn 2TB schijven 512B sectors hebben. Wellicht dat dit er ook iets mee van doen heeft?

Bij kleine datasets (128MB-16GB) lukt het wel om met meerdere GB/s te lezen. Schrijven gaat bij de extreem kleine datasets ook met meerdere GB/s, en bij 8 en 16GB met ca 900MB/s (ZIL op ssd's, gok ik zo). CPUgebruik is volgens zfs dan ook hoger: deze zit in de kleinste datasets op 70% volgens freebsd zelf.


Nog bedankt mbt GELI btw, ik zal er eens een dezer dagen in duiken.

[Verwijderd]

Virtualisatie zal waarschijnlijk je load flink verhogen. Als je bare metal ZFSguru zou installeren en dezelfde benchmark uit zou voeren, haal je waarschijnlijk per 100MB/s een véél lagere CPU-belasting.

2TB schijven zijn waarschijnlijk trager dan de 4TB schijven die je hebt. 512B-sectoren is zeer uitzonderlijk voor 2TB schijven; ik ken alleen Hitachi en sommige serverachtige schijven die dat hebben. En dat zou ook geen probleem mogen zijn als je ashift=12 gebruikt in combinatie met 512B-schijven. Dat bijt elkaar niet. Andersom wel (ashift=9 met 4K-schijven).

Bedenk wel met GELI dat je niet delen van je ZFS pool kunt encrypten. Met GELI kun je encryptie op de volgende manieren implementeren:

• Individuele disks encrypten; mijn favo methode. Je maakt dan een script om elke disk te encrypten. Eigenlijk hoef je alleen enkele disks te encrypten, zoals 3 disks met een RAID-Z2 als je het alleen lastig wilt maken; want ZFS recoveren is enorm lastig op die manier. Let wel op dat je elke disk een andere sleutel geeft. Ik zelf gebruik een script die om een wachtwoord vraagt en daarachter iets plakt als "-disk1" in het wachtwoord; zodat elke disk toch een ander wachtwoord gebruikt terwijl ik maar één keer mijn wachtwoord opgeef.
• Een ZVOL encrypten. Op de encrypted ZVOL maak je dan weer een zfs pool. Je slaat dan dus een 2e (encrypted) ZFS pool op je main pool op. Wel iets trager en minder flexibel qua ruimte. Maar dit kun je altijd achteraf doen zonder veel poespas.
• Zelfde als hierboven maar dan een file-container die een pool voorstelt, met mdconfig. Iets sneller meestal, maar eigenlijk minder netjes.

Mijn voorkeur gaat uit naar de eerste methode. Je kunt dat misschien ook achteraf doen. Je kunt dan één disk detachen van je pool, deze van encryptie voorzien en random writen. Dan weer attachen op de pool zodra je hem encrypted hebt. Dat herhalen voor elke disk (of slechts 3 disks). Zoiets als:

1: detach/offline disk in ZFSguru pools pagina
2: geli init -l 256 /dev/gpt/disk6 (let op -l = -L en niet -i)
3. geli attach /dev/gpt/disk6
4: dd if=/dev/random of=/dev/gpt/disk6.eli bs=1M (dit gaat HEEL lang duren, /dev/zero is veel sneller, of je slaat dit over)
5: online/replace de disk in ZFSguru; nu gebruik je /dev/gpt/disk6.eli met dus de .eli suffix erachter.

Het enige probleem kan zijn dat je nieuwe disk net een sector kleiner is, dat kan irritant zijn als ZFS alle ruimte op de disks gebruikt. In dit geval moet je wel alles overnieuw doen.

[Verwijderd]

FireDrunk schreef op dinsdag 09 juli 2013 @ 21:40:
ReFS is er, maar dat komt nog niet echt in de buurt van ZFS.

Ik Google uiteraard zelf ook, maar op de welke manieren niet?

[FireDrunk]

Dat hoort hier niet echt, maar ZFS ondersteund veel meer slimme en moderne technieken dan ReFS.
ReFS heeft wel checksums, maar volgens mij geen checksums op metadata.
ZFS heeft ARC, L2ARC, Hardwarematige encryptie, online data deduplication.

Features die maar half of niet aanwezig zijn in ReFS.

Maar ik weet niet zo goed of dit het topic is om dat te bespreken, CiPHER, wat vind jij?

[Verwijderd]

Er is nog geen ReFS-topic. Binnenkort zou dat wel kunnen denk ik, zodra er voldoende animo voor is en iemand een goede topicstart wilt schrijven. Tot die tijd mag wat mij betreft vergelijkingen tussen Btrfs en ReFS met ZFS wel in dit topic. Specifieke vragen over Btrfs en ReFS weer niet, maar een vergelijking tussen de drie next-gen filesystems kan wel wat mij betreft.

Zoals ik het tot nu toe begrepen heb, ligt ReFS achterop op het gebied van features, performance, stabiliteit en beschikbaarheid. Het meest uitontwikkelde next-gen filesystem is en blijft ZFS, gevolgd door Btrfs. ReFS staat daar op enige afstand van. Desondanks kan ReFS heel goed de vervanger worden van NTFS zodra ook consumenten hiervan massaal gebruik gaan maken. Wat wel een groot nadeel is, is dat zowel Btrfs en ReFS maar op één platform werken. ZFS werkt op meerdere platforms (Solaris, BSD, Linux) - eigenlijk op alles behalve Windows dus.

[Verwijderd]

FireDrunk schreef op woensdag 10 juli 2013 @ 10:51:
ZFS ondersteund veel meer slimme en moderne technieken dan ReFS.
ReFS heeft wel checksums, maar volgens mij geen checksums op metadata.
ZFS heeft ARC, L2ARC, Hardwarematige encryptie, online data deduplication.

Features die maar half of niet aanwezig zijn in ReFS.

Waar ik mij het meeste zorgen over maak bij NTFS is het corrupt raken van data zonder dat je het door hebt. Dan heb je een prachtige backup/mirror klaarstaan als de boel in de soep loopt, maar kom je er dan pas achter dat ook die data niets meer waard is. Met de toenemende hoeveelheid data op moderne systemen wordt zoiets natuurlijk waarschijnlijker - puur statistisch gezien en ook omdat je data langer niet gebruikt. Dit is eigenlijk de primaire reden voor mij om eens verder te kijken.

Zaken als encryptie vind ik persoonlijk minder interessant - ik heb altijd sterk de indruk dat mij dat meer tegenwerkt bij bijvoorbeeld het recoveren van een disk dan de voordelen die het biedt wanneer een schijf gestolen wordt. Toegegeven ben ik er ook nooit heel diep ingedoken, deels omdat mijn data niet superkritisch is.

Edit: ik lees hier Metadata integrity with checksums. Dat lijkt ReFS dus wel te hebben

[ Voor 8% gewijzigd door Verwijderd op 11-07-2013 05:45 ]

[Verwijderd]

Dus... ik ben een beetje in de war. Ik weet dat Microsoft ReFS eerst voor Windows Server uitbrengt, vervolgens als non-bootable volumes op consumentenniveau en vervolgens ook als systeem voor de boot drive. Ook kan ik vinden dat je met bepaalde trucs ReFS kunt gebruiken op de Windows 8 consumer preview.

Wat ik niet kan vinden is of ik ReFS nu als consument kan gebruiken voor mijn storage disks in Windows 8 Pro, met of zonder truc. Het complete gebrek aan informatie suggereert van niet, maar misschien dat iemand daar een licht op kan werpen?

Edit: dit suggereert weer dat het wel kan.

[FireDrunk]

Je kan in Windows 8 Storage Spaces gebruiken icm ReFS. Dan zit je al redelijk veilig.
En Windows 8 Consumer Preview hoef je echt niet meer te gebruiken...

[ Voor 30% gewijzigd door FireDrunk op 11-07-2013 09:34 ]

[Tsurany]

Klein vraagje, ik ga hopelijk dit weekend een ZFS systeem opzetten onder ESXi. Nu heb ik 4x1TB en 4x1,5TB die beiden in RAIDZ komen te staan. Dan heb ik dus twee vdev's en die zou ik uit praktisch oogpunt in een enkele pool willen zetten. Echter wil ik ook gebruik maken van spindown omdat het vooral media data is die eigenlijk amper tot niet benaderd gaat worden. Het is in de nachtelijke uren de nieuwe mediabestanden bijschrijven (downloaden gebeurt op een andere schijf) en in de avonduren de data benaderen omdat ik t wil kijken.

Nu zal die 4x1TB eerst volgegooid worden omdat dit tijdens migratie van harde schijven het meest praktisch is (ze zijn al gevuld). Vervolgens zal ik die 4x1,5TB gaan vullen tot de helft en dan komt vervolgens alle nieuwe data daar bij.

Is het dan handig om ze wel of niet in een enkele pool te zetten? Want als ik een bestand nodig heb op een van de vdev's zullen ze beiden opspinnen neem ik aan? Dan kan het dus praktisch zijn om geen enkele pool te maken?

[Verwijderd]

Zonder pool geen ZFS. Een pool bestaat uit minstens één vdev. In jouw geval kun je dus kiezen voor:

Optie 1: één pool met twee vdevs
pool: tank
vdev1: RAID-Z van 4x1TB
vdev2: RAID-Z van 4x1,5TB

Als je hier gegevens naar schrijft, worden beide vdevs gebruikt. Er is dus geen sprake van dat eerst de ene vdev gevuld wordt en daarna pas de andere. Beide vdevs worden gebruikt om gegevens naartoe te schrijven.

Optie 2: twee aparte pools
Pool: tank
vdev1: RAID-Z van 4x1TB

Pool: extra
vdev2: RAID-Z van 4x1,5TB

Hier is er sprake van twee pools. Dus je hebt ook twee keer vrije ruimte. Pool 'tank' kan vol zitten terwijl je nog wel ruimte hebt op de 'extra' pool. Dat is minder flexibel. Voordeel is wel dat je de ene pool spinned down kunt hebben terwijl je op de andere werkt.

[Verwijderd]

FireDrunk schreef op donderdag 11 juli 2013 @ 09:32:
Je kan in Windows 8 Storage Spaces gebruiken icm ReFS. Dan zit je al redelijk veilig.
En Windows 8 Consumer Preview hoef je echt niet meer te gebruiken...

Ik wil een RAID-achtige mirror voorkomen; liever heb ik een echte mirror die iets van één keer per week backupt, in het geval van corruptie door slechte kabels/RAM/een andere oorzaak.

Dan heb je net iets meer tijd om problemen te ondervangen.

[FireDrunk]

Iemand die hier mee kan helpen?

Ik word gek, ik heb alles al geprobeerd.

Boven is lokale SSD, onder is SSD Pool op ZFS met een 840 Pro als ZIL.
(Ja je leest het goed, 4 SSD's en een 840 Pro als ZIL...)

(Overigens is de lokale read laag omdat het maar om een SATA2 controller gaat.)

ESXi is vers geinstalleerd en de nieuwste versie, en de ZFS VM is een vers geinstalleerde ZFSGuru met VMWare Tools geinstalleerd (En maakt gebruik van vmxnet3)

[ Voor 32% gewijzigd door FireDrunk op 11-07-2013 11:44 ]

[Tsurany]

Verwijderd schreef op donderdag 11 juli 2013 @ 11:07:
Zonder pool geen ZFS. Een pool bestaat uit minstens één vdev. In jouw geval kun je dus kiezen voor:

Optie 1: één pool met twee vdevs
pool: tank
vdev1: RAID-Z van 4x1TB
vdev2: RAID-Z van 4x1,5TB

Als je hier gegevens naar schrijft, worden beide vdevs gebruikt. Er is dus geen sprake van dat eerst de ene vdev gevuld wordt en daarna pas de andere. Beide vdevs worden gebruikt om gegevens naartoe te schrijven.

Optie 2: twee aparte pools
Pool: tank
vdev1: RAID-Z van 4x1TB

Pool: extra
vdev2: RAID-Z van 4x1,5TB

Hier is er sprake van twee pools. Dus je hebt ook twee keer vrije ruimte. Pool 'tank' kan vol zitten terwijl je nog wel ruimte hebt op de 'extra' pool. Dat is minder flexibel. Voordeel is wel dat je de ene pool spinned down kunt hebben terwijl je op de andere werkt.

Kan je later aan een pool een extra vdev toevoegen? Ik moet wel eerst een van de twee vdev's vullen omdat ik op dit moment alle schijven al vol heb zitten. Ik heb straks 4x1TB en 1x1,5TB aan gevulde schijven in NTFS en dan 3x1.5TB aan lege schijven. Plan is om eerst die 4x1TB leeg te maken, in een vdev te zetten en vervolgens weer te vullen. Dit kan door de lege schijven te benutten. Daarna moet ik nog 1,5TB aan data kwijt, dit verspreid ik onder bestaande systemen om vervolgens terug de schrijven naar de 4x1,5TB vdev.

Dus ik kan dan een pool maken met 4x1TB en die vullen en daarna de pool uitbreiden met 4x1,5TB? Wellicht is het dan toch praktischer om met twee pools te werken omdat dan niet alle schijven hoeven te draaien als ik een van de twee pools wil aanspreken.

[Verwijderd]

@FireDrunk: screenshot van 'gstat -f gpt' tijdens de sequential write benchmark?

@Tsurany: ja je kan gewoon eerst je pool maken met de 1e vdev, dan bestanden kopiëren. Daarna de 2e vdev toevoegen aan dezelfde pool. Dan heb je uiteindelijk één pool met de vrije ruimte van beide vdevs. Enig klein nadeel is dat je gegevens die je hebt overgezet dan allemaal op de 1e vdev staan; ZFS doet achteraf geen load balancing. Dat betekent dat je iets minder performance hebt voor de bestaande gegevens. Je kunt dit achteraf wel corrigeren door de bestaande directories te kopiëren naar een andere naam en dan de originele dir te verwijderen. Dus zeg maar alle bestaande data opnieuw schrijven dan wordt het automatisch over beide vdevs verdeeld.

[Tsurany]

Dan denk ik dat ik gewoon voor twee pools ga, dat is minder gedoe en dan hoeven niet telkens acht schijven te draaien als ik data wil benaderen.

[FireDrunk]

[Verwijderd]

Je 840Pro (die je als SLOG gebruikt) is erg op de load. Verwijder je SLOG-device eens en doe dan de test eens overnieuw?

[FireDrunk]

(bijna) zelfde resultaat.

[ Voor 67% gewijzigd door FireDrunk op 11-07-2013 12:52 ]

[revox862]

Write-cache (ik roep maar wat)?

[Verwijderd]

Oke, nou het ligt dus niet aan de disks (de SSDs) want die zijn maar minimaal belast. Je maakt gebruik van SMB/CIFS neem ik aan? Kun je eens een ander protocol proberen? NFS of FTP; dat laatste kan redelijk gemakkelijk met Pure-FTPd (in de portstree). Pure-FTPd is gemakkelijk te configgen vanaf de command line, lekker handig voor een simpele performance test.

Performanceproblemen isoleren is meestal mijn methode. Ik probeer te onderscheiden:

• Lokale disk performance (gstat, zelf testjes doen met dd)
• Netwerk performance (iperf; voor Windows heb je een grafische jperf client bijvoorbeeld)
• Protocol performance (Samba-specfieke settings, maar kun je makkelijk uitsluiten door een ander protocol te proberen zoals NFS of FTP)

Als je dan de oorzaak te pakken hebt, dan kun je zo het probleem verder gaan isoleren. In jouw geval lijkt VMXNET3 wel goed te werken omdat je read wel lekker hoog is. Maar als ook FTP traag is dan zul je ook dit moeten uitsluiten.

[ Voor 46% gewijzigd door Verwijderd op 11-07-2013 13:49 ]

[FireDrunk]

Nee, dit is NFS. Write cache is niet aan de orde, het gaat om zfs.

[Ultraman]

Een vraag: Waarom een SSD ZIL voor een SSD pool?

[edit]
Een reden die ik kan bedenken is als de SSD's in de pool geen supercaps hebben, die de 840 Pro wel heeft, en je zo jezelf qua writes wilt indekken voor een stroomuitval.
Als dat echter de reden is en om echt oms (bedrijfs)kritische data gaat, dan lijkt me een UPS een betere investering. Want de SSDs in de pool kunnen alsnog zelf corrupt raken in zo'n geval en dan is de hele pool gewoon naar de klote

[ Voor 117% gewijzigd door Ultraman op 11-07-2013 14:12 ]

[Oid]

laatste versie van ZFSguru? daar heb ik namelijk ook problemen mee met snelheid binnen esxi icm nfs, daarom staat bij mij versie 8 er op die heeft wel lekkere snelheden. misschien kan je er wat mee

Powered by ZFSguru version 0.2.0-beta8
Running official system image 8.3-001 featuring FreeBSD 8.2-STABLE with ZFS v28.
Running Root-on-ZFS distribution.

had het niet iets te maken met async oid?

Ultraman schreef op donderdag 11 juli 2013 @ 13:50:
Een vraag: Waarom een SSD ZIL voor een SSD pool?

goede vraag, ben ik ook wel benieuwd naar

[ Voor 25% gewijzigd door Oid op 11-07-2013 14:00 ]

[FireDrunk]

Om te kijken of het uit maakt. De write latency van de 840 is veel lager dan die van de andere ssds. Hierdoor kunnen de ssds doorwerken als er sync writes langskomen.

Maar los van de zil is de performance waardeloos...

[ Voor 14% gewijzigd door FireDrunk op 11-07-2013 14:21 ]

[duiveltje666]

Oid schreef op donderdag 11 juli 2013 @ 13:59:
laatste versie van ZFSguru? daar heb ik namelijk ook problemen mee met snelheid binnen esxi icm nfs, daarom staat bij mij versie 8 er op die heeft wel lekkere snelheden. misschien kan je er wat mee

Powered by ZFSguru version 0.2.0-beta8
Running official system image 8.3-001 featuring FreeBSD 8.2-STABLE with ZFS v28.
Running Root-on-ZFS distribution.

had het niet iets te maken met async oid?


[...]


goede vraag, ben ik ook wel benieuwd naar

8.2 stable ? waarom zou je dat willen? afaik heeft die geen security updates meer

[FireDrunk]

Ik ga de pool vanavond eens proberen om te bouwen naar mijn fysieke server. Dan ben ik wel gelimiteerd tot 1Gb maar dan kan ik wel kijken of de iops hoger worden...

Zojuist Nas4Free geprobeerd, dat helpt (zonder SLOG) iets, maar niet veel, ipv 900 iops haalde ik 1000 iops. Bench met SLOG loopt nu.

Ook met SLOG maakt het onder Nas4Free niets uit.

Ik heb de disks zonder ZFS getest, en qua lezen haal ik als ik 4 DD commando's tegelijk doe, ruim 170MB/s per schijf. Er is dus duidelijk niets mis met VT-d, ESXi of de controller zelf, want dat performt dus duidelijk prima.

Misschien interesant leesvoor voor sommigen:
http://nex7.blogspot.nl/2013/03/readme1st.html

SSD Array in mijn fysieke server, (Core i5-3550, 16GB RAM, FreeBSD 10)
Getest vanaf ESXi over 1Gb Intel netwerkkaarten....


Soms denk ik echt, waar doen we het allemaal voor...

[ Voor 80% gewijzigd door FireDrunk op 12-07-2013 15:58 ]

[FireDrunk]

Via SMB is het een en ander toch sneller...

[Verwijderd]

Oke, dan kan het liggen aan NFS. Heb je bijvoorbeeld geprobeerd sync=disabled in te stellen op de filesystem die je met NFS test? En ook kun je de oude NFS server gebruiken. Check /etc/defaults/rc.conf voor wat opties met betrekking tot NFS.

Kleine offtopic tip:
ee /etc/defaults/rc.conf
control-Y = zoeken, vul in: nfs
Control-X = next-search result

[FireDrunk]

Ik gebruik SSD's dan zou sync aan nog steeds veel betere resultaten moeten geven, vanwege de lage latency...

Tuurlijk zal sync disabled sneller zijn, maar dat verteld mij niets, en is ook niet wat ik wil...

(maar ik zal het even testen...)

[ Voor 7% gewijzigd door FireDrunk op 12-07-2013 16:40 ]

[Xudonax]

Xudonax schreef op zaterdag 22 juni 2013 @ 20:53:
Wel ben ik van plan om twee 32GB SSDs* toe te voegen als L2ARC devices. Grofweg 16GB van beide SSDs wil ik gebruiken als caching voor mijn (nu nog) RAIDZ array van 500GB schijven welke als iSCSI het netwerk op gaan, en 8GB wil ik gaan gebruiken voor mijn algemene ZFS pool waar van alles en nog wat op gebeurd. Dit is een RAID-Z2 array op 1TB notebook schijven.

Okay... Deze SSDs heb ik een aardige tijd in gebruik gehad, maar ze zorgden ervoor dat ik bij het opstarten consequent een kernel panic kreeg. Als ze het deden dan werkten ze perfect en deden ze precies wat de bedoeling was, maar een kernel panic bij het opstarten vond ik geen héél fijn idee.

Ik heb de dingen nu dus verdeelt over Windows PCs waar ze hopelijk gewoon hun normale doel kunnen volbrengen Wel is er een nieuwe SSD naar mij onderweg welke maandag/dinsdag erin mag en dan gaat dienen als SLOG/cache device. Eens kijken of dat beter werkt ^_^

[FireDrunk]

Welke heb je besteld?

[Xudonax]

Ik ben voor zeker gegaan en heb gekozen voor een Intel 320 SSD 120GB. Dat zou een stuk eenvoudiger moeten zijn dan de brakke dingen die ik had

[FireDrunk]

Laten we het hopen

[Xudonax]

Ok, schijnbaar was het niet de SSD die het systeem bij het opstarten over z'n nek liet gaan, dat gebeurt namelijk nog steeds Dat word dus gezellig backtraces proberen te filmen om te kijken waar de oorzaak ligt zodat ik een fatsoenlijke Google zoektocht kan doen of een bug kan fillen bij ZFS on Linux.

Ik heb namelijk geen zin om ZFS te gaan virtualiseren, en er draait teveel ander speelgoed op die bak om met ZFSGuru en vriendjes te gaan spelen (denk aan KVM met een stapel Windows VMs, Deluge voor torrents, XBMC voor het home cinema stukje etc.).

[FireDrunk]

Post de message anders eens.

[Habana]

Na nieuwsgierig geworden te zijn, door CiPHER zijn mooie verhalen over ZFS en het één en ander gelezen te hebben, gisteravond en vandaag met ZFSguru aan het stoeien geweest, en alles werkt als een speer, dus voor zover prima.
Maar één ding ziet er mi. een beetje vreemd uit, ieder geval iets waar ik over twijfel, als ik kijk naar de pool (RAID-Z1 single parity like RAID5) die ik aangemaakt heb met 5x 2TB-WD20EARX drives, en word aangegeven in "ZFS pool configuration" dat deze RAID5 (single parity) is en Capacity 9.06TB, als ik het goed begrepen heb zou dus 1 Drive uit mogen vallen? toch? maar dan zou ik toch minder als de 9.06TB moet hebben.
Ben ik nu even de weg kwijt, zie ik iets over het hoofd?

Heren FireDrunk en CiPHER, dank jullie voor de uitleg/toelichting en CiPHER in het bijzonder,door de ZFSguru Live CD appeltje eitje zou ik bijna zeggen en ik moet zeggen dat het is heel leuk is om even met te ZFSguru stoeien en het valt zeker niet tegen, ik had nog een compleet systeem over met een 3770K met 16GB mem welliswaar een beetje teveel van het goede, SSD eruit en de vijf drives erin, enkel om er even mee te spelen en wat ervaring op te doen , ik heb al jaren een synology nas ook een prima ding, maar dit is veel leuker ,sowieso is zelf bouwen is altijd leuker , en om weer wat nieuws te leren.
Ik heb nog een nieuwe ongebruikte ASUS P8H77-I mini ITX met 6 Sata poorten, dat lijk me een prima boardje voor de nieuw ZFS Nas met de eerder genoemde drives., enkel nog een Processor voor dit boardje scoren, hebben jullie nog advies in deze.

[ Voor 37% gewijzigd door Habana op 13-07-2013 20:34 ]

[FireDrunk]

Je pool heeft altijd de volledige ruimte vrij, een filesystem geeft iets beter weer hoeveel ruimte je daadwerkelijk vrij hebt.

Maar je hebt gelijk als je zegt dat het soms onduidelijk is. Dit komt door een heleboel factoren, en is niet heel makkelijk uit te leggen.

Ik geloof dat CiPHER er al wel een keer een post aan gewijd heeft. Maar die zal je even moeten zoeken.
Hij heeft het in de post over het verschil tusse zpool list en du -h.

[Verwijderd]

ZFS pool denkt niet in termen van bruikbare opslagruimte, maar in termen van ruwe opslagruimte. Dus een RAID-Z van 3x2TB wordt gezien als 6TB ruw, terwijl ZFS filesystem 4TB bruikbaar zal aangeven.

Er zijn nog veel meer verschillen; als je bijvoorbeeld copies=2 instelt dan vul je de beschikbare ruimte twee keer zo snel. Ook kun je ruimte reserveren, waardoor ZFS filesystem aan zal geven dat er nog maar X ruimte vrij is, terwijl de pool zich hier niets van aantrekt en onveranderd zal blijven. Ook heb je sparse files; je kunt heel snel een 2TB groot bestand aanmaken - zoals een container voor een virtuele disk tbv. virtualisatie - maar die ruimte is niet daadwerkelijk beschreven. Dan zal zfs list wel vrije ruimte afsnoepen terwijl zpool list geen verandering zal tonen.

Kortom, het zijn twee werelden. Er staat overigens wel een melding in de ZFSguru web-interface hierover; dat de Pools en Filesystems pagina de ruimte verschillend weergeven. Maar dit is dus puur het gevolg van ZFS zelf, niet van ZFSguru.

Ps. dit verhaal gaat over het verschil tussen de output van zfs list en zpool list. Je hebt ook de utility 'du' (Disk Usage). Met du -sh . kun je de ruimte zien van de huidige directory. Met du -Ash . dus met de -A flag erbij krijg je de apparent size te zien, dus de grootte van het bestand of de directory, ongeacht hoeveel ruimte het gekost heeft om deze op te slaan. Maar du weet verder niets van pool redundancy, maar zaken als deduplicatie en compressie en copies worden mij wel meegewogen. Dus met copies=2 laat du -A gewoon 2MB zien terwijl du 4MB zal laten zien; de echte ruimte wat het kostte om het bestand op te slaan.

[ Voor 24% gewijzigd door Verwijderd op 13-07-2013 16:35 ]

[Xudonax]

FireDrunk schreef op zaterdag 13 juli 2013 @ 14:10:
Post de message anders eens.

Dat gaat niet, want screen blanking stond aan Echter, sinds het verwijderen van de SSDs lijkt het mis te lopen in de Intel KMS/DRM code...Typisch Fedora, heb het al vaker gehad. Waarschijnlijk gefixt in de volgende release. Voor nu in ieder geval console blanking uitgezet zodat *mocht* het mis gaan, dan kan ik iig zien wat er mis ging ^_^

EDIT: Gotcha! Maar dit ziet er niet echt uit als een ZFS error, hoewel de trace daar wel naartoe wijst... De exacte melding aan het einde van de trace is "[ 4024.947212 ] Kernel panic - not syncing: Fatal exception in interrupt". ZFS doet niets met interrupts lijkt me?

Ik heb de bug nog niet bij ZFS on Linux gerapporteerd, ik ben eerst even benieuwd of ik hier wel de juiste verdachte aanwijs. De (POF) en (OF) in de module lijst doen me wel ZFS verdenken, maar misschien dat er mijn M1015 er niet goed inzit ofzo? (deze ga ik sowieso even opnieuw aansluiten)

Volledige trace is:

code:

[ 4023.643608 ] ------------[ cut here ]------------
[ 4023.644117 ] kernel BUG at kernel/timer.c:1081!
[ 4023.644712 ] invalid opcode: 0000 [#1] SMP
[ 4023.645309 ] Models linked in: ip6table_filter ip6_tables ebtable_nat ebtables xt_CHECKSUM iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack bridge stp llc be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser bnep bluetooth rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi mptctl mptbase zfs(POF) zunicode(POF) zavl(POF) zcommon(POF) arc4 snd_hda_codec_hdmi snd_hda_codec_realtek spl(OF) zlib_deflate iTCO_wdt iTCO_vendor_support iwldvm mac80211 snd_hda_intel snd_hda_codec snd_hwdep acpi_cpufreq mperf snd_seq iwlwifi coretemp i915 snd_seq_device microcode cfg80211 serio_raw i2c_i801 snd_pcm rfkill snd_page_alloc snd_timer lpc_ich i2c_algo_bit mfd_core snd drm_kms_helper soundcore mei drm vhost_net tun macvtap macvlan kvm_intel nfsd kvm i2c_dev i2c_core auth_rpcgss nfs_acl lockd uinput crc32_pclmul crc32c_intel ghash_clmulni_intel firewire_ohci e1000e firewire_core mpt2sas crc_itu_t ptp raid_class pps_core scsi_transport_sas video sunrpc
[ 4023.776866 ] CPU 4
[ 4023.777138 ] Pid: 29, comm: ksoftirqd/4 Tainted: PF      W 0 3.9.9-201.fc18.x86_64 #1 /DH77DF
[ 4023.840442 ] RIP: 0010:[<ffffffff8106eb93>] [<ffffffff8106eb93>] cascade+0x93/0xa0
[ 4023.873765 ] RSP: 0018:ffff880408941d28 EFLAGS: 00010086
[ 4023.903637 ] RAX: 0000000000000000 RBX: ffff88004ff76910 RCX: ffff880078c9fa70
[ 4023.933720 ] RDX: 0000000000000023 RSI: ffff8802a3bedd00 RDI: ffff880408950000
[ 4023.962762 ] RBP: ffff880408941d58 R08: ffff880408950e28 R09: 0000000000000000
[ 4023.993460 ] R10: 0000000000000001 R11: 0000000000000001 R12: ffff880408950000
[ 4024.024750 ] R13: ffff880408941d28 R14: 0000000000000023 R15: 0000000000000000
[ 4024.087062 ] FS:  0000000000000000(0000) GS:ffff88041f300000(0000) knlGS:0000000000000000
[ 4024.118337 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4024.151045 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4024.182855 ] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 4024.214525 ] Process ksoftirqd/4 (pid: 29, threadinfo ffff880408940000, task ffff880408938000)
[ 4024.247573 ] Stack:
[ 4024.281051 ]  ffff8802a3bedd00 ffff88006f2a2910 ffff880408950000 0000000000000000
[ 4024.315430 ]  0000000000000001 0000000000000001 ffff880408941dd8 ffffffff8106f838
[ 4024.350296 ]  ffff880408951c28 ffff880408951828 ffff880408951428 ffff880408951028
[ 4024.384432 ] Call Trace:
[ 4024.417541 ]  [<ffffffff8106f838>] run_timer_softirq+0x238/0x2a0
[ 4024.452017 ]  [<ffffffff81067678>] __do_softirq+0xe8/0x230
[ 4024.486796 ]  [<ffffffff810677f0>] run_ksoftirqd+0x30/0x50
[ 4024.521714 ]  [<ffffffff8108a8ef>] smpboot_thread_fn+0x10f/0x1a0
[ 4024.555204 ]  [<ffffffff8108a7e0>] ? lg_global_unlock+0x60/0x60
[ 4024.589396 ]  [<ffffffff81082ba0>] kthread+0xc0/0xd0
[ 4024.623318 ]  [<ffffffff81010303>] ? perf_trace_xen_cup_set_ldt+0x33/0xe0
[ 4024.657469 ]  [<ffffffff81082ae0>] ? kthread_create_on_node+0x120/0x120
[ 4024.692435 ]  [<ffffffff8166af2c>] ret_from_fork+0x7c/0xb0
[ 4024.727537 ]  [<ffffffff81082ae0>] ? kthread_create_on_node+0x120/0x120
[ 4024.761355 ] Code: 89 c3 48 83 e1 fc 49 39 cc 75 20 4c 89 e7 e8 35 f8 ff ff 4c 39 eb 48 8b 03 75 dd 48 83 c4 10 44 89 f0 5b 41 5c 41 5d 41 5e 5d c3 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89
[ 4024.835600 ] RIP [<ffffffff8106eb93>] cascade+0x93/0xa0
[ 4024.869732 ]  RSP <ffff880408941d28>
[ 4024.908356 ] ---[ end trace d2ec33da37bb2b1e ]---
[ 4024.947212 ] Kernel panic - not syncing: Fatal exception in interrupt
[ 4026.057188 ] Shutting down cups with NMI

EDIT2: Ineens een andere ingeving. Ik ga die bak vannacht eens even memtest laten draaien. Eens zien wat daar uit komt

EDIT3: Nou, memtest86 levert dus geen fouten op na 5 passes, ik mag dus aannemen dat het geheugen het probleem niet is in dit geval. Dan gaan we verder zoeken... Ik denk dat ik mijn Intel WiFi er maar weer uitsloop...

EDIT4: Even op de bugtracker van ZoL gekeken, en dit is schijnbaar iets bekends in de laatste updates. Ik ga dus maar even kijken of ik nog een oude versie (0.6.0 ofzo) kan krijgen. Nadeel is wel dat het nu pool versie 5000 moet ondersteunen >_<

[ Voor 86% gewijzigd door Xudonax op 14-07-2013 14:19 ]

[Tsurany]

Net ZFSGuru geinstalleerd, draait allemaal prima. Benchmark is volgens mij ook redelijk positief.
ZFSguru 0.2.0-beta8 (9.1-005) pool benchmark
Pool : RAID-Z_5x1TB (4.53T, 0% full)
Test size : 64 GiB
normal read : 351 MB/s
normal write : 207 MB/s
I/O bandwidth : 23 GB/s

[Xudonax]

Ziet er goed uit, maar is die write niet wat laag? Ik weet dat ik met mijn set op 0% gevuld ~350MB/s deed op een RAIDZ2 setje van goedkope notebookschijfjes...Maargoed, dit is sowieso meer dan het gemiddelde netwerk kan verstouwen

Vraagje aan d ZFSGuru mensen trouwens, wat moet die bandwidth voorstellen? Ik zie het namelijk wel iedere keer, maar ik kan me er niets bij voorstellen

[Tsurany]

Geen idee of dat laag is. Kan me geen situatie voorstellen waarbij ik sneller dan dat zou willen schrijven
Enig issue is dat ZFSGuru mij niet bevalt qua webinterface, vind het geen fijn en overzichtelijk systeem.

[Verwijderd]

I/O bandwidth is de maximale I/O throughput die je systeem aankan, wat neerkomt op geheugenbandbreedte bruikbaar door FreeBSD. Dit kun je zien als bovengrens; het kan nooit sneller worden dan dit. Als de bandwidth heel laag is, kan dat duiden op bottlenecks. Aangezien ZFS heel geheugenintensief is, kan een lage bandbreedte wel degelijk prestaties remmen. Bedenk hierbij dat een I/O stroom zorgt voor meerdere geheugenacties, zodat je voor 1GB/s misschien wel 10GB/s geheugenbandbreedte nodig hebt.

@Tsurany: wel vreemd dat je de ZFSguru web-interface niet overzichtelijk vindt, want ik hoor juist het tegenovergestelde. Kun je aangeven wat je er niet fijn of duidelijk aan vindt? Wat vind je dan de overige interfaces zoals NAS4Free, FreeNAS, OpenMediaVault? Ik hoor namelijk juist het tegenovergestelde, dat mensen die interfaces te ingewikkeld en onoverzichtelijk vinden, en de ZFSguru interface duidelijk opgezet en zonder onnodige poespas.

[Tsurany]

Ik heb er nog niet zeer uitgebreid naar gekeken maar bijvoorbeeld het instellen van shares vind ik erg onoverzichtelijk, het is mij absoluut niet duidelijk hoe dit zou moeten en ik moet hiervoor echt online zoeken naar het antwoord. Op FreeNAS ging dit een stuk makkelijker en had ik heel snel al een eerste share aangemaakt. Het is daar een stuk duidelijker welke optie wat gaat veroorzaken.
Nas4Free heb ik nog niet gebruikt dus daar kan ik weinig over zeggen. Denk dat ik dit morgen nog even ga testen in een VM.

In ieder geval ben ik nu een ZFS pool aan het vullen met data zodat ik daarna van de straks lege schijven een tweede pool kan maken. Dan heb ik alle data overgezet en kan ik eenvoudig wisselen tussen de verschillende systemen.

[Verwijderd]

Aanmaken van Samba share is met één knop geregeld, op de files pagina klik je op de knop 'Share with Samba' boven de 'Share with NFS' knop. Dus makkelijker kan niet? Wel is de Samba management heel verouderd, maar juist dat is geheel herschreven in de komende beta9 versie, die nog niet uit is.

Maar test vooral uit de verschillende web-interfaces. Ik ben erg geïnteresseerd in je mening en bevindingen. Helpt mij ook om ZFSguru beter te maken, juist door feedback als deze. Je mag me ook DMen als het heel specifiek wordt. Hoe specifieker, hoe beter eigenlijk. Dan kan ik wijzigingen doorvoeren en heb jij dus ook veel invloed op de ontwikkeling van ZFSguru. Dat onderschatten mensen nogal vaak.

[FireDrunk]

Ik zal wel weer de boeman zijn hoor, maar er word al sinds 12 november vorig jaar over beta9 gesproken en in de tussentijd is zelfs de bug met het toevoegen van SLOG devices via de webinterface nog niet eens opgelost...

Dat geeft niet echt veel vertrouwen

[B2]

FireDrunk schreef op maandag 15 juli 2013 @ 08:09:
Ik zal wel weer de boeman zijn hoor, maar er word al sinds 12 november vorig jaar over beta9 gesproken en in de tussentijd is zelfs de bug met het toevoegen van SLOG devices via de webinterface nog niet eens opgelost...

Dat geeft niet echt veel vertrouwen

Inderdaad, door dit soort dingen ben ik ook van ZFSGuru afgestapt en naar ZoL gegaan.

[jacovn]

Er stond op het ZFSguru forum zelfs dat er afgelopen weekeinde nieuws zou komen, althans daar leek de post op..

Wat betreft de userinterface, die vindt ik wel makkelijk te doorgronden. Enige waar ik tegenaan liep dat ik de share niet onder de pool kon vinden (dat leek me logisch, maar achteraf gezien wel logisch dat je je filesystem shared en niet de fysieke pool)

Wat ik wel prima vindt is dat de sequrity gelijk goed staat (open), en ik zo van de server kan streamen zonder password geneuzel etc. Dat vondt ik het grootste nadeel van al de 2 andere systemen die ik geprobeerd heb: openindiana en nas4free)

[FireDrunk]

Tja dat is voor jou een voordeel, maar ik vind het belachelijk beroerd waardeloos slecht dat je een NAS appliance maakt die by-default alles open zet...

Er zou een vinkje moeten komen tijdens de initiele setup, "Weet je heel zeker dat je alles open wil zetten voor iedereen?".

Ik wil gewoon een SMB password... Als ik dan iemand toegang geef met een mobiele telefoon/laptop tot mijn thuisnetwerk hoef ik iig niet bang te zijn dat hij zomaar door mijn data gaat snuffelen...

[jacovn]

Tja bij mij staat niet alles in hetzelfde netwerk segment, en je kunt er iets van een firewall als pfsense tussen zetten, draait ook freebsd.
Ook wens ik ze succes om op een mobieltje een 50 GB blu rip te copieren..


De roadmap van zfsguru klopt ook niet helemaal meer, we zitten midden 2013:

http://zfsguru.com/doc/roadmap

[ Voor 41% gewijzigd door jacovn op 15-07-2013 08:35 ]

[Xudonax]

Terugkomend op mijn stacktrace van enkele posts hierboven, dit lijkt nu op mysterieuze manier opgelost. Ik heb gisteren het halve bootproces van Fedora uit elkaar getrokken en weer opgebouwd (het was een maffe mengelmoes van BIOS en EFI boot, ik snap nog steeds niet hoe en wat...), vervolgens één van de twee pools eruit gegooid en nu draait de machine al grofweg 7 uur. Dit terwijl deze eerst na ~1 uur al fouten gaf \o/

Vanavond nog even de 2e pool mounten om de bestanden (een iSCSI share, om het leuk te houden) eraf te plukken en dan kan die pool in principe weg.

[FireDrunk]

Mja, dat is vaak voor mij ook de reden om niet voor Fedora te gaan, die jongens zijn samen met Ubuntu het ergst qua onoverzichtelijkheid en vaag in elkaar stekende boot processen

Fedora heeft een gigantisch initrd bestand (Ubuntu ook) en daar hou ik niet zo van

Overigens heb je gelijk over die pfSense Firewall jacovn, maar dat is voor lokaal gebruik een beetje overdreven, ik heb een dd-wrt router met ingebouwde firewall, dat is al genoeg.

Het gaat mij meer om het principe, by-default alles open stoot bij mij gewoon een beetje tegen het zere been.
(en dat staat ook een tikkie haaks op de filosofie van FreeBSD, secure by-default enzo...)

[ Voor 41% gewijzigd door FireDrunk op 15-07-2013 09:01 ]

[Xudonax]

Het enige nadeel is dat de bak nu ook al ruim 7 uur bezig is met het checken van m'n downloads... Daar is Deluge iets te gevoelig mee geloof ik Dit terwijl de pool krap 100MByte/s doet met een CPU load van nog geen 75% (op 1 van de 8 cores). Ach ja, zolang het maar werkt

Is er trouwens een manier om een zvol van de ene pool naar de andere te verhuizen? Dat zou een stuk sneller moeten gaan op de machine zelf dan via 1GbE heen en weer lijkt me...

[jacovn]

FireDrunk schreef op maandag 15 juli 2013 @ 08:48:
Overigens heb je gelijk over die pfSense Firewall jacovn, maar dat is voor lokaal gebruik een beetje overdreven, ik heb een dd-wrt router met ingebouwde firewall, dat is al genoeg.

Het gaat mij meer om het principe, by-default alles open stoot bij mij gewoon een beetje tegen het zere been.
(en dat staat ook een tikkie haaks op de filosofie van FreeBSD, secure by-default enzo...)

Ik snap je wel, en je hebt ook gelijk

Ik ben bezig met een dedicated pfsense unit om wat filtering op www verkeer te kunnen doen voor 1 gebruiker in ons huishouden. Helaas draaien ze wat oude versie van FreeBSD, dus ik moet de beta versie draaien voor mijn hardware (MSI celeron 847) en daar lopen alle packages nog niet goed op. ZFS wordt overigens ook ondersteund

[FireDrunk]

Xudonax schreef op maandag 15 juli 2013 @ 09:26:
Het enige nadeel is dat de bak nu ook al ruim 7 uur bezig is met het checken van m'n downloads... Daar is Deluge iets te gevoelig mee geloof ik Dit terwijl de pool krap 100MByte/s doet met een CPU load van nog geen 75% (op 1 van de 8 cores). Ach ja, zolang het maar werkt

Is er trouwens een manier om een zvol van de ene pool naar de andere te verhuizen? Dat zou een stuk sneller moeten gaan op de machine zelf dan via 1GbE heen en weer lijkt me...

Een ZVOL is eigenlijk hetzelfde als een filesystem alleen is het een block device wat je kan formateren.

Volgens mij kan je dus gewoon met zfs send / recieve het ding transporteren.

https://blogs.oracle.com/mmusante/entry/backing_up_a_zvol

[ Voor 3% gewijzigd door FireDrunk op 15-07-2013 09:58 ]

[Xudonax]

Het enige nadeel is dat de ZVOL praktisch alle beschikbare ruimte inneemt... Naja, dan maar net als de vorige keer via GbE doen denk ik

[FireDrunk]

via ZFS send en receive worden alleen de gewijzigde / beschreven blocks verstuurd.

[ItsValium]

In mijn eeuwig durende zoektocht naar storage oplossingen kwam ik HAST + ZFS als mogelijke HA oplossing tegen. Dit is ook bij Nas4Free een van de features die reeds voorzien zijn. Ik vroeg me af of iemand dit al eens geprobeerd had, of zelfs al in productie heeft draaien? Momenteel beschik ik niet over de nodige hardware om het eens zelf bare-metal te gaan testen. In VM's op mijn laptop werkt het wel maar kan niet echt een inschatting van performance maken.

[Verwijderd]

jacovn schreef op maandag 15 juli 2013 @ 08:26:
Er stond op het ZFSguru forum zelfs dat er afgelopen weekeinde nieuws zou komen, althans daar leek de post op..

Dat is ook een beetje mijn fout. Ik zou nog screenshots maken. Ga ik zo gelijk even doen.

Wat betreft de userinterface, die vindt ik wel makkelijk te doorgronden. Enige waar ik tegenaan liep dat ik de share niet onder de pool kon vinden (dat leek me logisch, maar achteraf gezien wel logisch dat je je filesystem shared en niet de fysieke pool)

Inderdaad; je deelt bestanden geen pools, dus ik vind het opzich wel logisch. Maar Samba support wordt wel stukken beter dan nu het geval is. Nu is Samba binnen ZFSguru erg outdated en je kan er niet zoveel mee. Die krijgt een behoorlijke boost, want je kunt 'straks' () vrij ingewikkelde permissies instellen met extreem veel gemak; drag en drop interface.

Wat ik wel prima vindt is dat de sequrity gelijk goed staat (open), en ik zo van de server kan streamen zonder password geneuzel etc. Dat vondt ik het grootste nadeel van al de 2 andere systemen die ik geprobeerd heb: openindiana en nas4free)

Dat is ook bewust zo gedaan. Maar ik ben het ook wel eens met FireDrunk: security by default is wel zo fijn. Maar het grote punt is dat iets wat niet werkend te krijgen is voor een beginner slechter is dan iets wat gewoon werkt maar niet veilig is voor het boze internet. In de meeste gevallen wordt ZFSguru toch lokaal gebruikt en is security een minder groot probleem. Het 'just works' principe is dan belangrijker.

Ook had Jason de gedachte dat newbies beter kunnen beginnen met iets wat gewoon werkt, terwijl geavanceerde gebruikers zoals FireDrunk prima weten hoe ze hun box moeten beschermen met pf-firewall enzovoort.

Dat gezegd, de Samba functionaliteit in beta9 kun je gemakkelijk public en private kiezen en dat laatste met wachtwoord. Dus dat werkt al een stuk beter.

FireDrunk schreef op maandag 15 juli 2013 @ 08:28:
Er zou een vinkje moeten komen tijdens de initiele setup, "Weet je heel zeker dat je alles open wil zetten voor iedereen?".

Nou, nee. Het idee is dat zodra Netwerk functionaliteit werkt, daar een firewall geconfigureerd kan worden via de web-interface. Dan kun je dus zeggen Samba alleen voor LAN, de apache webserver voor iedereen dus ook internet, en NFS alleen voor dit en dat IP. Dat is eigenlijk wat je wilt, toch?

[Xudonax]

En toen vloog mijn bak er weer uit... Ik begin ZFS on Linux een beetje zat te worden
Naja, heb ik vanavond in ieder geval weer een stacktrace om over te typen en te submitten zullen we maar denken.

[Tsurany]

Verwijderd schreef op maandag 15 juli 2013 @ 02:20:
Aanmaken van Samba share is met één knop geregeld, op de files pagina klik je op de knop 'Share with Samba' boven de 'Share with NFS' knop. Dus makkelijker kan niet? Wel is de Samba management heel verouderd, maar juist dat is geheel herschreven in de komende beta9 versie, die nog niet uit is.

Makkelijker kan zeker wel. FreeNAS heeft wat dat betreft een heel simpel systeem waarbij je gewoon makkelijk een folder kan selecteren en kan delen. Ik kan in ZFSGuru enkel het gehele filesystem delen, hoe ik subfolders kan delen is voor mij absoluut niet duidelijk.

Maar test vooral uit de verschillende web-interfaces. Ik ben erg geïnteresseerd in je mening en bevindingen. Helpt mij ook om ZFSguru beter te maken, juist door feedback als deze. Je mag me ook DMen als het heel specifiek wordt. Hoe specifieker, hoe beter eigenlijk. Dan kan ik wijzigingen doorvoeren en heb jij dus ook veel invloed op de ontwikkeling van ZFSguru. Dat onderschatten mensen nogal vaak.

Ik denk dat mensen er eerder geen tijd voor hebben Ik wil eigenlijk gewoon een semi plug&play systeem wat mij geen tijd kost. Gewoon eenmalig opzetten en dan zo makkelijk mogelijk in beheer. En ZFSGuru voelt gewoon absoluut niet makkelijk aan, het voelt als een hele klus om alles voor elkaar te krijgen.

[Verwijderd]

Nou dat is vreemd om te horen, want de mensen díe ZFSguru gebruiken zeggen namelijk precies het tegenovergestelde. Met ZFSguru is het één klik op de muis en het werkt, terwijl bij andere projecten dat dus juist een heel gebeuren is met allerlei tutorials doorlopen, ook wat betreft extra services enzo.

Maar daarom is het toch fijn dat je keuze hebt, en niet aan één project vast zit zoals FreeNAS, wat ik persoonlijk ruk vind; allemaal bloat en onoverzichtelijke interface. Maar stel je hebt problemen met de ene interface/appliance, kun je altijd nog overlopen naar het andere project. Die migratie is toch wel een voordeel als je ZFS gebruikt; dat je niet vastzit aan één systeem. Zoals Xudonax nu gezeik heeft met ZFS-on-Linux kan hij vrij gemakkelijk migreren naar een BSD-project. Al heeft hij wel de fout gemaakt zijn pool versie 5000 te maken.

[Tsurany]

Verwijderd schreef op maandag 15 juli 2013 @ 11:22:
Nou dat is vreemd om te horen, want de mensen díe ZFSguru gebruiken zeggen namelijk precies het tegenovergestelde. Met ZFSguru is het één klik op de muis en het werkt, terwijl bij andere projecten dat dus juist een heel gebeuren is met allerlei tutorials doorlopen, ook wat betreft extra services enzo.

Volgens mij kijk je wel door een heel andere bril naar ZFSGuru dan naar andere ZFS projecten zoals FreeNAS. Mijn ervaring is toch echt dat het met ZFSGuru absoluut niet duidelijk is hoe ik nu in kan stellen dat een van de mappen op mijn schijf gedeeld moet worden als readonly terwijl andere mappen read/write mogen zijn. En dat is in FreeNAS een stuk eenvoudiger te doen.

Maar daarom is het toch fijn dat je keuze hebt, en niet aan één project vast zit zoals FreeNAS, wat ik persoonlijk ruk vind; allemaal bloat en onoverzichtelijke interface. Maar stel je hebt problemen met de ene interface/appliance, kun je altijd nog overlopen naar het andere project. Die migratie is toch wel een voordeel als je ZFS gebruikt; dat je niet vastzit aan één systeem. Zoals Xudonax nu gezeik heeft met ZFS-on-Linux kan hij vrij gemakkelijk migreren naar een BSD-project. Al heeft hij wel de fout gemaakt zijn pool versie 5000 te maken.

True, dat is ook de reden dat ik ZFSGuru een kans gegeven heb.

[FireDrunk]

ZFSGuru pool wilde bij mij niet importeren in Nas4Free, dus reken je niet rijk.

GPT labels werden niet overgenomen.

[Verwijderd]

Tsurany schreef op maandag 15 juli 2013 @ 11:26:
Volgens mij kijk je wel door een heel andere bril naar ZFSGuru dan naar andere ZFS projecten zoals FreeNAS.

Lijkt mij onoverkomelijk. Een schilder kijkt ook anders naar zijn eigen schilderij. Juist daarom is feedback van buiten onmisbaar.

Mijn ervaring is toch echt dat het met ZFSGuru absoluut niet duidelijk is hoe ik nu in kan stellen dat een van de mappen op mijn schijf gedeeld moet worden als readonly terwijl andere mappen read/write mogen zijn. En dat is in FreeNAS een stuk eenvoudiger te doen.

Akkoord, maar ik dacht dat we het over simpele dingen hadden? Gewoon je bestanden delen is met één knop te doen. FreeNAS ondersteunt gewoon veel meer specifieke opties en configuraties en is dus uitgebreider.

Dat gezegd, juist wat je nu zegt is al sterk verbeterd in beta9. Zal zo een screenshotje posten zodra ik ze gemaakt heb.

FireDrunk schreef op maandag 15 juli 2013 @ 11:30:
ZFSGuru pool wilde bij mij niet importeren in Nas4Free, dus reken je niet rijk.

GPT labels werden niet overgenomen.

Zucht. Dit soort dingen dus. Waarom kunnen Solaris/FreeNAS/NAS4Free hier zo moeilijk mee omgaan? zpool import ?! Al zouden gpt labels niet worden gevonden, dan ziet zpool import gewoon de partitie device nodes. Lijkt erop dat FreeNAS/NAS4Free gewoon een bepaalde configuratie verwachten en niet toelaten wat het systeem mogelijk maakt. ZFSguru werkt gewoon met zfs commando's. Als je zelf handmatig je pool importeert, zie je die ook gewoon in ZFSguru web-interface. FreeNAS gebruikte eerst een configuratiebestand waarin de ZFS pool configuratie in opgeslagen werd. Dat vind ik dus enorm vies.

[FireDrunk]

Uh neen, ZFS wil dat de disks dezelfde labels hebben anders kan je ze niet importeren. Nas4Free doet het gewoon direct op disk by default. Dus je pool bestaat uit /dev/da0 t/m daX. Dat is niet slecht, dat is een keuze... Ik heb niet eens geprobeerd om de GPT labels aan te zetten hoor, misschien kan dat best.

Maar mijn SSD pool was toch leeg, dus ik heb de hele meuk gewoon opnieuw aangemaakt.

[Verwijderd]

ZFS wil dat de disks dezelfde labels hebben anders kan je ze niet importeren.

Dat is onzin?!

Je kunt je disk op een andere controller gooien en die heeft een heel andere naam. Of bijvoorbeeld een disk via een externe behuizing aansluiten. Reboot en hij wordt direct gevonden.

FreeBSD werkt met device tasting. Dus ik weet niet hoe je hierbij komt?

Dat is niet slecht, dat is een keuze

Dat is heel erg slecht, om meerdere redenen. Zo heb je gezeik als je disk opeens wat kleiner wordt. Ook kun je niet achteraf bijvoorbeeld GELI encryptie op de disks doen want die heeft dan 512 bytes of 4K nodig voor de metainformatie. Je kunt bijna alle GEOM modules niet meer gebruiken hierdoor. Bovendien kun je je gemakkelijker vergissen omdat je met allemaal disk namen werkt, die ook nog eens kunnen verschillen bij verwisselen kabels of als een controller eerder wordt gevonden.

Ten slotte is het gevaarlijk, mocht je je disks aansluiten op Windows. Windows vraagt dan om je disks te 'initialiseren' omdat het geen partitietabel kan vinden. Dat klinkt onschuldig en dat doen mensen dan ook vaak, niet wetende dat ze in feite hun disks hiermee snel formatteren. Zo zijn best wat mensen hun data kwijtgeraakt.

Dit soort keuzes is dus één van de dingen die mij absoluut niet bevalt aan de overige projecten. Dat heeft ZFSguru toch beter voor elkaar IMO.

[ Voor 57% gewijzigd door Verwijderd op 15-07-2013 11:50 ]

[Tsurany]

Verwijderd schreef op maandag 15 juli 2013 @ 11:36:
Lijkt mij onoverkomelijk. Een schilder kijkt ook anders naar zijn eigen schilderij. Juist daarom is feedback van buiten onmisbaar.

True, maar in dit topic wellicht niet ideaal.

Akkoord, maar ik dacht dat we het over simpele dingen hadden? Gewoon je bestanden delen is met één knop te doen. FreeNAS ondersteunt gewoon veel meer specifieke opties en configuraties en is dus uitgebreider.

Dat gezegd, juist wat je nu zegt is al sterk verbeterd in beta9. Zal zo een screenshotje posten zodra ik ze gemaakt heb.

Ja, dit is toch een van de simpele dingen? Sterker nog, dit is de basis functionaliteit van een NAS, bestanden delen. Dan is het toch wel handig dat je mappen kan delen met verschillende mensen? Als ZFSGuru dit niet kan is het geen OS voor een NAS.

[FireDrunk]

Alle disks waren gewoon zichtbaar, en een zfs import -f op de commandline geef 0,0 opties om te importeren.

Dat is compleet buiten Nas4Free om.

[B2]

Xudonax schreef op maandag 15 juli 2013 @ 11:06:
En toen vloog mijn bak er weer uit... Ik begin ZFS on Linux een beetje zat te worden
Naja, heb ik vanavond in ieder geval weer een stacktrace om over te typen en te submitten zullen we maar denken.

Hm, ik gebruik ZoL op twee machines naar grote tevredenheid. Waar gaat het bij jou mis?

[Xudonax]

B2 schreef op maandag 15 juli 2013 @ 11:56:
[...]


Hm, ik gebruik ZoL op twee machines naar grote tevredenheid. Waar gaat het bij jou mis?

Dit: Kernel panic - not syncing: Fatal exception in interrupt. Hoewel ik nog niet weet waar de machine vandaag op vastgeslagen is. Het duurde in ieder geval grofweg 8x zolang met maar één pool in vergelijking met twee pools.

En CiPHER: Ik houd gewoon van een uitdaging, vandaar dat mijn pool v5000 is Maar nee, dit is gebeurd zonder dat ik er erg in had bij het opnieuw aanmaken. Ik baal wel flink, want ik had gisteren iets van "Naja, dan pak ik even ZFSGuru en trek ik een backup" maar dat mocht dus niet lukken...

[jacovn]

Verwijderd schreef op maandag 15 juli 2013 @ 10:50:
Ook had Jason de gedachte dat newbies beter kunnen beginnen met iets wat gewoon werkt, terwijl geavanceerde gebruikers zoals FireDrunk prima weten hoe ze hun box moeten beschermen met pf-firewall enzovoort.

Dat gezegd, de Samba functionaliteit in beta9 kun je gemakkelijk public en private kiezen en dat laatste met wachtwoord. Dus dat werkt al een stuk beter.

Kijk hij had mij in gedachten. Server opgezet, alle data erheen gecopieerd en kijken maar.

Zeer tevreden gebruiker.

[FireDrunk]

XudonaX je kan wel terug naar ZFSguru, alleen moet je 'even' zorgen dat het met FreeBSD 10 werkt

(dan moet je even de php versie upgraden, en een paar bugjes in de webinterface fixen )

[Xudonax]

FireDrunk schreef op maandag 15 juli 2013 @ 13:39:
XudonaXx je kan wel terug naar ZFSguru, alleen moet je 'even' zorgen dat het met FreeBSD 10 werkt

(dan moet je even de php versie upgraden, en een paar bugjes in de webinterface fixen )

Oh, als dat alles is...

[Verwijderd]

Met het risico dat ik weer uitgelachen word: de nieuwe releases van ZFSguru zijn binnen een paar weken. Dus je kunt er ook gewoon op wachten, dan heb je vrij simpel versie 5000 ZFS in ZFSguru. Tot die tijd, tja...

Ik heb nu de screenshots gemaakt. Hopelijk kan Jason zo zijn state-of-the-project online gooien. Kun je ook horen hoe het verder gaat met het project, voor degenen die dit interessant vinden.

[FireDrunk]

Doe dan op zijn minst een linkje

[FDMK]

Posted on 6 July 2013 @ 09:30 Quote
Actually, yes. I would like to make a statement this weekend.

Beetje dit?

[jacovn]

Qua communicatie vindt ik het ook niet geweldig (zie de roaddmap etc.) maar hij moet er ook maar tijd voor hebben.

Ik heb hiervoor unraid gedraaid (linux met Reiserfs filesysteem) daar was altijd wel iets mee aan de hand wat niet helemaal goed ging. De ontwikkelaar daar doet het allemaal alleen, en communiceert ook erg slecht meestal. Dit brengt nu wel elke week een nieuwe RC uit - zit op #16 nu..
Ergste was dat er gewoon dikke issues waren die uiteindelijk gewoon terug te voeren zijn op 32 bit OS versie en geheugen gebruik, maar dat communiceert niemand..

Met ZFSguru kan ik wel gewoon doen wat ik wil (NAS voor films op te zetten, en kijken)
Snelheid is altijd super, 10 GE kaart erin, en het werkt ook goed etc.

Voor mij als beginner op dit gebied heb ik in ieder geval een stuk minder frustatie met ZFSguru dan ik met unraid had.

[Verwijderd]

Ik wil jullie ook wel vragen om respect voor iemand die toch een deel van zijn leven geeft om zonder eigen belang iets te ontwikkelen voor anderen. Het kost Jason gewoon geld iedere maand om ZFSguru draaiende te houden. Met zijn skills had hij ook prima een goede baan kunnen krijgen, maar hij wilde toch een andere kant uit. Ik snap dat er vanalles beter kan. Communicatie is daar zeker één belangrijk punt van. Maar aan de andere kant, heb respect voor iets wat je gratis en voor niets krijgt?

Ik heb net de tekst van zijn State-of-the-Project gelezen en ben wel onder de indruk. Ben benieuwd hoe dat voor jullie geldt. Zodra hij online is krijgen jullie uiteraard een linkje.

[FireDrunk]

Mja, ik heb al vaak genoeg aangeboden om te helpen, zodat hij het niet allemaal meer alleen hoeft te doen. En communiceren kan jij ook (als zijn wederhelft ), als hij eens wat meer verantwoordelijkheid af gaf...

Tuurlijk is het mooi als mensen iets gratis in de markt zetten, maar het is niet dat ik hem daardoor op handen en voeten draag ofzo... Zoveel tijd als hij in ZFSGuru stopt, zoveel tijd stoppen jij en ik in het helpen van mensen op GoT.

Ik verwacht daar ook geen lintje voor hoor

[Verwijderd]

Vind ik toch wat anders. Voor mij kost het niet veel tijd wat berichtjes te typen op GoT. Een product designen en onderhouden kost toch wat meer moeite.

En je hebt dacht ik laatst het aanbod gekregen mee te ontwikkelen aan ZFSguru?