Het grote ZFS topic

[FireDrunk]

CurlyMo schreef op dinsdag 21 maart 2017 @ 09:05:
Vraagje over de grote van de ZIL / SLOG. Op internet lees ik dat dit afhangt van de snelheid van je netwerk:

[...]


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

Volgens mij klopt dat niet. Writes gaan niet per definitie naar ZIL/SLOG, alleen als re-ordering ten behoeven van de performance een gevaar voor de integriteit opleverd, gaan writes naar ZIL voor zover ik weet.

Als in 1 transactiegroep een heleboel async writes zitten die super goed direct uitgevoerd kunnen worden, maar er zit een kleine sync write in de weg die "eigenlijk" eerst moet. Zal ZFS in memory de sync write gewoon uitvoeren (waardoor reads alsnog goed gaan daarna), maar zal de daadwerkelijke IO naar ZIL gaan.

Daardoor kunnen al die async writes gewoon doorgaan in de transaction group, en kan de volgende transaction group gewoon alsnog de status van je memory naar disk geschreven worden (en er wordt dus ook niet van ZIL gelezen).

Stel je trekt tijdens de commit van de async transaction group de stekker er uit, zou je dus eigenlijk een invalid state hebben, omdat de sync write terug gecommit is naar de gebruiker.

Maar bij boot, tijdens de import van de pool, kijkt zfs of de laatste pointer de laatste write bevat van wat er in de ZIL staat. En alleen op *dat* moment zal er gelezen worden van de ZIL, en zal die ene (of een paar) sync writes alsnog toegepast worden op je pool.

ZIL wordt dus alleen belast met SYNC writes die ge-re-ordered worden. Als je 1 write hebt, in 1 transaction group op een pool die niets anders doet, zie je hem volgens mij niet door je SLOG heen gaan.

Als directe reactie op je post:
Dat verhaal met netwerk is leuk, maar mijn VMware machine kan toch echt via iSCSI zeggen:
ZFS kopieer even block x t/m y, naar z. Dat is een commando van 1KB, wat 18GB aan writes opleverd.

Dan zou mijn SLOG (die ik niet heb) toch wel even aan het werk gaan.

EDIT:
Hier een blogje die er iets dieper op in gaat:
https://blogs.oracle.com/realneel/entry/the_zfs_intent_log

Ik weet niet of mijn antwoord nog stand houdt, want ik lees hier dat het vooral om de grootte van de write gaat of deze direct weggeschreven wordt, en niet perse de re-ordering. Kan aan mij liggen, dacht dat ik dat ooit eens ergens gelezen heb

[ Voor 14% gewijzigd door FireDrunk op 21-03-2017 09:43 ]

[CurlyMo]

Wat is nu de beste manier om de SLOG te benchmarken over NFS? Ik heb nu een Intel S3700 in mijn NAS en een Crucial MX100. Nu ben ik benieuwd of de S3700 zijn naam als perfecte SLOG (na de Zeusram) waar maakt.

De sysbenches die ik hier vind geven niet dat enorme verschil als in de tabellen zichtbaar:
https://b3n.org/ssd-zfs-z...crucial-mx100-comparison/

code:

# rndwr (over NFS)
No SLOG                 116.2555s     1.3440Mb/sec
No SYNC                   1.6957s    92.1470Mb/sec
MX100 Virtual             3.9452s    39.6050Mb/sec
2 MX100 Virtual           4.1809s    37.3730Mb/sec
SLOG S3700 200GB          3.9577s    39.4800Mb/sec

# seqwr (over NFS)
No SLOG                  21.3898s   287.2400Mb/sec
No SYNC                  15.9038s   386.3200Mb/sec
MX100 Virtual            49.9184s   123.0800Mb/sec
2 MX100 Virtual          55.4818s   110.7400Mb/sec
SLOG S3700 200GB         23.5827s   260.5300Mb/sec

# rndrw (over NFS)
No SLOG                  49.6282s     3.1484Mb/sec
No SYNC                   1.9587s    79.7710Mb/sec
MX100 Virtual             2.7613s    56.5850Mb/sec
2 MX100 Virtual           2.4574s    63.5840Mb/sec
SLOG S3700 200GB          2.5412s    61.4860Mb/sec

# DB 2T
No SLOG                  60.0704s    R/W Req.  1508.73 per sec.
No SYNC                   6.6713s    R/W Req. 28480.16 per sec.
MX100 Virtual             8.7563s    R/W Req. 21698.71 per sec.
2 MX100 Virtual           9.2502s    R/W Req. 20540.12 per sec.
SLOG S3700 200GB          7.7548s    R/W Req. 24501.00 per sec.

# DB 4T
No SLOG                  60.0329s    R/W Req.  2719.62 per sec.
No SYNC                   3.6239s    R/W Req. 52429.27 per sec
MX100 Virtual             6.0595s    R/W Req. 31365.01 per sec.
2 MX100 Virtual           6.4608s    R/W Req. 29422.79 per sec.
SLOG S3700 200GB          4.1187s    R/W Req. 46130.85 per sec.

Het enige echte verschil is te zien in de database 4 threads test. Daarin scoort de S3700 vele malen beter dan de MX100.

[FireDrunk]

Heb je getuned aan de zfs property Logbias? En heb je iets veranderd aan de transaction timeouts en of transaction group sizes? Kan ook nog uitmaken.

Hoe groter (en langer) de transaction, hoe meer nut de slog heeft.

[CurlyMo]

FireDrunk schreef op donderdag 30 maart 2017 @ 09:51:
Heb je getuned aan de zfs property Logbias? En heb je iets veranderd aan de transaction timeouts en of transaction group sizes? Kan ook nog uitmaken.

Hoe groter (en langer) de transaction, hoe meer nut de slog heeft.

What? Nee, niks aan gedaan.

Na wat ingelezen te hebben zie ik dat logbias standaard op latency staat wat het dus ook moet zijn.

Verder zie ik in dit topc een sysctl van jou staan. Zou dat een mooi begin zijn?

FireDrunk in "Het grote ZFS topic"

[FireDrunk]

Dat kan je proberen, ik gebruik die instellingen momenteel niet, ze zijn mogelijk verouderd.

[Q]

Ik weet niet of iemand dit boeit, maar ik deel het toch.

https://www.sebastien-han...able-as-a-journal-device/

Dit gaat over SSDs die het beste geschikt zijn voor CEPH, maar ik denk dat het ook relevant is voor ZFS.

Kern van het verhaal: veel consumer SSDs zoals die van Crucial zijn super kut qua prestaties als je IO queue depth 1 is. Die gave SSD performance krijg je pas als je dingen doet die een hogere queue depth veroorzaakt.

Misschien is dat ook iets om stil bij te staan als je een SSD kiest voor toepassing met ZFS.

[GioStyle]

Ik heb voor mijn degraded array een nieuwe schijf op de kop kunnen tikken.

Vervolgens de commando 'zpool replace zpool name old disk new disk' erop los gelaten.

Paar uurtjes laten resilveren en mijn array is weer helemaal goed.

ZFS.

[Q]

GioStyle schreef op zaterdag 1 april 2017 @ 08:16:
Paar uurtjes laten resilveren en mijn array is weer helemaal goed.

ZFS.

Dat zou ook vast goed gegaan zijn met enige andere RAID technologie.

[CurlyMo]

Q schreef op zaterdag 1 april 2017 @ 09:23:
[...]


Dat zou ook vast goed gegaan zijn met enige andere RAID technologie.

Ondanks dat je vaak gelijk hebt in je nuanceringen kan je toch niet ontkennen dat het met ZFS wel allemaal erg gemakkelijk gaat. Afgezet tegen mijn kennis van mdadm, hardware raid (Areca) en BTRFS.

[A1AD]

Q schreef op zaterdag 1 april 2017 @ 09:23:
[...]
Dat zou ook vast goed gegaan zijn met enige andere RAID technologie.

Zolang je huidige schijven geen gebreken (current pending sectors) kennen heb ik mij laten wijsmaken.

[Q]

Als je braaf periodiek scubs draait, wat verstandig is voor iedere RAID array ongeacht de technologie, is die kans erg klein dat je tijdens een rebuild last krijgt van een bad sector die roet in het eten gooit.

Maar het proces met ZFS is redelijk makkelijk, true!

[ Voor 11% gewijzigd door Q op 01-04-2017 22:02 ]

[FireDrunk]

Volgens mij doet MDADM nog steeds geen checksums over de parity, dus wordt er altijd blindelings vanuit gegaan dat je data correct is, en de parity fout, waardoor je zelfs bij het tegenkomen van een corrupte sector tijdens je scrub de mist in gaat omdat er foutieve parity weggeschreven wordt.

Dus nee, andere RAID engines kunnen dat niet net zo goed

[Q]

FireDrunk schreef op zondag 2 april 2017 @ 00:55:
Volgens mij doet MDADM nog steeds geen checksums over de parity, dus wordt er altijd blindelings vanuit gegaan dat je data correct is, en de parity fout, waardoor je zelfs bij het tegenkomen van een corrupte sector tijdens je scrub de mist in gaat omdat er foutieve parity weggeschreven wordt.

Dus nee, andere RAID engines kunnen dat niet net zo goed

Een bad sector in data of parity is geen probleem, dat is waar RAID voor is gemaakt ongeacht welk smaakje.

Silent data corruptie natuurlijk wel, ZFS beschermt daar wel tegen, maar ik maak de weddenschap dat 99.999% van de mensen die ZFS draait nog nooit 'echte' silent data corruptie heeft meegemaakt. Dus 'silent' data corruptie door de storage laag.

Dus een reguliere rebuild - door een falende schijf zoals hierboven geïllustreerd - zonder 'silent' data corruptie, wat in 99.9999999% van de gevallen de situatie is, zal nooit een probleem zijn voor een willekeurige RAID oplossing.

Daarin zal ZFS zich niet onderscheiden.

Mocht je array al degraded zijn en je loopt tegen een bad sector aan op de overgebleven disks, dan denk ik dat ZFS daar inderdaad wel beter en makkelijker mee om zal gaan. Met MDADM kun je nog wel achterhalen welke data mogelijk corrupt is geraakt. Maar dat kost veel werk. Echter, zeer weinig mensen zullen deze situatie mee maken.

[ Voor 13% gewijzigd door Q op 02-04-2017 03:46 ]

[Bigs]

CurlyMo schreef op zaterdag 1 april 2017 @ 10:04:
[...]

Ondanks dat je vaak gelijk hebt in je nuanceringen kan je toch niet ontkennen dat het met ZFS wel allemaal erg gemakkelijk gaat. Afgezet tegen mijn kennis van mdadm, hardware raid (Areca) en BTRFS.

Mwa bij hardware RAID hoef je tenminste niet eerst je schijf te partitioneren voordat hij weer in je array/pool kan ZFS is leuk maar je ervaring is echt niet heel bijzonder hoor

[CurlyMo]

Bigs schreef op zondag 2 april 2017 @ 08:53:
[...]


Mwa bij hardware RAID hoef je tenminste niet eerst je schijf te partitioneren voordat hij weer in je array/pool kan ZFS is leuk maar je ervaring is echt niet heel bijzonder hoor

Maar een hardware RAID zal je hele schijf resilveren, terwijl ZFS alleen de gebruikte blokken doet. Dat scheelt nogal bij 8TB waarvan maar 2TB in gebruik is.

[Q]

Snellere rebuild tijden ten opzichte van andere RAID oplossingen - afhankelijk van de hoeveelheid data - is een pluspunt voor ZFS.

Naar mijn weten heb ik nooit handmatig een schijf hoeven te partitioneren voordat ik 'm kon gebruiken met ZFS, volgens mij ging dat automagisch.

[GioStyle]

Ik wilde helemaal geen discussie starten, maar ik wilde wel vermelden dat ik blij ben dat een leek zoals ik mijn data goed kan beschermen en dat zfs voor mij de manier is die mij daarbij helpt.

Dat was in mijn jongere jaren weleens anders: user errors zoals geen backups maken, kortsluiting veroorzaken, per ongeluk verkeerde schijf formatteren..

[WeaZuL]

Ok ik ben wat aan het testen met mijn ZFS config onder linux (Debian) en nu liep ik tegen pveperf aan. Ik heb het OS op local storage (ext4) staan, een Samsung 950 pro m2 NMVE 512GB en een ZFS data pool tank1 bestaande uit 6x ST1000LM024 1TB laptop schijven in mirrored ZFS vdev. Moederboard is een [url="https://http://www.fujitsu.com/fts/products/computing/peripheral/mainboards/extended-lifecycle-main/pmod-177972.html"]D3417-B van Fujistu met een Intel® C236 Express Chipset[/url] met 64GB ECC RAM. Details:

root@pve:~# zpool status tank1
  pool: tank1
 state: ONLINE
  scan: scrub repaired 0 in 0h2m with 0 errors on Sun Mar 12 00:26:18 2017
config:

	NAME                                           STATE     READ WRITE CKSUM
	tank1                                          ONLINE       0     0     0
	  mirror-0                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9FH202074  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S2WZJ90CA32577  ONLINE       0     0     0
	  mirror-1                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202905  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202934  ONLINE       0     0     0
	  mirror-2                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202937  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9FH202073  ONLINE       0     0     0

root@pve:~# zpool list tank1
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank1  2.72T  12.8G  2.71T         -     0%     0%  1.00x  ONLINE  -

root@pve:~# pveperf /tank1
CPU BOGOMIPS:      30335.04
REGEX/SECOND:      3230908
HD SIZE:           2684.18 GB (tank1)
FSYNCS/SECOND:     114.75
DNS EXT:           20.32 ms
DNS INT:           3.48 ms 

Vervolgens was ik aan het rondneuzen op google op "low fsync zfs" en kwam de volgende tip tegen:

set sync = disabled on the pools

Dus ik gedaan:

zfs set sync=disabled tank1

en vervolgens een pveperf eroverheen:

root@pve:~# pveperf /tank1
CPU BOGOMIPS:      30335.04
REGEX/SECOND:      3166710
HD SIZE:           2684.18 GB (tank1)
FSYNCS/SECOND:     45868.35
DNS EXT:           37.11 ms
DNS INT:           4.89 ms (onderdijk.io)

Wat zegt dit mij nu, ik ben een beginner met ZFS maar wil toch ff verifieeren of dat de lage fsyncs nu enkel aan de hardware te wijten is of aan een verkeerde config/setup

Wellicht moet ik mij inlezen aangaande het onderwerp SLOG

[ Voor 27% gewijzigd door WeaZuL op 02-04-2017 22:24 ]

[A1AD]

WeaZuL schreef op zondag 2 april 2017 @ 21:59:
Ok ik ben wat aan het testen met mijn ZFS config onder linux (Debian) en nu liep ik tegen pveperf aan. Ik heb het OS op local storage (ext4) staan, een Samsung 950 pro m2 NMVE 512GB en een ZFS data pool tank1 bestaande uit 6x ST1000LM024 1TB laptop schijven in mirrored ZFS vdev. Moederboard is een [url="https://http://www.fujitsu.com/fts/products/computing/peripheral/mainboards/extended-lifecycle-main/pmod-177972.html"]D3417-B van Fujistu met een Intel® C236 Express Chipset[/url] met 64GB ECC RAM. Details:

root@pve:~# zpool status tank1
  pool: tank1
 state: ONLINE
  scan: scrub repaired 0 in 0h2m with 0 errors on Sun Mar 12 00:26:18 2017
config:

	NAME                                           STATE     READ WRITE CKSUM
	tank1                                          ONLINE       0     0     0
	  mirror-0                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9FH202074  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S2WZJ90CA32577  ONLINE       0     0     0
	  mirror-1                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202905  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202934  ONLINE       0     0     0
	  mirror-2                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202937  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9FH202073  ONLINE       0     0     0

root@pve:~# zpool list tank1
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank1  2.72T  12.8G  2.71T         -     0%     0%  1.00x  ONLINE  -

root@pve:~# pveperf /tank1
CPU BOGOMIPS:      30335.04
REGEX/SECOND:      3230908
HD SIZE:           2684.18 GB (tank1)
FSYNCS/SECOND:     114.75
DNS EXT:           20.32 ms
DNS INT:           3.48 ms 

Vervolgens was ik aan het rondneuzen op google op "low fsync zfs" en kwam de volgende tip tegen:

set sync = disabled on the pools

Dus ik gedaan:

zfs set sync=disabled tank1

en vervolgens een pveperf eroverheen:

root@pve:~# pveperf /tank1
CPU BOGOMIPS:      30335.04
REGEX/SECOND:      3166710
HD SIZE:           2684.18 GB (tank1)
FSYNCS/SECOND:     45868.35
DNS EXT:           37.11 ms
DNS INT:           4.89 ms (onderdijk.io)

Wat zegt dit mij nu, ik ben een beginner met ZFS maar wil toch ff verifieeren of dat de lage fsyncs nu enkel aan de hardware te wijten is of aan een verkeerde config/setup

Wellicht moet ik mij inlezen aangaande het onderwerp SLOG

https://forum.proxmox.com...rformance-with-zfs.21568/

PS: enkel proxmox gebruikers kennen: pveperf

[WeaZuL]

A1AD schreef op zondag 2 april 2017 @ 22:27:
[...]


https://forum.proxmox.com...rformance-with-zfs.21568/

PS: enkel proxmox gebruikers kennen: pveperf

Helder, ik heb SLOG aangezet, hoe wordt performance van een zfspool normaliter gemeten?

root@pve:/# zpool status tank1
  pool: tank1
 state: ONLINE
  scan: scrub repaired 0 in 0h2m with 0 errors on Sun Mar 12 00:26:18 2017
config:

	NAME                                           STATE     READ WRITE CKSUM
	tank1                                          ONLINE       0     0     0
	  mirror-0                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9FH202074  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S2WZJ90CA32577  ONLINE       0     0     0
	  mirror-1                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202905  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202934  ONLINE       0     0     0
	  mirror-2                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202937  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9FH202073  ONLINE       0     0     0
	logs
	  SLOG                                         ONLINE       0     0     0

errors: No known data errors
root@pve:/# zfs get sync tank1
NAME   PROPERTY  VALUE     SOURCE
tank1  sync      standard  local

Ook heb ik lz4 compressie enabled en krijg nu de volgende waarden. Volgens mij moet ik het hiermee doen, iemand nog tips?

root@pve:~# bonnie++ -u root -r 1024 -s 16384 -d /tank1 -f -b -n 1 -c 4
Using uid:0, gid:0.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   4     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
pve             16G           1441293  87 1229146  98           4480053  99 13507  69
Latency                       21790us    5472us                67us   11978us
Version  1.97       ------Sequential Create------ --------Random Create--------
pve                 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  1   584   3 +++++ +++   571   3   579   2 +++++ +++   586   3
Latency             10997us      53us    7519us    7531us       4us    7454us
1.97,1.97,pve,4,1491188568,16G,,,,1441293,87,1229146,98,,,4480053,99,13507,69,1,,,,,584,3,+++++,+++,571,3,579,2,+++++,+++,586,3,,21790us,5472us,,67us,11978us,10997us,53us,7519us,7531us,4us,7454us

root@pve:~# pveperf /tank1
CPU BOGOMIPS:      30335.56
REGEX/SECOND:      3214920
HD SIZE:           2684.19 GB (tank1)
FSYNCS/SECOND:     578.35

root@pve:~# zfs get all tank1
NAME   PROPERTY              VALUE                  SOURCE
tank1  type                  filesystem             -
tank1  creation              Fri Mar  3 23:36 2017  -
tank1  used                  12.8G                  -
tank1  available             2.62T                  -
tank1  referenced            112K                   -
tank1  compressratio         1.00x                  -
tank1  mounted               yes                    -
tank1  quota                 none                   default
tank1  reservation           none                   default
tank1  recordsize            128K                   default
tank1  mountpoint            /tank1                 default
tank1  sharenfs              off                    default
tank1  checksum              on                     default
tank1  compression           lz4                    local
tank1  atime                 on                     default
tank1  devices               on                     default
tank1  exec                  on                     default
tank1  setuid                on                     default
tank1  readonly              off                    default
tank1  zoned                 off                    default
tank1  snapdir               hidden                 default
tank1  aclinherit            restricted             default
tank1  canmount              on                     default
tank1  xattr                 on                     default
tank1  copies                1                      default
tank1  version               5                      -
tank1  utf8only              off                    -
tank1  normalization         none                   -
tank1  casesensitivity       sensitive              -
tank1  vscan                 off                    default
tank1  nbmand                off                    default
tank1  sharesmb              off                    default
tank1  refquota              none                   default
tank1  refreservation        none                   default
tank1  primarycache          all                    default
tank1  secondarycache        all                    default
tank1  usedbysnapshots       0                      -
tank1  usedbydataset         112K                   -
tank1  usedbychildren        12.8G                  -
tank1  usedbyrefreservation  0                      -
tank1  logbias               latency                default
tank1  dedup                 off                    default
tank1  mlslabel              none                   default
tank1  sync                  standard               local
tank1  refcompressratio      1.00x                  -
tank1  written               112K                   -
tank1  logicalused           12.3G                  -
tank1  logicalreferenced     48K                    -
tank1  filesystem_limit      none                   default
tank1  snapshot_limit        none                   default
tank1  filesystem_count      none                   default
tank1  snapshot_count        none                   default
tank1  snapdev               hidden                 default
tank1  acltype               off                    default
tank1  context               none                   default
tank1  fscontext             none                   default
tank1  defcontext            none                   default
tank1  rootcontext           none                   default
tank1  relatime              off                    default
tank1  redundant_metadata    all                    default
tank1  overlay               off                    default

[ Voor 63% gewijzigd door WeaZuL op 03-04-2017 10:04 ]

[Q]

Ik vind bonnie++ een kut benchmark tool, ik zou naar fio kijken en daarmee testen, mits je ZFS met aio support draait om een goed gevoel te krijgen.

Maar wat voor performance zoek je? Ga je VMs draaien?

[WeaZuL]

Q schreef op maandag 3 april 2017 @ 21:06:
Ik vind bonnie++ een kut benchmark tool, ik zou naar fio kijken en daarmee testen, mits je ZFS met aio support draait om een goed gevoel te krijgen.

Maar wat voor performance zoek je? Ga je VMs draaien?

Dat is duidelijk, ja toepassing icm vm's het is proxmox ik heb nu een aantal lxc's draaien.

Ik ben niet op zoek naar een goed gevoel, ik ben op zoek naar een goed geconfigureerde server. ZFS is nieuw voor mij, ik wil geen gruwelijke mb/sec cijfers, ik wil goed performande vm's / containers, als fio mij daarbij helpt, swat.

edit:
[cmd]
root@pve:/tank1# fio --randrepeat=1 --ioengine=libaio --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.1.11
Starting 1 process
[.....]
test: (groupid=0, jobs=1): err= 0: pid=26750: Tue Apr 4 10:26:58 2017
read : io=3071.7MB, bw=43020KB/s, iops=10755, runt= 73114msec
write: io=1024.4MB, bw=14346KB/s, iops=3586, runt= 73114msec
cpu : usr=0.74%, sys=6.94%, ctx=6860, majf=0, minf=5
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
READ: io=3071.7MB, aggrb=43020KB/s, minb=43020KB/s, maxb=43020KB/s, mint=73114msec, maxt=73114msec
WRITE: io=1024.4MB, aggrb=14346KB/s, minb=14346KB/s, maxb=14346KB/s, mint=73114msec, maxt=73114msec[/cmd]

[ Voor 48% gewijzigd door WeaZuL op 04-04-2017 10:33 ]

[Wiebeltje]

Ik wil een disk replacen van mijn zpool omdat die stuk aan het gaan is maar ik weet niet 100% zeker hoe ik het aan moet pakken. Mijn pool wil ik natuurlijk niet slopen. Deze mirror is destijds aangemaakt in ZFS Guru. Inmiddels draai ik ZoL onder Proxmox. De disk die ik wil vervangen is ata-WDC_WD30EZRX-00AZ6B0_WD-WCC070360664.

zpool status
  pool: datapool
 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: scrub repaired 73.5M in 10h39m with 0 errors on Sat Apr  1 11:40:09 2017
config:

	NAME                                          STATE     READ WRITE CKSUM
	datapool                                      ONLINE       0     0     0
	  mirror-0                                    ONLINE       0     0     0
	    ata-WDC_WD30EZRX-00DC0B0_WD-WMC1T4026218  ONLINE       0     0     0
	    ata-WDC_WD30EZRX-00AZ6B0_WD-WCC070360664  ONLINE       0     0     0
	cache
	  zfs-cache                                   ONLINE       0     0     0

Dit is de partitietabel onder fdisk

Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 155CA2DA-35C9-11E3-A984-BC5FF4C9AE14

Device     Start        End    Sectors  Size Type
/dev/sdb1     34        545        512  256K FreeBSD boot
/dev/sdb2    552 5860533127 5860532576  2.7T FreeBSD ZFS

Partition 2 does not start on physical sector boundary.

En deze onder parted

(parted) print                                                            
Model: ATA WDC WD30EZRX-00A (scsi)
Disk /dev/sdb: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start  End          Size         File system  Name   Flags
 1      34s    545s         512s
 2      552s   5860533127s  5860532576s  zfs          disk2

Nu dacht ik dat ik mijn mirror destijds aangemaakt had op basis van de partitie naam: disk1, disk2. Het ID van de drive bij "zpool status" verwijst echter direct naar /dev/sdb.

/dev/disk/by-id/ata-WDC_WD30EZRX-00AZ6B0_WD-WCC070360664 -> ../../sdb

disk1 en disk2 verwijzen natuurlijk naar mijn partities

root@pve:/dev/disk/by-partlabel# ls -al
total 0
drwxr-xr-x 2 root root 100 Apr  4 18:09 .
drwxr-xr-x 6 root root 120 Apr  4 17:40 ..
lrwxrwxrwx 1 root root  10 Apr  4 18:07 disk1 -> ../../sdc2
lrwxrwxrwx 1 root root  10 Apr  4 18:40 disk2 -> ../../sdb2
lrwxrwxrwx 1 root root  10 Apr  4 18:07 zfs-cache -> ../../sda4

Ik heb geprobeerd om exact dezelfde partitietabel aan te maken op de nieuwe disk maar dit lukt voor geen meter. Niet met (s)fdisk en niet met parted. Waarschijnlijk toch een stukje incompatibiliteit tussen FreeBSD en Linux?

Kan ik deze disk nu toch simpelweg vervangen door het volgende uit te voeren of gaat het dan toch niet helemaal lekker omdat ik met die partitie zit?

zpool replace datapool ata-WDC_WD30EZRX-00AZ6B0_WD-WCC070360664 /dev/sdd

edit: zdb dump:

root@pve:~# zdb
datapool:
    version: 28
    name: 'datapool'
    state: 0
    txg: 15665701
    pool_guid: 4573242180056308410
    errata: 0
    hostid: 2831164162
    hostname: 'pve'
    vdev_children: 1
    vdev_tree:
        type: 'root'
        id: 0
        guid: 4573242180056308410
        children[0]:
            type: 'mirror'
            id: 0
            guid: 103775499775148702
            metaslab_array: 30
            metaslab_shift: 34
            ashift: 12
            asize: 3000587780096
            is_log: 0
            create_txg: 4
            children[0]:
                type: 'disk'
                id: 0
                guid: 5772089663749954631
                path: '/dev/disk/by-id/ata-WDC_WD30EZRX-00DC0B0_WD-WMC1T4026218-part2'
                phys_path: '/dev/gpt/hdd1'
                whole_disk: 1
                DTL: 129
                create_txg: 4
            children[1]:
                type: 'disk'
                id: 1
                guid: 15296293973782647703
                path: '/dev/disk/by-id/ata-WDC_WD30EZRX-00AZ6B0_WD-WCC070360664-part2'
                phys_path: '/dev/gpt/hdd2'
                whole_disk: 1
                DTL: 128
                create_txg: 4

[ Voor 16% gewijzigd door Wiebeltje op 04-04-2017 20:46 ]

[Q]

WeaZuL schreef op maandag 3 april 2017 @ 21:34:
[...]


Dat is duidelijk, ja toepassing icm vm's het is proxmox ik heb nu een aantal lxc's draaien.

Ik ben niet op zoek naar een goed gevoel, ik ben op zoek naar een goed geconfigureerde server. ZFS is nieuw voor mij, ik wil geen gruwelijke mb/sec cijfers, ik wil goed performande vm's / containers, als fio mij daarbij helpt, swat.

edit:
[cmd]
root@pve:/tank1# fio --randrepeat=1 --ioengine=libaio --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.1.11
Starting 1 process
[.....]
test: (groupid=0, jobs=1): err= 0: pid=26750: Tue Apr 4 10:26:58 2017
read : io=3071.7MB, bw=43020KB/s, iops=10755, runt= 73114msec
write: io=1024.4MB, bw=14346KB/s, iops=3586, runt= 73114msec
cpu : usr=0.74%, sys=6.94%, ctx=6860, majf=0, minf=5
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
READ: io=3071.7MB, aggrb=43020KB/s, minb=43020KB/s, maxb=43020KB/s, mint=73114msec, maxt=73114msec
WRITE: io=1024.4MB, aggrb=14346KB/s, minb=14346KB/s, maxb=14346KB/s, mint=73114msec, maxt=73114msec[/cmd]

Ik vind je test file veel te klein (4GB) ik zou minstends 100GB pakken om echt gevoel te krijgen.
een queue depth van 64 is ook niet realistisch, test maar eens met 1,2, 4 en 8.
In de output zie ik geen latency stats.

[JForceDesigns]

Beste tweakers...inmiddels draai ik enkele maanden met de zelf gebouwde FreeNAS server. Ik kan vanuit mijn verschillende windows machines bij de FreeNAS, kan bestanden daardoor centraal opslaan en kan de FreeNAS mijn usenetverkeer laten uitvoeren. Ik update iedere maand het systeem en tot de laatste update kon ik ook vanuit mijn mede8er de videobestanden bekijken die ik daarvoor betreffende share heb staan. Echter sinds de laatste update van FreeNAS krijg ik een continue login fail. Ik heb inmiddels de mede8er voorzien van de meest recente firmware, de FreeNAS een reboot gegeven, alle instellingen door gezocht maar ik krijg niks gevonden wat het kan zijn waarom de mediaspeler niet langer de FreeNAS mag benaderen. Voor de volledigheid ik zie de FreeNAS server, kan de share ook zien maar niet benaderen. Ik heb werkelijk geen idee hoe ik dit aan de praat krijg en hoop dat dit de juiste plek is om deze vraag te stellen.

[WeaZuL]

Q schreef op dinsdag 4 april 2017 @ 20:40:
[...]


Ik vind je test file veel te klein (4GB) ik zou minstends 100GB pakken om echt gevoel te krijgen.
een queue depth van 64 is ook niet realistisch, test maar eens met 1,2, 4 en 8.
In de output zie ik geen latency stats.

Is goed, ik kom over 5 dagen terug met de resultaten!

[Kuusj]

Lekker, weer een poging om de thuisserver aan de gang te krijgen (ditmaal gewacht tot de Corral release), lukt het wéér niet

En deze keer weer eens lekker simpele reden: ik kom in het installatiemenu (Install/Upgrade, Shell, Reboot, Shutdown, Exit), en kan op Enter blijven rammen tot ik een ons weeg, hij gaat gewoon niet verder. De rest doet hij wel, mijn Enter is dus niet kapot

Heb extra voor FreeNAS 2 nieuwe USB's gekocht, Sandisk 16GB USB3.0 schijfjes. Heb de ISO al 3x opnieuw op de USB gezet. Iemand een idee? Begin langzaam wel de hoop te verliezen in het o zo geweldige NAS zelfbouw project...

[GioStyle]

Zoiets heb ik in een ver verleden ook meegemaakt. Bij mij was de oplossing een andere usb stick gebruiken of een ander programma gebruiken om de iso op usb te zetten.

[FREAKJAM]

kuusj98 schreef op woensdag 12 april 2017 @ 02:14:
Lekker, weer een poging om de thuisserver aan de gang te krijgen (ditmaal gewacht tot de Corral release), lukt het wéér niet

En deze keer weer eens lekker simpele reden: ik kom in het installatiemenu (Install/Upgrade, Shell, Reboot, Shutdown, Exit), en kan op Enter blijven rammen tot ik een ons weeg, hij gaat gewoon niet verder. De rest doet hij wel, mijn Enter is dus niet kapot

Heb extra voor FreeNAS 2 nieuwe USB's gekocht, Sandisk 16GB USB3.0 schijfjes. Heb de ISO al 3x opnieuw op de USB gezet. Iemand een idee? Begin langzaam wel de hoop te verliezen in het o zo geweldige NAS zelfbouw project...

Het issue wat je omschrijft, wordt hier ook beschreven. Workaround is eerst versie 10.0.2 installeren en vanuit de webpagina upgraden. Verder is de downloadpagina aangepast en Corral gemarkeerd als "Not ready for production", dus wellicht toch nog wat langer wachten tot een betere stable build. Het schijnt nog aardig buggy te zijn.

[ Voor 35% gewijzigd door FREAKJAM op 12-04-2017 11:45 ]

[Kuusj]

FREAKJAM schreef op woensdag 12 april 2017 @ 11:40:
[...]


Het issue wat je omschrijft, wordt hier ook beschreven. Workaround is eerst versie 10.0.2 installeren en vanuit de webpagina upgraden. Verder is de downloadpagina aangepast en Corral gemarkeerd als "Not ready for production", dus wellicht toch nog wat langer wachten tot een betere stable build. Het schijnt nog aardig buggy te zijn.

Thanks dat het buggy is ben ik helaas ook al aardig mee bekend Het probleem is dat 9.X niet op Kaby Lake CPU's werkt, of dat moet nu opgelost zijn...

[CurlyMo]

Onlangs heb is mijn on-site backup (USB HDD) kapot gegaan door een stroomuitval. Nu probeer ik al een tijdje de on-site backup te herstellen met de offsite backup. Nu ik daar mee bezig ben zie ik echter steeds vaker kernel panics langskomen:


De betreffende pool wordt zo geïnitialiseerd:

code:

zpool set feature@async_destroy=enabled backup
zpool set feature@empty_bpobj=enabled backup
zpool set feature@lz4_compress=enabled backup
zpool set feature@enabled_txg=enabled backup
zpool set feature@hole_birth=enabled backup
zpool set feature@embedded_data=enabled backup
zfs set compression=lz4 backup
zfs set atime=off backup
zfs set dedup=on backup

Ik probeer nu weer even te draaien zonder backup schijf om te zien of die pool de oorzaak is, maar het is fijn om te weten waar het aan ligt zodat weer een betrouwbare on-site backup kan maken.

EDIT: Ik heb de USB HDD nu eens aan een aparte VM gekoppeld en daarbij krijg ik ongeveer 5 sec na het booten weer dezelfde kernel panics, terwijl mijn oorspronkelijke NAS VM lekker verder draait. Er lijkt dus iets raars aan de hand met die backup pool.

[ Voor 12% gewijzigd door CurlyMo op 17-04-2017 12:12 ]

[Verwijderd]

Welk OS? Heb je BSD 10.x of 11.x al geprobeerd?

[CurlyMo]

Ja, beide geprobeerd. Dedup lijkt de oorzaak te zijn, aangezien ddt staat voor deduplication table. Hier zijn dezelfde problemen te lezen (alhoewel al wat jaartjes terug):
https://github.com/zfsonlinux/zfs/issues/2839
http://marc.info/?l=zfs-discuss&m=133003639720587

Ik ben het nu eens op ZoL aan het proberen. Ik had al een deel van de offsite backup naar de onsite backup kunnen kopiëren. Misschien dat ik dat deel nog onsite -> onsite kan redden.

[ Voor 25% gewijzigd door CurlyMo op 17-04-2017 12:49 ]

[soulcrusher]

Ik heb een probleem met Transmission op mijn ZFSguru installatie. De Transmission daemon staat standaard ingesteld met een whitelist en als je via de ZFSguru gui naar de Transmission service gaat zou je ip toegevoegd moeten worden aan de whitelist. Nu heb ik al meerdere malen meegemaakt dat dit niet gebeurt en ik dus vanaf een bepaald ip geen toegang heb (en krijg) tot Transmission.

Ik kom er totaal niet uit waar de config files nu daadwerkelijk staan. De installatie dir is volgens ZFSguru: /services/transmission, maar het wijzigen van settings.json aldaar heeft geen invloed op de daemon (ik herstart de daemon na iedere wijziging). Via top zie ik dat de config dir /usr/local/etc/transmission/home is en in de settings.json aldaar zie ik dat er al ip adressen van andere pc's toe zijn gevoegd en dat andere settings juist staan. Het probleem hier is dat het geen zin heeft om extra ip's aan de whitelist in dit bestand toe te voegen want ze worden bij de herstart van de daemon weer teruggezet naar wat het voorheen was. Gek genoeg kan ik de download dir bijvoorbeeld wel gewoon aanpassen in dit bestand.

Ik heb toen geprobeerd mijn ip aan de whitelist toe te voegen en vervolgens het bestand read-only te maken, maar bij herstart van de deamon wordt het bestand weer read-write en wordt het ip adres weer weggehaald. Verder heb ik geprobeerd transmission-daemon -a 192.168.1.* uit te voeren maar dit wordt vervolgens niet in de whitelist gezet

Hoe kan ik nou in vredes naam een nieuw ip adres toevoegen, of die vervelende whitelist feature uitschakelen? Kan ik ergens de launch commando's van de transmission service aanpassen?

[Compizfox]

soulcrusher schreef op zondag 23 april 2017 @ 13:48:
Ik kom er totaal niet uit waar de config files nu daadwerkelijk staan. De installatie dir is volgens ZFSguru: /services/transmission, maar het wijzigen van settings.json aldaar heeft geen invloed op de daemon (ik herstart de daemon na iedere wijziging). Via top zie ik dat de config dir /usr/local/etc/transmission/home is en in de settings.json aldaar zie ik dat er al ip adressen van andere pc's toe zijn gevoegd en dat andere settings juist staan. Het probleem hier is dat het geen zin heeft om extra ip's aan de whitelist in dit bestand toe te voegen want ze worden bij de herstart van de daemon weer teruggezet naar wat het voorheen was. Gek genoeg kan ik de download dir bijvoorbeeld wel gewoon aanpassen in dit bestand.

De port van Transmission is vervelend in dat opzicht, ja. Het init-script override de config directory (wat al verwarrend genoeg is) maar override ook nog eens dingen zoals de download dir.

Als je de settings.json van Transmission moet aanpassen moet je eerst Transmission stoppen, dan je aanpassingen doen (en opslaan), en Transmission dan weer starten.

Maar goed, heeft vrij weinig met ZFS te maken

[soulcrusher]

Bedankt, het is gelukt. Dat ik daar niet zelf aan dacht, het klinkt zo logisch

De reden dat ik het hier post is omdat de meeste info over andere OS'en gaat en ik er daar niet mee uitkwam. Ik ging ervan uit dat bij ZFSguru het settings.json bestand ergens anders stond en met het startup script naar die folder gezet werd.

[CurlyMo]

Tijdens een scrub van mijn hoofd datapool zie ik de laatste week steeds vaker checksum errors langskomen en sinds gisteren heeft dit ook tot dataverlies geleid. De kabels heb ik al vervangen door nieuwe kabels. In de kernel logs is niks te vinden. Daarnaast treed dit probleem bij een scrub pas op tegen het eind. Het werken op de pool geeft ook zo nu en dan checksum errors. Is het daarmee aannemelijk geworden dat mijn geheugen aan het falen is? Of zijn er andere dingen die ik in de tussentijd nog kan uitsluiten?

Morgen heb ik weer beschikking over een oude backup systeem waarmee ik mijn datapool even kan inladen voor een nieuwe scrub. Dan kan ik op het andere systeem een memory test aanzetten. Mocht die nieuwe scrub geen fouten opleveren, dan is dat toch ook bewijs genoeg dat mijn geheugen faalt?

Het is overigens geen ECC geheugen. Mocht dit allemaal waar zijn, dan ga ik spoedig de huidige NAS vervangen (pas 3 jaar oud) door een nieuwe versie met ECC geheugen ondersteuning.

code:

  pool: data
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 688M in 6h26m with 1 errors on Wed Apr 26 13:24:40 2017
config:

        NAME                               STATE     READ WRITE CKSUM
        data                               ONLINE       0     0     0
          raidz2-0                         ONLINE       0     0     0
            diskid/DISK-WD-WCC4M7E57L60p1  ONLINE       0     0     0
            diskid/DISK-WD-WCC4M7E57JT9p1  ONLINE       0     0     0
            diskid/DISK-WD-WCC4M5YA8NY3p2  ONLINE       0     0     0
            diskid/DISK-WD-WCC4MPAH0T7Ep1  ONLINE       0     0     0
        logs
          mirror-1                         ONLINE       0     0     0
            label/data-log-ds1             ONLINE       0     0     0
            label/data-log-ds2             ONLINE       0     0     0

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

        /data/x-tools/freebsd/openwrt/build_dir/toolchain-arm_cortex-a8+vfpv3_gcc-5.3.0_musl-1.1.14_eabi/linux-4.4.7/drivers/scsi/bnx2i/bnx2i_hwi.c

[Q]

CurlyMo schreef op donderdag 27 april 2017 @ 15:57:
Tijdens een scrub van mijn hoofd datapool zie ik de laatste week steeds vaker checksum errors langskomen en sinds gisteren heeft dit ook tot dataverlies geleid. De kabels heb ik al vervangen door nieuwe kabels. In de kernel logs is niks te vinden. Daarnaast treed dit probleem bij een scrub pas op tegen het eind. Het werken op de pool geeft ook zo nu en dan checksum errors. Is het daarmee aannemelijk geworden dat mijn geheugen aan het falen is? Of zijn er andere dingen die ik in de tussentijd nog kan uitsluiten?

Morgen heb ik weer beschikking over een oude backup systeem waarmee ik mijn datapool even kan inladen voor een nieuwe scrub. Dan kan ik op het andere systeem een memory test aanzetten. Mocht die nieuwe scrub geen fouten opleveren, dan is dat toch ook bewijs genoeg dat mijn geheugen faalt?

Het is overigens geen ECC geheugen. Mocht dit allemaal waar zijn, dan ga ik spoedig de huidige NAS vervangen (pas 3 jaar oud) door een nieuwe versie met ECC geheugen ondersteuning.

code:

  pool: data
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 688M in 6h26m with 1 errors on Wed Apr 26 13:24:40 2017
config:

        NAME                               STATE     READ WRITE CKSUM
        data                               ONLINE       0     0     0
          raidz2-0                         ONLINE       0     0     0
            diskid/DISK-WD-WCC4M7E57L60p1  ONLINE       0     0     0
            diskid/DISK-WD-WCC4M7E57JT9p1  ONLINE       0     0     0
            diskid/DISK-WD-WCC4M5YA8NY3p2  ONLINE       0     0     0
            diskid/DISK-WD-WCC4MPAH0T7Ep1  ONLINE       0     0     0
        logs
          mirror-1                         ONLINE       0     0     0
            label/data-log-ds1             ONLINE       0     0     0
            label/data-log-ds2             ONLINE       0     0     0

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

        /data/x-tools/freebsd/openwrt/build_dir/toolchain-arm_cortex-a8+vfpv3_gcc-5.3.0_musl-1.1.14_eabi/linux-4.4.7/drivers/scsi/bnx2i/bnx2i_hwi.c

Ik zou even een nachtje een memtest draaien om je vermoeden te controleren en niet verder te draaien met je NAS. Dat was je al van plan.

Als je een nacht lang een memtest draait en je krijgt geen fouten te zien, dan weet ik nog zo net niet wat het probleem is.

[CurlyMo]

Q schreef op donderdag 27 april 2017 @ 15:59:
[...]
Als je een nacht lang een memtest draait en je krijgt geen fouten te zien, dan weet ik nog zo net niet wat het probleem is.

Standaard verhaal is elke keer kabels en geheugen. Kabels zijn al vervangen van alle schijven en alle schijven blijven fouten vertonen. Lijkt me sterk dat ze allemaal tegelijk aan het falen zijn.

[Q]

CurlyMo schreef op donderdag 27 april 2017 @ 16:06:
[...]

Standaard verhaal is elke keer kabels en geheugen. Kabels zijn al vervangen van alle schijven en alle schijven blijven fouten vertonen. Lijkt me sterk dat ze allemaal tegelijk aan het falen zijn.

Als je meerdere schijven had met issues dan was kabels vervangen eigenlijk bij voorbaat al niet nodig, flesje wijn op rot geheugen?

[CurlyMo]

Q schreef op donderdag 27 april 2017 @ 18:36:
[...]


Als je meerdere schijven had met issues dan was kabels vervangen eigenlijk bij voorbaat al niet nodig, flesje wijn op rot geheugen?

Niet als ik dit bij voorbaat zelf al vermoed. En die kabels had ik toch al nodig. Ik heb ze nu ingezet voor deze test.

Om even te illustreren hoe gaar de situatie is met die pool. Dit was na de laatste scrub:

code:

        NAME                               STATE     READ WRITE CKSUM
        data                               ONLINE       0     0     1
          raidz2-0                         ONLINE       0     0    11
            diskid/DISK-WD-WCC4M7E57L60p1  ONLINE       0     0 2.76K
            diskid/DISK-WD-WCC4M7E57JT9p1  ONLINE       0     0 2.77K
            diskid/DISK-WD-WCC4M5YA8NY3p2  ONLINE       0     0 2.85K
            diskid/DISK-WD-WCC4MPAH0T7Ep1  ONLINE       0     0 2.53K
        logs
          mirror-1                         ONLINE       0     0     0
            label/data-log-ds1             ONLINE       0     0     0
            label/data-log-ds2             ONLINE       0     0     0

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

Een leuk verhaal over het onderwerp:
http://jrs-s.net/2015/02/...n-ecc-ram-kill-your-data/

[ Voor 58% gewijzigd door CurlyMo op 27-04-2017 19:28 ]

[Q]

CurlyMo schreef op donderdag 27 april 2017 @ 18:45:
[...]

Niet als ik dit bij voorbaat zelf al vermoed. En die kabels had ik toch al nodig. Ik heb ze nu ingezet voor deze test.

Om even te illustreren hoe gaar de situatie is met die pool. Dit was na de laatste scrub:

code:

        NAME                               STATE     READ WRITE CKSUM
        data                               ONLINE       0     0     1
          raidz2-0                         ONLINE       0     0    11
            diskid/DISK-WD-WCC4M7E57L60p1  ONLINE       0     0 2.76K
            diskid/DISK-WD-WCC4M7E57JT9p1  ONLINE       0     0 2.77K
            diskid/DISK-WD-WCC4M5YA8NY3p2  ONLINE       0     0 2.85K
            diskid/DISK-WD-WCC4MPAH0T7Ep1  ONLINE       0     0 2.53K
        logs
          mirror-1                         ONLINE       0     0     0
            label/data-log-ds1             ONLINE       0     0     0
            label/data-log-ds2             ONLINE       0     0     0

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

Een leuk verhaal over het onderwerp:
http://jrs-s.net/2015/02/...n-ecc-ram-kill-your-data/

Het probleem is nu dat al je data dat is geschreven naar je NAS sinds je laatste goede scrub hebt uitgevoerd verdacht is en corrupted kan zijn.

Mogelijk dat je een lijst van files kunt maken die sinds de laatste scrub zijn aangemaakt of gemodificeerd en dan die data vergelijken met een betrouwbare kopie?

[CurlyMo]

Q schreef op donderdag 27 april 2017 @ 20:17:
[...]


Het probleem is nu dat al je data dat is geschreven naar je NAS sinds je laatste goede scrub hebt uitgevoerd verdacht is en corrupted kan zijn.

Mogelijk dat je een lijst van files kunt maken die sinds de laatste scrub zijn aangemaakt of gemodificeerd en dan die data vergelijken met een betrouwbare kopie?

Daar was ik inderdaad al op voorbereid. Er zijn genoeg snapshots, dus daar kan ik sowieso makkelijk naar terug.

Edit:
Binnen 1 minuut memtest86 al meer dan 12000 fouten. Dat is niet goed

[ Voor 7% gewijzigd door CurlyMo op 28-04-2017 00:47 ]

[Q]

CurlyMo schreef op donderdag 27 april 2017 @ 20:20:
[...]

Daar was ik inderdaad al op voorbereid. Er zijn genoeg snapshots, dus daar kan ik sowieso makkelijk naar terug.

Edit:
Binnen 1 minuut memtest86 al meer dan 12000 fouten. Dat is niet goed

Je weet het nu zeker, dat is een lichtpuntje. Je had het vast al zelf bedacht, maar trek even een van de dimm los en test opnieuw. Kun je even door draaien zonder het rotte geheugen.

[Pantagruel]

CurlyMo schreef op donderdag 27 april 2017 @ 20:20:
[...]

Daar was ik inderdaad al op voorbereid. Er zijn genoeg snapshots, dus daar kan ik sowieso makkelijk naar terug.

Edit:
Binnen 1 minuut memtest86 al meer dan 12000 fouten. Dat is niet goed

Dat kwalificeert wel als rot, gecondoleerd en idd (with stupid below ) dimmetje trekken en run herhalen met de resterende reepjes om je er van te verzekeren dat die nog goed functioneren.

[CurlyMo]

Ik heb twee 1150 systemen staan. Ik split het geheugen (2x 8GB) nu even over beide systemen om te zien of ze beide brak zijn of dat misschien het moederbord het probleem is. Waarschijnlijk niet, want de highest en lowest error address(es) liggen tussen de 8465MB en de 9471MB.

Samenvatting na 8 uur draaien en 6 iteraties:

Errors: 65535+
Test
0 0
1 39177
2 56053
3 65535+
4 65535+
5 65535+
6 65535+
7 65535+
8 65535+
9 65535+
10 64604

Dat verklaar waarschijnlijk ook waarom ik vorige week zo'n gezeik had met die backup schijf. Ook laat het mooi zien hoe het geheugen wordt gebruikt bij een scrub. Mijn datapool van 4TB 80% vol gaf bij een scrub continue foutmeldingen. Mijn backup pool (1TB 50% vol) en mijn zroot (16GB 50% vol) geen enkele.

Edit.

Oude test

Systeem 1: 2x 4GB geheugen in slot 1 en slot 2
Systeem 2: 2x 8GB geheugen in slot 1 en slot 2

Resultaten
- Systeem 1: 0 fouten
- Systeem 2: 65535+ fouten

Conclusie
Moederbord en geheugen systeem 1 werkt.
Moederbord en/of geheugen systeem 2 is brak.

Nieuwe test
Systeem 1: 1x 8GB in slot 2
Systeem 2: 1x 8GB slot 1 naar slot 2, 1x 4GB slot 1

1. Als nu systeem 1 fouten geeft dan weet ik dat dit het brakke geheugen is.
2. Als nu systeem 2 geen fouten geeft dan weet ik nog even niks.
3. Als nu systeem 2 wel fouten geeft boven de 8GB dan weet ik dat het ene geheugenreepje van 8GB brak is.
4. Als nu systeem 2 onder de 8GB fouten geeft dan weet ik nog even niks.
5. Als nu systeem 2 boven én onder de 8GB fouten geeft dan is zowel het moederbord als het geheugen brak.

In geval van uitkomsten 2 en 4 zal ik in systeem 2 alleen even de 8GB zelf moeten testen.

Edit.

Een van de twee 8GB geheugenbankjes is inderdaad kapot. Nu even aan het draaien op 1x 8GB + 1x 4GB. Opnieuw een scrub gedraaid, rond de 60 checksum errors per disk en 15.1M reparaties, maar de data corruptie is weer opgelost. Nu kijken of alle checksums op 0 blijven bij een tweede scrub. Dat de datacorruptie weer is opgelost is in ieder geval een goed teken.

Nu de tweede scrub afwachten en wanneer deze goed is dan kan ik alle nieuwe en gewijzigde bestanden van de laatste twee weken gaan controleren.

Edit.
Tweede scrub geeft 0 errors Nu nog even dat lijstje maken ter controle van mogelijke corruptie bestanden na de laatste succesvolle scrub.

[ Voor 53% gewijzigd door CurlyMo op 29-04-2017 15:48 ]

[F-Tim]

Weet iemand dit? Als ik mijn draaiende ZFSGuru installatie upgrade (ik draai nu 10.2.006), reboot en van de nieuwste release versie (11.0.010) opstart, dan moet ik het ZFS deel opnieuw configureren (migration manager komt immers pas in een latere versie van ZFSGuru).

Maar hoe zit het met "overige" configuratie?
- Wat als ik een static IP heb geconfigureerd? /etc/rc.conf staat immers los van de installatie?
- Wat gebeurt er met mijn Plex data? Moet ik mijn library backuppen-restoren?
- Hoe zit het met andere packages die ik via portstree heb geinstalleerd (bv Webmin).
- Moet ik eigen cron jobs opnieuw definieren? (Heb er een draaien die wekelijks een scrub uitvoert)

Zoals ik het nu voor me zie is het als volgt:
- Inloggen op de Web UI van 10.2.006
- Upgraden naar 11.0.010
- Reboot
- Opnieuw inloggen op de Web UI van 11.0.010 (zelfde al dan niet andere IP)
- ZFS Pool importeren (alleen de /tank, niet de /zboot, anders kan ie immers niet booten)
- Users opnieuw aanmaken (zelfde naam/ww voor de gebruikers en dan is het goed? of moet ik ook even rechten opnieuw toekennen?)
- Plex service opnieuw installeren.

Heb er namelijk geen monitor aan hangen (die heb ik overigens momenteel even niet eens in huis), dus wil niet m'n NAS verpesten met een 'upgrade'

[WeaZuL]

Vandaag een test uitgevoerd door mijn zfs pool (3x 1TBx2 mirror vdev) met 1TB uit te breiden door 1 mirror vdev te vervangen door 2x 2TB schijven. Tussenstand:

root@pve:~# zpool status
  pool: tank1
 state: ONLINE
  scan: resilvered 570G in 1h56m with 0 errors on Tue May 30 18:48:37 2017
config:

	NAME                                           STATE     READ WRITE CKSUM
	tank1                                          ONLINE       0     0     0
	  mirror-0                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9FH202074  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S2WZJ90CA32577  ONLINE       0     0     0
	  mirror-1                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202905  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202934  ONLINE       0     0     0
	  mirror-2                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202937  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9HFC12477  ONLINE       0     0     0
	logs
	  slog                                         ONLINE       0     0     0

errors: No known data errors

Nu de andere 1TB schijf nog vervangen... Resilvering is klaar ... maar:

root@pve:~# zpool status tank1
  pool: tank1
 state: ONLINE
  scan: resilvered 570G in 2h3m with 0 errors on Tue May 30 22:17:26 2017
config:

	NAME                                           STATE     READ WRITE CKSUM
	tank1                                          ONLINE       0     0     0
	  mirror-0                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9FH202074  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S2WZJ90CA32577  ONLINE       0     0     0
	  mirror-1                                     ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202905  ONLINE       0     0     0
	    ata-ST1000LM024_HN-M101MBB_S31LJ9EH202934  ONLINE       0     0     0
	  mirror-2                                     ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S32WJ9DF614425  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9HFC12477  ONLINE       0     0     0
	logs
	  slog                                         ONLINE       0     0     0

errors: No known data errors

root@pve:~# zpool list
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank1  2.72T  1.89T   846G      932G    42%    69%  1.00x  ONLINE  -
root@pve:~# 

Hmm en nu

Ik heb het volgende geprobeerd maar dat haalde niets uit:

root@pve:~# zpool set autoexpand=on tank1

root@pve:~# zpool list
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank1  2.72T  1.89T   846G      932G    42%    69%  1.00x  ONLINE  -

Ah via docs.oracle.com liep ik tegen de oplossing aan. Ik zie dat ik de -e vergeten ben, maar vreemd genoeg werkte het wel?

root@pve:~# zpool online tank1 ata-ST2000LM003_HN-M201RAD_S32WJ9DF614425
root@pve:~# zpool online tank1 ata-ST2000LM003_HN-M201RAD_S34RJ9HFC12477
root@pve:~# zpool list
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank1  3.62T  1.89T  1.73T         -    31%    52%  1.00x  ONLINE  -

[ Voor 46% gewijzigd door WeaZuL op 30-05-2017 22:33 ]

[Vuurvoske]

Ik deed net een reinstall van zfsguru 11.1.010-STABLE
En het valt mij op dat ik ontzettend veel issues heb met het starten van de SAMBA service. Het frapante is dat ik daar (nog) niets over terug zie in de logs.

-edit:

in de 11.0.010-RELEASE heb ik deze issues niet.

[ Voor 12% gewijzigd door Vuurvoske op 15-06-2017 11:55 ]

[CurlyMo]

Vuurvoske schreef op donderdag 15 juni 2017 @ 11:45:
En het valt mij op dat ik ontzettend veel issues heb met het starten van de SAMBA service.

En die issues zijn....

[Vuurvoske]

CurlyMo schreef op donderdag 15 juni 2017 @ 14:49:
[...]

En die issues zijn....

Ik heb echt een schijthekel aan mensen die suggestief ... plaatsen. Heel irritant.
Maar dat terzijde. De service wil überhaupt niet starten.

[FireDrunk]

Dat suggestieve komt omdat wij geen kristallen bol hebben om te zien wat jouw foutmeldingen zijn.
Het is enigzins vervelend om wel dat soort posts te plaatsen, maar niet te laten zien wat er fout gaat.

We zijn allemaal bereid om je te helpen, maar alleen maar roepen dat iets niet start, schieten we niets mee op.

[Vuurvoske]

FireDrunk schreef op vrijdag 16 juni 2017 @ 11:07:
Dat suggestieve komt omdat wij geen kristallen bol hebben om te zien wat jouw foutmeldingen zijn.
Het is enigzins vervelend om wel dat soort posts te plaatsen, maar niet te laten zien wat er fout gaat.

We zijn allemaal bereid om je te helpen, maar alleen maar roepen dat iets niet start, schieten we niets mee op.

Het was ook eigenlijk meer bedoeld als bug-melding, curiositeit of er meer mensen dit probleem ondervonden. Middels een fallback heb ik het probleem kunnen oplossen.

Echter heb ik nu een andere mooie uitdaging. Het valt mij op dat ik na verloop van tijd (en bij het behoorlijk warm worden van de disks (+44C)). Ik de volgende meldingen krijg in mijn logs:

code:

Jun 20 22:26:12 zfsguru ZFS: vdev state changed, pool_guid=5950655075393918443 vdev_guid=7670955120241523930
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): SCSI status: Check Condition
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): SCSI sense: Vendor Specific asc:0,0 (No additional sense information)
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): SCSI status: Check Condition
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): SCSI sense: Vendor Specific asc:0,0 (No additional sense information)
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error
Jun 20 22:26:53 zfsguru ZFS: vdev state changed, pool_guid=5950655075393918443 vdev_guid=7670955120241523930
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): SCSI status: Check Condition
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): SCSI sense: Vendor Specific asc:0,0 (No additional sense information)
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error

Nu heb ik her en der soortgelijke bugmeldingen gevonden. Maar specifiek voor Error 5 niet.
Behalve een iemand die problemen had met een falende usb-stick.
Ik vrees ervoor dat er iets niet goed is met mijn moederbord.
De disks geven de onderstaande SMART status aan:



Ik zou graag wat tips krijgen over de herkomst van deze foutmelding.

[Pantagruel]

Vuurvoske schreef op dinsdag 20 juni 2017 @ 22:43:
[...]


Het was ook eigenlijk meer bedoeld als bug-melding, curiositeit of er meer mensen dit probleem ondervonden. Middels een fallback heb ik het probleem kunnen oplossen.

Maakt niet uit hoe je fikkie noemt, maar het is en blijft een uiterst magere melding.

Echter heb ik nu een andere mooie uitdaging. Het valt mij op dat ik na verloop van tijd (en bij het behoorlijk warm worden van de disks (+44C)). Ik de volgende meldingen krijg in mijn logs:

code:

Jun 20 22:26:12 zfsguru ZFS: vdev state changed, pool_guid=5950655075393918443 vdev_guid=7670955120241523930
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): SCSI status: Check Condition
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): SCSI sense: Vendor Specific asc:0,0 (No additional sense information)
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): SCSI status: Check Condition
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): SCSI sense: Vendor Specific asc:0,0 (No additional sense information)
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error
Jun 20 22:26:53 zfsguru ZFS: vdev state changed, pool_guid=5950655075393918443 vdev_guid=7670955120241523930
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): SCSI status: Check Condition
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): SCSI sense: Vendor Specific asc:0,0 (No additional sense information)
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error

Nu heb ik her en der soortgelijke bugmeldingen gevonden. Maar specifiek voor Error 5 niet.
Behalve een iemand die problemen had met een falende usb-stick.
Ik vrees ervoor dat er iets niet goed is met mijn moederbord.
De disks geven de onderstaande SMART status aan:

[afbeelding]

Ik zou graag wat tips krijgen over de herkomst van deze foutmelding.

Wellicht door de hitte bevangen, maar m'n kristallen bol werkt niet.

Als je een serieus antwoord verwacht dan zul je:

-1 Aan moeten geven onder welke omstandigheden je ZFSGuru gebruikt:
-a bare metal [zo ja welke hardware, etc]
-b virtual [zo ja welke virt omgeving en versie, passthrough,etc])

-2 Moeten laten merken dat je al wat Google-foo hebt losgelaten op de log data

Een log message van jouw strekking kwam ik tegen bij een virtueel draaiende (esxi) FreeNAS install

[Vuurvoske]

Pantagruel schreef op donderdag 22 juni 2017 @ 12:51:
[...]


Maakt niet uit hoe je fikkie noemt, maar het is en blijft een uiterst magere melding.


[...]


Wellicht door de hitte bevangen, maar m'n kristallen bol werkt niet.

Als je een serieus antwoord verwacht dan zul je:

-1 Aan moeten geven onder welke omstandigheden je ZFSGuru gebruikt:
-a bare metal [zo ja welke hardware, etc]
-b virtual [zo ja welke virt omgeving en versie, passthrough,etc])

-2 Moeten laten merken dat je al wat Google-foo hebt losgelaten op de log data

Een log message van jouw strekking kwam ik tegen bij een virtueel draaiende (esxi) FreeNAS install

Ik heb ZFSGURU geviritualiseerd in ESXI 6.5. Voorheen in proxmox 4.4.x, maar wegens freeze problemen overgestapt. Deze VM draait op 2 cores met 12GB geheugen. Ik heb een intel panther sata controller als passthrough met daaraan 5x2TB WD Green disks.

En wat betreft google. Zoals ik al stelde was ik zo'n beetje alle forums al afgegaan. Een van de oplossingen die ik gisteren bijvoorbeeld geprobeerd heb is die van de onderstaande link. Alleen zorgt dat ervoor dat ik geen enkele vm meer zie.

AHCI driver

Verder zag ik in een ander forum reeds dat deze soortgelijke bug opgelost was in Freebsd 9.2.12. Echter bleekt het bij veel mensen in 10 en 11 nog steeds voor te komen.

https://communities.vmware.com/thread/498680
https://forums.freebsd.org/threads/53276/
https://forums.freenas.or...-scsi-status-error.43379/

Zelf ben ik er bang voor dat mijn moederbord een klein defect heeft waardoor FreeBSD en hypervisor soms slechte verbinding heeft met de schijven via de controller. Ik heb alleen geen idee hoe ik dit zou kunnen uitsluiten.

[ Voor 6% gewijzigd door Vuurvoske op 22-06-2017 17:46 ]

[nero355]

Vuurvoske schreef op dinsdag 20 juni 2017 @ 22:43:

code:

Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00
Jun 20 22:26:48 zfsguru kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error
Jun 20 22:27:28 zfsguru kernel: (da0:mpt0:0:0:0): Error 5, Unretryable error

Nu heb ik her en der soortgelijke bugmeldingen gevonden. Maar specifiek voor Error 5 niet.
Behalve een iemand die problemen had met een falende usb-stick.
Ik vrees ervoor dat er iets niet goed is met mijn moederbord.

Kijk eens goed naar bovenstaande errors : Het is echt niet je moederbord

Ik gok dat er een HDD stuk is net als in : Mattie112 in "HDD Read errors"

De disks geven de onderstaande SMART status aan:

[afbeelding]

Ik zou graag wat tips krijgen over de herkomst van deze foutmelding.

Dat is niet hoe we S.M.A.R.T. checken van HDD's : Doe eens smartctl -a /dev/**whatever en check goed de output

[Vuurvoske]

nero355 schreef op donderdag 22 juni 2017 @ 18:35:
[...]

Kijk eens goed naar bovenstaande errors : Het is echt niet je moederbord

Ik gok dat er een HDD stuk is net als in : Mattie112 in "HDD Read errors"


[...]

Dat is niet hoe we S.M.A.R.T. checken van HDD's : Doe eens smartctl -a /dev/**whatever en check goed de output

Afgaande op jouw tip heb ik het volgende gedaan:
Lijst van aanwezige HDD's (al da niet viritueel)

code:

[root@zfsguru /var/log]# ls -lta /dev/ada*
crw-r-----  1 root  operator  0x5b Jun 22 17:00 /dev/ada0
crw-r-----  1 root  operator  0x6f Jun 22 17:00 /dev/ada0p1
crw-r-----  1 root  operator  0x70 Jun 22 17:00 /dev/ada0p2
crw-r-----  1 root  operator  0x72 Jun 22 17:00 /dev/ada1
crw-r-----  1 root  operator  0x7a Jun 22 17:00 /dev/ada1p1
crw-r-----  1 root  operator  0x7b Jun 22 17:00 /dev/ada1p2
crw-r-----  1 root  operator  0x73 Jun 22 17:00 /dev/ada2
crw-r-----  1 root  operator  0x7d Jun 22 17:00 /dev/ada2p1
crw-r-----  1 root  operator  0x7e Jun 22 17:00 /dev/ada2p2
crw-r-----  1 root  operator  0x74 Jun 22 17:00 /dev/ada3
crw-r-----  1 root  operator  0x80 Jun 22 17:00 /dev/ada3p1
crw-r-----  1 root  operator  0x81 Jun 22 17:00 /dev/ada3p2
crw-r-----  1 root  operator  0x75 Jun 22 17:00 /dev/ada4
crw-r-----  1 root  operator  0x83 Jun 22 17:00 /dev/ada4p1
crw-r-----  1 root  operator  0x84 Jun 22 17:00 /dev/ada4p2
crw-r-----  1 root  operator  0x77 Jun 22 17:00 /dev/ada5
crw-r-----  1 root  operator  0x86 Jun 22 17:00 /dev/ada5p1
crw-r-----  1 root  operator  0x87 Jun 22 17:00 /dev/ada5p2

(ADA0 = de vmdk van het OS).

Geen van de HDD's gaf errors behalve numero 3:

Samenvatting van het onderstaande:
Device Fault; Error: ABRT
Wat ik zo snel op google lees is "backup everything asap, drive is going to fail" .

Rest mij nog de vraag: Kan ik zomaar een WD 2TB Red combineren met 4x WD 2TB Green? Of levert dat complicaties op? Ik kan ook niets vinden of er nu wel of niet TRIM op zit. Ik weet dat dat van belang is. Maar om eerlijk te zijn vergeten of het er nu juist wel of juist niet op moest zitten .

WD 2TB Red
WD 2TB Green

code:

[root@zfsguru ~]# smartctl -a /dev/ada3 -s on
smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-RELEASE-p8 amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Green
Device Model:     WDC WD20EARX-008FB0
Serial Number:    WD-WCAZAK687325
LU WWN Device Id: 5 0014ee 2b292377b
Firmware Version: 51.0AB51
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Thu Jun 22 17:13:48 2017 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Disabled

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (30600) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 329) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.
SCT capabilities:              (0x30b5) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   188   184   021    Pre-fail  Always       -       5566
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       189
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   052   052   000    Old_age   Always       -       35606
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       158
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       145
193 Load_Cycle_Count        0x0032   142   142   000    Old_age   Always       -       174980
194 Temperature_Celsius     0x0022   109   096   000    Old_age   Always       -       41
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
ATA Error Count: 2789 (device log contains only the most recent five errors)
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 2789 occurred at disk power-on lifetime: 2131 hours (88 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 61 46 00 00 00 a0  Device Fault; Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ef 03 46 00 00 00 a0 00   7d+09:06:12.259  SET FEATURES [Set transfer mode]
  ec 00 00 00 00 00 a0 00   7d+09:06:12.259  IDENTIFY DEVICE
  ec 00 00 00 00 00 a0 00   7d+09:06:12.258  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00   7d+09:06:12.257  SET FEATURES [Set transfer mode]

Error 2788 occurred at disk power-on lifetime: 2131 hours (88 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 61 46 00 00 00 a0  Device Fault; Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ef 03 46 00 00 00 a0 00   7d+09:06:12.257  SET FEATURES [Set transfer mode]
  ec 00 00 00 00 00 a0 00   7d+09:06:12.257  IDENTIFY DEVICE
  ec 00 00 00 00 00 a0 00   7d+09:06:12.256  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00   7d+09:06:12.256  SET FEATURES [Set transfer mode]

Error 2787 occurred at disk power-on lifetime: 2131 hours (88 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 61 46 00 00 00 a0  Device Fault; Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ef 03 46 00 00 00 a0 00   7d+09:06:12.256  SET FEATURES [Set transfer mode]
  ec 00 00 00 00 00 a0 00   7d+09:06:12.254  IDENTIFY DEVICE
  ec 00 00 00 00 00 a0 00   7d+09:06:12.253  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00   7d+09:06:12.253  SET FEATURES [Set transfer mode]

Error 2786 occurred at disk power-on lifetime: 2131 hours (88 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 61 46 00 00 00 a0  Device Fault; Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ef 03 46 00 00 00 a0 00   7d+09:06:12.253  SET FEATURES [Set transfer mode]
  ec 00 00 00 00 00 a0 00   7d+09:06:12.253  IDENTIFY DEVICE
  ec 00 00 00 00 00 a0 00   7d+09:06:12.252  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00   7d+09:06:12.251  SET FEATURES [Set transfer mode]

Error 2785 occurred at disk power-on lifetime: 2131 hours (88 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 61 46 00 00 00 a0  Device Fault; Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ef 03 46 00 00 00 a0 00   7d+09:06:12.251  SET FEATURES [Set transfer mode]
  ec 00 00 00 00 00 a0 00   7d+09:06:12.251  IDENTIFY DEVICE
  ec 00 00 00 00 00 a0 00   7d+09:06:12.250  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00   7d+09:06:12.249  SET FEATURES [Set transfer mode]

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

[ Voor 103% gewijzigd door Vuurvoske op 22-06-2017 19:27 ]

[nero355]

Vuurvoske schreef op donderdag 22 juni 2017 @ 19:19:
Geen van de HDD's gaf errors behalve numero 3:

Samenvatting van het onderstaande:
Device Fault; Error: ABRT
Wat ik zo snel op google lees is "backup everything asap, drive is going to fail" .

Weg met dat ding!

Rest mij nog de vraag: Kan ik zomaar een WD 2TB Red combineren met 4x WD 2TB Green? Of levert dat complicaties op? Ik kan ook niets vinden of er nu wel of niet TRIM op zit. Ik weet dat dat van belang is. Maar om eerlijk te zijn vergeten of het er nu juist wel of juist niet op moest zitten .

TRIM is voor SSD's

Je kan ze verder combineren, maar ik zou het persoonlijk niet doen : De Red's hebben TLER en de Greens niet en dat zou ik dus nooit mixen.

[kdbruin]

De harddisks in m'n NAS beginnen wat vaker in de logs van m'n FreeBSD 10.3 server voor te komen maar dat vind ik op zich niet zo vreemd na bijna 5 jaar continue gedraaid te hebben. Ik ben dus op zoek naar vervangende harddisks voor de huidige 3TB WD Greens (6 stuks in RAID Z2).

Ik dacht zelf aan 2x 8TB schijven die ik dan als een mirrored vdev in een pool kan stoppen. Het is dan wat makkelijker om nog enkele van m'n oude disks mee te nemen en deze later te vervangen. De vraag is echter welke schijven te nemen:

- pricewatch: Seagate IronWolf, 8TB
- pricewatch: HGST Deskstar NAS (2017), 8TB
- pricewatch: Seagate Desktop HDD, 8TB
- pricewatch: WD Red WD80EFZX, 8TB
- pricewatch: WD Purple (2017) WD80PUZX, 8TB

Het nadeel van de eerste 2 zijn dat ze op 7200RPM draaien en dat hoeft voor mij niet. Ik heb geen honger naar extreme doorvoer snelheden.

Als ik bijvoorbeeld bij Backblaze naar de laatste statistieken kijk komt de Seagate Desktop HDD er wel erg goed van af.

Ervaringen, suggesties?

[Giesber]

kdbruin schreef op vrijdag 23 juni 2017 @ 09:45:
De harddisks in m'n NAS beginnen wat vaker in de logs van m'n FreeBSD 10.3 server voor te komen maar dat vind ik op zich niet zo vreemd na bijna 5 jaar continue gedraaid te hebben. Ik ben dus op zoek naar vervangende harddisks voor de huidige 3TB WD Greens (6 stuks in RAID Z2).

Ik dacht zelf aan 2x 8TB schijven die ik dan als een mirrored vdev in een pool kan stoppen. Het is dan wat makkelijker om nog enkele van m'n oude disks mee te nemen en deze later te vervangen. De vraag is echter welke schijven te nemen:

- pricewatch: Seagate IronWolf, 8TB
- pricewatch: HGST Deskstar NAS (2017), 8TB
- pricewatch: Seagate Desktop HDD, 8TB
- pricewatch: WD Red WD80EFZX, 8TB
- pricewatch: WD Purple (2017) WD80PUZX, 8TB

Het nadeel van de eerste 2 zijn dat ze op 7200RPM draaien en dat hoeft voor mij niet. Ik heb geen honger naar extreme doorvoer snelheden.

Als ik bijvoorbeeld bij Backblaze naar de laatste statistieken kijk komt de Seagate Desktop HDD er wel erg goed van af.

Ervaringen, suggesties?

Als je geen 7200 RPM wilt (geen slecht idee) dan blijven er maar 3 over. Waarom dan geen Seagate Desktop en een WD Red nemen? Als je merken mixt heb je minder kans dat er 2 schijven tegelijkertijd overlijden (bron: mijn buikgevoel). Wel even controleren of beide schijven TLER ondersteuen.

[nero355]

kdbruin schreef op vrijdag 23 juni 2017 @ 09:45:
Ervaringen, suggesties?

Persoonlijk zit ik nog steeds te twijfelen tussen de volgende opties :

- WD Red HDD's voor de stilte. De 6TB varianten doen het erg goed!
- Hitachi NAS serie voor de betrouwbaarheid. Ook 6TB, maar zijn erg luid.

Van de 8TB modellen moet ik nog wat meer reviews lezen, want die zijn inderdaad erg interessant op het moment

[JWR]

Om maar met de deur in huis te vallen, ik heb een groot probleem.
Ik heb sinds een paar jaar een server met ESXI en o.a. Freenas als VM.

Hardware:
- Asrock B75pro3-m
- Cpu i5
- 16 Gb Ram
- Dell HBA controller
- SSD 256Gb voor VM’s
- ESXI, draait van USB stick
- 5x 2Tb Seagate, geconfigureerd als een ZFS pool

Probleem:
Het probleem zit hem in de vijf Seagate schijven, waar mijn data op staat.
Afgelopen week kon ik ineens geen data meer lezen vanaf de NAS. Na enige troubleshooting blijkt mijn nachtmerrie werkelijkheid te zijn geworden, de ZFS pool (raidz1) is niet benaderbaar, ondanks dat er 1 schijf echt stuk is.
Van de vijf schijven is er nog maar één zonder errors.
Schijf 1 : 0 errors
Schijf 2: 8 unreadable en uncorrectable errors
Schijf 3: 5072 unreadable en uncorrectable errors
Schijf 4: 56 unreadable en uncorrectable errors
Schijf 5: volledig stuk

Hoe het heeft kunnen gebeuren is helemaal niet helder, ik zat regelmatig in Freenas om de status te bekijken en het icoon met Critical heeft nog nooit eerder geknipperd. Nu zal ik daar ook nooit meer achter komen wat de reden is geweest. Waar ik me nu volledig op wil richten is het redden van de data.

Nu staat er een hoop data op wat me gestolen kan worden films/series/muziek,
waar het mij wel om gaat zijn de foto’s en documenten.

Wat heb ik allemaal gedaan?
1. Om er zeker van te zijn dat het niet aan de HBA controller lag, heb ik alle schijven rechtstreeks op het moederbord aangesloten. Tevens heb ik Freenas op een USB stick geïnstalleerd en daarmee de schijven proberen te importeren. Dus puur NAS en geen ESXI meer. Dit was de eerste keer dat ik het icoon critical met rood lampje zag knipperen, verklaarbaar?
2. Ik heb alle schijven één voor één losgekoppeld om er achter te komen welke schijven stuk zijn, goed zijn en errors hebben.
3. Van een goede vriend 2x 4Tb externe schijven en 2x 3Tb geleend, het idee is om eerst een clone te maken (d.m.v. Clonezilla) van de schijven, voordat ze mogelijk nog meer verslechteren.
4. Een andere goede vriend @Mystic Spirit, heeft nog meer schijven liggen waar ik (hopelijk) de data naar kan wegschrijven die ik (hopelijk) kan redden.

Vragen:
1. Is het mogelijk om data te recoveren in mijn situatie?
2. Heeft het zin om een clone te maken van de schijven?
3. Wat is de volgende stap?

[ZaPPZion]

Om te beginnen even een zpool status maken, dan kunnen wij ook mee kijken

Heb je al een scrub gedraaid? De kapotte schijf ge-replaced met een werkende en daarna gescrubd?
Of zie je de hele pool niet meer?

[JWR]

ZaPPZion schreef op zaterdag 24 juni 2017 @ 10:40:
Om te beginnen even een zpool status maken, dan kunnen wij ook mee kijken

Heb je al een scrub gedraaid? De kapotte schijf ge-replaced met een werkende en daarna gescrubd?
Of zie je de hele pool niet meer?

De hele pool is niet meer zichtbaar, dus een status kan ik niet maken.

[ZaPPZion]

Aha. Heb je al geprobeerd een zpool import te draaien om te kijken of je weer kunt re-attachen?

[kdbruin]

nero355 schreef op vrijdag 23 juni 2017 @ 15:18:
Persoonlijk zit ik nog steeds te twijfelen tussen de volgende opties :

- WD Red HDD's voor de stilte. De 6TB varianten doen het erg goed!
- Hitachi NAS serie voor de betrouwbaarheid. Ook 6TB, maar zijn erg luid.

Van de 8TB modellen moet ik nog wat meer reviews lezen, want die zijn inderdaad erg interessant op het moment

De 6TB WD Reds komen er bij Backblaze juist niet zo goed vanaf maar het aantal disks is ook klein is vergelijking met de andere aantallen.

Nog even wat meer rondgeneusd en ga voor de 8TB WD Red disks. Komen er in de verschillende reviews goed vanaf, zijn een stukje zuiniger en stiller ten opzichte van de Seagate IronWolf en qua duurzaamheid op langere termijn is het nu toch gokken.

Ik ga er 2 bestellen bij 2 verschillende winkels om "uit te sluiten" dat ze uit dezelfde batch komen. Gelijk even wat SATA kabels erbij en een molex naar SATA splitter voor de voeding en dan kunnen we de boel gaan inbouwen en de data overzetten van de oude naar de nieuwe pool.

[JWR]

ZaPPZion schreef op zaterdag 24 juni 2017 @ 12:50:
Aha. Heb je al geprobeerd een zpool import te draaien om te kijken of je weer kunt re-attachen?

Ja dat heb ik ook geprobeerd, de pool is helemaal onzichtbaar.

Maar wel even een status update.

De harde schijf die stuk is spint wel op, maar wordt niet herkend door het BIOS.
Mijn gedachten gang is, dat misschien de printplaat kapot is, aangezien die voor de aansturing zorgt.
Nu heeft @Mystic Spirit een exact dezelfde schijf liggen, nu ga ik proberen de kapotte harde schijf
te repareren en dan de pool weer zichtbaar te krijgen.
Als dat lukt dan haal ik alles van de pool af en ga ik nieuwe schijven kopen.

Nu is het wachten op de hdd die per post komt en een set schroevendraaiers van iFixit.
Ik hoop tegen het weekend een nieuwe update te kunnen geven.

[ZaPPZion]

Klinkt spannend, een pool die helemaal niet meer gevonden wordt. Hopen dat jouw oplossing lukt met de andere printplaat

[DaCoTa]

DaCoTa schreef op zondag 30 september 2012 @ 10:42:
Dan heb ik nog een leuke puzzel:

Jan heeft nu 3 losse 2TB disks, 1 100% vol, 1 disk met 1.2TB en 1 disk met 1TB data.

Nu wil Jan nog 3 2TB disks erbij halen, om een raidz2 set te bouwen, met daarop alle 4.2TB aan data.

Het enige dat Jan verder nog heeft zijn 3 lege 500GB disks.

Bovenstaande was mijn voorwerk om een ZFS Nas te bouwen. Begin 2013 heb ik, naast een AMD A8-5500, een MSI A85XA-G65 en 16GB geheugen, 3x ST3000DM001 aangeschaft en er een 6 disk Z2 pool van gemaakt van 3x 2TB en 3x 3TB, netto 8TB ruimte. De 3TB disks werden maar voor 2/3 gebruikt, maar met de vooruitziende blik dat schijven steeds goedkoper worden.

In 2015 was een 2TB oververhit en een 3TB overleden, deze heb ik toen vervangen door 2x H3IKNAS40003272SE (€175,-/stuk) en bestond de pool uit 2x 2TB, 2x 3TB en 2x 4TB, nog steeds netto 8TB.

Afgelopen maand was een van de 2TB uit de pool gegooid vanwege write errors. De andere 2TB was afgevlagd omdat deze inmiddels ouder dan 5 jaar was en een 3TB had errors die ik al een jaar aan het negeren was. Ik was dus genoodzaakt om weer een bestelling te plaatsen: 3x H3IKNAS400012872SWW (€136,-/stuk).

Eigenlijk wilde ik grotere disks, maar die vond ik economisch niet handig, zeker niet omdat ik er 3 nodig had. Na 3x resilveren om disks te vervangen (ongeveer 6 uur per disk) en de autoexpand vlag aan te zetten, draait de pool nu met 1x 3TB en 5x 4TB en heb ik netto 12TB, waarvan ongeveer 50% in gebruik.

Conclusie: in 5 jaar heb ik 5 disks nodig gehad om de pool in leven te houden. Aanschaf systeem, ongeveer €600,-, exclusief 3 donorschijven. Daarna gemiddeld €150,- per jaar aan disks. Ik ben tevreden, de groei is er nog niet uit, zodra de laatste 3TB vervangen is, heb ik 16TB netto, en dan kan het spelletje opnieuw beginnen met grotere disks.

Op naar de volgende 5 jaar!

[kdbruin]

Vandaag komt de eerste van de nieuwe 8TB schijven binnen maar heb een vraag met betrekking tot de resilvering die nu nog bezig is. Dit gaat extreem langzaam (pool zit ook behoorlijk vol) en ik vraag me af of ik de server tussentijds uit kan zetten om de nieuwe disk in te bouwen en alvast te beginnen met het kopiëren van de data.

Uitvoer van

zpool status

code:

  pool: vault
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Jun 27 08:24:52 2017
        56.5G scanned out of 13.8T at 6.02M/s, 665h3m to go
        2.80M resilvered, 0.40% done
config:

        NAME            STATE     READ WRITE CKSUM
        vault           ONLINE       0     0     0
          raidz2-0      ONLINE       0     0     0
            gpt/WD3T01  ONLINE       0     0     0
            gpt/WD3T02  ONLINE       0     0     0
            gpt/WD3T03  ONLINE       0     0     0
            gpt/WD3T04  ONLINE       0     0     0
            gpt/WD3T07  ONLINE       0     0     0
            gpt/WD3T06  ONLINE      16   353     7  (resilvering)

errors: No known data errors

[ZaPPZion]

Als ik jou was, zou ik niet tijdens resilvering allerlei dingen gaan doen met de server. Het is al zwaar genoeg voor de hdd's Uiteindelijk win je er ook niks mee, aangezien de schijven gewoon een maximale snelheid hebben voor het lezen en schrijven. Na elkaar is waarschijnlijk ook sneller dan tegelijkertijd schrijven en lezen, het meest optimale geval is parallel net zo snel als sequentieel.

[CurlyMo]

kdbruin schreef op dinsdag 27 juni 2017 @ 11:07:
Dit gaat extreem langzaam (pool zit ook behoorlijk vol) [...]

Dat is in het begin vrijwel altijd zo. Dat komt wel goed na een paar GB.

[kdbruin]

CurlyMo schreef op woensdag 28 juni 2017 @ 11:13:
Dat is in het begin vrijwel altijd zo. Dat komt wel goed na een paar GB.

Lijkt er inderdaad op. Huidige stand van zaken is nu:

code:

  pool: vault
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed Jun 28 12:52:21 2017
        104G scanned out of 13.8T at 247M/s, 16h8m to go
        92K resilvered, 0.74% done
config:

        NAME            STATE     READ WRITE CKSUM
        vault           ONLINE       0     0     0
          raidz2-0      ONLINE       0     0     0
            gpt/WD3T01  ONLINE       0     0     0
            gpt/WD3T02  ONLINE       0     0     0
            gpt/WD3T03  ONLINE       0     0     0
            gpt/WD3T04  ONLINE       0     0     0
            gpt/WD3T07  ONLINE       0     0     0
            gpt/WD3T06  ONLINE      16   353     7  (resilvering)

errors: No known data errors

Ach, vanavond toch geen tijd dus laat nog maar even rustig z'n ding doen.

[kdbruin]

ZaPPZion schreef op woensdag 28 juni 2017 @ 11:12:
Als ik jou was, zou ik niet tijdens resilvering allerlei dingen gaan doen met de server. Het is al zwaar genoeg voor de hdd's Uiteindelijk win je er ook niks mee, aangezien de schijven gewoon een maximale snelheid hebben voor het lezen en schrijven. Na elkaar is waarschijnlijk ook sneller dan tegelijkertijd schrijven en lezen, het meest optimale geval is parallel net zo snel als sequentieel.

Ik heb de meeste crontab taken al uitgezet om de disks zoveel mogelijk te ontlasten. Qua tijdsindicatie is het ook een stuk beter ten opzichte van gisteren: van 600+ naar 16 uur resterende tijd.

[dehardstyler]

kdbruin schreef op zondag 25 juni 2017 @ 13:44:
[...]

Gelijk even wat SATA kabels erbij en een molex naar SATA splitter voor de voeding

Hou je wel rekening met het spreekwoord: "Molex to SATA, lose all your data!"
Typ maar eens in op Google.

[FireDrunk]

Dat is wel een beetje bangmakerij... Op Reddit was 1 van de eerste reactie van een PC monteur die dat in 4 jaar nog nooit gezien had...

Ik gebruik ze zelf ook al jaren, maar wel highend kwaliteit (Highflow.nl heeft high quality verloopjes), en niet van die standaard witte prutsdingen inderdaad.

[kdbruin]

dehardstyler schreef op woensdag 28 juni 2017 @ 23:08:
Hou je wel rekening met het spreekwoord: "Molex to SATA, lose all your data!"
Typ maar eens in op Google.

Goh, als ik met alles wat fout kan gaan rekening moet houden, dan kan ik beter gelijk met alles stoppen. Ik heb in diverse systemen deze splitters zitten en nog geen problemen gehad. Gewoon een kwestie van kwaliteit kopen in plaats van zo goedkoop mogelijk zoals @FireDrunk ook al aangeeft.

[dehardstyler]

kdbruin schreef op donderdag 29 juni 2017 @ 09:20:
[...]


Goh, als ik met alles wat fout kan gaan rekening moet houden, dan kan ik beter gelijk met alles stoppen. Ik heb in diverse systemen deze splitters zitten en nog geen problemen gehad. Gewoon een kwestie van kwaliteit kopen in plaats van zo goedkoop mogelijk zoals @FireDrunk ook al aangeeft.

Zo gaat ie he? Was een tip hé, kalm aan joh! Doe er mee wat je wilt...
Wilde je inderdaad alleen behoeden voor de goedkopere kabels...

[InflatableMouse]

Snel vraagje.

Als ik een zfs send ene/pool | zfs receive andere/pool doe, en ergens halverwege druk ik per ongeluk op ctrl-c.

Als ik em dan opnieuw start, gaat tie door waar tie gebleven is? Is dit intelligent genoeg dat tie niet opnieuw begint?

Ik zie in m'n zpool iostat -v dat de target allocated wel raar doet. Dat was 520G, staat nu ineens op 503G en telt weer op. Het lijkt dus dat tie niet helemaal opnieuw begint, maar hoe zit dat precies?

Edit: ow nou allocated zakt meer dan dat het stijgt, ben bang dat ik mijn eigen vraag zo kan beantwoorden .

[ Voor 11% gewijzigd door InflatableMouse op 02-07-2017 12:59 ]

[nero355]

FireDrunk schreef op donderdag 29 juni 2017 @ 08:18:
Dat is wel een beetje bangmakerij... Op Reddit was 1 van de eerste reactie van een PC monteur die dat in 4 jaar nog nooit gezien had...

Ik gebruik ze zelf ook al jaren, maar wel highend kwaliteit (Highflow.nl heeft high quality verloopjes), en niet van die standaard witte prutsdingen inderdaad.

Van die Silverstone dingen toch ?
pricewatch: Silverstone SST-CP06 4x SATA

Wat dat betreft is een DIY NAS project best irritant : Waarom zijn er geen 350 Watt (of zo) voedingen met een stuk of 12 a 14 SATA stroomconnectoren ?!

Uiteraard zo stil en efficiënt mogelijk

[GioStyle]

Als je een DIY nas bouwt, dan kan je toch ook DIY kabels maken? Ik heb een semi-modulaire voeding gekocht plus connectoren, pinnen en draad. Kabels precies op maat.

[nero355]

GioStyle schreef op zondag 2 juli 2017 @ 22:07:
Als je een DIY nas bouwt, dan kan je toch ook DIY kabels maken? Ik heb een semi-modulaire voeding gekocht plus connectoren, pinnen en draad. Kabels precies op maat.

Één keer gedaan, maar werd daar niet echt vrolijk van...

[InflatableMouse]

Naar aanleiding van mijn eerdere post heb ik nu backup pool opnieuw aangemaakt en alles staat er weer terug op.

Ik ben nu aan het organiseren. Alles staat in /backup/uitzoeken. Ik heb zfs create backup/music aangemaakt en ik verplaats alles van /backup/uitzoeken/music/* naar /backup/music.

Simpel toch? Krijg ik ineens 'no space left on device'.

code:

$ zfs list
NAME                    USED  AVAIL  REFER  MOUNTPOINT
backup                 1.76T     0B   104K  /backup
backup/music            572G     0B   572G  /backup/music
backup/syncthing       54.7G     0B  54.5G  /backup/syncthing
backup/uitzoeken       1.14T     0B   547G  /backup/uitzoeken

Als ik nu dit doe

code:

$ zfs list -t snapshot
NAME                             USED  AVAIL  REFER  MOUNTPOINT
backup/syncthing@--head--        157M      -  54.7G  -
backup/uitzoeken@--head--        625G      -  1.14T  -

Wat zijn die --head-- dingen en kan ik die zomaar weghalen? Google vind er helemaal niets op en ik heb dat nooit eerder gezien. Maar er zit wel 625GB in, en dat is denk ik de reden dat ik geen ruimte meer heb.

[ZaPPZion]

InflatableMouse schreef op maandag 3 juli 2017 @ 10:24:
Wat zijn die --head-- dingen en kan ik die zomaar weghalen? Google vind er helemaal niets op en ik heb dat nooit eerder gezien. Maar er zit wel 625GB in, en dat is denk ik de reden dat ik geen ruimte meer heb.

Volgens mij is dat een snapshot. Als je snapshots hebt gemaakt, wordt de referentie naar de 'vorige' versie van een file bewaard. Als je die zou verwijderen, komt de ruimte weer vrij.
Als je zeker weet dat je die snapshot niet meer nodig hebt, kun je dit commando gebruiken (eigen risico natuurlijk ):

code:

zfs destroy backup/syncthing@--head--

[ZaPPZion]

InflatableMouse schreef op zondag 2 juli 2017 @ 12:49:
Snel vraagje.

Als ik een zfs send ene/pool | zfs receive andere/pool doe, en ergens halverwege druk ik per ongeluk op ctrl-c.

Als ik em dan opnieuw start, gaat tie door waar tie gebleven is? Is dit intelligent genoeg dat tie niet opnieuw begint?

Nee, een zfs send is een stream vanaf het begin tot het eind. Er zijn wel mogelijkheden om een zfs send met progress te doen, dan moet je even wat meer opzoeken over:

code:

zfs receive -s

Dan kun je na een abort weer verder met:

code:

zfs send -t token

[InflatableMouse]

ZaPPZion schreef op maandag 3 juli 2017 @ 12:45:
[...]

Volgens mij is dat een snapshot. Als je snapshots hebt gemaakt, wordt de referentie naar de 'vorige' versie van een file bewaard. Als je die zou verwijderen, komt de ruimte weer vrij.
Als je zeker weet dat je die snapshot niet meer nodig hebt, kun je dit commando gebruiken (eigen risico natuurlijk ):

code:

zfs destroy backup/syncthing@--head--

Thanks, ik had geen snapshots gemaakt. Mischien dat dit overblijfselen zijn van de zfs send/receive die ik heb getest. Ging eerste paar keer mis omdat dingen gemount waren, of omdat ik -F moest doen omdat het al bestond.

Het is weg in ieder geval, heb het verwijderd. Een complete copy had ik nog in data/backup sowieso, omdat ik natuurlijk backup pool opnieuw moest aanmaken.

ZaPPZion schreef op maandag 3 juli 2017 @ 12:51:
[...]


Nee, een zfs send is een stream vanaf het begin tot het eind. Er zijn wel mogelijkheden om een zfs send met progress te doen, dan moet je even wat meer opzoeken over:

code:

zfs receive -s

Dan kun je na een abort weer verder met:

code:

zfs send -t token

Nice! die ga ik verder uitzoeken. Lijkt me onwijs handig want ik ga samen met een vriend uitzoeken hoe we onze meest belangrijke spullen naar elkaar kunnen syncen met zfs send/recieve, over ssh en encrypted zodat we niet in elkaars dingetjes kunnen snuffelen.

[FireDrunk]

@InflatableMouse Wat jij denk ik zoekt is niet zozeer Snapshots, maar Bookmarks:
https://www.freebsd.org/cgi/man.cgi?query=zfs&sektion=8 -> Zoeken op "ZFS Bookmark"

[InflatableMouse]

FireDrunk schreef op maandag 3 juli 2017 @ 16:35:
@InflatableMouse Wat jij denk ik zoekt is niet zozeer Snapshots, maar Bookmarks:
https://www.freebsd.org/cgi/man.cgi?query=zfs&sektion=8 -> Zoeken op "ZFS Bookmark"

Ik zag bookmarks van de week voor het eerst toen ik weer eens door de man-page heen scrolde. Toen alleen in m'n achterhoofd gehouden, nu door jou weer getriggered om er naar te kijken:

Voor de geinteresseerden:
https://utcc.utoronto.ca/...laris/ZFSBookmarksWhatFor

Ik denk dus inderdaad dat die "snapshots" bookmarks waren die onbewust door mij gecreeerd zijn met de send/receive.

Zeer interessant weer!

[ZaPPZion]

InflatableMouse schreef op maandag 3 juli 2017 @ 13:05:
over ssh en encrypted zodat we niet in elkaars dingetjes kunnen snuffelen.

Je weet dat je dat soort filmpjes ook kunt streamen van allerlei websites he? (heb ik gehoord van een vriend)

[InflatableMouse]

ZaPPZion schreef op maandag 3 juli 2017 @ 17:37:
[...]

Je weet dat je dat soort filmpjes ook kunt streamen van allerlei websites he? (heb ik gehoord van een vriend)

Inflatablemouse snapt em niet

[FireDrunk]

Hij heeft het over pr0n...

[InflatableMouse]

Oh dat ... daar heb ik geen tijd voor man

[ Voor 11% gewijzigd door InflatableMouse op 03-07-2017 20:48 . Reden: typo ]

[Melkaz]

Zoals zo vaak als het tegen zit gaat ook alles mis. Afgelopen weekend is er een schijf overleden van mijn main server. Geen probleem, ik had nog een recente backup op mijn offline Freenas ZFS server.

Eenmaal opgestart:
CRITICAL: July 4, 2017, 8:19 a.m. - Device: /dev/ada2, 405 Currently unreadable (pending) sectors
CRITICAL: July 4, 2017, 8:19 a.m. - Device: /dev/ada2, 454 Offline uncorrectable sectors

Ok...dus ook daar staat er een schijf op overlijden. Geen probleem de vervangende schijven zijn besteld en komen vandaag binnen en het volume is nog gewoon beschikbaar.

Maar het restoren van de data gaat letterlijk met 700~KB/s met soms dalen van onder de 200 KB/s. Schrijven naar de pool gaat wel met 110~ MB/s maar het eraf halen schiet dus voor geen meter op. Komt dit door de problemen met de sectors zoals hierboven vermeld of heb ik een ander (3e) probleem?

[Dwarlorf]

Ik wil binnenkort een eigen NAS maken van mijn oude (=huidige) hardware maar dit is allemaal onbekend terrein voor me. Nou heb ik zo het één en ander gelezen en ik vraag nav deze primer af waarom ik geen ZFS NAS zou nemen? Het komt allemaal zo positief op me over dat een NAS met een 'klassieke' raid opstelling me niet eens een serieuze optie lijkt.

Het enige nadeel dat ik zo kan vinden is dat je een ZFS NAS niet makkelijk kan uitbreiden met nieuwe schijven. Maar voor mij niet relevant want ik verwacht niet echt meer dat 2 drie TB schijven te gaan gebruiken.

Zie ik iets belangrijks over het hoofd?

[FireDrunk]

- Configuratie is ingewikkelder
- Hardware eisen zijn iets zwaarder (en ECC is sterk aan te raden)
- Er zijn geen recovery tools
- En het is niet makkelijk uit te breiden in specifieke gevallen

Voor de rest: Wat jij er van maakt

[kdbruin]

Zo, gisteren de nieuwe 8TB disks ingebouwd (helaas op "oude" SATA poorten, de snelle zaten al vol) en gestart met het overzetten van de bestaande data naar de nieuwe data pool. Eens kijken hoe lang het duurt om de 6TB over te zetten met zfs send/receive.

[Compizfox]

FireDrunk schreef op woensdag 5 juli 2017 @ 16:24:
- Hardware eisen zijn iets zwaarder (en ECC is sterk aan te raden)

Niet geheel mee eens. Met ZFS heb je geen speciale RAID-controller nodig, je kunt gewoon gebruik maken van je onboard SATA. Dat is een enorm voordeel boven hardware-RAID.

[FireDrunk]

Correct, ik doelde ook meer op CPU en Memory footprint, je CPU wordt een stuk zwaarder belast door het berekenen van checksums en parity, en ZFS gebruikt een stuk meer geheugen.

Voor de rest heb je helemaal gelijk hoor

[Dwarlorf]

Ik heb geen ECC geheugen maar wel een i5 2500. Dat is CPU wise vast wel voldoende.

Loop ik een groot risico zonder ECC geheugen? En kan ik het geheugen op een later tijdstip swappen als de boel al up and running is?

[Compizfox]

Dwarlorf schreef op donderdag 6 juli 2017 @ 21:24:
Ik heb geen ECC geheugen maar wel een i5 2500. Dat is CPU wise vast wel voldoende.

Loop ik een groot risico zonder ECC geheugen?

Die vraag is ietswat controversieel in de ZFS-community, maar ik ben van mening dat het geen kwaad kan voor thuisgebruik.

Het is welliswaar zo dat je RAM dan je zwakste factor is, maar een ZFS-based NAS zonder ECC is nog altijd vele malen beter dan een non-ZFS-based NAS.

Zie ook:
http://jrs-s.net/2015/02/...n-ecc-ram-kill-your-data/
ECC geheugen voor zelfbouw ZFS NAS?

En kan ik het geheugen op een later tijdstip swappen als de boel al up and running is?

Als je nu een bord zonder ECC-RAM hebt past daar niet zomaar ECC RAM in.