Het grote ZFS topic

[jacovn]

Ok copy is klaar, dus ik wil de server upgraden.
Het gaat om zfsguru 9.1-005 met gui 0.2.0 beta 8

Helaas is hij onder system - install - root on zfs al bezig (of nog steeds bezig) met iets te doen. Download kan nooit zo lang duren met mijn verbinding..

Web interface upgrade dan eerst maar, helaas foutmelding:
Downloading of "http://bravo.zfsguru.com/interface/ZFSguru-0.2.0-beta9-webinterface.tgz" failed

Systeem staat primair naar Afla te kijken, maar toch foutmelding op Bravo ?
Zijn de systemen in de lucht aan de server kant ?

update: CD erin gedaan en 10.1 geinstalleerd.

update2: server 3 is nadat de copy klaar was min of meer bevroren.
webgui werkt, kan aanloggen met ssh, maar als ik naar root nivo ga bevriest de sessie.

Als ik nog troubleshooting data kan opleveren hoor ik het wel, laat hem wel een paar uur staan zo.

[ Voor 21% gewijzigd door jacovn op 07-04-2015 14:43 ]

[pica]

@jacovn, ik was gister ook lekker aan het klooien met ZFSguru, maar ik krijg inderdaad ook de laatste versie niet meer gedownload.
Best vervelend aangezien nu mijn pool niet meer wordt ingelezen omdat ik zo stom was geweest bepaalde features aan te zetten welke alleen beschikbaar zijn bij de laatste versies.

[FireDrunk]

Werkt de laatste livecd van FreeBSD zelf niet? (11-CURRENT) ?

[pica]

Hoogstwaarschijnlijk wel, heb alleen geen tijd meer gehad om te testen .
Het is een hobbieservertje dus het is niet zo'n grote ramp als het wat langer duurt.

[jacovn]

Ik heb hem weer draaien met 10.1 vanaf de CD die ik had liggen. In ieder geval een standaard server zodat ik de settings van de anderen naar standaard kan brengen

[Maestro]

Wordt het gewaardeerd als ik hier wat info verstrek over m.i. goedkope RES2SV240 SAS expanders?
Heb er deze ochtend twee besteld voor 197 euro (en verwacht 50 euro douanekosten):

https://forums.servetheho...ads/intel-res2sv240.4632/

[jacovn]

Ik heb er 3 gekocht voor $75 per stuk en $67 verzend kosten.
Dus 3 x ~70 euro voor de units, rond 60 euro verzendkosten en iets van 61 voor douane kosten.
Ze zijn nu voor mij ~110 euro per stuk

Die ik kreeg hadden 6 stuks SFF-8087 kabels per kaart

Maar ik hoor graag je ervaring, ik heb ze voor toekomstige uitbreiding gekocht.

[ Voor 26% gewijzigd door jacovn op 08-04-2015 13:33 ]

[Maestro]

Dat komt overeen (ook $75 per stuk, met 51 euro verzending betaald hier, douane volgt)
Helaas gaat niet lukken een on-topic ervaring te geven, heb ze samen met een Intel RS25AB080 gekocht en dan weet je 't wel: Daar houden jullie hier helemaal niet van

[jacovn]

Voor ZFS heb je geen RAID kaar nodig, tenzij hij in jbod kan voor zijn poorten.

Schijnbaar zegt die ebay verkoper soms ook wel ja tegen $60 maar ik wilde maar geen risico nemen voor zijn extra werk voor international verzending wellicht 3 x $15 te veel betaald.

[jacovn]

Ok tijd om te testen

2 servers.

zfsguru1 - 192.168.3.151 (Supermicro X9SAE-f met E3-1265Lv2 32 GB ram, intel X520-da2)
zfsguru3 - 192.168.3.153 (supermicro X10SL7-F met E3-1220v3 32 GB ram, intel X520-da2)


Stap 1)

Server:

code:

[root@zfsguru1 /home/ssh]# iperf -s -f m -m -i 5
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 0.06 MByte (default)
------------------------------------------------------------
[  4] local 192.168.3.151 port 5001 connected with 192.168.3.153 port 46832
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 5.0 sec  4454 MBytes  7473 Mbits/sec
[  4]  5.0-10.0 sec  4631 MBytes  7770 Mbits/sec
[  4] 10.0-15.0 sec  4667 MBytes  7829 Mbits/sec
[  4] 15.0-20.0 sec  4684 MBytes  7858 Mbits/sec
[  4] 20.0-25.0 sec  4693 MBytes  7874 Mbits/sec
[  4] 25.0-30.0 sec  4683 MBytes  7857 Mbits/sec
[  4] 30.0-35.0 sec  4687 MBytes  7863 Mbits/sec
[  4] 35.0-40.0 sec  4636 MBytes  7779 Mbits/sec
[  4] 40.0-45.0 sec  4401 MBytes  7384 Mbits/sec
[  4] 45.0-50.0 sec  4527 MBytes  7594 Mbits/sec
[  4] 50.0-55.0 sec  4702 MBytes  7889 Mbits/sec
[  4] 55.0-60.0 sec  4477 MBytes  7511 Mbits/sec
[  4]  0.0-60.0 sec  55246 MBytes  7722 Mbits/sec
[  
------------------------------------------------------------

Client:

code:

[root@zfsguru3 /home/ssh]# iperf -c 192.168.3.151 -f m -m -i 5 -t 60
Client connecting to 192.168.3.151, TCP port 5001
TCP window size: 0.03 MByte (default)
------------------------------------------------------------
[  3] local 192.168.3.153 port 46832 connected with 192.168.3.151 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  4454 MBytes  7473 Mbits/sec
[  3]  5.0-10.0 sec  4631 MBytes  7770 Mbits/sec
[  3] 10.0-15.0 sec  4667 MBytes  7830 Mbits/sec
[  3] 15.0-20.0 sec  4684 MBytes  7858 Mbits/sec
[  3] 20.0-25.0 sec  4693 MBytes  7874 Mbits/sec
[  3] 25.0-30.0 sec  4683 MBytes  7857 Mbits/sec
[  3] 30.0-35.0 sec  4686 MBytes  7863 Mbits/sec
[  3] 35.0-40.0 sec  4637 MBytes  7779 Mbits/sec
[  3] 40.0-45.0 sec  4404 MBytes  7389 Mbits/sec
[  3] 45.0-50.0 sec  4524 MBytes  7589 Mbits/sec
[  3] 50.0-55.0 sec  4702 MBytes  7889 Mbits/sec
[  3] 55.0-60.0 sec  4479 MBytes  7515 Mbits/sec
[  3]  0.0-60.0 sec  55246 MBytes  7724 Mbits/sec
[  3] MSS size 1448 bytes (MTU 1500 bytes, ethernet)4] MSS size 1448 bytes (MTU 1500 bytes, ethernet)

TCP window naar 0.13 Mbyte verminderde throughput tot 1/3 ongeveer: [ 4] 0.0-60.0 sec 19799 MBytes
2768 Mbits/sec


Stap 2)

Ik moest de syntax op 1 punt veranderen (optie -4 toevoegen) omdat ik anders een foutmelding kreeg.

Uiteindelijk gevonden door wat voorbeelden te googelen..


Server:

code:

[root@zfsguru1 /home/ssh]# mbuffer -4 -s 128k -m 1G -I 192.168.3.153:5002 > /dev/null
in @ 1122 MiB/s, out @ 1122 MiB/s, 9883 MiB total, buffer   0% full
summary: 1e+04 Byte in  9.4sec - average of 1064 MiB/s

Client:

code:

[root@zfsguru3 /home/ssh]# dd if=/dev/zero bs=1M count=10000 | mbuffer -4 -s 128k -m 1G -O 192.168.3.151:5002
in @ 1122 MiB/s, out @ 1122 MiB/s, 8842 MiB total, buffer 100% full10000+0 records in
10000+0 records out
10485760000 bytes transferred in 8.650521 secs (1212153575 bytes/sec)
in @  0.0 KiB/s, out @ 1122 MiB/s, 9965 MiB total, buffer   3% full
summary: 1e+04 Byte in  9.3sec - average of 1073 MiB/s

Stap 3:

De pool bevat 2 blu ray rips met alle files, groot en klein dus.. Samen ~70 GB.

code:

[root@zfsguru1 /home/ssh]# zfs send -R pool1/share@2015-04-09 | dd bs=1M of=/dev/null
0+1614075 records in
67361+1 records out
70633495788 bytes transferred in 59.182030 secs (1193495658 bytes/sec)

code:

bytes 1193495658 
kilobytes 1165523.10351562 
megabytes 1138.20615577698 
gigabytes 1.11152944900095

Dan leest die pool vrij snel lijkt het, 1.1 GB/sec De hdd ledjes blijven branden tijdens de test

De andere server heeft een 20TB pool, en als ik daar een snapshot van maak duurt de test een beetje te lang denk ik, maar de performance van de hdd's is daar gelijk met de zfsguru benchmark tests (ronde de 1 GB/sec op alle pools)


De laatste stap:

client:
zfs send -R tank5/share@2015-04-09 | mbuffer -4 -s 128k -m 1G -O 192.168.3.151:5001

Server:

mbuffer -4 -s 128k -m 1G -I 5001 | zfs recv -vFd pool1

loopt spaak op de server kant omdat de pool1 daar bestaat en actief is.
Ik neem haast aan dat ik daar een nieuwe pool kan maken (poolx), maar dan heb ik geen ruimte om de data naar de pool1 te moven waar ik de shares op heb staan, en moet ik bovendien nog een move van data doen.

Kan ik de data met zfs receive in een bestaande pool/file systeem krijgen ?

update: door er de share achter te zetten (man page lezen en met google naar wat voorbeelden zoeken helpt)

code:

mbuffer -4 -s 128k -m 1G -I 5001 | zfs recv -vFd pool1/share

[ Voor 30% gewijzigd door jacovn op 11-04-2015 16:55 . Reden: Stap 4 issue opgelost ]

[FREAKJAM]

ZFS on Linux 0.6.4 is gister released.

New Functionality

Compatible with kernels up to Linux 4.0.
New feature flags (additional details below):
spacemap_histogram
extensible_dataset
bookmarks
enabled_txg
hole_birth
embedded_data
New asynchronous I/O (AIO) support.
New fallocate() FALLOC_FL_PUNCH_HOLE support.
New fragmentation metric in 'zpool list'.
New LZ4 compression of meta data.
New "redundant_metadata" property controls desired redundancy level.
New "overlay" property controls behavior for non-empty mount points.
New 'zpool list -v' shows individual disk capacity.
New 'zpool get -H' (scripted mode) support.
New 'zpool create -t' creates a pool with a temporary name.
New arc_summary.py script from FreeNAS.
New bash completion support.
New DTRACE_PROBES integrated with Linux tracepoints.
New compressed block histograms with zdb.
New verbatim pool imports with zdb.
New Feature Flags

spacemap_histogram

This features allows ZFS to maintain more information about how free space is organized within the pool. If this feature is enabled, ZFS will set this feature to active when a new space map object is created or an existing space map is upgraded to the new format.

extensible_dataset

This feature allows more flexible use of internal ZFS data structures, and exists for other features to depend on. This feature will be active when the first dependent feature uses it.

bookmarks

This feature enables use of the zfs bookmark subcommand. Bookmarks mark the point in time when a snapshot was created, they can be used as the incremental source for a zfs send command. All bookmarks in the pool can be listed by running zfs list -t bookmark -r poolname.

enabled_txg

Once this feature is enabled ZFS records the transaction group number in which new features are enabled. This has no user-visible impact, but other features may depend on this feature.

hole_birth

This feature improves performance of incremental sends ("zfs send -i") and receives for objects with many holes. The most common case of hole-filled objects is zvols.

embedded_data

This feature improves the performance and compression ratio of highly-compressible blocks. Blocks whose contents can compress to 112 bytes or smaller can take advantage of this feature.

Bug Fixes

Fixed I/O error on fs/vol delete corrupting space map.
Fixed corruption during spacemap reallocation.
Fixed corruption due to faulty logic when undirtying spill block.
Fixed stale bonus buffer in recycled dnode_t data corruption.
Fixed SA header size accounting.
Fixed O_APPEND flag for open(2).
Fixed deadlocks caused by direct reclaim by setting PF_FSTRANS.
Fixed deadlocks on suspended pools.
Fixed deadlock in zio pipeline caused by mutex_exit() race.
Fixed deadlock between 'zpool export' and 'zfs list'.
Fixed deadlock related to 'zfs rename'.
Fixed deadlock related to z_teardown_inactive_lock.
Fixed deadlock related to zfs_putpage().
Fixed deadlock for meta data intensive workloads.
Fixed panic when removing log device.
Fixed panic in metaslab init when space_map_open returned ENXIO.
Fixed panic due to dirtying inodes in a snapshot.
Fixed panic in dbufstat.py.
Fixed panic when performing ACL-to-mode translation on empty ACL.
Fixed SEEK_HOLE misreporting hole at end of file.
Fixed discrepancies in futimens() timestamps.
Fixed pool free space leak.
Fixed L2ARC compressed buffer leak.
Fixed 'zpool history -i' hang.
Fixed 'zpool import -t' it should not update the cache file.
Fixed multiple 'zfs send/recv' failure modes.
Fixed dracut to export ZFS root pool on shutdown.
Fixed restore_object now performed in a single transaction.
Fixed zvol symbolic link handling.
Fixed per-filesystem memory reclaim.
Fixed removal of SA in sa_modify_attrs().
Fixed readdir for .zfs/snapshot directory.
Fixed maximum zvol transfer size.
Fixed dmu_sync'ed holes should retain birth time.
Fixed ctor/dtor called on each alloc/free not once per slab.
Fixed ZED io-spare.sh script.
Fixed spurious timeouts when create large pools.
Improved 'zpool add' dry-run mode.
Improved 'zfs send -p' to only send properties for sent snapshots.
Improved 'zpool import' hostid behavior.
Improved 'zpool import -XF' behavior.
Improved 'zpool import' when multiple duplicate labels are found.
Improved 'zfs receive' performance by increasing pipe buffer size.
Improved 'zfs send' for small blocks by increasing prefetch.
Improved SPL kmem implementation.
Improved zvol_get_stats() performance.
Improved ashift auto-detect and management.
Improved documentation in man pages.
Improved handling of damaged block pointers.
Improved ZED logging
Rate limited debug backtraces to avoid impacting performance.
Assorted performance improvements.
Substantial changes to realign code base with illumos.
Over 200 additional bug fixes.

[Kortfragje]

iemand al een upgrade gedaan op Ubuntu?

[HyperBart]

Sinds mijn ZFS-testkonijn en acceptatiedomein @FireDrunk over gegaan is naar Fedora en daar vrolijk en vrij experimenteert ben ik heel wat terughoudender...

Oooooooooh @FireDrunk, gaan we nog eens samen upgraden?

Iemand hierover trouwens een idee?
Als ik nu een zpool status doe, blijft de shell hangen. Komt 99% zeker door een degraded of offline zpool'tje genaamd spiegeltje. Want als ik een zpool status van mijn main storage pool doe, geen probleem.

Pool heeft problemen gekregen na een reboot, een van de disken is defect gegaan, en uit voorzorg heb ik de overblijvende er ook uit gehaald (is een backup pool).

Met het gevolg nu dat zpool status de shell doet hangen/totaal geen output geef/bokt.

[ Voor 52% gewijzigd door HyperBart op 10-04-2015 16:28 ]

[Wiebeltje]

Kortfragje schreef op vrijdag 10 april 2015 @ 16:20:
iemand al een upgrade gedaan op Ubuntu?

Jup, niks geks gebeurd hier. Ik draai verder ook niks bijzonders (simpele mirror met 2 disks).

[FREAKJAM]

Ik heb geupgrade op CentOS 7 en ook dat ging zonder problemen (zpool upgrade ook trouwens).

[Bigs]

Goh wat jammer, wil je eindelijk eens een keer delegations gebruiken (een gewone user toestaan om in een bepaalde dataset snapshots aan te maken etc.), blijkt ZFS on Linux dat niet te ondersteunen (omdat Linux op bepaalde punten nogal verschilt van Solaris waardoor het niet makkelijk over te nemen is, kennelijk). Dat is wel jammer, vooral aangezien de opslagbak in kwestie enkele weken geleden nog FreeBSD draaide en daar kan het wel Kanttekeningetje dus voor wie twijfelt tussen Linux en FreeBSD.

[ Voor 6% gewijzigd door Bigs op 10-04-2015 17:23 ]

[HyperBart]

FREAKJAM schreef op vrijdag 10 april 2015 @ 13:46:
ZFS on Linux 0.6.4 is gister released.
[...]

Dit vond ik even interessant, dus wat gaan opzoeken:

https://forums.freenas.or...kmarks.22216/#post-131735

Bottomline is dus , dat je nu kan snapshotten, bookmarken, en snapshotjes wegsmijten, maar op de receiving kant nog altijd kan verdergaan.

Ik moet nog even zien hoe het in de praktijk zit, maar dat betekent wel endless sending and receiving van je hele mikmak naar backup pools zonder dat je "main" pool "vervuild" geraakt met een hele waslijst aan snapshots en de bijhorende data. De waslijst is er nu nog wel, maar geen snapshotjes meer...

[Anoniem: 15758]

Fixed I/O error on fs/vol delete corrupting space map.
Fixed corruption during spacemap reallocation.
Fixed corruption due to faulty logic when undirtying spill block.
Fixed stale bonus buffer in recycled dnode_t data corruption.

Vier corruptie-bugs; maar ZoL was toch al production-ready verklaard?

Zo ging het ook op BSD. Pas na een tijd kun je van een proven production ready systeem spreken. Dit zal ook zeker niet de laatste corruptie-bug zijn die wordt geplet. Dus bedenk welke lijken er nog in de kast zitten, die veelal alleen tevoorschijn komen als je het verkeerde kastje opent. Obscure bugs, dat is het grote nadeel van ZFS door zijn complexiteit.

[Borromini]

Gaat BTRFS dan niet last hebben van hetzelfde probleem?

[tvwes]

@Borromini, BTRFS heeft last van nog meer problemen. Er was ooit een vuistregel dat het minstens 10 jaar duurde voordat een filesystem stabiel was. Maar die regel gold voor traditionele filesystems, niet voor complexe als ZFS en BTRFS met ingebouwde volume manager.

@Cipher, ZoL is nog lang niet productie klaar. Mijn inschatting is dat het nog een jaar of misschien twee kan duren voordat het in de buurt van "stabiel" gaat komen. Jij ziet het inderdaad juist, het is de complexiteit van ZFS dat zorgt voor een aantal grote hindernissen. Waaronder: slechts heel weinig mensen zijn capabel om hier aan te kunnen ontwikkelen, allerlei edge cases / obscure bugs zijn heel moeilijk te vinden en reproduceren (zelfs met een volledige coredump), er is heel weinig publieke kennis /documentatie over ZFS dat maakt instappen ook weer lastiger (maar voor een echt talent geen enkel probleem). In alle ZFS implementaties zitten nog de nodige obscure bugs. Het is alleen heel lastig deze op te sporen.

Plaats het wel in perspectief, ZFS timmert al ruim 10 jaar aan de weg. En was jaren geleden al prima bruikbaar. Ik gebruik bijvoorbeeld al sinds december 2008 een zpool v14 icm met zfs v3 zonder enig probleem, het is een thuisserver. Ik weet dat er allerlei issues in de code zijn, maar ik zal nooit meemaken op dat systeem dat ik 50000 zfs filesystems zal aanmaken en wil weg gooien of booten of zoveel snapshots probeer weg te gooien of meer van dit soort extreme gevallen. Voor mijn gebruik is het prima, NFS, SMB en iSCSI.

Mijn advies: Voor een goede NAS maar ook algemene server icm ZFS gebruik geen Linux op dit moment als je geen gezeur wilt.
(ZoL) Linux is niet slecht maar de focus ligt meer op the latest and greatest ipv kwaliteit.
De meest ervaren ontwikelaars zitten niet bij ZoL. Overigens werken aan ZOL ook een aantal zeer capabele mensen maar niet met zoveel ZFS ervaring als sommigen bij Illumos en FreeBSD.

Bovenstaand advies is een advies niet de absolute waarheid. Net als vorige week de ECC discussie is het ook hier weer een risico inschatting en belangenafweging. Het is een feit dat ZoL nog niet af is en dat er nog bugs in zitten. Ook is het een feit dat meer bugs in dan in FreeBSD en Illumos. Als iemand perse Linux moet gebruiken en zijn data niet kwijt mag raken, gebruik dan misschien niet ZoL. Mag je je data niet kwijt raken en wil je weinig gezeur? Gebruik ZFS dan niet op Linux. En weer zullen er hier op tweakers allemaal leden zijn die roepen "ja maar mijn tv kaartje doet het alleen onder Linux" "PPM 3 (PotentPr0nManager) doet het alleen onder Linux", prima. Iedereen moet en mag die afweging voorzich zelf maken. Als jij graag ZoL wil draaien icm je TV kaartje, ga je gang. Bovenstaand advies voor diegene die een stabiel systeem willen met ZFS.

[Kristofferson]

Anoniem: 15758 schreef op vrijdag 10 april 2015 @ 22:37:
[...]

Vier corruptie-bugs; maar ZoL was toch al production-ready verklaard?

3 van de 4 genoemde bugs zaten ook in Illumos, dus dat ligt niet direct aan ZoL:

* Illumos 4390 - I/O errors can corrupt space map when deleting fs/vol
* Illumos 5117 - spacemap reallocation can cause corruption
* Illumos 5630 - stale bonus buffer in recycled dnode_t leads to data corruption

[jacovn]

Nou zfs send en receive is toch wel een stuk sneller dan nfs en MC....

code:

receiving full stream of tank5/share@2015-04-09 into pool1/share/share@2015-04-09
in @ 1023 MiB/s, out @ 1027 MiB/s,  614 GiB total, buffer   0% full

Dit is de piek, het schommelt tussen 750-1120 MiB/sec.

En dit is standard zfsguru met MTU van 1500..

De machine die het ontvangt heeft het er wel druk mee: Current processor usage is: 522 %
Die het stuurt heeft het wat rustiger: Current processor usage is: 152 %

Uiteindelijk resultaat:
18.5 TiB total, buffer 0% fullreceived 18.5TB stream in 23456 seconds (829MB/sec)

Heel mooi resultaat voor out of the box config lijkt me. (het is MiB dus tegen de 870 MB/sec )

[ Voor 43% gewijzigd door jacovn op 12-04-2015 15:41 ]

[Bigs]

Productie ready is wanneer het out-of-the-box direct werkt. ZoL is wel een heel eind, maar is er echt nog niet. Bijvoorbeeld het feit dat je zelf een ARC limiet in moet stellen omdat ZFS kennelijk niet snel genoeg geheugen teruggeeft aan de kernel vind ik wel een issue. Vooral omdat de documentatie daar ook nergens over rept. Voordat ik dat deed zat de machine regelmatig minutenlang vast met 100% CPU gebruik tijdens simpele taken. Onder FreeBSD en Illumos regelt zich zit allemaal zelf zodat je geheugen optimaal ingezet wordt.

[HyperBart]

Nou ja dat vind ik niet iets mis zijn met ZFS en Linux an sich, iets mis met ZFS en Linux vind ik wanneer het boeltje helemaal gaat hangen of ze elkaar in de weg gaan zitten. Dat het geheugen management anders werkt, ja ok.

Nu doet iedereen net alsof ZFS op Linux kak is en dat je het eigenlijk NIET moet gebruiken. Men moet hier ook geen FUD gaan zaaien denk ik dan.

Als ik dit las als leek dan had ik zoiets van nou ja neen ZFS en Linux dan maar niet. Terwijl we er voor wel een pak gematigder over waren...

En als ik dan lees dat 3 van die 4 bugs ook in illumos zaten, dan heb ik helemaal zoiets van

tvwes schreef op zaterdag 11 april 2015 @ 11:01:
@Cipher, ZoL is nog lang niet productie klaar. Mijn inschatting is dat het nog een jaar of misschien twee kan duren voordat het in de buurt van "stabiel" gaat komen. Jij ziet het inderdaad juist, het is de complexiteit van ZFS dat zorgt voor een aantal grote hindernissen. Waaronder: slechts heel weinig mensen zijn capabel om hier aan te kunnen ontwikkelen, allerlei edge cases / obscure bugs zijn heel moeilijk te vinden en reproduceren (zelfs met een volledige coredump), er is heel weinig publieke kennis /documentatie over ZFS dat maakt instappen ook weer lastiger (maar voor een echt talent geen enkel probleem). In alle ZFS implementaties zitten nog de nodige obscure bugs. Het is alleen heel lastig deze op te sporen.

Plaats het wel in perspectief, ZFS timmert al ruim 10 jaar aan de weg. En was jaren geleden al prima bruikbaar. Ik gebruik bijvoorbeeld al sinds december 2008 een zpool v14 icm met zfs v3 zonder enig probleem, het is een thuisserver. Ik weet dat er allerlei issues in de code zijn, maar ik zal nooit meemaken op dat systeem dat ik 50000 zfs filesystems zal aanmaken en wil weg gooien of booten of zoveel snapshots probeer weg te gooien of meer van dit soort extreme gevallen. Voor mijn gebruik is het prima, NFS, SMB en iSCSI.

Maar wat zijn die issues zijn waarvan je weet dat ze in de code zitten?

Mijn advies: Voor een goede NAS maar ook algemene server icm ZFS gebruik geen Linux op dit moment als je geen gezeur wilt.
(ZoL) Linux is niet slecht maar de focus ligt meer op the latest and greatest ipv kwaliteit.

Mijn advies gaat daar lijnrecht tegenin, ik moet hier onmiddellijk mijn meerdere erkennen in het Linux wereldje, en het zal ook een stukje "ignorance is bliss" zijn, maar ik ben het absoluut niet eens met het feit dat je voor een goede NAS met ZFS geen Linux mag gebruiken. Hell, de shit die ik tegenkwam met ZFSguru om dingen werkend te krijgen en vage bugs vond ik nog veel erger. Waarom? Waarschijnlijk omdat ze visible in de GUI waren. ZFS in de backend buggy lijkt me idd nog erger, maar die "zie" je niet. Maar serieus, ik heb me vaak ge-ergerd aan vage manieren om stukjes software op ZFSguru werkend te krijgen.

En het zal me even worst wezen dat ZFS af en toe eens een corruptie tegenkomt, want dan wordt het toch gerepareerd(?)

Zeker als je spreekt over "algemene server" dan heb ik zoiets van, blijf alsjeblief helemaal weg bij FreeBSD...

De meest ervaren ontwikelaars zitten niet bij ZoL. Overigens werken aan ZOL ook een aantal zeer capabele mensen maar niet met zoveel ZFS ervaring als sommigen bij Illumos en FreeBSD.

Bovenstaand advies is een advies niet de absolute waarheid. Net als vorige week de ECC discussie is het ook hier weer een risico inschatting en belangenafweging. Het is een feit dat ZoL nog niet af is en dat er nog bugs in zitten. Ook is het een feit dat meer bugs in dan in FreeBSD en Illumos. Als iemand perse Linux moet gebruiken en zijn data niet kwijt mag raken, gebruik dan misschien niet ZoL. Mag je je data niet kwijt raken en wil je weinig gezeur? Gebruik ZFS dan niet op Linux.

Welk gezeur? Dat ik eens een time outje heb moeten instellen voor dat ZFS naar mijn disks mag zoeken? Of dat ik wat meer met partities moet klooien?

Het is nu eenmaal servers en software, dus het is altijd gezeur.

En weer zullen er hier op tweakers allemaal leden zijn die roepen "ja maar mijn tv kaartje doet het alleen onder Linux" "PPM 3 (PotentPr0nManager) doet het alleen onder Linux", prima. Iedereen moet en mag die afweging voorzich zelf maken. Als jij graag ZoL wil draaien icm je TV kaartje, ga je gang. Bovenstaand advies voor diegene die een stabiel systeem willen met ZFS.

[ Voor 82% gewijzigd door HyperBart op 11-04-2015 16:46 ]

[Kek]

Heren, een vraag, ik heb momenteel een ZFS pool van 12TB, (5x3tb in raidz1), nou heb ik nog geen SLOG en dacht dit toe te voegen door een intel 320 ssd'tje toe te voegen van 40 GB.

Wat zijn jullie ideeen hierover, is dit een goede keus of kan ik beter iets anders zoeken voor wat extra performance.

er zit 16gb ram in de bak en geen l2arc, de de pool is misschien ook maar voor 1/3e gevult..

[Anoniem: 15758]

Bigs schreef op zaterdag 11 april 2015 @ 14:43:
Productie ready is wanneer het out-of-the-box direct werkt.

Oh? Dan was ZFS al production-ready toen het in voor het eerst in een OS kwam. Dan werkt het out of the box, toch? Dus FreeBSD 7.0 of nog eerder bij Solaris. Maar om dergelijke alpha-quality implementaties nu production-ready te noemen, is volgens mij absoluut onjuist. Production-ready betekent volgens mij dat iets volwassen, stabiel en bruikbaar genoeg is om het voor het serieuze werk ('productie') te gebruiken.

HyperBart schreef op zaterdag 11 april 2015 @ 16:28:
Nou ja dat vind ik niet iets mis zijn met ZFS en Linux an sich, iets mis met ZFS en Linux vind ik wanneer het boeltje helemaal gaat hangen of ze elkaar in de weg gaan zitten. Dat het geheugen management anders werkt, ja ok.

Nu doet iedereen net alsof ZFS op Linux kak is en dat je het eigenlijk NIET moet gebruiken. Men moet hier ook geen FUD gaan zaaien denk ik dan.

Nou, een gezonde dosis scepsis als het om iets als filesystems gaat, is toch best gezond. Dat heb ik al in het prille begin gezegd, toen ik ZFS op FreeBSD -CURRENT probeerde met patches, waarbij het dus nog niet in -CURRENT zat. Toen was het makkelijk om je pool corrupt te maken; een aantal van die bugs was ook bekend bij pawel (pjd@) - de BSD developer die ZFS naar FreeBSD heeft geport. Je kunt dan goed zien hoe de failure modes werken bij ZFS. Als het schade is die ZFS kan herstellen, zie je checksum errors. Is het schade aan een file die niet hersteld kan worden, dan zie je de filenaam. Máár - en nu komt het - als er iets mis gaat met de metadata zelf, waarbij er een inconsistentie ontstaat die ZFS niet verwacht, dan gaat de hele pool op zijn bek. En dan zie je doodleuk 'corrupted data' achter je pool staan en is hij UNAVAIL (unavailable). Je kunt dan helemaal niet meer bij de data. Theoretisch mogelijk om data te recoveren, maar of je dat gaat lukken met zdb (ZFS debugger) is maar zeer de vraag.

Als jij zegt:

En het zal me even worst wezen dat ZFS af en toe eens een corruptie tegenkomt, want dan wordt het toch gerepareerd(?)

Dan denk ik dat je het risico op bugs in ZFS nog niet voldoende inschat.

Natuurlijk heb je zéér obscure bugs die alleen voordoen als je tijdens het rebuilden een snapshot maakt terwijl je een ZFS receive aan het doen bent - ik noem maar even iets specifieks - en dat dat die ene bug triggert. En dan nog hoeft een dergelijke bug niet het einde van je pool te betekenen. Maar die kans is zeker aanwezig. Niet naief over zijn, maar gewoon incalculeren.

Betekent dit dat ZFS on Linux slecht is en je dat moet mijden als de pest? Ik denk daar iets genuanceerder over. Maar ik raad mensen wel een BSD implementatie aan, dat is toch gewoon het beste. Als iemand specifiek wensen heeft voor Linux dan ligt het voor de hand om ZoL serieus te overwegen.

Maar o.a. door de licenties zal Btrfs op den duur toch de overhand krijgen. Het vervelende is wel dat het Linux-only zal blijven, door de GPLv3 licentie. Voordeel van ZFS blijft dat het multi-platform is en steeds meer reputatie krijgt van stabiel en volwassen 3e generatie bestandssysteem.

[HyperBart]

Anoniem: 15758 schreef op zaterdag 11 april 2015 @ 19:30:

Nou, een gezonde dosis scepsis als het om iets als filesystems gaat, is toch best gezond. Dat heb ik al in het prille begin gezegd, toen ik ZFS op FreeBSD -CURRENT probeerde met patches, waarbij het dus nog niet in -CURRENT zat. Toen was het makkelijk om je pool corrupt te maken; een aantal van die bugs was ook bekend bij pawel (pjd@) - de BSD developer die ZFS naar FreeBSD heeft geport. Je kunt dan goed zien hoe de failure modes werken bij ZFS. Als het schade is die ZFS kan herstellen, zie je checksum errors. Is het schade aan een file die niet hersteld kan worden, dan zie je de filenaam. Máár - en nu komt het - als er iets mis gaat met de metadata zelf, waarbij er een inconsistentie ontstaat die ZFS niet verwacht, dan gaat de hele pool op zijn bek. En dan zie je doodleuk 'corrupted data' achter je pool staan en is hij UNAVAIL (unavailable). Je kunt dan helemaal niet meer bij de data. Theoretisch mogelijk om data te recoveren, maar of je dat gaat lukken met zdb (ZFS debugger) is maar zeer de vraag.

Gadver CiPHER, als je dat van die corrupted data begint te vertellen dan gaan mijn haren recht staan .

Uiteraard ben ik wel wat bedachtzaam als het over mijn data gaat, maar ik heb altijd maar in mijn achterhoofd gehouden: zo rot als het met traditionele RAID is en was, zo kan het nooit meer zijn met ZFS.

Ik denk dat het voor onze use cases allemaal niet zo een vaart loopt, namelijk een NAS bouwen, liefst zo groot mogelijk, en wat bestanden serveren via SMB en het boeltje veilig stellen met snapshots... Maar je hebt wel een punt, maar ik vind ook dat we het niet moeten dramatiseren, volg je me?

Als jij zegt:

[...]

Dan denk ik dat je het risico op bugs in ZFS nog niet voldoende inschat.

Ok, dan had ik iets te veel vertrouwen in ZFS' reparatie mechanismes, ook al komt het een bug tegen. Point taken...

Of wij die bugs ooit tegenkomen? Ik denk toch dat we mogen zeggen dat de kern functionaliteit van ZFS, files serveren aan een OS, rebuilden bij defecten en scrubben 100% goed werkt?

Natuurlijk heb je zéér obscure bugs die alleen voordoen als je tijdens het rebuilden een snapshot maakt terwijl je een ZFS receive aan het doen bent - ik noem maar even iets specifieks - en dat dat die ene bug triggert. En dan nog hoeft een dergelijke bug niet het einde van je pool te betekenen. Maar die kans is zeker aanwezig. Niet naief over zijn, maar gewoon incalculeren.

Betekent dit dat ZFS on Linux slecht is en je dat moet mijden als de pest? Ik denk daar iets genuanceerder over. Maar ik raad mensen wel een BSD implementatie aan, dat is toch gewoon het beste. Als iemand specifiek wensen heeft voor Linux dan ligt het voor de hand om ZoL serieus te overwegen.

Tja, je kan dat ook weer wat meer doortrekken en zeggen dat ze het best bij het oer-OS van ZFS gaan, namelijk Solaris... Maar ik snap je punt wel.

Maar o.a. door de licenties zal Btrfs op den duur toch de overhand krijgen. Het vervelende is wel dat het Linux-only zal blijven, door de GPLv3 licentie. Voordeel van ZFS blijft dat het multi-platform is en steeds meer reputatie krijgt van stabiel en volwassen 3e generatie bestandssysteem.

[ Voor 5% gewijzigd door HyperBart op 11-04-2015 19:59 ]

[Anoniem: 15758]

HyperBart schreef op zaterdag 11 april 2015 @ 19:57:
Gadver CiPHER, als je dat van die corrupted data begint te vertellen dan gaan mijn haren recht staan .

Heb je ook alle reden toe, want dat is de hel voor elke ZFS pool.

ZFS is heel goed ontworpen voor een aantal dingen. Maar omdat ZFS véél complexer is dan traditionele filesystems (FAT,NTFS,Ext2/3/4) is de kans op bugs ook veel groter. Hoe simpeler de implementatie, des te makkelijker is het om bugs eruit te krijgen. Maar een complexe machine - dat overziet eigenlijk geen enkel mens. Er zijn zoveel combinaties mogelijk van factoren. Dat is het grote nadeel. Daarom is de UNIX filosofie ook dat iets modulair moet zijn ontworpen voor één functie en die functie heel goed uitvoeren; en in zijn algemeenheid is een computer ook in modules ontworpen zodat het voor het ene 'domein' niet nodig is om iets over het andere domein te weten. Als je met netwerk packets bezig bent, heb je niets te maken met welke CPU, bijvoorbeeld. Alles is gecompartimentaliseerd (hoe spel je dat? ) in modules zodat de complexiteit behapbaar blijft voor de mens. Maar dan nog...

Het moeilijke zit hem erin dat het een hele binaire ervaring is: óf ZFS doet alles goed en fixt altijd je corruptie, óf je krijgt een keer de genadeklap en je pool is corrupt. Dat zie je bij traditionele filesystems veel minder. Maar ik heb geleerd dat ZFS verwacht dat op bepaalde plekken bepaalde data staat en als dat niet overeenkomt met wat ZFS verwacht, dan heb je een ontoegankelijke pool. Goed voorbeeld zijn de statische device nodes waardoor ZFS de verkeerde disks op de verkeerde plek zette, nadat je de volgorde had veranderd. Wat kan door een BIOS upgrade of andere BIOS instellingen. Anyway, daardoor ging je pool op zijn bek in het verleden. Opnieuw importeren werkte wel. Het was dus niet permanent corrupt.

Want dat is ook een risico: dat gebruikers al snel denken deze pool is hopeloos kapot, ik doe hem weg. Formatteren die hap! En dat is jammer als er toch mogelijkheden zijn om het weer aan de praat te krijgen.

Let wel, ik praat nu over de begindagen van ZFS op FreeBSD, waarbij er tijdens de boot nog een 2-regel waarschuwing te lezen viel over dat ZFS nog een experimentele feature was op FreeBSD. Pas bij versie 14 volgens mij is het volgens de developer stabiel verklaard. Zelf heb ik geen issues meer kunnen ontdekken vanaf versie 28. FreeBSD is van 6->13->14->15->28->5000 gegaan.

De risico's nu voor ZFS-on-Linux is denk ik vooral stabiliteit; crashen, hangen, dat soort dingen. Permanente corruptie is denk ik hogere kans dan op BSD, maar nog steeds erg laag. Zeker als thuisgebruiker, waarbij je over het algemeen geen exotische features gebruikt. Maar... ook thuisgebruikers doen soms dingen die je zo specifiek zijn dat je een minderheid bent en dan is het risico op bugs het grootst. Zolang je op het grote pad blijft dat vele anderen ook dagelijks bewandelen, is de kans op bugs het kleinst.

Als iemand graag Linux wilt en ZFS-on-Linux overweegt, zou ik dat zeker aanraden als het belangrijk voor diegene is dat het een Linux-platform is en geen BSD platform. Maar dan zou ik wel de vraag stellen: stel de hele pool is weg, heb je dan echt belangrijke dingen verloren? Die vraag dien je natuurlijk bij elke situatie stellen, maar wordt denk ik des te meer relevant als je iets als ZoL gebruikt in dit tijdperk. Ik denk dat vanaf nu en in een aantal jaren ZoL steeds beter wordt - het loopt gewoon een aantal jaren achter op BSD grof gezegd. Ik zou me daardoor meer comfortabel voelen om ZoL over een aantal jaar aan te bevelen. Maar tegen die tijd wordt Btrfs waarschijnlijk ook al interessant genoeg om te overwegen.

[tvwes]

@kek

Heren, een vraag, ik heb momenteel een ZFS pool van 12TB, (5x3tb in raidz1), nou heb ik nog geen SLOG en dacht dit toe te voegen door een intel 320 ssd'tje toe te voegen van 40 GB.

Wat zijn jullie ideeen hierover, is dit een goede keus of kan ik beter iets anders zoeken voor wat extra performance.

De vraag zou moeten luiden heb ik sync writes? Zo ja, levert het toevoegen van die intel 320 voldoende op om de kosten van het verlies van een (sata) poort te rechtvaardigen?

Om de eerste vraag te beantwoorden zou ik zilstat even downloaden en draaien. Zie je daar in de output dat je sync writes hebt, dan zal een ssd bijna altijd helpen als je nu alleen maar harddisks hebt.

Sync writes heb je oa als in ESXi een NFS datastore hebt. Er zijn een andere gevallen met sync writes, eigenlijk alles met transacties, maar niks in het consumenten segment.

Als je geen ESXi NFS datastore vanaf ZFS hebt verwacht ik niet de je veel aan een SLOG gaat hebben. Maar meten is weten.

Je kan de SSD bijv ook als L2ARC inzetten, maar ook daarvoor geld eerst meten dan beslissen.

Je kan en de SLOG en de L2ARC later weer verwijderen van je zpool. Maar als je een verkeerde opdracht geeft kan je in de problemen komen.

[Kek]

tvwes schreef op zaterdag 11 april 2015 @ 23:15:
@kek

[...]

De vraag zou moeten luiden heb ik sync writes? Zo ja, levert het toevoegen van die intel 320 voldoende op om de kosten van het verlies van een (sata) poort te rechtvaardigen?

Om de eerste vraag te beantwoorden zou ik zilstat even downloaden en draaien. Zie je daar in de output dat je sync writes hebt, dan zal een ssd bijna altijd helpen als je nu alleen maar harddisks hebt.

Sync writes heb je oa als in ESXi een NFS datastore hebt. Er zijn een andere gevallen met sync writes, eigenlijk alles met transacties, maar niks in het consumenten segment.

Als je geen ESXi NFS datastore vanaf ZFS hebt verwacht ik niet de je veel aan een SLOG gaat hebben. Maar meten is weten.

Je kan de SSD bijv ook als L2ARC inzetten, maar ook daarvoor geld eerst meten dan beslissen.

Je kan en de SLOG en de L2ARC later weer verwijderen van je zpool. Maar als je een verkeerde opdracht geeft kan je in de problemen komen.

De boel draait nu freenas, en ben van plan om dat in esxi te gaan draaien, maar dan wel de m1115 gelijk door te sturen naar de freenas vm, dus heel veel sync write zal het niet zijn.

Wat ik nu vooral merk is dat de reactie snelheid van de pool niet zo hoog is, ik hoopte dat iets te versnellen met de SLOG.

Qua sata poorten zit ik wel goed, het is een asrock b85-po3m bordje met dus een m1115, iets van 16 poorten oid


goed om te weten dat de slog ook wel los gekoppeld kan worden, kan ik wat dingen testen en uitproberen.

[tvwes]

Mensen als we de toon een beetje luchtig kunnen houden hier en niet ieder bericht als een aanval op zijn persoonlijke mening kan opvatten dan blijft het een stuk leuker. Een scherpe op feiten gebaseerde discussie prima maar ga niet een tirade afsteken over zaken die helemaal niet gezegd zijn.

Ik krijg sterk het gevoel dat er hier met twee maten gegemeten wordt, aan de ene kant wordt er geklaagd als iets niet werkt of een feature ontbreekt, en aan de andere kant wordt er geklaagd als je opmerkt dat een bepaalde keuze suboptimaal is als het gaat om betrouwbaarheid.

Nu doet iedereen net alsof ZFS op Linux kak is en dat je het eigenlijk NIET moet gebruiken. Men moet hier ook geen FUD gaan zaaien denk ik dan.

Niemand heeft geschreven dat ZoL kak is. Ik heb geschreven dat ZoL achterloopt tov Illumos en FreeBSD, niks FUD gewoon waar. Ook schreef ik dat de meest ervaren ontwikkelaars bij Illumos en FreeBSD zitten, niks FUD gewoon waar.

Hell, de shit die ik tegenkwam met ZFSguru om dingen werkend te krijgen en vage bugs vond ik nog veel erger. Waarom? Waarschijnlijk omdat ze visible in de GUI waren. ZFS in de backend buggy lijkt me idd nog erger, maar die "zie" je niet. Maar serieus, ik heb me vaak ge-ergerd aan vage manieren om stukjes software op ZFSguru werkend te krijgen.

Ik heb volkomen geen boodschap en interesse in iedere GUI en/schil mbt tot ZFS. Het onderwerp hier is ZFS en niet een GUI. Dat die GUI's en/schillen falen is niet het probleem van ZFS. Dus hou de discussie wel zuiver aub.

Misschien nog even een voorbeeld geven van iets wat stabiel is: FAT en UFS en Ext3 zijn stabiel, na vele jaren. Maar even een snelle search net Ext3 bugs liet zien dat er zelfs anno 2015 nog bugs rondom Ext3 zijn. Is het daarmee onbruikbaar? Nee. Alleen de vergelijking met ZFS gaat mank. Alle ZFS implementaties hebben nog issues. Ik beweerde alleen dat de ZoL implementatie meer issues heeft dan andere ZFS implementaties. En omdat er prima alternatieven zijn het beter is om voor een andere implementatie te kiezen als je minder risico wilt lopen. Niks FUD gewoon een op feiten gebaseerd advies. En direct erachter schreef ik dat een ieder natuurlijk vrij is om ZoL te gebruiken als hij daar redenen toe heeft. Het gebruik van ZoL in productie is een goede zaak, misschien rollen er weer wat issues uit.

Waarom verkocht SUN dan destijds zijn AmberRoad nas'en terwijl er bekende bugs in ZFS waren? Omdat het niet als broodje worst werd verkocht. Klanten die dit kochten kregen begeleiding en als de klant een use case had waarvan bekend was dat het problemen ging opleveren dan ging de deal soms niet door of werd de bug speciaal opgelost voor die klant. Klanten van enterprise storage worden niet aan hun lot overgelaten die worden maximaal begeleid. Daar betalen ze ook grof voor. De SOHO gebruiker krijgt geen begeleiding. Enkele best practice adviezen is het beste wat de SOHO gebruiker kan verwachten.

De risico's nu voor ZFS-on-Linux is denk ik vooral stabiliteit; crashen, hangen, dat soort dingen. Permanente corruptie is denk ik hogere kans dan op BSD, maar nog steeds erg laag. Zeker als thuisgebruiker, waarbij je over het algemeen geen exotische features gebruikt. Maar... ook thuisgebruikers doen soms dingen die je zo specifiek zijn dat je een minderheid bent en dan is het risico op bugs het grootst. Zolang je op het grote pad blijft dat vele anderen ook dagelijks bewandelen, is de kans op bugs het kleinst.

@Cipher, heeft het weer juist. Het blijft een risico inschatting. En als niet weet wat je aan het doen bent waarom dan van het gebaande pad afwijken? Alle significante commerciele ZFS NAS implementaties zijn Illumos of FreeBSD gebaseerd, niet ZoL. Dat moet ook wat zeggen. ZFS is op deze OS'es op dit moment beter. Natuurlijk zal het gat snel dichten tussen ZoL en de anderen maar dat zal nog wel een jaar duren.
De rest van @Cipher zijn betoog kan ik ook grotendeels onderschrijven.

Nogmaals mijn advies om ZoL niet in een productie omgeving in te zetten is geen ZoL bashing. Ik juich de ontwikkeling alleen maar toe en bewonder de ontwikkelaars voor hun ontwikkel snelheid. Maar ZoL heeft op dit moment een achterstand tov andere implementaties. En mensen die vele TB's aan ZoL toe vertrouwen moeten op dit moment een prijsje krijgen. Ik durf het namelijk niet.

[brederodekater]

Q schreef op zaterdag 16 augustus 2014 @ 23:47:

Controllers

Ik heb de drie IBM 1015 controllers niet geflashed naar IT firmware omdat alles al prima functioneert en ik vond het teveel gedoe. Misschien dat het booten iets langer duurt, maar zo zal het zijn. Het grootste risico is misschien dat de disks met deze firmware - ook al worden ze 1-op-1 doorgezet - toch uit de array worden gekickt bij het minste of geringste, ik weet het niet.

Deze quote komt uit het 20TB show-off topic, maar ik denk dat deze reactie beter op z'n plaats is binnen dit topic.

Ik sta op het punt om mijn systeem van een update te voorzien, dus ik was aan het rondbladeren om inspiratie op te doen. Ik kwam Q's systeem tegen met de opmerking hierboven omtrent het niet flashen naar IT firmware van de 1015 controllers.

Ik mag aannemen dat hier een weloverwogen beslissing is genomen, ook al waren misschien de eventuele risico's niet helemaal duidelijk en/of bekend. Wat is jullie mening hierover? Is het risico verwaarloosbaar wanneer de disks in JBOD aan het systeem worden door gegeven?

[tvwes]

Kek schreef op zondag 12 april 2015 @ 12:09:
[...]
De boel draait nu freenas, en ben van plan om dat in esxi te gaan draaien, maar dan wel de m1115 gelijk door te sturen naar de freenas vm, dus heel veel sync write zal het niet zijn.

Wat ik nu vooral merk is dat de reactie snelheid van de pool niet zo hoog is, ik hoopte dat iets te versnellen met de SLOG.

Nogmaals de SLOG gaat alleen helpen als de SYNC writes hebt. ZFS buffert (async) writes in een transactie van enkele seconden. Daarna worden alle writes als een grote stream weggeschreven. Valt de stroom uit ben je een paar seconden data kwijt. Bij sync writes wordt iedere write direct naar disk geschreven, dat zijn dus veel IOPS en kost dus veel tijd. Heb je nu een SLOG dan worden de sync writes nog steeds direct weggeschreven maar nu naar je SLOG en na een paar seconden wordt een stream naar je gewonen disken geschreven. De sync writes worden omgezet naar async writes. Maar zonder kans op gegevens verlies. Omdat jouw SLOG een snelle SSD is zullen de writes sneller worden afgehandeld dan naar je harddisken. Heb je geen sync writes dan helpt een SLOG niks.

Het maakt niet uit of je FreeNAS in ESXi draait of los. Het enige wat telt is of je sync writes hebt. Gebruik je ESXi NFS datastores dan heb je altijd sync writes.

Meer is er niet.

[Kek]

tvwes schreef op zondag 12 april 2015 @ 12:28:
[...]


Nogmaals de SLOG gaat alleen helpen als de SYNC writes hebt. ZFS buffert (async) writes in een transactie van enkele seconden. Daarna worden alle writes als een grote stream weggeschreven. Valt de stroom uit ben je een paar seconden data kwijt. Bij sync writes wordt iedere write direct naar disk geschreven, dat zijn dus veel IOPS en kost dus veel tijd. Heb je nu een SLOG dan worden de sync writes nog steeds direct weggeschreven maar nu naar je SLOG en na een paar seconden wordt een stream naar je gewonen disken geschreven. De sync writes worden omgezet naar async writes. Maar zonder kans op gegevens verlies. Omdat jouw SLOG een snelle SSD is zullen de writes sneller worden afgehandeld dan naar je harddisken. Heb je geen sync writes dan helpt een SLOG niks.

Het maakt niet uit of je FreeNAS in ESXi draait of los. Het enige wat telt is of je sync writes hebt. Gebruik je ESXi NFS datastores dan heb je altijd sync writes.

Meer is er niet.

ik zal zilstat eens draaien en kijken hoeveel sync writes ik heb,het is een zeer gemêleerde storage, dus er staat vanalles op

[tvwes]

brederodekater schreef op zondag 12 april 2015 @ 12:26:
[...]


Deze quote komt uit het 20TB show-off topic, maar ik denk dat deze reactie beter op z'n plaats is binnen dit topic.

Ik sta op het punt om mijn systeem van een update te voorzien, dus ik was aan het rondbladeren om inspiratie op te doen. Ik kwam Q's systeem tegen met de opmerking hierboven omtrent het niet flashen naar IT firmware van de 1015 controllers.

Ik mag aannemen dat hier een weloverwogen beslissing is genomen, ook al waren misschien de eventuele risico's niet helemaal duidelijk en/of bekend. Wat is jullie mening hierover? Is het risico verwaarloosbaar wanneer de disks in JBOD aan het systeem worden door gegeven?

Ik ben benieuwd naar Q zijn overweging om het niet te doen. Ik weet eigenlijk niet beter dan het altijd terug te zetten naar IT mode.
Wat je ook doet gebruik niet firmware P20 maar P19 (ik weet niet zeker of dit ook geld voor IR mode maar zeker voor IT mode)

[Kek]

tvwes schreef op zondag 12 april 2015 @ 12:35:
[...]


Ik ben benieuwd naar Q zijn overweging om het niet te doen. Ik weet eigenlijk niet beter dan het altijd terug te zetten naar IT mode.
Wat je ook doet gebruik niet firmware P20 maar P19 (ik weet niet zeker of dit ook geld voor IR mode maar zeker voor IT mode)

wat is er mis met firmware p20 in IT mode? dat heb ik namelijk recent nog op mijn 1115m gezet...

edit:

al gevonden,

"P20 causes excessively slow reads in any sort of multiple disk access situation like raid or zfs.
In my case a 4-way sata3 raid0 was giving 1.4GB/s write, and only 30MB/s read.

The previous P19 version doesn’t exhibit this problem."

hmm dan toch maar even naar p19 overzetten...

[ Voor 24% gewijzigd door Kek op 12-04-2015 12:39 ]

[Q]

tvwes schreef op zondag 12 april 2015 @ 12:35:
[...]


Ik ben benieuwd naar Q zijn overweging om het niet te doen. Ik weet eigenlijk niet beter dan het altijd terug te zetten naar IT mode.

Ik waagde een poging maar het lukte niet met mijn moederbord iets met UEFI en toen werd het moeilijk en vond ik het wel best.

[tvwes]

Maar, mon capitaine! Nauwelijks te bevatten dat een firmware upgrade jouw dwars zat. Maar gelukkig was het geen technische reden om het IR mode te laten staan. Ik zal eens kijken in mijn archief naar een uitleg waarom je het beter terug kan zetten in IT mode. Er was in ieder geval geen enkele reden om het wel te laten staan.

[tvwes]

Cliffhanger

Wat begon rond

jacovn schreef op maandag 30 maart 2015 @ 14:38:
Ik heb een vraag..

en

jacovn schreef op woensdag 01 april 2015 @ 17:22:
Ik kan prima data copieren, alleen zie ik maar 140-150 Mbyte/sec gaan.

leverde een performance trouble shooting guide op van mij voor @jacovn

tvwes schreef op zondag 05 april 2015 @ 17:10:

De afgelopen dagen hebben @jacovn en ik zijn probleem opgelost en echt wirespeed overdracht snelheden behaald.

Samenvatting volgt binnenkort...

[Anoniem: 15758]

Ben ik zeker ook benieuwd in! Is het punt de TCP receive window, die vaak icm Windows platforms erg laag is (8 tot 16KiB) of zijn het andere zaken die roet in het eten gooien. Nu moet wel gezegd worden dat gigabit en 10 gigabit ethernet interfaces zijn met een groot 'bandwidth-delay-product'. Dus tuning en dergelijke is daar belangrijker bij dan bij andere interfaces waarbij de snelheid meer in verhouding ligt met de latency.

[tvwes]

@Cipher, je zal positief verbaasd zijn... Ik zal kijken of we Windows nog mee kunnen nemen in het verhaal. Misschien dat we dat in een tweede verhaal moeten stoppen. We zijn nog bezig enkele testen af te ronden voor het oorspronkelijke verhaal.

[Anoniem: 15758]

Ok, ik wacht met spanning af.

[jacovn]

Je moet nog even wachten. Ik ben langzaam van begrip en heb niet altijd genoeg tijd voor alles.
Maar.. Morgen werk ik weer thuis en dan kan ik alle tests doen met wat geluk

Alle tests zijn klaar

[ Voor 7% gewijzigd door jacovn op 13-04-2015 21:13 ]

[brederodekater]

Q schreef op zondag 12 april 2015 @ 19:04:
[...]


Ik waagde een poging maar het lukte niet met mijn moederbord iets met UEFI en toen werd het moeilijk en vond ik het wel best.

Hmm.. fingers crossed dan maar, want ik heb toevallig hetzelfde moederbord Mocht ik ook problemen tegenkomen en een oplossing vinden dan laat ik het je wel even weten.

[FireDrunk]

Aangezien de kampen heerlijk verdeeld zijn moet ik toch maar een duit in het zakje doen over ZFSonLinux.

Geen idee waar het stond, maar een belangrijk argument *voor* ZFSonLinux, is dat het een *native* implementatie is van ZFS.

ZFSonLinux heeft de *enige echte* ZFS implementatie zoals BSD die ook gewoon heeft.
De code is in de core gewoon gelijk, en corruptie bugs zouden dus (tenzij er hele vage dingen onderwater gebeuren met het wijzigen van IO commando's op laag niveau) niet voor moeten komen, *anders dan op BSD*.

Er zijn een aantal grote verschillen tussen Linux en BSD, namelijk:

*) Geheugen management
*) Cache management
*) IO Schedulers, (en de implementatie van IOnice bijvoorbeeld)
*) Licentie constraints

Al deze dingen zorgen er voor dat er wat meer (of minder) pas en meetwerk gedaan moet worden om ZFS (goed) aan het werk te krijgen.

In de basis: Puur ZFS dus, is het gewoon hetzelfde als op BSD en werkt het (volgens een aantal specialisten) goed genoeg om in productie te gebruiken.

Ga je speciale features gebruiken: (Bookmarks, resumable send en receive, POSIX ACL's, etc, etc). Dan ga je inderdaad wat meer risico nemen.

Hetzelfde geld voor BTRFS, veel mensen horen en lezen nog steeds corruptie verhalen van BTRFS. Dat klopt! Dat komt omdat mensen in de development omgeving de grenzen van het filesystem opzoeken! En terecht, want je moet goed testen en juist die edge cases opzoeken voordat je anderen aanraadt de feature te gebruiken.
(Het leuke is, dat in de basis van BTRFS, gewoon als single disk filesystem, er al heel lang geen corruptie verhalen meer zijn....)

Hetzelfde geldt voor ZFSonLinux: Ga je geavanceerde features gebruiken: Kies liever voor een platform waar ze al langer stabiel zijn, of gebruik ze liever niet als je data echt belangrijk is.

Gebruik je puur de basis (een pool... zelfs zonder snapshots, zonder ZVOL's, zonder enige ACL, zoals ik...) kan je perfect ZFSonLinux gebruiken. In de basis is het rete stabiel en doet het niet onder voor BSD (is mijn mening).

[ Voor 3% gewijzigd door FireDrunk op 13-04-2015 09:46 ]

[Phyt_]

Hmm, checkte zojuist even mijn SMART van de ZFSGURU bak, na de upgrade naar Vmware 6.
en zag dit:
197 Current_Pending_Sector 0x0012 100 100 000 - 56

http://i.imgur.com/E5SusdI.png
http://i.imgur.com/ToIk7pj.png

Moet gelijk de Disk in de prullenbak? of is deze nog te gebruiken met ZFS of als single disk voor minder belangrijke data?

[FireDrunk]

Ik zou een scrubje draaien en kijken of het hoger wordt (in de komende dagen/weken). Blijft het stabiel hoef je niet zo druk te maken, stijgt het, zou ik een RMA aanvragen.

In principe is een bad sector een valide reden voor RMA volgens mij, dus als je je kwaad maakt kan je hem terugsturen.

[Phyt_]

FireDrunk schreef op maandag 13 april 2015 @ 10:14:
Ik zou een scrubje draaien en kijken of het hoger wordt (in de komende dagen/weken). Blijft het stabiel hoef je niet zo druk te maken, stijgt het, zou ik een RMA aanvragen.

In principe is een bad sector een valide reden voor RMA volgens mij, dus als je je kwaad maakt kan je hem terugsturen.

Ok thanks ik ga het in de gaten houden en even een spare disk bestellen alvast.
de scrub heb ik iedere week draaien.

status: The pool is formatted using a legacy on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on software that does not support feature
flags.
scan: scrub repaired 0 in 3h7m with 0 errors on Sun Apr 12 04:08:08 2015
config:

NAME STATE READ WRITE CKSUM
pool_1 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gpt/da5 ONLINE 0 0 0
gpt/da1 ONLINE 0 0 0
gpt/da2 ONLINE 0 0 0
gpt/da3 ONLINE 0 0 0
gpt/da4 ONLINE 0 0 0

errors: No known data errors

[FireDrunk]

Goede kans dat de bad sectors dan in lege ruimte zitten. Totdat ZFS errors geeft zou ik me er niet zo druk over maken.

Ik heb heel lang pending sectors gehad, totdat ik een keer mijn hele pool volgeschreven heb.
Daarna werden ze 'gerepareerd' en gingen ze weg...

[Q]

tvwes schreef op zondag 12 april 2015 @ 19:13:
Maar, mon capitaine! Nauwelijks te bevatten dat een firmware upgrade jouw dwars zat. Maar gelukkig was het geen technische reden om het IR mode te laten staan. Ik zal eens kijken in mijn archief naar een uitleg waarom je het beter terug kan zetten in IT mode. Er was in ieder geval geen enkele reden om het wel te laten staan.

Yep, slap verhaal van mijn kant, het voornaamste risico wat ik loop is denk ik het gedrag bij read errors: wordt de disk van de controller geknikkerd of niet.

[tvwes]

FireDrunk schreef op maandag 13 april 2015 @ 09:45:
Aangezien de kampen heerlijk verdeeld zijn moet ik toch maar een duit in het zakje doen over ZFSonLinux.

Geen idee waar het stond, maar een belangrijk argument *voor* ZFSonLinux, is dat het een *native* implementatie is van ZFS.

ZFSonLinux heeft de *enige echte* ZFS implementatie zoals BSD die ook gewoon heeft.
De code is in de core gewoon gelijk, en corruptie bugs zouden dus (tenzij er hele vage dingen onderwater gebeuren met het wijzigen van IO commando's op laag niveau) niet voor moeten komen, *anders dan op BSD*.

Ik denk dat je bedoelt dat het een kernel module is en niet een FUSE implementatie. De code is helemaal niet zo gelijk. Kijk maar eens op github naar de enorme verschillen, ZoL heeft een volkomen andere structuur dan bijv Illumos. Ja, namen van data structuren en methods komen overeen. Maar er zijn echt grote verschillen, bijv de VFS layer is heel anders. Dat komt door de grote verschillen in tussen de kernels van Linux en Illumos. Illumos en FreeBSD lijken veel meer op elkaar.

Er zijn een aantal grote verschillen tussen Linux en BSD, namelijk:

*) Geheugen management
*) Cache management
*) IO Schedulers, (en de implementatie van IOnice bijvoorbeeld)
*) Licentie constraints

Al deze dingen zorgen er voor dat er wat meer (of minder) pas en meetwerk gedaan moet worden om ZFS (goed) aan het werk te krijgen.

Op de licentie constraints na, zijn de andere punten helemaal waar. Er moet voornamelijk nog meer paswerk gedaan worden. Je ziet het ondere terug in de problemen op het gebied van geheugen beheer. De agressieve consumentie van geheugen door de ARC is een non issue op Illumos, komt er geheugen druk dan zal de ARC het snel terug geven. Niet bij Linux.

In de basis: Puur ZFS dus, is het gewoon hetzelfde als op BSD en werkt het (volgens een aantal specialisten) goed genoeg om in productie te gebruiken.

ZFS is ZFS, als jouw implementatie mijn zpool kan lezen en schrijven en jij hebt het in VB geschreven ... hulde! Jouw implementatie is net zo goed als een andere. Vergelijk het met een compiler, iedere compiler die een taal kan compileren volgens de specificaties van die taal is een OK. Er is niet een pure compiler. Het enige wat je zou kunnen zeggen is dat de Illumos de oer en referentie implementatie is.

Aangaande jouw statement dat het voor simpel werk prima te gebruiken is. Helemaal mee eens. De reden dat ik eerder adviseerde om niet gebruik te maken van ZoL is dat mensen, en vooral hier, de neiging hebben om juist wel alle features te gebruiken. En juist dan kan het misgaan. Omdat bijna niemand de bugs volgt en kan ook bijna niemand een verantwoorde inschatting maken wat hij wel of niet niet kan doen met zijn ZFS implementatie. Als je die inschatting niet kan maken en er zijn alternatieven met een betere implementatie waarom dan niet daarvoor kiezen?

Ga je speciale features gebruiken: (Bookmarks, resumable send en receive, POSIX ACL's, etc, etc). Dan ga je inderdaad wat meer risico nemen.

Hetzelfde geld voor BTRFS, veel mensen horen en lezen nog steeds corruptie verhalen van BTRFS. Dat klopt! Dat komt omdat mensen in de development omgeving de grenzen van het filesystem opzoeken! En terecht, want je moet goed testen en juist die edge cases opzoeken voordat je anderen aanraadt de feature te gebruiken.
(Het leuke is, dat in de basis van BTRFS, gewoon als single disk filesystem, er al heel lang geen corruptie verhalen meer zijn....)

Hetzelfde geldt voor ZFSonLinux: Ga je geavanceerde features gebruiken: Kies liever voor een platform waar ze al langer stabiel zijn, of gebruik ze liever niet als je data echt belangrijk is.

Gebruik je puur de basis (een pool... zelfs zonder snapshots, zonder ZVOL's, zonder enige ACL, zoals ik...) kan je perfect ZFSonLinux gebruiken. In de basis is het rete stabiel en doet het niet onder voor BSD (is mijn mening).

Het is een inschatting. Die ieder zelf mag en moet maken. Alleen weet ik dat ik deze inschatting veel meer op feiten gebaseerd kan maken omdat ik de bugs en de (Illumos) code ken. Vandaar mijn advies om even na te denken voor je ergens je data aan toevertrouwd.

[HyperBart]

Q schreef op maandag 13 april 2015 @ 10:47:
[...]


Yep, slap verhaal van mijn kant, het voornaamste risico wat ik loop is denk ik het gedrag bij read errors: wordt de disk van de controller geknikkerd of niet.

Klopt, die "taak" leg je beter bij het OS. Vroeger dacht CiPHER dat ZFS zelf bepaalt of een disk geknikkerd moet worden of niet, vandaag de dag weten we al langer dat het OS dat gewoon doet...

[FireDrunk]

tvwes schreef op maandag 13 april 2015 @ 10:53:
[...]

Ik denk dat je bedoelt dat het een kernel module is en niet een FUSE implementatie. De code is helemaal niet zo gelijk. Kijk maar eens op github naar de enorme verschillen, ZoL heeft een volkomen andere structuur dan bijv Illumos. Ja, namen van data structuren en methods komen overeen. Maar er zijn echt grote verschillen, bijv de VFS layer is heel anders. Dat komt door de grote verschillen in tussen de kernels van Linux en Illumos. Illumos en FreeBSD lijken veel meer op elkaar.


[...]

Op de licentie constraints na, zijn de andere punten helemaal waar. Er moet voornamelijk nog meer paswerk gedaan worden. Je ziet het ondere terug in de problemen op het gebied van geheugen beheer. De agressieve consumentie van geheugen door de ARC is een non issue op Illumos, komt er geheugen druk dan zal de ARC het snel terug geven. Niet bij Linux.


[...]

ZFS is ZFS, als jouw implementatie mijn zpool kan lezen en schrijven en jij hebt het in VB geschreven ... hulde! Jouw implementatie is net zo goed als een andere. Vergelijk het met een compiler, iedere compiler die een taal kan compileren volgens de specificaties van die taal is een OK. Er is niet een pure compiler. Het enige wat je zou kunnen zeggen is dat de Illumos de oer en referentie implementatie is.

Aangaande jouw statement dat het voor simpel werk prima te gebruiken is. Helemaal mee eens. De reden dat ik eerder adviseerde om niet gebruik te maken van ZoL is dat mensen, en vooral hier, de neiging hebben om juist wel alle features te gebruiken. En juist dan kan het misgaan. Omdat bijna niemand de bugs volgt en kan ook bijna niemand een verantwoorde inschatting maken wat hij wel of niet niet kan doen met zijn ZFS implementatie. Als je die inschatting niet kan maken en er zijn alternatieven met een betere implementatie waarom dan niet daarvoor kiezen?


[...]

Het is een inschatting. Die ieder zelf mag en moet maken. Alleen weet ik dat ik deze inschatting veel meer op feiten gebaseerd kan maken omdat ik de bugs en de (Illumos) code ken. Vandaar mijn advies om even na te denken voor je ergens je data aan toevertrouwd.

Inderdaad, volgens mij zijn we het stiekem heel erg eens met elkaar
Ik heb wel wat code gezien van ZFSonLinux, maar baseer mijn mening vooral op wat mensen roepen in GitHub en daaromheen (wat mailing lists, en blogs).

Als jij zegt dat de code toch wat verschilt van Illumos (of OpenZFS eigenlijk als referentiekader) geloof ik je best.

Ik zou dat graag eens in procenten zien, dan hebben we 'harde cijfers'.

[Phyt_]

FireDrunk schreef op maandag 13 april 2015 @ 10:27:
Goede kans dat de bad sectors dan in lege ruimte zitten. Totdat ZFS errors geeft zou ik me er niet zo druk over maken.

Ik heb heel lang pending sectors gehad, totdat ik een keer mijn hele pool volgeschreven heb.
Daarna werden ze 'gerepareerd' en gingen ze weg...

Ok dan maak ik mij nog niet ongerust , ik houd de scrubs in de gaten.
bedankt.

[DRAFTER86]

Vraagje over de recente ZoL upgrade (welke op Ubuntu 14.04 overigens prima verliep, moest wel even rebooten om de pool te kunnen upgraden):
Elke nacht send ik een daily snapshot naar een andere Ubuntu ZoL machine, deze draait echter nog ZoL 6.3.
Hoe gaat dit dan met de nieuwe 6.4 feauture flags? Als ik nu een snapshot restore op mijn machine, heb ik dan weer 100% dezelfde pool? (gewoon uit interesse, de backup lijkt in ieder geval nog prima te werken)

Verder hier overigens zeer tevreden over ZoL, inmiddels draai ik syncthing bij wijze van Dropbox vervanging (opensource i.t.t. btsync), in combinatie met Owncloud als webinterface. Die laatste heeft dan ook weer toegang tot de .zfs/snapshots dir: een time-machine achtige functie die ik zelfs mijn vriendin uitgelegd krijg

[CurlyMo]

Ik heb redelijk wat geschreven in het verleden over feature flags met bijbehorende tests. Linkjes staan in de eerste post.

[tvwes]

De finale

Wat begon rond

jacovn schreef op maandag 30 maart 2015 @ 14:38:
Ik heb een vraag..

en

jacovn schreef op woensdag 01 april 2015 @ 17:22:
Ik kan prima data copieren, alleen zie ik maar 140-150 Mbyte/sec gaan.

leverde een performance trouble shooting guide op van mij voor @jacovn en het nodige test werk door ons samen.

De afgelopen dagen hebben @jacovn en ik zijn probleem opgelost en echt wirespeed overdracht snelheden behaald.

Er waren grof gezegd twee problemen:
-1- Er moest 18TB over gezet worden van de ene naar de andere server
-2- De overdracht snelheid van diverse mechanismen liet te wensen over
Bonus punten vielen te verdienen met
-iperf op wirespeed te krijgen

Als eerste wil ik @jacovn complimenteren met z'n goede hardware en doorzettings vermogen.

Even iets over de systemen:
De data moest van zfsguru3 naar zfsguru1
Beide systemen zijn via gigabit en 10gigabit ethernet met elkaar verbonden via een D-Link DGS-1510-28X. Gigabit en 10gigabit zijn gescheiden via vlan en elk in een verschillend ip subnet.

@jacovn haalde via NFS zo'n 140MB/sec voor een enkele stream en SMB 100MB/sec, zie metingen.

Dat was niet echt top. In reactie op @jacovn zn teleurstellende resultaten had ik deze troubleshooting guide voor hem opgesteld.

Als eerste heeft @jacovn alles op standaard gezet door een machine opnieuw te installeren en de settings voorzover nodig over te nemen op de andere. Daarnaast zijn alle powersafe features als frequency scaling en disk power management uitgezet.
Voor de rest was er helemaal niets getuned of getweaked, schoon out of the box.

Als eerste had ik voorgesteld om via iperf (2.0.5) te kijken wat de maximum tcp snelheid was. Dit bleek in eerste instantie zo'n 4500 mbit/sec te zijn. Nog lang niet 10gbit.
Maar ipv dat we eerst dat verder gingen uitzoeken was @jacovn lekker door gegaan met de volgende stappen in de guide.
Uiteindelijk moest de data over van de ene naar de andere zpool. Aangezien dit het grote ZFS topic is gaan we dat niet doen via, NFS, rsync, scp of wat dan ook. Wij gebruiken natuurlijk zfs send en receive.
Aangezien zfs send en receive zelf alleen maar naar stdout schrijven en lezen van stdin heb je een hulp programma nodig om het netwerk transport te verzorgen. Veel gebruikte tools zijn ssh en netcat maar mbuffer is mijn grote favoriet.
Omdat er tijdens de overdracht tal van factoren een rol spelen in de totale overdracht duur en daarmee de gemiddelde snelheid heb ik alles grotendeels onafhankelijk getest om te laten zien waar bij @jacovn de bottleneck zat. Ook hoop ik dat het hierna duidelijker is dat dit soort problemen maatwerk zijn.

We wisten dat iperf niet echt de maximale 10GBit wist te behalen. Kon mbuffer dat wel?
Als eerste zetten we een ontvanger (zfsguru1) op die alles naar /dev/null weggooide. Daarna een zender (zfsguru3) die van /dev/zero zo snel mogelijk naar mbuffer schrijft en diezelfde mbuffer die dat zo snel mogelijk naar de ontvanger stuurt

code:

zfsguru1# mbuffer -4 -s 128k -m 1G -I 5001 > /dev/null
in @ 1122 MiB/s, out @ 1122 MiB/s, 683 GiB total, buffer 0% full
summary: 684 GiByte in 10min 27.7sec - average of 1115 MiB/s 

zfsguru3# dd if=/dev/zero bs=1M count=700000 | mbuffer -4 -s 128k -m 1G -O 192.168.3.151:5001
in @ 1122 MiB/s, out @ 1122 MiB/s, 682 GiB total, buffer 100% full700000+0 records in
700000+0 records out
734003200000 bytes transferred in 626.935080 secs (1170780234 bytes/sec)
in @ 0.0 KiB/s, out @ 1122 MiB/s, 683 GiB total, buffer 34% full
summary: 684 GiByte in 10min 27.5sec - average of 1115 MiB/s

WTF? dat is 935GBit/sec of 1169MB/sec aan data (overhead van framing en tcp/ip komen er nog nog bij) zomaar out-of-the-box. Niks getweak aan tcp buffers, window sizes en wat voor andere setting waarvan niemand weet waar ze voor dienen.

Eerste conclusie met mbuffer werd het netwerk maximaal belast.

Vervolgens het overzetten van de data met zfs send en receive.

code:

zfsguru1# mbuffer -4 -s 128k -m 1G -I 5001 | zfs recv -vFd pool 1/share
receiving full stream of tank5/share@2015-04-09 into pool1/share/share@2015-04-0 9
in @ 0.0 KiB/s, out @ 0.0 KiB/s, 18.5 TiB total, buffer 0% full
received 18.5TB stream in 23456 seconds (829MB/sec)

zfsguru3# zfs send -R tank5/share@2015-04-09 | mbuffer -4 -s 12 8k -m 1G -O 192.168.3.151:5001
in @ 0.0 KiB/s, out @ 617 MiB/s, 18.5 TiB total, buffer 7% fulll
summary: 18.5 TiByte in 6h 30min 49.7sec - average of 829 MiB/s

829 MiB/sec is niet verkeerd maar is ook niet wat we eerder hadden gemeten (1115MiB/sec) zonder zfs send.
Waar zat dit verschil in? Was zfs send de beperkende factor? Of kon zfs receive het niet zo snel weg schrijven?
Tijdens de overdracht had @jacovn zo af en toe wat buffer underrun gezien op de zender.
De enige manier om deze hypothese te testen was zfs send naar /dev/null te sturen en kijken hoelang dat duurde.

code:

zfsguru3# zfs send -R tank5/share@2015-04-09 | dd bs=1M of=/dev/null
0+465976080 records in
19445956+1 records out
20390563309236 bytes transferred in 22908.047300 secs (890104820 bytes/sec)

Dat is dan 848 MiB/sec. Dit is sneller (6h 21min 48sec) dan over het netwerk (6h 30min 49.7sec). Hoe kan dit? Het verschil tussen de pieken en dalen in snelheid van zfs send is groter dan mbuffer kan vereffenen. Dus zfs send kan de data zo af en toe niet snel genoeg lezen van het enkele RAIDZ2 vdev in de pool.

Om de jumbo frame discussie ook maar te beslechten hebben we de synthetische test herhaald maar nu met jumbo frame support.
ix0 van MTU 1500 naar 9000 gezet
wederom de mbuffer icm dd test

code:

zfsguru1# mbuffer -4 -s 128k -m 1G -I 192.168.3.153:5002 > /dev/null
in @ 1180 MiB/s, out @ 1180 MiB/s, 683 GiB total, buffer 0% full
summary: 684 GiByte in 9min 53.9sec - average of 1179 MiB/s

zfsguru3# dd if=/dev/zero bs=1M count=700000 | mbuffer -4 -s 128k -m 1G -O 192.168.3.151:5002
in @ 1180 MiB/s, out @ 1180 MiB/s, 682 GiB total, buffer 100% fulle700000+0 records in
700000+0 records out
734003200000 bytes transferred in 593.192158 secs (1237378462 bytes/sec)
in @ 0.0 KiB/s, out @ 1180 MiB/s, 683 GiB total, buffer 21% full
summary: 684 GiByte in 9min 53.8sec - average of 1179 MiB/s

Ter vergelijking bij een MTU van 1500 duurde het 10min 27.5sec met een gemiddelde van 1115 MiB/sec
en nu met een MTU van 9000 duurde het 9min 53.9sec met een gemiddelde van 1179 MiB/sec
Dat is zo'n 5% tijd winst.
Waren er nog andere verschillen? Ja alleen de cpu load op de ontvanger zakte van zo'n 17% naar 10% de interupt tijd bleef gelijk en op de verzender bleef alles min of meer hetzelfde. Waarom niet een groter verschil? Omdat het hier om goede moderne netwerk kaarten gaat, Intel X520-DA2, met allerlei offload features. Bij oudere of mindere kaarten is dit verschil groter.
Hebben jumbo frames zin?
Hier misschien niet zo veel. Toch in het algemeen is er veel voor te zeggen. Je moet de zaken wel goed in richten, zet het altijd in een vlan, plaats het in een eigen non routable subnet. Mijn ervaring is dat jumbo frames voor storage toepassing altijd pure winst zijn. Vooral bij vSphere toepassingen is het net dat beetje extra. Ik zou het niet zomaar inzetten tussen je pc en je nas.

Om het verschil tussen MTU 1500 en MTU 9000 te illustreren heeft @jacovn wat spectaculaire beelden op youtube gezet.
Let op de load links boven!

Ook nog een filmpje van de zfs send en receive van 18TB waarbij het grillige karakter van zfs send te zijn is. Ook is nu goed te zien dat het lezen van disk en versturen en weer wegschrijven naar disk op maximale snelheid wel resources kost. De Xeon E3-1265LV2 @2.5 GHz was op de ontvanger voor zo'n 70% belast met alleen de stream weer weg te schrijven. Er is daar weinig ruimte om nog een beetje transcoding te doen.

De volgende conclusies kunnen worden getrokken
-de totale duur van zfs send hangt af van de onderliggende data. Veel kleine files kosten meer tijd dan een paar grote binaries.
-mbuffer is een handige tool om pieken en dalen van zfs send te vereffenen. De grote van de buffer hangt mede af van het verschil tussen pieken en dalen. De buffer moet zoveel data bevatten dat voordat de buffer leeg is zfs send weer op wirespeed of sneller data aanlevert.
-de grote buffer aan de ontvangende kan had hier nauwelijks effect. Toch kan het handig zijn. Bijvoorbeeld als de zpool van de ontvanger belast is. Dan kan de zpool misschien niet altijd alles op tijd wegschrijven dan kan de buffer handig zijn.
-Steekproeven hebben alleen zin als het om een representatieve sample gaat. @jacovn had op een gegeven moment wat directories naar een anders ZFS filesystem gecopieerd. En gemeten hoe lang dat duurde met zfs send. Toen bleek die data met 1.1GB/sec te kunnen worden gelezen, terwijl ALLE data lang niet zo snel kon worden gelezen. Als je het echt wilt weten meet dan over de hele dataset.
-Ook zie je hier dat de organisatie van de vdevs van invloed is op de (lees) prestaties. De verzender las vanaf een pool met 10x een Hitachi 7K4000 in een enkele RAIDZ2 vdev. Worst case read performance is dat van een enkele disk bij RAIDZx en dat is wat er ook enkele malen gebeurde.

Samenvatting

• Van 140MB/sec met NFS naar 829MiB/sec via zfs en mbuffer. Probleem opgelost. Wil je nog sneller? Splits de pool op in twee vdevs.
• ZFSGuru gebaseerd op FreeBSD 10.0-STABLE is out-of-the-box in staat om 10GBit ethernet zonder enige tweaks helemaal vol te schrijven. Hulde aan FreeBSD.
• Ga niet te snel allemaal tweaks doen die je eigenlijk niet snapt. Bedenk wat testen om er achter te komen waar de bottleneck zit. Misschien kom je er achter dat je helemaal niet hoeft te tweaken want het gaat niet sneller om welke reden dan ook.
• Ik denk niet dat welke applicatie of protocol zo snel de data kan over zetten als zfs send / receive icm mbuffer. Daarnaast verlies je bij iedere andere tool je zfs metadata en eventuele snapshots.
• Als ik een ranking zou moeten maken van file sharing protocollen van snel naar langzaam voor een unix systeem dan dat er als volgt uit zien:
  1. FTP, simpel snel en sommige clients kunnen meerdere streams tegelijk versturen
  2. NFS, simpel om op te zetten lastig om de performance van mbuffer te evenaren
  3. SMB en dan met name SMB2. Soms makkelijk op te zetten soms moeilijk als het met de hand moet. Ook hier zal niet zonder meer (lees bij lange na niet) de performance van mbuffer worden evenaard. SMB3 is een ander verhaal maar dat is op unix nog niet echt mainstream.
  Optioneel heb je nog tools nodig om het copieren parallel uit te voeren.
• Dan zit je met het probleem van crash recovery en gebrek aan data integriteit.
• En voordat iemand rsync noemt... diegene heeft nog nooit rsync gebruikt. RSync werkt prima als de data is over gezet niet om te copieren.
• Deze zelfde transfer kan je op gigabit wel met een kleine pentium afhandelen. Voor 10GBit heb je een zwaardere CPU nodig.

Slotopmerkingen
In het begin had ik voorgesteld om met iperf, wat een zeer geaccepteerde tool is, een baseline van het netwerk vast te stellen. Bij de standaard settings leverde dit over een minuut gemeten zo'n 7700MBit/sec op. Na enkele pogingen om dit te verbeteren ben ik hier snel mee gestopt. Mede omdat mbuffer wel volle snelheid wist te behalen. Ik heb later nog een keer getracht dit te verbeteren maar kwam niet hoger dan 7700MBit. Ik zal nog eens kijken of ik wirespeed op FreeBSD kan halen met iperf. Het is zonde om je tijd in iperf te stoppen ipv zfs send en receive.

Het was erg leuk om dit op te schrijven en de samenwerking met @jacovn was erg prettig.
Als lezers nog opmerkingen, vragen of nieuwe onderzoeks voorstellen dan hoor ik dat graag.

[brederodekater]

Leuk om te lezen & erg waardevol. Bedankt mannen!

[Q]

@tvwes, dit is interessant om te lezen, ik kende mbuffer niet, goed verhaal.

Ik heb zelf ook gemerkt hoe waardevol een juiste MTU (9000) kan zijn als je onder linux bonding doet van 4 gbit kaarten tot 4 Gbit (met inderdaad gescheiden vlans).

Vaak genoeg haal ik niet de 450 MB/s met een rsync of cp omdat met veel kleine bestanden dan de performance instort, en rsync is sowieso traag. Ik moet zelf ter backup ook iets van 6 TB wegzetten en ik ga hier ook eens mee spelen.

[tvwes]

Q schreef op dinsdag 14 april 2015 @ 08:22:
@tvwes, dit is interessant om te lezen, ik kende mbuffer niet, goed verhaal.

@Q
Snelle initiele testjes, van disk en netwerk, lieten snelheden van meer dan 1GB/sec zien terwijl dat uiteindelijk niet gehaald werd. (maar 829 MiB/sec) Het artikel was er vooral opgericht om te laten zien hoe systematisch te werk je moet gaan om achter de oorzaak van deze lagere snelheid te komen.
Daarnaast was het een goed voorbeeld van KISS, niks moeilijke settings en getweak, zo out-of-the-box een prachtig resultaat.

Ik heb zelf ook gemerkt hoe waardevol een juiste MTU (9000) kan zijn als je onder linux bonding doet van 4 gbit kaarten tot 4 Gbit (met inderdaad gescheiden vlans).

Q, dat mac spoofing was een leuke en de noodzaak van gescheiden vlans werd natuurlijk niet met dikke letters vermeld?
Wat voor mode gebruik jij?

code:

# cat /sys/class/net/bond0/bonding/mode

Ik neem aan dat alleen hosts die deel uitmaken van de bonded interface met elkaar kunnen communiceren. Het is dus niet als een trunk waar clients met een enkele poort ook over kunnen communiceren. Ik wil direct opmerken dat bij een trunk de snelheid altijd begrenst bij een enkele datastream tot de maximale snelheid van een enkele link. Deze bonded interface lost dit nu op.

Q, waarom maar 350MB/sec zonder jumbo frames en 450MB/sec met?
Ik begrijp dat het probleem is opgelost maar ik blijf toch met een beetje naar gevoel zitten doordat ik niet weet waarom het maar 350MB/sec was bij een MTU van 1500.
Is het probleem CPU bound? Is het de nic?
Want hoe dan ook zit je nu ook nog lang niet aan de max capaciteit. Reken even mee:
Gigabit ethernet hier beter bekend als 802.3ab kan 1 000 000 000 bits/sec elke richting op transporteren. Dit is gelijk aan 125000000 bytes/sec (125MB/sec) maar nu moet hier de overhead van L2-L4 van af.
Een ethernet paket bestaat uit een preambule (7 bytes), scheidingsteken (1 byte) en een ethernet frame gescheiden door minimaal 96 bits (12 bytes) pauze. Een ethernet paket is tussen de 72 - 1526 bytes groot
Een ethernet frame is tussen de 64 en 1518 bytes lang met een maximum data lengte (MTU) van 1500.
Nu gaat van de 1500 nog de IP header (20 bytes) en de TCP header (20 bytes) af en je houd de MaximumSegmentSize (MSS) over van 1460.
Per 1538 bytes over de lijn kan je max 1460 aan data versturen met TCP. Anders gezegd max 81274 volle ethernet packet, -frames of TCP packets per seconde. Is ruim 118MB/sec.
Nu komt er in jouw geval nog 4 bytes bij iedere ethernet frame ivm de vlan tagging, je krijgt dan ethernet packets van 1542 bytes bij een gelijkblijvende MSS van 1460.
Nu nog even de jumbo frame berekening. Stel dat de MTU 9000 wordt. Dan wordt een ethernet packet 9042 bytes en de MSS 8960. Met jumbo frames kan je nog maar 13824 ethernet packet /sec sturen maar je kan bijna 124MB/sec aan data versturen tov 118MB.sec bij gewone frames. Niet een spectaculair verschil. Maar wel minder processing doordat je minder paketjes hebt.
Met vier keer gigabit en jumboframes kan je bijna 600MB/sec aan nuttige data versturen, jij meet maar 450MB/sec. Is de verdwenen 150 MB/sec overhead? Waarom haal je maar 350MB/sec zonder jumbo frames? Als je mijn mbuffer icm dd draait over je bonded interface wat haal je dan?

Mensen houd er rekening mee dat deze getallen ruwe data is, overhead in L5-L7 (bijv SMB of NFS) gaat hier nog van af. Je zal nooit 118MB/sec via een SMB file copy behalen over gigabit. Jumbo frames leveren niet veel winst op, het kan de cpu load (vooral op de ontvanger) behoorlijk verlagen. Een moderne nic met werkende offload features kan de noodzaak voor jumbo frames grotendeels teniet doen.
Laatste tip: de ene MTU is de andere niet. Soms moet je ethernet frame size opgeven waar MTU staat of iets ander wazigs. Out-of-the-box, zonder vlans en jumbo frames, zal ieder OS en apparaat echt wel een MTU van 1500 hebben. Alleen heb ik wel eens gemerkt dat bij het instellen van jumboframes je net een paar bytes tekort of te veel had. Het bleek dat je waar MTU stond stiekem de etherframe size instelde of dat soort grappen. Altijd testen van twee kanten of je ook echt de ingestelde MTU kan versturen. Voor maximale zekerheid met tcpdump of wireshark nog even kijken.

Vaak genoeg haal ik niet de 450 MB/s met een rsync of cp omdat met veel kleine bestanden dan de performance instort, en rsync is sowieso traag. Ik moet zelf ter backup ook iets van 6 TB wegzetten en ik ga hier ook eens mee spelen.

Plain and simple veel files oversturen en niet rsync of cp?
Op de ontvanger: mbuffer -I poort [options] | tar xf -
Op de verzender: tar cf - /mijn_dir | mbuffer -O ontvanger:poort [options]
Ipv tar zou je star kunnen overwegen, uitgebreider en meer compatible.
Als je files comprimeerbaar zijn kan je in tar compressie aan zetten. Of nog beter een multithreaded compressor gebruiken als pxz of lrzip Deze zet je tussen tar en mbuffer in. Let wel op dat je dit eerst even moet testen op je data. Als tar het niet sneller kan lezen dan mbuffer het kan schrijven dan heeft compressie geen zin. Of als de compressie zoals cpu kost dat tar en mbuffer hier onder leiden dan moet je misschien een andere compressie of geen gebruiken.

@Q ik denk dat ik het jouw niet hoef uit te leggen maar bovenstaand was voor algemeen gebruik.
Als er vragen zijn dan hoor ik het graag.

[jacovn]

Anoniem: 15758 schreef op zondag 12 april 2015 @ 19:45:
Ben ik zeker ook benieuwd in! Is het punt de TCP receive window, die vaak icm Windows platforms erg laag is (8 tot 16KiB) of zijn het andere zaken die roet in het eten gooien.

Bedankt voor de hint, heb nu 2.5x de snelheid van Server naar PC toe..

Van 100 MB/sec naar 250 MB/sec

code:

netsh int tcp set global autotuninglevel=normal
netsh interface tcp set heuristics disabled

[Mr Alfabet]

Ik heb een paar vraagjes, maar ter goede onderbouwing eerst even de specs:

Ubuntu 14.04 LTS
1 zfs pool met 10 3TB disks
19" kast met hotswap bays voor de disks
2x M1015 met SAS>SAS kabels voor de backpane

Als ik een schijf uit de kast trek en dan een zpool status commando geef, denkt zfs blijkbaar dat alle schijven er nog zijn. Is er per se een scrub nodig om een disk failure te herkennen? Of is een schijf er hot swap uit halen niet hetzelfde als een disk failure? Na een reboot werd er wel herkend dat er een schijf mistte.

Ik heb begrepen dat het voor consumentendisks en thuisgebruik aanbevolen is om 1x per maand een scrub uit te voeren, is dat correct? De NAS wordt voornamelijk gebruikt voor downloaden/opslag/mediaserver. De spotweb server database die geinstalleerd is staat op de SSD.

Om te testen of de redundancy werkte, heb ik er een schijf uit getrokken, reboot gedaan (zodat zfs zou herkennen dat de schijf er uit lag) en de schijf er weer ingestopt. Vervolgens probeerde ik een replace commando uit te voeren, maar blijkbaar werd de schijf al herkend als onderdeel van de pool, dus werkte dat niet. Andere (verse) schijf gepakt, toen werkte de replace wel en begon het resilveren.

Nu wil ik graag de schijf die er oorspronkelijk uit is gehaald instellen als hot spare, maar ben bang dat de schijf straks weer herkend wordt als onderdeel van de zpool ipv als 'nieuwe' schijf. Hoe kan ik enige trace dat deze schijf ooit deel heeft uitgemaakt van de pool verwijderen? Ik gok dat er zowel iets met de zfs pool als met de schijf moet gebeuren.

Er zijn verschillende scripts in omloop die bv een email sturen als de zpool niet meer goed is, maar aangezien het hierboven beschreven probleem, weet ik niet of ik er op kan vertrouwen dat de status correct wordt uitgelezen. (Ik kom van een Areca af, die een HELS geluid produceerde de seconde dat er ook maar 1 schijf mistte)

[tvwes]

Mr Alfabet schreef op dinsdag 14 april 2015 @ 16:00:
Ik heb een paar vraagjes, maar ter goede onderbouwing eerst even de specs:

Ubuntu 14.04 LTS
1 zfs pool met 10 3TB disks
19" kast met hotswap bays voor de disks
2x M1015 met SAS>SAS kabels voor de backpane

Als ik een schijf uit de kast trek en dan een zpool status commando geef, denkt zfs blijkbaar dat alle schijven er nog zijn. Is er per se een scrub nodig om een disk failure te herkennen? Of is een schijf er hot swap uit halen niet hetzelfde als een disk failure?

Inderdaad, een hot-pull in jouw geval is niet hetzelfde als een disk io error. Daarnaast hangt er veel af van scsi laag van het OS. ZFS spreekt abstracte block devices aan. Of het nu een IDE, SATA of iSCSI (remote disk) is voor ZFS maakt het niet uit. ZFS vraagt aan deze abstractie laag (Block IO layer) "welke block devices zijn er?" "schrijf dit op die plek naar dat block device" Alleen als er een fout optreed bij een van deze opdrachten reageert ZFS. Voor zover mij bekend heeft Linux niet echt iets wat je zoekt. Mdadm heeft wel fault monitoring en alerting. Maar wat jij zoekt is bijv FMA van Solaris of Illumos. Dat is een compleet framework wat alles kan regelen, de disks tot en met hotswap van cpu's, memory en pcie devices. Dat detecteert dat een schijf verdwenen en meld dat aan ZFS. Maar ook hier gaat ZFS niet zelf er achter komen dat jij de schijf eruit getrokken hebt, het is FMA wat dit opmerkt. Of wanneer er een error optreed omdat het device weg is.
In de meeste gevallen wil je ook niet dat ZFS direct aan de bel trekt en een hotspare erbij pakt en begint te resilveren. Misschien is het een tijdelijk probleem. Had iemand per ongeluk de verkeerde disk er uit getrokken. Kwam die persoon achter zijn fout en duwde de disk weer snel terug. Zolang ZFS niks doet met dat device is er niks aan de hand. Dat je wel wil weten dat iemand de disk er uit heeft getrokken en weer snel terug geduwd, prima. Maar Linux heeft daar niet echt iets voor. Ik beweer niet dat Linux geen hotplug support heeft want dat heeft het al jaren. Bijv via hotplug( 8 ) worden devices in /dev via udev(adm) aangemaakt en weer verwijdert. Het is dus niet zo dat Linux geen hotplugging ondersteund. Linux heeft alleen niet een high level framework waarin fouten worden gelogd en kunnen worden hersteld. Je kan prima een programma maken ( in /lib/udev/ volgens mij) wat reageert op specifieke events zoals disk removal en dan een alert versturen of ZFS opdrachten geven. Er is bijv een tool devmon die grotendeels de glue voor je verzorgt, je moet alleen de nodige acties zelf opgeven.
Begin AANVULLING/CORRECTIE
ZoL heeft natuurrlijk de zed (zfs event daemon) sinds versie 0.6.3 wat oa gebruikt maakt van wat ik hierboven beschreef. zed heeft oa een set udev rules die kijken naar device removal wat ik zo snel zag op github.
Ik was deze feature een beetje kwijt omdat ik ZoL niet echt goed volg en het voor mij een non issue is omdat ik gebruik maak van FMA.
Feit blijft er geen algmeen framework is voor dit soort problemen, het ZoL project heeft het voor zich zelf opgelost.
einde AANVULLING/CORRECTIE

Na een reboot werd er wel herkend dat er een schijf mistte.

Logisch na het opstarten zoekt ZFS alle benodigde disks van je pool bij elkaar en als er dan een ontbreekt dan krijg je melding.

Ik heb begrepen dat het voor consumentendisks en thuisgebruik aanbevolen is om 1x per maand een scrub uit te voeren, is dat correct? De NAS wordt voornamelijk gebruikt voor downloaden/opslag/mediaserver. De spotweb server database die geinstalleerd is staat op de SSD.

Prima, het is maar hoeveel vertrouwen je hebt in je spullen.

Om te testen of de redundancy werkte, heb ik er een schijf uit getrokken, reboot gedaan (zodat zfs zou herkennen dat de schijf er uit lag) en de schijf er weer ingestopt. Vervolgens probeerde ik een replace commando uit te voeren, maar blijkbaar werd de schijf al herkend als onderdeel van de pool, dus werkte dat niet. Andere (verse) schijf gepakt, toen werkte de replace wel en begon het resilveren.

Nu wil ik graag de schijf die er oorspronkelijk uit is gehaald instellen als hot spare, maar ben bang dat de schijf straks weer herkend wordt als onderdeel van de zpool ipv als 'nieuwe' schijf. Hoe kan ik enige trace dat deze schijf ooit deel heeft uitgemaakt van de pool verwijderen? Ik gok dat er zowel iets met de zfs pool als met de schijf moet gebeuren.

Ik weet niet hoe je zpool is georganiseerd. Maar ik zou zeggen zpool offline [zpool name] [verdwenen disk] En daarna, mits de nieuwe disk op dezelfde device id krijgt van het OS, komt zpool replace [zpool name] [verdwenen disk]. Krijgt het een andere device id zpool replace [zpool name] [verdwenen disk] [nieuwe disk] en tot slot zpool online [zpool name] [verdwenen of nieuwe disk] In de tussen tijd kan je het in de gaten houden met zpool status. Na het resilveren nog wel een scrub uitvoeren.

Ik weet niet hoe ZoL omgaat met jouw specieke geval. Maar het lijkt raadzaam om nadat je de verdwenen disk hebt vervangen en zfs weer blij is, de disk die je eruit getrokken hebt even wissen.

Er zijn verschillende scripts in omloop die bv een email sturen als de zpool niet meer goed is, maar aangezien het hierboven beschreven probleem, weet ik niet of ik er op kan vertrouwen dat de status correct wordt uitgelezen. (Ik kom van een Areca af, die een HELS geluid produceerde de seconde dat er ook maar 1 schijf mistte)

Ik weet niet hoe je dit fatsoenlijk in Linux kan regelen, ook al heb ik boven wel wat hints en voorbeelden gegeven. Wat ik wel weet is dat dit geen probleem is van ZFS. ZFS is een volume manager en filesystem. ZFS (net als ieder ander FS) werkt met abstracte block devices. Jouw Areca kaart heeft dit wel af fabriek, hier moet je zelf aan de slag. Komt het even goed uit dat alles open source is en jij een tweaker bent. Met alle hints heb jij binnen een kwartier een scriptje gemaakt wat jouw een email stuurt als je de volgende keer de disk eruit trekt. Toch??
Hoe leuk het ook is monitoring en alerts, ik zou me er niet te druk over maken. Als het kan een spare en een simpel script wat een keer per dag of zo kijkt in zpool status of alles ok is. Als er een drive kapot gaat en je bent op vakantie kan je ook niets doen, behalve van te voren een spare toevoegen.

[ Voor 4% gewijzigd door tvwes op 14-04-2015 19:57 ]

[FREAKJAM]

Geheel off-topic, maar ik wil toch mijn waardering aan tvwes uitspreken voor de posts in dit topic de laatste tijd. Erg interessant om te lezen allemaal.

[HyperBart]

Second that, best wel eens fijn om iemand compleet los zien te gehen met 10Gbit, iets wat niet snel in thuis-setups voorkomt.

Ik had trouwens mijn grote mond wat moeten houden over ZoL. Blijkbaar is na een setje reboots mijn "scratch" pool bestaande uit een enkele EVO 500GB SSD in een Read only temporary gekomen.

Dit dus:

https://github.com/zfsonlinux/zfs/issues/2133

Seffens nog eens rebooten en eens kijken.

Moest ook wel scst terug opnieuw compilen, FireDrunk wist me te zeggen dat dat impliceerde dat ik een nieuwe kernel heb geinstalleerd, bijzonder want ik doe de laatste tijd geen upgrade/update zonder assistentie...

[ Voor 20% gewijzigd door HyperBart op 14-04-2015 18:32 ]

[tvwes]

HyperBart schreef op dinsdag 14 april 2015 @ 18:31:
Second that, best wel eens fijn om iemand compleet los zien te gehen met 10Gbit, iets wat niet snel in thuis-setups voorkomt.

Bedankt voor de aardige woorden. Maar het waren @jacovn zn spullen en zo spectaculair was het ook niet. Het was vooral een grote lap tekst van mij om het proces van troubleshooting goed uit te leggen. Alsmede het belang je doel in de gaten houden.
Leuk was het wel om het onderste uit de kan te halen.

Ik had trouwens mijn grote mond wat moeten houden over ZoL. Blijkbaar is na een setje reboots mijn "scratch" pool bestaande uit een enkele EVO 500GB SSD in een Read only temporary gekomen.

Dit dus:

https://github.com/zfsonlinux/zfs/issues/2133

Seffens nog eens rebooten en eens kijken.

Moest ook wel scst terug opnieuw compilen, FireDrunk wist me te zeggen dat dat impliceerde dat ik een nieuwe kernel heb geinstalleerd, bijzonder want ik doe de laatste tijd geen upgrade/update zonder assistentie...

Ik ga nu niet zeggen "told you so" Maar ik hoop wel dat mensen iets beter van te voren nadenken over hun keuzes. Als er adviezen worden gegeven om iets wel of niet te doen denk dan twee keer na voordat je die in de wind slaat. Als je lekker wilt klieren uh oefenen met allerlei verschillende ZFS implementaties prima. Maar voor je NAS zou ik toch even goed na denken of je nu perse met een of andere experimentele configuratie aan de slag moet gaan. Ik heb mijn thuis NAS eind 2008 ingericht en er nooit meer aangezeten. Ik gebruik een hele beperkte feature set en alle ZFS bugs vanaf december 2008 zijn niet gefixet. Maar omdat ik weet dat er daar geen last van heb en ik het heel druk heb en ik nog nooit een issue heb gehad op enkele stroom storingen en een uitgebrande voeding na. Maar geen enkele vastloper of wat dan ook. De NAS bedient een ESXi 4 machine via NFS, host zelf enkele taken als mail, db, logging etc.en verzorgt wat backups voor diverse clients. Misschien haal ik niet zo'n hoge load als sommigen met transcoden etc. Maar dit apparaat bedient een groep echte mensen die niet blij zijn als ze niet bij hun mail etc kunnen. Waarom is dit zo stabiel? Omdat ik van te voren echt goed heb gekeken naar mobo's en software. Overigens destijds was er niet zoveel keuze, er was OpenSolaris of Solaris 10 als je zfs wilde. Bij OpenSolaris kwam iedere twee weken een nieuwe build uit. Soms was je heel blij omdat er een fix of nieuwe feature in zat soms was je helemaal niet blij omdat er een regressie in zat. Soms bleef die regressie lang aanwezig... Build 104 was voor mij destijds prima. Ik heb nog een tijd gekeken of er een nieuwe release was met wat features waar ik wat aan had maar heb het nooit aangedurfd wat al die nieuwe releases hadden ook weer hun eigen problemen.

Bezint eer ge begint
en...
ge houd tijd over.

[HyperBart]

Tja, zolang ik niet reboot heb ik ook geen problemen hoor, dit is de eerste keer sinds tijden dat ik eens gereboot heb (omwille van meting verbruik) en in al die tussentijd hebben mijn ESXi hosts ook geen kik gegeven. En dat zijn er dan 3 (!), niet slecht voor een thuis-setup denk ik dan op basis van ESXi 5.5...

En ik heb de moeilijkste eindgebruiker der eindgebruikers: een vrouw, mijn bijna-echtgenote

[Pantagruel]

HyperBart schreef op dinsdag 14 april 2015 @ 19:48:
...
En ik heb de moeilijkste eindgebruiker der eindgebruikers: een vrouw, mijn bijna-echtgenote

Haha, ken 't gevoel, die blik van totale onbegrip en 't moment van besef dat 'de man' toch meer nerd is dan gedacht, is soms wel vertroetelend.

"Maar schat 't werkt toch altijd, waarom nu dan niet??" , de reactie op de mededeling dat de gevirtualiseerde fileserver ca. 5 minuten niet bereikbaar zal ivm een toevoeging. Uiteindelijk was de down time minder (server uit, cage install, kabels aansluiten, server aan) en had ze haar koffie met lekkers (goed voorbereidt afleidingsmanoeuvre) nog niet op toen de boel weer in de lucht was. ( 1 ESXi 5.5 hosts, 4 actieve VM's ).

De kids reageren doorgaans 'enthousiaster': "He, wat" (terwijl de headsets afgeschoven wordt) of "als ik maar Peppa pig kan blijven kijken" , die hebben al begrepen dat pappa een verloren zaak is

[HyperBart]

Dat ik een nerd ben weet ze al langer , nou ja, ze ziet het gewoon als mijn hobby, prima dus.

Maar oweeeeee als ik eens op een avond de fileserver er uit knal. Ik krijg makkelijker maintenance windows van mijn klanten die 24/7 draaien dan van haar

[Pantagruel]

HyperBart schreef op donderdag 16 april 2015 @ 09:25:
Dat ik een nerd ben weet ze al langer , nou ja, ze ziet het gewoon als mijn hobby, prima dus.

Maar oweeeeee als ik eens op een avond de fileserver er uit knal. Ik krijg makkelijker maintenance windows van mijn klanten die 24/7 draaien dan van haar

Haha, prijsloos je reactie, zeer herkenbaar, maar ach je moet wat kunnen hebben van je lief.

[DXaroth]

HyperBart schreef op donderdag 16 april 2015 @ 09:25:
Dat ik een nerd ben weet ze al langer , nou ja, ze ziet het gewoon als mijn hobby, prima dus.

Maar oweeeeee als ik eens op een avond de fileserver er uit knal. Ik krijg makkelijker maintenance windows van mijn klanten die 24/7 draaien dan van haar

Dit is ZO herkenbaar

[HyperBart]

*BAAAAAAAART ZIJT GE IETS AANT DOEN MET DE SERVER????!*

*HART OF DIXIE START NIE!!!!!111!!!*

[Pantagruel]

HyperBart schreef op donderdag 16 april 2015 @ 10:15:
*BAAAAAAAART ZIJT GE IETS AANT DOEN MET DE SERVER????!*

*HART OF DIXIE START NIE!!!!!111!!!*

[ikkeenjij36]

Vandaag nwe poging met guru op de nwe ssd.
Eerst en alleen het systeem de rest misschien later.
Welke stable kan ik het er beste op zetten?

[FireDrunk]

Zoiets moet je afdwingen. Als zij bepaalt wanneer er in de slaapkamer dingen gebeuren, mag jij bepalen wanneer er dingen in de Server gebeuren

Mijn server, mijn regels

[ Voor 9% gewijzigd door FireDrunk op 16-04-2015 14:44 ]

[FREAKJAM]

ikkeenjij36 schreef op donderdag 16 april 2015 @ 14:23:
Vandaag nwe poging met guru op de nwe ssd.
Eerst en alleen het systeem de rest misschien later.
Welke stable kan ik het er beste op zetten?

Die vraag heb je in december ook al eens gesteld en het antwoord blijft hetzelfde lijkt me. ZFSguru with FreeBSD 10.1-STABLE and ZFS v5000 downloaden en binnen 10.x stable blijven.

[ Voor 9% gewijzigd door FREAKJAM op 16-04-2015 14:50 ]

[ikkeenjij36]

Ok sorry wou jullie niet boos maken,na maanden rust gehad te hebben en nu even tijd wou ik hetgewoon weer eens proberen.
De nieuwe pool en systeem wordt geschreven op de nieuw ssd,ik hoop dat mijn vorige problemen hiermee verdwijnen en dat het aan mijn 3 jaar oude ocz vertex3 ssd lag.
Af en toe moet er gespaard worden voor nieuwe spulletjes.

[ Voor 48% gewijzigd door ikkeenjij36 op 16-04-2015 14:53 ]

[FREAKJAM]

Ik ben helemaal niet boos Ik wijs je er alleen op dat je dezelfde vraag al eerder hebt gesteld en daar toen ook antwoord op hebt gekregen.

[ikkeenjij36]

FREAKJAM schreef op donderdag 16 april 2015 @ 14:52:
Ik ben helemaal niet boos Ik wijs je er alleen op dat je dezelfde vraag al eerder hebt gesteld en daar toen ook antwoord op hebt gekregen.

Ok prima gelukkig,voor jullie allemaal misschien gesneden koek dit alles maar voor mij blijft het altijd spannend.
Dus ik zou voorlopig nog even weg moeten blijven van 11.0....... experimental?

[FREAKJAM]

De naam zegt het al. Stable betekent gewoon stable en de experimental versie is experimenteel. Je kunt het beste gewoon altijd stable draaien.

De versienummers staan gelijk aan de FreeBSD versie trouwens. FreeBSD 10.1 is ook nog niet zo heel lang uit. (November 2014). ZFSGuru 10.1 is gewoon nieuw en ook gewoon niets mis mee.

[ Voor 36% gewijzigd door FREAKJAM op 16-04-2015 15:03 ]

[ikkeenjij36]

Ok dan ga ik dat doen en hopen als snel de nieuwe versie uitkomt dat ik dan weer terug kan op zfsguru compleet als main systeem.
Nu eerst de dingen erop zetten die ik wil draaien en dan hopen dat het stabiel blijft,dan kan ik toch gaan denken dat het aan de ssd lag en niet aan mij of mijn hardware.

Ok guru draait dus nu een goed uur met de services erop die ik wil dus zoals sabznbd coucpotato headphones en sonar,daar vooralsnog geen probleem en ik blijf het bekijken of het eea goed blijft draaien zonder storingen of hickups.
Nu mijn vraag kan ik mijn data disks die nu in shr gemaakt zijn door xpenology zomaar als een pool gaan maken in zfs(guru) zonder data verlies?
Of worden alle disks zo in een zfspool gemaakt dat alle data gewiped wordt en ik dus vanaf 0 zal moeten beginnen?
Zomaar een vraag of dit uberhaupt mogelijk iss zonder dat de data verdwijnt of veranderd.
Overigens moet ik wel zeggen dat alles stukken sneller en lijkt wel makkelijker instaleert nu met de nieuwe ssd.

[ Voor 54% gewijzigd door ikkeenjij36 op 16-04-2015 16:21 ]

[Durandal]

Ik heb iets merkwaardigs met ZoL:
Sinds de laatste herstart ben ik mijn explicite device namen kwijt, maar voor 8 van de 10 identieke drives.
Enig idee waarom en hoe dit weer recht te zetten?

code:

  pool: tank
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on software that does not support
        feature flags.
  scan: resilvered 48.4M in 0h0m with 0 errors on Sun Apr 12 00:55:42 2015
config:

        NAME                                          STATE     READ WRITE CKSUM
        tank                                          ONLINE       0     0     0
          raidz2-0                                    ONLINE       0     0     0
            ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T006xxxx  ONLINE       0     0     0
            ata-WDC_WD30EFRX-68AX9N0_WD-WCC1T041xxxx  ONLINE       0     0     0
            sdh                                       ONLINE       0     0     0
            sdi                                       ONLINE       0     0     0
            sdg                                       ONLINE       0     0     0
            sdf                                       ONLINE       0     0     0
            sdm                                       ONLINE       0     0     0
            sdk                                       ONLINE       0     0     0
            sdl                                       ONLINE       0     0     0
            sdj                                       ONLINE       0     0     0

[FireDrunk]

zfs export [pool]
zfs import -d /dev/disk/by-partlabel/ [pool]

[Durandal]

FireDrunk schreef op donderdag 16 april 2015 @ 17:32:

zfs export \[pool]
zfs import -d /dev/disk/by-partlabel/ \[pool]

Hmm ja, je bedoelde zpool, maar er is meer aan de hand:

code:

root@server:~$ dir /dev/disk/by-partlabel/
total 0
drwxr-xr-x 2 root root  60 Apr 16 15:02 .
drwxr-xr-x 8 root root 160 Apr 16 15:02 ..
lrwxrwxrwx 1 root root  10 Apr 16 15:02 zfs -> ../../sdd1

de /dev/disk/by-partlabel directory is bijna leeg behalve een obscure zfs symlink,
en nadat ik toch die import heb gedaan heb ik nu

code:

        NAME                                          STATE     READ WRITE CKSUM
        tank                                          ONLINE       0     0     0
          raidz2-0                                    ONLINE       0     0     0
            ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T006xxxx  ONLINE       0     0     0
            zfs                                       ONLINE       0     0     0
            sdh                                       ONLINE       0     0     0
            sdi                                       ONLINE       0     0     0
            sdg                                       ONLINE       0     0     0
            sdf                                       ONLINE       0     0     0
            sdm                                       ONLINE       0     0     0
            sdk                                       ONLINE       0     0     0
            sdl                                       ONLINE       0     0     0
            sdj                                       ONLINE       0     0     0

Let op zfs als 2e drive..



EDIT:

code:

zpool import -d /dev/disk/by-id/ tank

heeft het gefixed.. thanks

[ Voor 3% gewijzigd door Durandal op 16-04-2015 18:01 ]

[ikkeenjij36]

ikkeenjij36 schreef op donderdag 16 april 2015 @ 14:59:
Ok dan ga ik dat doen en hopen als snel de nieuwe versie uitkomt dat ik dan weer terug kan op zfsguru compleet als main systeem.
Nu eerst de dingen erop zetten die ik wil draaien en dan hopen dat het stabiel blijft,dan kan ik toch gaan denken dat het aan de ssd lag en niet aan mij of mijn hardware.

Ok guru draait dus nu een goed uur met de services erop die ik wil dus zoals sabznbd coucpotato headphones en sonar,daar vooralsnog geen probleem en ik blijf het bekijken of het eea goed blijft draaien zonder storingen of hickups.
Nu mijn vraag kan ik mijn data disks die nu in shr gemaakt zijn door xpenology zomaar als een pool gaan maken in zfs(guru) zonder data verlies?
Of worden alle disks zo in een zfspool gemaakt dat alle data gewiped wordt en ik dus vanaf 0 zal moeten beginnen?
Zomaar een vraag of dit uberhaupt mogelijk iss zonder dat de data verdwijnt of veranderd.
Overigens moet ik wel zeggen dat alles stukken sneller en lijkt wel makkelijker instaleert nu met de nieuwe ssd.

Nogmaals dezelfde vraag voor jullie experts hier.
En nog even een snel vraagje:ssh toegang lukt niet met winscp,ik heb het ww veranderd naar de mijne en probeer in te loggen met ssh maar winscp bv geeft melding terug:De server heeft de SFTP verbinding geweigerd, maar laat wel FTP verbindingen toe.

Wilt u het FTP protocol gebruiken in plaats van SFTP? Gebruik bij voorkeur encryptie.
Hoe krijg ik dit opgelost?
Hiervoor dit nog nooit gehad en had ik gelijk toegang.

[ Voor 15% gewijzigd door ikkeenjij36 op 16-04-2015 19:59 ]

[FREAKJAM]

Wat had je zelf al ontdekt? Eigen onderzoek wordt wel gewaardeerd. We helpen je graag, maar we zijn geen helpdesk.

Ik heb geen ZFSGuru draaien, maar volgens Google moet je OpenSSH enablen onder services. Heb je dat al gedaan? Verder zou er in de meest recente webinterface opties te vinden zijn onder access -> SSH.

[ Voor 49% gewijzigd door FREAKJAM op 16-04-2015 20:11 ]

[ikkeenjij36]

Alle mogelijke manieren zowel scp sftp en ftp maarr ik krijg geen toegang,met putty wordt gewoon de verbinding geweigerd.
Kan wel gewoon pingen ernaartoe

[ Voor 12% gewijzigd door ikkeenjij36 op 16-04-2015 20:02 ]

[FREAKJAM]

Je moet niet zomaar vanalles proberen. Duik in de materie zou ik zeggen. Daar leer je veel meer van dan zomaar in het wilde weg vanalles proberen.

Feit dat je kunt pingen heeft trouwens verder niets te maken met het feit of SSH het wel of niet doet. Een ping is simpelweg een soort van hulpmiddel waarmee je kunt controleren of een ander device bereikbaar is binnen een netwerk. SSH betreft een protocol waarmee je op een versleutelde manier inlogt op een andere computer en via een secure shell commando's ingeeft met bijv putty.

[ Voor 81% gewijzigd door FREAKJAM op 16-04-2015 20:17 ]

[thibautb]

Misschien eerder een vraag om op het forum van freenas te stellen als dat gaat... Maar ik vroeg me af of, bij freenas als ik een nieuw raidz volume aanmaak dan staat daar bij expand volume, kan ik dan dus bv 5x 4tb raidz doen x2 zodat ik eigenlijk raidz2 heb onder 10 x4 tb?

[jacovn]

Putty werk prima bij mij met ssh inloggen op de server (10.1)
Je moet wel het password onder services zetten...
En in putty ook de ssh flag aanzetten, anders doe je plain telnet...

[ Voor 23% gewijzigd door jacovn op 16-04-2015 20:49 ]

[ikkeenjij36]

jacovn schreef op donderdag 16 april 2015 @ 20:48:
Putty werk prima bij mij met ssh inloggen op de server (10.1)
Je moet wel het password onder services zetten...
En in putty ook de ssh flag aanzetten, anders doe je plain telnet...

Heb ik allemaal gedaan ook het pw aangepast in services maar helaas niks putty error:network refused.
Nu komt trouwens ineens heel de gui niet meer tevoorschijn,dan maar een reboot,of mijn hw is niet geschikt voor zfsguru?

[FREAKJAM]

Het is al vaker tegen je geroepen in dit topic en ik zeg het weer:

Is ZFSGuru wel de juiste oplossing voor jou? Elke keer weer probeer je het opnieuw (wat ik trouwens aanmoedig, want doorzettingsvermogen heb je zeker), maar keer op keer raak je met ZFSGuru of vooral jezelf in de knoop. Ik ben bang dat deze oplossing en ZFS wellicht te hoog gegrepen voor je is.

Je had laatst nog Xpenology draaien en dat draaide letterlijk (het waren je eigen woorden) als een tierelier. Ik weet niet wat daar is mis gegaan, maar ik denk dat dat pakket toch beter bij je past. Idem dito voor OpenMediaVault. In de laatste versie kun je alles draaien wat jij zoekt (Plex, Sab, Sonarr etc). OpenMediavault is Debian (linux) based en dat is denk ik toch iets makkelijker dan FreeBSD met ZFS.

[ Voor 28% gewijzigd door FREAKJAM op 16-04-2015 21:13 ]

[ikkeenjij36]

Nou ik weet nu wat er aan de hand is/was.
Doordat ik de pool geupgrade heb naar zfs5000 zijn er feuture flags geinstaleerd/geactiveerd waardoor de pool verdwijnt of niet actief is?
Ik heb geen idee hoe dat kan of dat dat wel klopt met een fresh install,misschien hebben jullie een idee?
Of moet ik gewoon de pool niet upgraden?
Dat is dan met de enige pool die op de ssd staat en dus als start schijf geldt.
Dus het heeft iets met de v500 te maken.
Kunnen jullie gedacjten hier eens over laten gaan?
Als ik hem op 28 laat staan werkt het wel goed dus ik zou nooit de pool kunnen upgraden naar de laatste?

[GioStyle]

thibautb schreef op donderdag 16 april 2015 @ 20:46:
Misschien eerder een vraag om op het forum van freenas te stellen als dat gaat... Maar ik vroeg me af of, bij freenas als ik een nieuw raidz volume aanmaak dan staat daar bij expand volume, kan ik dan dus bv 5x 4tb raidz doen x2 zodat ik eigenlijk raidz2 heb onder 10 x4 tb?

Kortgezegd: nee.

Wat je eigenlijk doet is je maakt een pool aan dat uit 1 vdev bestaat. In jouw voorbeeld dus 5x 4TB raidz1. Vervolgens wil je uitbreiden met nog eens 5x 4TB raidz1. Dat wordt dan nog een vdev die je vervolgens aan je pool toevoegt.

Dan heb je uiteindelijk een pool die uit 2 vdev's bestaat. En elk vdev bestaat uit 5x 4TB raidz1.

Dat is niet veiliger dan pool die bestaat uit 1 vdev van 10x 4TB raidz2.

[ikkeenjij36]

MM weer eens ever opnieuw begonnen eerst de ssd geformateerd via de gui en nu kan er geen pool gecreeerd wordn dan valt de pagina weg en de pool is niet gemaakt na een refresh vd pagina,weer wat vreemds waar ik toch echt iets anders van verdenk als mijn hardware.

[jacovn]

De boot pool kan alleen v5000 hebben als je ook de boot code update staat op zfsguru forum: http://zfsguru.com/forum/zfsgurusupport/766

[ikkeenjij36]

jacovn schreef op donderdag 16 april 2015 @ 21:31:
De boot pool kan alleen v5000 hebben als je ook de boot code update staat op zfsguru forum: http://zfsguru.com/forum/zfsgurusupport/766

Inderdaad en dat had ik ook netjes gedaan voordat ik er ook maar iets anders meegedaan heb vnadaar het gekke dat ik er niet vanaf kon booten.
Nu probeer ik dus op de nwe ssd een pool te maken en dat lukt dus niet meer,is de schijf nu al kapot/verloren voor zfsguru of niet,nu eve kijken of het op de oude vertex wel wil lukken anders moet het toch ergens anders in gaan zoeken.
En nee hoor elke keer als ik dus een pool wil maken mislukt het dan valt de verbinding weg op de pagina en zegt ie dat ie niet kan verbinden,geef ik een refresh is het weer van 0 af beginnen en niet werken.
Eerst maar weer eens een andere livecd maken dan.

[FireDrunk]

Durandal schreef op donderdag 16 april 2015 @ 17:47:
[...]


Hmm ja, je bedoelde zpool, maar er is meer aan de hand:

code:

root@server:~$ dir /dev/disk/by-partlabel/
total 0
drwxr-xr-x 2 root root  60 Apr 16 15:02 .
drwxr-xr-x 8 root root 160 Apr 16 15:02 ..
lrwxrwxrwx 1 root root  10 Apr 16 15:02 zfs -> ../../sdd1

de /dev/disk/by-partlabel directory is bijna leeg behalve een obscure zfs symlink,
en nadat ik toch die import heb gedaan heb ik nu

code:

        NAME                                          STATE     READ WRITE CKSUM
        tank                                          ONLINE       0     0     0
          raidz2-0                                    ONLINE       0     0     0
            ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T006xxxx  ONLINE       0     0     0
            zfs                                       ONLINE       0     0     0
            sdh                                       ONLINE       0     0     0
            sdi                                       ONLINE       0     0     0
            sdg                                       ONLINE       0     0     0
            sdf                                       ONLINE       0     0     0
            sdm                                       ONLINE       0     0     0
            sdk                                       ONLINE       0     0     0
            sdl                                       ONLINE       0     0     0
            sdj                                       ONLINE       0     0     0

Let op zfs als 2e drive..



EDIT:

code:

zpool import -d /dev/disk/by-id/ tank

heeft het gefixed.. thanks

Die symlinks komen omdat je wel gpt gebruikt maar je disks allemaal hetzelfde label hebben. In mijn ogen niet aan te raden, maar by-id werkt idd wel.

[Anoniem: 15758]

ikenjij36, ik heb nog wel even tijd om je te helpen hoor. Stuur even je complete hardware setup naar mij toe, welke livecd/iso je gebruikt en precies wat meer over dat de netwerkverbinding wegvalt waar je over sprak.

[ikkeenjij36]

Ok ga ik doen via pm.
En pm verstuurd.

[ Voor 36% gewijzigd door ikkeenjij36 op 16-04-2015 22:09 ]