:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
Even niets...
:strip_exif()/u/17028/ico_sphere.gif?f=community)
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Ik ben daarin wat opportunistischer
Daar lijkt het inderdaad op, zie onderstaande.
Door deze opmerking alleen al zou ik mijn advies niet op hebben gevolgd. Je had zelf namelijk al aangegeven 8 schijven zichtbaar te hebben en dus ook 8 opties voor het *. Los van dat. Je hebt twee pools waarvan nu 8 schijven worden herkent door geom disk list. Terwijl er 10 schijven te zien zouden moeten zijn. Oftewel, er missen er twee.
Wat is de output van camcontrol devlist?
Ook al zou het tot een herstel van partitie tabellen moeten komen, laat je met dit soort reacties en acties zien onvoldoende te weten waar je mee bezig bent. Ik durf het niet aan je te adviseren een GPT label te herstellen als je dusdanig willekeurig je schijven lijkt te selecteren waarop je acties betrekking moet hebben. Zoals dus schijf 1 voor de symlinks. Eén aanvullende fout en je bent je data kwijt.
Hopen dat iemand hier bereid is om via bijv. een SSH verbinding te assisteren, want ik denk dat op deze manier is de kans te groot is dat het mis gaat.
Sinds de 2 dagen regel reageer ik hier niet meer
/u/715177/crop58b098eea2a1c_cropped.png?f=community)
Aha, dat is dus 't probleem. Pool is denk ik even offline geweest, Proxmox heeft daar een aantal folders gemaakt en nu wil die niet mounten vanwege de folders.
Even alle Proxmox services stilgelegd, folders verwijderd, gemount en dan zie ik 'm alles terug.
Na reboot is het wel terug kapot, dus nu nog uit te zoeken waarom die automount het niet doet.
Edit: Gefixt met https://forum.proxmox.com...ting-after-upgrade.56013/
[ Voor 6% gewijzigd door Michidez op 09-08-2020 13:25 ]
@WTM Hij zou nu klaar moeten zijn
Sinds de 2 dagen regel reageer ik hier niet meer
@CurlyMo zeker! Ergens vannacht al maar ik kom net m'n bedje uit nog even vakantie :-).
zpool status six4tb
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| pool: six4tb
state: ONLINE
scan: resilvered 2.41T in 0 days 11:32:43 with 0 errors on Mon Aug 10 02:21:13 2020
config:
NAME STATE READ WRITE CKSUM
six4tb ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gptid/39dbdb0d-8506-11e7-bbff-d050996ff8e2 ONLINE 0 0 0
gptid/75e759d8-a341-11ea-9020-d050996ff8e2 ONLINE 0 0 0
gptid/bdb2785d-f5c9-11e9-bb0c-d050996ff8e2 ONLINE 0 0 0
gptid/b7e766d9-33df-11ea-abdb-d050996ff8e2 ONLINE 0 0 0
gptid/bc6a0659-4031-11ea-b4f8-d050996ff8e2 ONLINE 0 0 0
da1 ONLINE 0 0 0
errors: No known data errors |
Mijn conclusie het is goed gegaan :-). Wat wel vreemd is dat er geen gptid aangemaakt is. In FreeNAS zie ik in de logs dit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| Aug 10 02:21:13 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=4321123093847478765 Aug 10 02:21:13 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=7341696284033616375 Aug 10 02:21:13 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=3675791852414277510 Aug 10 02:21:13 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=10778351145683311183 Aug 10 02:21:14 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=10677478820108001500 Aug 10 02:21:15 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=18182716167874336493 Aug 10 02:21:15 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=18108822582148919023 Aug 10 02:21:17 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=4321123093847478765 Aug 10 02:21:17 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=7341696284033616375 Aug 10 02:21:17 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=3675791852414277510 Aug 10 02:21:17 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=10778351145683311183 Aug 10 02:21:17 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=10677478820108001500 Aug 10 02:21:17 freenas ZFS: vdev state changed, pool_guid=13928668106559313930 vdev_guid=18108822582148919023 Aug 10 02:21:19 freenas zfsd: Unable to extract vdev GUID from vdev config data. |
Denk vooral deze past erbij:
code:
1
| Aug 10 02:21:19 freenas zfsd: Unable to extract vdev GUID from vdev config data. |
Moet ik me daar zorgen om maken? Ik heb 't systeem even gereboot. Dacht misschien dat hij bij mounten dan zo'n nummer toekent? Maar geen verschil:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| pool: six4tb
state: ONLINE
scan: resilvered 2.41T in 0 days 11:32:43 with 0 errors on Mon Aug 10 02:21:13 2020
config:
NAME STATE READ WRITE CKSUM
six4tb ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gptid/39dbdb0d-8506-11e7-bbff-d050996ff8e2 ONLINE 0 0 0
gptid/75e759d8-a341-11ea-9020-d050996ff8e2 ONLINE 0 0 0
gptid/bdb2785d-f5c9-11e9-bb0c-d050996ff8e2 ONLINE 0 0 0
gptid/b7e766d9-33df-11ea-abdb-d050996ff8e2 ONLINE 0 0 0
gptid/bc6a0659-4031-11ea-b4f8-d050996ff8e2 ONLINE 0 0 0
da1 ONLINE 0 0 0
errors: No known data errors |
Als de overige schijven wel gepartitioneerd zijn, dan moet ZFS die nieuwe schijf ook wel partitioneren anders kloppen de sectoren niet.:
Nope, lekker laten zo, gaat jaren goed
Sinds de 2 dagen regel reageer ik hier niet meer
/u/51802/new-user-icon.png?f=community){kind=icon}
Ik gebruik dit board:
Intel server moederboard s1200v3pl
Kan helaas niet meer uitvogelen of er problemen zijn me dit geheugen en dit moederboard
compatibiliteitslijst geeft 404 :-(
met dit geheugen:
32gb ECC DDR3 (set 4x8) kingston-valueram-kvr16e11k4-32
Kan eens memtest draaien een nachtje, kan nooit kwaad natuurlijk.
/edit
Nog geen memtest gedraaid.
Ik heb van de pool three4tb de data weggehaald en een nieuwe scrub gedaan. Nu komen er geen fouten terug.
Memtest nog nodig?
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| pool: six4tb
state: ONLINE
scan: resilvered 2.41T in 0 days 11:32:43 with 0 errors on Mon Aug 10 02:21:13 2020
config:
NAME STATE READ WRITE CKSUM
six4tb ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gptid/39dbdb0d-8506-11e7-bbff-d050996ff8e2 ONLINE 0 0 0
gptid/75e759d8-a341-11ea-9020-d050996ff8e2 ONLINE 0 0 0
gptid/bdb2785d-f5c9-11e9-bb0c-d050996ff8e2 ONLINE 0 0 0
gptid/b7e766d9-33df-11ea-abdb-d050996ff8e2 ONLINE 0 0 0
gptid/bc6a0659-4031-11ea-b4f8-d050996ff8e2 ONLINE 0 0 0
da1 ONLINE 0 0 0
errors: No known data errors
pool: three4tb
state: ONLINE
scan: scrub repaired 0 in 0 days 00:03:18 with 0 errors on Mon Aug 10 23:39:46 2020
config:
NAME STATE READ WRITE CKSUM
three4tb ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gptid/83c6492f-85bd-11e7-a5e3-d050996ff8e2 ONLINE 0 0 0
gptid/849990df-85bd-11e7-a5e3-d050996ff8e2 ONLINE 0 0 0
gptid/8565e3f6-85bd-11e7-a5e3-d050996ff8e2 ONLINE 0 0 0
errors: No known data errors |
/edit 2:
De memtest moet nog even wachten, ik kreeg op een schijf een s.m.a.r.t. fout. Dus die schijf eruit getrokken en nieuwe gezet. Oude schijf heeft nog 20 dagen garantie
dus die gaat de RMA in. Nieuwe schijf is aan het resilveren as we speak.
[ Voor 73% gewijzigd door WTM op 11-08-2020 21:56 ]
Gisterenavond is er plots een schijf verdwenen uit mijn server. Ik zal straks misschien eens gaan kijken of die fysiek nog in de behuizing steekt, of gaan lopen is door de hitte 
. Aangezien smartctl zegt dat ada0 niet bestaat, vermoed ik niet dat die nog terug tot leven gewekt kan worden. Zelfs mijn meest geavanceerde probleemoplostechnieken hebben niet geholpen (afzetten en terug aanzetten 
).
Omdat ik stilletjes richting 80% capaciteit aan het lopen was, had ik al ooit het idee om de 4TB schijven te vervangen door 8TB. Ik dacht dat hier op het forum iemand pas hetzelfde gedaan had in FreeNAS, maar ik vind de procedure niet meer terug. Weet iemand nog waar die staat, of wat in het kort gezegd de stappen zijn (en dan vooral of ik iets moet doen vóór ik in mijn enthousiasme de schijven één voor één vervang)?
. Aangezien smartctl zegt dat ada0 niet bestaat, vermoed ik niet dat die nog terug tot leven gewekt kan worden. Zelfs mijn meest geavanceerde probleemoplostechnieken hebben niet geholpen (afzetten en terug aanzetten ).Omdat ik stilletjes richting 80% capaciteit aan het lopen was, had ik al ooit het idee om de 4TB schijven te vervangen door 8TB. Ik dacht dat hier op het forum iemand pas hetzelfde gedaan had in FreeNAS, maar ik vind de procedure niet meer terug. Weet iemand nog waar die staat, of wat in het kort gezegd de stappen zijn (en dan vooral of ik iets moet doen vóór ik in mijn enthousiasme de schijven één voor één vervang)?
De optie autoexpand aanzetten en daarna alle schijven 1 voor 1 vervangen.:
Gisterenavond is er plots een schijf verdwenen uit mijn server. Ik zal straks misschien eens gaan kijken of die fysiek nog in de behuizing steekt, of gaan lopen is door de hitte
Omdat ik stilletjes richting 80% capaciteit aan het lopen was, had ik al ooit het idee om de 4TB schijven te vervangen door 8TB. Ik dacht dat hier op het forum iemand pas hetzelfde gedaan had in FreeNAS, maar ik vind de procedure niet meer terug. Weet iemand nog waar die staat, of wat in het kort gezegd de stappen zijn (en dan vooral of ik iets moet doen vóór ik in mijn enthousiasme de schijven één voor één vervang)?
Sinds de 2 dagen regel reageer ik hier niet meer
autoexpand is inderdaad het magische Google woord, bedankt.
Intussen de schijf eens in mijn desktop gestoken, en helaas het spijtige verdikt: de schijf doet het nog.
Spijtig omdat ik dan mag gaan zoeken wat er wèl kapot is (kabel, moederbord, voeding: laat ons hopen van dat eerste), en spijtig omdat ik dan geen excuus meer heb om te prutsen om de capaciteit te verhogen.
Intussen de schijf eens in mijn desktop gestoken, en helaas het spijtige verdikt: de schijf doet het nog.
Spijtig omdat ik dan mag gaan zoeken wat er wèl kapot is (kabel, moederbord, voeding: laat ons hopen van dat eerste), en spijtig omdat ik dan geen excuus meer heb om te prutsen om de capaciteit te verhogen
.
:strip_icc():strip_exif()/u/200296/crop6893856e4e7de_cropped.jpg?f=community)
Thanks voor de info, ook voor de linkjes!
Ik heb het gewoon geprobeerd, de tests waren net klaar en de pool is niet in gebruik.
Dit:
Maakt:
Die andere maakt 3 mirrors van 2 disks.
Misschien is het verschil alleen in de weergave en is het feitelijk in de werking gelijk aan elkaar, ik heb een nieuwe test gestart, dus we gaan het zien!
Ben IT'er, dus per definitie eigenwijs
Ik heb het gewoon geprobeerd, de tests waren net klaar en de pool is niet in gebruik.
Dit:
code:
1
| zpool create -o options mirror disk1 disk2 mirror disk3 disk4 mirror disk5 disk6 |
Maakt:
code:
1
2
3
4
5
6
7
8
| tank
ata-disk1
ata-disk2
ata-disk3
mirror-3
ata-disk4
ata-disk5
ata-disk6 |
Die andere maakt 3 mirrors van 2 disks.
Misschien is het verschil alleen in de weergave en is het feitelijk in de werking gelijk aan elkaar, ik heb een nieuwe test gestart, dus we gaan het zien!
Dat create commando komt niet overeen met de zpool layout.:
Thanks voor de info, ook voor de linkjes!
[...]
Ben IT'er, dus per definitie eigenwijs
Ik heb het gewoon geprobeerd, de tests waren net klaar en de pool is niet in gebruik.
Dit:
code:
Maakt:
code:
tank ata-disk1 ata-disk2 ata-disk3 mirror-3 ata-disk4 ata-disk5 ata-disk6
Die andere maakt 3 mirrors van 2 disks.
Misschien is het verschil alleen in de weergave en is het feitelijk in de werking gelijk aan elkaar, ik heb een nieuwe test gestart, dus we gaan het zien!
code:
1
| zpool create -o options disk1 disk2 disk3 mirror disk4 disk5 disk6 |
^^ Die klopt wel met die layout.
Bovenstaande layout bestaat uit 3 vdevs van 1 disk en 1 vdev met een 3weg mirror. Dat betekent dat 3/4 van je zpool nu geen redundantie heeft. Dat is vast niet de bedoeling
. Dit is exact de reden waarom je heel goed moet uitkijken met vdevs toevoegen aan een bestaande zpool, je kunt ze niet meer verwijderen!Ik snap dat je aan het spelen bent, maar toch voor de leuk:
Als je bovenstaande zpool zou willen 'redden' dan zul je elke single disk vdev moeten promoveren naar een 2-way mirror, en van de 3-way mirror kun je dan 1 disk weghalen. Je hebt dan minimaal 8 disks nodig.
12x 280Wp ZW, 12x 280Wp ZO, Zubadan SHW80YAA 8kW, Zehnder Q450 ERV
Ja, sorry ik had de verkeerde regel gekopie/paste .
Dit is het verschil:
https://www.thegeekstuff.com/2011/10/raid10-vs-raid01/
Ik ga er vanuit dat het voor zfs hetzelfde is (ik had dezelfde vraag op reddit gesteld waar iemand met die link kwam).
Die drie mirrortjes heeft dus absolute voorkeur boven de 3-disk stripe mirror (raid01).
.Dit is het verschil:
https://www.thegeekstuff.com/2011/10/raid10-vs-raid01/
Ik ga er vanuit dat het voor zfs hetzelfde is (ik had dezelfde vraag op reddit gesteld waar iemand met die link kwam).
Die drie mirrortjes heeft dus absolute voorkeur boven de 3-disk stripe mirror (raid01).
[ Voor 15% gewijzigd door InflatableMouse op 17-08-2020 12:10 ]
Alleen heb je geen RAID01 gemaakt zoals @P5ycho terecht zegt.:
Ja, sorry ik had de verkeerde regel gekopie/paste
Dit is het verschil:
https://www.thegeekstuff.com/2011/10/raid10-vs-raid01/
Ik ga er vanuit dat het voor zfs hetzelfde is (ik had dezelfde vraag op reddit gesteld waar iemand met die link kwam).
Sinds de 2 dagen regel reageer ik hier niet meer
Dat klopt, maar het is nog steeds good practice om even na te denken voordat je aan je pool sleutelt. Ik heb al teveel gevallen gezien waar pools verminkt werden en/of data verloren ging door onvoorzichtigheid. Hetzelfde geldt voor l2arc, zlog en special devices. Denk na over de gevolgen voordat je er mee begint.
Ik zie het kunnen verwijderen van een vdev als 'convenient', maar in de praktijk heb je het bijna nooit nodig. Een scenario wat ik voor thuis kan bedenken is het migreren van bijv. een 5 disk raidz1 van 5x 1tb naar een 3x4tb raidz1 ivm energieverbruik en groei van je poolsize. Handig, maar het is ook niet zo moeilijk om even zfs send/receive te doen naar een nieuwe zpool. Ik heb mijn pool maar 1 keer opnieuw gebouwd met zfs send/receive sinds freebsd 7.0 (begin 2008). Eerst altijd mirrored ahift=9, daarna 5 disk raidz1 ashift=12 vanwege 4k sector disks.
RAID01 bestaat niet in ZFS land. een record staat op 1 vdev, niet meer dan dat.:
Ja, sorry ik had de verkeerde regel gekopie/paste
Dit is het verschil:
https://www.thegeekstuff.com/2011/10/raid10-vs-raid01/
Ik ga er vanuit dat het voor zfs hetzelfde is (ik had dezelfde vraag op reddit gesteld waar iemand met die link kwam).
Die drie mirrortjes heeft dus absolute voorkeur boven de 3-disk stripe mirror (raid01).
In je link kun je een 'group' zien als een vdev en een geletterd data block als een record. Een record staat dus altijd op 1 vdev, en als de vdev een x-way mirror is dan staat hij op x disks binnen die vdev.
[ Voor 26% gewijzigd door P5ycho op 17-08-2020 12:46 ]
12x 280Wp ZW, 12x 280Wp ZO, Zubadan SHW80YAA 8kW, Zehnder Q450 ERV
Edit: P5ycho was me net voor dus mijn bewoording hier klopt dan niet met raid01. Hoe dan ook, het gaat sowieso verdwijnen en ga er 3 mirrors van maken.
Ondertussen wel, maar ik was alleen slordig met copy/paste daaro.
Mijn tests draaien nu tegen de raid01 aan, maar ik gezien de nadelen zal ik daar niet mee blijven draaien.
Wel weer een leerzame zoektocht geweest
.Het eind is in zicht in elk geval, na deze tests kan ik de definitieve pool opzetten. Dan volgen er nog een aantal tests met random i/o's op kleinere recordsizes. Daarna moet ik me gaan beraden op de workloads en welke blocksizes ik daar verwacht (is dat te meten eigenlijk?).
[ Voor 10% gewijzigd door InflatableMouse op 17-08-2020 13:29 ]
Eens
@InflatableMouse, gaf zpool create je geen error toen je die pool zonder redundancy maakte? Vaak krijg je een warning over mismatched redundancy levels, maar het kan ook zijn dat je die warning alleen krijgt bij het toevoegen van een vdev aan een bestaande array. Je moet dan -f gebruiken om de warning te bypassen.
[ Voor 46% gewijzigd door P5ycho op 17-08-2020 13:36 ]
12x 280Wp ZW, 12x 280Wp ZO, Zubadan SHW80YAA 8kW, Zehnder Q450 ERV
Ik denk dat ik iets niet goed begrijp, hoe bedoel je zonder redundantie? Beide pools hadden evenveel redundantie?
code:
1
| zpool create -o options mirror disk1 disk2 mirror disk3 disk4 mirror disk5 disk6 |
heeft toch evenveel redundantie als
code:
1
| zpool create -o options disk1 disk2 disk3 mirror disk4 disk5 disk6 |
Ik heb overigens de benchmark afgebroken, de performance van deze laatste was enorm veel trager dan de eerste optie die ik nu weer terug heb met de laatste batch aan tests. Vanacht ergens is tie klaar ...
.
:strip_exif()/u/259931/stuiterbal2.gif?f=community)
Met het risisco dat ik allemaal dingen ga vertellen die jullie al lang weten ... Ik lees dus net dat er met zfs geen sprake is van een striping in de traditionele zin van het woord. Als voorbeeld, een traditionele raid0 zou op elke disk in de raid set een record plaatsen op dezelfde offset, tesamen vormt dit de stripe. Bij zfs lees ik gebeurd dat niet. Als je dus een pool maakt:
Heb je feitelijk 3 losse vdevs in je pool, en niet een raid0-achtig iets van 1 vdev met 3 disks waarover gestriped wordt.
Wat zfs schijnbaar dus wel doet is onder andere op basis van vrije ruimte bepalen welke record naar welke vdev gaat en het "balanced" de records dus wel die het wegschrijft, maar maakt dus geen stripes over de disks (vdevs). Bij raidz zou dat anders werken, daar wordt dan wel weer met een soort striping gewerkt binnen de vdev.
Raid01 kan je dus ook niet aanmaken. Deze pool:
is dus geen raid01. Dit zijn 3 losse vdevs die gemirrored zijn met die 3 andere. Hoe die dit dan precies doet weet ik ook niet maar het is niet hetzelfde en ook lang niet zo snel als 3 mirrors aan een pool geven.
Goed, als er dan geen striping plaats vind dan zou ik denken (maar dat is dan ook meteen de vraag hier), zou de uitval in geval van de "raid01" dus ook niet gewoon drie disks mogen zijn, zolang het maar niet 2 uit dezelfde mirror zijn? Eigenlijk hetzelfde als met 3 mirrors?
... Ik lees dus net dat er met zfs geen sprake is van een striping in de traditionele zin van het woord. Als voorbeeld, een traditionele raid0 zou op elke disk in de raid set een record plaatsen op dezelfde offset, tesamen vormt dit de stripe. Bij zfs lees ik gebeurd dat niet. Als je dus een pool maakt:code:
1
| zpool create -o options disk1 disk2 disk3 |
Heb je feitelijk 3 losse vdevs in je pool, en niet een raid0-achtig iets van 1 vdev met 3 disks waarover gestriped wordt.
Wat zfs schijnbaar dus wel doet is onder andere op basis van vrije ruimte bepalen welke record naar welke vdev gaat en het "balanced" de records dus wel die het wegschrijft, maar maakt dus geen stripes over de disks (vdevs). Bij raidz zou dat anders werken, daar wordt dan wel weer met een soort striping gewerkt binnen de vdev.
Raid01 kan je dus ook niet aanmaken. Deze pool:
code:
1
| zpool create -o options disk1 disk2 disk3 mirror disk4 disk5 disk6 |
is dus geen raid01. Dit zijn 3 losse vdevs die gemirrored zijn met die 3 andere. Hoe die dit dan precies doet weet ik ook niet maar het is niet hetzelfde en ook lang niet zo snel als 3 mirrors aan een pool geven.
Goed, als er dan geen striping plaats vind dan zou ik denken (maar dat is dan ook meteen de vraag hier), zou de uitval in geval van de "raid01" dus ook niet gewoon drie disks mogen zijn, zolang het maar niet 2 uit dezelfde mirror zijn? Eigenlijk hetzelfde als met 3 mirrors?
Even mezelf quoten:
Je hebt dus 3 losse disks en een enkele 3-way mirror in een striped config. Oeps.:
Bovenstaande layout bestaat uit 3 vdevs van 1 disk en 1 vdev met een 3weg mirror. Dat betekent dat 3/4 van je zpool nu geen redundantie heeft. Dat is vast niet de bedoeling
Zie ook het verschil tussen dit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
| zpool create -o options mirror disk1 disk2 mirror disk3 disk4 mirror disk5 disk6
tank
mirror-0
disk1
disk2
mirror-1
disk3
disk4
mirror-2
disk5
disk6 |
en dit:
code:
1
2
3
4
5
6
7
8
9
10
11
| zpool create -o options mirror disk1 disk2 disk3 mirror disk4 disk5 disk6
tank
mirror-1
disk1
disk2
disk3
mirror-2
disk4
disk5
disk6 |
en dit:
code:
1
2
3
4
5
6
7
8
9
10
11
| zpool create -o options disk1 disk2 disk3 mirror disk4 disk5 disk6
vdev1 vdev2 vdev3 ( vdev4, 3 way mirror )
tank
disk1
disk2
disk3
mirror-0
disk4
disk5
disk6 |
De laatste zpool heeft geen bestaansrecht imho, die pool gaat nergens in uitblinken.
Nogmaals, de RAID01 array die je denkt te maken bestaat niet in ZFS omdat redundantie alleen gecreerd kan worden binnen een vdev, niet daar buiten.
edit: ik post dit net nadat je het zelf ook uitgevonden hebt. reagerende op jouw post:
ZFS doet zeker aan striping, maar niet zo strict als de simpele, klassieke, 'domme' striping. Als je striping ziet als het verdelen van je records over meerdere vdevs, dan is dit zeker striping. Het is alleen wat intelligenter, met instelbare recordsize per filesystem, met gewogen verdeling over de vdevs.
[ Voor 35% gewijzigd door P5ycho op 18-08-2020 00:09 ]
12x 280Wp ZW, 12x 280Wp ZO, Zubadan SHW80YAA 8kW, Zehnder Q450 ERV
/u/3875/gnu_linux_freebsd_openbsd_small_v2.png?f=community)
pvoutput. Waarom makkelijk doen, als het ook moeilijk kan! Every solution has a new problem
/u/1176/crop635f8931b2b68_cropped.png?f=community)
Oke; thanks, ga ik binnenkort maar eens een schijf vervangen. dat is sneller dan een nieuwe server opbouwen. Dat project ligt ook pas 3 jaar of zo; dus gaat lekker hard
Die nieuwe build met SSD's is voor het runnen van verschillende VM's. Iets met download en wat dockers en andere spullenboel. Die wou ik vanaf SSD doen. Ik dacht eerst aan FreeNAS; maar denk dat ik lekker voor Debian of Ubuntu ga. ZFS wordt steeds beter op Linux.
pvoutput. Waarom makkelijk doen, als het ook moeilijk kan! Every solution has a new problem
Je doet er goed aan om die 2 sata poorten tegelijk in te zetten tijdens de resilver, 2 disks tegelijk replacen duurt even lang als 1. Even een molex naar 2 sata splitter scoren dus .
.
12x 280Wp ZW, 12x 280Wp ZO, Zubadan SHW80YAA 8kW, Zehnder Q450 ERV
Daar was ik al naar aan het kijken ja, eentje die direct leverbaar is. Dan besluit ik hier de accessoireschuif eens open te trekken en hier ligt er gewoon eentje .
Ik ga ze per 2 aansluiten en SMART testen, en aangezien de redundantie toch blijft kan ik inderdaad de schijven gewoon per 2 gaan vervangen. Hoewel de urgentie nu weg is: of het nu 2 dagen of een week duurt maakt eigenlijk niet veel uit.
.Ik ga ze per 2 aansluiten en SMART testen, en aangezien de redundantie toch blijft kan ik inderdaad de schijven gewoon per 2 gaan vervangen. Hoewel de urgentie nu weg is: of het nu 2 dagen of een week duurt maakt eigenlijk niet veel uit.
:strip_icc():strip_exif()/u/101865/crop5e04c97889698_cropped.jpeg?f=community)
:strip_exif()/u/17745/Koetje.gif?f=community)
Met het volgen van de stappen van OpenZFS staat uiteindelijk dit in mijn fstab:
er staat dus 2x een /boot/efi in.
blkid UUID (nvme0 is nieuwe ssd):
Ik kan dus die eerste boot/efi regel verwijderen(sowieso de eerste 3 regels, die gaan allemaal over oude SSD)? In de onderste regel staat geen legacy.
gaat om dit stukje uit de tutorial van OpenZFS denk ik:
voordat ik zo met een systeem zit dat niet meer wil opstarten
code:
1
2
3
4
| UUID=d3f0611a-5b66-43e1-b17e-dac54b317ddf / ext4 errors=remount-ro 0 1 UUID=F3E6-08CA /boot/efi vfat umask=0077 0 1 UUID=fb1c008f-aa88-45fa-99de-a10ba274c84f none swap sw 0 0 PARTUUID=64f0d62b-938c-4f3e-abb5-fd1c0877384c /boot/efi vfat nofail,x-systemd.device-timeout=1 0 1 |
er staat dus 2x een /boot/efi in.
blkid UUID (nvme0 is nieuwe ssd):
code:
1
2
3
4
5
6
7
| /dev/nvme1n1p1: UUID="F3E6-08CA" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="6e608547-43d6-4812-bcc2-1381b0790a6e" /dev/nvme1n1p2: UUID="d3f0611a-5b66-43e1-b17e-dac54b317ddf" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b62fd2bd-c29d-4519-8845-25e1e68c0db0" /dev/nvme1n1p3: UUID="fb1c008f-aa88-45fa-99de-a10ba274c84f" TYPE="swap" PARTUUID="ea8ee236-0092-4b06-bf84-1e1be732d0a4" /dev/nvme0n1p2: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="7D82-B3FC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="64f0d62b-938c-4f3e-abb5-fd1c0877384c" /dev/nvme0n1p3: LABEL="bpool" UUID="11677001688569340185" UUID_SUB="4465143603672911983" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="c75b2453-2e38-4ef4-a419-b09e539ed0d0" /dev/nvme0n1p4: LABEL="rpool" UUID="2539621985895764986" UUID_SUB="17185164116259433080" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="4de5ce77-d63b-43f6-abda-a0c98fe77f10" /dev/nvme0n1p1: PARTUUID="6ebcd27b-17ba-4bdd-b133-74d625eb5bd1" |
Ik kan dus die eerste boot/efi regel verwijderen(sowieso de eerste 3 regels, die gaan allemaal over oude SSD)? In de onderste regel staat geen legacy.
gaat om dit stukje uit de tutorial van OpenZFS denk ik:
code:
1
2
3
4
5
6
7
| apt install dosfstools
mkdosfs -F 32 -s 1 -n EFI ${DISK}-part2
mkdir /boot/efi
echo PARTUUID=$(blkid -s PARTUUID -o value ${DISK}-part2) \
/boot/efi vfat nofail,x-systemd.device-timeout=1 0 1 >> /etc/fstab
mount /boot/efi
apt install --yes grub-efi-amd64 shim-signed |
voordat ik zo met een systeem zit dat niet meer wil opstarten
:strip_exif()/u/49248/DPCkoeienUD.gif?f=community)
Daar zijn Live CD's voor gemaakt!:
voordat ik zo met een systeem zit dat niet meer wil opstarten
En je hebt dan weer iets nieuws geleerd!
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
:strip_icc():strip_exif()/u/38800/i_m_weasel-char.jpg?f=community)
Ik ben iets soortgelijk tegengekomen een maand geleden. Ik moest even troubleshooten of het aan een kabel of iets dergelijks lag (want de fouten gingen weer weg), maar een goede week later of zo is de schijf met de fouten overleden.
Kijk eens naar de SMART waardes van die 2 schijven zou ik zeggen, misschien zie je daar iets wat niet pluis is, en kan je een schijf preventief vervangen (of andere maatregelen nemen).
En om even een statusupdate te geven: alle schijven zijn intussen vervangen hier, de laatste oude schijf ben ik nog aan het wipen. De capaciteit is inderdaad automatisch omhoog gegaan, ik heb weer 44TiB beschikbaar nu (van de ongeveer 56 TiB totaal), daar kom ik wel even mee toe .
Kijk eens naar de SMART waardes van die 2 schijven zou ik zeggen, misschien zie je daar iets wat niet pluis is, en kan je een schijf preventief vervangen (of andere maatregelen nemen).
En om even een statusupdate te geven: alle schijven zijn intussen vervangen hier, de laatste oude schijf ben ik nog aan het wipen. De capaciteit is inderdaad automatisch omhoog gegaan, ik heb weer 44TiB beschikbaar nu (van de ongeveer 56 TiB totaal), daar kom ik wel even mee toe
.
/u/231803/ramdisk2.png?f=community)
Recent zoiets moeten doen, klopt inderdaad.
Procesgang is dat je de nieuwe disc met GPT moet initialiseren, erna de opbouw moet kopiëren, vervolgens het boot deel kopiëren (partitie 1 en 2 voor legacy en uefi boot) en tot slot de derde partitie aan de rpool moet toevoegen (attach, resilver, joy). Commando's/stappen (in dit geval is sdc de nieuwe disc):
- Replace the physical failed/offline drive, /dev/sdc
- Initialize Disk with GPT (/dev/sdc)
- Copy the partition table from /dev/sda to /dev/sdc
sgdisk --replicate=/dev/sdc /dev/sda - Ensure the GUIDs are randomized
sgdisk --randomize-guids /dev/sdc - Install the Grub on the new disk
grub-install /dev/sdc - Then replace/attach/... the disk in the ZFS pool, several options, opted for this one:
zpool attach rpool /dev/disk/by-id/<oude disc>-part3 /dev/disk/by-id/<nieuwe disc>-part3 - Remove old disc
zpool detach rpool <oude disc> - Install grup failed for some reason on my end, therefore copied the set over using dd
dd if=/dev/sda1 of=/dev/sdb1
dd if=/dev/sda2 of=/dev/sdb2
En uiteraard nog even de gebruikelijke disclaimers, test het zelf nog even, ik moet het binnenkort zelf nog even dubbelchecken, maar dit zou het moeten zijn.
Thanks, ik vermoedde inderdaad al dat ik de UUID's moest randomizen. Zodra de disk binnen is ga ik het proberen.:
[...]
Recent zoiets moeten doen, klopt inderdaad.
Procesgang is dat je de nieuwe disc met GPT moet initialiseren, erna de opbouw moet kopiëren, vervolgens het boot deel kopiëren (partitie 1 en 2 voor legacy en uefi boot) en tot slot de derde partitie aan de rpool moet toevoegen (attach, resilver, joy). Commando's/stappen (in dit geval is sdc de nieuwe disc):In het Engels omdat ik misschien ooit dit soort zaken eens ergens in een blog post. Maar ja, dat is project #4534
- Replace the physical failed/offline drive, /dev/sdc
- Initialize Disk with GPT (/dev/sdc)
- Copy the partition table from /dev/sda to /dev/sdc
sgdisk --replicate=/dev/sdc /dev/sda- Ensure the GUIDs are randomized
sgdisk --randomize-guids /dev/sdc- Install the Grub on the new disk
grub-install /dev/sdc- Then replace/attach/... the disk in the ZFS pool, several options, opted for this one:
zpool attach rpool /dev/disk/by-id/<oude disc>-part3 /dev/disk/by-id/<nieuwe disc>-part3- Remove old disc
zpool detach rpool <oude disc>- Install grup failed for some reason on my end, therefore copied the set over using dd
dd if=/dev/sda1 of=/dev/sdb1
dd if=/dev/sda2 of=/dev/sdb2
:strip_icc():strip_exif()/u/11913/crop60a2bd6d1f03a.jpg?f=community)
![[Afbeelding]](https://tweakers.net/i/ox5VzMdmNESkrjfoZLU9jdbmh2U=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/zm2MciUzJfg8L0zijb8vem9M.png?f=user_large){kind=link}
![[Afbeelding]](https://tweakers.net/i/8GNQexzpRDjgvDaCwGaa1QUSU6U=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/QXpRHPsdfTF7OZSh7wAMfShG.png?f=user_large){kind=link}
![[Afbeelding]](https://tweakers.net/i/pf2Cx_IsW1H0NjQxZ1SnHaP_FEU=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/2HiBPHcxo33Gc3hYMQ1axlqF.png?f=user_large){kind=link}