:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
/u/461322/crop5bf4878fe31e3_cropped.png?f=community)
12.090kWp → 40 panelen → oost/zuid/west | Tibber | EV
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
/u/116403/crop64cfe7aeafeb6_cropped.png?f=community)
:strip_icc():strip_exif()/u/1801/crop683edf62d2a51_cropped.jpg?f=community)
Je hebt helemaal gelijk. Ik ben inmiddels echter al een paar weken zoet met deze migratie terwijl ik er 3 dagen voor gerekend had. Heb inmiddels 85 browser vensters open staan met elke een tabje of 30, allemaal onderzoek naar de verschillende issues waar ik tegenaan loop. Dus had even een moment van zwakte en hoopte op een snel antwoord. Zal het nooit meer doen
Dat is natuurlijk fantastisch! Zal onderzoeken hoe ver Proxmox is met de implementatie van ZFS 2.0.
"I'll just use my Go-Go-Gadget handbook!"
:strip_exif()/u/49248/DPCkoeienUD.gif?f=community)
Ik blijf het een raar verhaal vinden...
- Stond die optie AAN of UIT in je UEFI/BIOS
- Zijn er nieuwere versies daarvan uitgekomen waarin mogelijk iets wordt gefixt omtrent SATA Link Power Management ?
Toen ik onlangs bezig was met mijn HTPC/NAS en ZFS heb ik eerst ALLE opties in mijn UEFI/BIOS nagelopen en dergelijke dingen specifiek uitgezet!
Dat klinkt als of je het woord "effe" hebt gebruikt destijds : Niet doen!
Herkenbaar!
Volgens mij hier of in het Proxmox Topic al een keer gepost, maar bij deze nog een keer : Als je ZFS 2.0 wilt dan moet je Kernel naar versie 5.10 of hoger onder Debian en dus waarschijnlijk ook Proxmox
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
I beg to differ:
[...]
Volgens mij hier of in het Proxmox Topic al een keer gepost, maar bij deze nog een keer : Als je ZFS 2.0 wilt dan moet je Kernel naar versie 5.10 of hoger onder Debian en dus waarschijnlijk ook Proxmox
robert@nas:~$ zfs version zfs-2.0.4-pve1 zfs-kmod-2.0.4-pve1 robert@nas:~$ uname -a Linux nas 5.4.106-1-pve #1 SMP PVE 5.4.106-1 (Fri, 19 Mar 2021 11:08:47 +0100) x86_64 GNU/Linux
Uit mijn hoofd verder ook niks geks gedaan qua additionele repos of zo. Uiteraard alleen de standaard community repo toegevoegd maar niks voor extra ZFS upgrades.
Ik ook, vandaar ook de waarschijnlijk opmerking!
Mijn Debian 11 Testing installatie ging namelijk allerlei 5.10 libraries installeren, terwijl ik nog 5.4 draaide en pas na een upgrade naar 5.10 deed alles het ineens!
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
:strip_icc():strip_exif()/u/65843/chef60x60.jpg?f=community)
Hmm, je hebt gelijk dat het nog niet 100% duidelijk is. Wel wat er aan de hand was en hoe het opgelost kon worden, maar niet hoe het ontstaan is.:
[...]
Ik blijf het een raar verhaal vinden...
- Stond die optie AAN of UIT in je UEFI/BIOS
- Zijn er nieuwere versies daarvan uitgekomen waarin mogelijk iets wordt gefixt omtrent SATA Link Power Management ?
Ik ben er nog wel een beetje naar aan het kijken maar ben bang dat het misschien nooit duidelijk gaat worden:
- BIOS is afgelopen jaren niet bijgewerkt. Maar, wellicht dat de plotselinge spanningsuitval enkele weken geleden instellingen heeft omgegooid.
- Nieuwere kernel: hmmm, ik heb dat in eerste instantie uitgesloten, maar nu twijfel ik. Ik kan aan de bestandsdatum zien dat de laatste kernel op 28 maart geinstalleerd is en de stroomstoring was op vrijdag 2 april - en de wekelijkse scrub op elke zaterdag. Dus wellicht dat die nieuwere kernel inderdaad een problematische setting erbij kreeg. Niet helemaal wat ik zou verwachten, Debian is over het algemeen best conservatief hierin.
:strip_icc():strip_exif()/u/11631/tentacle.jpg?f=community)
Ik draai Debian stable met ZFS op een aantal systemen::
[...]
Ik ook, vandaar ook de waarschijnlijk opmerking!
Mijn Debian 11 Testing installatie ging namelijk allerlei 5.10 libraries installeren, terwijl ik nog 5.4 draaide en pas na een upgrade naar 5.10 deed alles het ineens!
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| # uname -a Linux archive 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux # dpkg -l | grep zfs ii libzfs4linux 2.0.3-1~bpo10+1 amd64 OpenZFS filesystem library for Linux ii zfs-dkms 2.0.3-1~bpo10+1 all OpenZFS filesystem kernel modules for Linux ii zfs-zed 2.0.3-1~bpo10+1 amd64 OpenZFS Event Daemon ii zfsutils-linux 2.0.3-1~bpo10+1 amd64 command-line tools to manage OpenZFS filesystems # dpkg -l | grep linux-headers ii linux-headers-4.19.0-16-amd64 4.19.181-1 amd64 Header files for Linux 4.19.0-16-amd64 ii linux-headers-4.19.0-16-common 4.19.181-1 all Common header files for Linux 4.19.0-16 ii linux-headers-5.10.0-0.bpo.5-amd64 5.10.24-1~bpo10+1 amd64 Header files for Linux 5.10.0-0.bpo.5-amd64 ii linux-headers-5.10.0-0.bpo.5-common 5.10.24-1~bpo10+1 all Common header files for Linux 5.10.0-0.bpo.5 ii linux-headers-amd64 5.10.24-1~bpo10+1 amd64 Header files for Linux amd64 configuration (meta-package) |
Kernel is dus 4.19.X maar hij trekt wel 5.10 linux-headers mee naar binnen voor het bouwen van de ZFS 2.0 dkms modules.
Leaping Lab Rats!
/u/172597/crop5e1225c8b1011.png?f=community)
No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.
No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.
Maar hoe vaak gebeurt dat nog
Zat er laatst nog over na te denken toen een vriend wat dingen vroeger over de blocksize en zo...
Vroeger was men heel erg met dat soort dingen bezig als het om een bepaald type server ging en alle storage op HDD's zat en dan eigenlijk vrijwel altijd in RAID vorm dus kreeg je bij je stripesize al de keuzes :
- 32 a 64 KB was dan voornamelijk voor kleine bestanden/drukke fileservers.
- 128 KB was een veilige tussenvariant die zowel voor kleine als grote bestanden voldeed.
- 256 KB was al meer voor voornamelijk grote bestanden.
En dan kreeg je natuurlijk nog de keuzes op filesystem niveau die weer zelfs per variant konden verschillen :
- NTFS voor Windows bakken met bijbehorende keuzes.
- EXT3 en EXT4 onder Linux waren een soort allround solution.
- XFS onder Linux stond echter weer bekend als dat filesystem voor hele grote bestanden.
Zijn dit soort keuzes en gedachtes nu helemaal de wereld uit sinds we oplossingen zoals BTRFS en ZFS hebben
Het enige wat ik zo gauw kan bedenken zijn de ashift waardes...
En op het moment dat je een ZFS Volume aanmaakt dan heb je niet eens met het formateren daarvan te maken!
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Het betekent simpelweg of je database writes aligned zijn of niet. Zo niet, dan ben elk blok meerdere keren aan aan het schrijven.:
[...]
Maar hoe vaak gebeurt dat nog
Het enige wat ik zo gauw kan bedenken zijn de ashift waardes...
En op het moment dat je een ZFS Volume aanmaakt dan heb je niet eens met het formateren daarvan te maken!
Sinds de 2 dagen regel reageer ik hier niet meer
Vaak & ja. Je hebt inderdaad de ashift die voor heel je pool geldt, maar je hebt ook nog een record size die per dataset ingesteld kan worden. Volgens mij is het zo dat bij een recordsize van 64MiB iedere write+fsync 64 MiB kost. Da's prima voor wanneer je je Bluray films backupt, maar als je een database hebt die heel veel kleine writes doet (per rij 1 write soms/vaak) dan is het significant minder handig. Daarnaast kan er, afhankelijk van de toepassing, ook best wat performanceverschil in zitten.:
[...]
Maar hoe vaak gebeurt dat nog
[...]
Zijn dit soort keuzes en gedachtes nu helemaal de wereld uit sinds we oplossingen zoals BTRFS en ZFS hebben
maken!
No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.
Nope, met deze vraag geef je duidelijk aan de scope niet te kennen
Sinds de 2 dagen regel reageer ik hier niet meer
No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.
:strip_exif()/u/54579/Static.gif?f=community)
Heb je nou 10 nieuwe schijven of 8 nieuwe schijven
Als het er maar 8 zijn dan zal je sowieso een nieuwe pool moeten gaan bouwen, want autoexpanden gaat dan niet, omdat je ze dan ook alle 10 moet vervangen!
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Ik denk dat dit de beste plek is om mijn vraag even te droppen
Ik ben voor een familielid aan het kijken om een klein servertje in elkaar te zetten (voor MKB gebruik, voornamelijk voor "gedeelde opslag" en evt. later wat meer server toepassingen). Keuzes qua hardware liggen bij mij en ik zal het ding verder ook gaan onderhouden. Zelf ook al 10 jaar of zo een thuisservertje draaien op consumentenhardware dus in die zin ben ik ook niet echt op zoek naar een kant en klare server of (semi dure) zakelijke hardware.
Ding zal ik Proxmox op gaan draaien met ZFS zodat ik de boel mooi kan syncen met mijn thuisserver en een Orange Pi. Mijn eigen server heb ik begin vorig jaar geupgrade / vervangen en toen de keuze voor ECC geheugen gemaakt (met een Intel i3-9100 en Fujitsu / Kontron moederbord). Echter blijkt ECC ondersteuning op de nieuwste Intel CPUs te ontbreken / alleen aanwezig bij de Xeons, en bij AMD (waar ik nog minder kaas van gegeten heb) lijkt ECC support volgens de pricewatch ook alleen op de server CPUs te zitten.
Mijn grote vraag is dan ook: hoe hard is ECC nodig? Ik weet in zoverre dat het voordelen bied om bitflips in het geheugen te voorkomen / detecteren en daarmee dus bestandscorruptie tegen te gaan. Ik vraag me dan alleen af hoe reëel de kans daarop is, ook gezien de meerprijs die het met zich mee zou brengen. Bij mijn i3-9100 systeem had ik niet echt het idee dat ik veel duurder uit kwam, die CPU kwam ik al op uit, Fujitsu / Kontron wordt veel gebruikt en zit ECC als bijkomstigheid op, dus dan nog net dat ECC RAM plaatsen is dan geen gekke keuze. Alleen hebben recente Intel (consumenten) CPUs klaarblijkelijk dus geen ECC ondersteuning, dus kom je al bij de veel duurdere Xeons uit. En een "oud" systeem samenstellen kan weer niet omdat bv de genoemde i3-9100 (vrijwel) niet verkrijgbaar is en daarnaast een stuk duurder (dan 10th/11th gen CPUs).
Wat is in deze dus wijsheid? Toch voor een systeem gaan met ECC geheugen, of is de kans op issues zo klein dat het de meerprijs niet waard is en dus lekker zonder ECC gaan draaien? Gezien ik dus ook periodieke backups / syncs zal doen naar 2 andere systemen lijkt de kans op dataverlies bij corruptie mij dan ook afwezig? De bitflip zou eventueel met een sync mee gaan, maar de oude snapshots zullen onaangepast blijven en daaruit zou een corrupt bestand dan teruggehaald kunnen worden, zou ik zeggen.
Ik ben voor een familielid aan het kijken om een klein servertje in elkaar te zetten (voor MKB gebruik, voornamelijk voor "gedeelde opslag" en evt. later wat meer server toepassingen). Keuzes qua hardware liggen bij mij en ik zal het ding verder ook gaan onderhouden. Zelf ook al 10 jaar of zo een thuisservertje draaien op consumentenhardware dus in die zin ben ik ook niet echt op zoek naar een kant en klare server of (semi dure) zakelijke hardware.
Ding zal ik Proxmox op gaan draaien met ZFS zodat ik de boel mooi kan syncen met mijn thuisserver en een Orange Pi. Mijn eigen server heb ik begin vorig jaar geupgrade / vervangen en toen de keuze voor ECC geheugen gemaakt (met een Intel i3-9100 en Fujitsu / Kontron moederbord). Echter blijkt ECC ondersteuning op de nieuwste Intel CPUs te ontbreken / alleen aanwezig bij de Xeons, en bij AMD (waar ik nog minder kaas van gegeten heb) lijkt ECC support volgens de pricewatch ook alleen op de server CPUs te zitten.
Mijn grote vraag is dan ook: hoe hard is ECC nodig? Ik weet in zoverre dat het voordelen bied om bitflips in het geheugen te voorkomen / detecteren en daarmee dus bestandscorruptie tegen te gaan. Ik vraag me dan alleen af hoe reëel de kans daarop is, ook gezien de meerprijs die het met zich mee zou brengen. Bij mijn i3-9100 systeem had ik niet echt het idee dat ik veel duurder uit kwam, die CPU kwam ik al op uit, Fujitsu / Kontron wordt veel gebruikt en zit ECC als bijkomstigheid op, dus dan nog net dat ECC RAM plaatsen is dan geen gekke keuze. Alleen hebben recente Intel (consumenten) CPUs klaarblijkelijk dus geen ECC ondersteuning, dus kom je al bij de veel duurdere Xeons uit. En een "oud" systeem samenstellen kan weer niet omdat bv de genoemde i3-9100 (vrijwel) niet verkrijgbaar is en daarnaast een stuk duurder (dan 10th/11th gen CPUs).
Wat is in deze dus wijsheid? Toch voor een systeem gaan met ECC geheugen, of is de kans op issues zo klein dat het de meerprijs niet waard is en dus lekker zonder ECC gaan draaien? Gezien ik dus ook periodieke backups / syncs zal doen naar 2 andere systemen lijkt de kans op dataverlies bij corruptie mij dan ook afwezig? De bitflip zou eventueel met een sync mee gaan, maar de oude snapshots zullen onaangepast blijven en daaruit zou een corrupt bestand dan teruggehaald kunnen worden, zou ik zeggen.
De standaard vraag is in dit geval wat de kosten van downtime zijn. Als je familielid 10k per dag aan omzetverlies leidt bij een onbereikbare server, dan heb je daar direct de markt voor kant en klare servers te pakken. Dezelfde vraag als jouw backups falen, er een cryptoware langskomt, enz. Hoe zit het met privacy gevoeligheid van de data?
Ik denk dus dat ECC nog wel de minst relevante kwestie is van je dienst. We zijn tenminste op tweakers. Dan krijg je net weer een ander antwoord op de vraag dan gesteld
Is het budget zo laag dat ECC en Xeon nou echt zo'n probleem vormen, nog los van het gemak van vPro voor remote beheer.
Sinds de 2 dagen regel reageer ik hier niet meer
Allemaal zeer terechte vragen.:
[...]
De standaard vraag is in dit geval wat de kosten van downtime zijn. Als je familielid 10k per dag aan omzetverlies leidt bij een onbereikbare server, dan heb je daar direct de markt voor kant en klare servers te pakken. Dezelfde vraag als jouw backups falen, er een cryptoware langskomt, enz. Hoe zit het met privacy gevoeligheid van de data?
Ik denk dus dat ECC nog wel de minst relevante kwestie is van je dienst. We zijn tenminste op tweakers. Dan krijg je net weer een ander antwoord op de vraag dan gesteld
Is het budget zo laag dat ECC en Xeon nou echt zo'n probleem vormen, nog los van het gemak van vPro voor remote beheer.
De situatieschets. Het gaat om een (eet)café, dus computer / administratie gebeuren is min of meer bijzaak. Het gaat dan ook voornamelijk om opslag van offertes en gemaakte facturen etc. Momenteel staan deze op een PC (Origineel mijn eerste zelfbouw PC, met een Core2Duo waar alleen een SSD bij is gezet
), waarbij via Syncthing de belangrijke mappen worden gesynchroniseerd naar mijn zelfbouw server.Qua privacy: die is er dus niet, ben ik mij bewust van, en het familielid zou dit evengoed moeten weten (maar wil wel van OneDrive af want cloud is vies bah
). Andersom geldt ook dat ik, op locatie, sowieso op het systeem kan inloggen. De data is op mijn thuisserver vervolgens wel opgeslagen op een encrypted ZFS volume (key staat wel op dit systeem ), waarbij de snapshots "raw" (oftewel encrypted) naar de Orange Pi gaan (hier staat de sleutel dan ook niet op). Maar evengoed zal ik ook bij een andere oplossing ("koop een HP / Dell / ... server") de boel mogen installeren en onderhouden, en dus root / admin toegang hebben en aan alle bestanden kunnen.Qua ransomware: de belangrijke data komt momenteel dus al mijn kant op waar periodiek (elk kwartier / uur / dag) ZFS snapshots worden gemaakt. In die zin verwacht ik v.w.b. ransomware dus veilig te zijn want snapshots zijn read only. Uiteraard zou er wel iets kunnen gebeuren als iemand toegang verschaft tot de thuisserver. Maar de Orange Pi, die bij hem ligt, weer pull based werkt en mijn server daar überhaupt niet op kan inloggen. En andersom de Orange Pi een beperkte login op mijn server heeft en alleen snapshots kan senden, holden etc., dus zeker geen snapshots kan destroyen, noch heeft dat account sudo rechten. Dus toegang tot systeem A betekent niet dat ook de snapshots op systeem B verwijderd kunnen worden.
Voor mij dus een gevalletje "in het land der blinden is eenoog koning". Maar ik probeer wel alles zo goed / veilig mogelijk op te zetten en voor mijn gevoel is dat ook zo (enige wat echt mist naar mijn weten is een semi automatische offline backup). En vanuit mijzelf probeer ik dingen sowieso altijd zo goed / perfect mogelijk op te zetten (in ieder geval qua software, qua hardware ging ik anders wel direct voor een Xeon met ECC
). En ging dit, zoals jij stelt, over een situatie waarbij downtime echt meteen zou zorgen voor omzetverlies dan had ik alsnog meteen "nee" verkocht. Immers is dit voor mij, als software developer van beroep, ook maar gehobby en iets waar mijn interesses liggen. Het is dan ook zeker niet mijn bedoeling om dit als "professionele" oplossing neer te zetten met "24/ support". (En was dit wel de bedoeling, had ik ook vriendelijk bedankt)
Ik heb diverse 2TB schijven in RaidZ2, alle 2TB schijven ben ik aan het vervangen (enkele van deze zijn al 4TB).:
[...]
Heb je nou 10 nieuwe schijven of 8 nieuwe schijven
Als het er maar 8 zijn dan zal je sowieso een nieuwe pool moeten gaan bouwen, want autoexpanden gaat dan niet, omdat je ze dan ook alle 10 moet vervangen!
Dat ik ze alle 10 dien te vervangen om de verdubbeling uiteindelijk te krijgen is bij mij bekend.
Autoexpand staan wel alvast aan :-)
Tja, je zei er niks over dus ik dacht laat ik dat maar effe aanwijzen als mogelijk probleem:
Ik heb diverse 2TB schijven in RaidZ2, alle 2TB schijven ben ik aan het vervangen (enkele van deze zijn al 4TB).
Dat ik ze alle 10 dien te vervangen om de verdubbeling uiteindelijk te krijgen is bij mij bekend.
Autoexpand staan wel alvast aan :-)
Waarom niet gewoon een 1U "pizzadoos formaat" cheapo servertje van Dell of HP kopen en daarin 2x 4 TB of zo proppen
Verder kan je natuurlijk ook voor een Gxxxx model gaan die ook ECC support hebben t/m de G5000 serie als het goed is in ieder geval
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Ehh...
- https://www.serverzaak.nl...ore-2-40-ghz-80w-tdp.html
Dit is een Socket 2011 model en die gaat niet passen in een :
- https://www.serverzaak.nl/dell-poweredge-r210.html
Daarnaast is een Xeon 3400 wel heel erg oud : Dergelijke nieuwere modellen worden met de E3 Xeon Serie geleverd die genoeg hebben aan alleen ECC geheugen
Heeft niks in V&A staan op het moment
Mocht het trouwens nog interessant/relevant zijn :
- Xeon E5 2000 modellen passen ook op een regulier X79 moederbord.
- Xeon E5 2000v2 modellen ook.
- Xeon E5 2000v3 modellen passen ook op een regulier X99 moederbord.
- Xeon E5 2000v4 modellen ook.
In alle gevallen kan je beter niet knoeien met ECC of Registered RAM, want dat is één groot gepuzzel!
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Dat snap ik, links puur ter referentie/indicatie van de prijzen in dat segment.:
[...]
Ehh...
- https://www.serverzaak.nl...ore-2-40-ghz-80w-tdp.html
Dit is een Socket 2011 model en die gaat niet passen in een :
- https://www.serverzaak.nl/dell-poweredge-r210.html
Dat zei ik ook niet. Stuur hem even een DM of een email (server-express.nl), hij heeft genoeg geschikte hardware in de aanbieding en anders kan hij er waarschijnlijk wel aan komen voor nette prijzen en goede service.Heeft niks in V&A staan op het moment
[ Voor 6% gewijzigd door d3vlin op 17-05-2021 16:12 ]
Leaping Lab Rats!
/u/200133/artemis_square_e_60-60.png?f=community)
Het was toch juist zo dat je altijd voor de Pro modellen moet kiezen als je gegarandeerde ECC support wilt hebben
Vooral omdat er helaas geen "Pro chipsets" bestaan... voor zover je daarvan kan spreken bij AMD dan...
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
:strip_icc():strip_exif()/u/399334/crop5a6e1999e99b3_cropped.jpeg?f=community)
Voor zover ik weet ondersteunen alle zen2 en zen3 CPU's (onofficieel) ECC. Van de x570 borden heb ik gelezen dat alle x570 borden van Gigabyte en Asrock ECC. Maar zolang niks officieel is kan de daadwerkelijke ondersteuning nogal iffy zijn natuurlijk.:
[...]
Het was toch juist zo dat je altijd voor de Pro modellen moet kiezen als je gegarandeerde ECC support wilt hebben
Vooral omdat er helaas geen "Pro chipsets" bestaan... voor zover je daarvan kan spreken bij AMD dan...
PVoutput Wie goed doet, die goed ontmoet.
Dat is dus het hele probleem...
pricewatch: Gigabyte X570 Aorus PRO
Hoop geld voor een weinig spectaculair moederbord zonder IPMI dat voornamelijk op Gaming en RGB is gericht en makkelijk rond de € 80 minder had mogen kosten, zoals de AsRock Z87/97 Extreme4 bordjes die ik in het verleden heb gekocht!
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
:strip_exif()/u/73/koelkast-lach.gif?f=community)
Ik weet niet hoeveel je aan de data bent gehecht, maar ik zou het volgende doen :
- Ervoor zorgen dat de AutoExpand vlag aanstaat!
- De HDD's 1 voor 1 vervangen!
- En dan de boel laten expanden
Verder moet je inderdaad echt even goed lezen over hetgene dat je aan het doen bent, want één foutje en je zit gelijk in de shit met dit soort dingen!
Ga daarom eens even flink lezen in Het grote ZFS topic hoe het WEL moet en wat de beste manier is om dit soort dingen veilig uit te voeren
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
- Auto Expand had ik al aan staan:
[...]
Ik weet niet hoeveel je aan de data bent gehecht, maar ik zou het volgende doen :
- Ervoor zorgen dat de AutoExpand vlag aanstaat!
- De HDD's 1 voor 1 vervangen!
- En dan de boel laten expanden
Verder moet je inderdaad echt even goed lezen over hetgene dat je aan het doen bent, want één foutje en je zit gelijk in de shit met dit soort dingen!
Ga daarom eens even flink lezen in Het grote ZFS topic hoe het WEL moet en wat de beste manier is om dit soort dingen veilig uit te voeren
- 1 voor 1 kan (zal wat langer duren met 10 disks en dan steeds rebuilden ^^)
- Zou meer irritant zijn als ik de data zou verliezen
- Heb apparte RAID1 Zfs pool voor backups.
/u/170728/owl.png?f=community)
Een stukje een crosspost maar een specifieke ZFS vraag:
Hoe komt dat na een resilver er na een scrub toch nog wat cksum errors achterblijven? Mijn ervaring was altijd "na een resilver doe ik altijd nog eens een scrub want doorgaans komen er nog een aantal achterblijvertjes qua fouten uit".
@Thralas ik zag nu ook dat een deel van mijn zpool status'en niet mee gekomen was, bij deze nog even.
Op 08/06 12.37AM werd ik verwittigd door ZED en smartd:
Om 1:03 AM:
Die ochtend dan even een zpool status gedaan en die gaf aan dat op disk 2 er 15 write errors waren (dus geen cksum) waardoor het device in de vdev als faulted gemarkeerd werd, bijgevolg een degraded vdev en dus een degraded pool.
Na een "zpool clear poolnaam" begon er automatisch een resilver die voltooide met volgende output:
Verder geen fouten, cksum errors of wat dan ook op dat moment. Scrub gestart.
Op woensdag 9 juni kreeg ik opnieuw een melding, richting het einde van de scrub:
Hierna opnieuw een clear gedaan, opnieuw een scrub en toen kwam alles met 0 fouten terug.
zpool history:
Kernel log ten tijde van fouten:
Wat? Dat laat ik aan ZFS over. Ik heb de pool gecleared en de resilver trapte automatisch af (ik ga er van uit door ZED).
Ze zijn aangesloten via de onboard controller en een LSI 2008 (zijnde een M1015 in IT mode), in een verdeling 4 op LSI en 2 op onboard. De disk die bokte zat op de onboard van mijn Fujitsu D3644-B bordje. (zie inventaris NAS refreshed).
Hoe komt dat na een resilver er na een scrub toch nog wat cksum errors achterblijven? Mijn ervaring was altijd "na een resilver doe ik altijd nog eens een scrub want doorgaans komen er nog een aantal achterblijvertjes qua fouten uit".
EDIT::
Vandaag kreeg ik een berichtje van mijn server dat disk nummer 2 naar FAULTED is gegaan binnen mijn ZFS Pool met 1 RAIDZ2 VDEV.
Ik kan zelf niet inschatten hoe ernstige de fout is, wie kan even mee beoordelen. Er gaat voor de rest niks mis met sectors, het lijkt mij op het eerste zicht een communicatiefout tussen disk en controller, waarbij de diskmechanica en logica goed werkt maar er iets mis loopt bij het aanleveren/communiceren van de data.
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 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0004 128 128 054 Old_age Offline - 108 3 Spin_Up_Time 0x0007 180 180 024 Pre-fail Always - 319 (Average 411) 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 131 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000a 100 100 067 Old_age Always - 0 8 Seek_Time_Performance 0x0004 140 140 020 Old_age Offline - 15 9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 4214 10 Spin_Retry_Count 0x0012 100 100 060 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 32 22 Unknown_Attribute 0x0023 100 100 025 Pre-fail Always - 100 192 Power-Off_Retract_Count 0x0032 097 097 000 Old_age Always - 4442 193 Load_Cycle_Count 0x0012 097 097 000 Old_age Always - 4442 194 Temperature_Celsius 0x0002 185 185 000 Old_age Always - 35 (Min/Max 22/53) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 1 SMART Error Log Version: 1 ATA Error Count: 1 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 1 occurred at disk power-on lifetime: 4205 hours (175 days + 5 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 43 00 00 00 00 00 Error: ICRC, ABRT at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 61 00 90 18 9c a3 40 08 32d+04:03:38.908 WRITE FPDMA QUEUED 61 40 88 58 9f a3 40 08 32d+04:03:38.907 WRITE FPDMA QUEUED 61 40 e0 18 9f a3 40 08 32d+04:03:38.907 WRITE FPDMA QUEUED 61 40 78 d8 9b a3 40 08 32d+04:03:38.906 WRITE FPDMA QUEUED 61 40 d8 98 9b a3 40 08 32d+04:03:38.906 WRITE FPDMA QUEUED
Aangezien ZFSheb ik nu gewoon even de pool gecleared (=de fouten clearen, dus de pool terug op orde stellen en aangeven dat de disk terug mag mee doen), dan doet de disk hopelijk toch al terug (een tijdje mee, tenzij er wat ernstigers aan de hand is maar dan zal de disk ongetwijfeld er weer uit knikkeren.
root@nas:~# zpool clear poolnaam scan: resilvered 493M in 0 days 00:00:05 with 0 errors on Tue Jun 8 10:11:36 2021
@Thralas ik zag nu ook dat een deel van mijn zpool status'en niet mee gekomen was, bij deze nog even.
Op 08/06 12.37AM werd ik verwittigd door ZED en smartd:
code:
1
2
3
4
5
6
7
8
9
10
11
12
| The number of I/O errors associated with a ZFS device exceeded
acceptable levels. ZFS has marked the device as faulted.
impact: Fault tolerance of the pool may be compromised.
eid: 48
class: statechange
state: FAULTED
host: nas
time: 2021-06-08 00:37:29+0200
vpath: /dev/disk/by-partlabel/disk-2-SERIENUMMER
vguid: 0x650479A064440F15
pool: 0x4CB3559B6DED0CAF |
Om 1:03 AM:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| This message was generated by the smartd daemon running on: host name: nas DNS domain: [Empty] The following warning/error was logged by the smartd daemon: Device: /dev/sdh [SAT], ATA error count increased from 0 to 1 Device info: WDC WD120EDAZ-11F3RA0, S/N:serienummer, WWN:5-000cca-291e211da, FW:81.00A81, 12.0 TB For details see host's SYSLOG. You can also use the smartctl utility for further investigation. Another message will be sent in 24 hours if the problem persists. |
Die ochtend dan even een zpool status gedaan en die gaf aan dat op disk 2 er 15 write errors waren (dus geen cksum) waardoor het device in de vdev als faulted gemarkeerd werd, bijgevolg een degraded vdev en dus een degraded pool.
Na een "zpool clear poolnaam" begon er automatisch een resilver die voltooide met volgende output:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| ZFS has finished a resilver: eid: 56 class: resilver_finish host: nas time: 2021-06-08 10:11:36+0200 pool: poolnaam state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(5) for details. scan: resilvered 493M in 0 days 00:00:05 with 0 errors on Tue Jun 8 10:11:36 2021 |
Verder geen fouten, cksum errors of wat dan ook op dat moment. Scrub gestart.
Op woensdag 9 juni kreeg ik opnieuw een melding, richting het einde van de scrub:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| The number of checksum errors associated with a ZFS device
exceeded acceptable levels. ZFS has marked the device as
degraded.
impact: Fault tolerance of the pool may be compromised.
eid: 82
class: statechange
state: DEGRADED
host: nas
time: 2021-06-09 05:46:39+0200
vpath: /dev/disk/by-partlabel/disk-2-serienummer
vguid: 0x650479A064440F15
pool: 0x4CB3559B6DED0CAF |
Hierna opnieuw een clear gedaan, opnieuw een scrub en toen kwam alles met 0 fouten terug.
zpool history:
code:
1
2
3
4
5
6
7
8
9
10
11
12
| 2021-05-03.02:00:38 zpool scrub poolnaam 2021-05-10.02:00:39 zpool scrub poolnaam 2021-05-17.02:00:38 zpool scrub poolnaam 2021-05-24.02:00:33 zpool scrub poolnaam 2021-05-31.02:00:35 zpool scrub poolnaam 2021-06-07.02:00:36 zpool scrub poolnaam 2021-06-08.10:11:36 zpool clear poolnaam 2021-06-08.11:48:34 zpool scrub poolnaam 2021-06-08.14:51:53 zpool upgrade poolnaam 2021-06-09.08:58:38 zpool clear poolnaam 2021-06-09.08:59:16 zpool scrub poolnaam 2021-06-14.02:00:38 zpool scrub poolnaam |
Kernel log ten tijde van fouten:
[Jun 8 00:36] ata6.00: exception Emask 0x10 SAct 0x10060000 SErr 0x400100 action 0x6 frozen
[ +0.000010] ata6.00: irq_stat 0x08000000, interface fatal error
[ +0.000002] ata6: SError: { UnrecovData Handshk }
[ +0.000002] ata6.00: failed command: WRITE FPDMA QUEUED
[ +0.000003] ata6.00: cmd 61/40:88:58:9f:a3/00:00:f0:00:00/40 tag 17 ncq dma 32768 out
res 40/00:00:18:9c:a3/00:00:f0:00:00/40 Emask 0x10 (ATA bus error)
[ +0.000002] ata6.00: status: { DRDY }
[ +0.000002] ata6.00: failed command: WRITE FPDMA QUEUED
[ +0.000002] ata6.00: cmd 61/00:90:18:9c:a3/03:00:f0:00:00/40 tag 18 ncq dma 393216 out
res 40/00:00:18:9c:a3/00:00:f0:00:00/40 Emask 0x10 (ATA bus error)
[ +0.000002] ata6.00: status: { DRDY }
[ +0.000002] ata6.00: failed command: WRITE FPDMA QUEUED
[ +0.000002] ata6.00: cmd 61/40:e0:18:9f:a3/00:00:f0:00:00/40 tag 28 ncq dma 32768 out
res 40/00:00:18:9c:a3/00:00:f0:00:00/40 Emask 0x10 (ATA bus error)
[ +0.000002] ata6.00: status: { DRDY }
[ +0.000003] ata6: hard resetting link
[ +0.313400] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ +0.000449] ata6.00: supports DRM functions and may not be fully accessible
[ +0.111403] ata6.00: supports DRM functions and may not be fully accessible
[ +0.008142] ata6.00: configured for UDMA/133
[ +0.000010] sd 6:0:0:0: [sdh] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ +0.000001] sd 6:0:0:0: [sdh] tag#17 Sense Key : Illegal Request [current]
[ +0.000001] sd 6:0:0:0: [sdh] tag#17 Add. Sense: Unaligned write command
[ +0.000002] sd 6:0:0:0: [sdh] tag#17 CDB: Write(16) 8a 00 00 00 00 00 f0 a3 9f 58 00 00 00 40 00 00
[ +0.000001] blk_update_request: I/O error, dev sdh, sector 4037255000 op 0x1:(WRITE) flags 0x700 phys_seg 8 prio class 0
[ +0.000007] zio pool=poolnaam vdev=/dev/disk/by-partlabel/disk-2-serienummer error=5 type=2 offset=2067071414272 size=32768 flags=180880
[ +0.000009] sd 6:0:0:0: [sdh] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ +0.000001] sd 6:0:0:0: [sdh] tag#18 Sense Key : Illegal Request [current]
[ +0.000001] sd 6:0:0:0: [sdh] tag#18 Add. Sense: Unaligned write command
[ +0.000001] sd 6:0:0:0: [sdh] tag#18 CDB: Write(16) 8a 00 00 00 00 00 f0 a3 9c 18 00 00 03 00 00 00
[ +0.000001] blk_update_request: I/O error, dev sdh, sector 4037254168 op 0x1:(WRITE) flags 0x700 phys_seg 6 prio class 0
[ +0.000003] zio pool=poolnaam vdev=/dev/disk/by-partlabel/disk-2-serienummer error=5 type=2 offset=2067070988288 size=393216 flags=40080c80
[ +0.000004] sd 6:0:0:0: [sdh] tag#28 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ +0.000000] sd 6:0:0:0: [sdh] tag#28 Sense Key : Illegal Request [current]
[ +0.000001] sd 6:0:0:0: [sdh] tag#28 Add. Sense: Unaligned write command
[ +0.000001] sd 6:0:0:0: [sdh] tag#28 CDB: Write(16) 8a 00 00 00 00 00 f0 a3 9f 18 00 00 00 40 00 00
[ +0.000001] blk_update_request: I/O error, dev sdh, sector 4037254936 op 0x1:(WRITE) flags 0x700 phys_seg 8 prio class 0
[ +0.000002] zio pool=poolnaam vdev=/dev/disk/by-partlabel/disk-2-serienummer error=5 type=2 offset=2067071381504 size=32768 flags=180880
[ +0.000004] ata6: EH complete
Nou ja
Wat? Dat laat ik aan ZFS over. Ik heb de pool gecleared en de resilver trapte automatisch af (ik ga er van uit door ZED).Het zijn WDC WD120EDAZ-11F3RA0 schijven.
Ze zijn aangesloten via de onboard controller en een LSI 2008 (zijnde een M1015 in IT mode), in een verdeling 4 op LSI en 2 op onboard. De disk die bokte zat op de onboard van mijn Fujitsu D3644-B bordje. (zie inventaris NAS refreshed).
Ik heb de kernel logs er even bij geplakt.
[ Voor 69% gewijzigd door HyperBart op 14-06-2021 23:54 ]
Eindelijk !!!! ArsTechnica: ZFS fans, rejoice—RAIDz expansion will be a thing very soon
Dit is een functie die ik zo miste van de hardware raid kaarten
[dislectie] hoeveel forum deelnemers heb je nodig om een peertje te vervangen ?
Yes, best een leuke.:
ArsTechnica: ZFS fans, rejoice—RAIDz expansion will be a thing very soon
[...]
Dit is een functie die ik zo miste van de hardware raid kaarten
Aandachtspuntje: bestaande datablocks en hun pariteit worden niet volgens het nieuwe aantal disks verspreid. Dat wil dus zeggen dat als je een RAIDZ2 had van 5 disks en je breidt uit met 2 disks de blocks A B C P1 en P2 op die 5 disks stond herverdeeld worden maar niet herberekend worden volgens het nieuwe aantal disks.
Het blijft dus A B C P1 P2 waarbij een of twee blocks op de nieuwe disks terechtkomen om alles capaciteitsgewijs in balans te houden maar het is NIET zo dat hij gaat inlezen en er A B C D E P1 P2 van gaat maken oid. Je oude "pariteitsratio'" wordt dus behouden tenzij er wat wijzigt aan de files natuurlijk.
[ Voor 63% gewijzigd door HyperBart op 17-06-2021 12:12 ]
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
:strip_exif()/u/53522/crop583d477015a24.gif?f=community)
Ik zit even mezelf weer in te lezen in ZFS, maar eerst even een situatieschetsje:
Dit is mijn huidige pool. Vier van deze disks zijn 2TB groot, de andere 4 zijn 4TB groot. De disks van 2TB wil ik allemaal gaan vervangen voor v van 14TB groot. Dit zijn nog te shucken WD Elements, maar ik wil eerst even weten hoe ik de beoogde migratie het beste kan aanpakken. Is er een manier waarop ik (nu weet ik even niet exact welke raidz1 pool ik moet hebben) een van deze pools kan migreren naar de nieuw aan te maken?
Kan ik dit het beste aanpakken door een snapshot te maken en die over te zetten naar de nieuwe pool? Dus eerst met zfs snapshot -r data@moving en daarna zfs send -R sourcepool@moving | zfs receive -F [nieuwepool]? Of kan dat niet, omdat ik maar 1 data pool heb?
Of zijn de raidz1-0 en raidz1-1 de pools? Het is voor mij even geleden wat ook alweer precies een pool is.
pool: data
state: ONLINE
scan: scrub repaired 0B in 10:06:57 with 0 errors on Sun Jun 13 10:30:59 2021
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sdb ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
sdc ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
sdh ONLINE 0 0 0
sdf ONLINE 0 0 0
sdi ONLINE 0 0 0
sdg ONLINE 0 0 0
errors: No known data errors
Kan ik dit het beste aanpakken door een snapshot te maken en die over te zetten naar de nieuwe pool? Dus eerst met zfs snapshot -r data@moving en daarna zfs send -R sourcepool@moving | zfs receive -F [nieuwepool]? Of kan dat niet, omdat ik maar 1 data pool heb?
Of zijn de raidz1-0 en raidz1-1 de pools? Het is voor mij even geleden wat ook alweer precies een pool is.
[ Voor 5% gewijzigd door CH4OS op 08-07-2021 19:41 ]
Ik ben ook niet echt van de terminologie, maar wat ik er uit op maak is dat je één pool hebt, genaamd data. Deze pool bestaat vervolgens uit 2 vdevs met uhm "virtuele" schijven, zijnde raidz1-0 en raidz1-1, echter durf ik niet te zeggen of deze "gekoppeld" zijn via mirroring (beide slaan hetzelfde op) of striping (data wordt gedeeld). En deze beide vdevs bestaan dan weer uit andere vdeva bestaande de fysieke schijven (sd*).:
Ik zit even mezelf weer in te lezen in ZFS, maar eerst even een situatieschetsje:
Dit is mijn huidige pool. Vier van deze disks zijn 2TB groot, de andere 4 zijn 4TB groot. De disks van 2TB wil ik allemaal gaan vervangen voor v van 14TB groot. Dit zijn nog te shucken WD Elements, maar ik wil eerst even weten hoe ik de beoogde migratie het beste kan aanpakken. Is er een manier waarop ik (nu weet ik even niet exact welke raidz1 pool ik moet hebben) een van deze pools kan migreren naar de nieuw aan te maken?pool: data state: ONLINE scan: scrub repaired 0B in 10:06:57 with 0 errors on Sun Jun 13 10:30:59 2021 config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 sdb ONLINE 0 0 0 sdd ONLINE 0 0 0 sde ONLINE 0 0 0 sdc ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 sdh ONLINE 0 0 0 sdf ONLINE 0 0 0 sdi ONLINE 0 0 0 sdg ONLINE 0 0 0 errors: No known data errors
Kan ik dit het beste aanpakken door een snapshot te maken en die over te zetten naar de nieuwe pool? Dus eerst met zfs snapshot -r data@moving en daarna zfs send -R sourcepool@moving | zfs receive -F [nieuwepool]? Of kan dat niet, omdat ik maar 1 data pool heb?
Of zijn de raidz1-0 en raidz1-1 de pools? Het is voor mij even geleden wat ook alweer precies een pool is.
V.w.b. migratie naar een nieuwe pool. Ja, je zou dan een snapshot kunnen maken en met send & receive over zetten. Waarbij je on principe de keuze hebt of je alleen dat ene snapshot over zet of ook alle eventueel tussenliggende snapshots. Maar daar zou je met de manual uit moeten kunnen komen (en kan ook niet heel veel mis mee gaan, behalve naar de verkeerde pool schrijven).
Ik heb momenteel in 1 pool: 4x2TB + 4x4TB. De 4x2TB wil ik vervangen voor de 4x14TB. De 4x14TB wil ik dus in dezelfde pool hebben, uiteindelijk. Lijkt me dat ik eerst de data moet overzetten en daarna de pool pas kan uitbreiden?
Bedankt voor de hulp zover, ook van @RobertMe!
[ Voor 22% gewijzigd door CH4OS op 08-07-2021 20:14 ]
Mijn aanname was dus dat je een nieuwe pool wou maken, vervolgens de oude schijven eruit trekken, en klaar (/nieuwe pool renamen naar oude naam). Als je alleen de 4x2TB wilt vervangen door 4x14TB onder dezelfde pool en dan dus de 4x4TB behouden dan moet je zoals @CurlyMo al aangeeft inderdaad de schijven een voor een zfs replacen
RAID-5 (RAID-Z1), waarin maar 1 disk mag falen, wordt met grotere disks al ongeveer 10 jaar lang door iedereen afgeraden sinds die disks beschikbaar zijn.
Waarom? Een resilver/rebuild van de pool met grotere disks duurt zolang, dat de kans dat nog een disk faalt tijdens de resilver statistisch niet meer insignificant is. Wanneer een tweede disk faalt, dan ben je al je data in die pool kwijt.
Een van de aller grootste problemen met SMR disks in een RAID is dat een resilver nog vele malen langer duurt dan met normale PMR disks. (ZFS is (nog) niet "SMR aware".)
ZFS "ploetert" niet door. Bij ZFS krijgt je correcte data of geen data.
Bij een fout op een disk weet ZFS op welke disk de fout is en heeft daardoor de mogelijkheid om de juiste disk te corrigeren. Ben geen expert maar bij andere "standaard" hardware/software RAIDs, weet de software dat er een (parity) fout is maar weet niet op welke disk de fout is.
Waarom? Een resilver/rebuild van de pool met grotere disks duurt zolang, dat de kans dat nog een disk faalt tijdens de resilver statistisch niet meer insignificant is. Wanneer een tweede disk faalt, dan ben je al je data in die pool kwijt.
Een van de aller grootste problemen met SMR disks in een RAID is dat een resilver nog vele malen langer duurt dan met normale PMR disks. (ZFS is (nog) niet "SMR aware".)
ZFS "ploetert" niet door
. Bij ZFS krijgt je correcte data of geen data.Bij een fout op een disk weet ZFS op welke disk de fout is en heeft daardoor de mogelijkheid om de juiste disk te corrigeren. Ben geen expert maar bij andere "standaard" hardware/software RAIDs, weet de software dat er een (parity) fout is maar weet niet op welke disk de fout is.
No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.
Ik kreeg niet gelijk alle disks aan de praat en had een verjaardag tussendoor, dus heb vandaag hier even verder naar gekeken. De disks worden intussen herkend, ik kan de data dus gaan migreren. Ik draai ZFS-on-Linux op basis van Debian, maar het zfs commando heeft helaas geen replace parameter.
Na een zoekopdracht kom ik wel zpool replace tegen, maar doe ik zowel zpool list als zfs list, dan krijg ik respectievelijk de melding 'No pools available' en 'No datasets available'.
EDIT:
Ah, ik moest even importeren met zpool import.
Ik ga er daarom ook vanuit dat ik in plaats van zfs het commando zpool moet hebben. EDIT2:
De pool is echter niet te importeren, omdat de pool in een faulted state is. Zelfs een zpool import -f doet niets.
EDIT3:
Ik realiseer mij net dat ik die letterlijk disk voor disk moet doen, ook fysiek...
Had de stille hoop dat ik gewoon 1:1 de 4 2TB disks kon 'clonen' naar de 14TB disks... Ik ga dus even de machine weer uit zetten en 3 2TB disks los halen en 3 4TB disks terug in de machine...EDIT4:
Bummer, heb geen 4 SATA kabels thuis liggen, anders had ik nog een onboard controller met passthrough kunnen doorspelen naar de VM in kwestie, en daarop de rests van de disks kunnen aansluiten...
EDIT5: Resilvering loopt.
Thanks voor de hulp iedereen!
[ Voor 31% gewijzigd door CH4OS op 11-07-2021 19:29 ]
Klopt, die haal ik vaker door elkaar.:
[...]
Ah, ik moest even importeren met zpool import.
Sinds de 2 dagen regel reageer ik hier niet meer
Het hebben van verschillende binaries in 1 'applicatie' blijf ik toch wel wat ouderwets vinden.
Ik zou liever zien dat ze iets doen als en
Maar goed, dat zijn lastige changes
Ik zou liever zien dat ze iets doen als
zfs volume ...
zfs pool ...
Maar goed, dat zijn lastige changes
[ Voor 6% gewijzigd door FireDrunk op 12-07-2021 08:07 ]
Even niets...
Hij kan de data niet magisch bedenken natuurlijk, je moet het inderdaad doen met je te vervangen disks nog online.:
[...]
Ik kreeg niet gelijk alle disks aan de praat en had een verjaardag tussendoor, dus heb vandaag hier even verder naar gekeken. De disks worden intussen herkend, ik kan de data dus gaan migreren. Ik draai ZFS-on-Linux op basis van Debian, maar het zfs commando heeft helaas geen replace parameter.
Na een zoekopdracht kom ik wel zpool replace tegen, maar doe ik zowel zpool list als zfs list, dan krijg ik respectievelijk de melding 'No pools available' en 'No datasets available'.
EDIT:
Ah, ik moest even importeren met zpool import.
EDIT2:
De pool is echter niet te importeren, omdat de pool in een faulted state is. Zelfs een zpool import -f doet niets.
EDIT3:
Ik realiseer mij net dat ik die letterlijk disk voor disk moet doen, ook fysiek...
EDIT4:
Bummer, heb geen 4 SATA kabels thuis liggen, anders had ik nog een onboard controller met passthrough kunnen doorspelen naar de VM in kwestie, en daarop de rests van de disks kunnen aansluiten...
EDIT5: Resilvering loopt.
Het is ook beter om ze te vervangen terwijl de te vervangen disk nog online is.
Dus disk 1 2 3 4 in je array, disk 5 gaat disk 1 vervangen. Dan hou je best alle disks online en hang je disk 5 in je server en doe je de vervanging met 5 disks draaiende. Dan kan zfs zowel pariteit en de bestaande data gebruiken, maximale beschikbaarheid.
Maar dan moet je natuurlijk genoeg poorten en kabels hebben.
Dit is inderdaad een optie die ik overweeg, vanmorgen was de resilvering klaar (twee disks zijn sinds gisteravond resilvered), maar om een of andere reden zie ik de nieuwe 14TB disk niet terug in de pool, wel zie ik de oude nu als faulted wanneer ik de status van de pool opvraag. Vanavond maar even op mijn gemak bekijken. Misschien dan ook even vier SATA kabeltjes scoren. Dan kan ik alle disks aansluiten en gemakkelijker vervangen nadat ik de onboard Marvel controller ook heb doorgegeven aan de desbetreffende Debian VM.
Plaats eens een zpool status?:
[...]
Dit is inderdaad een optie die ik overweeg, vanmorgen was de resilvering klaar (twee disks zijn sinds gisteravond resilvered), maar om een of andere reden zie ik de nieuwe 14TB disk niet terug in de pool, wel zie ik de oude nu als faulted wanneer ik de status van de pool opvraag. Vanavond maar even op mijn gemak bekijken. Misschien dan ook even vier SATA kabeltjes scoren. Dan kan ik alle disks aansluiten en gemakkelijker vervangen nadat ik de onboard Marvel controller ook heb doorgegeven aan de desbetreffende Debian VM.
Verder zie je pas de nieuwe ruimte als alle schijven zijn vervangen door grotere varianten.
Sinds de 2 dagen regel reageer ik hier niet meer
Ik ben op het moment aan het werk en heb geen remote access (ook staat de machine in kwestie momenteel uit). Ik zal op zijn vroegst vanavond antwoord kunnen geven op de vraag.
Ik denk dat je even rustig moet doen en stoppen, want als je een succesvolle replace hebt gedaan dan mag er niks meer in FAULTED staan. Ik raad je aan om hier even zpool status te posten zoals @CurlyMo zegt, je machine even niet uitzetten/rebooten in de tussentijd en van daaruit verder kijken.:
[...]
Dit is inderdaad een optie die ik overweeg, vanmorgen was de resilvering klaar (twee disks zijn sinds gisteravond resilvered), maar om een of andere reden zie ik de nieuwe 14TB disk niet terug in de pool, wel zie ik de oude nu als faulted wanneer ik de status van de pool opvraag. Vanavond maar even op mijn gemak bekijken. Misschien dan ook even vier SATA kabeltjes scoren. Dan kan ik alle disks aansluiten en gemakkelijker vervangen nadat ik de onboard Marvel controller ook heb doorgegeven aan de desbetreffende Debian VM.
@HyperBart en @CurlyMo ik heb hier de output van zpool status
De error betreft een permanent error op een bestand in de pool.
SDC is trouwens in dit overzicht de eerste disk van 14TB. Ik kan eventueel de 2TB ervoor terug doen en kijken hoe de status dan is? Morgen krijg ik trouwens ook een SATA kabel, dus dan kan ik met alle disks aanwezig de replace doen.
pool: data
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: resilvered 2.96M in 00:03:54 with 1 errors on Mon Jul 12 17:56:41 2021
config:
NAME STATE READ WRITE CKSUM
data DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
sdd ONLINE 0 0 1
sdc ONLINE 0 0 1
13984520045058853556 FAULTED 0 0 0 was /dev/sde1
sdb ONLINE 0 0 1
raidz1-1 ONLINE 0 0 0
sdh ONLINE 0 0 0
sdg ONLINE 0 0 0
sdi ONLINE 0 0 0
sdf ONLINE 0 0 0
SDC is trouwens in dit overzicht de eerste disk van 14TB.
Ik kan eventueel de 2TB ervoor terug doen en kijken hoe de status dan is? Morgen krijg ik trouwens ook een SATA kabel, dus dan kan ik met alle disks aanwezig de replace doen.
[ Voor 10% gewijzigd door CH4OS op 12-07-2021 18:24 ]