:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
Dank je wel! Moest 'ie na deze scrub terug een het repairen slaan op deze schijf, dan is er dus iets structureels aan de hand en moet ik verder onderzoeken of er iets mis is met de schijf zelf. Hoe pak ik dat dan juist aan?Dat is niet erg. Daarom doe je na deze scrub weer hetzelfde nog een keer om te checken of het inderdaad niet tijdelijk is.
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
:strip_icc():strip_exif()/u/11631/tentacle.jpg?f=community)
/u/170728/owl.png?f=community)
De meest prangende vraag. Gewenste prestaties. Ik heb hier een dedup pool nét niet werkend gekregen op een SBC met 1GB geheugen
Probleem was dat hij de dedup tables niet in kon laden. Oftewel, alle adviezen gaan uit van enterprise gewenste prestaties. Als je die niet hebt, dan gaat het vrijwel zeker ook prima werken met meer courante geheugen hoeveelheden.
Sinds de 2 dagen regel reageer ik hier niet meer
:strip_icc():strip_exif()/u/75828/sid.jpg?f=community)
Kwam dit nog tegen::
@HyperBart
Jij hebt dus 6 schijven in 1 grote USB enclosure zitten, begrijp ik? Kan je daar iets meer over vertellen?
https://www.amazon.co.uk/...ure-SATA3-0/dp/B07449Q74W
:strip_exif()/u/340453/crop67a669ce4f1f4_cropped.webp?f=community)
De dataset zal na de initiele transfer grotendeels in rust zijn. Er zal met intervallen (zeg wekelijks) naar schatting 100-250GB aan nieuwe data aangeboden worden aan de server (rsync). De gigabit ethernet verbinding is in elk geval een eerste limiet. Transfer moet klaar zijn binnen een paar uur, maar dat zou binnen die constraints prima mogelijk moeten zijn.:
[...]
De meest prangende vraag. Gewenste prestaties. Ik heb hier een dedup pool nét niet werkend gekregen op een SBC met 1GB geheugen
De reden om voor zfs te gaan zit eigenlijk met name in de dedup mogelijkheden op filesystem niveau. Dat het ook gelijk RAID biedt is mooi meegenomen, maar daar zijn ook goede alternatieven voor. Een ruwe estimate voor besparing schijfruimte door dedup op deze dataset is ongeveer 30-50%.
1GB RAM klinkt wel heel weinig overigens voor dedup? Hoe groot is de totale zfs pool daarbij?
[ Voor 17% gewijzigd door d3vlin op 20-12-2020 12:12 ]
Leaping Lab Rats!
Je zou te weten moeten komen welke controller er in zit. Diegene die ik postte geeft hard aan dat hij niks van RAID doet. Ik kan me prima voorstellen dat het gros van de mensen net WEL RAID wil “want ik heb nu een grote schijf, deze doos is mijn grote schijf” (zonder dan de consequenties er van in te zien).
Bestel eens en post eens wat output van lsusb enzo?
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
128GB SWAP als je al 128GB RAM hebt? Wat ga je in vredesnaam doen met die machine 
Wil je alle 80TB aan storage in Dedup zetten? Dat lijkt me *erg* onverstandig.
Dedup is leuk voor plekken waar het veel helpt, maar voor films, foto's, video etc maakt het geen kont uit, en vreet het alleen maar geheugen.
Als je al 128GB RAM hebt is een L2ARC voor een thuis server overkill, gaat zo weinig opleveren. Tenzij je iets van plan bent waardoor ZFS niets van die 128GB kan gebruiken.
Verschillen tussen ZFS 0.8.x en 2.0 zijn vrij beperkt hoor, wat extra features, niet veel meer.
Wil je alle 80TB aan storage in Dedup zetten? Dat lijkt me *erg* onverstandig.
Dedup is leuk voor plekken waar het veel helpt, maar voor films, foto's, video etc maakt het geen kont uit, en vreet het alleen maar geheugen.
Als je al 128GB RAM hebt is een L2ARC voor een thuis server overkill, gaat zo weinig opleveren. Tenzij je iets van plan bent waardoor ZFS niets van die 128GB kan gebruiken.
Verschillen tussen ZFS 0.8.x en 2.0 zijn vrij beperkt hoor, wat extra features, niet veel meer.
Even niets...
Wat veranderen films en fotos aan het nut van dedup? Als hij twee keer dezelfde set opslaat is het toch nuttig?:
128GB SWAP als je al 128GB RAM hebt? Wat ga je in vredesnaam doen met die machine
Wil je alle 80TB aan storage in Dedup zetten? Dat lijkt me *erg* onverstandig.
Dedup is leuk voor plekken waar het veel helpt, maar voor films, foto's, video etc maakt het geen kont uit, en vreet het alleen maar geheugen.
Daarnaast lijkt hij toch alle nodige hardware te bezitten? Heel beefy CPU’s en een sloot geheugen (waar hij geen probleem mee heeft om uit te breiden).
Ik denk ook dat het ik een kantoor omgeving is.
Als je iedere dag bijna dezelfde 100 a 150G wegschrijft dan lijkt zijn hardware en usecase toch prima om dedup te enablen? Of waar denk jij aan?
Server is inderdaad niet voor thuisgebruik, het gaat om het archiveren van 3D producties die veelal dezelfde assets delen. Ik weet dat dedup op deze dataset circa 30-50% bespaart op basis van eerdere tests met borgbackup. Met RAIDZ2 blijft er effectief 55TB over voor storage met dedup. Die grootte is natuurlijk zo bedacht met het oog op de toekomst. In eerste instantie zal daarvan maar een deel gevuld worden. Het idee is dat we er vervolgens een aantal jaar mee vooruit kunnen.:
128GB SWAP als je al 128GB RAM hebt? Wat ga je in vredesnaam doen met die machine
Wil je alle 80TB aan storage in Dedup zetten? Dat lijkt me *erg* onverstandig.
Dedup is leuk voor plekken waar het veel helpt, maar voor films, foto's, video etc maakt het geen kont uit, en vreet het alleen maar geheugen.
Als je al 128GB RAM hebt is een L2ARC voor een thuis server overkill, gaat zo weinig opleveren. Tenzij je iets van plan bent waardoor ZFS niets van die 128GB kan gebruiken.
Verschillen tussen ZFS 0.8.x en 2.0 zijn vrij beperkt hoor, wat extra features, niet veel meer.
128GB SWAP juist omdat ik niet weet hoeveel RAM dedup gaat vergen. Lijkt me beter dat de swap space er is dan dat het geheugen vol loopt. En voor het OS is de ruimte ook niet nodig dus what gives.
Mocht het blijken dat er echt veel RAM nodig is voor dedup dan kan dat uitgebreid worden en kan de swap size weer naar beneden. Lang leve LVM. 
[ Voor 60% gewijzigd door d3vlin op 20-12-2020 19:49 ]
Leaping Lab Rats!
@d3vlin
Als het om een backup pool gaat (die had ik even gemist) is L2ARC zoals @Thralas al zegt. L2ARC doet niets bij writes. En L2ARC moet ook gevuld worden, dus als jij 'af en toe' wat opvraagt, is de eerste 100 jaar je L2ARC nog niet gevuld. Bovendien helpt een L2ARC alleen maar als je vaak dezelfde data opvraagt. Van een Backup vraag je naar mijn idee juist unieke data op, omdat je die data weer terug zet op het originele systeem.
Je hebt dus 99.9% sequential writes, en 0.1% semi-random reads die je 1 keer doet.
Met dat patroon in het hoofd is dedup op zich niet zo'n gek idee. Het ligt vooral aan je verwachtingen.
Zie een van de issues die ik tegengekomen ben met dedup:
https://github.com/openzfs/zfs/issues/6823
Dit soort vage dingen gaan er (kunnen) gebeuren. Nou is dit issue relatief oud, en zal de dedup logica best wat verbeterd zijn, maar ook weer niet schrikbarend.
Even wat berekeningen:
Je gaat uit van een pool van 80TB. Laten we zeggen dat deze voor 70% gevuld is -> 56TB.
Dan hebben we het over 56.000.000.000 KB.
Als jouw filesystem vooral media /3D Assets bevat (waarvan ik aanneem dat ze niet heel klein zijn), zal je een mooie relatief hoge recordsize in kunnen stellen. Iets als 128K of zelfs nog groter is erg nuttig in dit geval.
Als je gemiddelde recordsize 128K wordt (wat best optimistisch is). Zit je dus voor 56.000.000.000 KB op 437.500.000 DDT entries.
Die zijn per stuk 320 bytes, dat maakt 140GB aan alleen de DDT table. Dat is gigantisch.
Bedenk je dat het een database is waar elke read iets in opgezocht moet worden. Uiteraard zijn er truukjes om dat snel te doorzoeken(onderwater is het dacht ik een red/black tree), maar bij 140GB hebben ook die hun limieten.
Als je DDT tabel op disk (swap) komt, stort je performance in tot de snelheid van een floppy drive. Je systeem moet dan zoveel wachten op IO, voordat het die acties kan doen, dat je hele systeem waarschijnlijk zal vastlopen.
Even uitrekenen: Als jij ~85 euro per uur kost, en hier al een uurtje of 5 mee bezig bent geweest om het een en ander uit te zoeken, en bij het inrichten nog eens een uur of 10 gaat spenderen (inclusief testen). En achteraf nog eens een uur of 8 gaat debuggen en troubleshooten als het mis gaat, kost dat 5+10+8*85=1955 euro
Kan je beter gewoon 5 extra schijven kopen: pricewatch: Seagate Exos X16 SATA (Standard model), 16TB (~2000 euro)
Ben je haast goedkoper uit, en scheelt je een hoop ellende...
PS: Ik heb in verhouding best dure schijven genomen, omdat je al dat kaliber schijven hebt, maar met iets goedkopere schijven, kan je ook prima toe, en dan zou je al iets sneller goedkoper uit zijn
Dit is ook wel een mooie guide: https://constantin.glez.d...-to-dedupe-or-not-dedupe/
Die gaat uit van 20GB ram per TB als dedup aan staat.
Als het om een backup pool gaat (die had ik even gemist) is L2ARC zoals @Thralas al zegt. L2ARC doet niets bij writes. En L2ARC moet ook gevuld worden, dus als jij 'af en toe' wat opvraagt, is de eerste 100 jaar je L2ARC nog niet gevuld. Bovendien helpt een L2ARC alleen maar als je vaak dezelfde data opvraagt. Van een Backup vraag je naar mijn idee juist unieke data op, omdat je die data weer terug zet op het originele systeem.
Je hebt dus 99.9% sequential writes, en 0.1% semi-random reads die je 1 keer doet.
Met dat patroon in het hoofd is dedup op zich niet zo'n gek idee. Het ligt vooral aan je verwachtingen.
Zie een van de issues die ik tegengekomen ben met dedup:
https://github.com/openzfs/zfs/issues/6823
Dit soort vage dingen gaan er (kunnen) gebeuren. Nou is dit issue relatief oud, en zal de dedup logica best wat verbeterd zijn, maar ook weer niet schrikbarend.
Even wat berekeningen:
Je gaat uit van een pool van 80TB. Laten we zeggen dat deze voor 70% gevuld is -> 56TB.
Dan hebben we het over 56.000.000.000 KB.
Als jouw filesystem vooral media /3D Assets bevat (waarvan ik aanneem dat ze niet heel klein zijn), zal je een mooie relatief hoge recordsize in kunnen stellen. Iets als 128K of zelfs nog groter is erg nuttig in dit geval.
Als je gemiddelde recordsize 128K wordt (wat best optimistisch is). Zit je dus voor 56.000.000.000 KB op 437.500.000 DDT entries.
Die zijn per stuk 320 bytes, dat maakt 140GB aan alleen de DDT table. Dat is gigantisch.
Bedenk je dat het een database is waar elke read iets in opgezocht moet worden. Uiteraard zijn er truukjes om dat snel te doorzoeken(onderwater is het dacht ik een red/black tree), maar bij 140GB hebben ook die hun limieten.
Als je DDT tabel op disk (swap) komt, stort je performance in tot de snelheid van een floppy drive. Je systeem moet dan zoveel wachten op IO, voordat het die acties kan doen, dat je hele systeem waarschijnlijk zal vastlopen.
Even uitrekenen: Als jij ~85 euro per uur kost, en hier al een uurtje of 5 mee bezig bent geweest om het een en ander uit te zoeken, en bij het inrichten nog eens een uur of 10 gaat spenderen (inclusief testen). En achteraf nog eens een uur of 8 gaat debuggen en troubleshooten als het mis gaat, kost dat 5+10+8*85=1955 euro
Kan je beter gewoon 5 extra schijven kopen: pricewatch: Seagate Exos X16 SATA (Standard model), 16TB (~2000 euro)
Ben je haast goedkoper uit, en scheelt je een hoop ellende...
PS: Ik heb in verhouding best dure schijven genomen, omdat je al dat kaliber schijven hebt, maar met iets goedkopere schijven, kan je ook prima toe, en dan zou je al iets sneller goedkoper uit zijn
Dit is ook wel een mooie guide: https://constantin.glez.d...-to-dedupe-or-not-dedupe/
Die gaat uit van 20GB ram per TB als dedup aan staat.
[ Voor 5% gewijzigd door FireDrunk op 21-12-2020 08:10 ]
Even niets...
L2ARC doet niets bij writes maar wordt in het geval van DDT’s wel gebruikt als RAM door die 1/4 regel niet voldoende is. Dus in dit geval is dat wel van toepassing, toch?:
@d3vlin
Als het om een backup pool gaat (die had ik even gemist) is L2ARC zoals @Thralas al zegt. L2ARC doet niets bij writes. En L2ARC moet ook gevuld worden, dus als jij 'af en toe' wat opvraagt, is de eerste 100 jaar je L2ARC nog niet gevuld. Bovendien helpt een L2ARC alleen maar als je vaak dezelfde data opvraagt. Van een Backup vraag je naar mijn idee juist unieke data op, omdat je die data weer terug zet op het originele systeem.
Je hebt dus 99.9% sequential writes, en 0.1% semi-random reads die je 1 keer doet.
Met dat patroon in het hoofd is dedup op zich niet zo'n gek idee. Het ligt vooral aan je verwachtingen.
Zie een van de issues die ik tegengekomen ben met dedup:
https://github.com/openzfs/zfs/issues/6823
Dit soort vage dingen gaan er (kunnen) gebeuren. Nou is dit issue relatief oud, en zal de dedup logica best wat verbeterd zijn, maar ook weer niet schrikbarend.
Even wat berekeningen:
Je gaat uit van een pool van 80TB. Laten we zeggen dat deze voor 70% gevuld is -> 56TB.
Dan hebben we het over 56.000.000.000 KB.
Als jouw filesystem vooral media /3D Assets bevat (waarvan ik aanneem dat ze niet heel klein zijn), zal je een mooie relatief hoge recordsize in kunnen stellen. Iets als 128K of zelfs nog groter is erg nuttig in dit geval.
Als je gemiddelde recordsize 128K wordt (wat best optimistisch is). Zit je dus voor 56.000.000.000 KB op 437.500.000 DDT entries.
Die zijn per stuk 320 bytes, dat maakt 140GB aan alleen de DDT table. Dat is gigantisch.
Bedenk je dat het een database is waar elke read iets in opgezocht moet worden. Uiteraard zijn er truukjes om dat snel te doorzoeken(onderwater is het dacht ik een red/black tree), maar bij 140GB hebben ook die hun limieten.
Als je DDT tabel op disk (swap) komt, stort je performance in tot de snelheid van een floppy drive. Je systeem moet dan zoveel wachten op IO, voordat het die acties kan doen, dat je hele systeem waarschijnlijk zal vastlopen.
Even uitrekenen: Als jij ~85 euro per uur kost, en hier al een uurtje of 5 mee bezig bent geweest om het een en ander uit te zoeken, en bij het inrichten nog eens een uur of 10 gaat spenderen (inclusief testen). En achteraf nog eens een uur of 8 gaat debuggen en troubleshooten als het mis gaat, kost dat 5+10+8*85=1955 euro
Kan je beter gewoon 5 extra schijven kopen: pricewatch: Seagate Exos X16 SATA (Standard model), 16TB (~2000 euro)
Ben je haast goedkoper uit, en scheelt je een hoop ellende...
PS: Ik heb in verhouding best dure schijven genomen, omdat je al dat kaliber schijven hebt, maar met iets goedkopere schijven, kan je ook prima toe, en dan zou je al iets sneller goedkoper uit zijn
Dit is ook wel een mooie guide: https://constantin.glez.d...-to-dedupe-or-not-dedupe/
Die gaat uit van 20GB ram per TB als dedup aan staat.
Tja, als je het zo in kosten uitdrukt is het heel snel plat te slaan maar ik denk dat bij @d3vlin er ook nog wel een “hobbyfactor” aanwezig is.
Hoedanook zijn de hardware eisen stevig maar van alle dedup-nieuwsgierigen gaat hij er nog wel het meest bedachtzaam mee om en met de juist hardware in het vooruitschiet lijkt mij.
Dank voor het uitgebreide antwoord op de vroege ochtend! Much appreciated:
@d3vlin
Als het om een backup pool gaat (die had ik even gemist) is L2ARC zoals @Thralas al zegt. L2ARC doet niets bij writes. En L2ARC moet ook gevuld worden, dus als jij 'af en toe' wat opvraagt, is de eerste 100 jaar je L2ARC nog niet gevuld. Bovendien helpt een L2ARC alleen maar als je vaak dezelfde data opvraagt. Van een Backup vraag je naar mijn idee juist unieke data op, omdat je die data weer terug zet op het originele systeem.
Je hebt dus 99.9% sequential writes, en 0.1% semi-random reads die je 1 keer doet.
Met dat patroon in het hoofd is dedup op zich niet zo'n gek idee. Het ligt vooral aan je verwachtingen.
Zie een van de issues die ik tegengekomen ben met dedup:
https://github.com/openzfs/zfs/issues/6823
Dit soort vage dingen gaan er (kunnen) gebeuren. Nou is dit issue relatief oud, en zal de dedup logica best wat verbeterd zijn, maar ook weer niet schrikbarend.
Even wat berekeningen:
Je gaat uit van een pool van 80TB. Laten we zeggen dat deze voor 70% gevuld is -> 56TB.
Dan hebben we het over 56.000.000.000 KB.
Als jouw filesystem vooral media /3D Assets bevat (waarvan ik aanneem dat ze niet heel klein zijn), zal je een mooie relatief hoge recordsize in kunnen stellen. Iets als 128K of zelfs nog groter is erg nuttig in dit geval.
Als je gemiddelde recordsize 128K wordt (wat best optimistisch is). Zit je dus voor 56.000.000.000 KB op 437.500.000 DDT entries.
Die zijn per stuk 320 bytes, dat maakt 140GB aan alleen de DDT table. Dat is gigantisch.
Bedenk je dat het een database is waar elke read iets in opgezocht moet worden. Uiteraard zijn er truukjes om dat snel te doorzoeken(onderwater is het dacht ik een red/black tree), maar bij 140GB hebben ook die hun limieten.
Als je DDT tabel op disk (swap) komt, stort je performance in tot de snelheid van een floppy drive. Je systeem moet dan zoveel wachten op IO, voordat het die acties kan doen, dat je hele systeem waarschijnlijk zal vastlopen.
Even uitrekenen: Als jij ~85 euro per uur kost, en hier al een uurtje of 5 mee bezig bent geweest om het een en ander uit te zoeken, en bij het inrichten nog eens een uur of 10 gaat spenderen (inclusief testen). En achteraf nog eens een uur of 8 gaat debuggen en troubleshooten als het mis gaat, kost dat 5+10+8*85=1955 euro
Kan je beter gewoon 5 extra schijven kopen: pricewatch: Seagate Exos X16 SATA (Standard model), 16TB (~2000 euro)
Ben je haast goedkoper uit, en scheelt je een hoop ellende...
PS: Ik heb in verhouding best dure schijven genomen, omdat je al dat kaliber schijven hebt, maar met iets goedkopere schijven, kan je ook prima toe, en dan zou je al iets sneller goedkoper uit zijn
Dit is ook wel een mooie guide: https://constantin.glez.d...-to-dedupe-or-not-dedupe/
Die gaat uit van 20GB ram per TB als dedup aan staat.
Als het puur om kosten en weinig gedoe gaat is een 'reguliere' hardware/software RAID5 oplossing de makkelijke en vertrouwde route. Sterker nog, de server had al een hardware RAID controller die ik speciaal verwisseld heb voor een LBA controller om met ZFS aan de slag te kunnen.De storage pool wordt effectief ~55TB (na RAIDZ2) maar orde van grootte kom je dan nog steeds op een enorme DDT uit natuurlijk. Het klinkt alsof genoeg RAM de meest bepalende factor is om dedup te laten slagen. Real life tests zullen moeten uitwijzen hoeveel dat is voor deze dataset. De server kan 768GB aan dus daar zit zeker headroom en de kosten voor eventueel extra geheugen zijn geen direct probleem.
Het chassis van de server ondersteunt 8 schijven en die zijn nu dus gevuld (8X10TB). Schijven er bij zetten betekent dus over naar een ander chassis. 60TB effectief met RAID5 biedt overigens zeker ook voldoende ruimte voor de toekomst, ik zie ZFS dedup als een mogelijkheid om binnen de huidige setup nog meer opslag mogelijk te maken die ik best wil onderzoeken. Als dat resulteert in een server die niet bruikbaar is dan is dat natuurlijk een valide reden om er vanaf te zien. Probleem hierbij is dat ik weinig/geen echte verhalen tegen kom over dedup op deze schaal. Als het een aantal seconden duurt om een bestandje te lezen, schrijven of deleten dan klinkt dat als 'niet bruikbaar'.
Leaping Lab Rats!
Mja, ik zat ook al te denken om suggesties te geven, maar het gaat hier om semiprofessioneel / zakelijk gebruik. Misschien is iets met 'support' / 'garantie' beter
Even niets...
Dan koop je hem nieuw.:
[...]
Mja, ik zat ook al te denken om suggesties te geven, maar het gaat hier om semiprofessioneel / zakelijk gebruik. Misschien is iets met 'support' / 'garantie' beter
Sinds de 2 dagen regel reageer ik hier niet meer
Tja, een single case is leuk, maar in een zakelijke omgeving waar je nog 20U overhebt in een cabinet wat ergens in een kleine serverruimte staat, boeit het weinig om een extra JBOD chassis te plaatsen.
Maar wat je zegt, wat @d3vlin wil.
Maar wat je zegt, wat @d3vlin wil.
Even niets...
Waarschijnlijk heeft je OS de disks na de volgende reboot dus een andere letter gegeven met dit als gevolg.
Dat kan kloppen, reden waarom ik het vroeg is omdat het net Black Friday geweest is en de "shuck kandidaten" vaak voorzien zijn van een USB enclosure waar een controller inzit die wel wat geks doet met partities enzo. Gewoon even afchecken dat je zoiets niet had.
Da's idd nog wel een goeie en correct. Daarom gebruik ik partities. Zoveel jaar na dato is deze blog van @FireDrunk toch nog altijd geldig (en die ga ik binnenkort weer gebruiken
)
Dat is geen probleem bij ZFS, dat gaat intern op metadata locaties op de disk zelf. ZFS probeert schijven te openen die in de zpool.cache file staan, en gaat daar de metadata van lezen.:
[...]
Waarschijnlijk heeft je OS de disks na de volgende reboot dus een andere letter gegeven met dit als gevolg.
[...]
Dat kan kloppen, reden waarom ik het vroeg is omdat het net Black Friday geweest is en de "shuck kandidaten" vaak voorzien zijn van een USB enclosure waar een controller inzit die wel wat geks doet met partities enzo. Gewoon even afchecken dat je zoiets niet had.
[...]
Da's idd nog wel een goeie en correct. Daarom gebruik ik partities. Zoveel jaar na dato is deze blog van @FireDrunk toch nog altijd geldig (en die ga ik binnenkort weer gebruiken
Het probleem waar @CurlyMo en @ocaj waarschijnlijk last van hebben is een niet accurate zpool.cache file. Sommige operating systems cachen deze in je initramfs, waardoor als die achter loopt op de realiteit, je cache file dus niet gelijk is aan wat er 'echt' op de disk staat. Dat kan je in veel operating systems wel forceren, door je initramfs opnieuw te genereren.
Als ZFS disks die in de zpool.cache file staan niet kan vinden, skipped hij deze gewoon, maar gaat niet zomaar opnieuw zoeken naar disks die missen in de pool.
Bij een import gebeurt dat dus expliciet wel. Na een export/import wordt ook de zpool.cache file netjes opnieuw weggeschreven, wat vaak dit soort problemen verhelpt.
Even niets...
Maar dan kun je dus nooit eerst een schijf bijplaatsen, een zpool replace doen en hem dan pas fysiek op de oorspronkelijke plek zetten? Dan verandert immers de device-naam altijd?
Ik meen me te herinneren dat zfs liever hele schijven heeft dan partities, daarom heb ik tot nu toe altijd de hele schijf aan mijn pool toegekend. Belangrijkste voordeel is dus dat je je schijven dan van een label kunt voorzien.
Maar maakt zfs niet zelf een aantal partities aan als je hem een hele schijf geeft? Ik zie in mijn pool met "whole-disk = 1" (volgens zdb-output) dat het pad dat hij gebruikt niet de hele schijf is, maar bijv. /dev/sdb1. Ook zie ik bij /dev/disk/by-path dat alle schijven uit mijn data-pool een -part1 en een -part9 hebben. Die heb ik zeker zelf nooit aangemaakt....
Ok, maar hoe kan ik die zpool.cache-file dan updaten? Immers, ik plaatste nu de nieuwe schijf via een usb-poort. Dan zpool replace, dat ging allemaal prima, dus op dat moment bestaat de zpool uit 2 sata-schijven en 1 usb-schijf.
Vervolgens zet ik de server uit en verplaats de usb-schijf naar sata. Maar op dat moment staat mijn server uit, en na een reboot is alles anders.
Waarom kijkt ZFS niet gewoon even wat verder als hij een schijf niet kan vinden?
Is dat typisch een ZFS-on-Linux ding? Kan me dit soort gedoe niet herinneren van mijn OpenIndiana-server, daar vond ZFS de schijven altijd, ook als ze na starten een andere devicenaam hadden?
Ik zou dan dus voordat ik de server een shutdown geef, eerst al mijn LXC/VM's die de data-schijf nodig hebben moeten stoppen en configureren dat ze niet meer auto-starten, dan de data-schijf moeten exporteren, schijven wisselen, pool opnieuw importeren en dan mijn LXC/VM's weer allemaal handmatig moeten starten en config weer op autostart zetten?
Klinkt als een hoop omslachtig gedoe..... (dan kan ik nog beter een in-place replace doen, ook al zit ik dan 24 uur zonder redundantie, ik dacht er juist goed aan te doen om de nieuwe schijf eerst bij te plaatsen zodat je tijdens de replace nog redundant bent.)
@ocaj Hele disks komt nog uit het Solaris tijdperk. Vroegah was het zo dat er in de kernel iets met locking gedaan werd met zowel de disk als met partities, en daardoor was het efficienter om hele disks te gebruiken, dat kwam de locking mechnismes ten goede. Dat is al jaren geleden gefixt (in Solaris), en niet nodig in Linux.
ZFS on Linux kan prima overweg met hele disks, maar zal zoals je zelf al noemt (tegenwoordig) zelf partities aanmaken. Dit doen ze met wat afkortingen en wat UID's. Daarna wordt de pool gemount met deze partities, maar ZFS on Linux boeit het weinig of dit via ID's of via partitie labels gebeurt.
Mijn voorkeur: Gebruik zelfgemaakte Partitie Labels, waarom? Je kan dan het serienummer van de disk in het label zetten. Voordeel is dat als een disk uitvalt, je weet welke disk je kwijt bent, en dus niet moeilijk hoeft te doen om er achter te komen welke disk het was.
Als je graag wil dat ZFS je disks netjes mount op id, kan je je huidige pool exporteren, en weer importeren door ZFS geforceerd in een bepaalde directory te laten kijken dmv:
Als je CurlyMo's advies volgt en op id wil werken:
Als je mijn guide volgt en met partitie labels wil werken:
Dit zorgt er voor dat ZFS _alleen_ in de genoemde directory kijkt, en daar zoekt naar te importeren pools.
Als je die -d optie niet meegeeft, zal ZFS in meerdere directories zoeken. Ik heb geloof ik jaren geleden een pull request ingediend, waar /by-id/ en /by-partlabel/ hoger kwamen te staan dan de root devices (/dev/sdx).
Geen idee of dat nog steeds zo is Jup:
https://github.com/openzf...ux/zutil_import_os.c#L260
ZFS on Linux kan prima overweg met hele disks, maar zal zoals je zelf al noemt (tegenwoordig) zelf partities aanmaken. Dit doen ze met wat afkortingen en wat UID's. Daarna wordt de pool gemount met deze partities, maar ZFS on Linux boeit het weinig of dit via ID's of via partitie labels gebeurt.
Mijn voorkeur: Gebruik zelfgemaakte Partitie Labels, waarom? Je kan dan het serienummer van de disk in het label zetten. Voordeel is dat als een disk uitvalt, je weet welke disk je kwijt bent, en dus niet moeilijk hoeft te doen om er achter te komen welke disk het was.
Als je graag wil dat ZFS je disks netjes mount op id, kan je je huidige pool exporteren, en weer importeren door ZFS geforceerd in een bepaalde directory te laten kijken dmv:
Als je CurlyMo's advies volgt en op id wil werken:
zpool import -d /dev/disk/by-id/
Als je mijn guide volgt en met partitie labels wil werken:
zpool import -d /dev/disk/by-partlabel/
Dit zorgt er voor dat ZFS _alleen_ in de genoemde directory kijkt, en daar zoekt naar te importeren pools.
Als je die -d optie niet meegeeft, zal ZFS in meerdere directories zoeken. Ik heb geloof ik jaren geleden een pull request ingediend, waar /by-id/ en /by-partlabel/ hoger kwamen te staan dan de root devices (/dev/sdx).
Geen idee of dat nog steeds zo is
Jup:https://github.com/openzf...ux/zutil_import_os.c#L260
C:
1
2
3
4
5
6
7
8
9
10
11
12
| static char * zpool_default_import_path[DEFAULT_IMPORT_PATH_SIZE] = { "/dev/disk/by-vdev", /* Custom rules, use first if they exist */ "/dev/mapper", /* Use multipath devices before components */ "/dev/disk/by-partlabel", /* Single unique entry set by user */ "/dev/disk/by-partuuid", /* Generated partition uuid */ "/dev/disk/by-label", /* Custom persistent labels */ "/dev/disk/by-uuid", /* Single unique entry and persistent */ "/dev/disk/by-id", /* May be multiple entries and persistent */ "/dev/disk/by-path", /* Encodes physical location and persistent */ "/dev" /* UNSAFE device names will change */ }; |
[ Voor 23% gewijzigd door FireDrunk op 21-12-2020 13:50 ]
Even niets...
ZFS on Linux doet aan autopartitioning inclusief labels. Als je pool vroeger gemaakt is met hele disks, en je vervangt een oude disk met een nieuwe zonder partities, zal ZFS er een partitie op aanmaken, en die aan je pool toevoegen.
ZFS on Linux zal volgens mij altijd partities aanmaken, als udev aangeeft dat het om een 'disk' gaat.
De 'rules' daarvoor zijn wat complex.
Bijbehorende code:
https://github.com/openzf...d/zpool/zpool_vdev.c#L956
en labels:
https://github.com/openzf...nux/libzfs_pool_os.c#L212
Exacte label definitie:
https://github.com/openzf...nux/libzfs_pool_os.c#L204
Hmm, die laatste klopt niet helemaal, maar de functie is wel degene die de write doet, het maken van het label gebeurt ergens anders, maar goed, you get the point
ZFS on Linux zal volgens mij altijd partities aanmaken, als udev aangeeft dat het om een 'disk' gaat.
De 'rules' daarvoor zijn wat complex.
Bijbehorende code:
https://github.com/openzf...d/zpool/zpool_vdev.c#L956
en labels:
https://github.com/openzf...nux/libzfs_pool_os.c#L212
Exacte label definitie:
https://github.com/openzf...nux/libzfs_pool_os.c#L204
Hmm, die laatste klopt niet helemaal, maar de functie is wel degene die de write doet, het maken van het label gebeurt ergens anders, maar goed, you get the point
[ Voor 44% gewijzigd door FireDrunk op 21-12-2020 14:29 ]
Even niets...
@CurlyMo Inmiddels is de resilver succesvol afgelopen en het partitielabel is er nog steeds.
Label-format klopt ook met de code die @FireDrunk aangegeven had.
Binnenkort schijven bestellen om de andere 2 uit de RAID ook te vervangen, dus dan mag ik nog 2 keer oefenen met resilveren, maar dan direct met partitie-labels
Bedankt in ieder geval voor de uitleg
Label-format klopt ook met de code die @FireDrunk aangegeven had.
Binnenkort schijven bestellen om de andere 2 uit de RAID ook te vervangen, dus dan mag ik nog 2 keer oefenen met resilveren, maar dan direct met partitie-labels
Bedankt in ieder geval voor de uitleg
Na een kleine 170h testen met badblocks en verifieren dat ze goed werken een paar oude bankkaartformaat kaartjes genomen en 20 minuutjes zitten prielen en prullen. Disks er uit en allemaal via forward breakout to SATA opgekoppeld aan een LSI2008 die ik nog had liggen.:
Met black friday een paar WD 12TB op de kop kunnen tikken
Binnenkort shucken maar eerst eens kijken hoe ze werken icm ZFS en USB3.1.
Gisteren dan ook maar deze post even opgehaald:
HyperBart in "Het grote ZFS topic" en hey presto deze middag was alle data in bulk al over
. Nu nog maar eens een paar keer flink scrubben, alles down brengen, nog eens een snapshot nemen, incremental verzenden , configs nog wat omgooien en klaar.Dat ZFS send + receive en gewoon *weten* dat je data goed geland is, heerlijk.
Ik heb nog wel een vraagstuk waar ik het meest efficiënte antwoord op zoek. Meest efficiënt wil zeggen:
- zo min mogelijk buiten ZFS om
- secundair zo min mogelijk bits moven (geen zin om een cp van 20TB te doen of een move van een dataset/filesystem naar een ander)
Gewenste resultaat:
pad "/pool/A/1" en "/pool/A/2" dienen ook filesystems te worden, bij voorkeur onder map A.
Ik stoeide met het idee
[list=1]
• snapshot van A nemen
• een map weg te doen
• snapshot opnieuw als filesystem te mounten
[/list]
Maar dan zit ik met de andere overblijvende map die geen FS is. Dan kan je je afvragen wat het nut is van een snapshot van te maken en zit ik met het probleem dat je een map niveau dieper moet gaan en ik een redelijk zware mv ga moeten doen, want ik zit in een andere FS.
Andere optie zou zijn:
[list=1]
• 2 clones maken van /pool/A
• niet mounten
• map 1 en 2 verwijderen
• clones 2 keer mounten onder 2 mappen in A
• move doen naar één mapje hoger (want ze zitten nu één niveau te diep) en dit twee maal
• oude "bundelende fileystem" droppen (gaat dat?)
[/list]
Stom idee, alles wat op snapshots gebaseerd is kan je niet weg doen
Dat heeft volgens mij als voordeel dat ik in hetzelfde FS de move doe, dus dat gaat zga instant en dat alles via ZFS op de achtergrond gaat.
Als ik je post meraki in "Het grote ZFS topic" er bij neem dan heb je inderdaad geen mirrors, dus die specifieke change die je aanstipt is op jou niet van toepassing.
Goed dat je een backup hebt maar mijn voorkeur ligt nog altijd bij "eerst gezond geraken" voor je gaat upgraden. Of vouw je ook nonchalant je eerste parachute met het idee "ah joh, kheb toch nog die tweede"
9/10 zal het wel goed gaan, maar je zal maar net zien dat er dan iets mis gaat.
[ Voor 70% gewijzigd door HyperBart op 24-12-2020 10:49 ]
Nou, ik heb het geprobeerd met partition-labels, maar gaat nog steeds niet erg lekker.:
Binnenkort schijven bestellen om de andere 2 uit de RAID ook te vervangen, dus dan mag ik nog 2 keer oefenen met resilveren, maar dan direct met partitie-labels
Aanmaken volgens de blog van @FireDrunk ging prima. Vervolgens een zpool replace gedaan van de oude drive met de nieuwe op partition-label.
Resilver afgewacht (om de een of andere reden had mijn sata-dock besloten om op USB2 te connecten, dus dat duurde bijna 3 dagen ipv 22 uur).
Vanmorgen server uitgezet en de nieuwe schijf vanuit USB naar sata verplaatst, maar het hele partition-label dat ik aangemaakt had werd helemaal niet meer herkend? En dus de schijf ook niet, mijn pool zat dus weer in degraded-toestand.
Anyway, ik heb dus het partion-label opnieuw aangebracht. Daarbij viel wel op dat de first-sector nu default op 2048 stond en bij USB (meen ik) op 256. In beide gevallen heb ik de default aangehouden, kan daar het verschil in gezeten hebben?
Na een reboot herkende zfs de pool wel en begon uit zichzelf een resilver die in een halve minuut klaar was met 29 checksum errors.
Helemaal vertrouwen deed ik het niet, dus nog maar een scrub tegenaan gegooid, na een paar uur had die teveel errors en was de pool degraded.
Wat ik nu probeer - en me niet lukt - is om een complete resilver te forceren van de nieuwe schijf.
Pool ziet er nu zo uit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| zpool status data
pool: data
state: DEGRADED
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-9P
scan: resilvered 9.40M in 0 days 00:00:04 with 0 errors on Sun Dec 27 12:50:21 2020
config:
NAME STATE READ WRITE CKSUM
data DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
DATA-12TB-HGST-5PJX7Y9B DEGRADED 0 0 60 too many errors
logs
sda4 ONLINE 0 0 0
cache
sda5 ONLINE 0 0 0 |
Ik heb gepoogd een zpool replace van de nieuwe schijf te doen, maar die klaagt dat die schijf al onderdeel is van een actieve pool. Ook als je het middels "-f" forceert:
code:
1
2
3
4
5
6
7
8
| zpool replace data DATA-12TB-HGST-5PJX7Y9B invalid vdev specification use '-f' to override the following errors: /dev/disk/by-partlabel/DATA-12TB-HGST-5PJX7Y9B is part of active pool 'data' root@pve:~# zpool replace -f data DATA-12TB-HGST-5PJX7Y9B invalid vdev specification the following errors must be manually repaired: /dev/disk/by-partlabel/DATA-12TB-HGST-5PJX7Y9B is part of active pool 'data' |
Ik heb ook nog geprobeerd eerst het device offline te maken en dan de replace te doen, maar dat maakte geen verschil.
Wat is nu de juist weg om een resilver van die nieuwe schijf te forceren?
dmesg en smart zeggen niks relevants.
Voor mijn gevoel komt e.e.a door net iets andere alignment via USB dan via SATA. Ik wil dus nu gewoon de zpool replace opnieuw doen, maar dan in-place.
Of is dat een kwestie van :
- schijf via zpool offline inactief maken
- via gdisk de schijf opnieuw formatteren
- schijf weer toevoegen, hetzij met hetzelfde label, of met een net iets ander label?
Update:
Bovenstaande aanpak net geprobeerd, maar dat werkt dus ook niet. Ik heb via gdisk de hele partitie weggegooid, vervolgens een nieuwe aangemaakt met een afwijkend label.
Zoals te verwachten is het device in de zpool nu "UNAVAIL" ipv "DEGRADED".
Ik had verwacht dat ik met een zpool replace deze schijf nu weer opnieuw aan mijn pool kon toevoegen, maar ZFS blijft ergens herkennen dat de schijf eerder onderdeel is geweest van een pool.
Hoe destructief moet ik een schijf wissen voordat ZFS hem niet meer herkend? Ik kan er wel 12TB aan nullen overheen schrijven met dd, dat werkt vast wel, maar dat lijkt me ook weer wat overkill.
Dat moet toch eenvoudiger kunnen?
Ik sta op het punt om weer gewoon op whole-disk over te gaan ipv partition-labels, maar uit de eerdere discussies begreep ik dat partition-labels eigenlijk de betere methode is. Tot nu toe voelt dat nog niet zo...
Update2:
ZFS blijkt nogal robuust te zijn en geen moeite te hebben met weggegooide partities of andere partitielabels. ZFS heeft zelf 4 "labels" waar de device-info in bewaard wordt. Om een device geen onderdeel meer uit te laten maken van een pool moet je dus al die 4 labels wissen. Anders blijft zpool herkennen dat deze schijf al eerder onderdeel was van een actieve pool.
Er is een commando "zpool labelclear", maar dat werkt niet zoals je zou verwachten. Uiteindelijk hier gevonden: https://github.com/openzfs/zfs/issues/2076 hoe je middels strace en zdb -l kunt achterhalen waar op je schijf die labels staan. Vervolgens met dd die plekken gewist. (maar brute-force de hele 12TB wissen had met wat ik nu weet ook gewerkt...)
Daarna wordt de schijf weer gewoon geaccepteerd in een zpool replace-commando.
PoePoe, gelukkig was het een regenachtige zondagmiddag
Voor mijn gevoel komt e.e.a door net iets andere alignment via USB dan via SATA. Ik wil dus nu gewoon de zpool replace opnieuw doen, maar dan in-place.
Of is dat een kwestie van :
- schijf via zpool offline inactief maken
- via gdisk de schijf opnieuw formatteren
- schijf weer toevoegen, hetzij met hetzelfde label, of met een net iets ander label?
Update:
Bovenstaande aanpak net geprobeerd, maar dat werkt dus ook niet. Ik heb via gdisk de hele partitie weggegooid, vervolgens een nieuwe aangemaakt met een afwijkend label.
Zoals te verwachten is het device in de zpool nu "UNAVAIL" ipv "DEGRADED".
Ik had verwacht dat ik met een zpool replace deze schijf nu weer opnieuw aan mijn pool kon toevoegen, maar ZFS blijft ergens herkennen dat de schijf eerder onderdeel is geweest van een pool.
Hoe destructief moet ik een schijf wissen voordat ZFS hem niet meer herkend? Ik kan er wel 12TB aan nullen overheen schrijven met dd, dat werkt vast wel, maar dat lijkt me ook weer wat overkill.
Dat moet toch eenvoudiger kunnen?
Ik sta op het punt om weer gewoon op whole-disk over te gaan ipv partition-labels, maar uit de eerdere discussies begreep ik dat partition-labels eigenlijk de betere methode is. Tot nu toe voelt dat nog niet zo...
Update2:
ZFS blijkt nogal robuust te zijn en geen moeite te hebben met weggegooide partities of andere partitielabels. ZFS heeft zelf 4 "labels" waar de device-info in bewaard wordt. Om een device geen onderdeel meer uit te laten maken van een pool moet je dus al die 4 labels wissen. Anders blijft zpool herkennen dat deze schijf al eerder onderdeel was van een actieve pool.
Er is een commando "zpool labelclear", maar dat werkt niet zoals je zou verwachten. Uiteindelijk hier gevonden: https://github.com/openzfs/zfs/issues/2076 hoe je middels strace en zdb -l kunt achterhalen waar op je schijf die labels staan. Vervolgens met dd die plekken gewist. (maar brute-force de hele 12TB wissen had met wat ik nu weet ook gewerkt...)
Daarna wordt de schijf weer gewoon geaccepteerd in een zpool replace-commando.
PoePoe, gelukkig was het een regenachtige zondagmiddag
[ Voor 78% gewijzigd door ocaj op 27-12-2020 15:48 ]
Toch heel fijn, ik wil altijd graag dingen begrijpen!
Via SATA meldt mijn (512e-schijf) volgens verwachting een sector size logical/physical van 512/4096 bytes.
Ik heb hierna nog 1 schijf te vervangen (en dan is mijn hele pool van 3x6TB naar 3x12TB), dus ik laat hier van de week wel weten hoe de usb-dock de logical/physical size doorgeeft. Ik denk dat ik morgen na de resilver voor de zekerheid eerst nog een scrub doe, dus duurt nog even voor ik aan de derde schijf toe ben.
Als dat via USB 4096/4096 is, dan gaat de automatische berekening van first-sector door gdisk dus fout als ik je goed begrijp en kan ik beter handmatig first sector=2048 kiezen. Dan zou hij op dezelfde plek komen waar hij via sata terecht zou moeten komen.
Heb je advies voor een goede? Ik vind zo'n docking-station waar je de sata-schijf rechtop in kunt zetten eigenlijk wel handig. (gebruik ik ook om af en toe offsite backups van mijn pool te maken op oude schijven, heb binnenkort weer 3 stuks 6TB backup-schijven beschikbaar
)Ja, ik denk dat je wel gelijk hebt en dat was ook hoe ik begonnen was (met een scrub). Ik denk (maar kan in mijn Terminal-venster niet meer zo ver terugscrollen) dat ik in de war was omdat de schijf tijdens de scrub de schijf van ONLINE naar DEGRADED ging en ik meen dat er iets stond van "too many errors", (60 chksum-errors). Mogelijk heb ik daardoor aangenomen dat hij gestopt was met scrubben, maar liep hij nog wel gewoon door en was hij er uiteindelijk toch wel uitgekomen. Omdat ik dacht dat hij gestopt was ben ik verdere herstelpogingen gaan doen. Volgende keer zal ik via iostat eerst goed kijken of hij nog bezig is.
Waar @CurlyMo die -Fn vandaan had waarschijnlijk: https://github.com/openzfs/zfs/issues/6805
Mogelijk interessant leesvoer, ziet er naar uit dat die invalid exchange iets met corruptie te maken heeft
Mogelijk interessant leesvoer, ziet er naar uit dat die invalid exchange iets met corruptie te maken heeft
Even niets...
Veel te moeilijk:
Waar @CurlyMo die -Fn vandaan had waarschijnlijk: https://github.com/openzfs/zfs/issues/6805
Mogelijk interessant leesvoer, ziet er naar uit dat die invalid exchange iets met corruptie te maken heeft
Die opties staan gewoon in de man pages.
Sinds de 2 dagen regel reageer ik hier niet meer