Het grote ZFS topic

[FabiandJ]

Ik ben zojuist over gegaan van software RAID6 middels mdadm overgegaan naar ZFS, maar ik vind de performance tegenvallen iemand tips?

Het betreft 8x HGST Deskstar 7K4000 4TB schijven die in raidz2 staan, ik maak gebruik van OpenSuse en zfs-fuse.

server:/ # zpool get all datastore
NAME PROPERTY VALUE SOURCE
datastore size 29T -
datastore capacity 0% -
datastore altroot - default
datastore health ONLINE -
datastore guid 15750593508793150884 default
datastore version 23 default
datastore bootfs - default
datastore delegation on default
datastore autoreplace off default
datastore cachefile - default
datastore failmode wait default
datastore listsnapshots off default
datastore autoexpand off default
datastore dedupditto 0 default
datastore dedupratio 1.00x -
datastore free 28.9T -
datastore allocated 83.5G -

server:/ # zfs get dedup
NAME PROPERTY VALUE SOURCE
datastore dedup off default
datastore/backup dedup off default

server:/ # dd if=/dev/zero of=/mnt/zerofile.txt bs=1M count=64000
64000+0 records in
64000+0 records out
67108864000 bytes (67 GB) copied, 668.006 s, 100 MB/s
server:/ # dd if=/mnt/zerofile.txt of=/dev/null bs=1M
64000+0 records in
64000+0 records out
67108864000 bytes (67 GB) copied, 211.706 s, 317 MB/s

[ Voor 48% gewijzigd door FabiandJ op 17-12-2016 18:58 ]

[Verwijderd]

ZFS-fuse is dat niet de oude ZFS onder Linux, moet je niet ZFS-on-Linux hebben wat kernel-level is? FUSE is filesystem-in-userland. Kortom, gebruik je wel de 'juiste' ZFS?

[FabiandJ]

Verwijderd schreef op zaterdag 17 december 2016 @ 18:58:
ZFS-fuse is dat niet de oude ZFS onder Linux, moet je niet ZFS-on-Linux hebben wat kernel-level is? FUSE is filesystem-in-userland. Kortom, gebruik je wel de 'juiste' ZFS?

Ik gebruikte inderdaad niet de juiste.

Ik loop nu alleen wel tegen een ander issue aan, ik probeer een pool aan te maken met ashift=12 vanwege de sector size van 4K maar wat ik ook doe hij lijkt dit niet te pakken:
zpool create -f datastore -o ashift=12 raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi

Als ik een zdb -l /dev/sdd | grep ashift doe rolt er ashift: 9 uit.

Op dit moment zijn dit mijn lees en schrijf snelheden, toch een stuk sneller dan eerst
server:/ # dd if=/dev/zero of=/mnt/zerofile.txt bs=1M count=6400
6400+0 records in
6400+0 records out
6710886400 bytes (6.7 GB) copied, 8.48066 s, 791 MB/s
server:/ # dd if=/mnt/zerofile.txt of=/dev/null bs=1M
6400+0 records in
6400+0 records out
6710886400 bytes (6.7 GB) copied, 5.45857 s, 1.2 GB/s

[ Voor 22% gewijzigd door FabiandJ op 18-12-2016 14:16 ]

[Verwijderd]

Probeer eens met -O (dus hoofdletter o) - uit mijn hoofd. De ene is een filesystem property, de andere een pool-property.

Verder: als je benchmarks doet moet je wel een grote size gebruiken ivm RAM caching. Dus 8* je RAM-size heb je pas de 'echte' snelheid te pakken. Probeer het eens met 64GiB, dan krijg je een realistische snelheid die lager zal liggen.

Tip: als je eerst de write benchmark doet, doe dan een zpool export & zpool import om de cache te legen. Dan de read test. Dan is de read-test helemaal vrij van RAM caching.

[ Voor 19% gewijzigd door Verwijderd op 18-12-2016 15:56 ]

[Q]

Als aanvulling: je kunt live de 'echte' throughput zien met de tool 'dstat' om je nummers te verifiëren.

[Verwijderd]

dstat is voor Linux wat gstat voor BSD is neem ik aan? Weet ik dat ook weer.

[GioStyle]

Vandaag voor het eerst dat mijn 10 disk raidz2 array degraded is. Sterker nog: voor mij is het voor het eerst dat ik meemaak dat een array degraded is. Niet leuk om mee te maken, maar ik ben blij dat de data te redden valt.

Een schijf heeft problemen met lezen/schrijven:

• Ik heb de schijf al verplaatst om kapotte kabels uit te sluiten, maar dat mocht niet baten. Het ligt dus echt aan de schijf.
• Schijf terug in de array plaatsen resulteert in resilver, maar na een aantal GB knalt ZFS de schijf weer uit de array vanwege lees/schrijf fouten.

Wat kan ik nog doen om te kijken of de schijf nog te redden valt? Een low format? Anders gaat ie gewoon terug naar de verkoper. Schijf komt uit 12/2014, gekocht in 03/2015, dus er zit nog garantie op.

[A1AD]

FabiandJ schreef op zondag 18 december 2016 @ 13:21:
[...]

zpool create -f datastore -o ashift=12 raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi

Heeft niets met je probleem te maken, maar gebruik altijd /dev/disk/by-id/...

[Q]

Verwijderd schreef op zondag 18 december 2016 @ 20:14:
dstat is voor Linux wat gstat voor BSD is neem ik aan? Weet ik dat ook weer.

ik ken gstat niet maar ik denk dat het meer lijkt op iostat (met history)

[FabiandJ]

Verwijderd schreef op zondag 18 december 2016 @ 15:56:
Probeer eens met -O (dus hoofdletter o) - uit mijn hoofd. De ene is een filesystem property, de andere een pool-property.

Verder: als je benchmarks doet moet je wel een grote size gebruiken ivm RAM caching. Dus 8* je RAM-size heb je pas de 'echte' snelheid te pakken. Probeer het eens met 64GiB, dan krijg je een realistische snelheid die lager zal liggen.

Tip: als je eerst de write benchmark doet, doe dan een zpool export & zpool import om de cache te legen. Dan de read test. Dan is de read-test helemaal vrij van RAM caching.

Met de -O functie werkt het niet:
zpool create -f datastore -O ashift=12 raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi
cannot create 'datastore': invalid property 'ashift'

Als ik het met -o doe, werkt het zo te zien:
server:/ # zdb
\datastore:
version: 5000
name: 'datastore'
state: 0
txg: 4
pool_guid: 8656163497243173429
errata: 0
hostname: 'server'
vdev_children: 1
vdev_tree:
type: 'root'
id: 0
guid: 8656163497243173429
create_txg: 4
children[0]:
type: 'raidz'
id: 0
guid: 18259883161558540507
nparity: 2
metaslab_array: 35
metaslab_shift: 38
ashift: 12
asize: 32006175981568
is_log: 0
create_txg: 4
children[0] t/m children[7]
features_for_read:
com.delphix:hole_birth
com.delphix:embedded_data
]

A1AD schreef op zondag 18 december 2016 @ 22:30:
[...]


Heeft niets met je probleem te maken, maar gebruik altijd /dev/disk/by-id/...

Ik neem aan dat dit te maken heeft omdat er een kans bestaat dat bij een herstart de harde schijf een andere /dev/sd* waarde mee kan krijgen?

[ Voor 41% gewijzigd door FabiandJ op 20-12-2016 22:01 ]

[Verwijderd]

Het moet toch -o zijn (zpool property, -O = filesystem property).

Merk wel op dat die switch Linux-only is - BSD heeft autodetectie van de ashift/sectorsize. Heb je wel moderne ZFS-on-Linux? Bij FUSE werkt die '-o ashift=' mogelijk niet.

Ik ken ZFS-on-Linux niet zo goed, dus mogelijk weten anderen meer dan ik.

Edit: dus het werkt nu wel? Waarom werkte het dan eerst niet toen je -o gebruikte?!

[ Voor 12% gewijzigd door Verwijderd op 20-12-2016 22:04 ]

[FabiandJ]

Verwijderd schreef op dinsdag 20 december 2016 @ 22:03:
Het moet toch -o zijn (zpool property, -O = filesystem property).

Merk wel op dat die switch Linux-only is - BSD heeft autodetectie van de ashift/sectorsize. Heb je wel moderne ZFS-on-Linux? Bij FUSE werkt die '-o ashift=' mogelijk niet.

Ik ken ZFS-on-Linux niet zo goed, dus mogelijk weten anderen meer dan ik.

Edit: dus het werkt nu wel? Waarom werkte het dan eerst niet toen je -o gebruikte?!

Ik gebruik -o en gebruikte ik al, de -O optie die werkt dus niet zoals je zag

Ik heb FUSE meteen na jou eerste reactie er af geknikkerd en overgestapt op ZFS-On-Linux gebruik te laatste versies die hier staan: http://zfsonlinux.org/

Goeie vraag het enige wat ik veranderd heb ik dat ik nu niet /dev/sd* gebruik maar meteen het by-id, dus zo:

code:

zpool create -f datastore -o ashift=12 raidz2 scsi-SATA_Hitachi_HDS72404_PK1331PAH2JM7S scsi-SATA_Hitachi_HDS72404_PK1331PAH2JJ8S scsi-SATA_Hitachi_HDS72404_PK1331PAH2JL8S scsi-SATA_Hitachi_HDS72404_PK1331PAH2X17S scsi-SATA_HGST_HDN724040AL_PK2334PEK0WH4T scsi-SATA_HGST_HDN724040AL_PK2338P4HZ21RC scsi-SATA_Hitachi_HDS72404_PK1311PAGN9BJX scsi-SATA_Hitachi_HDS72404_PK1331PAH2LGLS

[ Voor 30% gewijzigd door FabiandJ op 20-12-2016 22:08 ]

[Q]

Misschien leuk voor de mensen die ZFS fan zijn:

Ik heb een artikeltje op mijn blog gepost over hoe ik op mijn werk ZFS heb gebruikt om aan te tonen dat een controller van onze Storage Arrays data corruptie veroorzaakte.

http://louwrentius.com/tr...-controller-with-zfs.html

[FireDrunk]

Leuke use case voor ZFS

[Verwijderd]

Ik zal maar wijselijk mijn mond houden dat hetzelfde opgaat voor andere oorzaken van corruptie.

[Q]

Als je doelt op corruptie door geheugen / RAM fouten dan weet je wat ik daarvan vind

Dit was een mooie use-case voor ZFS omdat het ging om het opsporen van de root-cause van storage-gerelateerde corruptie.

Ik moet er wel bij zeggen dat de methode waarmee ik corruptie aantoonde nogal grof was.
Zodra ik een 'zpool scrub' deed, hing mijn console. Dus geen mooie output van zpool met detailed info over corruptie.

[ Voor 33% gewijzigd door Q op 21-12-2016 11:11 ]

[Verwijderd]

Wellicht dat die ervaring anders was geweest met BSD; daar ben ik zelf benieuwd naar.

Want mijn ervaring is dat BSD robuuster is wat betreft ZFS. ZoL vind ik maar buggy in vergelijking met de ZFS-ondersteuning onder *BSD.

Dat gezegd, mijn systemen draaien vooral ook in RAM wat als voordeel heeft dat I/O-problemen de systeemdisk niet onderuit kunnen halen. Dus stel een controller gaat bokken, dan blijft het systeem zelf gewoon responsive. Dat vind ik een groot voordeel.

[Q]

Een paar dingen.

Ik vind het onzin om mijn ervaring als aanleiding te gaan gebruiken om een BSD vs Linux discussie te starten, vind ik zelf totaal irrelevant.

Ik teste met een 2e schijf, dus het OS was niet affected. Ik moest alleen die schijf vmotionen en als hij corrupt raakte opnieuw voorzien van een schone zfs pool en wat data.

Het OS bleef draaien en de machine bleef prima bruikbaar, alleen een 'zpool scrub' bleef hangen. Dat een tool hangt op een corrupte disk tja. Het OS ging niet plat en dat is waar het om gaat.

[Verwijderd]

Als jij het niet relevant vindt, dan houd ik er over op. Echter, het is wel een thema dat regelmatig voorbij komt en ook zeker relevant voor dit topic. Het gaat namelijk specifiek om de ZFS-ondersteuning die verschilt per OS, niet de verschillen tussen operating systems in het algemeen.

Ik vind het namelijk wel interessant om te weten of de keuze voor een OS invloed heeft op het blijven hangen van een zpool commando - dat zou mijns inziens niet mogen.

[FREAKJAM]

Geen idee of deze "wiki" al eens is gepost hier, maar vind hem zeker het vermelden waard.
Dit betreft een writeup van een dualnode ZFS HA cluster met shared JBOD storage onder linux.

• The basic design is RHEL/CentOS 7.x, the Redhat cluster add-on (Corosync/Pacemaker), a shared JBOD and dual-ported SAS disks.
• There aren't any exotic components or esoteric procedures required for this build, other than standard SAS HBAs and the appropriate SSD types for the L2ARC and SLOG workloads. I use Stec ZeusRAM for ZIL and SAS read-optimized SSDs for L2ARC.
• Pool and disk monitoring is achieved via zfswatcher, real-time analytics are achievable with netdata and everything else is a standard Linux build.

[ Voor 5% gewijzigd door FREAKJAM op 21-12-2016 15:21 ]

[Q]

Verwijderd schreef op woensdag 21 december 2016 @ 14:12:
Als jij het niet relevant vindt, dan houd ik er over op. Echter, het is wel een thema dat regelmatig voorbij komt en ook zeker relevant voor dit topic. Het gaat namelijk specifiek om de ZFS-ondersteuning die verschilt per OS, niet de verschillen tussen operating systems in het algemeen.

Ik vind het namelijk wel interessant om te weten of de keuze voor een OS invloed heeft op het blijven hangen van een zpool commando - dat zou mijns inziens niet mogen.

Natuurlijk zou een zpool app de conditie moeten afvangen en niet hangen. Maar het is wat anders dan dat er een kernel panic optreedt.

Je maakt er veel meer drama van dan dat het werkelijk is, wat mij betreft.

Je bent in dit forum een high-profile persoon, je bent moderator, mede-auteur van ZFSGuru en veel aanwezig in posts met advies. Je hebt jezelf een duidelijke status verworven, mensen gaan op jou advies af.

Maar om nu dan dit issue aan te grijpen om insituaties te maken over Linux, dat vind ik zelf niet zo sterk. Je zaait angst en twijfel, terwijl ZFS op Linux gewoon prima stabiel is op de grote distro's.

Zelfs al is ZFS op FreeBSD nog beter/stabieler dan Linux, dat wil niet zeggen dat Linux geen prima keuze is voor heel veel mensen, zeker als hun expertise daar meer ligt en ze geen GUI zoeken zoals ZFSGuru of FreeNAS wel biedt.

[Verwijderd]

Ik gebruik zelf ook ZFS-on-Linux op de desktop, sinds het default is onder Ubuntu. Ik zeg ook niet dat ZFS-on-Linux een slechte keuze is, alhoewel het denk ik zeker niet overdreven is om te stellen dat de ondersteuning onder BSD gewoon stukken beter is. Dat is ook niet gek omdat ZFS op het Linux-platform toch een achterstand heeft door licentie-issues en daarnaast de meeste aandacht uitgaat naar Btrfs wat toch het native next-gen filesystem gaat worden voor Linux.

Maar voel je niet zo aangevallen; ik wil ZoL niet afkraken; maar wel inzicht krijgen in de verschillen. En ja, ik vind het gedonder met updates van ZFS op het Linux-platform maar amateuristisch. Maar die mening lijkt me prima te verdedigen en ik zal echt niet de enige zijn die het jammer vindt dat ZFS op Linux niet zo goed werkt als onder BSD. Juist omdat ZFS cross-platform is zou het wenselijk zijn dat het gewoon goed werkt onder Linux. Maar regelmatig komen hier en elders verhalen voorbij die aantonen dat daar twijfels bij gezet kunnen worden, wat niet betekent dat het onbruikbaar is, alleen niet zo stabiel en volwassen als onder Solaris en BSD platform - dat is gewoon jammer.

[CurlyMo]

Q heeft al heel vaak beargumenteerd dat en waarom ZFS voor hem geen wondermiddel is. Daar wordt zowel in dit topic als andere topics (bijv. BTRFS) telkens opnieuw de discussie over aangegaan. Veelal echter zonder echt (nieuwe) bewijsvoering (zoals in de vorm van concrete praktijk tests).

Of zoals Q het zelf verwoord aldaar:

Q schreef op donderdag 11 augustus 2016 @ 00:29:
Klinkt goed

Ik vind het ook leuk dat je zelf even test en niemand hier op zijn/haar woord gelooft

Eigenlijk net als dat ik telkens de behoefte voel om de discussie over ZFSGuru te voeren, omdat ik me ook nog altijd niet overtuigd zie van mijn ongelijk Maar daar ben ik ook mee gestopt, omdat de ideeën daarover ook te verschillend zijn.

Het voorbeeld wat Q laat zien is een mooie out-of-the-box gedachte werkwijze voor het ontdekken van een falende controller. Laten we het daar vooral over hebben en niet verzanden in de discussie over ZoL vs FreeBSD ZFS of voor de 10de met Q de discussie over ZFS an-sich voeren zolang er nog geen nieuw voer is voor discussie (zoals een doorbraak als block-pointer-rewrite).

[Q]

CurlyMo schreef op woensdag 21 december 2016 @ 16:26:

Het voorbeeld wat Q laat zien is een mooie out-of-the-box gedachte werkwijze voor het ontdekken van een falende controller. Laten we het daar vooral over hebben en niet verzanden in de discussie over ZoL vs FreeBSD ZFS of voor de 10de met Q de discussie over ZFS an-sich voeren zolang er nog geen nieuw voer is voor discussie (zoals een doorbraak als block-pointer-rewrite).

Ik vind dit een hele mooie kerstgedachte.

[Verwijderd]

Zeker weten, sluit ik me bij aan!

Over testen gesproken: BSD heeft geom_nop wat read errors en met een patch ook corruptie kan introduceren. Dat kan ook een leuke basis zijn voor wat scripted tests over hoe ZFS omgaat met corruptie en statistische analyse hoeveel bad sectors disks mogen hebben en nog wel veilig is met diverse ZFS pool configuraties (single disk met of zonder copies=2, mirror, raid-z1/2/3).

Is dat leuk om eens op te zetten? Zou niet veel tijd kosten. Ook wilde ik nog eens de RAM corruptie test uitvoeren; want ik heb nog een paar reepjes corrupt geheugen liggen. Maar dat doe ik dan graag in het andere topic.

Punt is wel, ik heb het vrij druk. Dus praten zonder bewijsvoering is natuurlijk wel makkelijker dan daadwerkelijk tests uitvoeren. Maar ik ben het zeker eens dat dat laatste van een grotere waarde is.

[MikeVM]

mn freebsd-servertje had weer wat kuren, bestanden raakte corrupt, dus even maar eens memtest en cpu-test gerunt via een nieuwe windows installatie.

aangezien mijn windows-vm (onder zfsguru) vaak crashte wou ik nu toch maar eens proberen of ik het andersom zou kunnen doen, namenlijk zfsguru in virtualbox draaien, maar dat is toch niet zo makkelijk als ik dacht, en ik weet niet of het allemaal(veel tutorials met sketchy workarounds) zo betrouwbaar is.

misschien toch maar weer ouderwets zfsguru als main os behouden. maar ik vraag me toch af hoe het komt dat windows zo vaak crasht, vaak is het als ik veel netwerk activiteit heb. iemand een idee wat de oorzaak zou kunnen zijn?

[MikeVM]

als zfsguru aangeeft dat er corrupte bestanden zijn, maar alle disks zijn healthy, zou er dan iets mis zijn met mijn sata-controller of??

[EnerQi]

MikeVM schreef op maandag 26 december 2016 @ 17:45:
als zfsguru aangeeft dat er corrupte bestanden zijn, maar alle disks zijn healthy, zou er dan iets mis zijn met mijn sata-controller of??

Een scrub laten draaien in ZFSguru (daarom zie je corrupte bestanden die gerepareerd worden) en daarna even controleren op kabelfouten via SMART (zit ook in ZFSguru).

Als bestanden niet vaak be/herschreven worden, kan de harde schijf door demagnetisering soms data verliezen (vandaar veiligheid in ECC per beschreven byte). Normaal wordt dit door ZFS zelf gecorrigeerd en inzichtelijk gemaakt ;-)

[soulcrusher]

Ik zag dat het ZFSguru project nu in handen van CiPHER ligt (link). Succes CiPHER en ik ben benieuwd naar de toekomstige plannen voor ZFSguru!

[BartNL]

zal wel verrassing zijn aangezien CiPHER in Discussie over de toekomst van ZFSguru nog niets heeft laten weten?

[FREAKJAM]

BartNL schreef op maandag 2 januari 2017 @ 13:57:
zal wel verrassing zijn aangezien CiPHER in Discussie over de toekomst van ZFSguru nog niets heeft laten weten?

CiPHER had wel aangekondigd dat er iets zou gaan gebeuren.
Verwijderd in "Discussie over de toekomst van ZFSguru"
Verwijderd in "Discussie over de toekomst van ZFSguru"

[ Voor 9% gewijzigd door FREAKJAM op 02-01-2017 14:00 ]

[BartNL]

Ik bedoel meer dat het exacte moment van aankondigen door Jason voor CiPHER een verrassing zou zijn. Mijn reactie komt ook omdat ik Jason zijn communicatie altijd al wat minder betrouwbaar vond.

[Verwijderd]

De bedoeling was eerst dat die aankondiging vóór de kerst kwam en ik iets van een tijdelijke website online zou gooien 1 januari; maar het was natuurlijk geen verrassing dat er een aankondiging op handen was. Overigens moet mijn eigen aankondiging nog komen; dan zal ik zelf mijn plannen kenbaar maken.

Daarnaast probeer ik een beetje voorzichtig te zijn met posts over ZFSguru - ik verwijs dan liever naar de aankondiging op de website zelf. Ik denk nog na over een nieuw topic over ZFSguru. Tips zijn altijd welkom via de DM.

[Packetloss]

Ik heb een vraagje over het maken van backups. Ik draai FreeNAS-9.10.2 met een ZFS storage. Kort geleden kreeg ik het voor elkaar om met vmrc (http://vmrc.bsd.lv/) een Ubuntu 16.04 VM te draaien, waar ik Graylog2 in host. Nou vraag ik me af: hoe maak ik een backup van deze VM ? Hij staat op een SSD die stuk kan gaan, of die ik een keer wil vervangen enz enz.

Is het zo simpel als de VM stoppen en een kopie maken van de directory? Of is er een betere methode?

user@server:/mnt/SystemDataSetPool/vmrc/virtualmachines$ du -sch graylog20/
7.3G graylog20/
7.3G total

[CurlyMo]

Packetloss schreef op zaterdag 7 januari 2017 @ 09:53:
Ik heb een vraagje over het maken van backups. Ik draai FreeNAS-9.10.2 met een ZFS storage. Kort geleden kreeg ik het voor elkaar om met vmrc (http://vmrc.bsd.lv/) een Ubuntu 16.04 VM te draaien, waar ik Graylog2 in host. Nou vraag ik me af: hoe maak ik een backup van deze VM ? Hij staat op een SSD die stuk kan gaan, of die ik een keer wil vervangen enz enz.

Is het zo simpel als de VM stoppen en een kopie maken van de directory? Of is er een betere methode?

user@server:/mnt/SystemDataSetPool/vmrc/virtualmachines$ du -sch graylog20/
7.3G graylog20/
7.3G total

Als die VM op een ZFS staat dan gewoon via standaard snapshots + send / receive. VM hoef je er niet voor te stoppen. Dat kan gewoon live.

[ Voor 3% gewijzigd door CurlyMo op 07-01-2017 10:58 ]

[Packetloss]

CurlyMo schreef op zaterdag 7 januari 2017 @ 10:39:
[...]

Als die VM op een ZFS staat dan gewoon via standaard snapshots + send / receive. VM hoef je er niet voor te stoppen. Dat kan gewoon live.

Ok, bedankt voor de reactie. De VM staat op een aparte SSD die ook mijn System dataset pool is; niet op mijn grote ZFS volume met veel data. Die SSD is ook voorzien van ZFS.

Alleen gebruik ik geen snapshots. Ik zal me verdiepen in send / receive, ook niet eerder gebruikt. Ben pas paar maanden gebruiker van FreeNAS / ZFS. Oja, naar tevredenheid uiteraard .

[Packetloss]

CurlyMo schreef op zaterdag 7 januari 2017 @ 10:39:
[...]

Als die VM op een ZFS staat dan gewoon via standaard snapshots + send / receive. VM hoef je er niet voor te stoppen. Dat kan gewoon live.

Ik heb hier toch nog een vraag over; ik wil dus een bhyve VM die op een FreeNAS ZFS storage staat, backuppen. Dat doe ik liever naar een andere server dan waar het op draait. Als ik op internet wat voorbeelden lees, zoals deze: https://pthree.org/2012/1...nd-receiving-filesystems/ dan gaat men er van uit dat 'de andere kant', degene die

Bash:

zfs receive

doet, ook ZFS snapt. Maar wat als dit niet het geval is, bijvoorbeeld 'gewoon' een Ubuntu host? Is er dan iets anders aanbevolen om wel een

Bash:

zfs send

te kunnen doen? Of toch de VM stoppen en met bijv rsyng naar een Ubuntu host pompen?
NB; ik weet dat er ZFS on Linux is, maar daar waag ik me liever even niet aan ivm tijd; alle andere backups doe ik reeds met rsync door SSH heen, wat ik met deze bhyve VM ook het liefst zou doen.

[Verwijderd]

'ZFS snappen' ? ZFS send en receive werkt alleen van een ZFS pool naar een ZFS pool, en dus niet van ZFS naar Ext4 ofzo.

Normaliter werkt een zfs send op een snapshot; dus alles wat sinds die snapshot is gewijzigd, doet er niet toe. Belangrijk is dat ZFS alle snapshots netjes overbrengt en dat kan dus prima terwijl een VM draait op één van de datasets, omdat de snapshots alles in een consistente staat behouden.

[Packetloss]

Verwijderd schreef op zondag 8 januari 2017 @ 16:56:
'ZFS snappen' ? ZFS send en receive werkt alleen van een ZFS pool naar een ZFS pool, en dus niet van ZFS naar Ext4 ofzo.

vandaar dat ik vraag of er een andere methode geschikt is, zonder zfs aan de ontvangende kant. Ik denk dat je m'n vraag wel begrepen hebt.

[Verwijderd]

Je wilt dus geen zfs send/receive maar je wilt een filesystem-agnostisch programma wat bestanden tussen twee computers kan synchroniseren? Zo ja, dan kun je kijken naar 'rsync' oftewel remote synchronization. Dat kun je ook met checksums gebruiken; alleen duurt het dan wel extreem veel langer omdat zowel de client als server lokaal alle bestanden moeten lezen en daar checksums van maken. Maar het kan wel.

rsync hoef je niet de VM voor te stoppen, indien je de rsync doet vanaf de snapshot. Die moet je dan wel eerst mounten (zfs set snapdir=visible <filesystem>).

[CurlyMo]

Of zfs send naar een bestand.

[Kuusj]

Ik heb een nieuwe NAS gebouwd en ben bezig met het installeren van FreeNAS. Ik heb eerst FreeNAS 10 geprobeerd, maar de webinterface daarvan is zo gaar en buggy dat er niet mee te werken is. Nu dus FreeNAS 9.3, maar na installatie blijft het ding hangen op "loading kernel modules:". Ik gebruik USB sticks.

Specs:

#	Product	Prijs	Subtotaal
1	Intel Pentium G4560 Boxed	€ 57,95	€ 57,95
1	MSI H110M ECO	€ 53,95	€ 53,95
3	WD Red WD30EFRX, 3TB	€ 115,95	€ 347,85
1	BitFenix Neos Zwart/Zwart	€ 35,70	€ 35,70
1	Crucial CT4G4DFS8213	€ 28,95	€ 28,95
1	Seasonic G-series 360 watt	€ 63,95	€ 63,95
Bekijk collectie Importeer producten		Totaal	€ 588,35

Ik heb ergens gelezen dat ik de installatie USB ook erin moet laten zitten oid, hoe dan ook, het wil niet langs loading kernel modules.

[Paul]

Kun je niet beter uitzoeken waarom je de webinterface van 10 zo "gaar en buggy" vindt? Dat is hij namelijk niet per definitie; bij mij werkt het gewoon goed?

[Kuusj]

Paul schreef op vrijdag 20 januari 2017 @ 16:38:
Kun je niet beter uitzoeken waarom je de webinterface van 10 zo "gaar en buggy" vindt? Dat is hij namelijk niet per definitie; bij mij werkt het gewoon goed?

Het werkt in de basis wel, maar zodra ik bijvoorbeeld een nieuw volume ga maken, daarna weer op het dashboard klik en daarna bijvoorbeeld naar de settings wil gaan reageert het menu nergens meer op. Vensters gaan steeds meer naar rechts staan en zo nog wel een aantal dingetjes die mij niet de bedoeling lijken.

Kan dit komen doordat ik een USB 2.0 stick gebruik? Of is het sowieso een goed idee om een kleine SSD te halen? pricewatch: Transcend SSD340K 32GB bijvoorbeeld.

[FREAKJAM]

FreeNAS 10 is in beta en nog lang niet af, vergeet dat ook niet.

[Paul]

Een SSD om FreeNAS van te booten is zonde, FreeNAS doet met die stick vrij weinig, het start er enkel vanaf op. De snelheid van de stick heeft er niks me te maken, "vroeger" was er nog niet eens USB 3 Wat wel kan is dat je USB stick mogelijk stuk is, kun je het met een andere proberen?

Verspringende vensters en een niet-reagerend menu herken ik totaal niet namelijk, hooguit dat er wat quirks in zitten dat je zowel boven als links een kopje "plugins", "jails", "storage" etc hebt en dat ze beiden andere opties geven.

[Kuusj]

FREAKJAM schreef op vrijdag 20 januari 2017 @ 16:48:
FreeNAS 10 is in beta en nog lang niet af, vergeet dat ook niet.

Ja daar ben ik me bewust van, ik heb een zwak voor leuke GUI's dus wilde die eerst proberen. Nu toch blijkt dat ik beter voor de stabiele software kan gaan wat ik maar met 10 tot die final is.

Paul schreef op vrijdag 20 januari 2017 @ 16:48:
Een SSD om FreeNAS van te booten is zonde, FreeNAS doet met die stick vrij weinig, het start er enkel vanaf op. De snelheid van de stick heeft er niks me te maken, "vroeger" was er nog niet eens USB 3 Wat wel kan is dat je USB stick mogelijk stuk is, kun je het met een andere proberen?

Verspringende vensters en een niet-reagerend menu herken ik totaal niet namelijk, hooguit dat er wat quirks in zitten dat je zowel boven als links een kopje "plugins", "jails", "storage" etc hebt en dat ze beiden andere opties geven.

Dat is goed om te weten. Ik zal eens proberen om de USB's te veranderen. Misschien dat FreeNAS 10 daardoor ook een beetje gaar liep.

Heb een andere stick geprobeerd, heb andere USB poorten geprobeerd maar hij blijft steken op "Loading kernel modules:". Heb de HDD's ook afgekoppeld maar dat maakt ook niks uit. Ik zal anders even 16GB ram erin gooien, kijken of dat wat uitmaakt.

Edit: dan toch maar opgegeven en gewoon weer versie 10 gepakt, nu met een andere USB stick lijkt het een stuk beter te werken. Of zou het aan 8GB RAM liggen ipv 4? Maakt ook niet uit, ik ga vanavond lekker veel kloten en leren haha.

[ Voor 16% gewijzigd door Kuusj op 20-01-2017 18:29 ]

[idef1x]

Zit nog eens de startpost te lezen en wellicht is het al voorbij gekomen, maar in het stukje over uitbreiding en dan het praktische gedeelte staat:

Je begint met een 6-disk 3TB RAID-Z2 met goede bescherming, maar wilt later nog wat extra ruimte. Je kunt dan bijvoorbeeld 3 disks 4TB in RAID-Z plaatsen voor 8TB extra opslagruimte.

Dat lijkt mij toch niet echt praktisch daar een ketting net zo sterk is als de slechtste schakel. In dit gevail ga je met je uitbreiding met een Z1 je goede bescherming van een Z2 te niet doen. De Z1 en Z2 vdevs worden immers gestriped?
Of lees ik dit nu verkeerd? Dat het kan oke, maar praktisch?

[FireDrunk]

In die zin staat toch nergens dat je het in 1 pool moet stoppen? Je kan gewoon 2 losse pools naast elkaar draaien?

[HyperH]

Ik ben bezig met het samenstellen van een nieuw FreeNAS systeem.

De oude data draait op een andere FreeNAS ZFS box en moet worden over gezet naar de nieuwe.
Het is de bedoeling dat de oude bij een zwager komt te staan en dan kunnen we op gezette tijden synchroniseren via internet. VPN of SSH moet veilig genoeg zijn.

De oude box draait met 3 hdds in een zraid. De nieuwe gaat dat ook doen.

Ik vroeg me af of ik in de nieuwe box een losse disk kan hangen om tijdelijke data op te slaan. Denk aan een remote hdd om op te werken vanaf een laptop of als audio file server voor mijn versterker.
Dit zou dan een SSD kunnen zijn, zodat de gewone hdds niet altijd hoeven te draaien.
Belangrijke data zet ik dan later wel weer naar de zraid storage.

Is dit een goed idee qua performance (snelheid / energie verbruik) of kan ik beter de ssd als cache disk gebruiken voor de zfs pool?

[FireDrunk]

Als je een SSD als read cache (L2ARC) inzet, zal dat weinig helpen tegen het opspinnen van de disks. ARC en L2ARC helpen wel bij het niet opspinnen van disks, maar ook weer niet super goed. Zodra je schrijft, spint de hele handel op.

Zelfde geldt als je de SSD als SLOG inzet.

Als je het toch al niet erg vindt om de data handmatig te 'backuppen' naar je raidz array, zou ik dat lekker doen.

[HyperH]

Dank je voor de uitleg. Ik ga er dan toch een losse SSD met ZFS bij zetten in een eigen pool denk ik.
Dan kan voor de simpele niet kritische taken lekker snel met de SSD op een gbit lan gewerkt worden. Als het goed is blijven de HDD's dan in een energiezuinige modus totdat er een beroep op wordt gedaan.

Je schrijft 'backup' tussen aanhalingstekens. Wat is er mis met deze aanpak?
In principe is het niet kritische data. Ik gebruik het om b.v. muziek te streamen naar mijn speakers en als werk schijf voor audio/video/code. Pas als het klaar is komt het in de permanente backup op de ZFS pool met HDD's.

Ik wil de nieuwe NAS en de oude met elkaar synchroniseren. De eerste keer moet de lege pool op de nieuwe echter gevuld worden met de oude data.
Hoe kan ik dit het best doen? Send/receive is misschien niet zo snel over ssh?

[syl765]

Je kan zfs send en receive ook gebruiken in combinatie met netcat of mbuffer.
Je hebt dan niet de overhead van ssh.

[idef1x]

syl765 schreef op vrijdag 3 februari 2017 @ 13:15:
Je kan zfs send en receive ook gebruiken in combinatie met netcat of mbuffer.
Je hebt dan niet de overhead van ssh.

+1 voor mbuffer...scheelde bij mij een doorvoer van een 200Mbps over een 1Gbps link t.o.v. ssh

[dcm360]

Dan liep je met SSH vermoedelijk tegen een CPU-limiet op, want SSH is best zwaar vanwege de encryptie die wordt toegepast.

Maar sowieso is mbuffer wel handig om de snelheid mee te verhogen. De schijven in mn oude game-bak schrijven prima sneller weg dan gigabit, maar bij vlagen is er ook andere access en dan is het wel handig dat er een buffer tussen zit om dat op te vangen.

[idef1x]

Niet echt als ik zo mijn cpu utillisation bekijk in die periode...een 60% zo'n beetje

[HyperH]

Mijn oude nas draaide met FreeNAS vanaf een usb-stick. Ik twijfel nu of de nieuwe build wederom van usb-stick gaat draaien of dat het vanaf een disk moet draaien. Complicerende factor is dat ik encryptie wil gebruiken in de pool met HDD's.

Ik speel met de gedachte om een SSD toe te voegen in een eigen pool. Niet voor L2ARC of SLOG maar puur als snelle disk voor veelgebruikte data en om de HDD's zo weinig mogelijk te laten opspinnen. (de HDD's zijn voor permanente opslag, de SSD voor tijdelijke data, muziek streamen naar speakers en veelgebruikte bestanden)

Is het verstandig om FreeNAS ook op deze SSD te installeren? (de SSD mag evtentueel unencrypt zijn)
Kan ik dan het beste voor root on zfs gaan of een ander fs? (de usb stick had natuurlijk geen zfs partitie)
Misschien is het beter om twee USB sticks te hebben i.p.v. een enkele partitie op een SSD voor redundancy?

Laatste vraag betreft het merk / type SSD. Samsung SSD's zijn niet geschikt voor L2ARC of SLOG las ik. Hoe zit het met de 'power safe functie' en ingebouwde 'cache' van bijvoorbeeld de Crucial MX300? Zou dat ZFS in de weg kunnen zitten?

[ Voor 18% gewijzigd door HyperH op 07-02-2017 00:42 ]

[revox862]

zpool destory filesystem, is weg he?

[Verwijderd]

HyperH schreef op dinsdag 7 februari 2017 @ 00:23:
Mijn oude nas draaide met FreeNAS vanaf een usb-stick. Ik twijfel nu of de nieuwe build wederom van usb-stick gaat draaien of dat het vanaf een disk moet draaien. Complicerende factor is dat ik encryptie wil gebruiken in de pool met HDD's.

Dat heeft toch niets te maken of je OS op een USB-stick of op een disk draait? Waar je van boot kan zelf niet encrypted zijn. Maar je kunt bij een disk bijvoorbeeld partities maken waarbij je de eerste partitie voor een unencrypted boot-pool gebruikt en de tweede partitie een encrypted data partitie voor de grote ZFS pool waar alle data op komt (behalve voor de boot / het OS).

Ik speel met de gedachte om een SSD toe te voegen in een eigen pool. Niet voor L2ARC of SLOG maar puur als snelle disk voor veelgebruikte data en om de HDD's zo weinig mogelijk te laten opspinnen. (de HDD's zijn voor permanente opslag, de SSD voor tijdelijke data, muziek streamen naar speakers en veelgebruikte bestanden)

Dat kan, gewoon een ZFS pool op een SSD ipv HDD.

Is het verstandig om FreeNAS ook op deze SSD te installeren? (de SSD mag evtentueel unencrypt zijn)
Kan ik dan het beste voor root on zfs gaan of een ander fs? (de usb stick had natuurlijk geen zfs partitie)
Misschien is het beter om twee USB sticks te hebben i.p.v. een enkele partitie op een SSD voor redundancy?

Dit zijn vragen die specifiek op je gekozen OS ingaan. Van FreeNAS weet ik dat deze SSDs maar voor één doeleinde toestaat te gebruiken - dat is enorm zonde. Dus als je er FreeNAS op kwakt kun je niets meer met de SSD en kun je L2ARC of sLOG vergeten; meerdere doeleinden 'mag' dus niet. Om die reden raad ik het af, want voor de boot snelheid hoef je het echt niet te doen. En redundancy? Wat wil je behouden precies? Lijkt mij allemaal erg overdreven voor thuis.

Laatste vraag betreft het merk / type SSD. Samsung SSD's zijn niet geschikt voor L2ARC of SLOG las ik. Hoe zit het met de 'power safe functie' en ingebouwde 'cache' van bijvoorbeeld de Crucial MX300? Zou dat ZFS in de weg kunnen zitten?

Alle SSDs zijn geschikt voor L2ARC; weinig SSDs zijn geschikt voor sLOG. Crucial MX-series hebben capacitors waardoor deze de FLUSH honoreren, terwijl consumenten SSDs van Samsung dit niet doen. Dat maken deze Samsung SSDs ongeschikt voor sLOG, maar je kunt ze prima voor L2ARC gebruiken. Bedenk wel dat Samsung je TLC geeft terwijl je bij Crucial voor dezelfde prijs MLC krijgt. Technisch is Crucial vaak beter op papier. In de praktijk maakt het allemaal niet zoveel uit - behalve de capacitors dan.

Samsung SSDs zijn om dezelfde reden ook ongeschikt om in RAID-arrays te gebruiken, of in ZFS pools met meerdere devices - met name RAID-Z1/2/3 en sLOG is ongeschikt. Dit slaat dus op de SSD zelf, niet de data pool met hardeschijven. Hardeschijven kennen dit probleem niet. Daarvan verandert de inhoud van reeds bevestigde (FLUSHed) data niet.

revox862 schreef op vrijdag 10 maart 2017 @ 11:52:
zpool destory filesystem, is weg he?

Een filesystem kun je niet met 'zpool destroy' vernietigen, dat kan alleen met 'zfs destroy'. Als je je hele pool hebt verwijderd, kun je deze eenvoudigweg importeren met de -d flag, zodat je destroyed pools weer zichtbaar maakt. Als je je filesystem hebt vernietigt, dan is die weg ja.

[revox862]

Verwijderd schreef op vrijdag 10 maart 2017 @ 12:15:
[...]

Een filesystem kun je niet met 'zpool destroy' vernietigen, dat kan alleen met 'zfs destroy'. Als je je hele pool hebt verwijderd, kun je deze eenvoudigweg importeren met de -d flag, zodat je destroyed pools weer zichtbaar maakt. Als je je filesystem hebt vernietigt, dan is die weg ja.

Oh, ja dat bedoel ik ook. zfs destroy. Prima
Overigens haal ik die wel vaker door elkaar (zpool en zfs) en type ik ook vaak destory i.p.v. destroy.

[ Voor 10% gewijzigd door revox862 op 10-03-2017 13:26 ]

[Endpoint]

kuusj98 schreef op vrijdag 20 januari 2017 @ 16:35:
Ik heb een nieuwe NAS gebouwd en ben bezig met het installeren van FreeNAS. Ik heb eerst FreeNAS 10 geprobeerd, maar de webinterface daarvan is zo gaar en buggy dat er niet mee te werken is. Nu dus FreeNAS 9.3, maar na installatie blijft het ding hangen op "loading kernel modules:". Ik gebruik USB sticks.

Specs:

#	Product	Prijs	Subtotaal
1	Intel Pentium G4560 Boxed	€ 57,95	€ 57,95
1	MSI H110M ECO	€ 53,95	€ 53,95
3	WD Red WD30EFRX, 3TB	€ 115,95	€ 347,85
1	BitFenix Neos Zwart/Zwart	€ 35,70	€ 35,70
1	Crucial CT4G4DFS8213	€ 28,95	€ 28,95
1	Seasonic G-series 360 watt	€ 63,95	€ 63,95
Bekijk collectie Importeer producten		Totaal	€ 588,35

Ik heb ergens gelezen dat ik de installatie USB ook erin moet laten zitten oid, hoe dan ook, het wil niet langs loading kernel modules.

Na zelf veel gekloot te hebben met (bijna) dezelfde config blijkt dit aan Kaby Lake processor te liggen. Is een bekende issue, schijnt binnenkort opgelost te worden.

9.10.1 werkt wel, vanaf 9.10.2 is het gestopt.

[Kuusj]

TomdeJ schreef op vrijdag 10 maart 2017 @ 17:36:
[...]


Na zelf veel gekloot te hebben met (bijna) dezelfde config blijkt dit aan Kaby Lake processor te liggen. Is een bekende issue, schijnt binnenkort opgelost te worden.

9.10.1 werkt wel, vanaf 9.10.2 is het gestopt.

Ah, bedankt haha Heb sowieso al een harde les geleerd: altijd je USB back-uppen GRUB-boot error: USB dood. 2 nieuwe USB3.0 16GB stickjes gehaald, daar 9.10 mee proberen te installeren (omdat ik toch meer heb aan een GUI die goed werkt dan eentje die mooi uit ziet) maar tevergeefs. Maar dit verklaard het!

[Verwijderd]

revox862 schreef op vrijdag 10 maart 2017 @ 13:24:
[...]

Oh, ja dat bedoel ik ook. zfs destroy. Prima
Overigens haal ik die wel vaker door elkaar (zpool en zfs) en type ik ook vaak destory i.p.v. destroy.

Mja het gebeurt mij ook wel eens. Toch moet je een beetje voorzichtig zijn hiermee....

Zpool destroy kun je nog terugdraaien (en faalt wanneer je pool in gebruik is) maar zfs destroy is onomkeerbaar en dus erg gevoelig voor user-error.

[revox862]

Verwijderd schreef op vrijdag 10 maart 2017 @ 19:47:
[...]

Mja het gebeurt mij ook wel eens. Toch moet je een beetje voorzichtig zijn hiermee....

Zpool destroy kun je nog terugdraaien (en faalt wanneer je pool in gebruik is) maar zfs destroy is onomkeerbaar en dus erg gevoelig voor user-error.

With great power
Ook geen backup natuurlijk. Was alles maar weg. Per ongelijk dan he, expres zou ik dat niet kunnen.

[Verwijderd]

Het helpt als je regelmatig snapshots maakt, zodat een destroy commando ook weer extra parameters nodig heeft, en zonder parameter zie je welke snapshots de dataset in gebruik houdt. Dat heeft mij zeker een paar keer gered van totale data-annihilatie.

[A1AD]

Ik heb een test disk voor wat prul VM's als single disk ZFS, deze disk vertoonde wat kuren dus ikke:

"zpool replace poolname disk_old disk_new"

met de gedachte van achteraf zpool detach poolname disk_old te doen... maar helaas:
"cannot detach dm-name-hddisk500: no valid replicas"

Heb ik nu per ongeluk een 2disk "raid0" en kan ik dus mijn oude schijf niet verwijderen?.

status:

code:

zpool status wdpool
  pool: wdpool
 state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: resilvered 201G in 5h32m with 3 errors on Mon Mar 13 15:42:37 2017
config:
    NAME                     STATE     READ WRITE CKSUM
    wdpool                   ONLINE       0     0     0
      replacing-0            ONLINE       0     0     0
        dm-name-hddisk500    ONLINE       0     0     0
        dm-name-hddisk500.1  ONLINE       0

Wat betekend die: "replacing-0" ? Ik kan de data eenvoudig naar mijn main pool send-receiven, de wdpool opnieuw aanmaken en weer terug sturen. Maar vraag me af wat ik fout gedaan heb?

Had ik de nieuwe disk moeten attachen IPV replacen?

[FireDrunk]

Replacing-0 is de tijdelijke mirror naam.
Verdwijnt zodra je replace klaar is.

[A1AD]

FireDrunk schreef op maandag 13 maart 2017 @ 18:54:
Replacing-0 is de tijdelijke mirror naam.
Verdwijnt zodra je replace klaar is.

Mijn replace was al klaar. Dus ik haal dan gewoon de schijf eruit?

[FireDrunk]

Als het goed is, is de schijf dan ook uit de pool. Als dat zo is, kan je hem gewoon weghalen ja.

[A1AD]

FireDrunk schreef op dinsdag 14 maart 2017 @ 09:53:
Als het goed is, is de schijf dan ook uit de pool. Als dat zo is, kan je hem gewoon weghalen ja.

Nee, daar gaat het nu juist om. De status van mijn pool is zoals in mijn eerste post (maandag 13 maart 2017 16:30)

[FireDrunk]

Vreemd, je zou hem nu gewoon moeten kunnen detachen.

[A1AD]

FireDrunk schreef op dinsdag 14 maart 2017 @ 11:38:
Vreemd, je zou hem nu gewoon moeten kunnen detachen.

code:

root@pve:~/utils/disks# zpool status wdpool
  pool: wdpool
 state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: resilvered 201G in 5h32m with 3 errors on Mon Mar 13 15:42:37 2017
config:

    NAME                     STATE     READ WRITE CKSUM
    wdpool                   ONLINE       0     0   268
      replacing-0            ONLINE       0     0   536
        dm-name-hddisk500    ONLINE       0     0   536
        dm-name-hddisk500.1  ONLINE       0     0   536

errors: 1 data errors, use '-v' for a list


root@pve:~/utils/disks# zpool detach wdpool dm-name-hddisk500
cannot detach dm-name-hddisk500: no valid replicas

Zou het kunnen komen omdat er checksum errors aanwezig zijn op de pool?

[CurlyMo]

Heb je geprobeerd hem eerst offline te halen?

[A1AD]

CurlyMo schreef op dinsdag 14 maart 2017 @ 11:57:
Heb je geprobeerd hem eerst offline te halen?

Ja hoor

code:

root@pve:~/utils/disks# zpool offline wdpool dm-name-hddisk500
cannot offline dm-name-hddisk500: no valid replicas

[CurlyMo]

Kan je een verbose output geven van zpool status? Zit je probleem misschien in de metadata?

[A1AD]

CurlyMo schreef op dinsdag 14 maart 2017 @ 12:02:
Kan je een verbose output geven van zpool status? Zit je probleem misschien in de metadata?

Het probleem zit in een VM dataset

code:

errors: Permanent errors have been detected in the following files:

        wdpool/vm-disks/vm-110-disk-1:<0x1>

[CurlyMo]

Daar is dus je verklaring. Je pool metadata is corrupt. Kloppen je dev paden wel?

[ Voor 19% gewijzigd door CurlyMo op 14-03-2017 12:05 ]

[A1AD]

CurlyMo schreef op dinsdag 14 maart 2017 @ 12:04:
Daar is dus je verklaring. Je pool metadata is corrupt. Kloppen je dev paden wel?

Dat moet je mij toch is verder uitleggen, omdat er 1 dataset van de zovele een probleempje heeft kan ik mijn schijf niet vervangen?

De dataset wordt gebruikt als root schijf voor een KVM VM welke nog perfect werkt.

edit: mijn dev paden kloppen ja, het zijn luks encrypted disks op /dev/mapper/dm-name-...

[ Voor 10% gewijzigd door A1AD op 14-03-2017 12:07 ]

[CurlyMo]

Kan je eens een uitdraait geven van zpool status alleen

[FireDrunk]

Er is data die dus corrupt is, en ZFS kan niet garanderen dat die data beschikbaar blijft als je 1 van de 2 devices offline haalt. Je zal dus ofwel dmv een scrub alles moeten repareren, ofwel de errors moeten clearen (niet aan te raden).

In eerste instantie zou ik van die desbetreffende file (vm-110-disk-1) een inhoudelijke backup maken.

[A1AD]

CurlyMo schreef op dinsdag 14 maart 2017 @ 12:14:
Kan je eens een uitdraait geven van zpool status alleen

code:

root@pve:~/utils/disks# zpool status wdpool 
  pool: wdpool
 state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: resilvered 201G in 5h32m with 3 errors on Mon Mar 13 15:42:37 2017
config:

    NAME                     STATE     READ WRITE CKSUM
    wdpool                   ONLINE       0     0   277
      replacing-0            ONLINE       0     0   554
        dm-name-hddisk500    ONLINE       0     0   554
        dm-name-hddisk500.1  ONLINE       0     0   554

FireDrunk schreef op dinsdag 14 maart 2017 @ 12:24:
Er is data die dus corrupt is, en ZFS kan niet garanderen dat die data beschikbaar blijft als je 1 van de 2 devices offline haalt. Je zal dus ofwel dmv een scrub alles moeten repareren, ofwel de errors moeten clearen (niet aan te raden).

In eerste instantie zou ik van die desbetreffende file (vm-110-disk-1) een inhoudelijke backup maken.

De data op zich is niet belangrijk, deze opzet is playground. Dit was ik nog niet tegen gekomen en probeer wat bij te leren. Ik zal de dataset eens verwijderen en opnieuw proberen, dan weten we of je stelling klopt

[CurlyMo]

Een zpool status zonder wdpool erachter.

[syl765]

je kan ook eens een zfs split proberen.
Hiermee splits je de mirror naar twee pools, ik denk dat je tegen hetzelfde probleem aanloopt, maar het proberen waard.
Of gewoon de pool exporteren en dan 1 disk read only importeren.
Je kan dat dan ook doen met de andere disk en kijken welke de juiste data geeft. Maar wat vreemd is dat ze beide evenveel checksums errors geven.

[Verwijderd]

@A1AD: bij checksum errors dien je zo snel mogelijk MemTest86+ te draaien om defect RAM geheugen uit te sluiten. Zoveel checksum errors is extreem verdacht en kan eigenlijk niet veel anders zijn dan of catastrofale hardware-falure (bugs in de controller of hardeschijven; dirty buffers die verdwenen zijn doordat je Hardware RAID controllers gebruikt) of RAM geheugencorruptie.

Mijn advies is dus om niets meer te doen met de disks totdat je zeker weet dat de hardware goed is. En te beginnen met je RAM geheugen. 9 van de 10 keer is dit de oorzaak van excessieve checksum errors.

[CyBeR]

Inderdaad. Normaal gesproken horen al die getallen nul te zijn…

[root@juliet ~]# zpool status
  pool: zones
 state: ONLINE
  scan: scrub repaired 0 in 3h49m with 0 errors on Sun Mar 12 21:59:02 2017
config:

        NAME        STATE     READ WRITE CKSUM
        zones       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c1t0d0  ONLINE       0     0     0
            c1t1d0  ONLINE       0     0     0

errors: No known data errors

[A1AD]

Verwijderd schreef op dinsdag 14 maart 2017 @ 23:30:
@A1AD: bij checksum errors dien je zo snel mogelijk MemTest86+ te draaien om defect RAM geheugen uit te sluiten. Zoveel checksum errors is extreem verdacht en kan eigenlijk niet veel anders zijn dan of catastrofale hardware-falure (bugs in de controller of hardeschijven; dirty buffers die verdwenen zijn doordat je Hardware RAID controllers gebruikt) of RAM geheugencorruptie.

Mijn advies is dus om niets meer te doen met de disks totdat je zeker weet dat de hardware goed is. En te beginnen met je RAM geheugen. 9 van de 10 keer is dit de oorzaak van excessieve checksum errors.

Ik heb op dezelfde hardware 3 Pools die nog veel meer worden gebruikt zonder checksum errors (een mirror van 2 ssds voor de root, 1 data store ssd en een 5 disk raidz2)

De pool met checksum errors is een 2.5inch laptop schijfje.

Gezien dat de andere Pools wel OK zijn is de kans toch zeer groot dat het aan de laptop schijf zelf zal liggen?

[CurlyMo]

CurlyMo schreef op dinsdag 14 maart 2017 @ 15:21:
Een zpool status zonder wdpool erachter.

Kan je nog steeds deze draaien?

[A1AD]

CurlyMo schreef op woensdag 15 maart 2017 @ 06:58:
[...]

Kan je nog steeds deze draaien?

Sure, ik ben een HD aan het resilveren op mijn main pool.

Maar ik ga het over een andere boeg gooien; 2de schijf (die ik wou vervangen) van de wdpool detachen en een wdpool2 aanmaken, dan send en receiven van wdpool > wdpool2 ... (behalve dan de corrupte data)

[CurlyMo]

A1AD schreef op woensdag 15 maart 2017 @ 11:02:
[...]
Sure, [..]

Waar is de output dan?

[A1AD]

CurlyMo schreef op woensdag 15 maart 2017 @ 11:17:
[...]

Waar is de output dan?

Die is voor al mijn pools perfect normaal, wat wil je juist weten? Geen checksum errors of dergelijke.

[CurlyMo]

A1AD schreef op woensdag 15 maart 2017 @ 11:20:
[...]


Die is voor al mijn pools perfect normaal, wat wil je juist weten? Geen checksum errors of dergelijke.

Ik wil die output weten

[A1AD]

CurlyMo schreef op woensdag 15 maart 2017 @ 11:20:
[...]

Ik wil die output weten

Ok dan.. omdat jij het bent ;-)

Main pool:

code:

root@pve:~# zpool status bds
  pool: bds
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
    continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed Mar 15 08:02:16 2017
    2.23T scanned out of 10.9T at 199M/s, 12h42m to go
    457G resilvered, 20.47% done
config:

    NAME                   STATE     READ WRITE CKSUM
    bds                    DEGRADED     0     0     0
      raidz2-0             DEGRADED     0     0     0
        dm-name-disk1.1    ONLINE       0     0     0
        dm-name-disk2.0    ONLINE       0     0     0
        dm-name-disk3.1    ONLINE       0     0     0
        replacing-3        OFFLINE      0     0     0
          dm-name-disk4.1  OFFLINE      0     0     0
          dm-name-disk4.2  ONLINE       0     0     0  (resilvering)
        dm-name-disk5.1    ONLINE       0     0     0

errors: No known data errors

evopool (datastore)

code:

root@pve:~# zpool status evopool 
  pool: evopool
 state: ONLINE
  scan: scrub repaired 0 in 0h7m with 0 errors on Wed Mar 15 01:07:38 2017
config:

    NAME               STATE     READ WRITE CKSUM
    evopool            ONLINE       0     0     0
      dm-name-evodisk  ONLINE       0     0     0

errors: No known data errors

rpool

code:

root@pve:~# zpool status rpool 
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0 in 0h3m with 0 errors on Wed Mar 15 01:03:15 2017
config:

    NAME        STATE     READ WRITE CKSUM
    rpool       ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdh2    ONLINE       0     0     0
        sdi2    ONLINE       0     0     0

errors: No known data errors

wdpool

code:

root@pve:~# zpool status wdpool -v
  pool: wdpool
 state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: scrub in progress since Wed Mar 15 11:08:49 2017
    15.7G scanned out of 190G at 16.6M/s, 2h59m to go
    0 repaired, 8.29% done
config:

    NAME                 STATE     READ WRITE CKSUM
    wdpool               ONLINE       0     0     0
      dm-name-hddisk500  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        <0x192>:<0x1>

[ Voor 16% gewijzigd door A1AD op 15-03-2017 11:25 ]

[CurlyMo]

Nu heb je wdpool er weer niet in zitten. Draai gewoon eens een zpool status en niks anders. Dan de volledige output hier posten.

[A1AD]

CurlyMo schreef op woensdag 15 maart 2017 @ 11:24:
Nu heb je wdpool er weer niet in zitten. Draai gewoon eens een zpool status en niks anders. Dan de volledige output hier posten.

Toegevoegd, dus ik heb die 2de schijf gedetached, de corrupte files verwijderd en nu een scrub draaien.
Als dat gedaan is zal ik nog eens een replace doen.

edit: na het verwijderen van de corrupte bestanden had ik een "clear" gedaan..

[ Voor 9% gewijzigd door A1AD op 15-03-2017 11:29 ]

[CurlyMo]

Was niet het probleem dat je die schijf niet losgekoppeld kreeg of heb je dat afgedwongen via een clear?

[ Voor 23% gewijzigd door CurlyMo op 15-03-2017 11:30 ]

[A1AD]

CurlyMo schreef op woensdag 15 maart 2017 @ 11:29:
Was niet het probleem dat je die schijf niet losgekoppeld kreeg of heb je dat afgedwongen via een clear?

De originele inderdaad, die staat nog steeds in de pool.

edit: na het replacen de 2de schijf weer gedetached, dit ging wel
edit: dus nu probeer ik een error vrije pool te creeren, om dan eens opnieuw te replacen

[ Voor 22% gewijzigd door A1AD op 15-03-2017 11:32 ]

[FireDrunk]

Na de clear kan je inderdaad waarschijnlijk weer detachen omdat er geen 'state' is waarin ZFS denkt dat er te weinig replica's zijn. Mijn statement houdt dus stand

[A1AD]

FireDrunk schreef op woensdag 15 maart 2017 @ 12:52:
Na de clear kan je inderdaad waarschijnlijk weer detachen omdat er geen 'state' is waarin ZFS denkt dat er te weinig replica's zijn. Mijn statement houdt dus stand

Niet helemaal getest.

1: replace
2: oude schijf niet te detachen
3: clear
4: oude schijf niet te detachen
5: nieuwe schijf detach ok
6: corrupte files verwijderen
7: clear
8: scrub
9: replace
10: oude schijf is nu wel te verwijderen

Na het clearen (stap 3) ging de detach van de oude schijf niet, dat heb ik getest. MAAR toen waren de corrupte bestanden nog niet verwijderd, dus je statement kan zeker wel kloppen hoor.

Ik ben nu aan het zorgen dat de originele pool gecleared is en vrij is van corrupte bestanden om zo nog eens de replace te doen. Als dan alles goed gaat staat het zo goed als vast dat ZFS weigert een replace te doen wanneer er ook maar 1 lullig bestandje corrupt is op een pool zonder redundantie.

_{I know, deze test had ook veel sneller gekund , en best leuk is om nog eens te verifiëren (wie heeft er nu ook een pool zonder replica's )}

edit:
@FireDrunk @CurlyMo Na het verwijderen van de corrupte bestanden + clear + scrub is de replace wel mooi gelukt (zonder te moeten detachen oid):

code:

  pool: wdpool
 state: ONLINE
  scan: resilvered 163G in 3h59m with 0 errors on Wed Mar 15 18:25:41 2017
config:

    NAME                   STATE     READ WRITE CKSUM
    wdpool                 ONLINE       0     0     0
      dm-name-hddisk500.1  ONLINE       0     0     0

errors: No known data errors

[ Voor 18% gewijzigd door A1AD op 16-03-2017 08:58 ]

[CurlyMo]

Vraagje over de grote van de ZIL / SLOG. Op internet lees ik dat dit afhangt van de snelheid van je netwerk:

ZFS will take data written to the ZIL and write it to your pool every 5 seconds. Here is some simple throughput math using a 1Gb connection. The maximum throughput, ignoring overheads and assuming one direction, would be .125 Gigabytes per second. With 5 seconds between SLOG flushes and using a 1Gbit link with 100% synchronous writes, the most you will see written to your SLOG is 5 x .125 GB = .625 GB.

Nu draai ik ESXi waardoor het interne ESXi netwerk via RAM wordt gebruikt om tussen de virtuele machines te communiceren. Maakt dat de eis aan de grote van de SLOG / ZIL niet anders? Moet hij in die situatie niet veel groter zijn?

[Bigs]

Als je daadwerkelijk een datastroom met continu 10Gb/s sync writes aanlevert aan je storage dan zou je je ZIL kunnen vergroten ja. Maar haal je dat? Het moet ook ergens vandaan komen