ZFS; zpool FAULTED, hulp gevraagd

[hansdegit]

Hoi ,

Sinds gisteren heb ik een vreemd probleem aan mn fiets hangen. Ik had 2 miljoen checksum errors op één device.

De situatie:
Een supermicro X10SL7-F bord met onboard LSI controller, ESXi met passthrough van de controller naar een FreeBSD ZFS server.

code:

root@zfsserver:/etc # sysctl -n kern.osrelease kern.ostype
11.2-RELEASE-p1
FreeBSD

De server komt op, maar ik krijg mn pool niet online. Dit is de output van "zpool status":

code:

root@zfsserver:/dev # zpool status
  pool: flashpool
 state: FAULTED
status: One or more devices could not be used because the label is missing
        or invalid.  There are insufficient replicas for the pool to continue
        functioning.
action: Destroy and re-create the pool from
        a backup source.
   see: http://illumos.org/msg/ZFS-8000-5E
  scan: none requested
config:

        NAME                      STATE     READ WRITE CKSUM
        flashpool                 FAULTED      0     0     1
          raidz1-0                ONLINE       0     0     6
            gpt/ssd1              ONLINE       0     0     1
            gpt/ssd2              ONLINE       0     0     0
            14203667806721998607  UNAVAIL      0     0     0  was /dev/gpt/ssd3
            16565702290378247892  UNAVAIL      0     0     0  was /dev/gpt/ssd4
            18427777116630032338  UNAVAIL      0     0     0  was /dev/gpt/ssd5

Je zou denken: nah, logisch 3 devices missen. Logisch dat je RAIDZ1 er niet is. Het vreemde is: Als ik drie devices aansluit, zie ik er drie. Vanaf de vierde gaat het mis. Zodra ik vier en vijf aansluit, "ziet" ZFS er maar 2. Ik vermoedde een elektrisch probleem.

Het maakt niet uit welke devices ik aansluit, bij een willekeurige 4e SSD wordt een andere als UNAVAIL aangemerkt.

Ik zie ze wél in /dev/gpt:

code:

root@zfsserver:/dev/gpt # ls -lrt
total 0
crw-r-----  1 root  operator  0x77 Mar  4 11:06 ssd5
crw-r-----  1 root  operator  0x79 Mar  4 11:06 ssd4
crw-r-----  1 root  operator  0x7a Mar  4 11:06 ssd3
crw-r-----  1 root  operator  0x7b Mar  4 11:06 ssd2
crw-r-----  1 root  operator  0x78 Mar  4 11:06 ssd1
crw-r-----  1 root  operator  0x74 Mar  4 11:06 gptboot0

Dus als ZFS eventjes zijn best doet, zou ie toch de devices moeten kunnen "zien" en evt corrigeren?

Ben ik de pool écht kwijt? Heb ik inderdaad een hardwareprobleem als ik de devices evengoed wél kan zien?

Ben een beetje de weg kwijt en sta op het punt om een nieuw (2e hands) moederbord aan te schaffen.

Graag tips hoe ik eea kan troubleshooten.

[BCC]

Heb je het al met een nieuwe voeding geprobeerd? Als je voltages inzakken spinnen disks soms niet meer up.

[hansdegit]

Het zijn Crucial MX500 SSD's. En ter controle had ik er ook nog een WD spinning disk aan gehangen; die komt er ook gewoon bij. Helaas heb ik geen spare voeding liggen.

[ Voor 14% gewijzigd door hansdegit op 04-03-2020 11:33 ]

[FireDrunk]

Ik gok op RAM of Controller kaduuk. Test vooral eerst even met memtest. Maar aangezien je een Supermicro bord hebt, check ook even je eventlog op ECC errors.

Zie je iets in kernel log? (dmesg)

[antubus]

Je zou kunnen proberen de schijven in een nieuw systeem met een verse instalatie te hangen, als ze daar gevonden worden (evt zonder de schijf met de vele errors) weet je in ieder geval dat je data nog niet weg is.
edit:
Ik lees dat je geen extra voeding hebt liggen, dan zal een volledig systeem ook wel buiten de mogelijkheden liggen...
Heb je gekeken of er een logica zit in de poorten waar je je schijven op aansluit? Op die manier kun je eventueel ontdekken of het probleem in je controller zit

[ Voor 40% gewijzigd door antubus op 04-03-2020 11:37 ]

[hansdegit]

@Firedrunk: leuk om te zien dat je nog actief bent! Ik denk ook dat de controller kaduuk is.

Eh, hoe check ik op ECC errors?

Ik heb een backup in de cloud; dit is een leuke test.....Maar het is zo'n gedoe. Ik heb liever gewoon de pool terug.

[FireDrunk]

Via de IPMI interface (Web UI) kan je dat wel zien. Anders kan je memtest draaien.

[hansdegit]

@antubus

Ik heb wat gevarieerd in de poorten, maar er zit totaal geen logica in. Ook de volgorde van het aansluiten van de SSD's maakt geen verschil. Het lijkt willekeur.

Maar: omdat de schijven wél zichtbaar zijn in /dev/gpt, betekent dat dan dat er een logische corruptie is oid?

[CurlyMo]

hansdegit schreef op woensdag 4 maart 2020 @ 11:38:
@Firedrunk: leuk om te zien dat je nog actief bent! Ik denk ook dat de controller kaduuk is.

Komt omdat je deze vraag niet in het ZFS topic hebt gesteld. Daar hangen de ZFS enthousiastelingen het meest rond, waaronder @FireDrunk.

[antubus]

Als de schijven wel in /dev herkend worden doet me vermoeden dat je hardware oke is. Omdat de eerste 2 wel altijd herkend worden lijkt te bevestigen dat de zfs labels en data nog in orde zijn wat een defecte controller onwaarschijnlijk maakt. Dan is er dus een reële kans dat dit ergens bij zfs misgaat wat betekent dat ik nu mn mond moet houden en de experts aan het woord moet laten ;-)

[FireDrunk]

Dat is mijns inziens te kort door de bocht. Een kapotte controller hoeft zich zeker niet te manifesteren door afwezigheid van schijven.

Ook op dat ding zit wat cache / dram, en dat kan ook kapot, waardoor vooral transfers corrupt raken.
ZFS ziet dat door de checksums die falen, en zal je disks offline halen.
Als de controller logica zelf intact is, zie je de schijven gewoon.

Been there, had that...

[hansdegit]

CurlyMo schreef op woensdag 4 maart 2020 @ 12:19:
[...]

Komt omdat je deze vraag niet in het ZFS topic hebt gesteld. Daar hangen de ZFS enthousiastelingen het meest rond, waaronder @FireDrunk.

Ik wilde het ZFS topic nou juist niet vervuilen met mn sores....

Is er iets wat ik met command-line dingen kan proberen om eea verder uit te sluiten?

[ Voor 66% gewijzigd door hansdegit op 04-03-2020 14:37 ]

[Q]

Ik had laatst grote problemen met uitvallende devices conform jouw huidige problematiek. De oplossing: andere voeding.

Als jezelf niets hebt aangepast of hebt lopen knoeien dan lijkt me dit een goede verklaring. Het kan zijn dat je controller rot is maar dat is volgens mij zo zeldzaam.

Ik heb een spare controller en voeding om mee te testen als je in de regio haarlem zit.

Er is nog meer wat je zelf kunt testen.

Stap 1: sluit alle devices aan en log in met ssh op de freenas server.
Stap 2: doe een dd if=/dev/<dev> of=/dev/null bs=1M & voor ieder device
Stap 3: controleer of devices verdwijnen in /var/log/syslog of me ls /dev/<dev?

Mogelijk kun je met dstat of iostat -xm 5 zien hoeveel verkeer over je disks gaan.

Als dit werkt dan bewijfel ik of het hardware is.

[ Voor 48% gewijzigd door Q op 04-03-2020 22:01 ]

[hansdegit]

Tsja, het systeem (en de voeding) is 6 jaar oud. Op zich was het al even tijd om eea te vervangen.

Rare dingen gedaan: mwoah, een scrub. En toen geconstateerd dat er erg veel checksum errors waren op /dev/gpt/ssd1. Reboot gedaan, en misschien wel een device losgekoppeld tijdens het vervolg van de scrub. Is dat heel erg? Zou niet moeten, vind ik, maar ik heb de software niet geschreven.

[ Voor 59% gewijzigd door hansdegit op 04-03-2020 22:30 ]

[Q]

Ik weet niet hoe anderen er over denken maar 6 jaar voor een voeding is niet vreselijk oud. Hangt een beetje van de kwalteit/prijs af. Ik ben ook niet zo van het preventief vervangen, ik vraag me af of anderen dat wel doen.

Ik durf er verder niet zoveel over te zeggen.

[hansdegit]

't Is een Seasonic van 360W (pricewatch: Seasonic G-series 360 watt)

Was altijd een prima ding, maar uiteindelijk ga ik toch iets nieuws bakken, dus dan is een voeding een prima eerste aanschaf. 't Is alleen dat dit probleem niet helemaal lekker getimed is. Normaalgesproken kan ik mezelf maanden lang verkneukelen bij het uitzoeken van nieuwe hardware en nu voelt het als een "moetje".

Ik heb op dit moment eigenlijk geen ruimte voor zo'n nieuw projectje.

[FireDrunk]

Dat is echt een prima voeding, die zou nog niet aan het einde van zijn levensduur moeten zijn...

Heb je nou al naar mijn punten gekeken?

[hansdegit]

Nee @FireDrunk ! de tijd ontbreekt me op dit moment. Denk niet dat ik je tips niet ter harte neem, hoor. 't Is gewoon even een gekkenhuis (grote verbouwing thuis en mn werk verdient ook aandacht).

[Thralas]

hansdegit schreef op woensdag 4 maart 2020 @ 14:32:
Is er iets wat ik met command-line dingen kan proberen om eea verder uit te sluiten?

Met zdb het label van de disks bekijken. Aangenomen dat deze 'm ook niet ziet zou ik beniewd zijn naar wat er wél staat (althans, volgens de controller).

zdb -l /dev/nvme0n1p2
head -c 65536 /dev/nvme0n1p2 | hexdump -C

..want op een intacte disk zie je het label zelfs zo in een hexdump.

[ Voor 3% gewijzigd door Thralas op 06-03-2020 12:14 ]

[hansdegit]

@Thralas

Het zdb commando geeft m.i. heel leesbare info. Kan je specifieke zaken noemen waar ik op moet letten?

code:

------------------------------------
LABEL 0
------------------------------------
    version: 28
    name: 'flashpool'
    state: 0
    txg: 9997652
    pool_guid: 16464963977959785148
    hostid: 1501423073
    hostname: 'zfsserver'
    top_guid: 1399636153582128311
    guid: 14203667806721998607
    vdev_children: 1
    vdev_tree:
        type: 'raidz'
        id: 0
        guid: 1399636153582128311
        nparity: 1
        metaslab_array: 37
        metaslab_shift: 35
        ashift: 12
        asize: 5000991866880
        is_log: 0
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 15906662527662901730
            path: '/dev/gpt/ssd1'
            whole_disk: 1
            DTL: 593275
            create_txg: 4
        children[1]:
            type: 'disk'
            id: 1
            guid: 3613398654120934556
            path: '/dev/gpt/ssd2'
            whole_disk: 1
            DTL: 593269
            create_txg: 4
            removed: 1
        children[2]:
            type: 'disk'
            id: 2
            guid: 14203667806721998607
            path: '/dev/gpt/ssd3'
            whole_disk: 1
            DTL: 593274
            create_txg: 4
        children[3]:
            type: 'disk'
            id: 3
            guid: 16565702290378247892
            path: '/dev/gpt/ssd4'
            whole_disk: 1
            DTL: 593270
            create_txg: 4
        children[4]:
            type: 'disk'
            id: 4
            guid: 18427777116630032338
            path: '/dev/gpt/ssd5'
            whole_disk: 1
            DTL: 593273
            create_txg: 4
    features_for_read:
------------------------------------
LABEL 1
------------------------------------
    version: 28
    name: 'flashpool'
    state: 0
    txg: 9997652
    pool_guid: 16464963977959785148
    hostid: 1501423073
    hostname: 'zfsserver'
    top_guid: 1399636153582128311
    guid: 14203667806721998607
    vdev_children: 1
    vdev_tree:
        type: 'raidz'
        id: 0
        guid: 1399636153582128311
        nparity: 1
        metaslab_array: 37
        metaslab_shift: 35
        ashift: 12
        asize: 5000991866880
        is_log: 0
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 15906662527662901730
            path: '/dev/gpt/ssd1'
            whole_disk: 1
            DTL: 593275
            create_txg: 4
        children[1]:
            type: 'disk'
            id: 1
            guid: 3613398654120934556
            path: '/dev/gpt/ssd2'
            whole_disk: 1

[...]

Gaat nog even door...

de voortgang van dit topic gaat wat sloom, maar dat wijt ik aan tijdgebrek. Jullie input wordt enorm gewaardeerd! Dank!

[Q]

Als je tijd zo beperkt is dan zou ik mijn instructie met 'dd' hierboven eerst opvolgen.

Want als dat stabiel is gedurende zeg een uurtje, dan acht ik de kans een stuk kleiner dat het met hardware te maken heeft. Die test zet een zware belasting op al je schijven en je controller (en dus ook op de voeding).

Maar als het wel met hardware te maken heeft dan kun je uren naar ZFS staren zonder dat je wijzer wordt.

[ Voor 12% gewijzigd door Q op 08-03-2020 00:04 ]

[hansdegit]

Hoi Q,

"jouw" dd heb ik uitgevoerd en dat was compleet zonder foutmeldingen. Ging redelijk snel, overigens.

Ik start 'em gewoon nog eens. Gewoon nog maar eens een "zpool status" gedraaid, omdat het kan...:

code:

root@zfsserver:~ # zpool status
  pool: flashpool
 state: FAULTED
status: One or more devices could not be used because the label is missing
        or invalid.  There are insufficient replicas for the pool to continue
        functioning.
action: Destroy and re-create the pool from
        a backup source.
   see: http://illumos.org/msg/ZFS-8000-5E
  scan: none requested
config:

        NAME                      STATE     READ WRITE CKSUM
        flashpool                 FAULTED      0     0     1
          raidz1-0                ONLINE       0     0     6
            gpt/ssd1              ONLINE       0     0     1
            gpt/ssd2              ONLINE       0     0     0
            14203667806721998607  UNAVAIL      0     0     0  was /dev/gpt/ssd3
            16565702290378247892  UNAVAIL      0     0     0  was /dev/gpt/ssd4
            18427777116630032338  UNAVAIL      0     0     0  was /dev/gpt/ssd5

  pool: zroot
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          da0p3     ONLINE       0     0     0

errors: No known data errors

Voor de goede orde: alle SSD's zijn aangesloten.

[ Voor 82% gewijzigd door hansdegit op 08-03-2020 09:26 ]

[Thralas]

hansdegit schreef op zaterdag 7 maart 2020 @ 21:41:
@Thralas

Het zdb commando geeft m.i. heel leesbare info. Kan je specifieke zaken noemen waar ik op moet letten?

Dat is zo te zien het label van ssd3? Aangezien zdb een label ziet lijkt dat in ieder geval oké.

Zou het misschien kunnen zijn dat de disks out-of-sync zijn geraakt door een issue met de controller? Ik weet niet hoe ZFS dat weergeeft.

Probeer eens:

zdb -CCG flashpool

Als het goed is probeert zdb dan zelf de pool te laden, met een hoop extra debug output. En hopelijk probeert hij nog iets met de disks die de kernel als UNAVAIL markeert.

Je zou ook nog uberblocks kunnen vergelijken op een werkende/niet-werkende member:

zdb -ul <disk>

(zelf even de meest recente entry zoeken)

Om de een-of-andere reden spuugt jouw zdb alle labels uit, die van mij laat er maar één zien (zouden toch hetzelfde moeten zijn)

[ Voor 16% gewijzigd door Thralas op 08-03-2020 22:07 ]

[hansdegit]

code:

root@zfsserver:~ # zdb -CCG flashpool
zdb: can't open 'flashpool': Input/output error

ZFS_DBGMSG(zdb):
spa_open_common: opening flashpool
spa_load(flashpool, config trusted): LOADING
disk vdev '/dev/gpt/ssd3': best uberblock found for spa flashpool. txg 9997654
spa_load(flashpool, config untrusted): using uberblock with txg=9997654
spa_load(flashpool, config untrusted): FAILED: couldn't get 'config' value in MOS directory [error=5]
spa_load(flashpool, config untrusted): UNLOADING

Ik denk dat je zdb -ul bedoelt...Spuugt heel veel uit, even interpreren

[Thralas]

zdb inderdaad

Die foutmelding suggereert dat er metadata corrupt is. Misschien kun je de pool wel importeren met een oudere transaction group?

zpool import -F zou dat moeten proberen, als ik de man page/internet goed begrijp kun je daar -n aan toevoegen om enkel te checken of recovery mogelijk is. Dus -Fn. En -FXn (maar lees vooral de man page over -X, al lijkt het me dat je dat met -n veilig kunt proberen)

[ Voor 7% gewijzigd door Thralas op 08-03-2020 22:46 ]

[hansdegit]

meeeeh,

code:

 zpool import -F --rewind-to-checkpoint flashpool
cannot import 'flashpool': I/O error
        Destroy and re-create the pool from
        a backup source.

'k Moest 'em eerst exporteren.

de -n optie deed helemaal niets, geen melding, niets.

't Wordt een beetje een gebed zonder end, zo lijkt.

Resumerend:
het begon met die checkpoint errors; dat lijkt natuurlijk op een niet zo'n fijn hardwareprobleem. Ik vermoed dat de scrub daarna de boel heeft verergerd.

[hansdegit]

Memtest inmiddels gedraaid, geen fouten.

import -FX resulteert in bootloop. Dat wil zeggen: bij opstarten van FreeBSD probeert het systeem de pool te "laden" . Ik vermoed dat dat een import is. Maar dan ontstaat er een "Solaris panic" en een reboot.

Ik ga nog proberen met een ander bord, maar zie mezelf daarna toch heel snel een nieuwe pool aanmaken en de cloud backup terug te zetten. Veel VM's opnieuw optuigen, gat in mn database...Jammer allemaal; ik had gehoopt dat dit soort problemen juist met ZFS tot het verleden zouden behoren.

Maargoed: ook weer een kans om nieuwe dingen te leren.

[FireDrunk]

Nou ga ik het nog maar een keer vragen: Wat zegt dmesg tijdens fouten, en heb je al in meer logs van je systeem gekeken?

[hansdegit]

Ik snap je ongeduld Firedrunk.

Het is een beetje lastig om een dmesg te vergaren van een systeem in bootloop. Dus nu heb ik een oude ZFSguru live CD eraan gehangen. Dit is de dmesg van die boot:

code:

Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.2-RELEASE-p1 #0 r287022: Sat Aug 22 09:34:56 UTC 2015
    [e-mail]:/ZFSguru/src/sys/OFED-POLLING-ALTQ amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
VT: running with driver "vga".
CPU: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz (3292.38-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c  Stepping=3
  Features=0xf83fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,SS>
  Features2=0xfffa3203<SSE3,PCLMULQDQ,SSSE3,FMA,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x21<LAHF,ABM>
  Structured Extended Features=0x272a<TSCADJ,BMI1,AVX2,BMI2,ERMS,INVPCID,NFPUSG>
  XSAVE Features=0x1<XSAVEOPT>
  TSC: P-state invariant
Hypervisor: Origin = "VMwareVMware"
real memory  = 8589934592 (8192 MB)
avail memory = 8247267328 (7865 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <PTLTD          APIC  >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  2
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 1.1> irqs 0-23 on motherboard
kbd1 at kbdmux0
module_register_init: MOD_LOAD (vesa, 0xffffffff80e93170, 0) error 19
random: <Software, Yarrow> initialized
acpi0: <INTEL 440BX> on motherboard
acpi0: Power Button (fixed)
Timecounter "HPET" frequency 14318180 Hz quality 950
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
isab0: <PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX4 UDMA33 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1060-0x106f at device 7.1 on pci0
ata0: <ATA channel> at channel 0 on atapci0
ata1: <ATA channel> at channel 1 on atapci0
pci0: <bridge> at device 7.3 (no driver attached)
vgapci0: <VGA-compatible display> port 0x1070-0x107f mem 0xe8000000-0xefffffff,0xfe000000-0xfe7fffff irq 16 at device 15.0 on pci0
vgapci0: Boot video device
mpt0: <LSILogic 1030 Ultra4 Adapter> port 0x1400-0x14ff mem 0xfeba0000-0xfebbffff,0xfebc0000-0xfebdffff irq 17 at device 16.0 on pci0
mpt0: MPI Version=1.2.0.0
pcib2: <ACPI PCI-PCI bridge> at device 17.0 on pci0
pci2: <ACPI PCI bus> on pcib2
uhci0: <UHCI (generic) USB controller> port 0x20c0-0x20df irq 18 at device 0.0 on pci2
usbus0 on uhci0
em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.6> port 0x2000-0x203f mem 0xfd5a0000-0xfd5bffff,0xfdff0000-0xfdffffff irq 19 at device 1.0 on pci2
em0: Ethernet address: 00:0c:29:6b:a5:cf
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfd5cf000-0xfd5cffff irq 16 at device 2.0 on pci2
usbus1: EHCI version 1.0
usbus1 on ehci0
em1: <Intel(R) PRO/1000 Legacy Network Connection 1.0.6> port 0x2040-0x207f mem 0xfd580000-0xfd59ffff,0xfdfe0000-0xfdfeffff irq 18 at device 4.0 on pci2
em1: Ethernet address: 00:0c:29:6b:a5:d9
em2: <Intel(R) PRO/1000 Legacy Network Connection 1.0.6> port 0x2080-0x20bf mem 0xfd560000-0xfd57ffff,0xfdfd0000-0xfdfdffff irq 19 at device 5.0 on pci2
em2: Ethernet address: 00:0c:29:6b:a5:e3
pcib3: <ACPI PCI-PCI bridge> at device 21.0 on pci0
pci3: <ACPI PCI bus> on pcib3
mps0: <Avago Technologies (LSI) SAS2308> port 0x4000-0x40ff mem 0xfd4f0000-0xfd4fffff,0xfd480000-0xfd4bffff irq 18 at device 0.0 on pci3
mps0: Firmware: 19.00.00.00, Driver: 20.00.00.00-fbsd
mps0: IOCCapabilities: 5285c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,HostDisc>
pcib4: <ACPI PCI-PCI bridge> at device 21.1 on pci0
pci4: <ACPI PCI bus> on pcib4
pcib5: <ACPI PCI-PCI bridge> at device 21.2 on pci0
pci5: <ACPI PCI bus> on pcib5
pcib6: <ACPI PCI-PCI bridge> at device 21.3 on pci0
pci6: <ACPI PCI bus> on pcib6
pcib7: <ACPI PCI-PCI bridge> at device 21.4 on pci0
pci7: <ACPI PCI bus> on pcib7
pcib8: <ACPI PCI-PCI bridge> at device 21.5 on pci0
pci8: <ACPI PCI bus> on pcib8
pcib9: <ACPI PCI-PCI bridge> at device 21.6 on pci0
pci9: <ACPI PCI bus> on pcib9
pcib10: <ACPI PCI-PCI bridge> at device 21.7 on pci0
pci10: <ACPI PCI bus> on pcib10
pcib11: <ACPI PCI-PCI bridge> at device 22.0 on pci0
pci11: <ACPI PCI bus> on pcib11
pcib12: <ACPI PCI-PCI bridge> at device 22.1 on pci0
pci12: <ACPI PCI bus> on pcib12
pcib13: <ACPI PCI-PCI bridge> at device 22.2 on pci0
pci13: <ACPI PCI bus> on pcib13
pcib14: <ACPI PCI-PCI bridge> at device 22.3 on pci0
pci14: <ACPI PCI bus> on pcib14
pcib15: <ACPI PCI-PCI bridge> at device 22.4 on pci0
pci15: <ACPI PCI bus> on pcib15
pcib16: <ACPI PCI-PCI bridge> at device 22.5 on pci0
pci16: <ACPI PCI bus> on pcib16
pcib17: <ACPI PCI-PCI bridge> at device 22.6 on pci0
pci17: <ACPI PCI bus> on pcib17
pcib18: <ACPI PCI-PCI bridge> at device 22.7 on pci0
pci18: <ACPI PCI bus> on pcib18
pcib19: <ACPI PCI-PCI bridge> at device 23.0 on pci0
pci19: <ACPI PCI bus> on pcib19
pcib20: <ACPI PCI-PCI bridge> at device 23.1 on pci0
pci20: <ACPI PCI bus> on pcib20
pcib21: <ACPI PCI-PCI bridge> at device 23.2 on pci0
pci21: <ACPI PCI bus> on pcib21
pcib22: <ACPI PCI-PCI bridge> at device 23.3 on pci0
pci22: <ACPI PCI bus> on pcib22
pcib23: <ACPI PCI-PCI bridge> at device 23.4 on pci0
pci23: <ACPI PCI bus> on pcib23
pcib24: <ACPI PCI-PCI bridge> at device 23.5 on pci0
pci24: <ACPI PCI bus> on pcib24
pcib25: <ACPI PCI-PCI bridge> at device 23.6 on pci0
pci25: <ACPI PCI bus> on pcib25
pcib26: <ACPI PCI-PCI bridge> at device 23.7 on pci0
pci26: <ACPI PCI bus> on pcib26
pcib27: <ACPI PCI-PCI bridge> at device 24.0 on pci0
pci27: <ACPI PCI bus> on pcib27
pcib28: <ACPI PCI-PCI bridge> at device 24.1 on pci0
pci28: <ACPI PCI bus> on pcib28
pcib29: <ACPI PCI-PCI bridge> at device 24.2 on pci0
pci29: <ACPI PCI bus> on pcib29
pcib30: <ACPI PCI-PCI bridge> at device 24.3 on pci0
pci30: <ACPI PCI bus> on pcib30
pcib31: <ACPI PCI-PCI bridge> at device 24.4 on pci0
pci31: <ACPI PCI bus> on pcib31
pcib32: <ACPI PCI-PCI bridge> at device 24.5 on pci0
pci32: <ACPI PCI bus> on pcib32
pcib33: <ACPI PCI-PCI bridge> at device 24.6 on pci0
pci33: <ACPI PCI bus> on pcib33
pcib34: <ACPI PCI-PCI bridge> at device 24.7 on pci0
pci34: <ACPI PCI bus> on pcib34
acpi_acad0: <AC Adapter> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model IntelliMouse, device ID 3
orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xdc000-0xdffff,0xe0000-0xe7fff on isa0
ppc0: cannot reserve I/O port range
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
Timecounters tick every 1.000 msec
md0: Preloaded image </boot/preloaded.ufs> 11845632 bytes at 0xffffffff81e3e300
random: unblocking device.
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 480Mbps High Speed USB v2.0
ugen0.1: <0x15ad> at usbus0
uhub0: <0x15ad UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <0x15ad> at usbus1
uhub1: <0x15ad EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
uhub0: 2 ports with 2 removable, self powered
mps0: SAS Address for SATA device = 48262f3a6181436d
mps0: SAS Address from SATA device = 48262f3a6181436d
mps0: SAS Address for SATA device = 48262f3a61814466
mps0: SAS Address from SATA device = 48262f3a61814466
mps0: SAS Address for SATA device = 48262f3a6181437b
mps0: SAS Address from SATA device = 48262f3a6181437b
mps0: SAS Address for SATA device = 48262f3a61814467
mps0: SAS Address from SATA device = 48262f3a61814467
ugen0.2: <VMware> at usbus0
mps0: SAS Address for SATA device = 48262f3a6181427a
mps0: SAS Address from SATA device = 48262f3a6181427a
da0 at mpt0 bus 0 scbus2 target 0 lun 0
da0: <VMware Virtual disk 1.0> Fixed Direct Access SCSI-2 device
da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
da0: Command Queueing enabled
da0: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C)
da0: quirks=0x40<RETRY_BUSY>
cd0 at ata0 bus 0 scbus0 target 0 lun 0
cd0: <NECVMWar VMware IDE CDR00 1.00> Removable CD-ROM SCSI device
cd0: Serial Number 00000000000000000001
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: cd present [216310 x 2048 byte records]
da4 at mps0 bus 0 scbus3 target 3 lun 0
da4: <ATA CT1000MX500SSD1 010> Fixed Direct Access SPC-4 SCSI device
da4: Serial Number 1802E10A8D21
da4: 600.000MB/s transfers
da4: Command Queueing enabled
da4: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da3 at mps0 bus 0 scbus3 target 2 lun 0
da3: <ATA CT1000MX500SSD1 010> Fixed Direct Access SPC-4 SCSI device
da3: Serial Number 1802E10A8D1E
da3: 600.000MB/s transfers
da3: Command Queueing enabled
da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da5 at mps0 bus 0 scbus3 target 4 lun 0
da5: <ATA CT1000MX500SSD1 010> Fixed Direct Access SPC-4 SCSI device
da5: Serial Number 1802E10A8D0D
da5: 600.000MB/s transfers
da5: Command Queueing enabled
da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da1 at mps0 bus 0 scbus3 target 0 lun 0
da1: <ATA CT1000MX500SSD1 010> Fixed Direct Access SPC-4 SCSI device
da1: Serial Number 1802E10A8D17
da1: 600.000MB/s transfers
da1: Command Queueing enabled
da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da2 at mps0 bus 0 scbus3 target 1 lun 0
da2: <ATA CT1000MX500SSD1 010> Fixed Direct Access SPC-4 SCSI device
da2: Serial Number 1802E10A8D20
da2: 600.000MB/s transfers
da2: Command Queueing enabled
da2: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
Running ipoib_init_module (0xffffffff80b9dbb0)
SMP: AP CPU #1 Launched!
Root mount waiting for: usbus1 usbus0
ugen0.3: <vendor 0x0e0f> at usbus0
uhub2: <VMware Virtual USB Hub> on usbus0
uhub1: 6 ports with 6 removable, self powered
uhub2: 7 ports with 7 removable, self powered
Trying to mount root from ufs:/dev/md0 []...
md1.uzip: 17655 x 65536 blocks
md1.uzip: 57416 requests, 33376 cached
ums0: <VMware> on usbus0
ums0: 8 buttons and [XYZ] coordinates ID=0
[root@zfsguru ~]#

Ik ben even aan t uitvogelen hoe ik een dmesg kan laten zien van het moment waarop de import van de pool misgaat.

[Thralas]

Lijkt me niet heel handig om daar dan een 5 jaar outdated en unmaintained-distributie voor te gebruiken. Dat is zelfs een achteruitgang ten opzichte van wat je eerst had.

Als een recente BSD tegenwerkt dan zou ik een recente Linux met ZoL proberen.

De ZFS module retourneert overigens zelf ook -EIO, dus een I/O-error hoeft geen hardware I/O error te zijn.

[hansdegit]

Ja, eens hoor.

'k Heb er nu een nieuw moederbord ingeschroefd. Nog even een passende koeler erop en dan kunnen we verder spelen.

[hansdegit]

Final wrap-up:

Moederbord vervangen, paar nieuwe SSD's erin en opgeschaald naar een RAIDZ2. En toen kreeg ik foutmeldingen op een nieuwe SSD...

Uiteindelijk was het een voedingsprobleem. Dat wil zeggen: een brakke SATA connector die aan een molex hing. Ik kon een SSD horen "zingen" en om de haverklap vloog de SSD die aan dezelfde y-cable hing eruit (dat was dus de nieuwe SSD).

Ik heb de y-cable vervangen. Weg is het gezang en de array functioneert eindelijk foutloos. Fingers crossed, natuurlijk.

Dit geintje heeft één SSD het leven gekost; best jammer, want hij was twee weken voorbij de garantie.

Allemaal bedankt voor jullie hulp. Iemand nog een X10SL7-F mobo nodig?

[FireDrunk]

https://tweakers.net/aanbod/

Eind goed, al goed, in ieder geval.

[Q]

Bedankt dat je de uitkomst met ons hebt gedeeld, niet iedereen doet dat. Het was inderdaad dus de voeding maar niet zoals ik dat bedoelde, het was een kabel van de voeding, de voeding zelf was dus nog prima.