Het grote ZFS topic

[willemw12]

code:

zpool status data -v

. Misschien zie je dan welke file die checksum error heeft.

[CH4OS]

willemw12 schreef op maandag 12 juli 2021 @ 18:14:

code:

zpool status data -v

. Misschien zie je dan welke file die checksum error heeft.

Ja, die zie ik, maar dat lost het issue van de migratie van de data niet op natuurlijk, vandaar dat ik dat stukje weggelaten heb. Het punt is namelijk dat de faulted disk, precies de disk is die ik vervangen heb voor een 14TB disk, maar desondanks alsnog als faulted in de lijst terug komt.

De file in kwestie verwijderd (is geen belangrijk document of zo) en de pool is er niet opeens goed door.
(Was ook te mooi geweest om waar te zijn)

Middels een scrubbing is die error in elk geval nu weg, hou ik nog wel een faulted disk over, die vervangen is voor een 14TB disk. Als ik de 2TB disk terug doe in plaats van de 14TB disk, dan is mijn gedachte gang nu in elk geval dat de pool weer healthy zou moeten zijn, klopt dat? Dit is in elk geval de huidige zpool status output:

  pool: data
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
  scan: scrub canceled on Mon Jul 12 18:46:15 2021
config:

        NAME                      STATE     READ WRITE CKSUM
        data                      DEGRADED     0     0     0
          raidz1-0                DEGRADED     0     0     0
            sdd                   ONLINE       0     0     2
            sdc                   ONLINE       0     0     2
            13984520045058853556  FAULTED      0     0     0  was /dev/sde1
            sdb                   ONLINE       0     0     2
          raidz1-1                ONLINE       0     0     0
            sdh                   ONLINE       0     0     0
            sdg                   ONLINE       0     0     0
            sdi                   ONLINE       0     0     0
            sdf                   ONLINE       0     0     0

errors: No known data errors

@CurlyMo en/of @HyperBart Moet ik nu nog een keer zpool replace data sde sdc doen? SDC is althans volgens lsblk de 14TB disk:

sda      8:0    0  100G  0 disk
├─sda1   8:1    0   98G  0 part /
└─sda2   8:2    0    2G  0 part
sdb      8:16   0  1.8T  0 disk
├─sdb1   8:17   0  1.8T  0 part
└─sdb9   8:25   0    8M  0 part
sdc      8:32   0 12.8T  0 disk
├─sdc1   8:33   0 12.8T  0 part
└─sdc9   8:41   0    8M  0 part
sdd      8:48   0  1.8T  0 disk
├─sdd1   8:49   0  1.8T  0 part
└─sdd9   8:57   0    8M  0 part
sde      8:64   0  1.8T  0 disk
├─sde1   8:65   0  1.8T  0 part
└─sde9   8:73   0    8M  0 part
sdf      8:80   0  3.7T  0 disk
├─sdf1   8:81   0  3.7T  0 part
└─sdf9   8:89   0    8M  0 part
sdg      8:96   0  3.7T  0 disk
├─sdg1   8:97   0  3.7T  0 part
└─sdg9   8:105  0    8M  0 part
sdh      8:112  0  3.7T  0 disk
├─sdh1   8:113  0  3.7T  0 part
└─sdh9   8:121  0    8M  0 part
sdi      8:128  0  3.7T  0 disk
├─sdi1   8:129  0  3.7T  0 part
└─sdi9   8:137  0    8M  0 part
sr0     11:0    1 1024M  0 rom

Of kan ik nu ik morgen een sata kabel krijg beter wachten tot morgen?

[ Voor 111% gewijzigd door CH4OS op 12-07-2021 18:53 ]

[willemw12]

Met "zpool clear data" kan je in de meeste gevallen die checksums weer op 0 zetten. Weet niet of dat hier ook kan.

Maar wacht wel eerst even op advies van anderen.

[CH4OS]

willemw12 schreef op maandag 12 juli 2021 @ 18:53:
Met "zpool clear data" kan je in de meeste gevallen die checksums weer op 0 zetten. Weet niet of dat hier ook kan.

Volgens mij is dat niet echt meer de issue, de file die permanent error had, is immers weg? Dat de teller nu op 2 staat, komt denk ik omdat ik de file heb proberen te verplaatsen naar mijn desktop, wat niet lukte. Aangezien het ook geen belangrijk bestand is (alle data die er op staat is niet heel super belangrijk zoals bijvoorbeeld een CV) heb ik de file verwijderd, komt vast wel een keer terug, zeg maar.

[ Voor 42% gewijzigd door CH4OS op 12-07-2021 18:56 ]

[RobertMe]

Heb je de replace gedaan met beide disks aangesloten en online? Of heb je alleen de nieuwe schijf geplaatst, oude eruit gehaald/gelaten, en toen de replace gedaan? Want dat zal neem ik aan een groot verschil maken. Immers kan die in de situatie met beide disks aangesloten gewoon de data van de oude schijf lezen en op de nieuwe zetten. Is de oude niet aangesloten dan zal die de data opnieuw moeten opbouwen / berekenen op basis van de twee overgebleven schijven. Zou mij niks verbazen als die juist daarom in het laatste geval de oude schijf op faulted zet. Immers is de schijf ook al een tijdje "vermist" en niet "officieel afgemeld" in de pool.

Als je die ene schijf standalone aansluit zal een zpool import hem waarschijnlijk ook zien/herkennen, maar uiteraard niet kunnen importeren omdat er nog een aanwezig moet zijn. En ik vraag mij af of dat ook het geval is als de schijf online is tijdens de replace.

[CH4OS]

Ik heb maar 8 poorten beschikbaar op de controller en ze zijn alle acht in gebruik. De bewuste 2TB disk heb ik dus eruit moeten halen anders kon ik de data niet laten herstellen naar de 14TB schijf. Immers de andere disks kunnen de data die er zou moeten staan herstellen.

Morgen kan ik kijken of ik de onboard Marvel controller kan doorgeven aan de VM en daarop een disk aansluiten om een van de 2TB disks te vervangen. Op die manier kan ik dan dus @HyperBart's advies opvolgen.

[ Voor 33% gewijzigd door CH4OS op 12-07-2021 19:08 ]

[willemw12]

Je heb RAID-Z1, dus maar 1 redundante disk per VDEV. Dus liefst die oude 2TB disk meteen weer terug doen. Hopelijk accepteert ZFS die disk weer. Misschien een scrub doen om de pool weer healthy te maken.

Morgen met de nieuwe SATA + power kabels een nieuwe 14TB disk aansluiten en een disk replace doen.

[Ravefiend]

CH4OS schreef op maandag 12 juli 2021 @ 18:05:
SDC is trouwens in dit overzicht de eerste disk van 14TB.

@CH4OS Even tussendoor een vraagje hierover: is dat dan al zo'n disk die je uit een WD Elements hebt geplukt? If so, welk type/model hard disk steekt WD er tegenwoordig in? (CMR versus SMR enzo).

[CH4OS]

Ravefiend schreef op maandag 12 juli 2021 @ 19:27:
[...]

@CH4OS Even tussendoor een vraagje hierover: is dat dan al zo'n disk die je uit een WD Elements hebt geplukt? If so, welk type/model hard disk steekt WD er tegenwoordig in? (CMR versus SMR enzo).

Het SMR verhaal speelt voor disks van 2TB-6TB, alles daarboven is altijd CMR geweest. Kun je gewoon terugvinden op internet. Dit is ook een van de redenen voor mij geweest om groter dan 6TB te pakken. Snap niet waarom hier nog steeds een heisa om is, maar goed.

Dus op zich hoef je je niet af te vragen of nog SMR gebruikt wordt, voor disks groter dan 6TB doet WD dat per definitie gewoon niet.

[ Voor 18% gewijzigd door CH4OS op 12-07-2021 19:31 ]

[willemw12]

WD doet dat nog niet voor >6TB.

[HyperBart]

Ravefiend schreef op maandag 12 juli 2021 @ 19:27:
[...]

@CH4OS Even tussendoor een vraagje hierover: is dat dan al zo'n disk die je uit een WD Elements hebt geplukt? If so, welk type/model hard disk steekt WD er tegenwoordig in? (CMR versus SMR enzo).

In die Elements zitten EDAZ'en, althans dat was bij mijn 6 exemplaren van de 12TB variant zo.


@CH4OS je hebt volgens mij het "label probleem" aan de hand. De foutmelding zegt het ook specifiek "because the label is missing or invalid".

Als je kijkt naar je lsblk dan zie je ook dat er "een" device is wat thans een label draagt wat normaal gebruikt zou moeten worden maar waar ZFS van zegt dat er iets niet klopt. @FireDrunk is heel wat wijzer over dat soort dingen, ik werk al jaren dankzij zijn tips op basis van labels ipv die sdX naamgeving.

Je moet die replace in alle geval NIET doen, want die is al in gebruik.

[ Voor 33% gewijzigd door HyperBart op 12-07-2021 19:47 ]

[CH4OS]

HyperBart schreef op maandag 12 juli 2021 @ 19:38:
[...]


[Afbeelding]

In die Elements zitten EDAZ'en, althans dat was bij mijn 6 exemplaren van de 12TB variant zo.

Ik heb vier EDFZ, die staan niet in de afbeelding, maar zijn helium gevuld met CMR.

EDIT:
Ook bedankt voor de uitleg, @HyperBart, ik kan dan het beste gewoon de oude disk terug doen en dan - alsnog - de disks op basis van UUID koppelen, zoals iemand recent al eerder tegen me zei.

[ Voor 18% gewijzigd door CH4OS op 12-07-2021 19:51 ]

[RobertMe]

HyperBart schreef op maandag 12 juli 2021 @ 19:38:
[...]


[Afbeelding]

In die Elements zitten EDAZ'en, althans dat was bij mijn 6 exemplaren van de 12TB variant zo.

WD lijkt voornamelijk erin te stoppen waar ze zin in hebben. Zo waren vroeger de 8TB modellen met helium, maar de nieuwere zouden dat weer niet zijn. En er is idd EDAZ, maar ook EMAZ en nog wat varianten en dat kan ook gewoon verschillen tussen batches. An zich ook niet heel gek, immers is de voornaamste spec van een externe schijf de grote. Je gaat geen externe schijf uitzoeken op of die helium of lucht gevuld is etc etc. Wat WD dus ook nog eens probeert te manipuleren door niet altijd specificaties te benoemen maar te spreken over "prestaties gelijkwaardig aan", waarbij het stiekeme SMR verhaal een mooi voorbeeld is. Want volgens WD zijn de prestaties gelijk aan het type apparaat dat ze benoemen. Oftewel: de SMR schijven voldoen aan "5400 rpm class schijven voor bv gebruik in een NAS".

[CurlyMo]

@CH4OS Ik snap ook je output niet. Een schijf hoort niet op faulted te staan als je die netjes met een replace hebt vervangen. Hier is dus iemand anders aan de hand.

[CH4OS]

Ik heb nu de 2TB disk weer terug gedaan, waardoor ik qua disks de oude situatie weer heb. Na importeren een zpool status gedaan en daarvan is de output nu als volgt:

   pool: data
     id: 1681985799723901396
  state: DEGRADED
status: One or more devices contains corrupted data.
 action: The pool can be imported despite missing or damaged devices.  The
        fault tolerance of the pool may be compromised if imported.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
 config:

        data        DEGRADED
          raidz1-0  DEGRADED
            sdd     ONLINE
            sdc     FAULTED  corrupted data
            sdc     ONLINE
            sdb     ONLINE
          raidz1-1  ONLINE
            sdh     ONLINE
            sdg     ONLINE
            sdi     ONLINE
            sdf     ONLINE

SDC was in elk geval tijdens mijn eerste poging van de migratie de 14TB disk.

[ Voor 4% gewijzigd door CH4OS op 12-07-2021 20:02 ]

[Thralas]

CH4OS schreef op maandag 12 juli 2021 @ 18:28:
Middels een scrubbing is die error in elk geval nu weg

Werp nog even een blik op je kernel logs en/of SMART. Een checksum error op drie verschillende disks suggereert dat het niet aan de disks ligt, maar iets anders aan de hand is (bv. ALPM). Nuttig om in ieder geval te kijken hoe dat er op kernel-niveau uitzag.

Begrijp dat je nu al met een 'veiligere' replace aan de slag probeert te gaan (voor zover mogelijk), maar als dat niet mogelijk is dan zou ik erg voorzichtig zijn als je weet dat er onverklaarbare checksum errors optreden (dat zou immers een unrecoverable error op kunnen leveren zolang je pool degraded is.

HyperBart schreef op maandag 12 juli 2021 @ 19:38:
Als je kijkt naar je lsblk dan zie je ook dat er "een" device is wat thans een label draagt wat normaal gebruikt zou moeten worden maar waar ZFS van zegt dat er iets niet klopt. @FireDrunk is heel wat wijzer over dat soort dingen, ik werk al jaren dankzij zijn tips op basis van labels ipv die sdX naamgeving.

Ho ho, je hebt labels en labels.

Een label in zfs context is metadata die de disk en/of pool beschrijft. Te zien met zdb -l. Jij bedoelt GPT partitielabels, dat is iets anders..

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 20:01:
SDC was in elk geval tijdens mijn eerste poging van de migratie de 14TB disk.

Wat bedoel je nu precies? Hoort die sdc nu de 14TB of de 2TB te zijn voor je zfs pool? Punt is dat je met een van die 2 schijven een redundante pool moet hebben. Anders gaan er andere dingen mis die je eerst moet fixen.

[Ravefiend]

De vrije keuze die WD heeft voor externe schijven maakt dat het soms een gokje is wat je in werkelijkheid gaat krijgen, en soms ook hoe de schijf gaat presteren. Net zoals die 14TB EDFZ van @CH4OS daarvan had men vastgesteld dat de throughput deels werd gelimiteerd tot +- 200MB/s. Dat maakt het daarom niet minder interessant want goedkopere drives tenzij dan mss wanneer de data gestriped is over meerdere disks RAIDZ1/2 die dan niet allemaal een gelijkwaardige throughput kunnen aanhouden?

https://www.reddit.com/r/...4tb_drives_get_30_faster/

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 20:06:
Wat bedoel je nu precies? Hoort die sdc nu de 14TB of de 2TB te zijn voor je zfs pool? Punt is dat je met een van die 2 schijven een redundante pool moet hebben. Anders gaan er andere dingen mis die je eerst moet fixen.

Ik heb nu de oude situatie weer hersteld en alle 14TB disks zijn er dus weer uit. Gisteren heb ik de eerste disk gemigreerd, toen heb ik SDE (die op degraded stond en missing op de status die ik vanavond gaf) laten vervangen voor SDC. Nu mist de pool dus SDC en staat de disk daardoor dus op degraded.

Ik begrin bijna het idee te krijgen dat ik alles beter gewoon wegflikker wat er op staat (zoveel belangrijks staat er toch niet op) en dat ik dan twee nieuwe vdev's aanmaak.

[ Voor 4% gewijzigd door CH4OS op 12-07-2021 20:10 ]

[HyperBart]

Thralas schreef op maandag 12 juli 2021 @ 20:03:
[...]


Werp nog even een blik op je kernel logs en/of SMART. Een checksum error op drie verschillende disks suggereert dat het niet aan de disks ligt, maar iets anders aan de hand is (bv. ALPM). Nuttig om in ieder geval te kijken hoe dat er op kernel-niveau uitzag.

Begrijp dat je nu al met een 'veiligere' replace aan de slag probeert te gaan (voor zover mogelijk), maar als dat niet mogelijk is dan zou ik erg voorzichtig zijn als je weet dat er onverklaarbare checksum errors optreden (dat zou immers een unrecoverable error op kunnen leveren zolang je pool degraded is.


[...]


Ho ho, je hebt labels en labels.

Een label in zfs context is metadata die de disk en/of pool beschrijft. Te zien met zdb -l. Jij bedoelt GPT partitielabels, dat is iets anders..

Ok, ik bedoelde identifiers en labels inderdaad ja, maar het was duidelijk

@CH4OS mij ben je compleet kwijt hoor. Je had die pool nu beter correct met die UUID's kunnen importeren, want wat is nu echt sdc en wat is de valse sdc?

Nu heb je die 2TB terug gehangen en die 14TB er terug af? Dan gaat er wat stuk ja, en al helemaal als de boel in de war is omdat die identifiers gewisseld zijn en je zit te swappen.

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 20:09:
[...]
Ik heb nu de oude situatie weer hersteld en alle 14TB disks zijn er dus weer uit. Gisteren heb ik de eerste disk gemigreerd, toen heb ik SDE (die op degraded stond) laten vervangen voor SDC. Nu mist de pool dus SDC en staat de disk daardoor dus op degraded.

Ik begrin bijna het idee te krijgen dat ik alles beter gewoon wegflikker wat er op staat (zoveel belangrijks staat er toch niet op) en dat ik dan twee nieuwe vdev's aanmaak.

Twee dingen:
- Waar @RobertMe al terecht op wees zijn de SD* labels niet bar betrouwbaar. Deze willen nog wel eens veranderen. Stellen dat een schijf de ene keer SDC bij een nieuwe situatie alsnog SDC is, is niet hard te stellen. ZFS is slim genoeg om te merken dat SDC de vorige SDA was. De stelling die je koppelt aan deze labels lijkt dus niet echt hout te snijden.
- Je zal met ofwel met de 2TB of met de 14TB een goed werkende pool terug moeten krijgen.

Ik zou dus beginnen met eens je pool te importeren met de -d /dev/disk/by-id/ optie zodat je zeker weet met welke schijven je aan het werk bent tussen verandering van configuratie.

Daarna zou ik proberen je pool weer netjes online te krijgen. Als je meer risico wil lopen dan zou ik z.s.m. die degraded schijf vervangen door een nieuwe 14TB zodat je weer een werkende pool krijgt.

[willemw12]

Dat met die /dev/sdX opmerking, dat was ik die ermee begon.

Dit is een goede les. Kan net zo goed doorgaan.

Doe een "zpool export data" daarna een "zpool import -d /dev/disk/by-label" o.i.d. voor de duidelijkheid (zpool status).

ZFS gebruikt zelf ook nog interne UUIDs voor disks als extra check.

[ Voor 14% gewijzigd door willemw12 op 12-07-2021 20:20 ]

[HyperBart]

Ja, duw nu even door @CH4OS , altijd leerrijk en liever nu met alle mogelijkheden dan dat het de volgende keer mis gaat.

Hier de laatste tabel, /r/datahoarder op Reddit is een schat van informatie:

[ Voor 39% gewijzigd door HyperBart op 12-07-2021 20:19 ]

[CH4OS]

willemw12 schreef op maandag 12 juli 2021 @ 20:14:
Dat met die /dev/sdX opmerking, dat was ik die ermee begon.

Dit is een goede les. Kan net zo goed doorgaan.

Doe een "zpool export data" daarna een "zpool import -d /dev/disk/by-label" o.i.d. voor de duidelijkheid (zpool status).

ZFS gebruikt zelf ook nog interne UUIDs voor disks als extra check.

Ik ben nu dus de disks stuk voor stuk aan het toevoegen (nadat ik een zpool export heb gedaan) met by-partuuid, onder uuid heb ik deze disks niet staan.

De disk die nu als sde1 bekend staat, kan ik nu althans niet importeren in de pool. Dit komt naar ik aanneem, omdat de 14TB daar zojuist op zat.

HyperBart schreef op maandag 12 juli 2021 @ 20:16:
Ja, duw nu even door @CH4OS , altijd leerrijk en liever nu met alle mogelijkheden dan dat het de volgende keer mis gaat.

Hier de laatste tabel, /r/datahoarder op Reddit is een schat van informatie:

[Afbeelding]

True that, maar aan de andere kant, gezien mijn postgeschiedenis hier in het topic, lijk ik of hardleers, of blijft het toch niet plakken. Heb je van die afbeelding de directe URL? Ik kan deze zo niet lezen in elk geval.

[ Voor 42% gewijzigd door CH4OS op 12-07-2021 20:25 ]

[willemw12]

Stuk voor stuk? Zpool import is in 1 stap. Of doe je wat anders?

[CH4OS]

willemw12 schreef op maandag 12 juli 2021 @ 20:25:
Stuk voor stuk? Zpool import is in 1 stap. Of doe je wat anders?

Ik heb nu disk voor disk geimporteerd, middels zpool import -d /dev/disk/by-partuuid/[uuid], zoals je zelf eerder al aangaf.

[ Voor 5% gewijzigd door CH4OS op 12-07-2021 20:26 ]

[HyperBart]

CH4OS schreef op maandag 12 juli 2021 @ 20:26:
[...]
Ik heb nu disk voor disk geimporteerd, middels zpool import -d /dev/disk/by-partuuid/[uuid], zoals je zelf eerder al aangaf.

Doe eens gewoon

zpool import -d /dev/disk/by-partuuid/ data

want zoals men hierboven al zei: importeren is gewoon pool importeren in één slag en klaar, niet disk per disk.

[ Voor 15% gewijzigd door HyperBart op 12-07-2021 20:30 ]

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 20:23:
[...]
Ik ben nu dus de disks stuk voor stuk aan het toevoegen (nadat ik een zpool export heb gedaan) met by-partuuid, onder uuid heb ik deze disks niet staan.

De disk die nu als sde1 bekend staat, kan ik nu althans niet importeren in de pool. Dit komt naar ik aanneem, omdat de 14TB daar zojuist op zat.

Dit is echt niet te volgen. Doe maar even letterlijk wat @HyperBart zegt en daarna nog een zpool status hier plaatsen.

[CH4OS]

HyperBart schreef op maandag 12 juli 2021 @ 20:28:
[...]


Doe eens gewoon

zpool import -d /dev/disk/by-partuuid/ data

root@VM-DOCKER:~# zpool import -d /dev/disk/by-partuuid/ data
root@VM-DOCKER:~# zpool status
  pool: data
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
  scan: scrub canceled on Mon Jul 12 18:46:15 2021
config:

        NAME                                      STATE     READ WRITE CKSUM
        data                                      DEGRADED     0     0     0
          raidz1-0                                DEGRADED     0     0     0
            4b3ee5a3-b004-a84c-afbe-cb15678a3292  ONLINE       0     0     0
            17842497405783188795                  FAULTED      0     0     0  was /dev/sdc1
            80113319-440a-eb44-bfcc-a0e3fb8767d0  ONLINE       0     0     0
            ad6b142d-80c9-784f-b89a-0df10587c30e  ONLINE       0     0     0
          raidz1-1                                ONLINE       0     0     0
            781dca8d-aeb8-5c4b-a0dd-3196b1e83f8e  ONLINE       0     0     0
            fa725f27-5cf5-4942-ba0a-fff2de2f7fb2  ONLINE       0     0     0
            d9b5ed5f-fbf8-7749-85c2-3d8074738d52  ONLINE       0     0     0
            d78c3107-2ee8-9d46-8857-b21df9f4d9de  ONLINE       0     0     0

errors: No known data errors

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 20:29:
[...]

Dit is echt niet te volgen. Doe maar even letterlijk wat @HyperBart zegt en daarna nog een zpool status hier plaatsen.

Ja, dat vermoedde ik al, zie hierboven.

[HyperBart]

Ok en nu nog een mapping van je schijven en die id's tesamen met een lijstje van je huidig fysiek aangesloten disks en we zijn al wat dichter.

[CH4OS]

HyperBart schreef op maandag 12 juli 2021 @ 20:31:
Ok en nu nog een mapping van je schijven en die id's tesamen met een lijstje van je huidig fysiek aangesloten disks en we zijn al wat dichter.

Ik heb wel even enkel de broodnodige info gegeven (lijst was langer):

4b3ee5a3-b004-a84c-afbe-cb15678a3292 -> ../../sdd1
781dca8d-aeb8-5c4b-a0dd-3196b1e83f8e -> ../../sdh1
80113319-440a-eb44-bfcc-a0e3fb8767d0 -> ../../sdc1
ad6b142d-80c9-784f-b89a-0df10587c30e -> ../../sdb1
d78c3107-2ee8-9d46-8857-b21df9f4d9de -> ../../sdf1
d9b5ed5f-fbf8-7749-85c2-3d8074738d52 -> ../../sdi1
f10af815-9e75-1149-84ab-57c5d53939e4 -> ../../sde1
fa725f27-5cf5-4942-ba0a-fff2de2f7fb2 -> ../../sdg1

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 20:34:
[...]
Ik heb wel even enkel de broodnodige info gegeven (lijst was langer)

Doe maar even zo:

lsblk -r|awk 'NR==1{print $0" DEVICE-ID(S)"}NR>1{dev=$1;printf $0" ";system("find /dev/disk/by-id -lname \"*"dev"\" -printf \" %p\"");print "";}'

https://unix.stackexchange.com/a/502674

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 20:35:
[...]

Doe maar even zo:

lsblk -r|awk 'NR==1{print $0" DEVICE-ID(S)"}NR>1{dev=$1;printf $0" ";system("find /dev/disk/by-id -lname \"*"dev"\" -printf \" %p\"");print "";}'

https://unix.stackexchange.com/a/502674

root@VM-DOCKER:~# lsblk -r|awk 'NR==1{print $0" DEVICE-ID(S)"}NR>1{dev=$1;printf $0" ";system("find /dev/disk/by-id -lname \"*"dev"\" -printf \" %p\"");print "";}'
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT DEVICE-ID(S)
sda 8:0 0 100G 0 disk
sda1 8:1 0 98G 0 part /
sda2 8:2 0 2G 0 part
sdb 8:16 0 1.8T 0 disk   /dev/disk/by-id/wwn-0x50014ee20d8a0437 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3
sdb1 8:17 0 1.8T 0 part   /dev/disk/by-id/wwn-0x50014ee20d8a0437-part1 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3-part1
sdb9 8:25 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee20d8a0437-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3-part9
sdc 8:32 0 1.8T 0 disk   /dev/disk/by-id/wwn-0x50014ee2b83503a8 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H
sdc1 8:33 0 1.8T 0 part   /dev/disk/by-id/wwn-0x50014ee2b83503a8-part1 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H-part1
sdc9 8:41 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b83503a8-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H-part9
sdd 8:48 0 1.8T 0 disk   /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC /dev/disk/by-id/wwn-0x50014ee2b83461cf
sdd1 8:49 0 1.8T 0 part   /dev/disk/by-id/wwn-0x50014ee2b83461cf-part1 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC-part1
sdd9 8:57 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b83461cf-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC-part9
sde 8:64 0 1.8T 0 disk   /dev/disk/by-id/wwn-0x50014ee2b834f65d /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE
sde1 8:65 0 1.8T 0 part   /dev/disk/by-id/wwn-0x50014ee2b834f65d-part1 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE-part1
sde9 8:73 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b834f65d-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE-part9
sdf 8:80 0 3.7T 0 disk   /dev/disk/by-id/wwn-0x50014ee2640c673d /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1
sdf1 8:81 0 3.7T 0 part   /dev/disk/by-id/wwn-0x50014ee2640c673d-part1 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1-part1
sdf9 8:89 0 8M 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1-part9 /dev/disk/by-id/wwn-0x50014ee2640c673d-part9
sdg 8:96 0 3.7T 0 disk   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD /dev/disk/by-id/wwn-0x50014ee2b95eb52e
sdg1 8:97 0 3.7T 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD-part1 /dev/disk/by-id/wwn-0x50014ee2b95eb52e-part1
sdg9 8:105 0 8M 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD-part9 /dev/disk/by-id/wwn-0x50014ee2b95eb52e-part9
sdh 8:112 0 3.7T 0 disk   /dev/disk/by-id/wwn-0x50014ee2b964b755 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3
sdh1 8:113 0 3.7T 0 part   /dev/disk/by-id/wwn-0x50014ee2b964b755-part1 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3-part1
sdh9 8:121 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b964b755-part9 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3-part9
sdi 8:128 0 3.7T 0 disk   /dev/disk/by-id/wwn-0x50014ee2113d18a8 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C
sdi1 8:129 0 3.7T 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C-part1 /dev/disk/by-id/wwn-0x50014ee2113d18a8-part1
sdi9 8:137 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2113d18a8-part9 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C-part9
sr0 11:0 1 1024M 0 rom   /dev/disk/by-id/ata-VMware_Virtual_SATA_CDRW_Drive_00000000000000000001

Kan ik trouwens niet gewoon de vdev met de 4 4Tb disks niet loshalen voor de timebeing, of is die vdev ook nodig? Als die vdev namelijk niet nodig is, heb ik de SATA kabel morgen ook niet nodig en kan ik nu toch al de data migreren?

[HyperBart]

CH4OS schreef op maandag 12 juli 2021 @ 20:40:
[...]

root@VM-DOCKER:~# lsblk -r|awk 'NR==1{print $0" DEVICE-ID(S)"}NR>1{dev=$1;printf $0" ";system("find /dev/disk/by-id -lname \"*"dev"\" -printf \" %p\"");print "";}'
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT DEVICE-ID(S)
sda 8:0 0 100G 0 disk
sda1 8:1 0 98G 0 part /
sda2 8:2 0 2G 0 part
sdb 8:16 0 1.8T 0 disk   /dev/disk/by-id/wwn-0x50014ee20d8a0437 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3
sdb1 8:17 0 1.8T 0 part   /dev/disk/by-id/wwn-0x50014ee20d8a0437-part1 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3-part1
sdb9 8:25 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee20d8a0437-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3-part9
sdc 8:32 0 1.8T 0 disk   /dev/disk/by-id/wwn-0x50014ee2b83503a8 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H
sdc1 8:33 0 1.8T 0 part   /dev/disk/by-id/wwn-0x50014ee2b83503a8-part1 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H-part1
sdc9 8:41 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b83503a8-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H-part9
sdd 8:48 0 1.8T 0 disk   /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC /dev/disk/by-id/wwn-0x50014ee2b83461cf
sdd1 8:49 0 1.8T 0 part   /dev/disk/by-id/wwn-0x50014ee2b83461cf-part1 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC-part1
sdd9 8:57 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b83461cf-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC-part9
sde 8:64 0 1.8T 0 disk   /dev/disk/by-id/wwn-0x50014ee2b834f65d /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE
sde1 8:65 0 1.8T 0 part   /dev/disk/by-id/wwn-0x50014ee2b834f65d-part1 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE-part1
sde9 8:73 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b834f65d-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE-part9
sdf 8:80 0 3.7T 0 disk   /dev/disk/by-id/wwn-0x50014ee2640c673d /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1
sdf1 8:81 0 3.7T 0 part   /dev/disk/by-id/wwn-0x50014ee2640c673d-part1 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1-part1
sdf9 8:89 0 8M 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1-part9 /dev/disk/by-id/wwn-0x50014ee2640c673d-part9
sdg 8:96 0 3.7T 0 disk   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD /dev/disk/by-id/wwn-0x50014ee2b95eb52e
sdg1 8:97 0 3.7T 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD-part1 /dev/disk/by-id/wwn-0x50014ee2b95eb52e-part1
sdg9 8:105 0 8M 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD-part9 /dev/disk/by-id/wwn-0x50014ee2b95eb52e-part9
sdh 8:112 0 3.7T 0 disk   /dev/disk/by-id/wwn-0x50014ee2b964b755 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3
sdh1 8:113 0 3.7T 0 part   /dev/disk/by-id/wwn-0x50014ee2b964b755-part1 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3-part1
sdh9 8:121 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b964b755-part9 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3-part9
sdi 8:128 0 3.7T 0 disk   /dev/disk/by-id/wwn-0x50014ee2113d18a8 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C
sdi1 8:129 0 3.7T 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C-part1 /dev/disk/by-id/wwn-0x50014ee2113d18a8-part1
sdi9 8:137 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2113d18a8-part9 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C-part9
sr0 11:0 1 1024M 0 rom   /dev/disk/by-id/ata-VMware_Virtual_SATA_CDRW_Drive_00000000000000000001

Kan ik trouwens niet gewoon de vdev met de 4 4Tb disks niet loshalen voor de timebeing, of is die vdev ook nodig? Als die vdev namelijk niet nodig is, heb ik de SATA kabel morgen ook niet nodig en kan ik nu toch al de data migreren?

Leuke denkwijze maar neen. Je mist een stukje van kennis over ZFS manier van werken (da's niet erg, maar dat moeten we wel even recht zetten)/

Een pool is een verzameling van vdev's, die vdev's maken ieder integraal deel uit van de pool. Een pool heeft altijd een vdev.

Je kan dus niet zomaar vdev's weghalen want daar staat data op en het is een deel van je pool.

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 20:40:
[...]

Dan wijk ik toch even van @HyperBart af. Kan je dit doen i.p.v. wat hij voorstelde:
zpool import -d /dev/disk/by-id/ data

En vanzelfsprekend weer de zpool status plaatsen.

[ Voor 11% gewijzigd door CurlyMo op 12-07-2021 20:43 ]

[Thralas]

CH4OS schreef op maandag 12 juli 2021 @ 20:23:
Ik ben nu dus de disks stuk voor stuk aan het toevoegen (nadat ik een zpool export heb gedaan) met by-partuuid, onder uuid heb ik deze disks niet staan.

Ik zou by-id gebruiken voor het importeren. Dan zie je tenminste een disk model en serienummer (als het goed is) in plaats van een nietszeggend partitie-uuid...

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 20:43:
[...]

Dan wijk ik toch even van @HyperBart af. Kan je dit doen i.p.v. wat hij voorstelde:
zpool import -d /dev/disk/by-id/ data

En vanzelfsprekend weer de zpool status plaatsen.

root@VM-DOCKER:~# zpool import -d /dev/disk/by-id/ data
root@VM-DOCKER:~# zpool status
  pool: data
 state: DEGRADED
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: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: resilvered 14.9M in 00:04:03 with 1 errors on Mon Jul 12 20:33:52 2021
config:

        NAME                                          STATE     READ WRITE CKSUM
        data                                          DEGRADED     0     0     0
          raidz1-0                                    DEGRADED     0     0     0
            wwn-0x50014ee2b83461cf                    ONLINE       0     0     0
            17842497405783188795                      FAULTED      0     0     0  was /dev/sdc1
            wwn-0x50014ee2b83503a8                    ONLINE       0     0     0
            wwn-0x50014ee20d8a0437                    ONLINE       0     0     0
          raidz1-1                                    ONLINE       0     0     0
            wwn-0x50014ee2b964b755                    ONLINE       0     0     0
            wwn-0x50014ee2b95eb52e                    ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C  ONLINE       0     0     0
            wwn-0x50014ee2640c673d                    ONLINE       0     0     0

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

De output van zpool status -v:

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

        data:<0x0>

Deze kan ik fixen door te scrubben, dus dat doe ik nu even.

[HyperBart]

CurlyMo schreef op maandag 12 juli 2021 @ 20:43:
[...]

Dan wijk ik toch even van @HyperBart af. Kan je dit doen i.p.v. wat hij voorstelde:
zpool import -d /dev/disk/by-id/ data

En vanzelfsprekend weer de zpool status plaatsen.

Na de import besefte ik inderdaad dat ik ergens uuid heb gecopypaste. By Id had dat moeten zijn.

[CH4OS]

Hmmm, het scrubben heeft in dit geval geen resultaat op de errors.

[CurlyMo]

Even samenvattend:

1.8T	ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3	wwn-0x50014ee20d8a0437
1.8T	ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H	wwn-0x50014ee2b83503a8
1.8T	ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC	wwn-0x50014ee2b83461cf
1.8T	ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE	wwn-0x50014ee2b834f65d
3.7T	ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1	wwn-0x50014ee2640c673d
3.7T	ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD	wwn-0x50014ee2b95eb52e
3.7T	ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3	wwn-0x50014ee2b964b755
3.7T	ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C	wwn-0x50014ee2113d18a8

@CH4OS kan je dit overzicht blijven bijwerken als je schijven verwisselt? Kan je nu dus even de 14TB weer aansluiten die je gebruikt heb bij het replacen en dan aanvullen op dit lijstje.

[Thralas]

CH4OS schreef op maandag 12 juli 2021 @ 20:45:
wwn-0x50014ee2640c673d ONLINE 0 0 0

Ook niet handig. Nu pakt hij wwns in plaats van ata-*.

mv /dev/disk/by-id/wwn* /tmp/
zpool import -d /dev/disk/by-id/ data
mv /tmp/wwn* /dev/disk/by-id/

Dan hoef je ook niet te klooien met het bijhouden van tabelletjes.

[CH4OS]

Thralas schreef op maandag 12 juli 2021 @ 20:55:
[...]


Ook niet handig. Nu pakt hij wwns in plaats van ata-*.

mv /dev/disk/by-id/wwn* /tmp/
zpool import -d /dev/disk/by-id/ data
mv /tmp/wwn* /dev/disk/by-id/

Dan hoef je ook niet te klooien met het bijhouden van tabelletjes.

En wat gaat dit precies doen dan? Krijg ik er nieuwe IDs door of zo?

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 21:07:
[...]
En wat gaat dit precies doen dan? Krijg ik er nieuwe IDs door of zo?

Die zorgt ervoor dat in mijn lijstje je alleen de eerste ID's krijgt i.p.v. de tweede.

[CH4OS]

Dus alleen de ata-WDC_*?

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 21:11:
Dus alleen de ata-WDC_*?

Check

[CH4OS]

Ik moet nog wel de 14TB even in de machine doen en daarna weer rebooten. Lijkt me dat ik het beste dat als laatste kan doen dan?

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 21:12:
Ik moet nog wel de 14TB even in de machine doen en daarna weer rebooten. Lijkt me dat ik het beste dat als laatste kan doen dan?

Yep. Dan hebben we een compleet overzicht.

[Thralas]

-

[ Voor 99% gewijzigd door Thralas op 12-07-2021 21:14 ]

[CH4OS]

En nu met 14TB disk:

root@VM-DOCKER:~# lsblk -r|awk 'NR==1{print $0" DEVICE-ID(S)"}NR>1{dev=$1;printf $0" ";system("find /dev/disk/by-id -lname \"*"dev"\" -printf \" %p\"");print "";}'
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT DEVICE-ID(S)
sdb 8:16 0 1.8T 0 disk   /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3 /dev/disk/by-id/wwn-0x50014ee20d8a0437
sdb1 8:17 0 1.8T 0 part   /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3-part1 /dev/disk/by-id/wwn-0x50014ee20d8a0437-part1
sdb9 8:25 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee20d8a0437-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3-part9
sdc 8:32 0 12.8T 0 disk   /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_XHG53D8H /dev/disk/by-id/wwn-0x5000cca299c2529a
sdc1 8:33 0 12.8T 0 part   /dev/disk/by-id/wwn-0x5000cca299c2529a-part1 /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_XHG53D8H-part1
sdc9 8:41 0 8M 0 part   /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_XHG53D8H-part9 /dev/disk/by-id/wwn-0x5000cca299c2529a-part9
sdd 8:48 0 1.8T 0 disk   /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC /dev/disk/by-id/wwn-0x50014ee2b83461cf
sdd1 8:49 0 1.8T 0 part   /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC-part1 /dev/disk/by-id/wwn-0x50014ee2b83461cf-part1
sdd9 8:57 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b83461cf-part9 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC-part9
sde 8:64 0 1.8T 0 disk   /dev/disk/by-id/wwn-0x50014ee2b834f65d /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE
sde1 8:65 0 1.8T 0 part   /dev/disk/by-id/wwn-0x50014ee2b834f65d-part1 /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE-part1
sde9 8:73 0 8M 0 part   /dev/disk/by-id/ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE-part9 /dev/disk/by-id/wwn-0x50014ee2b834f65d-part9
sdf 8:80 0 3.7T 0 disk   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1 /dev/disk/by-id/wwn-0x50014ee2640c673d
sdf1 8:81 0 3.7T 0 part   /dev/disk/by-id/wwn-0x50014ee2640c673d-part1 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1-part1
sdf9 8:89 0 8M 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1-part9 /dev/disk/by-id/wwn-0x50014ee2640c673d-part9
sdg 8:96 0 3.7T 0 disk   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD /dev/disk/by-id/wwn-0x50014ee2b95eb52e
sdg1 8:97 0 3.7T 0 part   /dev/disk/by-id/wwn-0x50014ee2b95eb52e-part1 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD-part1
sdg9 8:105 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b95eb52e-part9 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD-part9
sdh 8:112 0 3.7T 0 disk   /dev/disk/by-id/wwn-0x50014ee2b964b755 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3
sdh1 8:113 0 3.7T 0 part   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3-part1 /dev/disk/by-id/wwn-0x50014ee2b964b755-part1
sdh9 8:121 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2b964b755-part9 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3-part9
sdi 8:128 0 3.7T 0 disk   /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C /dev/disk/by-id/wwn-0x50014ee2113d18a8
sdi1 8:129 0 3.7T 0 part   /dev/disk/by-id/wwn-0x50014ee2113d18a8-part1 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C-part1
sdi9 8:137 0 8M 0 part   /dev/disk/by-id/wwn-0x50014ee2113d18a8-part9 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C-part9
sr0 11:0 1 1024M 0 rom   /dev/disk/by-id/ata-VMware_Virtual_SATA_CDRW_Drive_00000000000000000001

En een nieuwe zpool status:

root@VM-DOCKER:~# zpool status
  pool: data
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
  scan: resilvered 3.91M in 00:00:03 with 0 errors on Mon Jul 12 21:31:00 2021
config:

        NAME                                          STATE     READ WRITE CKSUM
        data                                          DEGRADED     0     0     0
          raidz1-0                                    DEGRADED     0     0     0
            wwn-0x50014ee2b83461cf                    ONLINE       0     0     0
            sdc                                       ONLINE       0     0     1
            13984520045058853556                      UNAVAIL      0     0     0  was /dev/disk/by-id/wwn-0x50014ee2b83503a8-part1
            wwn-0x50014ee20d8a0437                    ONLINE       0     0     0
          raidz1-1                                    ONLINE       0     0     0
            wwn-0x50014ee2b964b755                    ONLINE       0     0     0
            wwn-0x50014ee2b95eb52e                    ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C  ONLINE       0     0     0
            wwn-0x50014ee2640c673d                    ONLINE       0     0     0

errors: No known data errors

Thralas schreef op maandag 12 juli 2021 @ 20:55:
[...]


Ook niet handig. Nu pakt hij wwns in plaats van ata-*.

mv /dev/disk/by-id/wwn* /tmp/
zpool import -d /dev/disk/by-id/ data
mv /tmp/wwn* /dev/disk/by-id/

Dan hoef je ook niet te klooien met het bijhouden van tabelletjes.

Ik ga nu de 2TB disk terug doen, daarna ga ik dit doen.

[ Voor 3% gewijzigd door CH4OS op 12-07-2021 21:40 ]

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 21:37:
En nu met 14TB disk:

De 14TB is nu dus blijkbaar sdc.

Nu alleen nog even wwn-0x50014ee2b83503a8 (WCC4M3VXYT5H) terug doen en wwn-0x50014ee2b834f65d (WCC4M2UASUUE) weglaten.

Dan moet je pool weer werken.

Zou dan nog mooi zijn als je wat minder eigenwijs zou zijn zodat ik dit niet alsnog hoeft te vragen
- Ik vroeg je mijn lijstje bij te werken met de 14TB.
- Je hebt weer een zpool status met sdc i.p.v. ata-*, dus weer even een export / import doen met de juiste parameters.

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 21:54:
De 14TB is nu dus blijkbaar sdc.

Ja, wat ik de hele tijd al zei.

Nu alleen nog even wwn-0x50014ee2b83503a8 (WCC4M3VXYT5H) terug doen en wwn-0x50014ee2b834f65d (WCC4M2UASUUE) weglaten.

Dan moet je pool weer werken.

Ik heb nu de 14TB disk er weer uitgehaald. Of ik de oude 2TB terug doe, of de 14TB, maakt dus niet meer uit, in beide gevallen heb ik een degraded state van de pool. Met de oude 2TB terug, ziet het wel het beste eruit.

Zou dan nog mooi zijn als je wat minder eigenwijs zou zijn zodat ik dit niet alsnog hoeft te vragen
- Ik vroeg je mijn lijstje bij te werken met de 14TB.

Ben al blij dat ik het eruit krijg, lol.

- Je hebt weer een zpool status met sdc i.p.v. ata-*, dus weer even een export / import doen met de juiste parameters.

Ja, ik zei dat ik dat zou doen als de oude disks weer terug zijn, die zijn dat nu, dus kan ik de juiste ID's toekennen.

[ Voor 5% gewijzigd door CH4OS op 12-07-2021 22:02 ]

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 22:01:
[...]
Ik heb nu de 14TB disk er weer uitgehaald. Of ik de oude 2TB terug doe, of de 14TB, maakt dus niet meer uit, in beide gevallen heb ik een degraded state van de pool. Met de oude 2TB terug, ziet het wel het beste eruit.

Dat brengt je pool alleen niet online. Je moet gewoon letterlijk doen wat ik zeg. Voordeel van de ID's is dat je die als het goed is ook fysiek op je schijven kan zien. Dus kijk daar even naar en plaats de juiste schijven in je systeem.

Ook zie ik nog steeds het bijgewerkte lijstje niet.

[ Voor 4% gewijzigd door CurlyMo op 12-07-2021 22:04 ]

[CH4OS]

En de samenvatting met alle disks in kwestie:

1.8T	ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3	wwn-0x50014ee20d8a0437
1.8T	ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H	wwn-0x50014ee2b83503a8
1.8T	ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC	wwn-0x50014ee2b83461cf
1.8T	ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2UASUUE	wwn-0x50014ee2b834f65d
3.7T	ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1	wwn-0x50014ee2640c673d
3.7T	ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD	wwn-0x50014ee2b95eb52e
3.7T	ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3	wwn-0x50014ee2b964b755
3.7T	ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C	wwn-0x50014ee2113d18a8
12.8T	ata-WDC_WD140EDFZ-11A0VA0_XHG53D8H		wwn-0x5000cca299c2529a

CurlyMo schreef op maandag 12 juli 2021 @ 22:03:
Ook zie ik nog steeds het bijgewerkte lijstje niet.

Ik kan inderdaad niet heksen of toveren, sorry.

@CurlyMo Ik begrijp ook niet waarom ik de ene 2TB weg moet laten en een andere van 2TB erin moet doen? Dan start ik op met drie disks in deze vdev, klopt dat? De vdev bestond immers uit de 4 2TB disks?

EDIT: Om een of andere reden kan ik ook niet meer de pool exporteren, volgens Debian is het nu steeds ingebruik. Geen idee waarom.

[ Voor 28% gewijzigd door CH4OS op 12-07-2021 22:15 ]

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 22:04:
Ik begrijp ook niet waarom ik de ene 2TB weg moet laten en een andere van 2TB erin moet doen? Dan start ik op met drie disks in deze vdev, klopt dat?

Dit is hoe je werkende pool er nu uit zou moeten zien:

        data                                          ONLINE       0     0     0
          raidz1-0                                    ONLINE       0     0     0
            wwn-0x50014ee2b83461cf                    ONLINE       0     0     0
            wwn-0x5000cca299c2529a                    ONLINE       0     0     0
            wwn-0x50014ee2b83503a8                    ONLINE       0     0     0
            wwn-0x50014ee20d8a0437                    ONLINE       0     0     0
          raidz1-1                                    ONLINE       0     0     0
            wwn-0x50014ee2b964b755                    ONLINE       0     0     0
            wwn-0x50014ee2b95eb52e                    ONLINE       0     0     0
            wwn-0x50014ee2113d18a8                    ONLINE       0     0     0
            wwn-0x50014ee2640c673d                    ONLINE       0     0     0

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 22:15:
[...]

Dit is hoe je werkende pool er nu uit zou moeten zien:

        data                                          ONLINE       0     0     0
          raidz1-0                                    ONLINE       0     0     0
            wwn-0x50014ee2b83461cf                    ONLINE       0     0     0
            wwn-0x5000cca299c2529a                    ONLINE       0     0     0
            wwn-0x50014ee2b83503a8                    ONLINE       0     0     0
            wwn-0x50014ee20d8a0437                    ONLINE       0     0     0
          raidz1-1                                    ONLINE       0     0     0
            wwn-0x50014ee2b964b755                    ONLINE       0     0     0
            wwn-0x50014ee2b95eb52e                    ONLINE       0     0     0
            wwn-0x50014ee2113d18a8                    ONLINE       0     0     0
            wwn-0x50014ee2640c673d                    ONLINE       0     0     0

Dan moet de 14TB dus wel terug in de PC. Oke, dan ga ik dat doen, maar ook dan is de vdev dus degraded.

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 22:17:
[...]
Dan moet de 14TB dus wel terug in de PC. Oke, dan ga ik dat doen, maar ook dan is de vdev dus degraded.

Dat komt omdat je niet de juiste 2TB's erbij zet. Vergelijk mijn overzicht maar met de jouwe.

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 22:18:
Dat komt omdat je niet de juiste 2TB's erbij zet. Vergelijk mijn overzicht maar met de jouwe.

Ik heb steeds dezelfde verwisseld? Maar goed, dubbelchecken kan geen kwaad natuurlijk.

[ Voor 10% gewijzigd door CH4OS op 12-07-2021 22:19 ]

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 22:18:
[...]
Ik heb steeds dezelfde verwisseld? Maar goed, dubbelchecken kan geen kwaad natuurlijk.

Dat zei ik hier dus al:

Nu alleen nog even wwn-0x50014ee2b83503a8 (WCC4M3VXYT5H) terug doen en wwn-0x50014ee2b834f65d (WCC4M2UASUUE) weglaten.

Hier lijkt het telkens mis te gaan. Tenminste aan de hand van je output te zien.

[ Voor 3% gewijzigd door CurlyMo op 12-07-2021 22:26 ]

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 22:15:
[...]

Dit is hoe je werkende pool er nu uit zou moeten zien:

        data                                          ONLINE       0     0     0
          raidz1-0                                    ONLINE       0     0     0
            wwn-0x50014ee2b83461cf                    ONLINE       0     0     0
            wwn-0x5000cca299c2529a                    ONLINE       0     0     0
            wwn-0x50014ee2b83503a8                    ONLINE       0     0     0
            wwn-0x50014ee20d8a0437                    ONLINE       0     0     0
          raidz1-1                                    ONLINE       0     0     0
            wwn-0x50014ee2b964b755                    ONLINE       0     0     0
            wwn-0x50014ee2b95eb52e                    ONLINE       0     0     0
            wwn-0x50014ee2113d18a8                    ONLINE       0     0     0
            wwn-0x50014ee2640c673d                    ONLINE       0     0     0

Sorry dat ik deze post weer quote, maar de disks zitten nu op de opgegeven wijze in de machine. Die boot nu. Ik post zometeen even weer een nieuwe zpool status.

EDIT:
@CurlyMo zoals ik al voorspelde, is de zpool status niet goed:

root@VM-DOCKER:~# zpool status
  pool: data
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
  scan: resilvered 524K in 00:00:01 with 0 errors on Mon Jul 12 21:48:28 2021
config:

        NAME                                          STATE     READ WRITE CKSUM
        data                                          DEGRADED     0     0     0
          raidz1-0                                    DEGRADED     0     0     0
            wwn-0x50014ee2b83461cf                    ONLINE       0     0     0
            17842497405783188795                      FAULTED      0     0     0  was /dev/sdc1
            wwn-0x50014ee2b83503a8                    ONLINE       0     0     0
            wwn-0x50014ee20d8a0437                    ONLINE       0     0     0
          raidz1-1                                    ONLINE       0     0     0
            wwn-0x50014ee2b964b755                    ONLINE       0     0     0
            wwn-0x50014ee2b95eb52e                    ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C  ONLINE       0     0     0
            wwn-0x50014ee2640c673d                    ONLINE       0     0     0

errors: No known data errors

En ik kan de pool ook nog steeds niet exporten.

[ Voor 38% gewijzigd door CH4OS op 12-07-2021 22:36 ]

[CurlyMo]

@CH4OS Verwijst /dev/sdc1 inderdaad naar je 14TB schijf?

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 22:36:
@CH4OS Verwijst /dev/sdc1 inderdaad naar je 14TB schijf?

Nee, dat is sde1:

root@VM-DOCKER:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   0  1.8T  0 disk
├─sdb1   8:17   0  1.8T  0 part
└─sdb9   8:25   0    8M  0 part
sdc      8:32   0  1.8T  0 disk
├─sdc1   8:33   0  1.8T  0 part
└─sdc9   8:41   0    8M  0 part
sdd      8:48   0  1.8T  0 disk
├─sdd1   8:49   0  1.8T  0 part
└─sdd9   8:57   0    8M  0 part
sde      8:64   0 12.8T  0 disk
├─sde1   8:65   0 12.8T  0 part
└─sde9   8:73   0    8M  0 part
sdf      8:80   0  3.7T  0 disk
├─sdf1   8:81   0  3.7T  0 part
└─sdf9   8:89   0    8M  0 part
sdg      8:96   0  3.7T  0 disk
├─sdg1   8:97   0  3.7T  0 part
└─sdg9   8:105  0    8M  0 part
sdh      8:112  0  3.7T  0 disk
├─sdh1   8:113  0  3.7T  0 part
└─sdh9   8:121  0    8M  0 part
sdi      8:128  0  3.7T  0 disk
├─sdi1   8:129  0  3.7T  0 part
└─sdi9   8:137  0    8M  0 part

[ Voor 69% gewijzigd door CH4OS op 12-07-2021 22:38 ]

[CurlyMo]

CH4OS schreef op maandag 12 juli 2021 @ 22:37:
[...]
Nee, dat is sde1:

root@VM-DOCKER:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   0  1.8T  0 disk
├─sdb1   8:17   0  1.8T  0 part
└─sdb9   8:25   0    8M  0 part
sdc      8:32   0  1.8T  0 disk
├─sdc1   8:33   0  1.8T  0 part
└─sdc9   8:41   0    8M  0 part
sdd      8:48   0  1.8T  0 disk
├─sdd1   8:49   0  1.8T  0 part
└─sdd9   8:57   0    8M  0 part
sde      8:64   0 12.8T  0 disk
├─sde1   8:65   0 12.8T  0 part
└─sde9   8:73   0    8M  0 part
sdf      8:80   0  3.7T  0 disk
├─sdf1   8:81   0  3.7T  0 part
└─sdf9   8:89   0    8M  0 part
sdg      8:96   0  3.7T  0 disk
├─sdg1   8:97   0  3.7T  0 part
└─sdg9   8:105  0    8M  0 part
sdh      8:112  0  3.7T  0 disk
├─sdh1   8:113  0  3.7T  0 part
└─sdh9   8:121  0    8M  0 part
sdi      8:128  0  3.7T  0 disk
├─sdi1   8:129  0  3.7T  0 part
└─sdi9   8:137  0    8M  0 part

Gebruik aub het andere commando hiervoor. Dan zien we óók die labels, maar ook de id's.

Heb je wel expliciet een import met by-id gedaan? Waren die 14TB wel echt schoon voor gebruik? Plaats eens een fdisk -l?

---

Wat je dus ziet is dat de 14TB wisselt tussen /dev/sdc en /dev/sde afhankelijk van je aangesloten schijven. Aangezien je je replace niet met id's hebt gedaan met systeem labels, raakt ZFS in de war. Je zult in de laatste configuratie moeten zorgen dat die 14TB daadwerkelijk op /dev/sdc terecht komt. Het veiligste is om dat te doen met een udev regel. Zoekterm daarvoor is:

udev persistent disk naming

En dan specifiek voor je OS.

[ Voor 15% gewijzigd door CurlyMo op 12-07-2021 22:53 ]

[CH4OS]

CurlyMo schreef op maandag 12 juli 2021 @ 22:45:
Gebruik aub het andere commando hiervoor. Dan zien we óók die labels, maar ook de id's.

Ik neem aan dat je deze bedoelt:

root@VM-DOCKER:~# lsblk -r|awk 'NR==1{print $0" DEVICE-ID(S)"}NR>1{dev=$1;printf $0" ";system("find /dev/disk/by-id -lname \"*"dev"\" -printf \" %p\"");print "";}' | grep part1
sdb1 1.8T  wwn-0x50014ee2b83503a8-part1 ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H-part1
sdc1 1.8T  wwn-0x50014ee20d8a0437-part1 ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3-part1
sdd1 1.8T  wwn-0x50014ee2b83461cf-part1  ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC-part1 
sde1 12.8T wwn-0x5000cca299c2529a-part1 ata-WDC_WD140EDFZ-11A0VA0_XHG53D8H-part1
sdf1 3.7T wwn-0x50014ee2640c673d-part1 ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1-
sdg1 3.7T wwn-0x50014ee2b95eb52e-part1 ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD-part1 
sdh1 3.7T wwn-0x50014ee2b964b755-part1 ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3-part1 
sdi1 3.7T wwn-0x50014ee2113d18a8-part1 ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C-part1

Voor leesbaarheid heb ik het overzicht wel iets leesbaarder gemaakt.

Heb je wel expliciet een import met by-id gedaan? Waren die 14TB wel echt schoon voor gebruik? Plaats eens een fdisk -l?

Nee, zoals ik net al een paar keer aangeef, ik kan niet eens exporten, ik krijg de melding dat de pool busy is.

[CurlyMo]

@CH4OS Zie mijn aanvulling op mijn vorige reactie.

Dit issue zou je dus niet gehad hebben als je direct met by-id had gewerkt, en je ziet nu hoe onbetrouwbaar systeem labels zijn.

CH4OS schreef op maandag 12 juli 2021 @ 22:52:
[...]
Nee, zoals ik net al een paar keer aangeef, ik kan niet eens exporten, ik krijg de melding dat de pool busy is.

Hier stelde ik overigens nog wat vragen waarvan je er maar één beantwoord.

[ Voor 101% gewijzigd door CurlyMo op 12-07-2021 23:06 ]

[CH4OS]

@CurlyMo Voor hier eigenlijk off topic, maar een DM sturen vind ik dan ook weer zo iets...
Ik draai Debian 10.10 (testing), ik zit op kernel 4.19.0-17, maar in https://wiki.debian.org/Persistent_disk_names zie ik alleen oudere versies? Wat kan ik dan het beste doen? Met Google kom ik verder ook niet veel soeps tegen om een udev rule aan te maken om de disk een vaste schijfnaam te geven.

Ik zie ook dat ik

Waren die 14TB wel echt schoon voor gebruik?

Nog niet beantwoord had.
Er zat eerst een NTFS partitie op de disk (ZFS gaf ook een melding daarover voordat ik de migratie startte), die heb ik met fdisk verwijderd. Daarna gereboot om zeker te zijn dat de nieuwe partitie indeling gebruikt werd door zowel het OS als ZFS. Maar goed, output fdisk -l over de 14TB disk:

Disk /dev/sde: 12.8 TiB, 14000519643136 bytes, 27344764928 sectors
Disk model: WDC WD140EDFZ-11
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: 3DB73A76-287E-8344-9CF2-36175A7079A2

Device           Start         End     Sectors  Size Type
/dev/sde1         2048 27344746495 27344744448 12.8T Solaris /usr & Apple ZFS
/dev/sde9  27344746496 27344762879       16384    8M Solaris reserved 1

Overigens heb ik uiteindelijk de partities laten aanmaken door ZFS zelf (het replace commando effectief).

[ Voor 61% gewijzigd door CH4OS op 12-07-2021 23:31 ]

[Thralas]

CH4OS schreef op maandag 12 juli 2021 @ 23:22:
https://wiki.debian.org/Persistent_disk_names zie ik alleen oudere versies? Wat kan ik dan het beste doen?

Dat wikiartikel is niet relevant. Doe wat ik eerder zei (wwns even moven) - daarna worden die paden als het goed is zo opgeslagen in de zpool.cache, dus je hoeft het maar een keer te doen. Als je niet kunt exporten: zoek uit waarom niet (fuser, lsof en/of zorg er voor dat je zelf niet ergens in /data staat met een shell)

Wil dat allemaal niet, maak dan een mapping aan: Setting up the /etc/zfs/vdev_id.conf file - hierna kun je /dev/disk/by-vdev gebruiken. Zie ook vdev_id.conf voor een voorbeeld (onderaan) waar ze wwns aliasen. Of zet GPT partlabels - whatever works.

Er zat eerst een NTFS partitie op de disk (ZFS gaf ook een melding daarover voordat ik de migratie startte), die heb ik met fdisk verwijderd.

Tip: wipefs gooit ook alle signatures van het filesystem zelf weg ipv. enkel een partitie uit de tabel. En specifiek voor zfs: zpool labelclear. Misschien relevant als hij die 14T disk alsnog niet zomaar slikt (ik ben het overzicht kwijt).

Daarna gereboot om zeker te zijn dat de nieuwe partitie indeling gebruikt werd door zowel het OS als ZFS.

Zou niet nodig moeten zijn.

Overigens heb ik uiteindelijk de partities laten aanmaken door ZFS zelf (het replace commando effectief).

Ja, dat ziet er gewoon goed uit.

Probeer vooral de labels even zo te fixen (hoe dan ook) zodat in een oogopslag duidelijk is welke disk waar zit voordat je weer output post, er staan hierboven inmiddels tig posts met allerlei mappings en veranderlijke sd* names die in principe allemaal overbodig zijn en alleen maar verwarring zaaien voor de meelezer...

[ Voor 4% gewijzigd door Thralas op 13-07-2021 00:23 ]

[CH4OS]

Ik heb de pool eindelijk weer in orde, ik moest de 14TB in een ander slot doen, toen was het goed.
Alleen kan ik nog steeds niet de pool exporteren om de ID's te fixen:

root@VM-DOCKER:~# zpool export data
cannot export 'data': pool is busy

root@VM-DOCKER:~# zpool status
  pool: data
 state: ONLINE
  scan: resilvered 3.59M in 00:00:02 with 0 errors on Tue Jul 13 00:19:06 2021
config:

        NAME                                          STATE     READ WRITE CKSUM
        data                                          ONLINE       0     0     0
          raidz1-0                                    ONLINE       0     0     0
            wwn-0x50014ee2b83461cf                    ONLINE       0     0     0
            sdc                                       ONLINE       0     0     0
            wwn-0x50014ee2b83503a8                    ONLINE       0     0     0
            wwn-0x50014ee20d8a0437                    ONLINE       0     0     0
          raidz1-1                                    ONLINE       0     0     0
            wwn-0x50014ee2b964b755                    ONLINE       0     0     0
            wwn-0x50014ee2b95eb52e                    ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C  ONLINE       0     0     0
            wwn-0x50014ee2640c673d                    ONLINE       0     0     0

[ Voor 69% gewijzigd door CH4OS op 13-07-2021 00:38 ]

[CurlyMo]

CH4OS schreef op dinsdag 13 juli 2021 @ 00:21:
Alleen kan ik nog steeds niet de pool exporteren om de ID's te fixen:

root@VM-DOCKER:~# zpool export data
cannot export 'data': pool is busy

Daar heeft @Thralas al verschillende tips voor gegeven. Anders even exporteren vanaf livecd. Zodra hij geëxporteerd is, wordt hij als het goed is ook niet meer automatisch geïmporteerd.

[ Voor 12% gewijzigd door CurlyMo op 13-07-2021 08:02 ]

[FireDrunk]

Vaak kan je je systeem wel in rescue mode booten zonder livecd, of in single user mode, daar moet de pool wel te exporteren zijn.
Als dat ook niet lukt, kan je *let op, advanced shizzle* ook de cachefile op none zetten met:

zpool set cachefile=none <pool>

bron: https://openzfs.github.io...hen-creating-a-pool-linux

De devicenames staan in de cachefile, waardoor die voorkeur krijgt als je de pool weer zou importeren, tenzij je dus expliciet uit een bepaalde directory importeert.

[CH4OS]

FireDrunk schreef op dinsdag 13 juli 2021 @ 09:16:
Vaak kan je je systeem wel in rescue mode booten zonder livecd, of in single user mode, daar moet de pool wel te exporteren zijn.

True, maar is ZFS in rescue mode beschikbaar onder Debian? Weet ik even niet 100% zeker.

Ik heb vandaag ook de extra SATA kabel ontvangen, dus ik kan vanavond aan de gang met replacen op de juiste manier.

[ Voor 15% gewijzigd door CH4OS op 13-07-2021 13:31 ]

[nero355]

Ik begrijp niet dat iemand zo onvoorbereid omgaat met zijn data...

Wat ik heb gedaan en zou doen :

- Alle 14 TB HDD's door een VOLLEDIGE FORMAT gooien.
Dus geen snelle format, gewoon onder Windows, op het moment dat ze nog steeds in de Externe behuizing zaten!
Waarom : Een dergelijke format zal vastlopen op het moment dat er iets mis is met de HDD en dan kan je die nog omruilen VOORDAT je hem hebt gesloopt

- Daarna ga je pas aan de slag met Linux en ZFS en alles wat erbij komt kijken.
Zorg ervoor dat je een Kernel draait die recent is en de meest recente ZFS versie goed kan ondersteunen.
Daarnaast uiteraard het hele systeem gewoon up-to-date maken/houden.

- Wat betreft ZFS zijn er een hoop Best Practices zowel in dit topic als @ https://openzfs.github.io...hen-creating-a-pool-linux en bijvoorbeeld https://pthree.org/2013/0...st-practices-and-caveats/ te vinden.

Ik heb ontzettend veel aan alle drie gehad toen ik onlangs aan de slag ging met mijn oude 6 x 2 TB HDDtjes en IMHO zou iedereen die met ZFS aan de slag gaat die eerst eens moeten lezen!

En dat zeg ik als iemand die al jarenlang in dit topic meeleest, maar tot voor kort niks daadwerkelijks met ZFS had gedaan

[CurlyMo]

@nero355 Wat ik vooral niet snap (vanuit duurzaamheidsperspectief) dat iemand 4x 14TB schijven gebruikt, maar ook net zo makkelijk roept dat alles wat er op de 4TB versies stond weg mag, want toch niet zo heel belangrijk.

Mijn migratie bestond van 6x 2TB 3.5" energieslurpers naar 3x 5TB 2.5" zuinig en alles wat ik toen nog aan ruimte tekort kwam bestond uit een simpele:

rm -rf /data/films/*
rm -rf /data/series/*

En weer door...

[nero355]

@CurlyMo
Dat is weer iets dat ieder voor zich mag weten en mij echt geen bal kan schelen!

Stroomzuipende hardware ga ik pas erg vinden als het echt belachelijk begint te worden, zoals de huidige videokaarten bijvoorbeeld die echt te ver zijn doorgeslagen!
En dat zeg ik als ex-eigenaar van een Quad Crossfire setup met 4 x HD5870

[CurlyMo]

nero355 schreef op dinsdag 13 juli 2021 @ 17:37:
@CurlyMo
Dat is weer iets dat ieder voor zich mag weten en mij echt geen bal kan schelen!

Klopt, heb hem ook geholpen, maar dit soort dingen zitten wel in mijn achterhoofd.

[CH4OS]

Via de recovery modus de ZFS cache file bijgewerkt;

root@VM-DOCKER:~# zpool status
  pool: data
 state: ONLINE
  scan: scrub canceled on Tue Jul 13 01:14:03 2021
config:

        NAME                                          STATE     READ WRITE CKSUM
        data                                          ONLINE       0     0     0
          raidz1-0                                    ONLINE       0     0     0
            ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC  ONLINE       0     0     0
            ata-WDC_WD140EDFZ-11A0VA0_XHG53D8H        ONLINE       0     0     0
            ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H  ONLINE       0     0     0
            ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3  ONLINE       0     0     0
          raidz1-1                                    ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3  ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD  ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C  ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1  ONLINE       0     0     0

Ik heb voor de rest van de migratie, ook de Marvel controller van het moederbord (zie daarvoor gallery: CH4OS -> VMWare 2.0) doorgegeven middels passthrough. De VM herkend de controllers, maar om de een of andere reden nog niet de tweede 12.8TB disk die ik aangesloten heb. Ik vermoed de SATA kabel, maar dat is kwestie van 'debugging'.

Voor de rest van het migreer proces, moet ik neem ik aan zpool replace [2tb disk] [14tb disk] doen, waarna ik de 14TB disk op dezelfde plek in de computer doe als het vervangen van de disk klaar is?

[HyperBart]

CH4OS schreef op dinsdag 13 juli 2021 @ 18:32:
Via de recovery modus de ZFS cache file bijgewerkt;

root@VM-DOCKER:~# zpool status
  pool: data
 state: ONLINE
  scan: scrub canceled on Tue Jul 13 01:14:03 2021
config:

        NAME                                          STATE     READ WRITE CKSUM
        data                                          ONLINE       0     0     0
          raidz1-0                                    ONLINE       0     0     0
            ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M2RS7CDC  ONLINE       0     0     0
            ata-WDC_WD140EDFZ-11A0VA0_XHG53D8H        ONLINE       0     0     0
            ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M3VXYT5H  ONLINE       0     0     0
            ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M7XNNSA3  ONLINE       0     0     0
          raidz1-1                                    ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1AT8XE3  ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K1TFK6XD  ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K7SP0F7C  ONLINE       0     0     0
            ata-WDC_WD40EFRX-68N32N0_WD-WCC7K3FEYVC1  ONLINE       0     0     0

Ik zie een gecancel'ede scrub, ik zou voor de zekerheid graag eens een full scrub voltooid willen zien.

Ik heb voor de rest van de migratie, ook de Marvel controller van het moederbord (zie daarvoor gallery: CH4OS -> VMWare 2.0) doorgegeven middels passthrough.

Dat is goed.

De VM herkend de controllers, maar om de een of andere reden nog niet de tweede 12.8TB disk die ik aangesloten heb. Ik vermoed de SATA kabel, maar dat is kwestie van 'debugging'.

Je koppelt nu het probleem aan de controller of de sata kabel.

Heb je al eens gecontroleerd of de disk effectief in je BIOS van het echte fysieke moederbord tevoorschijn komt? Ik doe een educated guess en ik *denk* dat het aan PWDIS 3.3V probleem ligt, waar je hier een aantal oplossingen voor vindt: https://www.reddit.com/r/..._of_dealing_with_the_33v/ . Dat had ik namelijk ook met een aantal disks door een toevallig combinatie van voedingskabels.

Ik raad je wel aan om GEEN gebruik te maken van molex naar SATA.
Molex to sata: lose your data! Het zal nu ongetwijfeld al wel beter zijn dan in de tijd van deze jongen, maar ik gebruik het niet graag net omwille van dat verhaal.

Door in je BIOS te gaan kijken (en al je disks na te tellen en te vergelijken met wat er in de host zit) kan je al wat gerichter gaan zoeken.

PWDIS verhaal:

Voor de rest van het migreer proces, moet ik neem ik aan zpool replace [2tb disk] [14tb disk] doen

bijna correct:

zpool replace poolnaam oudedisk nieuwedisk

, waarna ik de 14TB disk op dezelfde plek in de computer doe als het vervangen van de disk klaar is?

Neen, dat hoeft zelfs niet, je haalt gewoon de oude disk er uit, opnieuw opstarten en klaar.

[ Voor 11% gewijzigd door HyperBart op 13-07-2021 19:36 ]

[CurlyMo]

HyperBart schreef op dinsdag 13 juli 2021 @ 19:28:
[...]
Neen, dat hoeft zelfs niet, je haalt gewoon de oude disk er uit, opnieuw opstarten en klaar.

Mits je case geen hotswap mogelijkheid heeft. Anders hoeft rebooten ook niet. Alhoewel ik de aanname dat er geen hotswap in het spel is na de vele reboots wel aannemelijk vind

[HyperBart]

CurlyMo schreef op dinsdag 13 juli 2021 @ 19:33:
[...]

Mits je case geen hotswap mogelijkheid heeft. Anders hoeft rebooten ook niet. Alhoewel ik de aanname dat er geen hotswap in het spel is na de vele reboots wel aannemelijk vind

Ik neem al geen risico meer

[CH4OS]

HyperBart schreef op dinsdag 13 juli 2021 @ 19:28:
Ik zie een gecancel'ede scrub, ik zou voor de zekerheid graag eens een full scrub voltooid willen zien.

Gisteren al meermaals gedaan en zal dat ook weer doen nadat de replace klaar is.

Je koppelt nu het probleem aan de controller of de sata kabel.

In de BIOS werd de disk perfect herkend, ook zonder de mod op de 3V.

zpool replace poolnaam oudedisk nieuwedisk

Zo kwam ik in history er ook achter idd.

Aangezien het moederbord meerdere controllers heeft, zowel van Intel als Marvell, heb ik beide controllers geprobeerd, maar beiden zonder succes (via de Intel controller heb ik de datastores met de VMs, maar dat werd dus niet overgenomen via de Marvell controller) en ben het intussen een beetje beu om het netjes op te lossen, terwijl ik nu ook weet hoe ik nu zelfstandig verder kan.

Ik heb geen zin om nog een avond verder te peuteren, ik heb nu vooral geleerd om de disks aan de hand van de IDs te koppelen, en goed op te letten welke disk ik voor welke 14TB disk vervang. Met dat in het achterhoofd ga ik wellicht wat eigenwijs zijn nu, ik heb echter geen zin om door te blijven emmeren en jullie lastig te vallen met mijn vragen. Ik ga daarom (helaas voor mij dan maar) verder door een 2TB disk los te halen en de 14TB ervoor in de plaats te doen. Dan duurt het wellicht langer, maar dan maak ik voor mijn gevoel meer vooruitgang dan wanneer ik het netjes zou doen, het spijt me zeer.

Thanks voor de hulp en de lessen, @willemw12, @RobertMe, @HyperBart, @CurlyMo en @FireDrunk! Toppers!

[ Voor 8% gewijzigd door CH4OS op 13-07-2021 19:53 ]

[CurlyMo]

CH4OS schreef op dinsdag 13 juli 2021 @ 19:49:
[...]
Met dat in het achterhoofd ga ik wellicht wat eigenwijs zijn nu

Dat noemt men dus eigenzinnig. Eigenwijs impliceert eigenrichting gebaseerd op wijsheid

[CH4OS]

Ook goed... Ik heb in elk geval geleerd waarop te letten (de juiste ID's e.d.) en heb nu op de juiste manier de disks in de pool gekoppeld. Nogmaals, dank voor alle hulp en de (hernieuwde) inzichten!

[willemw12]

Om mijn USB disks nog in hun behuizing te testen heb ik het programma "badblocks" (Linux) gebruikt. Gelukkig maar want de enige cache/scratch 2.5" disk die ik had besteld vertoonde duizenden write errors (en geen enkele read errors, dus de disk "liegt").

Met 2.5" "spinning" disks heb ik vaker problemen gehad. Met 3.5" disks eigenlijk nooit.

Om ruimte te besparen, heb recentelijk bestanden weggegooid of apart gezet, zodat die bestanden niet in een nieuwe pool komen.


14 TB disks in een RAID-Z1 zou ik zelf niet doen. Ik zou een aparte 2x 14 TB mirror pool overwegen.

En waar zijn de backups?

[HyperBart]

Badblocks is inderdaad een topper om je disks even "in te roderen". Toen ik hier mijn WD Element 14TB's had heb ik ze alle 6 via USB een weekje getest met badblocks. 2 runs dacht ik gecombineerd met daarna een ZFS pool er op en die met dd volschrijven en daarna volcontinu scrubs laten draaien , toen had ik genoeg vertrouwen om ze te shucken en in te schakelen voor "productie"

[ Voor 13% gewijzigd door HyperBart op 13-07-2021 22:19 ]

[nero355]

CH4OS schreef op dinsdag 13 juli 2021 @ 19:49:
Aangezien het moederbord meerdere controllers heeft, zowel van Intel als Marvell, heb ik beide controllers geprobeerd, maar beiden zonder succes (via de Intel controller heb ik de datastores met de VMs, maar dat werd dus niet overgenomen via de Marvell controller) en ben het intussen een beetje beu om het netjes op te lossen, terwijl ik nu ook weet hoe ik nu zelfstandig verder kan.

Geen idee wat je hier nou precies zegt, maar het lijkt erop dat je één of beide controllers niet "geVT-D krijgt" via Passthrough in VMWare

Dat kan namelijk wel kloppen, want vaak is zo'n tweede Marvell of AsMedia controller gekoppeld aan de Intel SATA poorten en kan je dus maar twee dingen doen :
- De Intel Controller doorgeven.
- De Intel + Marvell/AsMedia Controller doorgeven.

Alleen de Marvell/AsMedia Controller gaat dus niet werken!

[CH4OS]

nero355 schreef op woensdag 14 juli 2021 @ 17:43:
Geen idee wat je hier nou precies zegt, maar het lijkt erop dat je één of beide controllers niet "geVT-D krijgt" via Passthrough in VMWare

Jawel? Ik kreeg beiden perfect met passthrough aan een VM gekoppeld. Wanneer ik de Intel controller echter doorspeelde, zag VMware de datastores niet meer waar ik mijn VM's in opgeslagen heb. Importeren lukte niet helaas.

Dat kan namelijk wel kloppen, want vaak is zo'n tweede Marvell of AsMedia controller gekoppeld aan de Intel SATA poorten en kan je dus maar twee dingen doen :
- De Intel Controller doorgeven.
- De Intel + Marvell/AsMedia Controller doorgeven.

Alleen de Marvell/AsMedia Controller gaat dus niet werken!

Ik kon twee Marvell controllers doorgeven, de disks werden ook in het BIOS weergegeven, het OS (Debian) herkende de disks niet en dat is een issue wat al sinds 2012 of zo openstaande bugs heeft, zover ik kon terugvinden. Al met al maakt het ook niet meer uit, ik doe het nu zonder dat de ZFS array in orde is, al dat geemmer om het netjes werkend te krijgen was ik gisteren best zat, zacht gezegd, hahaha

[FireDrunk]

@CH4OS Maar heb je dan ook je Datastores draaien op diezelfde Intel controller? Want je kan niet en/en hebben. Een controller is *of* beschikbaar voor de host, *of* beschikbaar voor een VM dmv VT-d, niet beide.

Je kan dus niet 1 disk/ssd voor VM storage gebruiken, en de controller tegelijk doorgeven aan een VM dmv VT-d.

[CH4OS]

FireDrunk schreef op donderdag 15 juli 2021 @ 09:10:
@CH4OS Maar heb je dan ook je Datastores draaien op diezelfde Intel controller? Want je kan niet en/en hebben.

Dat je niet en/en kan hebben snap ik (en is eigenlijk ook wel logisch). Daarom had ik de disks met de datastores op de andere controller aangesloten (en daarvan dus de passthrough uit gezet).

Een controller is *of* beschikbaar voor ESXi, *of* beschikbaar voor een VM dmv VT-d, niet beide.

Dat weet ik, het is niet dat passthrough als concept onbekend is voor me of zo, ik gebruik ESXi en passthrough al de nodige jaren. Voor de rest lijkt me dit in het ZFS topic een beetje offtopic.

Intussen is mijn data ook volledig over! Moet alleen nog even kijken of qua beschikbare ruimte alles goed staat, ik heb het idee van niet, maar goed, dat ga ik vanavond eerst zelf even uitzoeken.

[ Voor 4% gewijzigd door CH4OS op 15-07-2021 09:18 ]

[Beninho]

Ik draai al jaren op een inmiddels stokoude thuisserver (amd E-350) een ZFS in Raid Z2 met 6 schijven van 2tb. Het is al een oud beestje, dus veel performance haalde ik er al niet uit, maar het werkt prima waar ik het voor nodig heb.

Helaas is vorige week voor de vierde keer een schijf overleden en de pool degraded. Destijds heb ik de pool aangemaakt met de volgende parameters

• ashift=12
• lz4 compression

Nu wil ik die kapotte hdd vervangen voor een SSD met hetzelfde formaat. Maar omdat een HDD anders werkt dan een SSD vroeg ik me af in hoeverre ik hier aanpassingen voor moet doen?

Ik vind online wel het e.a. over het vervangen van complete pools met schijven en dat er een ander compressie algoritme nodig is. Maar ik lees niks over het vervangen van een hdd in een pool voor een ssd.

Vraag:
Heeft iemand hier ervaring met het vervangen van hdd's door ssd's. In dit geval een enkele schijf?

[Brahiewahiewa]

Beninho schreef op woensdag 29 september 2021 @ 11:35:
...
Nu wil ik die kapotte hdd vervangen voor een SSD met hetzelfde formaat...

Wat denk je hiermee te kunnen bereiken? Een SSD in een RAID set met 5 mechanische harddisks gaat je geen enkele performance winst opleveren. De performance winst komt pas als je alle 6 harddisks hebt vervangen. Zolang er ook maar één mechanische harddisk in zit, blijft de RAID set performen alsof het allemaal mechanische disks zijn.

Besides, als je 6 SSD's in RAID hebt staan op zo'n oud systeem, ga je er waarschijnlijk nog steeds niet veel van merken. Je voegt weliswaar indrukwekkende getallen toe qua read & write speeds, maar er zitten nog zoveel bottlenecks in dat oude systeem dat de netto verbetering naar nul nadert

[Beninho]

Ik hoop vooral op een langere levensduur. Dit is 'al' de 4e schijf die in deze setup is heengegaan (tussen 2014 en 2021). Verder verwacht ik geen performance verschillen hoor.

Wellicht dat ik een de nabije toekomst een upgrade ga doen, maar de huidige prijzen van hardware maken dat ik nog even wacht.

[Brahiewahiewa]

Beninho schreef op woensdag 29 september 2021 @ 13:45:
Ik hoop vooral op een langere levensduur. Dit is 'al' de 4e schijf die in deze setup is heengegaan (tussen 2014 en 2021). Verder verwacht ik geen performance verschillen hoor...

Hmmz, je vertelt niet wat voor schijven je gekocht hebt. Maar ook al zou je "dure" schijven hebben gekocht, met een fabrieksgarantie van 5 jaar, dan nog is de verwachting dat ze na 7 jaar allemaal stuk zijn. Als je goedkope schijven hebt gekocht ben je m.i. spekkoper.

Anyway, met de huidige prijzen zijn SSD's ongeveer 4 keer zo duur als mechanische harddisks maar ik denk niet dat je op een SSD 20 jaar fabrieksgarantie gaat krijgen

[Beninho]

Ja, ik denk zelf nog langer, want het was al 2011 dat de server in gebruik ging en vanaf 2014 actief ZFS RaidZ2 met 6 schijven.

Wat er nu in zit:

• 2*WD-green
• 4*WD-Red (1 kapot)

Hiervoor zijn er al 2 WD-green, 1 Seagate overleden en nu dus ook de eerste RED stuk.

Het prijsverschil is inderdaad nog enorm, tegenwoordig betaal je 75 euro voor een WD Red. Dat is de helft van een SSD. Ik laat het gewoon zo doordraaien.

[nero355]

@Beninho
Waarom koop je niet 2 x 8/12/14 TB Externe HDD's die je kan "shucken" om die HDD's te vervangen

Je zou dan zelfs een tweede VDEV kunnen aanmaken met de HDD's die nog steeds goed zijn, nadat je de data hebt overgezet!

Deze modellen zijn vaak goedkoop te krijgen :
- pricewatch: WD Elements Desktop Storage 8TB Zwart
- pricewatch: WD My Book USB 3.0 12TB Zwart
(Effe twee totaal verschillende uitvoeringen gepakt per model, maar de andere uitvoeringen zakken dus ook weleens in prijs!)

Helaas wel altijd bij Amazon maar het is effe niet anders...

[Extera]

Dag heren,

Ik kom even niet uit een disk replacement....

code:

root@claustofobia:~ # zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P
  scan: resilvered 7.87M in 00:00:02 with 0 errors on Thu Sep 30 18:23:55 2021
config:

        NAME                                              STATE     READ WRITE CKSUM
        tank                                              ONLINE       0     0     0
          raidz2-0                                        ONLINE       0     0     0
            gptid/1037cdd6-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/3fb9a79f-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
            gptid/3f209f6e-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
            spare-3                                       ONLINE       0     0    50
              gptid/354a59a1-363c-11eb-845b-000c29d1be09  ONLINE       1     0     0
              gptid/b990b874-3584-11eb-845b-000c29d1be09  ONLINE       3   395     0
            gptid/41ff4144-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
            gptid/12568da2-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/114c6974-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/151dab3b-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/0f6dc72a-8095-11e5-b3dc-0060dd47d1cb    ONLINE       0     0     0
            gptid/393af75a-818d-11e5-b3dc-0060dd47d1cb    ONLINE       0     0     0
        spares
          gptid/b990b874-3584-11eb-845b-000c29d1be09      INUSE     currently in use

Zo te zien is de spare in use, gptid/b990b874-3584-11eb-845b-000c29d1be09 heeft disk gptid/354a59a1-363c-11eb-845b-000c29d1be09 vervangen

Moet ik nu gptid/354a59a1-363c-11eb-845b-000c29d1be09 offline gooien en dan een replace uitvoeren?
Daarnaast lijkt de spare disk ook aan vervanging toe?

[CurlyMo]

@Extera Ik weet het antwoord niet zo. Spare disk nog nooit gezien bij iemand. Want je weet dat je beter je parity level kan verhogen dan een spare disk gebruiken.

[Beninho]

@nero355 dat is best een idee en daar had ik nog niet eens aan gedacht... alleen ik lees (geen ervaring) dat SMR drives niet zo goed hun werk doen in een NAS.

Heb jij wel goede ervaring met SMR in een ZFS pool?

[CurlyMo]

Beninho schreef op donderdag 30 september 2021 @ 22:58:
Heb jij wel goede ervaring met SMR in een ZFS pool?

Dat is echt al zoveel besproken hier dat je beter hier even kan zoeken i.p.v. op slashdot.

[RobertMe]

Beninho schreef op donderdag 30 september 2021 @ 22:58:
@nero355 dat is best een idee en daar had ik nog niet eens aan gedacht... alleen ik lees (geen ervaring) dat SMR drives niet zo goed hun werk doen in een NAS.

Heb jij wel goede ervaring met SMR in een ZFS pool?

WD maakt bij mijn weten sowieso al geen HDDs op basis van SMR die groter zijn dan 8TB. Als je dus voor 10 / 12 / 14 / 16 / 18 TB gaat zou je sowieso veilig moeten zitten v.w.b. (geen) SMR.

[Extera]

CurlyMo schreef op donderdag 30 september 2021 @ 18:58:
@Extera Ik weet het antwoord niet zo. Spare disk nog nooit gezien bij iemand. Want je weet dat je beter je parity level kan verhogen dan een spare disk gebruiken.

Dat ben ik met je eens, ik had echter een 4TB disk over en heb deze als spare toegevoegd.
In mijn vakantie heeft hij deze zelf ingezet om een disk te vervangen die al weken lang meldingen gaf

Ik heb nu dus de data disk offline gehaald en vervangen. Ik ben benieuwd wat er gebeurd als hij klaar is... volgens mij is de spare dan weer spare

code:

root@claustofobia:~ # zpool status -v tank
  pool: tank
 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 Thu Sep 30 23:50:06 2021
        535G scanned at 11.1G/s, 6.88G issued at 147M/s, 19.2T total
        602M resilvered, 0.04% done, 1 days 14:03:35 to go
config:

        NAME                                              STATE     READ WRITE CKSUM
        tank                                              ONLINE       0     0     0
          raidz2-0                                        ONLINE       0     0     0
            gptid/1037cdd6-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/3fb9a79f-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
            gptid/3f209f6e-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
            spare-3                                       ONLINE       0     0    54
              gptid/5f6f546b-2238-11ec-a5dc-000c29d1be09  ONLINE       0     0     0  (resilvering)
              gptid/b990b874-3584-11eb-845b-000c29d1be09  ONLINE       3   395     0  (resilvering)
            gptid/41ff4144-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
            gptid/12568da2-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/114c6974-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/151dab3b-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/0f6dc72a-8095-11e5-b3dc-0060dd47d1cb    ONLINE       0     0     0
            gptid/393af75a-818d-11e5-b3dc-0060dd47d1cb    ONLINE       0     0     0
        spares
          gptid/b990b874-3584-11eb-845b-000c29d1be09      INUSE     currently in use

[ Voor 59% gewijzigd door Extera op 30-09-2021 23:54 ]