Het grote ZFS topic

[mdbraber]

FireDrunk schreef op dinsdag 16 oktober 2018 @ 15:58:
[...]

Ik zou het native doen, die limieten kan je ook prima op ZFS niveau installen (ARC limieten etc).

Wat bedoel je met non-native? Proxmox bied zelfs out-of-the-box support voor ZFS?
Of bedoel je dat ZFS zelf non-native is voor Linux? Dat is achterhaald, ZFS is een 'first-class citizen' op Linux tegenwoordig.

Ook ligt FreeBSD niet meer 'voor' qua features t.o.v. Linux. In sommige gevallen bied FreeBSD wel 'andere' features dan Linux, maar dat is ook zo vice-versa.

Ik draai zelf mijn 2 flinke ZFS arrays native in Proxmox, dus mocht je iets willen weten, vraag maar raak.

Tnx, met non-native bedoelde ik vooral dat het gevirtualiseerd is, wat mogelijkerwijs een performance-hit op kan leveren.

Wat ik nu aan het bekijken ben is hoe ik onderliggend aan ZFS full-disk encryption kan gebruiken voor een mirrored root disk (SSD). Het lijkt erop dat ik het beste gewoon een Debian install kan doen en daar voor full-disk encryption kan kiezen en dan van daar verder kan gaan.

Heb jij daar wellicht ervaring mee? Schijnt nog niet heel voor de hand liggend te zijn... Een oplossing die daar wordt aangedragen is wel interessant: Proxmox op een kleine SSD en alle verdere data op LUKS+ZFS disks Probleem is echter dat mijn cloud server alleen 2x SSD + 2x HDD heeft. Eventueel zou ik Proxmox op een USB kunnen installeren, maar volgens mij wordt dat juist weer afgeraden (alhoewel het wellicht prima kan als je al het andere op de SSDs draait...)

[dcm360]

Kijk wel een beetje uit met het installeren van Proxmox op een SSD. Proxmox doet uit zichzelf best veel writes (tenzij je het configureert om dat niet te doen), en daarmee ga je best hard door de TBW van een goedkope SSD heen, om het nog maar niet te hebben over USB-sticks.

[CAPSLOCK2000]

Ter lering ende vermaeck.
Ik wil de een defect disk vervangen in mijn raidz2.
Mijn plan was om de disk eerst als spare toe te voegen, deze te activeren en dan de oude schijf er uit te halen.

Ik gaf dus het commando:

zpool add tank /dev/een/disk

En dat is helemaal verkeerd. Het had moeten zijN:

zpool add spare tank /dev/een/disk

ZFS heeft mijn pool nu uitgebreid met die disk, zeg maar RAID-0 en ik krijg hem er niet meer uit.

Uiteindelijk heb ik met mijn domme en vermoeide hoofd de partitietabel van die disk gewist met zo iets van 'ik zal jou krijgen". Dat was natuurlijk helemaal verkeerd en nu weigert mijn pool nog te starten. Ik was zo naief om te denken dat het herstellen van de partitietabel genoeg zou zijn om de schijf weer te zien. Dat blijkt een onjuiste aanname, en nu lijkt mijn pool reddeloos verloren

Het is erg frustrerend omdat ik weet dat alle dat gewoon nog op de schijven staat. Fundamenteel zit het me niet lekker dat ik de redundantie van de data kan verlagen door een schijf verkeerd toe te voegen, en dan niet meer terug kan.

Ik ben momenteel ernstig met mezelf aan het overleggen of ik wel verder moet gaan met ZFS of dat het tijd is voor iets anders.

[ Voor 3% gewijzigd door CAPSLOCK2000 op 16-10-2018 16:25 ]

[mdbraber]

dcm360 schreef op dinsdag 16 oktober 2018 @ 16:22:
Kijk wel een beetje uit met het installeren van Proxmox op een SSD. Proxmox doet uit zichzelf best veel writes (tenzij je het configureert om dat niet te doen), en daarmee ga je best hard door de TBW van een goedkope SSD heen, om het nog maar niet te hebben over USB-sticks.

Yes, daar ben ik me van bewust. De SSDs in mn cloud-server zijn Enterprise SSDs. Ik moet eerlijk zeggen dat ik niet weet of het zijn heeft om ook Enterprise SSDs in mn thuis-server te zetten. Iets zegt me dat dat voelt als overkill, maar heeft iemand daar wellicht cijfers over?

[FireDrunk]

mdbraber schreef op dinsdag 16 oktober 2018 @ 16:18:
[...]


Tnx, met non-native bedoelde ik vooral dat het gevirtualiseerd is, wat mogelijkerwijs een performance-hit op kan leveren.

Wat ik nu aan het bekijken ben is hoe ik onderliggend aan ZFS full-disk encryption kan gebruiken voor een mirrored root disk (SSD). Het lijkt erop dat ik het beste gewoon een Debian install kan doen en daar voor full-disk encryption kan kiezen en dan van daar verder kan gaan.

Heb jij daar wellicht ervaring mee? Schijnt nog niet heel voor de hand liggend te zijn... Een oplossing die daar wordt aangedragen is wel interessant: Proxmox op een kleine SSD en alle verdere data op LUKS+ZFS disks Probleem is echter dat mijn cloud server alleen 2x SSD + 2x HDD heeft. Eventueel zou ik Proxmox op een USB kunnen installeren, maar volgens mij wordt dat juist weer afgeraden (alhoewel het wellicht prima kan als je al het andere op de SSDs draait...)

Ik snap nog steeds je punt niet qua virtualisatie. Je *hoeft* geen VM te draaien om ZFS op Proxmox te draaien.
Het ondersteund het echt _native_

Full disk encryption op root zou ik persoonlijk niet zo belangrijk vinden. Wat wil je beschermen? Een 'standaard' Proxmox installatie kan iedereen nadoen?
Full disk encryption voor je ZFS pool kan ik in komen. Ik zou Proxmox zelf niet zo snel op ZFS draaien. Nergens voor nodig.

Een encrypted ZFS pool maken op LUKS is even wat commandline werk, maar zodra de pool er is, kan je prima via de Proxmox GUI deze weer gebruiken voor VM's, dus ik zie daar niet echt veel problemen mee.

Of ik moet je ergens niet begrijpen.

[FireDrunk]

CAPSLOCK2000 schreef op dinsdag 16 oktober 2018 @ 16:24:
Ter lering ende vermaeck.
Ik wil de een defect disk vervangen in mijn raidz2.
Mijn plan was om de disk eerst als spare toe te voegen, deze te activeren en dan de oude schijf er uit te halen.

Ik gaf dus het commando:

zpool add tank /dev/een/disk

En dat is helemaal verkeerd. Het had moeten zijN:

zpool add spare tank /dev/een/disk

ZFS heeft mijn pool nu uitgebreid met die disk, zeg maar RAID-0 en ik krijg hem er niet meer uit.

Uiteindelijk heb ik met mijn domme en vermoeide hoofd de partitietabel van die disk gewist met zo iets van 'ik zal jou krijgen". Dat was natuurlijk helemaal verkeerd en nu weigert mijn pool nog te starten. Ik was zo naief om te denken dat het herstellen van de partitietabel genoeg zou zijn om de schijf weer te zien. Dat blijkt een onjuiste aanname, en nu lijkt mijn pool reddeloos verloren

Het is erg frustrerend omdat ik weet dat alle dat gewoon nog op de schijven staat. Fundamenteel zit het me niet lekker dat ik de redundantie van de data kan verlagen door een schijf verkeerd toe te voegen, en dan niet meer terug kan.

Ik ben momenteel ernstig met mezelf aan het overleggen of ik wel verder moet gaan met ZFS of dat het tijd is voor iets anders.

Er zijn wat mini-guides hoe je dat terugdraait. Ik ga even voor je googlen. Belangrijk: even niets doen met de pool.

[dcm360]

mdbraber schreef op dinsdag 16 oktober 2018 @ 16:34:
[...]


Yes, daar ben ik me van bewust. De SSDs in mn cloud-server zijn Enterprise SSDs. Ik moet eerlijk zeggen dat ik niet weet of het zijn heeft om ook Enterprise SSDs in mn thuis-server te zetten. Iets zegt me dat dat voelt als overkill, maar heeft iemand daar wellicht cijfers over?

Hangt er van af wat je overkill noemt. Op een Crucial MX200 en Crucial MX300 ging het hard genoeg om ze in 3 jaar tijd door de TBW te jagen. Ook kunnen ze er niet zo goed tegen dat er geen TRIM ondersteund wordt door ZoL, dus de prestaties waren om te huilen.
In een nieuw apparaat heb ik een Intel Optane geplaatst, en die heeft van beide pijnpunten tot zover geen last na een kwart jaar.

[mdbraber]

FireDrunk schreef op dinsdag 16 oktober 2018 @ 16:36:
[...]
Ik snap nog steeds je punt niet qua virtualisatie. Je *hoeft* geen VM te draaien om ZFS op Proxmox te draaien.
Het ondersteund het echt _native_

Ik snap dat het native ondersteund wordt, mijn punt ging dus over dat je het mogelijk in een VM *zou* kunnen draaien vanwege mogelijke voordelen. Niet heel zinnig dus. Point taken :-)

Full disk encryption op root zou ik persoonlijk niet zo belangrijk vinden. Wat wil je beschermen? Een 'standaard' Proxmox installatie kan iedereen nadoen?
Full disk encryption voor je ZFS pool kan ik in komen. Ik zou Proxmox zelf niet zo snel op ZFS draaien. Nergens voor nodig.

Het punt is vnml dat ik mijn LXC containers en VMs ook (grotendeels) op de SSD zou hebben ivm snelheid (de HDDs zijn een stuk langzamer en vnml bedoeld voor backup / slow storage).

Een encrypted ZFS pool maken op LUKS is even wat commandline werk, maar zodra de pool er is, kan je prima via de Proxmox GUI deze weer gebruiken voor VM's, dus ik zie daar niet echt veel problemen mee.

Check!

@FireDrunk Overigens: ik zou Proxmox op een ZFS pool zetten voor het kunnen snapshotten en backup. Zou jij dat eerder doen op (thin)LVM of iets anders?

[ Voor 6% gewijzigd door mdbraber op 16-10-2018 16:46 ]

[mdbraber]

dcm360 schreef op dinsdag 16 oktober 2018 @ 16:40:
[...]

Hangt er van af wat je overkill noemt. Op een Crucial MX200 en Crucial MX300 ging het hard genoeg om ze in 3 jaar tijd door de TBW te jagen. Ook kunnen ze er niet zo goed tegen dat er geen TRIM ondersteund wordt door ZoL, dus de prestaties waren om te huilen.
In een nieuw apparaat heb ik een Intel Optane geplaatst, en die heeft van beide pijnpunten tot zover geen last na een kwart jaar.

Even back of the envelope berekening: mijn 500GB SSD heeft een TBW van 200. Stel dat ik de lifespan op 10 jaar zet dan is dat 20TB/jaar of 1.6TB/maand. Dat zou dan alleen om writes gaan van de containers / VMs. Als ik m'n downloads niet direct naar de SSD schrijf maar direct naar de storage dan zou dit toch goed moeten gaan (aangenomen dat ik genoeg heb aan 1.6TB voor 'normal operations')?

[FireDrunk]

@CAPSLOCK2000 Afhankelijk van je ZFS versie zou je wel een toplevel zpool remove moeten kunnen done:

https://github.com/zfsonlinux/zfs/pull/7893

zpool remove [-np] pool device...
             Removes the specified device from the pool.  This command supports
             removing hot spare, cache, log, and both mirrored and [b]non-redundant
             primary top-level vdevs[/b], this includes dedup and special vdevs.  When
             the primary pool storage includes a top-level raidz vdev only hot
             spare, cache, and log devices can be removed.

Proberen waard.

@dcm360

TRIM support is "just-around-the-corner":

https://github.com/zfsonlinux/zfs/pull/7363

@mdbraber
VM's snapshotten kan prima als alleen de VM op ZFS staat. Of Proxmox op ZFS staat heeft daar weinig mee te maken. Tenzij je Proxmox zelf wil snapshotten, maar dat lijkt me niet nodig.

[ Voor 19% gewijzigd door FireDrunk op 16-10-2018 16:50 ]

[CAPSLOCK2000]

FireDrunk schreef op dinsdag 16 oktober 2018 @ 16:37:


Er zijn wat mini-guides hoe je dat terugdraait. Ik ga even voor je googlen. Belangrijk: even niets doen met de pool.

Heel tof, ik hoop dat je wat kan vinden want mijn pogingen zijn allemaal op niks uitgelopen. zpool import heeft een -T optie om transacties terug te draaien, maar dat werkt niet over veranderingen aan je hardware heen.
Solaris schijnt daar beter mee om te gaan, dus heb ik een OpenSolaris USB-stok klaar liggen, maar helaas lijkt mijn hardware te nieuw voor OpenSolaris (al heb ik deze route nog niet opgegeven, ik ben gewoon niet bekend genoeg met O.S.).

Ik heb de nieuwste versie van ZFS gecompileerd om dat er recent wat patches zijn doorgevoerd om beter met missende devices om te gaan, maar dat biedt dusver nog geen soelaas. Vervolgens heb ik, je bent wanhopig of je bent het niet, de drivers aangepast om de checks op missende disks er uit te slopen. Ook dat heeft niet geholpen. Hij herkent de nieuwe disk wel maar zegt dat de data er op corrupt is waardoor het array niet meer gestart kan worden.

Ondertussen is de falende disk (of misschien wel twee disks) een ravage aan het aanrichten en trekt andere schijven mee down.

[dcm360]

mdbraber schreef op dinsdag 16 oktober 2018 @ 16:44:
[...]


Even back of the envelope berekening: mijn 500GB SSD heeft een TBW van 200. Stel dat ik de lifespan op 10 jaar zet dan is dat 20TB/jaar of 1.6TB/maand. Dat zou dan alleen om writes gaan van de containers / VMs. Als ik m'n downloads niet direct naar de SSD schrijf maar direct naar de storage dan zou dit toch goed moeten gaan (aangenomen dat ik genoeg heb aan 1.6TB voor 'normal operations')?

Dat zou op zich al beter moeten gaan, de door mij genoemde MX200 heeft slechts een TBW van 80TB. Vraag is nog wel wat een gebrek aan TRIM ermee doet.

FireDrunk schreef op dinsdag 16 oktober 2018 @ 16:45:
@dcm360

TRIM support is "just-around-the-corner":

https://github.com/zfsonlinux/zfs/pull/7363

De indruk dat het best binnenkort eens gaat gebeuren had ik een half jaar geleden ook al (zie ook de datum van de PR). Ik heb niet echt de verwachting meer dat het heel erg snel gaat gebeuren, de laatste updates aan de PR zijn ook niet echt hoopvol.

[CAPSLOCK2000]

FireDrunk schreef op dinsdag 16 oktober 2018 @ 16:45:

https://github.com/zfsonlinux/zfs/pull/7893

zpool remove [-np] pool device...
             Removes the specified device from the pool.  This command supports
             removing hot spare, cache, log, and both mirrored and ~~[b]non-redundant
             primary top-level vdevs~~[/b], this includes dedup and special vdevs.  When
             the primary pool storage includes a top-level raidz vdev only hot
             spare, cache, and log devices can be removed.

Tnx, dat had ik al tevergeefs geprobeerd. Ik krijg de melding dat het device niet kan worden verwijderd. Ik zie dat die tekst super recent is, misschien dat de versie van ZFS die ik gebruikte (7.11) hier nog niet zo goed meer overweg kon.

Uit mijn logs:

root@whisky:~# zpool remove tank /dev/een/schijf
cannot remove schijf: only inactive hot spares, cache, or log devices can be removed

[FireDrunk]

Oeh, das inderdaad lastig. Om nou een devel versie van ZFS te installeren om alleen die functie te kunnen gebruiken is misschien wat onhandig.

Aan de andere kant, veel andere opties heb je denk ik niet. Ik dacht dat ik ooit wat kon vinden over hoe je die transactie dmv `zdb` kon terugdraaien, maar dat kan ik zo snel niet vinden.

[mdbraber]

dcm360 schreef op dinsdag 16 oktober 2018 @ 16:55:
[...]
Dat zou op zich al beter moeten gaan, de door mij genoemde MX200 heeft slechts een TBW van 80TB. Vraag is nog wel wat een gebrek aan TRIM ermee doet.
[...]

Wel goed dat je me er nog eens aan herinnert want ik heb eens naar de waarden van de smartctl output gekeken van mn cloud-server (Hetzner auction server, dus gebruikte componenten) en die waren enorm bedroevend. Nog eens heroverwegen of ik daar in de plaats een nieuwe server ga zetten.

Btw - als je niet Proxmox op een SSD adviseert, wat zou je dan aanraden? Of wel op een SSD maar alleen maar enterprise? Btw - hier een interessant draadje over Proxmox en (enterprise) SSDs (o.a. overprovisioning als tip): https://forum.proxmox.com...on-enterprise-ssds.43684/

[ Voor 11% gewijzigd door mdbraber op 16-10-2018 17:20 . Reden: link toegevoegd ]

[FireDrunk]

@CAPSLOCK2000 Zojuist even getest, de laatste FreeBSD 12.0-SNAPSHOT ISO ondersteund het verwijderen van top level VDEV's d.m.v. zpool remove. Dat kan je proberen.

[CAPSLOCK2000]

FireDrunk schreef op dinsdag 16 oktober 2018 @ 17:03:
Oeh, das inderdaad lastig. Om nou een devel versie van ZFS te installeren om alleen die functie te kunnen gebruiken is misschien wat onhandig.

Ik ben bang dat het te laat is. De devel versie installeren heb ik al gedaan. Helaas moet ik mijn pool wel kunnen starten voor ik er een device uit kan halen, daar gaat het dus al fout.

Aan de andere kant, veel andere opties heb je denk ik niet. Ik dacht dat ik ooit wat kon vinden over hoe je die transactie dmv `zdb` kon terugdraaien, maar dat kan ik zo snel niet vinden.

Wat ik daar over heb gevonden is dat 'zpool import -T<id>' of 'zfs import -FX' dat kunnen, maar niet over veranderingen in de hardware heen. De eerste transacties die ik zie zijn van direct na dat ik de schijf heb toegevoegd aan de array.

Dat betekent niet dat andere transacties weg zijn, die zouden er ook nog moeten zijn. Ik overweeg om blokken data van de schijf te gaan wissen om zo recente transacties weg te gummen tot ik bij een transactie kom van voordat ik die schijf toevoegde. Ik acht de kans op succes bijzonder laag.

[CAPSLOCK2000]

FireDrunk schreef op dinsdag 16 oktober 2018 @ 17:20:
@CAPSLOCK2000 Zojuist even getest, de laatste FreeBSD 12.0-SNAPSHOT ISO ondersteund het verwijderen van top level VDEV's d.m.v. zpool remove. Dat kan je proberen.

Tnx, ga ik proberen, maar ik vrees dat FreeBSD het ook niet kan zonder eerst de pool te starten. Dat kan ik alleen niet op afstand testen, het zal dus moeten wachten tot ik weer thuis ben.

[FireDrunk]

Je zult inderdaad sowieso de pool moeten importeren, maar ik verwacht dat dat geen probleem is.
Zolang je de pool maar *niet* upgrade
Oh wacht, dat zou idd wel eens een probleem kunnen zijn. Je mag de pool dan niet 'online' brengen. Geen idee of je dan wel een device mag verwijderen. Let's hope so.

@mdbraber Ik draai Proxmox zelf op een Samsung 850 Pro (welke daarvoor in mijn werkstation heeft gezeten, en daar al de nodige ellende over zich heen heeft gekregen).

Ik zou me daar niet zo druk over maken. Als je echt voor een dubbeltje een SSD komt zou het inderdaad een probleem kunnen zijn, maar mits je een beetje zelfrespecterende SSD koopt zou het geen probleem moeten zijn.

Mijn SSD die al jaren dienst doet:

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       735
175 Program_Fail_Count_Chip 0x0032   100   100   010    Old_age   Always       -       0
176 Erase_Fail_Count_Chip   0x0032   100   100   010    Old_age   Always       -       0
177 Wear_Leveling_Count     0x0013   078   078   005    Pre-fail  Always       -       774
178 Used_Rsvd_Blk_Cnt_Chip  0x0013   100   100   010    Pre-fail  Always       -       0
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0013   100   100   010    Pre-fail  Always       -       9152
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
195 Hardware_ECC_Recovered  0x001a   200   200   000    Old_age   Always       -       0
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       62148494470
242 Total_LBAs_Read         0x0032   099   099   000    Old_age   Always       -       57841017079

Dat is dus ~26TB written.

[ Voor 91% gewijzigd door FireDrunk op 16-10-2018 17:29 ]

[CurlyMo]

CAPSLOCK2000 schreef op dinsdag 16 oktober 2018 @ 16:24:
Mijn plan was om de disk eerst als spare toe te voegen, deze te activeren en dan de oude schijf er uit te halen.

Hier gaat het al mis. Zo hoort dat niet. Maar dat zal je nu ook wel door hebben. Toch verbaasd het me hoeveel mensen dingen anders doen dan ZFS het bedoeld heeft. Het vervangen van een schijf hoort nog altijd te gaan via:

zpool replace tank [old] [new]

ZFS heeft mijn pool nu uitgebreid met die disk, zeg maar RAID-0 en ik krijg hem er niet meer uit.

Ook hier is tegenwoordig gewoon een oplossing voor. ZFS ondersteund sinds kort namelijk het verwijderen van schijven toegevoegd als top-level vdev's. Dat is zoals @FireDrunk al aangaf het commando:

zpool remove tank [device]

Sinds in ieder geval FreeBSD 12 moet het verwijderen van een schijf van een RAIDZ[123] array ook ondersteund worden.

Fundamenteel zit het me niet lekker dat ik de redundantie van de data kan verlagen door een schijf verkeerd toe te voegen, en dan niet meer terug kan.

Ik kan hier niks anders op zeggen dan RTFM of vraag om hulp.

Ik ben momenteel ernstig met mezelf aan het overleggen of ik wel verder moet gaan met ZFS of dat het tijd is voor iets anders.

Je kan het ZFS niet kwalijk nemen dat jij je pool molt door de verkeerde commando's te gebruiken. Elk ander RAID systeem zal je net zo hard mollen op deze manier.

CAPSLOCK2000 schreef op dinsdag 16 oktober 2018 @ 16:49:
[...]
Ondertussen is de falende disk (of misschien wel twee disks) een ravage aan het aanrichten en trekt andere schijven mee down.

Hoe heb je dit vastgesteld? Want als dat zo is, dan werkt de pool blijkbaar nog wel voor ZFS.

CAPSLOCK2000 schreef op dinsdag 16 oktober 2018 @ 16:56:
Uit mijn logs:

root@whisky:~# zpool remove tank /dev/een/schijf
cannot remove schijf: only inactive hot spares, cache, or log devices can be removed

Probeer eens FreeBSD 11.2. Daarin heb ik dit afgelopen week geprobeerd met een test pool met bestandjes als vdevs. Dat gaf me jammer genoeg kernel panics, maar de schijf was wel verwijderd.

Geef ons verder eens wat meer informatie. Bijv. een zpool import output.

[mdbraber]

@FireDrunk OK - dan lijkt dit nog niet zo heel slecht. Een raw_value van 1 voor iedere 65,356 sectors (32MB) written is ongeveer ~3.3TB written in ~4.5 jaar (met een power cycle count van 14... )

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       40430
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       14
177 Wear_Leveling_Count     0x0013   098   098   005    Pre-fail  Always       -       268
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0013   100   100   010    Pre-fail  Always       -       5248
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   072   064   000    Old_age   Always       -       28
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
202 Exception_Mode_Status   0x0033   100   100   010    Pre-fail  Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       6
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       6941418531

[CurlyMo]

Iemand een idee hoe je dit bij mijn Crucial MX300 SSD's doet?

code:

246 Total_Host_Sector_Write 0x0032   100   100   ---    Old_age   Always       -       34443599574
246 Total_Host_Sector_Write 0x0032   100   100   000    Old_age   Always       -       61681646870

[mdbraber]

CurlyMo schreef op dinsdag 16 oktober 2018 @ 19:06:
Iemand een idee hoe je dit bij mijn Crucial MX300 SSD's doet?

Hier wat pointers: https://askubuntu.com/que...th-of-a-ssd/381779#381779. En dit was de eerste hit als je zoekt op Total_Host_Sector_Write https://forums.crucial.co...Sector-Writes/td-p/171056

Let even goed op dat dit soort SMART data device specifiek is en smartctl voornamelijk gericht lijkt op Intel en Samsung SSDs en andere output nog wel eens volledig niet kan kloppen (check ook even of je SSD in de database staat met

smartctl -P

[ Voor 13% gewijzigd door mdbraber op 16-10-2018 19:12 ]

[FireDrunk]

Volgens mij hebben bijna alle SSD's LBA's van 512 bytes, dus is het gewoon dat getal maal 512 bytes.
Maar ik heb deze gebruikt:
https://www.virten.net/20...bytes-written-calculator/

@mdbraber 3.3TB is peanuts

[ Voor 18% gewijzigd door FireDrunk op 16-10-2018 19:42 ]

[CurlyMo]

mdbraber schreef op dinsdag 16 oktober 2018 @ 19:10:
[...]
Hier wat pointers: https://askubuntu.com/que...th-of-a-ssd/381779#381779.

Ik heb geen Wear_Leveling_Count

En dit was de eerste hit als je zoekt op Total_Host_Sector_Write https://forums.crucial.co...Sector-Writes/td-p/171056

Dat heb ik natuurlijk gezien, maar klopt dat? Want ZFS gebruikt die 4k sector sizes? Of moet ik uitgaan van de logical bytes?

FireDrunk schreef op dinsdag 16 oktober 2018 @ 19:38:
Volgens mij hebben bijna alle SSD's LBA's van 512 bytes, dus is het gewoon dat getal maal 512 bytes.
Maar ik heb deze gebruikt:
https://www.virten.net/20...bytes-written-calculator/

Ik mijn geval is dat dus 28.72 TB en 16.04 TB

[ Voor 24% gewijzigd door CurlyMo op 16-10-2018 19:55 ]

[CAPSLOCK2000]

CurlyMo schreef op dinsdag 16 oktober 2018 @ 18:49:
[...]

Hier gaat het al mis. Zo hoort dat niet. Maar dat zal je nu ook wel door hebben. Toch verbaasd het me hoeveel mensen dingen anders doen dan ZFS het bedoeld heeft. Het vervangen van een schijf hoort nog altijd te gaan via:

zpool replace tank ~~~[old] ~~~[new]

Het verhaal is eigenlijk langer dan dit, ik heb last van rotte hardware. De een na de andere schijf valt om, en ik kom er nog niet achter wat het is, een slechte batch schijven, een slechte controller, een slechte kabel, falende voeding, een rotte schijf die de controller meeneemt, iets?

Om de data te beschermen heb ik wat extra schijven aan het systeem toegevoegd om zo iedere verdachte schijf te mirrorren. Misschien niet de beste oplossing, maar wel die oplossing die ik binnen handbereik had om m'n data zo goed mogelijk te beschermen. Bij het toevoegen van de derde spare ging het fout.

Ook hier is tegenwoordig gewoon een oplossing voor. ZFS ondersteund sinds kort namelijk het verwijderen van schijven toegevoegd als top-level vdev's. Dat is zoals @FireDrunk al aangaf het commando:

zpool remove tank ~~~[device]

Dat heb ik gedaan en het werkte niet, het lijkt er op dat ZFSonLinux nog niet zo geavanceerd is/was.

Sinds in ieder geval FreeBSD 12 moet het verwijderen van een schijf van een RAIDZ[123] array ook ondersteund worden.

Na deze post ga ik dat proberen.

Je kan het ZFS niet kwalijk nemen dat jij je pool molt door de verkeerde commando's te gebruiken. Elk ander RAID systeem zal je net zo hard mollen op deze manier.

Ach, als die 'remove' had gewerkt dan was er niks aan de hand geweest. Ik neem het ZFS uiteraard niet kwalijk dat ik iets doms heb gedaan. Ik ben wel een beetje teleurgesteld in hoe makkelijk in een situatie kwam waar geen weg terug was. Dat zal dan wel een gebrek van ZFSonLinux zijn, maar dat maakt voor mij verder weinig uit. Ik gebruik Linux dus als ZFSonLinux niet goed genoeg is, dan zal ik daar rekening mee moeten houden.

Ik kom hier niet om over ZFS te zeiken of te zeggen dan andere systemen beter zijn. Maar dit incident heeft me wel aan het denken gezet over hoe storage hoort te werken, en daar is echt nog wel wat aan te verbeteren. Ja, ik heb wat doms gedaan, maar dat neemt niet weg dat al mijn bitjes nog op die disks staan. De primaire taak van ieder storage-systeem is mijn bitjes terughalen. Dat kan beter.

Hoe heb je dit vastgesteld? Want als dat zo is, dan werkt de pool blijkbaar nog wel voor ZFS.

Kernel messages die zeggen dat schijven offline gaan en weer terugkomen.
zpool import (dat faalt) laat zien dat schijven op 'unvail' gaan of zelfs op 'corrupted'.
Dat ligt niet aan ZFS, dat is de hardware, maar zolang ZFS niet werkt kan ik de data niet verplaatsen.

Probeer eens FreeBSD 11.2. Daarin heb ik dit afgelopen week geprobeerd met een test pool met bestandjes als vdevs. Dat gaf me jammer genoeg kernel panics, maar de schijf was wel verwijderd.

Ga ik zo doen.

Geef ons verder eens wat meer informatie. Bijv. een zpool import output.

Heel eerlijk kwam ik hier vooral om anderen te waarschuwen en heb ik zelf de hoop een beetje opgegeven, daarom gaf ik niet meer info. Niettemin ben ik blij met alle hulp en belangstelling, dus, here we go.

whisky:# zpool add tank sdl
        NAME                                                  STATE     READ WRITE CKSUM
        tank                                                  ONLINE       0     0     0
          raidz2-0                                            ONLINE       0     0     0
            spare-0                                           ONLINE       0     0     4
              sdd                                             ONLINE       0     0     0
              sde                                             ONLINE       0     0     0
            spare-1                                           ONLINE       0     0     8
              sdc                                             ONLINE       0     0     0
              sdj                                             ONLINE       0     0     0
            sdb                                               ONLINE       0     0     0
            sda                                               ONLINE       0     0     3
            sdf                                               ONLINE       0     0     0
            sdg                                               ONLINE       0     0     3
          sdl
     logs
          ata-ADATA_SSD_S396_30GB_02328114500200000262-part2  ONLINE       0     0     0
        cache
          ata-ADATA_SSD_S396_30GB_02328114500200000262-part3  ONLINE       0     0     0
        spares
          sde                                                                                 INUSE     currently in use
          sdj                                                                                  INUSE     currently in use

Hier begon het avontuur min of meer, sdl is de schijf die ik foutief heb toegevoegd.
De andere schijven zijn op dit (weer) online en in orde.
<intermezzo>
Ik weet dat het gebruik van namen als 'sda' en 'sdl' niet ideaal is. Dat was niet mijn keuze. Op zoek naar mijn hardware-probleem heb ik de SAS-controller vervangen en toen heeft ZFS deze namen aangenomen. Die namen vervangen door stabiele namen stond nog op de todo-lijst maar ik had eerst andere prioriteiten, achteraf gezien misschien de verkeerde.
</intermezzo>

Na het lomp verwijderen van de schijf, dacht ik de boel te kunnen redden door een nieuwe partitietabel aan te maken. ZFS zag de schijf toen weer, maar wel als corrupted:

[/pre]
(irrelevante regels weggelaten)
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
spare-0 ONLINE 0 0 4
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
spare-1 ONLINE 0 0 8
sdc ONLINE 0 0 0
sdj ONLINE 0 0 0
sdb ONLINE 0 0 0
sda ONLINE 0 0 3
sdf ONLINE 0 0 0
sdg ONLINE 0 0 3
sdl FAULTED corrupted data
[/pre]

Toen begon de hardware weer op te spelen. Inmiddels kijk ik hier naar:

        tank                                                  FAULTED  corrupted data
          raidz2-0                                            UNAVAIL  insufficient replicas
            spare-0                                           DEGRADED
              sdd                                             UNAVAIL
              sdb                                             ONLINE
            spare-1                                           DEGRADED
              sdc                                             UNAVAIL
              sde                                             ONLINE
            sdb                                               FAULTED  corrupted data
            sda                                               FAULTED  corrupted data
            sdf                                               UNAVAIL
            sdg                                               UNAVAIL

Had ik al gezegd dat ik het redelijk dicht bij opgeven ben?
Ik verwacht dat de UNAVAIL schijven terugkomen als ik reboot en het dan weer prima doen, maar ZFS nog steeds niet start om dat 'sdl' mist.

[ Voor 9% gewijzigd door CAPSLOCK2000 op 16-10-2018 21:40 ]

[CurlyMo]

CAPSLOCK2000 schreef op dinsdag 16 oktober 2018 @ 21:19:
[...]
Ik ben wel een beetje teleurgesteld in hoe makkelijk in een situatie kwam waar geen weg terug was. Dat zal dan wel een gebrek van ZFSonLinux zijn, maar dat maakt voor mij verder weinig uit.

Hier ben ik het helemaal mee eens. ZFS maakt het extreem simpel om de meest domme dingen te doen. Er zit nergens een confirmatie die zegt:

Weet je zeker dat je je complete data collectie met je volledige collectie aan heel dierbare familie geschiedenis wilt verwijderen, waarvan we gezien hebben dat je het nog niet in een backup hebt staan:

Kies nee of nee [N]:
Kies nou nee! [N]:
Weet je het echt zeker?!: [N]
Als je morgen het Russische volkslied fonetisch correct weet te zingen waarbij je de melodie meetikt met de [Y] knop, dan zullen we inderdaad je pool kapot maken. Tot morgen [N]:

Het verhaal is eigenlijk langer dan dit, ik heb last van rotte hardware. De een na de andere schijf valt om, en ik kom er nog niet achter wat het is, een slechte batch schijven, een slechte controller, een slechte kabel, falende voeding, een rotte schijf die de controller meeneemt, iets?

Had je wel eerder om hulp gevraagd?

Ja, ik heb wat doms gedaan, maar dat neemt niet weg dat al mijn bitjes nog op die disks staan. De primaire taak van ieder storage-systeem is mijn bitjes terughalen. Dat kan beter.

Toch vraag ik me af of dit bij een ander RAID systeem anders zal zijn.

Kernel messages die zeggen dat schijven offline gaan en weer terugkomen.
zpool import (dat faalt) laat zien dat schijven op 'unvail' gaan of zelfs op 'corrupted'.
Dat ligt niet aan ZFS, dat is de hardware, maar zolang ZFS niet werkt kan ik de data niet verplaatsen.

Ander OS, ander tijdelijk systeem?

whisky:# zpool add tank sdl
        NAME                                                  STATE     READ WRITE CKSUM
        tank                                                  ONLINE       0     0     0
          raidz2-0                                            ONLINE       0     0     0
            spare-0                                           ONLINE       0     0     4
              sdd                                             ONLINE       0     0     0
              sde                                             ONLINE       0     0     0
            spare-1                                           ONLINE       0     0     8
              sdc                                             ONLINE       0     0     0
              sdj                                             ONLINE       0     0     0
            sdb                                               ONLINE       0     0     0
            sda                                               ONLINE       0     0     3
            sdf                                               ONLINE       0     0     0
            sdg                                               ONLINE       0     0     3
          sdl
     logs
          ata-ADATA_SSD_S396_30GB_02328114500200000262-part2  ONLINE       0     0     0
        cache
          ata-ADATA_SSD_S396_30GB_02328114500200000262-part3  ONLINE       0     0     0
        spares
          sde                                                                                 INUSE     currently in use
          sdj                                                                                  INUSE     currently in use

Ik zie niks raars.

Inmiddels kijk ik hier naar:

Hier wordt sdl helemaal niet meer genoemd. Heb je die reboot als een geprobeerd? Eventueel direct in FreeBSD?

Ik zal eens in een FreeBSD VM kijken of ik het geheel kan testen voor je.

[FireDrunk]

Weet je zeker dat het niet aan die drive letters ligt? Probeer eens de pool te exporteren en dan te doen:

zpool import -d /dev/disk/by-id/ <poolnaam>

[CAPSLOCK2000]

Ik heb m'n post bijgewerkt met nog een extra tussenstap.

Had je wel eerder om hulp gevraagd?

Nee, niet echt mijn stijl. Ik lees de handleiding en de source. Verder liggen de problemen die ik heb prima binnen mijn vermogen om het op te lossen, maar met ZFS heb ik iets stoms gedaan.

Toch vraag ik me af of dit bij een ander RAID systeem anders zal zijn.

LVM en BTRFS hadden dit concrete probleem niet gehad, daar werkt 'remove' gewoon, dus wat dat betreft wel. Of ze het hadden overleefd als ik er net zo lomp een schijf uit had gerukt betwijfel ik (nou ja), dat was gewoon stom van mij. Ik heb het letterlijk gedaan terwijl ik de eerste pot koffie van de dag aan het zetten was, waarmee bewezen is hoe belangrijk die koffie is.
Ik heb vergelijkbare situaties met Linux-LVM/RAID kunnen redden, al is het behoorlijk harig, dat heeft me wellicht wat overmoedig gemaakt.

Ander OS, ander tijdelijk systeem?

Ander OS staat komt er zo aan, andere hardware ligt op dit moment praktisch gezien wat moeilijker, een deel van het systeem is overigens al vervangen en verder moet ik op de postbode wachten.

[pimlie]

FireDrunk schreef op dinsdag 16 oktober 2018 @ 19:38:
@mdbraber 3.3TB is peanuts
[Afbeelding]

Is dit wat je bedoelt? ~226TB and still going strong

code:

246 Total_Host_Sector_Write 0x0032   100   100   000    Old_age   Always       -       485862404879

(is trouwens een 256GB Crucial MX100 waarvan 50GB als zfs log dient)

[ Voor 8% gewijzigd door pimlie op 16-10-2018 22:11 ]

[FireDrunk]

Bijvoorbeeld

[CurlyMo]

CAPSLOCK2000 schreef op dinsdag 16 oktober 2018 @ 21:53:
Ander OS staat komt er zo aan, andere hardware ligt op dit moment praktisch gezien wat moeilijker, een deel van het systeem is overigens al vervangen en verder moet ik op de postbode wachten.

Ik heb het even getest en ik heb slecht nieuws:

# zpool create test raidz2 da1 da2 da3 da4
# zpool status
  pool: test
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        test        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
            da4     ONLINE       0     0     0

errors: No known data errors
# zpool add test da5
invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: pool uses raidz and new vdev is disk
# zpool add test /dev/da5
invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: pool uses raidz and new vdev is disk
# zpool add -f test /dev/da5
# zpool status
  pool: test
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        test        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
            da4     ONLINE       0     0     0
          da5       ONLINE       0     0     0

errors: No known data errors
# zpool remove test da4
cannot remove da4: only inactive hot spares, cache, top-level, or log devices can be removed
# uname -a
FreeBSD dev-freebsd 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 02:10:02 UTC 2016     [e-mail]:/usr/obj/usr/src/sys/GENERIC  amd64

Even een upgrade naar 11.2

# uname -a
FreeBSD dev-freebsd 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018     [e-mail]:/usr/obj/usr/src/sys/GENERIC  amd64
# zpool remove test da5
cannot remove da5: invalid config; all top-level vdevs must have the same sector size and not be raidz.
# zpool destroy test
# zpool create test /dev/da1 /dev/da2 /dev/da3 /dev/da4 /dev/da5
# zpool status
  pool: test
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        test        ONLINE       0     0     0
          da1       ONLINE       0     0     0
          da2       ONLINE       0     0     0
          da3       ONLINE       0     0     0
          da4       ONLINE       0     0     0
          da5       ONLINE       0     0     0

errors: No known data errors
# zpool status
  pool: test
 state: ONLINE
  scan: none requested
remove: Removal of vdev 4 copied 33K in 0h0m, completed on Tue Oct 16 21:31:42 2018
    120 memory used for removed device mappings
config:

        NAME          STATE     READ WRITE CKSUM
        test          ONLINE       0     0     0
          da1         ONLINE       0     0     0
          da2         ONLINE       0     0     0
          da3         ONLINE       0     0     0
          da4         ONLINE       0     0     0

errors: No known data errors

Wat ik dan wel heel interessant vind is dat FreeBSD wel een foutmelding geeft als je op jouw manier een schijf toevoegt aan een RAIDZ pool:

# zpool add test da5
invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: pool uses raidz and new vdev is disk

In FreeBSD 12.0 zou het verwijderen van een schijf uit een RAIDZ pool wel moeten werken, maar die is nog niet beschikbaar.

[pimlie]

Heeft iemand ervaring met Seagate 2.5" 5TB disks icm zfs? Deze bv: pricewatch: Seagate Backup Plus Portable Drive (STDR) 5TB Zwart

Zit er over te denken om deze te gebruiken voor een nieuwe server, maar mijn huidige WD Blue's geven nogal wat problemen icm de H200 controllers en zou zonde zijn als dat met de seagate's ook het geval zou zijn.

[CAPSLOCK2000]

CurlyMo schreef op dinsdag 16 oktober 2018 @ 22:08:

# zpool add test da5
invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: pool uses raidz and new vdev is disk

Die waarschuwing had ik graag gehad, dat had me vast gered.

In FreeBSD 12.0 zou het verwijderen van een schijf uit een RAIDZ pool wel moeten werken, maar die is nog niet beschikbaar.

Staat te booten

[ Voor 3% gewijzigd door CAPSLOCK2000 op 16-10-2018 22:49 ]

[CurlyMo]

CAPSLOCK2000 schreef op dinsdag 16 oktober 2018 @ 22:49:
Die waarschuwing had ik graag gehad.

Qua ZFS vertrouw ik FreeBSD toch nog altijd meer dan Linux. Het zijn deze kleine dingen die het doen. Misschien even een github issue over openen, waarom die melding er op FreeBSD wel is, maar in ZoL niet.

Staat te booten

Lijkt me sterk, want FreeBSD 12.0 is nog niet uit

[ Voor 13% gewijzigd door CurlyMo op 16-10-2018 22:55 ]

[FireDrunk]

@CurlyMo je test de verkeerde dingen volgens mij. Hij heeft een top level disk naast zijn raidz pool toegevoegd.
Wat jij test is een device uit een zpool halen.

Overigens zijn er van FreeBSD 12 al 8 Alpha versies uit.

[CurlyMo]

FireDrunk schreef op dinsdag 16 oktober 2018 @ 22:52:
@CurlyMo je test de verkeerde dingen volgens mij. Hij heeft een top level disk naast zijn raidz pool toegevoegd.
Wat jij test is een device uit een zpool halen.

In de tweede test wel, maar in de eerste niet

[CAPSLOCK2000]

@CurlyMo @FireDrunk

Ik probeer inderdaad een alpha van FreeBSD 12. De live editie ziet m'n sas-controller helaas nog niet (of het ding heeft de geest gegeven), to be continued.

[CurlyMo]

CAPSLOCK2000 schreef op dinsdag 16 oktober 2018 @ 22:57:
@CurlyMo @FireDrunk

Ik probeer inderdaad een alpha van FreeBSD 12. De live editie ziet m'n sas-controller helaas nog niet (of het ding heeft de geest gegeven), to be continued.

Ik ga mijn test even op de Alpha van FreeBSD 12 doen.

---

Ik heb slecht nieuws:

# zpool status
  pool: test
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        test        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
            da4     ONLINE       0     0     0
          da5       ONLINE       0     0     0

errors: No known data errors
# zpool remove test da5
cannot remove da5: invalid config; all top-level vdevs must have the same sector size and not be raidz.
# zpool remove test da5
# uname -a
FreeBSD devfreebsd 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 r339271 GENERIC  amd64

[ Voor 52% gewijzigd door CurlyMo op 16-10-2018 23:32 ]

[CAPSLOCK2000]

Het is nu geluk om FreeBSD 12 te booten en m'n schijven te zien. Helaas kan ook FreeBSD 12 de pool niet importeren en is het niet mogelijk om een schijf te verwijderen uit een pool die niet online is.

Onder Linux is de rest van m'n schijven ook weer wakker geworden, en ik heb weer een iets gezondere pool om mee te werken:

root@whisky:~# zpool import
   pool: tank
     id: 4066078533163291458
  state: UNAVAIL
 status: One or more devices are faulted.
 action: The pool cannot be imported due to damaged devices or data.
 config:

        tank                                                  UNAVAIL  insufficient replicas
          raidz2-0                                            ONLINE
            spare-0                                           ONLINE
              sdd                                             ONLINE
              sdf                                             ONLINE
            spare-1                                           ONLINE
              sdc                                             ONLINE
              sdi                                             ONLINE
            sdb                                               ONLINE
            sda                                               ONLINE
            sde                                               ONLINE
            sdg                                               ONLINE
          sdk                                                 FAULTED  corrupted data
        logs
          ata-ADATA_SSD_S396_30GB_02328114500200000262-part2  ONLINE

[CurlyMo]

CAPSLOCK2000 schreef op dinsdag 16 oktober 2018 @ 23:35:
Onder Linux is de rest van m'n schijven ook weer wakker geworden, en ik heb weer een iets gezondere pool om mee te werken:

Het vervelende is dat je je sdk schijf kapot hebt gemaakt. Anders had je je pool nog kunnen importeren om de data eraf te halen. Een long shot is eventueel bij de zfs mailing list vragen of zij weten hoe je de partitie weer kan herstellen zodat de pool de schijf weer accepteert als onderdeel. Of dat je eventueel via zdb nog relevante informatie kunt achterhalen. Dat zou echter zomaar neer kunnen komen op het beschrijven van die schijf met handmatig geconstrueerde binary blob.

[CAPSLOCK2000]

Een long shot is eventueel bij de zfs mailing list vragen of zij weten hoe je de partitie weer kan herstellen zodat de pool de schijf weer accepteert als onderdeel.

Voor zover ik weet heb ik alleen de partitietabel veranderd. Mijn eerste poging was om die tabel te herstellen. Dat is min of meer gelukt, aan het GUID weet ik niet. Mogelijk is dat het hele probleem. Als dat het is zou ZFS het ergens moeten hebben opgeslagen, maar dat heb ik nog niet kunnen vinden.

De ZDB route ben ik ook aan het proberen, met enig succes, maar het is nogal omslachtig. Mijn vriend probeert er wat om heen te programmeren.

[FireDrunk]

Wat het een GPT partitietabel? Anders kan je misschien nog dmv recovery iets terughalen:

https://www.rodsbooks.com/gdisk/repairing.html

Kopje "Manual Recovery Procedures".

[IceTeaGX]

Heel eenvoudig lijkt het mij toch allemaal niet:
https://www.joyent.com/bl...es-from-a-destroyed-zpool

Al is regel 1 steeds om een 1:1 clone te maken van al je data, voordat je begint te experimenteren.

[CurlyMo]

@CAPSLOCK2000 Even de conclusies op een rij.

Je gaat je pool niet terug kunnen brengen naar de status waarbij je alleen je RAIDZ2 top-level VDEV hebt. Oftewel, schijf sdk krijg je niet meer verwijderd in de nabije toekomst.

Afhankelijk van de hoeveelheid data die je hebt, kan het een voordeel zijn dat je een RAIDZ2 met spares hebt gemaakt.

Als je het aandurft en als je je pool weer weet te importeren, dan zou je met de spares een nieuwe RAIDZ2 pool kunnen maken of een RAID10 pool. Via zfs send/recv kan je dan je volledige pool kopiëren van oud naar nieuw.

Als je echter zoals in jouw geval met spares werkt, dan zou het veel logischer zijn om een RAID10 te maken met 3-way-mirrors. Dan doen die spare schijven namelijk daadwerkelijk wat. Ze zijn in ieder geval altijd een live kopie van je data. Nu is het volgens mij zo dat de spares pas nut krijgen als een schijf uitvalt. De grote máár is dan alleen dat de spare dan nog resilvered moet worden om de pool weer healhty te krijgen, wat dus bij een 3-way-mirror niet zo is.

Dus met hetzelfde aantal schijven is een RAIDZ2 pool met spares is niet direct redundant bij uitval van een schijf terwijl een RAID10 met three-way-mirrors dat wel is.

Oftewel, haal je spares uit je pool. Maak daar een RAID10 van. Zodra je al je data hebt weten veilig te stellen op je nieuwe pool, maak je van je RAID10 two-way-mirrors allemaal three-way-mirrors, waardoor je uiteindelijk veiliger uit bent dan je huidige RAIDZ2 met spares. Let wel goed op je commando's om dat te doen.

Mits je natuurlijk je pool geïmporteerd krijgt en bij ZFS wil blijven. Maar ik zou je aanraden om na deze operatie (of het nu wel of niet gelukt is) toch hulp te vragen.

Ik duim in ieder geval voor je

[CAPSLOCK2000]

Tnx.
Goed nieuws, ik heb m'n pool weer geimporteerd gekregen!
Dusver durf ik alleen read-only, maar toch.

De kunst was

echo 1 > /sys/module/zfs/parameters/zfs_max_missing_tvds 

Ik moest de source lezen om daar achter te komen, maar toen ik het eenmaal wist vond ik: https://www.delphix.com/blog/openzfs-pool-import-recovery

Nu "even" een backup maken, en dan nog een keer proberen dat device er uit te krijgen.
Maar dan ná m'n eerste kopje koffie...

PS. Normaal zitten die spares er niet in. Die heb ik toegevoegd toen het systeem problemen kreeg die ik niet direct kreeg opgelost. De spares zijn in gebruik, dus effectief zijn dat nu 2-way mirrors. Als alles weer in orde is gaan de rotte schijven en overtollige spares er weer uit. 3-way mirror klinkt aantrekkelijk maar is me wat te duur.

[FireDrunk]

Sweet!! Die beveiliging is op zich wel logisch, als je pool ineens een complete VDEV mist, is het beter om dat niet by-default meteen te 'accepteren' als loss

In ieder geval fijn dat hij readonly werkt!

[CAPSLOCK2000]

Voor het volgende slachtoffer... Bovenstaande optie is gloednieuw en zit nog niet in een stabiele versie van ZFSonLinux. Daarna kon ik met 'zpool import -F' de pool weer importeren door de laatste transacties te negeren.

offtopic:
Ik heb nóg een filer gesloopt.
Namelijk het SAN waar ik mijn backups op aan het zetten was.
Maar mijn baas is heel tevreden, de betrouwbaarheid van dat systeem testen stond namelijk op mijn takenlijst, mission accomplished

[FireDrunk]

Is je pool dan nu ook helemaal weer gered en ReadWrite? Of ga je de pool opnieuw opbouwen?

[CAPSLOCK2000]

Ik ben er nog lang niet, de pool is weer leesbaar, maar de foutief toegevoegde disk is nog niet weg. Het zou wel eens lastig kunnen worden als ik ga schrijven.

Het plan is nu eerst een backup te maken. Eigenlijk vind ik dat de duur voor de data waar het om gaat, dat is een geaccepteerd risico, maar voor een paar dagen kan ik wel wat ruimte lenen.

Vervolgens wil ik nog een keer een 'zpool remove' proberen, maar dan de nieuwste versie(s) van ZFS, dus met ZSFonLinux 8 / FreeBSD 12 / OpenIndiana.

Als dat niet werkt wil ik nogmaals 'zpool import -T' proberen om terug te gaan naar een punt in het verleden voordat ik een fout maakte.

Als dat niet werkt ga ik proberen om met ZDB het systeem wijs te maken dat die andere schijf weg is.

Als dat niet werkt ga ik met zfs_revert proberen transacties van de disks te poetsen tot ik het juiste punt in het verleden heb bereikt.

Als dat niet werkt dan weet ik het ook niet meer. Ik heb de data weer, dus ik hoef geen wanhopige pogingen meer te doen om op z'n minst een directory-index te krijgen. Dan is m'n pool weggooien de enige optie die rest.

[CurlyMo]

CAPSLOCK2000 schreef op donderdag 18 oktober 2018 @ 14:44:
Als dat niet werkt dan weet ik het ook niet meer.

Nu begint de "ter lering en vermaak" pas echt. Je vastberaden inzetten om tot het gaatje gaan en kijken wat je er van kan leren.

[FireDrunk]

Ik ben _heel_ beniewd! Als je een klein beetje je stappenplan van 'attempts' bijhoudt, kan dit echt wel een hulp zijn voor meer mensen in dit topic, die in de toekomst net zo'n foutje begaan

[CAPSLOCK2000]

Dat "ter lering en vermaak" ging vooral over jullie vermaak

Ik zal jullie op de hoogte houden van de voortgang, maar nu gaat dit project een paar dagen de koelkast in terwijl er een backup wordt gemaakt. Even de FUP van m'n provider testen

[CAPSLOCK2000]

Een stap vooruit, twee terug.

Nadat ik backup had gemaakt ben ik bovenstaande plan uit gaan voeren.

Vervolgens wil ik nog een keer een 'zpool remove' proberen, maar dan de nieuwste versie(s) van ZFS, dus met ZSFonLinux 8 / FreeBSD 12 / OpenIndiana.

Werkt niet, remove kan niet op een 'read-only' pool, wat niet zo heel vreemd is.
Voor ik -F loslaat op een writable pool wil ik eerst wat minder riskante opties proberen.

Als dat niet werkt wil ik nogmaals 'zpool import -T' proberen om terug te gaan naar een punt in het verleden voordat ik een fout maakte.

Met ZDB heb ik transactienummers gevonden van vlak na mijn fout. Helaas niet van ervoor. Die nummers lopen echter gewoon door, dus ik ben op de gok verder terug in de tijd gegaan tot de laatste transactie had van vlak voor mijn fout.

Dat was behoorlijk succesvol, het filesysteem startte weer en van het verkeerde device was (nog) geen spoor te vinden. Wel kreeg ik een melding over 1 corrupt bestand, dat was gemaakt na mijn fout, maar dat vond ik een acceptabel verlies, het was toch maar een tijdelijk bestand.

Toen dit werkte het heb ik het filesysteem writable gemount en dat leek allemaal prima te werken.
Op een klein dingetje na....
De volgende keer dat ik de pool probeerde te importeren ging hij terug naar de laatste transactie na mijn fout.
Dat had ik niet verwacht. Ik had verwacht dat mijn schrijfactie een nieuwe transactie zou hebben gemaakt die dan de nieuwe 'head' zou zijn. Blijkbaar werkt het niet zo, want zonder expliciet een transactie-nummer mee te geven bleef ik terug gaan naar de oude 'head'.


Voor de zekerheid heb ik het nog een keer geprobeerd, je weet nooit of je niet net tegen een uitzondering aan bent gelopen. Dat ging ook prima. Toen deed ik het een derde keer met wat meer data.... en toen ging het flink mis.

De nieuwe status is dat ik de pool wel kan importeren, maar het filesystem niet kan mounten.

cannot iterate filesystems: I/O error

In een notendop wat ik effectief gedaan heb om mijn filesystem weer te kunnen mounten.

# accepteer 1 missende (top-level) disk
echo 1 > /sys/module/zfs/parameters/zfs_max_missing_tvds
# doe géén volledige scrub voor de mount want dat duurt 20 uur          
echo 0 > /sys/module/zfs/parameters/spa_load_verify_metadata
# niet controleren of je de juiste disk hebt maar gewoon gaan met die banaan    
echo 1 > /sys/module/zfs/parameters/vdev_validate_skip              
zpool import -o readonly=on -T 17619718  tank

Misschien was het beter gegaan als ik de volledige scrub had toegestaan en of vdev_validate_skip had weggelaten. Dat was een bewuste keuze. In deze degraded mode wordt namelijk een volledige scrub uitgevoerd voor ieder commando. Ik had geen zin om 20 uur te gaan wachten om te zien of die import misschien zou werken, om dan na ieder nieuw commando weer 20 uur te gaan zitten wachten. Dan is het terugzetten van de backup al snel efficienter.

[CurlyMo]

CAPSLOCK2000 schreef op maandag 22 oktober 2018 @ 16:10:
Een stap vooruit, twee terug.

Is het makkelijk ook om toe te lichten hoe je je transactie hebt gevonden met zdb? Daar ben ik wel benieuwd naar.

[CAPSLOCK2000]

CurlyMo schreef op maandag 22 oktober 2018 @ 17:06:
[...]

Is het makkelijk ook om toe te lichten hoe je je transactie hebt gevonden met zdb? Daar ben ik wel benieuwd naar.

zdb -ul /dev/doe/maar/een/disk

[CurlyMo]

CAPSLOCK2000 schreef op maandag 22 oktober 2018 @ 17:07:
[...]

zdb -ul /dev/doe/maar/een/disk

Interessant inderdaad. Handzaam met UTC datum indicatie

[Pixeltje]

Hallo, na een hele lange afwezigheid meld ik me ook weer in dit topic. Ik heb ooit met hulp van een aantal tweakers hier een zelfbouw NAS samengesteld, die heb ik besteld en heeft jarenlang prima gewerkt. Het systeem (zie rml hieronder) draait op FreeNas (FreeNAS-9.10.2-U6 om precies te zijn) en heeft vier schijven in raidz2 config die als één volume worden gepresenteerd.

#	Product	Prijs	Subtotaal
1	Intel Pentium G630T Boxed	€ 0,-	€ 0,-
1	Intel Desktop Board DH67CF (B3)	€ 0,-	€ 0,-
1	Fractal Design Array R2 Mini ITX NAS Case	€ 0,-	€ 0,-
1	Scythe Shuriken Rev. B	€ 23,45	€ 23,45
1	Corsair XMS CMX8GX3M2A1333C9	€ 53,90	€ 53,90
Bekijk collectie Importeer producten		Totaal	€ 77,35

Er zitten dus vier schijven in, aangesloten op de SATA poorten van het moederbord. Tot gister waren dat 2 WD black schijven van 2TB en twee Seagate Barracuda LP 2TB. Die seagates zitten er zo goed als vanaf het begin in, de WD black zijn schijven die ik geplaatst heb nadat andere het begeven hadden.

Vorige week kreeg ik de melding dat de pool degraded was omdat er op een of meer devices een 'unrecoverable error' was. Ik heb de NAS daarom uitgeschakeld en gister de defecte schijf (Ada2) vervangen door een nieuwe, ongebruikte WD black 2TB schijf. De schijf die ik uit de NAS heb gehaald was één van de twee oude seagates. Schijf vervangen in de GUI van FreeNas en gisteravond was het resilveren bijna klaar toen ik naar bed ging.

Vanmorgen stond ik op met een nieuwe mail van de NAS dat de pool degraded was omdat er opnieuw een unrecoverable error had plaatsgevonden op een van de schijven. Na controle blijkt dat het wederom om Ada2 gaat.

Nu kan het natuurlijk zo zijn dat ik toevallig een slechte schijf heb gehad en die geplaatst heb, maar ik vind het wel erg toevallig dat de nieuwe schijf nu een fout geeft. Daarom ben ik benieuwd of dat ik op een of andere manier kan achterhalen wát er mis gaat en of het wel echt aan de schijf ligt.

Ik hoop dat iemand hier me kan helpen, als het aan de schijf ligt en dit om stom toeval gaat koop ik gewoon een nieuwe en zet ik die erin, maar ik wil een beetje voorkomen dat ik alleen symptoombestrijding doe.

Edit;
Smartctl -a /dev/ada2 levert het volgende op

code:

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital RE4-GP
Device Model:     WDC WD2003FYPS-27Y2B0
Serial Number:    WD-WCAVY5736263
LU WWN Device Id: 5 0014ee 20512b68d
Firmware Version: 04.05G11
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Mon Oct 22 21:00:21 2018 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

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

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

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

SMART Error Log Version: 1
No Errors Logged

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

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

Bij voorbaat dank..

[ Voor 36% gewijzigd door Pixeltje op 22-10-2018 21:04 ]

[CurlyMo]

@Pixeltje Al een andere SATA poort of SATA kabel geprobeerd?

[FireDrunk]

Van de ZFS mailing list:

Saso Kiselkov via openzfs-developer <[e-mail]>
22 okt. 2018 20:19 (13 uur geleden)

aan developer

Thanks Jerry, great stuff! I'll jump on it in the coming days.

Cheers,
--
Saso

On 10/22/18 7:30 PM, Jerry Jelinek wrote:
> I have merged all of the patches from last years openzfs pull request
> and ported that code to the latest version of zfs. There were two
> significant bugs I found after I merged in the patches.
>
> The first bug was an intermittent infinite loop
> in metaslab_group_alloc_normal when a txg was being synced out. I
> tracked this down to the incorrect sorting in metaslab_exec_trim. The
> fix was to ensure that the weight includes the type, as is already done
> when we re-sort after a txg sync.
>
> The second bug was a blown assert in metaslab_group_alloc_normal on a
> DEBUG build. I removed the invalid assertion in
> metaslab_group_alloc_normal at end of the for loop (line 3350 in the
> original review):
> ASSERT(!metaslab_should_allocate(msp, asize));
> The assertion is obviously invalid because the check at line 3273 can
> return false and we then goto next, which will trip the assertion. It
> appears that a manual trim could cause this scenario from time to time.
>
> I have also made various simple changes based on the code review
> feedback I already received on the first round of review I posted. There
> is an updated code review at:
>
> ttps://cr.joyent.us/#/c/4929/ <https://cr.joyent.us/#/c/4929/>
>
> For people unfamiliar with gerrit, you can see what was changed from the
> first round by using the "Diff against:" button to select the latest rev.
>
> Feel free to post new code review comments there or email them to me
> directly.
>
> Thanks,
> Jerry

Het lijkt er op dat we binnenkort TRIM support in Open-ZFS gaan krijgen!

[Pixeltje]

CurlyMo schreef op maandag 22 oktober 2018 @ 21:31:
@Pixeltje Al een andere SATA poort of SATA kabel geprobeerd?

Andere poort niet, omdat ik niet zeker wist of FreeNas dat leuk zou vinden, andere kabel wel. Gister nog even zitten rommelen en het lijkt erop alsof de daily report (elke nacht) net iets eerder was dan dat de resilver klaar was, want na een zpool clear was de foutmelding weg, en na een reboot kwam die ook niet terug. Het lijkt er dus op alsof de schijf toch gewoon werkt, iets wat door de SMART data bevestigd lijkt te worden.

Ik hou deze nu even goed in de gaten maar begin te vermoeden dat een verse installatie van FreeNAS geen kwaad kan omdat ik regelmatig ook hele lange (en voor mij onduidelijke) reports krijg uit de daily status update, zie onder;

code:

SMP: AP CPU #1 Launched!
> Timecounter "TSC-low" frequency 1147419998 Hz quality 1000
> Trying to mount root from zfs:freenas-boot/ROOT/9.10.2-U6 []...
> GEOM_RAID5: Module loaded, version 1.3.20140711.62 (rev f91e28e40bf7)
> hwpmc: SOFT/16/64/0x67<INT,USR,SYS,REA,WRI> TSC/1/64/0x20<REA> IAP/8/48/0x3ff<INT,USR,SYS,EDG,THR,REA,WRI,INV,QUA,PRC> IAF/3/48/0x67<INT,USR,SYS,REA,WRI> UCP/8/48/0x3f8<EDG,THR,REA,WRI,INV,QUA,PRC> UCF/1/48/0x60<REA,WRI>
> em0: link state changed to UP
> GEOM_ELI: Device ada0p1.eli created.
> GEOM_ELI: Encryption: AES-XTS 128
> GEOM_ELI:     Crypto: software
> GEOM_ELI: Device ada1p1.eli created.
> GEOM_ELI: Encryption: AES-XTS 128
> GEOM_ELI:     Crypto: software
> GEOM_ELI: Device ada2p1.eli created.
> GEOM_ELI: Encryption: AES-XTS 128
> GEOM_ELI:     Crypto: software
> GEOM_ELI: Device ada3p1.eli created.
> GEOM_ELI: Encryption: AES-XTS 128
> GEOM_ELI:     Crypto: software

Dit is een fragment uit de mail die ik krijg als de nas ge(re)boot is. De timecounter melding helemaal bovenin krijg ik ook wel eens (random?) als losse melding..

[ Voor 4% gewijzigd door Pixeltje op 23-10-2018 10:03 ]

[mdbraber]

Ik heb recent mijn server geïnstalleerd en wilde daarvoor een ZFS root (zodat ik makkelijk snapshots kan maken) en encrypted (vmml. omdat ik dat thuis in kan stellen en weet wat ik bij mijn andere server in het datacenter nodig heb). Mijn moederbord / configuratie ondersteunt alleen UEFI boot met NVMe (dus geen Legacy Mode / SATA / AHCI). Op de server draait Proxmox, maar ik ben uitgegaan van eerste een Debian installatie en daarna Proxmox.

Voor de mensen die ook een encrypted ZFS root willen met UEFI + NVMe een paar tips:

- Er is een hele goede guide van ZFSonLinux over encrypted ZFS root in Debian Stretch met instructies voor UEFI boot.

- Omdat ik een redelijk recente hardware heb werkte bij mij de Buster (opvolger van Stretch) installatie live CD het beste. Daar zit ook ZFS 0.7.11 'ingebakken'. Bedenk wel dat als je met debootstrap ook Buster installeert voor je definitieve installatie dat je dan niet (makkelijk) kan downgraden naar Stretch. Dat betekent ook dat je voor bijv. Proxmox een andere repository moet gebruiken.

- Check even goed dat je dus op een aantal plaatsen in de guide 'stable' of 'stretch' moet vervangen door 'testing' of 'buster'.

- In de Debian Stretch ZFS guide staat niets over encryption (nog). Dat staat wel in de vergelijkbare Ubuntu ZFS guide. Als je deze guides naast elkaar legt en per stap kijkt of er iets anders is voor LUKS/encryption (aangeven in de Ubuntu guide) dan is het niet al te ingewikkeld.

- Mocht er iets mis gaan en je moet de Live CD gebruiken om een al gecreëerde pool te importeren en te mounten in een chroot - daar staan instructies voor aan het einde van de guide (dat zag ik pas toen ik zelf al aan het googlen was gegaan)

- Mocht je voor encryption ook nog een remote mogelijkheid zoeken (zodat je zonder KVM je encryption password in kan voeren) dan kan je dropbear-initramfs gebruiken

[FireDrunk]

Grappig concept, dat remote unlocking, nooit zo over nagedacht.

[Tha_Butcha]

Als ik nu een mirrored set draai, kan ik als ik later twee SSD's van dezelfde grootte aan toevoeg he omtoveren tot een striped mirror set of lukt dat alleen bij het creeeren van de pool?

[unezra]

Tha_Butcha schreef op zondag 28 oktober 2018 @ 16:56:
Als ik nu een mirrored set draai, kan ik als ik later twee SSD's van dezelfde grootte aan toevoeg he omtoveren tot een striped mirror set of lukt dat alleen bij het creeeren van de pool?

https://pthree.org/2012/1...inistration-part-i-vdevs/

Je kunt een vdev niet vergroten. Als je een vdev hebt die bestaat uit 2 mirrored disks en je voegt er een 2e vdev aan toe, bestaande uit 2 mirrored disks, zal je bestaande data NIET opeens gestriped worden. Voor zover ik weet alleen nieuwe data. Dat nut is dus zeer beperkt.

Basisregel bij ZFS is: Je bouwt je vdevs aan het begin en je voegt géén disks toe. Wel kun je disks zonder dataverlies vervangen door andere, grotere, exemplaren. Dus van 4x5T in een mirrored stripe (10T bruto) kun je naar 4x12T in een mirrored stripe (24T bruto).

[FireDrunk]

Dat is wel erg kort door de bocht. Technisch gezien is er weinig op tegen om het niet te doen, anders dan performance. ZFS zal er voor zorgen dat vdevs gelijk vol raken.

Voeg je dus de SSDs toe op het moment dat je pool 90% vol is, dan zul je er wel wat van merken. Doe je dat bij 25% vol, is het al haast verwaarloosbaar.

Het antwoord is dus simpel: it depends...

[Tha_Butcha]

Ah, dan hou ik het voorlopig wel bij een 3 disk zraid. Gaat om vm storage voor proxmox, met voornamelijk wat kleine *nix vms en wat docker containers.

En als ik echt iops tekort kom bouw ik jet wel om naar een striped mirror.

[FireDrunk]

Of gewoon 2e losse mirror.

[NmS]

Ik heb een vraag m.b.t. het testen van schrijf- en leessnelheden. Wat is de beste manier om dat te testen?

Wanneer ik het test met dd, dan krijg ik voor mijn gevoel te hoge waarden.

Schrijven:

code:

mathijs@mnemosyne:/mnt/tank/temp % dd if=/dev/zero of=/mnt/tank/temp/zefofile.000 bs=1M count=6400
6400+0 records in
6400+0 records out
6710886400 bytes transferred in 2.964964 secs (2263395951 bytes/sec)

Lezen

code:

mathijs@mnemosyne:/mnt/tank/temp % dd if=/dev/zero of=/dev/null bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 0.209449 secs (50063462358 bytes/sec)

Als ik dat goed omreken is dat voor schrijven 2158,5 MB/s en lezen 12.683,3 MB/s

Ik draai overigens FreeNAS 11.2 RC1 via XenServer 7.1 met 8GB RAM.

[GioStyle]

Wat is je setup?

Probeer eens een bestand van 100GB.

[dcm360]

Voor het schrijven zou je kunnen kijken of het toevoegen van 'oflag=sync' wat meer realistische waarden oplevert. Voor het lezen (waarvan er nu waarschijnlijk de verkeerde code staat, namelijk van /dev/zero naar /dev/null) moet je zien te voorkomen dat de in te lezen data nog in het geheugen staat. Daarvoor is het handig als het bestand ruim niet in het geheugen past.

[NmS]

Onderstaande met bestand van 100GB ('oflag=sync' werkt niet -> unknown operand):

code:

mathijs@mnemosyne:/mnt/tank/temp % dd if=/dev/zero of=/mnt/tank/temp/zefofile.000 bs=1M count=100000
100000+0 records in
100000+0 records out
104857600000 bytes transferred in 49.433590 secs (2121181163 bytes/sec)

mathijs@mnemosyne:/mnt/tank/temp % dd if=/mnt/tank/temp/zefofile.000 of=/dev/null bs=1M
100000+0 records in
100000+0 records out
104857600000 bytes transferred in 8.162322 secs (12846540759 bytes/sec)

Dan kom ik uit op schrijven van 2023 MB/s en lezen 12.251 MB/s.

Mijn setup
Intel Xeon E3-1230 v5
32 GB ECC RAM
6x Toshiba DT01ACA300, 3TB
64 GB Crucial M4 SSD

FreeNAS 11.2 RC1 draait virtueel met 8GB RAM via XenServer 7.1 en een IBM ServeRAID M1015 in passthrough.

zpool status

code:

 pool: tank
 state: ONLINE
  scan: scrub repaired 0 in 0 days 22:29:13 with 0 errors on Tue Oct  9 01:57:54 2018
config:

        NAME             STATE     READ WRITE CKSUM
        tank             ONLINE       0     0     0
          raidz2-0       ONLINE       0     0     0
            gpt/disk0    ONLINE       0     0     0
            gpt/disk1    ONLINE       0     0     0
            gpt/disk2    ONLINE       0     0     0
            gpt/disk3    ONLINE       0     0     0
            gpt/disk4    ONLINE       0     0     0
            gpt/disk5    ONLINE       0     0     0
        cache
          gpt/ssd_cache  ONLINE       0     0     0

errors: No known data errors

Pool: HEALTHY (13.62 TiB (83%) Used / 2.63 TiB Free)

[ Voor 4% gewijzigd door NmS op 31-10-2018 22:47 ]

[CurlyMo]

NmS schreef op woensdag 31 oktober 2018 @ 22:41:
Onderstaande met bestand van 100GB ('oflag=sync' werkt niet -> unknown operand):

Gebruik /dev/urandom of /dev/random zodat er niet gecomprimeerd kan worden.

[GioStyle]

Je waardes die je aangeeft zijn niet realistisch. Met 6 schijven in raidz2 zou je in de orde van 500/400MB/s lezen/schrijven moeten halen, mits de pool leeg is.

Ik haal met mijn 10 disks raidz2 800MB/s lezen geloof ik. Is ook niet echt boeiend, want mijn netwerk is de bottleneck (gbit lan).

[FireDrunk]

CurlyMo schreef op woensdag 31 oktober 2018 @ 22:52:
[...]

Gebruik /dev/urandom of /dev/random zodat er niet gecomprimeerd kan worden.

Die zijn beide vaak CPU bottlenecked. Tools als iozone kunnen dat prima met pseudo-random data testen.

[Simkin]

Kan iemand mij uitleggen of en waarom de 'ZFS Event Daemon' actief zou moeten blijven? Ik heb deze nu uitgezet omdat deze problemen veroorzaakt tijdens resilvering (geforceerde herstarts). Ik heb geen behoefte aan alerts/email notificaties als de pool degraded raakt.

[CurlyMo]

Simkin schreef op vrijdag 2 november 2018 @ 08:56:
Ik heb geen behoefte aan alerts/email notificaties als de pool degraded raakt.

Totdat je je in paniek in dit topic komt melden, omdat je data kwijt bent. Geen mail is iets anders dan geen irritante mails.

[FireDrunk]

Je kan de ZED gewoon zo configureren dat je daar geen mail van krijgt. Hoewel een melding van een degraded pool mij erg nuttig lijkt... Ik zou er ernstig van schrikken als dat zou gebeuren

[Simkin]

Maar, lost van alerts kan ik hem veilig uit laten?

[FireDrunk]

Simkin schreef op vrijdag 2 november 2018 @ 10:35:
Maar, lost van alerts kan ik hem veilig uit laten?

Ja hoor.

[Simkin]

Bedankt!

[mdbraber]

Ik run naar tevredenheid een een ZFS root (on LUKS) voor Proxmox en daarnaast een pool voor media met 4x 5TB disks (ook op LUKS disks). Dit draait allemaal op de Debian / Proxmox host. Ik ben aan het nadenken of het uit zou maken of ik FreeNAS zou gebruiken voor de media pool. Voor zover ik kan overzien betekent dat iets betere monitoring - de GUI maakt me niet heel veel uit. Een voordeel van de huidige setup is dat ik tzt de nieuwe zfs 0.8 features (vnml. encryption) zou kunnen gebruiken.

Zijn er meer / andere overwegingen om FreeNAS te gebruiken in plaats van direct op de Proxmox host?

[A1AD]

Simkin schreef op vrijdag 2 november 2018 @ 10:35:
Maar, lost van alerts kan ik hem veilig uit laten?

Dat is wat ik ook doe. Monitor doe ik via nagios.

[FireDrunk]

mdbraber schreef op vrijdag 2 november 2018 @ 14:13:
Ik run naar tevredenheid een een ZFS root (on LUKS) voor Proxmox en daarnaast een pool voor media met 4x 5TB disks (ook op LUKS disks). Dit draait allemaal op de Debian / Proxmox host. Ik ben aan het nadenken of het uit zou maken of ik FreeNAS zou gebruiken voor de media pool. Voor zover ik kan overzien betekent dat iets betere monitoring - de GUI maakt me niet heel veel uit. Een voordeel van de huidige setup is dat ik tzt de nieuwe zfs 0.8 features (vnml. encryption) zou kunnen gebruiken.

Zijn er meer / andere overwegingen om FreeNAS te gebruiken in plaats van direct op de Proxmox host?

BSD gaat iets anders om met ZFS, specifieke features vinden hun weg soms eerder naar BSD. Verder heeft BSD bhyve, maar of je daar nou zo blij van moet worden

[WeaZuL]

Nadeel van de ST5000LM000 is dat het resilveren zo lang duurt :

code:

 scan: resilver in progress since Sun Nov  4 18:16:50 2018
    335G scanned out of 5.01T at 134M/s, 10h10m to go
    115G resilvered, 6.54% done

[nero355]

NmS schreef op woensdag 31 oktober 2018 @ 22:41:
Onderstaande met bestand van 100GB ('oflag=sync' werkt niet -> unknown operand):

code:

mathijs@mnemosyne:/mnt/tank/temp % dd if=/dev/zero of=/mnt/tank/temp/zefofile.000 bs=1M count=100000
100000+0 records in
100000+0 records out
104857600000 bytes transferred in 49.433590 secs (2121181163 bytes/sec)

mathijs@mnemosyne:/mnt/tank/temp % dd if=/mnt/tank/temp/zefofile.000 of=/dev/null bs=1M
100000+0 records in
100000+0 records out
104857600000 bytes transferred in 8.162322 secs (12846540759 bytes/sec)

Dan kom ik uit op schrijven van 2023 MB/s en lezen 12.251 MB/s.

Doe eens het volgende :

code:

dd if=/dev/zero of=/mnt/tank/temp/zerofile.000 bs=1M count=100000 conv=fdatasync

En inderdaad altijd een file laten aanmaken die groter is dan de hoeveelheid aanwezige RAM.
Het liefst twee keer zo groot!

Check ook de man page van DD voor dit soort dingetjes => https://linux.die.net/man/1/dd

[FireDrunk]

Kwam toevallig deze tegen op de ZFS mailing list:

https://zgrep.org/zfs.html

Erg handig voor mensen die een nieuwe pool maken!

_{Startpost is ondertussen ook een klein beetje geupdatet}

[ Voor 20% gewijzigd door FireDrunk op 29-11-2018 08:50 ]

[Keiichi]

Tijdens een rebuild van een raidz1 is een tweede schijf gaan bokken. De resilver was op z'n minst klaar voor 80% De bokkende schijf geeft errors zoals "ATA status: 41 (DRDY ERR), error: 40 (UNC )".

Ik weet niet hoever de resilver precies was (systeem heeft een spontane reboot gehad), zpool en zfs commando's blijven hangen omdat deze schijf aan het bokken is.

is er een mogelijkheid dat FreeBSD de errors negeert en zo snel mogelijk verder gaat? Of is het beste om deze schijf uit het systeem te halen en te kijken hoeveel corrupt geraakt is?

[FireDrunk]

1) Nee, niet direct. Sommige schijven kunnen dat wel, dat heet TLER, ff googlen of jouw schijf dat kan.
2) Als je de schijf er uit haalt komt je pool waarschijnlijk niet online. Maar je kan het proberen.

[Keiichi]

M'n zpool heeft nu enkele permanent errors, met zpool status -v te bekijken. Hier staan naast duidelijke bestandsnamen ook waardes als:

code:

       <0x1041>:<0x1>
        <0x2083>:<0x5699d77>
        <0x2083>:<0x5699d7d>
        <0x2083>:<0x569a0bb>

Wat zijn dit voor fouten?

Is het trouwens verstandig om een zpool met errors met zfs send/recv naar een gezonde zpool te copieren?

[CurlyMo]

Keiichi schreef op donderdag 6 december 2018 @ 15:09:
Wat zijn dit voor fouten?

Metadata fouten. Juist degene die je niet wil hebben.

Is het trouwens verstandig om een zpool met errors met zfs send/recv naar een gezonde zpool te copieren?

De laatste snapshot waarschijnlijk niet, maar een eerdere kan die fouten misschien nog niet hebben.

[Keiichi]

Tijdens resilveren zijn fouten naar boven gekomen, bij de files die gevonden zijn als corrupted staan er een aantal juist eerdere snapshots.

Als fouten op zvol's gevonden zouden zijn, zou dit dan ook duidelijk in dit overzichtje naar voren komen?

[jadjong]

Ik heb een systeempje wat na tig jaren (begin van dit topic) er geen zin meer in heeft.
De pool bestaat uit zes data-schijven en twee keer een SSD voor log/cache. Dit zit in een Z2 volume en zorgt voor gedeelde data via NFS of 'locale' data via iSCSI.
Sinds vorige week ziet de pool er zo uit:

code:

        NAME                           STATE     READ WRITE CKSUM
        e6                             DEGRADED     0     0  216K
          raidz2-0                     DEGRADED     0     0  431K
            c6t4d0                     DEGRADED     0     0     0  too many erro                                                                                                                                                              rs
            c6t3d0                     DEGRADED     0     0     0  too many erro                                                                                                                                                              rs
            c6t0d0                     ONLINE       0     0     0
            c6t5d0                     DEGRADED     0     0     0  too many erro                                                                                                                                                              rs
            c0t5000C50064D63EBAd0      ONLINE       0     0     0
            c0t5000C50064D75FECd0p0    ONLINE       0     0     0
        logs
          c6t2d0p2                     ONLINE       0     0     0
          c6t1d0p2                     ONLINE       0     0     0
       Cache
          C6t1d0p4                    ONLINE       0      0     0

Een kapotte schijf kan ik mee leven, een tweede ook nog, maar drie tegelijk is vreemd. Om alle externe fouten uit te sluiten heb ik de hele pool verplaatst naar een ander systeem. Op de een of andere manier is tijdens die verplaatsing een SSD verwisselt met een data-schijf, geen idee hoe dat kan maar mij is het gelukt. De SSD met een dubbelleven heb ik als cache en log netjes kunnen verwijderen, maar zijn deeltijd-baan met de zesde data-schijf krijg ik er niet uit. Hoe vaak ik ook "zpool remove/detach/offline e6 c6t1d0" in tik, hij blijft zeuren over 'no valid replicas'.
Dit is de tussenstand:

code:

        NAME                           STATE     READ WRITE CKSUM
        e6                             DEGRADED     0     0     0
          raidz2-0                     DEGRADED     0     0     0
            c6t4d0                     ONLINE       0     0     0
            c6t3d0                     ONLINE       0     0     0
            c6t0d0                     ONLINE       0     0     0
            c6t5d0                     ONLINE       0     0     0
            c0t5000C50064D63EBAd0      ONLINE       0     0     0
            replacing-5                DEGRADED     0     0     0
              c6t1d0                   UNAVAIL      0     0     0  cannot open
              c0t5000C50064D75FECd0p0  ONLINE       0     0     0
        logs
          c6t2d0p2                     ONLINE       0     0     0

Als ik een resilver of een scrub doe stopt deze netjes op 100% met 1 error in een iSCSI volume. Geen enkele schijf begint dan te zeuren over 'too many errors'. Ook de snelheid van een scrub is meer dan voldoende Pas als ik het iSCSI volume wil benaderen stapelen de errors zich op en gaat de pool uiteindelijk offline wegens te veel errors.

Iemand een idee hoe ik dit recht kan breien?

[FireDrunk]

Welk OS draai je? c6t5d0 doet mij geloven dat je een Solaris variant draait?

[jadjong]

FireDrunk schreef op zondag 16 december 2018 @ 09:47:
Welk OS draai je? c6t5d0 doet mij geloven dat je een Solaris variant draait?

Jep, OI151 in het oude systeem en de laatste versie in het nieuwe systeem.

[FireDrunk]

Tja, de locatie van devices is daar minder gefixeerd dan op andere platforms. Dat maakt het allemaal iets lastiger.

Wel vaag dat je die c6t1d0 niet mag weghalen. Dat zou ik wel verwachten. Misschien moet je eerst de replace stoppen?

[jadjong]

Ik verwachtte dat '3.6T resilvered, 100% done' aangeeft dat de replace gelukt is. Tenminste, dat deed het vroeger wel. Inmiddels voor de derde keer zpool clear gedaan, maar die schijf blijft in beeld hangen.

[ Voor 26% gewijzigd door jadjong op 16-12-2018 13:29 ]

[kdbruin]

Met de Black Friday sales een nieuwe SSD van 500GB op de kop getikt ter vervanging van de huidige 120GB SSD. Hoe kan ik deze vervanging het beste aanpakken? Het gaat hierbij om een ZFS on Root disk met de volgende indeling:

# gpart show ada2
=>       40  250069600  ada2  GPT  (119G)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048   16777216     2  freebsd-swap  (8.0G)
   16779264  233289728     3  freebsd-zfs  (111G)
  250068992        648        - free -  (324K)

Het idee is om de swap te vergroten naar 32GB en dan de rest voor de ZFS root te gebruiken.

Bij zoeken kom ik vooral tegen hoe ik binnen een ZFS volume een disk kan vervangen maar niet zozeer hoe ik het vervangen van de complete bootdisk kan doen. Enige pointers naar een handleiding die ik kan gebruiken?

O ja, de ZFS indeling is als volgt:

# zfs list -r zroot
NAME                      USED  AVAIL  REFER  MOUNTPOINT
zroot                    69.8G  37.7G    96K  /zroot
zroot/ROOT               39.8G  37.7G    96K  none
zroot/ROOT/11.2-RELEASE  39.8G  37.7G  39.8G  /
zroot/p                  1.90G  37.7G    88K  /zroot/p
zroot/p/jails             971M  37.7G    88K  /zroot/p/jails
zroot/p/jails/11amd64     971M  37.7G   970M  /poudriere/jails/11amd64
zroot/p/ports             975M  37.7G    88K  /zroot/p/ports
zroot/p/ports/default     975M  37.7G   975M  /poudriere/ports/default
zroot/storage            3.20G  37.7G   112K  /storage
zroot/storage/downloads  3.20G  37.7G  3.20G  /storage/downloads
zroot/tmp                26.3M  37.7G  26.3M  /tmp
zroot/usr                23.2G  37.7G    96K  /usr
zroot/usr/home           23.2G  37.7G  23.2G  /usr/home
zroot/usr/src              96K  37.7G    96K  /usr/src
zroot/var                1.64G  37.7G    96K  /var
zroot/var/audit            96K  37.7G    96K  /var/audit
zroot/var/crash          1.64G  37.7G  1.64G  /var/crash
zroot/var/log            3.00M  37.7G  3.00M  /var/log
zroot/var/mail            120K  37.7G   120K  /var/mail
zroot/var/tmp             144K  37.7G   144K  /var/tmp

[CurlyMo]

kdbruin schreef op zondag 16 december 2018 @ 14:10:
Enige pointers naar een handleiding die ik kan gebruiken?

Stappen zijn grofweg:
1. Op nieuwe SSD partitie indeling maken zoals je huidige maar dan met de juiste grootte.
2. ZFS pool maken op nieuwe partitie. Als huidige zroot heet dan kan je de nieuwe bijv. rpool noemen.
3. Volledige zfs send/recv doen van oude naar nieuwe pool.
4.1. Ofwel in de zfs parameters de boot locatie aanpassen.
4.2. Ofwel in de fstab de boot locatie aanpassen.
5. In de bootloader aangeven wat de nieuwe root pool is.

En booten maar.

[kdbruin]

CurlyMo schreef op zondag 16 december 2018 @ 15:40:
[...]

Stappen zijn grofweg:
1. Op nieuwe SSD partitie indeling maken zoals je huidige maar dan met de juiste grootte.
2. ZFS pool maken op nieuwe partitie. Als huidige zroot heet dan kan je de nieuwe bijv. rpool noemen.
3. Volledige zfs send/recv doen van oude naar nieuwe pool.
4.1. Ofwel in de zfs parameters de boot locatie aanpassen.
4.2. Ofwel in de fstab de boot locatie aanpassen.
5. In de bootloader aangeven wat de nieuwe root pool is.

En booten maar.

Top! Gaan we volgend weekend maar eens proberen.