Het grote ZFS topic

[FireDrunk]

Dat issue was toch al opgelost met de sequential scrub & resilver feature van ZFS 0.8?
Mijn scrubs gaan een stuk sneller sinds die upgrade.

[P5ycho]

Dat is waar.
De rest van je array moet wel snel genoeg die data aan kunnen leveren natuurlijk. Niet elk systeem staat te idlen als de TV+Kodi uit staat

Ik worstel ook nog wat met de voordelen van distributed spares, hoewel het logisch is om een spare dan maar aan het werk te zetten heb ik het altijd logischer gevonden om dan ook maar meteen die spare in te zetten voor parity. Blijkbaar zijn er situaties waar de extra parity zoveel trammelant geeft bij een resilver dat distributed spares beter werken.

Dit is nog minder insteressant dan special allocation class vdevs imho.

[FireDrunk]

Jup, dat was precies wat ik dacht. Niet een super interessante feature.

Ik zie vooral uit naar online RAIDZ expansion, die feature is nu in zijn "af, maar nog niet goed genoeg getest" fase.

[Xantis]

FireDrunk schreef op dinsdag 23 februari 2021 @ 11:23:
Jup, dat was precies wat ik dacht. Niet een super interessante feature.

Ik zie vooral uit naar online RAIDZ expansion, die feature is nu in zijn "af, maar nog niet goed genoeg getest" fase.

Zo precies, hier zie ik ook heel erg naar uit. Dit maakt het plannen van een pool uitbreiding veel makkelijker voor de gemiddelde huis-tuin-en-keuken gebruiker. Kan niet wachten m'n bestaande pool uit te kunnen uit te breiden als deze feature af is. Voor de bedrijfsmatige gebruiker zal dit niet veel brengen, daar schuift men waarschijnlijk gewoon een xU bakkie bij

[P5ycho]

Dat zou ik ook nog wel eens nodig kunnen hebben in de toekomst. raidz1 met 5x1TB 2.5" is een goede keus geweest voor mijn toepassing, maar doordat 2.5" disks alleen nog in SMR te krijgen zijn is het upgradepad niet zo geweldig. 5x 2.5" disks zie ik dan weer niet zitten vanwege het energieverbruik.

Op zich is een zfs send/receive ook zo gebeurd natuurlijk, dus ik zit er niet meteen om te springen ofzo.

[Q]

FireDrunk schreef op maandag 22 februari 2021 @ 18:05:
[...]

Ja, een poos geleden. Het lijkt een soort shared parity over meerdere vdev's heen. Ik vond het een vaag begrip, en het leek mij niet heel nuttig voor thuisgebruikers.

Ik ben er inmiddels verder in gedoken, ik vond het wel interessant.

Wat ik begrijp is dat ZFS met wijde vdevs of vdevs met heel veel disks serieuze problemen heeft met resilver performance, tot op een niveau dat het eigenlijk niet meer bruikbaar is.

Ik snap heel goed dat veel storage partijen wijde vdevs wil: storage space efficiency.

Maar daar komen we dus meteen op het punt. Met minder dan 20 disks in een vdev heb je niets aan dRAID.
Het is duidelijk niet voor de doorsnee consument nee.

Die distributed spare is wel heel leuk, want die maakt dus die rebuilds heel snel. Je restored redundancy vlot. Maar de rebuild van de vervangen schijf duurt waarschijnlijk evengoed nog wel lang.

Helaas lijkt het kern probleem bij ZFS dat die hele data veiligheid door checksums vanwege de implementaties eigenlijk ook een risico vormt: trage rebuilds. Ergens proef ik wel wat ironie.

Overigens is het concept van de distributed spare al 20 jaar een main-stream ding in enterprise storage, maar dat is meer terzijde.

Wat ik zelf heel frappant vind is dat dRAID vdevs gewoon identiek redundant zijn aan een enkele RAIDZ(2|3) maar dan met meer schijven.

Een 90-disk RAIDZ3 is blijkbaar prima acceptabel qua redundancy... Waarschijnlijk door de snelle rebuild performance. Tradeoffs, dat is wel duidelijk.

Er zitten nog meer haken en ogen aan dRAID als je naar de child vdevs of raid groups kijkt. Meer performance gaat ten koste van storage efficiency, ik vind het maar een rare feature.

Serieus, als ik vanuit een bedrijfssituatie veel storage capaciteit zou willen hebben, dan zou ik eerder voor Ceph gaan, dat schaalt misschien nog wel beter ook.

---

Uitbreidbare vdevs zou ZFS een no-brainer maken voor leuke thuis NAS setups, maar dat is drie jaar na aankondiging dus nog steeds niet af. Net als dRAID zelf trouwens...

[ Voor 7% gewijzigd door Q op 23-02-2021 17:55 ]

[Thralas]

FireDrunk schreef op dinsdag 23 februari 2021 @ 10:42:
Dat issue was toch al opgelost met de sequential scrub & resilver feature van ZFS 0.8?
Mijn scrubs gaan een stuk sneller sinds die upgrade.

Ja en nee.

Dat wat in 0.8 zat was een soort zo-sequentiëel-mogelijke scrub/resilver, maar nog niet puur lineair zoals md dat doet. Dat zit pas in 2.0, en geldt alleen voor het rebuilden van mirrors. En dat laatste is helemaal gunstig voor SMR.

Zie ook Thralas in "Het grote ZFS topic"

[P5ycho]

Q schreef op dinsdag 23 februari 2021 @ 17:51:
[...]
Uitbreidbare vdevs zou ZFS een no-brainer maken voor leuke thuis NAS setups, maar dat is drie jaar na aankondiging dus nog steeds niet af. Net als dRAID zelf trouwens...

Draid zit geld van Intel en HPE achter, dat maakt het verschil...

[Q]

P5ycho schreef op dinsdag 23 februari 2021 @ 22:31:
[...]

Draid zit geld van Intel en HPE achter, dat maakt het verschil...

Ja, precies en dat heeft al met al ook een jaar of drie geduurd en nog steeds niet af. Niet dat je graag bugs wilt in een FS ofzo maar dit is wel extreem. En de documentatie van dRAID vind ik als gebruiker helemaal niet helder.

[Freeaqingme]

Q schreef op dinsdag 23 februari 2021 @ 23:25:
[...]


Ja, precies en dat heeft al met al ook een jaar of drie geduurd en nog steeds niet af. Niet dat je graag bugs wilt in een FS ofzo maar dit is wel extreem. En de documentatie van dRAID vind ik als gebruiker helemaal niet helder.

Hoezo is 3 jaar extreem? Ik volg zo af en toe een beetje de monthly meeting van ZFS devs op youtube, en ik krijg de indruk dat er 1 engineer van HPE aan werkt. Enerzijds zal die ook zo af en toe op vakantie gaan en her en der wat vrije tijd willen. Anderzijds moest er voor draid ook gewoon nog een hoop bestaande code gerefactored worden. Als je dan ook nog eens bedenkt dat de standaarden hoog gehouden worden, dan vind ik 3 jaar niet heel lang.

Kijk bijvoorbeeld voor de grap eens hoe lang het duurt om Bcachefs in mainline te krijgen (*kuch*of Btrfs stabiel*kuch*)...

[P5ycho]

Het enige dat boeit is dat alles robuust is. Ik werk al 10+ jaar met zfs en het is heel robuust gebleken. Als ik nog 5 jaar moet wachten voordat deze feature er is, prima. Je ziet wat er gebeurt met een filesystem dat dat niveau niet kan halen omdat het met de verkeerde beweegredenen opgezet is... Dat bloedt gewoon dood.
Ik wacht graag nog 3 jaar op een convenience feature als dat betekent dat de boel stabiel is en blijft.

[Sando]

Ik ben gewoon een hele pool kwijt met 2x2 mirrors, omdat er twee schijven tegelijk stuk gingen.

Het waren twee van dezelfde mirror. Gelukkig heb ik backups van de hele pool, maar nu is het wel de tijd om even na te denken hoe ik de pool opnieuw ga bouwen.

Ik heb zelf thuis een RaidZ1 met 3 schijven die draait al een jaar of 6. Iedereen en zijn moeder vertelde me dat ik dat niet moest doen, dat ik niet greedy moest zijn, en dat ik gewoon mirrors moet gebruiken. Dus dat deed ik 3 jaar terug op een andere locatie, en dat is nu dus een total loss.

Het herstellen van de pool is niet zonder moeite; nieuwe schijven kopen, badblocks er overheen, 3 uur rijden naar de locatie, oude schijven ophalen naar backup locatie, pool seeden, dan weer terug om te plaatsen, dus liever voorkom je dat.

Dus nu zit ik erg te twijfelen. Was dit heel erg dumb luck en moet ik gewoon weer 2 mirrors bouwen? Of gebeurt het wel vaker, en kan ik beter naar RaidZ2 overstappen? Bij Z2 heb ik de zelfde redundancy, maar dan had ik dit scenario wél overleefd.

De aanzienlijke drawback is natuurlijk dat je bij 2x2 mirrors bijna 4x de read-performance hebt, en bij z2 slechts 1x. Write performance is ongeveer het zelfde, rond de 2x.

Daarbij hangt het natuurlijk af van de processor, want z2 is niet gratis. De pool hangt aan een AMD 2700u. Volgens mij is dat wel okay.

---

Gratis tip voor wie nog twijfelt: Je mirror is niet heilig. Zorg dat je backups hebt!

[Q]

Sando schreef op woensdag 24 februari 2021 @ 12:11:
Ik ben gewoon een hele pool kwijt met 2x2 mirrors, omdat er twee schijven tegelijk stuk gingen.

Het waren twee van dezelfde mirror. Gelukkig heb ik backups van de hele pool, maar nu is het wel de tijd om even na te denken hoe ik de pool opnieuw ga bouwen.

Ik heb zelf thuis een RaidZ1 met 3 schijven die draait al een jaar of 6. Iedereen en zijn moeder vertelde me dat ik dat niet moest doen, dat ik niet greedy moest zijn, en dat ik gewoon mirrors moet gebruiken. Dus dat deed ik 3 jaar terug op een andere locatie, en dat is nu dus een total loss.

Het herstellen van de pool is niet zonder moeite; nieuwe schijven kopen, badblocks er overheen, 3 uur rijden naar de locatie, oude schijven ophalen naar backup locatie, pool seeden, dan weer terug om te plaatsen, dus liever voorkom je dat.

Dus nu zit ik erg te twijfelen. Was dit heel erg dumb luck en moet ik gewoon weer 2 mirrors bouwen? Of gebeurt het wel vaker, en kan ik beter naar RaidZ2 overstappen? Bij Z2 heb ik de zelfde redundancy, maar dan had ik dit scenario wél overleefd.

De aanzienlijke drawback is natuurlijk dat je bij 2x2 mirrors bijna 4x de read-performance hebt, en bij z2 slechts 1x. Write performance is ongeveer het zelfde, rond de 2x.

Daarbij hangt het natuurlijk af van de processor, want z2 is niet gratis. De pool hangt aan een AMD 2700u. Volgens mij is dat wel okay.

---

Gratis tip voor wie nog twijfelt: Je mirror is niet heilig. Zorg dat je backups hebt!

Je RAIDZ(1) pool was net zo hard verloren geweest bij een double-drive-failure. Als je dit risico wilt mitigeren dan is RAIDZ2 de enige optie.

Dit hele mirrors verhaal vind ik een onoprecht en slecht advies.

Het houdt totaal geen rekening met de werkelijke behoeftes van mensen. Het is vooral een artikel dat over de beperkingen van ZFS heen moet plamuren.

Niet dat dit alles je gered zou hebben, maar ik denk dat de meeste thuis gebruiker NAS bouwers gewoon het beste uit zijn met RAIDZ(2).

P.S. hoe regelmatig draaide je Scrubs en kreeg jij output van die scrubs in de mail?

[Sando]

Q schreef op woensdag 24 februari 2021 @ 12:43:

Je RAIDZ(1) pool was net zo hard verloren geweest bij een double-drive-failure. Als je dit risico wilt mitigeren dan is RAIDZ2 de enige optie.

Dat klopt wel. Daarom denk ik ook aan Z2 nu. Die opmerking over Z1 was meer om aan te geven: Die "don't be greedy, use mirrors" instelling is ook niet heilig.

Dus nu zit ik te dubben tussen Z2 en weer 2x2 mirrors.

P.S. hoe regelmatig draaide je Scrubs en kreeg jij output van die scrubs in de mail?

Eén keer per maand. Altijd 0 errors, op één keer na, toen had hij 64 kb hersteld.

De pool (server) is een week (bewust) offline geweest in verband met wat werkzaamheden. Niks schokkends (letterlijk), maar ik ga haast vermoeden dat er toch iets een klap heeft gekregen, al dan niet een elektrische. Want het is wel een vreemd verhaal.

Overigens, ik kan er nu niet bij want alles is oflfine, maar ik weet niet zeker of de schijven ook echt stuk stuk zijn. Zpool gaf aan dat beide schijven (en dus de hele pool) FAULTED zijn met de melding: "Destroy and re-create the pool from a backup source."

Deze melding heb ik nog nooit gezien, dus ik ging er meteen van uit dat die schijven niet meer te vertrouwen zijn, en dat ik dus de backup moet terugzetten op nieuwe schijven.

[Q]

Sando schreef op woensdag 24 februari 2021 @ 13:14:
[...]


Dat klopt wel. Daarom denk ik ook aan Z2 nu. Die opmerking over Z1 was meer om aan te geven: Die "don't be greedy, use mirrors" instelling is ook niet heilig.

Dus nu zit ik te dubben tussen Z2 en weer 2x2 mirrors.


[...]

Eén keer per maand. Altijd 0 errors, op één keer na, toen had hij 64 kb hersteld.

De pool (server) is een week (bewust) offline geweest in verband met wat werkzaamheden. Niks schokkends (letterlijk), maar ik ga haast vermoeden dat er toch iets een klap heeft gekregen, al dan niet een elektrische. Want het is wel een vreemd verhaal.

Overigens, ik kan er nu niet bij want alles is oflfine, maar ik weet niet zeker of de schijven ook echt stuk stuk zijn. Zpool gaf aan dat beide schijven (en dus de hele pool) FAULTED zijn met de melding: "Destroy and re-create the pool from a backup source."

Deze melding heb ik nog nooit gezien, dus ik ging er meteen van uit dat die schijven niet meer te vertrouwen zijn, en dat ik dus de backup moet terugzetten op nieuwe schijven.

Ik denk dat het verstandig is om even de uitgebreide SMART waarden van de schijven uit te lezen. Ik vraag me af wat er dan werkelijk aan de hand is.

Even specifiek kijken naar deze SMART waarden (dit is waar Backblaze naar kijkt):

SMART 5: Reallocated_Sector_Count.
SMART 187: Reported_Uncorrectable_Errors.
SMART 188: Command_Timeout.
SMART 197: Current_Pending_Sector_Count.
SMART 198: Offline_Uncorrectable.

[Q]

Freeaqingme schreef op woensdag 24 februari 2021 @ 00:57:
Hoezo is 3 jaar extreem?

Omdat zowel hardware RAID, enpterprise storage als MDADM RAID dit al 30+ jaar online capacity expansion ondersteund.

Als je dan ook nog eens bedenkt dat de standaarden hoog gehouden worden, dan vind ik 3 jaar niet heel lang.

Kijk bijvoorbeeld voor de grap eens hoe lang het duurt om Bcachefs in mainline te krijgen (*kuch*of Btrfs stabiel*kuch*)...

Oh, vertel mij wat maar vanuit een gebruikersperspectief is geen van de oplossingen ideaal.

ZFS heeft last van trage rebuilds, zeker met RAIDZ(x) en kan niet worden uitgebreid zonder de ZFS tax te betalen. BTRFS lijkt een soepzooi waar ook geen serieuze vorderingen worden gemaakt.

Maar fair enough: ZFS is nooit ever bedoeld of ontworpen voor 'thuis gebruikers' dus misschien is het unfair om ZFS daar op af te dingen.

Maar dit topic is denk ik 100% voor thuisgebruikers die toch met ZFS spelen en in die context denk ik dat de trage vorderingen gewoon erg jammer zijn.

Natuurlijk is betrouwbaarheid belangrijker, en het is dus een tradeoff. Maar die tradeoff is niet zo clear-cut met name omdat ook het risico voor de thuis gebruiker voor wat betreft silent data corruptie gewoon niet zo groot is.

Nu is dit topic specifiek voor ZFS dus wie hier post heeft zijn/haar keuze gemaakt maar persoonlijk - als ZFS gebruiker - sta ik vanuit het perspectief van de thuisgebruiker erg ambivalent tegenover ZFS.

[Sando]

Q schreef op woensdag 24 februari 2021 @ 13:40:
[...]


Ik denk dat het verstandig is om even de uitgebreide SMART waarden van de schijven uit te lezen. Ik vraag me af wat er dan werkelijk aan de hand is.

Even specifiek kijken naar deze SMART waarden (dit is waar Backblaze naar kijkt):

SMART 5: Reallocated_Sector_Count.
SMART 187: Reported_Uncorrectable_Errors.
SMART 188: Command_Timeout.
SMART 197: Current_Pending_Sector_Count.
SMART 198: Offline_Uncorrectable.

Bedankt voor het delen van de indicators. Ik zal eens kijken als ik op locatie ben. (Het is nog steeds offline)

[Thralas]

Q schreef op woensdag 24 februari 2021 @ 12:43:
Het houdt totaal geen rekening met de werkelijke behoeftes van mensen. Het is vooral een artikel dat over de beperkingen van ZFS heen moet plamuren.

Daar ga je ook een beetje te snel. Ik denk dat er voor beide wat te zeggen valt. Striped mirrors kun je uitbreiden en hebben tenminste niet zo'n ontzettend tragische IOPS rating.

In dit specifieke geval: het zou me verbazen als er werkelijk twee disks helemaal dood zijn. Zou naast SMART ook eens heel aandachtig naar de kernel logs staren om te zien wat er precies is voorgevallen.

Wat bad sectors links en rechts sure, maar een disk die helemaal dood is is vrij uniek. Laat staan twee tegelijk.

[Q]

Thralas schreef op woensdag 24 februari 2021 @ 19:37:
[...]


Daar ga je ook een beetje te snel. Ik denk dat er voor beide wat te zeggen valt. Striped mirrors kun je uitbreiden en hebben tenminste niet zo'n ontzettend tragische IOPS rating.

Random IOPs performance is denk ik niet iets wat voor de meeste NAS bouwers belangrijk is. Bovendien gebruik je daar tegenwoordig toch SSDs voor.

Met een array van 8 schijven betaal je met mirrors ten opzichte van RAIDZ2 zomaar 2 schijven extra = 300+ euro voor wat? Meer risico? (RAIDZ2 kan te allen tijde 2 disk failures aan, mirrors niet altijd en met name de schijf die niet mag falen is het drukste bij een rebuild).

Zo'n artikel dat dan maar een kort-door-de-bocht uitspraak doet dat iedereen maar aan de mirror moet: dat is gewoon in mijn ogen geen fair advies. Dat is voor veel mensen niet in hun voordeel.

Het is misschien in bepaald zicht op de persoon spelen, maar zo bedoel ik het niet: jrs-s.net is van Jim Salter, een (goede) schrijver op Ars Technica. Hij heeft ook een op ZFS gebaseerd product wat hij verkoopt, dus hij heeft er belang bij om ZFS te promoten en nadelen te bagataliseren. Niet dat hij op enige wijze te kwader trouw is, maar we zijn hopelijk allemaal bekend met bias.

In dit specifieke geval: het zou me verbazen als er werkelijk twee disks helemaal dood zijn. Zou naast SMART ook eens heel aandachtig naar de kernel logs staren om te zien wat er precies is voorgevallen.

Wat bad sectors links en rechts sure, maar een disk die helemaal dood is is vrij uniek. Laat staan twee tegelijk.

Mee eens, het kan maar het is wel wat merkwaardig. Maar ik weet nog niet precies wat die 'werkzaamheden' precies inhouden.

[ Voor 24% gewijzigd door Q op 25-02-2021 00:42 ]

[GioStyle]

Ik heb een bepaalde situatie en zoek daarvoor bevestiging.

Ik heb een zpool van 1 nvme waarop mijn belangrijke documenten/media op staan. Deze pool wordt via smb aan het netwerk aangeboden. Als intern een bitje omvalt, dan kan ZFS deze herkennen, klopt dat? Maar omdat ik geen redudantie heb, kan ZFS deze niet herstellen. Echter kan ik zien welke bestand is beschadigd en deze herstellen door middel van gemaakte backups?

[CurlyMo]

@GioStyle Klopt

[willemw12]

@GioStyle: Tenzij metadata beschadigd raakt. Mijn ervaring is dat een scrub dat niet altijd herstelt. En de fout zelf lokaliseren kan moeilijk of onmogelijk zijn.

[Brahiewahiewa]

GioStyle schreef op donderdag 25 februari 2021 @ 10:33:
... Als intern een bitje omvalt...

Waarom zou er intern een bitje omvallen?

[RobertMe]

Brahiewahiewa schreef op donderdag 25 februari 2021 @ 12:08:
[...]

Waarom zou er intern een bitje omvallen?

Fout met werkgeheugen of zo (waarvoor je dus ECC zou kunnen gebruiken), fout in SSD ("bad sector" idee). Er zullen best wel dingen zijn waarbij het mis kan gaan. Het is niet waarschijnlijk, maar het kan natuurlijk wel.

@GioStyle hoe past de smb opmerking in je vraag? Want als het bitje omvalt in smb of zo dan gaat ZFS dat natuurlijk niet zien. Als het bitje omvalt tijdens transport zal ZFS dat niet zien en slaat die gewoon het verkeerde bitje op.

Als bij lezen, of scrub, een bitje omgevallen blijkt te zijn ziet die dat uiteraard wel. Omdat dan de opgeslagen checksum niet meer overeen komt met de huidige checksum over de data.

[P5ycho]

GioStyle schreef op donderdag 25 februari 2021 @ 10:33:
Ik heb een bepaalde situatie en zoek daarvoor bevestiging.

Ik heb een zpool van 1 nvme waarop mijn belangrijke documenten/media op staan. Deze pool wordt via smb aan het netwerk aangeboden. Als intern een bitje omvalt, dan kan ZFS deze herkennen, klopt dat? Maar omdat ik geen redudantie heb, kan ZFS deze niet herstellen. Echter kan ik zien welke bestand is beschadigd en deze herstellen door middel van gemaakte backups?

Met copies=2 kun je wel herstellen. elke file wordt in tweevoud opgeslagen op die manier. Dit is per filesystem in te stellen.

[GioStyle]

RobertMe schreef op donderdag 25 februari 2021 @ 13:35:
[...]

Fout met werkgeheugen of zo (waarvoor je dus ECC zou kunnen gebruiken), fout in SSD ("bad sector" idee). Er zullen best wel dingen zijn waarbij het mis kan gaan. Het is niet waarschijnlijk, maar het kan natuurlijk wel.

@GioStyle hoe past de smb opmerking in je vraag? Want als het bitje omvalt in smb of zo dan gaat ZFS dat natuurlijk niet zien. Als het bitje omvalt tijdens transport zal ZFS dat niet zien en slaat die gewoon het verkeerde bitje op.

Als bij lezen, of scrub, een bitje omgevallen blijkt te zijn ziet die dat uiteraard wel. Omdat dan de opgeslagen checksum niet meer overeen komt met de huidige checksum over de data.

Ik ben me er van bewust dat ik als ik bijvoorbeeld een document vanaf de zpool open op mijn laptop, bewerk en opsla op de zpool dat er onderweg corruptie kan plaatsvinden. Hier gaat ZFS niet mee helpen, dat snap ik.

Ik heb nu 1TB nvme opslag in een zpool. Ik dacht als ik er nu 3 in raidz1 doe, dat ik dan extra beschermd bent. Echter nu ik er goed over nadenk verhoogt het alleen maar mijn uptime. Ik kan beter in mijn backup server een andere zpool van 1TB aanmaken en daar backups gaan plaatsen door middel van ZFS send and receive.

Ik wil mijn kennis in ZFS verdiepen, zodat ik belangrijke data veilig kan stellen, maar ook terug kan plaatsen.

[Sando]

Q schreef op woensdag 24 februari 2021 @ 12:43:
[...]

Als je dit risico wilt mitigeren dan is RAIDZ2 de enige optie.

Een "portable" ZFS-pool die ik maakte om de backup naar de locatie te brengen in plaats van andersom (klinkt wat luxe, maar daarna wil ik hem toch thuis gebruiken) geeft een hoop write- en checksum-fouten als ik USB Attached SCSI gebruik, maar niet als ik SATA gebruik.

Dacht eerst dat het aan RAIDZ2 lag, maar Mirror doet het ook. Ik wilde eigenlijk uitgebreider reageren, maar ik vermoed dat het niet aan ZFS ligt, enkel dat ZFS het probleem inzichtelijk maakt. Dus heb ik de uitgebreide informatie maar in een nieuw hardwaretopic geplaatst: DAS: fouten over USB 3.1 maar niet over SATA

Iemand ervaring met UAS en dit eerder gezien?

[ Voor 21% gewijzigd door Sando op 25-02-2021 17:58 ]

[Sando]

Even in het Engels zodat ik kan crossposten op github.
Edit: Nevermind. Ik heb de pool gedestroyed om het met rsync te doen.

---

I am trying to upgrade an old compiled from source ZFS 0.7.0-133_g35df0bb55 release candidate to the latest stable version, and rebuild the related dataset called pool.

These are the steps I planned on taking.

1. Create new dataset backup on temporary storage.
2. ZFS send old pool to backup
   • a) send ENCRYPTED=NO datasets first (majority of data)
   • b) send ENCRYPTED=YES datasets using --raw or -w
3. Upgrade ZFS, destroy and recreate pool with new version.
4. Mount backup as read-only
5. rsync backup to pool
6. destroy backup

The problem starts with 2b: sending encrypted datasets. I had already made the main backup pool. This is how I transfered the encrypted datasets:

code:

for F in data data/www data/footage data/foley data/projects; do \
  zfs create -o mountpoint=/mnt/backup/$F backup/$F
  zfs send --raw pool/$F | pv | zfs receive -u -F backup/$F
done

The encrypted datasets show up as unencrypted on the destination, and cannot be mounted. Something clearly went wrong. So I want to destroy them, and try again with rsync. However, I cannot remove them:

code:

# zfs destroy -f backup/data/www
cannot destroy 'backup/data/www': filesystem has children
use '-r' to destroy the following datasets:
backup/data/www@--head--

[h1]zfs destroy -rf backup/data/www[/h1]

^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C

The command hangs indefinitely (although this is a mini dataset which should be done in under a minute)

I would like to destroy all the encrypted datasets and try again by manually using rsync in stead. If I have to destroy the whole pool, I wil loose many terabytes of already copied unencrypted data, and it will set me back two days.

Is it possible to recursively destroy backup/data and keep the backup itself alive?

Edit: Nevermind. Ik heb de pool gedestroyed om het met rsync te doen.

[d3vlin]

Thralas schreef op maandag 15 februari 2021 @ 09:10:
Sure, maar L2ARC is ook de minst interessante use case. De special vdev cachet ddt en metadata. Dat laatste is het voor mij al absoluut waard in een disk array, dan is een find tenminste wel snel.

Als ik die slides zie vraag ik me ook af waarom men het zwaartepunt lijkt te leggen bij het hebben van genoeg memory. Als die slides (nog) kloppen dan is er altijd sprake van veel I/O overhead, ook als de DDT in memory leeft.

Anyhow, zou het even testen met wat special vdevs (of dedup als je SSDs heel klein zijn). Daarvoor zul je helaas wel de pool opnieuw moeten schrijven vrees ik.

Zonder dedup is de schrijfsneldheid op de Z3 pool van 12x14TB circa 750 MB/s. Met 30% daarvan gevuld (met dedup aan) is dat circa 100 MB/s. Inderdaad circa de eerder genoemde 7x performance hit. Vervelender zijn de write throttles, een soort zaagtandbeweging van 100 MB/s terug naar 1 MB/s of soms nog lager en weer terug. Met 256GB ipv 64GB RAM (en aanpassen zfs_arc_max zodat het ook gebruikt wordt... ) zijn de dalen een stuk minder diep (10-20 MB/s), maar nog steeds aanwezig. RAM lijkt dus wel invloed hierop te hebben, maar de uiteindelijke bottleneck is volgens mij gewoon de I/O van de DDT naar de schijven.

Nu ook een dedup vdev toegevoegd van 2 NVMe 1TB SSDs in mirror en de writes blijven redelijk constant op 750MB/s hangen, dus eigenlijk vergelijkbaar met de pool zonder dedup. Dat is wel met nog een vrijwel lege pool, dus even kijken hoe zich dit verder ontwikkelt tijdens het vullen.

- De SSD's zijn nu bewust ingericht als dedup vdev ipv special vdev. Het klinkt wel aantrekkelijk om alle metadata op de SSD's op te slaan, maar hoe bereken ik de grootte van de metadata incl. DDT wanneer de pool bijna vol zal zijn? Je wil natuurlijk voorkomen dat de DDT overflow dan alsnog naar de 'spinning rust' gaat.
- Anderzijds is ook de endurance van de SSD's hierbij een overweging. Met alleen de DDT op de SSD's is het aantal transacties natuurlijk een stuk lager. We gebruiken nu 2x Corsair Force MP600 1TB in mirror. Die viel positief op vanwege het hoge TBW (1,8PB) en goede prestaties met mixed read/writes (ook in PCIe x3 mode wat de server gebruikt).
- Als laatste overweging (en ZFS kwam hier zelf ook mee bij het toevoegen van mirror dedup vdev aan de raidz3 vdev in de pool) is de reduncancy: "mismatched replication level: raidz and mirror vdevs with different redundancy, 3 vs. 1 (2-way) are present". Tsja. Dan zou je met raidz3 voor een 4-way mirror dedup vdev moeten gaan..

Nog een heel ander punt dat ik terloops tegenkwam. Met encrypted datasets werkt dedup alleen per dataset en dus niet over alle datasets met dedup aan. Iets om rekening mee te houden bij het kiezen van je layout als je dedup EN encryptie overweegt.

[ Voor 9% gewijzigd door d3vlin op 28-03-2021 19:59 ]

[d3vlin]

Nog een interessante caveat gevonden. Wanneer je een encrypted dataset met dedup uit met 'zfs send -w' (raw) recpliceert naar een andere pool met dedup aan dan wordt de data aan de ontvangende kant blijkbaar NIET gededupliceerd. Zonder de -w optie gebeurt dat wel, maar dan wordt de data dus decrypted verstuurd en aan de ontvanende kant gewoon opnieuw encrypted met de lokale sleutel die dan dus ook beschikbaar moet zijn. Jammer.

Het vervelende is dat de ontvangende pool wel gewoon dedup=on laat zien, maar dat de dedupratio 1.00x blijft.

Na wat testjes blijkt dat als ook de verzendende kant encrypted EN gededupliceerd is, verzenden met -w waarbij de ontvangende kant zonder sleutel encrypted opslaat EN dedupliceert blijkbaar wel kan.

De use case waarbij een dataset op een productieserver zonder dedup maar met encryptie draait en deze zonder sleutel (dus met -w) naar een backupserver repliceert en daar gededupliceerd op kan slaan lijkt dus niet mogelijk te zijn. Dat is jammer, want juist op een backupserver is de performance penalty van dedup minder relevant.

[ Voor 72% gewijzigd door d3vlin op 21-03-2021 09:09 ]

[iGadget]

ZFS noob vraagje - heb onlangs de consumer-SSD's in mijn 3 Proxmox nodes vervangen door server-class SSD's. De nieuwe SSD's hebben echter een andere capaciteit (480GB) dan de oude (respectievelijk 250GB op node 1, 1000GB op node 2 en 120GB op node 3).
Iedere node heeft één SSD met één rpool (standaard Proxmox ZFS installatie), de redundancy wordt geleverd door het cluster. Het gaat om een home/smb omgeving, dus voorlopig vind ik dat 'veilig' genoeg. Zodra het budget het toelaat ga ik investeren in extra disks om mirroring te kunnen gaan doen, maar dat is voor later (de server-class SSD's hebben het beschikbare budget voorlopig even opgesnoept).

Ik heb met Clonezilla voor node 1 en node 3 de beide disks gecloned en dat werkte prima. Alleen heb ik nu een boel ongebruikte diskspace, aangezien de partities (en rpools) nog de oude grootte hebben. Node 3 (met 1TB consumer SSD) moet nog, maar daarvoor moet ik (denk ik?) eerst de partitie verkleinen naar < 480GB.

Twee vragen hierover:
1. Hoe vergroot ik de partities op node 1 en 3? Volstaat een

code:

zpool set autoexpand=on rpool

of moet ik nog meer hier voor doen?
2. Hoe verklein ik de partitie / rpool op node 2?

[dcm360]

Mijn antwoord op vraag 2, die je blijkbaar op 2 plaatsen gesteld hebt:

dcm360 schreef op zondag 4 april 2021 @ 16:44:
Een zpool verkleinen gaat m niet worden. Wat wel kan, is een nieuwe (kleinere) zpool aanmaken, en dan met zfs send/receive de complete inhoud overzetten. Ruim niet zo makkelijk als klonen, maar het zou wel moeten werken.

[iGadget]

dcm360 schreef op zondag 4 april 2021 @ 16:53:
Mijn antwoord op vraag 2, die je blijkbaar op 2 plaatsen gesteld hebt:
[...]

Dank voor je antwoord. En klopt, nadat ik de vraag in het Proxmox-topic had gepost, kwam ik achter de code van vraag 1. En toen bedacht ik me dat het wellicht slimmer was om die dan meteen hier te posten omdat het niet Promox-specifiek is.

Wat betreft de code - klopt mijn verwachting / vrees dat deze alleen groen licht geeft voor de rpool om groter te worden naar behoefte, maar dat dit alleen gaat kunnen als de partitie zelf al groter is? Of gaat die gewoon automagisch mee?
In het eerste geval - hoe vergroot ik dan de partitie?

En nog een extra vraag - als ik zpool status doe op mijn Proxmox nodes, dan krijg ik terug:

code:

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.

Wat is wijsheid hier? Kan me voorstellen dat voor mijn use-case (single disk) veel features niet nodig zijn. Is het dan verstandiger om het zo te laten of kan zo'n "zpool upgrade" geen kwaad?

Update: Het vergroten van de partitie is gelukt. Zo heb ik het gedaan:
1. Boot vanaf een Live Ubuntu 20.04 USB
2. Start parted:

code:

$ sudo parted

3. Kijk welke partitie je moet hebben en hoeveel vrije ruimte er nog is:

code:

print free

In mijn geval was het partitie 3 met nog 230GB vrije ruimte over op de schijf.
De bestaande partitie is 250GB. Ik wil veiligheidshalve 17GB leeg laten voor een eventuele swap partitie op termijn (de machine heeft 16GB RAM). De nieuwe partitiegrootte moet dus worden 250+230-17 = 463GB
4. Vergroot partitie 3 tot 463GB:

code:

resizepart 3 463GB

5. Dubbel-check of het gelukt is:

code:

print free

6. Quit & reboot
De partitie is nu vergroot, maar de rpool heeft nog de oude grootte:

code:

# zpool list -v
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
rpool       232G   152G  80.2G        -      198G    34%    65%  1.00x    ONLINE  -
  sda3      232G   152G  80.2G        -      198G    34%  65.4%      -  ONLINE

7. Vergroot de rpool:

code:

# zpool online -e rpool sda3

8. Check of het gelukt is:

code:

# zpool list -v
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
rpool       430G   152G   278G        -         -    18%    35%  1.00x    ONLINE  -
  sda3      430G   152G   278G        -         -    18%  35.3%      -  ONLINE

Win!

[ Voor 66% gewijzigd door iGadget op 06-04-2021 10:46 . Reden: paritie vergroten is gelukt! ]

[haborym]

Ik ben nu een tijdje bezig met Proxmox en heb daar met 2 SSD's een mirror raid gemaakt met ZFS. Nu is 1 disk gegraded.
Om de disk te vervangen moet ik die eerst opsturen dan krijg ik direct een nieuwe. Kan ik de proxmox server down brengen, de disk eruit halen, en dan weer aanzetten tot de nieuwe disk er is?
Overal lees ik over het replace commando wat je moet uitvoeren na het plaatsen van de nieuwe maar ik vraag me dus af of ik tijdelijk kan doordraaien op 1 poot tot de nieuwe disk er is?

[iGadget]

haborym schreef op dinsdag 6 april 2021 @ 14:59:
Ik ben nu een tijdje bezig met Proxmox en heb daar met 2 SSD's een mirror raid gemaakt met ZFS. Nu is 1 disk gegraded.
Om de disk te vervangen moet ik die eerst opsturen dan krijg ik direct een nieuwe. Kan ik de proxmox server down brengen, de disk eruit halen, en dan weer aanzetten tot de nieuwe disk er is?
Overal lees ik over het replace commando wat je moet uitvoeren na het plaatsen van de nieuwe maar ik vraag me dus af of ik tijdelijk kan doordraaien op 1 poot tot de nieuwe disk er is?

Hoewel ik hier persoonlijk geen ervaring mee heb, lijkt het me te toch bijzonder sterk als je niet in 'degraded' toestand gewoon door kan draaien tot de nieuwe disk er is. Dat is toch het hele principe van RAID1 / mirroring?
Het enige risico dat je nu loopt is als die eerste disk ook uitvalt vóór dat je nieuwe schijf er is, je data kwijt kan raken en je server down gaat. Maar dat lijkt me logisch en ik neem aan dat je backups maakt.

Overigens wel een puntje van aandacht - soms is het zo dat een hele serie schijven een bepaald euvel heeft, dus als je meerdere schijven uit dezelfde batch in 1 array hebt zitten, dan is de kans groter dat als er één uit valt, er binnen afzienbare tijd nog 1 uitvalt. Heb dit al meerdere keren meegemaakt, al was dit met 'normale' schijven. Hoezeer dit probleem bij SSD's nog relevant is durf ik niet te zeggen.

[haborym]

iGadget schreef op dinsdag 6 april 2021 @ 15:23:
[...]

Hoewel ik hier persoonlijk geen ervaring mee heb, lijkt het me te toch bijzonder sterk als je niet in 'degraded' toestand gewoon door kan draaien tot de nieuwe disk er is. Dat is toch het hele principe van RAID1 / mirroring?
Het enige risico dat je nu loopt is als die eerste disk ook uitvalt vóór dat je nieuwe schijf er is, je data kwijt kan raken en je server down gaat. Maar dat lijkt me logisch en ik neem aan dat je backups maakt.

Overigens wel een puntje van aandacht - soms is het zo dat een hele serie schijven een bepaald euvel heeft, dus als je meerdere schijven uit dezelfde batch in 1 array hebt zitten, dan is de kans groter dat als er één uit valt, er binnen afzienbare tijd nog 1 uitvalt. Heb dit al meerdere keren meegemaakt, al was dit met 'normale' schijven. Hoezeer dit probleem bij SSD's nog relevant is durf ik niet te zeggen.

Ik had ook dat gevoel maar wilde het (als ZFS newbie) toch ff navragen. Heb de disk offline gebracht en vanavond ff eruit halen om te laten vervangen.! Thanks voor je snelle reactie.

[FutureCow]

Zijn er hier mensen die de overstap hebben gemaakt van grub2 naar systemd-boot. Deze laatste ondersteund als het goed is wel alle ZFS features waardoor een aparte boot-pool niet meer nodig is?

Ik probeer het nu eerst met nog een losse rpool en bpool

Eerst /boot/efi/loader/loader.conf aangemaakt:

code:

default debian
timeout 1
editor 1

Daarna:

code:

bootctl install --path=/boot/efi

en met behulp van dit script de bestanden op de juiste plek. Deze moet na elke kernel update uitgevoerd worden:

code:

#!/bin/sh
#
# This is a simple kernel hook to populate the systemd-boot entries
# whenever kernel images are added or removed.
#


# The disk containing the root partition; also see `sudo blkid`
root_disk="ZFS=rpool/ROOT/debian"

# The linux kernel arguments
flags=""

prog_name=`basename $0`
boot_dir="/boot"
sd_boot_dir="loader/entries"
sd_boot_path="$boot_dir/efi/$sd_boot_dir"
title=
prefix=
force=0
verbose=0


usage() {
    echo "$prog_name [OPTIONS]"
}

help() {
    usage
    echo
    echo "OPTIONS"
    echo "  -h          show this help page"
    echo "  -f          force overwrite"
    echo "  -v          make verbose"
}

while getopts hfv opt; do
    case "$opt" in
        h)  help
            exit 0;;
        f)  force=1;;
        v)  verbose=1;;
        \?)     # unknown flag
            usage >&2
            exit 1;;
    esac
done
shift `expr $OPTIND - 1`

if [ $# -ne 0 ]; then
    echo >&2 "No extra argument allowed"
    exit 1
fi


sd_boot_entry() {
    cat <<-EOF
    title   $title
    version $version
    linux   /$sd_boot_dir/vmlinuz-$version
    initrd  /$sd_boot_dir/initrd.img-$version
    options root=$root_disk $flags
    EOF
}


if [ ! -h "/dev/disk/by-uuid/${root_disk#UUID=}" ]; then
    echo >&2 "error: root disk '$root_disk' not found"
    exit 1
fi

if [ ! -d "$sd_boot_path" ]; then
    echo >&2 "error: directory '$sd_boot_path' not found"
    exit 1
fi

if [ ! -f /etc/machine-id ]; then
    echo >&2 "error: machine id file '/etc/machine-id' not found"
    exit 1
fi
prefix="`cat /etc/machine-id`-v"

if [ -f /etc/os-release ]; then
    title=`sed -ne '/^PRETTY_NAME=/s/.*"\(.*\)".*/\1/p' /etc/os-release`
else
    title=Debian
fi


echo "Updating Systemd boot entries"

# Copy images from the Debian install directory to the EFI partition
find "$boot_dir" -maxdepth 1 -type f -name '*.dpkg-tmp' -prune -o -name 'vmlinuz-*' -exec cp -u {} "$sd_boot_path" \;
find "$boot_dir" -maxdepth 1 -type f -name '*.dpkg-tmp' -prune -o -name 'initrd.img-*' -exec cp -u {} "$sd_boot_path" \;

# Remove files from the EFI if they are missing from the Debian install directory
find "$sd_boot_path" -maxdepth 1 -type f -name 'vmlinuz-*' | while read i; do
    kernel="$boot_dir/`basename $i`"
    if [ ! -f "$kernel" ]; then
        rm -f "$i"
    fi
done
find "$sd_boot_path" -maxdepth 1 -type f -name 'initrd.img-*' | while read i; do
    initrd="$boot_dir/`basename $i`"
    if [ ! -f "$initrd" ]; then
        rm -f "$i"
    fi
done

# Remove the conf file
find "$sd_boot_path" -maxdepth 1 -type f -name "$prefix*.conf" | sort -Vr | while read i; do
    version=`basename $i | sed -e "s/$prefix//; s/.conf$//"`
    kernel="$sd_boot_path/vmlinuz-$version"
    initrd="$sd_boot_path/initrd.img-$version"
    if [ ! -f "$kernel" -o ! -f "$initrd" ]; then
        echo "Removing kernel v$version"
        rm -f "$i" "$kernel" "$initrd"
    fi
done

# Add new kernel entries
find "$boot_dir" -maxdepth 1 -type f -name '*.dpkg-tmp' -prune -o -name 'vmlinuz-*' -print | sort -Vr | while read i; do
    version=`basename $i | sed -e 's/vmlinuz-//'`
    initrd="$boot_dir/initrd.img-$version"
    file="$sd_boot_path/$prefix$version.conf"
    echo "Found kernel `basename $i`"
    if [ ! -f "$initrd" ]; then
        echo "Ignoring $i"
    elif [ $force -eq 1 -o ! -f "$file" ]; then
        echo "Adding $file"
        sd_boot_entry "$version" > "$file"
        cp -v $i "$initrd" "$sd_boot_path"
    fi
done

Deze bestanden zijn dan aanwezig:

code:

/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/loader/entries/bc5f952e67104a19a224a48e3318140c-v5.10.0-5-amd64.conf
/boot/efi/loader/entries/initrd.img-5.10.0-5-amd64
/boot/efi/loader/entries/vmlinuz-5.10.0-5-amd64

in de bc5f952e67104a19a224a48e3318140c-v5.10.0-5-amd64.conf:

code:

title   Debian GNU/Linux bullseye/sid
version 5.10.0-5-amd64
linux   /loader/entries/vmlinuz-5.10.0-5-amd64
initrd  /loader/entries/initrd.img-5.10.0-5-amd64
options root=ZFS=rpool/ROOT/debian

Zou dit genoeg moeten zijn?

[zierbeek]

Hi all,

ik maakte net een truenas install aan met een ubuntu vm om de -arr's en plex te draaien.
Ik zou graag men media hdd mountne op de vm. Hoe gaat dat juist in zen werk?

[CurlyMo]

zierbeek schreef op vrijdag 9 april 2021 @ 11:06:
Hi all,

ik maakte net een truenas install aan met een ubuntu vm om de -arr's en plex te draaien.
Ik zou graag men media hdd mountne op de vm. Hoe gaat dat juist in zen werk?

Ik zou het in een zen topic vragen i.p.v. een ZFS topic.

[Thralas]

FutureCow schreef op donderdag 8 april 2021 @ 09:06:
Zou dit genoeg moeten zijn?

Zoek je nu alleen bevestiging? Ik neem aan dat je het ook gewoon geprobeerd hebt? Werkt het?

Zo te zien parkeert je oplossing de kernel/initramfs op je ESP. Natuurlijk werkt het dan, omdat ZFS dan pas aan de orde komt nadat de kernel is gestart. Dat is ook hoe ik hier boot, en dat werkt inderdaad prima.

[matty___]

Volgende week komt FreeBSD 13 uit met native OpenZFS 2.0 ondersteuning. Net nog een virtual test gedaan en de binary upgrade van 12 naar 13 gaat gewoon zonder issues.

[Giesber]

zierbeek schreef op vrijdag 9 april 2021 @ 11:06:
Hi all,

ik maakte net een truenas install aan met een ubuntu vm om de -arr's en plex te draaien.
Ik zou graag men media hdd mountne op de vm. Hoe gaat dat juist in zen werk?

Ik wil straks wel eens zien hoe ik dat geregeld heb (gaat nu even niet), maar het zou zomaar kunnen dat ik dat met een NFS share geregeld heb.

[nero355]

matty___ schreef op vrijdag 9 april 2021 @ 15:27:
Volgende week komt FreeBSD 13 uit met native OpenZFS 2.0 ondersteuning. Net nog een virtual test gedaan en de binary upgrade van 12 naar 13 gaat gewoon zonder issues.

Wat zijn eigenlijk de gevolgen voor FreeBSD na deze verandering

Ik weet dat deze aankondiging lang geleden werd gedaan : FireDrunk in "Het grote ZFS topic"
Maar daarna heb ik er weinig van meegekregen...

Dus hoe zal dit uiteindelijk uitpakken qua ondersteuning en functionaliteit ?!


Waarom ik dat vraag :
- Die aparte FreeBSD DIY ZFS NAS moet er nog steeds een keer komen.
- Ik heb onlangs mijn grote HTPC van Windows 7 Pro naar Debian 11 Testing omgegooid en daar zit ik met een nare dependencies situatie, want ZoL heeft een bepaalde Kernel nodig (DKMS en zo...) dus die moet redelijk nieuw zijn, echter ook weer niet te nieuw, want dan zegt mijn Nvidia driver dat die ermee kapt!
Het werkt nu wel, maar toch... beetje een tricky situatie!

Krijg je dit soort gezeur nu ook bij FreeBSD
Niet dat ik daarin een Nvidia videokaart ga proppen, maar ik vroeg het me gewoon af

[zierbeek]

Giesber schreef op vrijdag 9 april 2021 @ 17:51:
[...]

Ik wil straks wel eens zien hoe ik dat geregeld heb (gaat nu even niet), maar het zou zomaar kunnen dat ik dat met een NFS share geregeld heb.

Het is me gelukt, gewoon de etc/fstab juist invullen . Zonder problemen

[matty___]

nero355 schreef op vrijdag 9 april 2021 @ 18:59:
[...]

Wat zijn eigenlijk de gevolgen voor FreeBSD na deze verandering

Ik weet dat deze aankondiging lang geleden werd gedaan : FireDrunk in "Het grote ZFS topic"
Maar daarna heb ik er weinig van meegekregen...

Dus hoe zal dit uiteindelijk uitpakken qua ondersteuning en functionaliteit ?!


Waarom ik dat vraag :
- Die aparte FreeBSD DIY ZFS NAS moet er nog steeds een keer komen.
- Ik heb onlangs mijn grote HTPC van Windows 7 Pro naar Debian 11 Testing omgegooid en daar zit ik met een nare dependencies situatie, want ZoL heeft een bepaalde Kernel nodig (DKMS en zo...) dus die moet redelijk nieuw zijn, echter ook weer niet te nieuw, want dan zegt mijn Nvidia driver dat die ermee kapt!
Het werkt nu wel, maar toch... beetje een tricky situatie!

Krijg je dit soort gezeur nu ook bij FreeBSD
Niet dat ik daarin een Nvidia videokaart ga proppen, maar ik vroeg het me gewoon af

Als dan wordt de ondersteuning beter.

Je Nvidia gaat gewoon werken met de laatste driver en elke FreeBSD kernel (niet dat je daar veel versies in hebt)

[djmartain]

Ik ben bezig met een truenas server op te zetten om te migreren van een oude QNAP NAS.

Om de migratie zo pijnloos mogelijk te maken heb ik de datasize van mijn huidige QNAP gematched (4x3TB)

De truenas server heeft 8 diskslots en heeft nu dus 4x 3TB. Ik heb de ZFS vol nu ingesteld in RAIDZ1.

Van zodra alle data van de QNAP op de truenas staat, wil ik deze disks eruithalen en toevoegen aan mijn truenas voor 8 disk capaciteit.

Nu komt mijn vraag:

Welke RAIDZ neem ik best nadat de migratie is gebeurd? Beter 2x RAIDZ1? Of kan ik van de huidige RAIDZ1 op 4 disks migreren naar RAIDZ2 op 8 disks ZONDER een externe backup? Deze 8 disks is alles wat ik heb.

Ik ben nu geneigd om te gaan voor 2 pools gezien ik de initiele pool dan niet moet aanraken maar ik heb liever 1 pool en redudancy van 2 drives over de hele pool dan 2x 1 disk redudantie op elke pool.

Hoe pak ik dit het beste aan?

Thanks

[nero355]

djmartain schreef op zondag 11 april 2021 @ 12:30:
Hoe pak ik dit het beste aan?

Twee opties :

- VDEV aan je huidige Pool toevoegen waarin de rest van de HDD's zitten.
- Regel toch maar die Externe Storage als tijdelijke Backup en maak die 8 Disk RAIDZ2 aan

Andere opties zie ik niet echt in jouw situatie...

[ph0t0nix]

Het voordeel van een pool met 2 vdevs is dat je er ook je iops mee verdubbeld. Of je dat in de praktijk merkt is natuurlijk afhankelijk van wat je met je NAS wilt doen.

[vanaalten]

Afgelopen week een paar keer een stroomstoring gehad waarbij een machine (Debian 'stable' als OS) met ZFS-mirror onverwachts is uitgezet. Wekelijks wordt er een scrub gedaan met normaal gesproken nul fouten, maar afgelopen zondag:

code:

  pool: datapool
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
    attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
    using 'zpool clear' or replace the device with 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P
  scan: scrub repaired 1.25M in 10:32:08 with 0 errors on Sun Apr 11 03:35:19 2021
config:

    NAME        STATE     READ WRITE CKSUM
    datapool    ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb     ONLINE       3     8     0
        sdc     ONLINE       7 2.61K     0

errors: No known data errors

Advies uit bovenstaande opgevolgd: zpool clear en nog eens scrub, en nu hetzelfde report met iets andere getallen:

code:

        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb     ONLINE       8   132     0
            sdc     ONLINE       2 3.07K     1

Hierna ook maar een long selftest gedaan, maar voor zover ik kan beoordelen (zie vanaalten in "Check je SMART") is er niets aan de hand.

Kan ik nog op de een of andere manier de errors wegkrijgen zonder nieuwe schijven er aan te hangen?

[FireDrunk]

Blijven scrubben (en clearen), op een gegeven moment zouden de fouten moeten verdwijnen.

[vanaalten]

FireDrunk schreef op dinsdag 13 april 2021 @ 14:34:
Blijven scrubben (en clearen), op een gegeven moment zouden de fouten moeten verdwijnen.

@FireDrunk, hoe snel zou ik resultaat moeten zien?

Twaalf keer scrubben:

code:

scrub 1:
        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb     ONLINE       3     8     0
            sdc     ONLINE       7 2.61K     0
scrub 2:
            sdb     ONLINE       8   132     0
            sdc     ONLINE       2 3.07K     1
scrub 3:
            sdb     ONLINE       4   308     0
            sdc     ONLINE       3 1.93K     0
(scrub 4 ontbreekt)
scrub 5:
            sdb     ONLINE       0   287     0
            sdc     ONLINE       3 2.11K     0
scrub 6:
            sdb     ONLINE       0     0     0
            sdc     ONLINE       5 1.75K     0
scrub 7:
            sdb     ONLINE       0     4     0
            sdc     ONLINE       1 1.56K     0
scrub 8:
            sdb     ONLINE       0     0     0
            sdc     ONLINE       6 1.63K     0
scrub 9:
            sdb     ONLINE       0     0     0
            sdc     ONLINE       1 1.93K    23
scrub 10:
            sdb     ONLINE       3     8     0
            sdc     ONLINE      10 1.61K     0
scrub 11:
            sdb     ONLINE       0     0     0
            sdc     ONLINE       5 1.72K     0
scrub 12:
            sdb     ONLINE       2   594     0
            sdc     ONLINE       4 2.19K     0

Ik kan nog niet zeggen dat ik verbetering zie - het springt alle kanten op. Gewoon volhouden? SMART-status ziet er nog steeds normaal uit.

[nero355]

@vanaalten

Vergelijk eens je S.M.A.R.T. waardes van vóór de scrub(s) en ná de scrub(s) om te checken of je niet te maken hebt met een brakke kabels/controller situatie!

[vanaalten]

nero355 schreef op dinsdag 20 april 2021 @ 00:28:
@vanaalten

Vergelijk eens je S.M.A.R.T. waardes van vóór de scrub(s) en ná de scrub(s) om te checken of je niet te maken hebt met een brakke kabels/controller situatie!

Hmmm, ik had na die eerste 'foute' scrub aan long selftest laten doen en daar kwam niets vreemds uit. Op dit moment zie ik in 'smartctl -a /dev/sdc' nog steeds niets geks, maar nu weer een long selftest opgestart. Dagje afwachten en dan eens vergelijken.

[RobertMe]

vanaalten schreef op dinsdag 20 april 2021 @ 08:14:
[...]

Hmmm, ik had na die eerste 'foute' scrub aan long selftest laten doen en daar kwam niets vreemds uit. Op dit moment zie ik in 'smartctl -a /dev/sdc' nog steeds niets geks, maar nu weer een long selftest opgestart. Dagje afwachten en dan eens vergelijken.

Ik ben geen kenner, maar verwacht niet dat je met een selftest fouten in de communicatie gaat vinden, en dat is juist waar @nero355 naar verwijst. Ik vermoed namelijk dat een selftest puur de HDD "test", in de zin van bv de volledige disk lezen etc. Maar dat zal niet met de SATA controller babbelen buiten de communicatie over de resultaten. Terwijl als je een scrub doet wel elke gelezen byte over de lijn naar de controller gaat. Als de kabel dus brak is, bv, kan het voorkomen dat er fouten in de communicatie zijn, terwijl de HDD verder perfect werkt. En die communicatiefouten moet je volgens mij ook in SMART kunnen zijn (ik denk DMCA uncorrectable of zoiets dat dat is).

[FireDrunk]

vanaalten schreef op maandag 19 april 2021 @ 20:41:
[...]

@FireDrunk, hoe snel zou ik resultaat moeten zien?

Twaalf keer scrubben:

code:

scrub 1:
        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb     ONLINE       3     8     0
            sdc     ONLINE       7 2.61K     0
scrub 2:
            sdb     ONLINE       8   132     0
            sdc     ONLINE       2 3.07K     1
scrub 3:
            sdb     ONLINE       4   308     0
            sdc     ONLINE       3 1.93K     0
(scrub 4 ontbreekt)
scrub 5:
            sdb     ONLINE       0   287     0
            sdc     ONLINE       3 2.11K     0
scrub 6:
            sdb     ONLINE       0     0     0
            sdc     ONLINE       5 1.75K     0
scrub 7:
            sdb     ONLINE       0     4     0
            sdc     ONLINE       1 1.56K     0
scrub 8:
            sdb     ONLINE       0     0     0
            sdc     ONLINE       6 1.63K     0
scrub 9:
            sdb     ONLINE       0     0     0
            sdc     ONLINE       1 1.93K    23
scrub 10:
            sdb     ONLINE       3     8     0
            sdc     ONLINE      10 1.61K     0
scrub 11:
            sdb     ONLINE       0     0     0
            sdc     ONLINE       5 1.72K     0
scrub 12:
            sdb     ONLINE       2   594     0
            sdc     ONLINE       4 2.19K     0

Ik kan nog niet zeggen dat ik verbetering zie - het springt alle kanten op. Gewoon volhouden? SMART-status ziet er nog steeds normaal uit.

Dat klinkt niet goed, had je al een RAM test gedaan?

[vanaalten]

RobertMe schreef op dinsdag 20 april 2021 @ 09:27:
[...]

Ik ben geen kenner, maar verwacht niet dat je met een selftest fouten in de communicatie gaat vinden, en dat is juist waar @nero355 naar verwijst. Ik vermoed namelijk dat een selftest puur de HDD "test", in de zin van bv de volledige disk lezen etc. Maar dat zal niet met de SATA controller babbelen buiten de communicatie over de resultaten. Terwijl als je een scrub doet wel elke gelezen byte over de lijn naar de controller gaat. Als de kabel dus brak is, bv, kan het voorkomen dat er fouten in de communicatie zijn, terwijl de HDD verder perfect werkt. En die communicatiefouten moet je volgens mij ook in SMART kunnen zijn (ik denk DMCA uncorrectable of zoiets dat dat is).

Ah, ja, OK. Het is mij niet helemaal duidelijk hoe en wanneer de SMART-tabel die gerapporteerd wordt bijgewerkt wordt. Of dat continu is, of enkel na een korte of lange selftest, of sommige direct en andere na een selftest. Dus daarom die selftest opgestart.

En ja, ik kijk ook naar de tabel met resultaten, niet enkel het 'passed' woordje. En vooralsnog zie ik daar niets verontrustends voorbij komen.

Initieel, na scrub #1 op de schijf met meeste errors:

code:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   211   194   021    Pre-fail  Always       -       8450
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       3161
  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   093   093   000    Old_age   Always       -       5592
 10 Spin_Retry_Count        0x0032   100   100   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       -       90
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0032   174   174   000    Old_age   Always       -       78334
194 Temperature_Celsius     0x0022   124   098   000    Old_age   Always       -       28
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   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

En nu, na scrub #12 met ongoing long test:

code:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VAL                      UE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   202   194   021    Pre-fail  Always       -       8866
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       3173
  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   093   093   000    Old_age   Always       -       5724
 10 Spin_Retry_Count        0x0032   100   100   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       -       90
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0032   174   174   000    Old_age   Always       -       78373
194 Temperature_Celsius     0x0022   115   098   000    Old_age   Always       -       37
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   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

...lijkt mij niet verontrustend.

FireDrunk schreef op dinsdag 20 april 2021 @ 10:30:
Dat klinkt niet goed, had je al een RAM test gedaan?

Hmmm, nee. Juist doordat dit pas optrad na een onverwachte stroomstoring (veroorzaakt door iemand die wat enthousiast een groep in de groepenkast uitschakelde) had ik het idee dat het eerder een harddisk issue zou zijn. Ik kan na de smart-test eens een memory test uitvoeren, kijken of daar wat uit komt.

En ergens jeukt het wel, ik zou eigenlijk deze twee schijven eens willen leegmaken, opnieuw formatteren als ZFS mirror en een backup terugzetten om te kijken of dat het probleem oplost - maar dat klinkt als iets wat wel tegen de filosofie van ZFS in gaat.

[nero355]

vanaalten schreef op dinsdag 20 april 2021 @ 11:41:
En ergens jeukt het wel, ik zou eigenlijk deze twee schijven eens willen leegmaken, opnieuw formatteren als ZFS mirror en een backup terugzetten om te kijken of dat het probleem oplost - maar dat klinkt als iets wat wel tegen de filosofie van ZFS in gaat.

Als je dat toch overweegt denk dan ook eens aan het volgende :

Lang... laaaang geleden... heb ik een paar HDD's betrapt op een slechte actuator door de HDD's te benchmarken met downloads: HD Tune 2.54 en wat mij opviel is dat de lijn van links naar rechts heel erg digitaal eruit zag i.p.v. analoog : Meerdere rechthoekige dakjes/Pi achtige tekentjes die naast elkaar langzaam omlaag gaan op de manier dat je dat altijd ziet als resultaat zeg maar...

Ik zie net pas dat er nu ook andere versies zijn dus kijk maar effe wat het beste werkt op een hedendaags OS :
- downloads: HD Tune Pro 3.10
- downloads: HD Tune Pro 5.75

[Brahiewahiewa]

vanaalten schreef op dinsdag 20 april 2021 @ 11:41:
[...]
...

code:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VAL                      UE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   202   194   021    Pre-fail  Always       -       8866
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       3173
  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   093   093   000    Old_age   Always       -       5724
 10 Spin_Retry_Count        0x0032   100   100   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       -       90
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0032   174   174   000    Old_age   Always       -       78373
194 Temperature_Celsius     0x0022   115   098   000    Old_age   Always       -       37
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   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

...lijkt mij niet verontrustend.

Hmmz, misschien ongerelateerd maar de Load_Cycle_Count is wel verontrustend hoog.
Bij goeie disks kan die oplopen tot 300.000, sommigen beweren zelfs 500.000.
Bij een slechte disk kan het betekenen dat-ie nu al stuque is

[FireDrunk]

vanaalten schreef op dinsdag 20 april 2021 @ 11:41:
[...]

Hmmm, nee. Juist doordat dit pas optrad na een onverwachte stroomstoring (veroorzaakt door iemand die wat enthousiast een groep in de groepenkast uitschakelde) had ik het idee dat het eerder een harddisk issue zou zijn. Ik kan na de smart-test eens een memory test uitvoeren, kijken of daar wat uit komt.

En ergens jeukt het wel, ik zou eigenlijk deze twee schijven eens willen leegmaken, opnieuw formatteren als ZFS mirror en een backup terugzetten om te kijken of dat het probleem oplost - maar dat klinkt als iets wat wel tegen de filosofie van ZFS in gaat.

Dat zou kunnen, maar dan heb je twee schijven tegelijk stuk, kan uiteraard, maar is onwaarschijnlijk(er).
Dat uitsluiten is complex, en al helemaal als SMART geen enkele aanwijzing geeft.

Ik zou vooral even RAM testen.

Als je RAM echt stuk is, is scrubben zelfs onverstandig, dat kan het geheel verder stuk maken (in theorie).

[vanaalten]

FireDrunk schreef op woensdag 21 april 2021 @ 07:49:
[...]


Dat zou kunnen, maar dan heb je twee schijven tegelijk stuk, kan uiteraard, maar is onwaarschijnlijk(er).
Dat uitsluiten is complex, en al helemaal als SMART geen enkele aanwijzing geeft.

Ik zou vooral even RAM testen.

Als je RAM echt stuk is, is scrubben zelfs onverstandig, dat kan het geheel verder stuk maken (in theorie).

Ram testen ga ik doen, maar moet ik even wat praktische problemen voor oplossen... (machine heeft DVI-D output en ik heb enkel een DVI-I converter naar HDMI beschikbaar...arghh...). Moet ik even wat dingen voor omzetten.

[FireDrunk]

Als je een oude GPU hebt, kan je die er even tijdelijk in prikken? Voor de memtest maakt dat natuurlijk weinig uit.

[vanaalten]

FireDrunk schreef op woensdag 21 april 2021 @ 09:13:
Als je een oude GPU hebt, kan je die er even tijdelijk in prikken? Voor de memtest maakt dat natuurlijk weinig uit.

Nee, ik doe nooit iets met games, dus losse GPU's niet in huis. En met de verhuizing vorig jaar flink opgeruimd, dus zelfs geen ouderwetse VGA kabel meer liggen.

Uiteindelijk met wat omgooien van dingen toch de boel kunnen aansluiten, dus ondertussen al drie uur aan het testen (Passmark MemTest86 V9.0); vooralsnog geen errors gevonden. Laat 'm voorlopig nog zeker tot morgenochtend lopen - wie weet vindt 'ie nog iets.

[Thralas]

Heb je al naar de (historische) kernel logs gekeken?

READ en WRITE zijn namelijk I/O errors, die zou je daar terug moeten zien. Bij bad RAM zou ik enkel checksum errors verwachten.

Zie ook `zpool events (-v)` voor een verbose listing van de errors. Dat geeft o.a. ook de I/O status code terug (mocht de kernel niets te vertellen hebben).

[FireDrunk]

@Thralas goed punt, daar had ik nog helemaal niet bij stil gestaan. Misschien is zijn controller wel aan het kwakkelen. Onwaarschijnlijk, maar in theorie kan het.

[vanaalten]

@Thralas goede suggestie.

Vannacht en gistermiddag dus memtest laten lopen - 16 uur, 16 passes, 0 errors.

Net even "grep error kern.log" gedaan:

code:

Apr 22 07:29:59 nas kernel: [  307.074827] print_req_error: I/O error, dev sdb, sector 10804545424
Apr 22 07:29:59 nas kernel: [  307.074836] zio pool=datapool vdev=/dev/sdb1 error=5 type=2 offset=5531926208512 size=49152 flags=40080c80
Apr 22 07:31:13 nas kernel: [  380.954521]          res 40/00:18:b0:31:00/00:00:70:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 07:31:14 nas kernel: [  381.668559] print_req_error: I/O error, dev sdb, sector 10468995528
Apr 22 07:31:14 nas kernel: [  381.668576] zio pool=datapool vdev=/dev/sdb1 error=5 type=2 offset=5360124661760 size=12288 flags=40080c80
Apr 22 07:37:57 nas kernel: [  784.709514]          res 40/00:80:20:de:3f/00:00:40:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 07:37:57 nas kernel: [  784.709543]          res 40/00:80:20:de:3f/00:00:40:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 07:37:57 nas kernel: [  784.709571]          res 40/00:80:20:de:3f/00:00:40:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 07:37:58 nas kernel: [  785.423531] print_req_error: I/O error, dev sdb, sector 9667862056
Apr 22 07:37:58 nas kernel: [  785.423548] zio pool=datapool vdev=/dev/sdb1 error=5 type=2 offset=4949944324096 size=4096 flags=180880
Apr 22 07:37:58 nas kernel: [  785.423585] print_req_error: I/O error, dev sdb, sector 9667862064
Apr 22 07:37:58 nas kernel: [  785.423594] zio pool=datapool vdev=/dev/sdb1 error=5 type=2 offset=4949944328192 size=8192 flags=40080c80
Apr 22 07:37:58 nas kernel: [  785.423621] print_req_error: I/O error, dev sdb, sector 9730898088
Apr 22 07:37:58 nas kernel: [  785.423629] zio pool=datapool vdev=/dev/sdb1 error=5 type=2 offset=4982218772480 size=16384 flags=40080c80
Apr 22 07:39:00 nas kernel: [  847.726244]          res 40/00:c0:70:45:00/00:00:70:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 07:39:00 nas kernel: [  847.726274]          res 40/00:c0:70:45:00/00:00:70:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 07:39:01 nas kernel: [  848.440488] print_req_error: I/O error, dev sdc, sector 10804570392
Apr 22 07:39:01 nas kernel: [  848.440505] zio pool=datapool vdev=/dev/sdc1 error=5 type=2 offset=5531938992128 size=4096 flags=180880
Apr 22 07:39:01 nas kernel: [  848.440543] print_req_error: I/O error, dev sdc, sector 10804570280
Apr 22 07:39:01 nas kernel: [  848.440552] zio pool=datapool vdev=/dev/sdc1 error=5 type=2 offset=5531938934784 size=8192 flags=40080c80

...lijkt behoorlijk niet OK. Dan lijkt het mij dat beide harde schijven een flinke opdonder hebben gekregen van het plotseling wegvallen van de stroom in huis. Bizar, want daarvoor gaf de wekelijkse scrub nul fouten...

Meh. Binnenkort dan maar eens proberen de schijven leeg te maken, formatteren of zo, wie weet verdwijnen de problemen dan weer, maar tussendoor alvast nieuwe schijven uitzoeken in de PriceWatch...

Edit: hmmm, kan natuurlijk ook zijn dat de controller en niet de schijven een probleem heeft.

[FireDrunk]

@vanaalten
Ho, wat @Thralas terecht zegt, is dat het misschien niet je RAM is, en als SMART goed is, kan het best eens je controller zijn.

Als je toevallig nog een ander moederbord / cpu combinatie hebt liggen, zou je eens kunnen kijken of je de pool met een live linux distro met ZFS wel kan importeren (en gebruiken) zonder errors.

Als dat wel goed gaat, is het hoogstwaarschijnlijk je moederbord, en niet de schijven zelf.

[vanaalten]

FireDrunk schreef op donderdag 22 april 2021 @ 07:48:
@vanaalten
Ho, wat @Thralas terecht zegt, is dat het misschien niet je RAM is, en als SMART goed is, kan het best eens je controller zijn.

Als je toevallig nog een ander moederbord / cpu combinatie hebt liggen, zou je eens kunnen kijken of je de pool met een live linux distro met ZFS wel kan importeren (en gebruiken) zonder errors.

Als dat wel goed gaat, is het hoogstwaarschijnlijk je moederbord, en niet de schijven zelf.

Goed punt. Zat zelf te denken om de harde schijven over te zetten naar andere SATA aansluitingen. Intel had, jaren geleden, eens een designfout waardoor de SATA output zelf kapot kon gaan na wat tijd - mijn moederbord is wel van na die tijd, maar wie weet. Maar een tweede systeem om mee te testen heb ik ook wel.

[Thralas]

vanaalten schreef op donderdag 22 april 2021 @ 07:45:
Net even "grep error kern.log" gedaan:

Kun je de context er nog even bij zoeken? Er staat een hoop boven en onder dat óók nog bij de error hoort, ook al staat daar niet het woordje 'error' in.

Edit: hmmm, kan natuurlijk ook zijn dat de controller en niet de schijven een probleem heeft.

Zoiets. Zie ook: The Analysis of Drive Issues

Er staat o.a. nog nuttige informatie in de SError die nu net buiten boord valt (en misschien wel andere zaken). Op een andere controller testen is geen verkeerd idee.

[vanaalten]

Thralas schreef op donderdag 22 april 2021 @ 09:14:
[...]


Kun je de context er nog even bij zoeken? Er staat een hoop boven en onder dat óók nog bij de error hoort, ook al staat daar niet het woordje 'error' in.

Klein stukje uit de log:

code:

Apr 22 07:28:51 nas kernel: [  238.702848] ata3.00: exception Emask 0x50 SAct 0x10040 SErr 0x4cc0801 action 0xe frozen
Apr 22 07:28:51 nas kernel: [  238.702860] ata3.00: irq_stat 0x04000040, connection status changed
Apr 22 07:28:51 nas kernel: [  238.702867] ata3: SError: { RecovData HostInt CommWake 10B8B Handshk LinkSeq DevExch }
Apr 22 07:28:51 nas kernel: [  238.702874] ata3.00: failed command: WRITE FPDMA QUEUED
Apr 22 07:28:51 nas kernel: [  238.702885] ata3.00: cmd 61/10:30:b8:a9:3f/00:00:40:02:00/40 tag 6 ncq dma 8192 out
Apr 22 07:28:51 nas kernel: [  238.702885]          res 40/00:78:58:29:00/00:00:28:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 07:28:51 nas kernel: [  238.702894] ata3.00: status: { DRDY }
Apr 22 07:28:51 nas kernel: [  238.702899] ata3.00: failed command: WRITE FPDMA QUEUED
Apr 22 07:28:51 nas kernel: [  238.702909] ata3.00: cmd 61/08:80:d8:a9:3f/00:00:40:02:00/40 tag 16 ncq dma 4096 out
Apr 22 07:28:51 nas kernel: [  238.702909]          res 40/00:78:58:29:00/00:00:28:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 07:28:51 nas kernel: [  238.702918] ata3.00: status: { DRDY }
Apr 22 07:28:51 nas kernel: [  238.702926] ata3: hard resetting link
Apr 22 07:28:52 nas kernel: [  239.414862] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Apr 22 07:28:52 nas kernel: [  239.416818] ata3.00: configured for UDMA/133
Apr 22 07:28:52 nas kernel: [  239.416914] sd 2:0:0:0: [sdc] tag#6 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 22 07:28:52 nas kernel: [  239.416919] sd 2:0:0:0: [sdc] tag#6 Sense Key : Illegal Request [current]
Apr 22 07:28:52 nas kernel: [  239.416924] sd 2:0:0:0: [sdc] tag#6 Add. Sense: Unaligned write command
Apr 22 07:28:52 nas kernel: [  239.416930] sd 2:0:0:0: [sdc] tag#6 CDB: Write(16) 8a 00 00 00 00 02 40 3f a9 b8 00 00 00 10 00 00
Apr 22 07:28:52 nas kernel: [  239.416933] print_req_error: I/O error, dev sdc, sector 9667848632
Apr 22 07:28:52 nas kernel: [  239.416949] zio pool=datapool vdev=/dev/sdc1 error=5 type=2 offset=4949937451008 size=8192 flags=40080c80
Apr 22 07:28:52 nas kernel: [  239.416972] sd 2:0:0:0: [sdc] tag#16 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 22 07:28:52 nas kernel: [  239.416975] sd 2:0:0:0: [sdc] tag#16 Sense Key : Illegal Request [current]
Apr 22 07:28:52 nas kernel: [  239.416979] sd 2:0:0:0: [sdc] tag#16 Add. Sense: Unaligned write command
Apr 22 07:28:52 nas kernel: [  239.416983] sd 2:0:0:0: [sdc] tag#16 CDB: Write(16) 8a 00 00 00 00 02 40 3f a9 d8 00 00 00 08 00 00
Apr 22 07:28:52 nas kernel: [  239.416985] print_req_error: I/O error, dev sdc, sector 9667848664
Apr 22 07:28:52 nas kernel: [  239.416994] zio pool=datapool vdev=/dev/sdc1 error=5 type=2 offset=4949937467392 size=4096 flags=180880
Apr 22 07:28:52 nas kernel: [  239.417007] ata3: EH complete

Er staat o.a. nog nuttige informatie in de SError die nu net buiten boord valt (en misschien wel andere zaken). Op een andere controller testen is geen verkeerd idee.

Ik had toevallig on een oude ongebruikte machine staan en daar heb ik de drie schijven (twee van de pool en de boot-SSD met het OS) op aangesloten. Daarmee nu een scrub opgestart - en helaas zie ik dezelfde errors weer in de kernel log verschijnen.

Ofwel, het lijkt er toch meer op dat de harde schijven - beide tegelijk - niet meer OK zijn.

[ph0t0nix]

Heb je de disks in de ongebruikte machine aangesloten met andere SATA kabels, of met de kabels uit de eerste machine?

[Thralas]

vanaalten schreef op donderdag 22 april 2021 @ 21:00:
[...]
Klein stukje uit de log:

code:

Apr 22 07:28:51 nas kernel: [  238.702860] ata3.00: irq_stat 0x04000040, connection status changed
Apr 22 07:28:51 nas kernel: [  238.702867] ata3: SError: { RecovData HostInt CommWake 10B8B Handshk LinkSeq DevExch }

Dat zijn de twee meest relevante regels denk ik.

Volgens Google serveert de AHCI controller die interrupt bit als het device een COMINIT stuurt, ie. een device initiated reset. De rest lijkt me een gevolg van in-flight I/O dat gecancelled wordt (en de unaligned write errors zijn wel erg vreemd, maar blijkbaar gebeurt dat bij iedereen na een reset).

Daarmee nu een scrub opgestart - en helaas zie ik dezelfde errors weer in de kernel log verschijnen.

Exact hetzelfde? Laat ze anders voor de volledigheid nog even zien.

Ofwel, het lijkt er toch meer op dat de harde schijven - beide tegelijk - niet meer OK zijn.

Als het echt een hele andere machine is (SATA-kabels, PSU!) en de errors identiek zijn dan lijkt het daar wel op.

Wat je verder nog zou kunnen proberen is wat andere zaken die mensen lijken te helpen bij instabiele SATA links:

echo 1 > /sys/block/sda/device/queue_depth
echo max_performance > /sys/class/scsi_host/host*/link_power_management_policy

(NCQ resp link power saving disablen)

En de derde: SATA link naar 3Gb/s forceren (zie Google).

[vanaalten]

ph0t0nix schreef op donderdag 22 april 2021 @ 23:24:
Heb je de disks in de ongebruikte machine aangesloten met andere SATA kabels, of met de kabels uit de eerste machine?

Wel met dezelfde SATA en power cables.

Thralas schreef op vrijdag 23 april 2021 @ 00:21:
Exact hetzelfde? Laat ze anders voor de volledigheid nog even zien.

code:

Apr 22 18:41:05 nas kernel: [ 2103.563796] ata2.00: exception Emask 0x50 SAct 0x140000 SErr 0x4cc0801 action 0xe frozen
Apr 22 18:41:05 nas kernel: [ 2103.563864] ata2.00: irq_stat 0x04000040, connection status changed
Apr 22 18:41:05 nas kernel: [ 2103.563908] ata2: SError: { RecovData HostInt CommWake 10B8B Handshk LinkSeq DevExch }
Apr 22 18:41:05 nas kernel: [ 2103.563964] ata2.00: failed command: WRITE FPDMA QUEUED
Apr 22 18:41:05 nas kernel: [ 2103.564004] ata2.00: cmd 61/10:90:98:60:40/00:00:40:02:00/40 tag 18 ncq dma 8192 out
Apr 22 18:41:05 nas kernel: [ 2103.564004]          res 40/00:98:70:60:40/00:00:40:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 18:41:05 nas kernel: [ 2103.564101] ata2.00: status: { DRDY }
Apr 22 18:41:05 nas kernel: [ 2103.564128] ata2.00: failed command: WRITE FPDMA QUEUED
Apr 22 18:41:05 nas kernel: [ 2103.564167] ata2.00: cmd 61/10:a0:78:60:40/00:00:40:02:00/40 tag 20 ncq dma 8192 out
Apr 22 18:41:05 nas kernel: [ 2103.564167]          res 40/00:98:70:60:40/00:00:40:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 18:41:05 nas kernel: [ 2103.564264] ata2.00: status: { DRDY }
Apr 22 18:41:05 nas kernel: [ 2103.564293] ata2: hard resetting link
Apr 22 18:41:06 nas kernel: [ 2104.275755] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Apr 22 18:41:06 nas kernel: [ 2104.277184] ata2.00: configured for UDMA/133
Apr 22 18:41:06 nas kernel: [ 2104.277254] sd 1:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 22 18:41:06 nas kernel: [ 2104.277257] sd 1:0:0:0: [sdb] tag#18 Sense Key : Illegal Request [current]
Apr 22 18:41:06 nas kernel: [ 2104.277260] sd 1:0:0:0: [sdb] tag#18 Add. Sense: Unaligned write command
Apr 22 18:41:06 nas kernel: [ 2104.277264] sd 1:0:0:0: [sdb] tag#18 CDB: Write(16) 8a 00 00 00 00 02 40 40 60 98 00 00 00 10 00 00
Apr 22 18:41:06 nas kernel: [ 2104.277266] print_req_error: I/O error, dev sdb, sector 9667895448
Apr 22 18:41:06 nas kernel: [ 2104.277318] zio pool=datapool vdev=/dev/sdb1 error=5 type=2 offset=4949961420800 size=8192 flags=40080c80
Apr 22 18:41:06 nas kernel: [ 2104.277334] sd 1:0:0:0: [sdb] tag#20 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 22 18:41:06 nas kernel: [ 2104.277336] sd 1:0:0:0: [sdb] tag#20 Sense Key : Illegal Request [current]
Apr 22 18:41:06 nas kernel: [ 2104.277338] sd 1:0:0:0: [sdb] tag#20 Add. Sense: Unaligned write command
Apr 22 18:41:06 nas kernel: [ 2104.277340] sd 1:0:0:0: [sdb] tag#20 CDB: Write(16) 8a 00 00 00 00 02 40 40 60 78 00 00 00 10 00 00
Apr 22 18:41:06 nas kernel: [ 2104.277342] print_req_error: I/O error, dev sdb, sector 9667895416

...lijkt mij hetzelfde.

Als het echt een hele andere machine is (SATA-kabels, PSU!) en de errors identiek zijn dan lijkt het daar wel op.

Wel dezelfde SATA- en power kabels, maar andere PSU.

Wat je verder nog zou kunnen proberen is wat andere zaken die mensen lijken te helpen bij instabiele SATA links:

echo 1 > /sys/block/sda/device/queue_depth
echo max_performance > /sys/class/scsi_host/host*/link_power_management_policy

(NCQ resp link power saving disablen)

En de derde: SATA link naar 3Gb/s forceren (zie Google).

Maar... maar... dit alles heeft 6 jaar lang stabiel en probleemloos gewerkt, met wekelijks een ZFS scrub log met 0 errors! Dan krijg je toch niet ineens een instabiele link?

Maar, om dit alles maar weer wat complexer te maken:
Gisteren om 18:00 een scrub opgestart en toen dus wat errors in kern.log gezien. Het systeem is toen tot 23:54 doorgegaan met errors in de log te schrijven - en sindsdien niet meer.

En de status vanochtend zag er ook al een stuk beter uit:

code:

        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     2     0
            sdb     ONLINE       0    22     0

Ik snap er nu niets meer van. Net dus maar opnieuw een scrub opgestart. Tot nu toe geen errors in kern.log. Ofwel, is het dan toch de controller?! Waarom had ik dan toch bijna zes uur lang SATA errors in de log?

[CurlyMo]

vanaalten schreef op vrijdag 23 april 2021 @ 07:50:
[...]
Maar... maar... dit alles heeft 6 jaar lang stabiel en probleemloos gewerkt, met wekelijks een ZFS scrub log met 0 errors! Dan krijg je toch niet ineens een instabiele link?

Tsja, waarom heeft elektronica een eindige levensduur. Uiteindelijk komt er toch een moment dat er dingen kapot gaan. Of dat nu na 1 maand, 3 jaar, 6 jaar of 30 jaar is. Dat punt komt een keer.

[vanaalten]

CurlyMo schreef op vrijdag 23 april 2021 @ 08:56:
[...]

Tsja, waarom heeft elektronica een eindige levensduur. Uiteindelijk komt er toch een moment dat er dingen kapot gaan. Of dat nu na 1 maand, 3 jaar, 6 jaar of 30 jaar is. Dat punt komt een keer.

Dat is waar. Maar een instabiele link zie ik als een incompatibiliteit, iets wat vanaf het begin aanwezig is. Als het na 6 jaar optreedt, dan is dat geen incompatibiliteit maar het begin van kapot-gaande-hardware. Dan is de boel niet meer betrouwbaar, kan het morgen erger worden en moet je niet met lapmiddeltjes aan de gang als NCQ resp link power saving disablen of snelheid begrenzen.

[CurlyMo]

vanaalten schreef op vrijdag 23 april 2021 @ 09:47:
[...]

Dat is waar. Maar een instabiele link zie ik als een incompatibiliteit, iets wat vanaf het begin aanwezig is. Als het na 6 jaar optreedt, dan is dat geen incompatibiliteit maar het begin van kapot-gaande-hardware. Dan is de boel niet meer betrouwbaar, kan het morgen erger worden en moet je niet met lapmiddeltjes aan de gang als NCQ resp link power saving disablen of snelheid begrenzen.

Heb je in de tussentijd ook nooit geüpgraded? Kan zijn dat in kernel upgrades power saving features standaard zijn gemaakt, die je met dit soort instellingen weer terugdraait.

[AtlAntA]

vanaalten schreef op vrijdag 23 april 2021 @ 07:50:
[...]

Wel met dezelfde SATA en power cables.

[...]

code:

Apr 22 18:41:05 nas kernel: [ 2103.563796] ata2.00: exception Emask 0x50 SAct 0x140000 SErr 0x4cc0801 action 0xe frozen
Apr 22 18:41:05 nas kernel: [ 2103.563864] ata2.00: irq_stat 0x04000040, connection status changed
Apr 22 18:41:05 nas kernel: [ 2103.563908] ata2: SError: { RecovData HostInt CommWake 10B8B Handshk LinkSeq DevExch }
Apr 22 18:41:05 nas kernel: [ 2103.563964] ata2.00: failed command: WRITE FPDMA QUEUED
Apr 22 18:41:05 nas kernel: [ 2103.564004] ata2.00: cmd 61/10:90:98:60:40/00:00:40:02:00/40 tag 18 ncq dma 8192 out
Apr 22 18:41:05 nas kernel: [ 2103.564004]          res 40/00:98:70:60:40/00:00:40:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 18:41:05 nas kernel: [ 2103.564101] ata2.00: status: { DRDY }
Apr 22 18:41:05 nas kernel: [ 2103.564128] ata2.00: failed command: WRITE FPDMA QUEUED
Apr 22 18:41:05 nas kernel: [ 2103.564167] ata2.00: cmd 61/10:a0:78:60:40/00:00:40:02:00/40 tag 20 ncq dma 8192 out
Apr 22 18:41:05 nas kernel: [ 2103.564167]          res 40/00:98:70:60:40/00:00:40:02:00/40 Emask 0x50 (ATA bus error)
Apr 22 18:41:05 nas kernel: [ 2103.564264] ata2.00: status: { DRDY }
Apr 22 18:41:05 nas kernel: [ 2103.564293] ata2: hard resetting link
Apr 22 18:41:06 nas kernel: [ 2104.275755] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Apr 22 18:41:06 nas kernel: [ 2104.277184] ata2.00: configured for UDMA/133
Apr 22 18:41:06 nas kernel: [ 2104.277254] sd 1:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 22 18:41:06 nas kernel: [ 2104.277257] sd 1:0:0:0: [sdb] tag#18 Sense Key : Illegal Request [current]
Apr 22 18:41:06 nas kernel: [ 2104.277260] sd 1:0:0:0: [sdb] tag#18 Add. Sense: Unaligned write command
Apr 22 18:41:06 nas kernel: [ 2104.277264] sd 1:0:0:0: [sdb] tag#18 CDB: Write(16) 8a 00 00 00 00 02 40 40 60 98 00 00 00 10 00 00
Apr 22 18:41:06 nas kernel: [ 2104.277266] print_req_error: I/O error, dev sdb, sector 9667895448
Apr 22 18:41:06 nas kernel: [ 2104.277318] zio pool=datapool vdev=/dev/sdb1 error=5 type=2 offset=4949961420800 size=8192 flags=40080c80
Apr 22 18:41:06 nas kernel: [ 2104.277334] sd 1:0:0:0: [sdb] tag#20 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 22 18:41:06 nas kernel: [ 2104.277336] sd 1:0:0:0: [sdb] tag#20 Sense Key : Illegal Request [current]
Apr 22 18:41:06 nas kernel: [ 2104.277338] sd 1:0:0:0: [sdb] tag#20 Add. Sense: Unaligned write command
Apr 22 18:41:06 nas kernel: [ 2104.277340] sd 1:0:0:0: [sdb] tag#20 CDB: Write(16) 8a 00 00 00 00 02 40 40 60 78 00 00 00 10 00 00
Apr 22 18:41:06 nas kernel: [ 2104.277342] print_req_error: I/O error, dev sdb, sector 9667895416

...lijkt mij hetzelfde.

[...]

Wel dezelfde SATA- en power kabels, maar andere PSU.

[...]

Maar... maar... dit alles heeft 6 jaar lang stabiel en probleemloos gewerkt, met wekelijks een ZFS scrub log met 0 errors! Dan krijg je toch niet ineens een instabiele link?

Maar, om dit alles maar weer wat complexer te maken:
Gisteren om 18:00 een scrub opgestart en toen dus wat errors in kern.log gezien. Het systeem is toen tot 23:54 doorgegaan met errors in de log te schrijven - en sindsdien niet meer.

En de status vanochtend zag er ook al een stuk beter uit:

code:

        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     2     0
            sdb     ONLINE       0    22     0

Ik snap er nu niets meer van. Net dus maar opnieuw een scrub opgestart. Tot nu toe geen errors in kern.log. Ofwel, is het dan toch de controller?! Waarom had ik dan toch bijna zes uur lang SATA errors in de log?

Je hebt natuurlijk wel de SATA kabels opnieuw in en uit geplugd. Aangezien je de SATA kabels nog niet hebt uitgesloten zou ik het eerst daar zoeken. Ik heb ook al verschillende sata kabels moeten vervangen en ben er achter gekomen dat brakke kabels heel vaak gelijksoortige errors kunnen geven als stervende schijven. Dus het goedkoopste is om even de kabels uit te sluiten.

Edit: Vooral nu je nu geen errors krijgt begint het er steeds meer op te lijken dat de sata kabels de boosdoener zijn.

[Thralas]

CurlyMo schreef op vrijdag 23 april 2021 @ 09:49:
Heb je in de tussentijd ook nooit geüpgraded? Kan zijn dat in kernel upgrades power saving features standaard zijn gemaakt, die je met dit soort instellingen weer terugdraait.

Ja, dat is misschien wel een van de meest beruchte redenen waarom hardware die 'altijd prima werkte' dat ineens niet meer doet. Iets om in de gaten te houden als je na een onverwachte herstart ook een kernel upgrade meepakt.

vanaalten schreef op vrijdag 23 april 2021 @ 07:50:
Maar... maar... dit alles heeft 6 jaar lang stabiel en probleemloos gewerkt, met wekelijks een ZFS scrub log met 0 errors! Dan krijg je toch niet ineens een instabiele link?

Blijkbaar wel. Naast bovengenoemde is het wel handig als je een situatie weet te creeëren waar het wel weer even werkt.

Ik snap er nu niets meer van. Net dus maar opnieuw een scrub opgestart. Tot nu toe geen errors in kern.log. Ofwel, is het dan toch de controller?! Waarom had ik dan toch bijna zes uur lang SATA errors in de log?

Mja, dat maakt het inderdaad nog vreemder. Wat voor disks zijn het eigenlijk? Toch geen SMR hoop ik? Daar past zulk gedrag geloof ik wel een beetje bij..

[vanaalten]

Thralas schreef op vrijdag 23 april 2021 @ 10:49:
Ja, dat is misschien wel een van de meest beruchte redenen waarom hardware die 'altijd prima werkte' dat ineens niet meer doet. Iets om in de gaten te houden als je na een onverwachte herstart ook een kernel upgrade meepakt.


[...]


Blijkbaar wel. Naast bovengenoemde is het wel handig als je een situatie weet te creeëren waar het wel weer even werkt.

De laatste reboot en kernel-update was al enkele weken voor de stroomuitval, dus dat is niet het meest waarschijnlijke.

Mja, dat maakt het inderdaad nog vreemder. Wat voor disks zijn het eigenlijk? Toch geen SMR hoop ik? Daar past zulk gedrag geloof ik wel een beetje bij..

Deze:
pricewatch: WD Green HDD, 6TB
...waarbij ik niet snel zie of het SMR is of niet. WesternDigital heeft wel ooit een overzicht laten zien van welke drives wel of niet SMR hebben, maar de oude green serie werd daarbij niet genoemd. Ook met Google vind ik niet snel duidelijke resultaten. Ofwel, zou kunnen.

Hier ondertussen toch te vroeg gejuicht: na 4 uur scrub op 50% en toch al wat errors gevonden, zowel met zpool status als kern.log. Maar vooralsnog wel aanzienlijk minder dan met het originele moederbord.

Ofwel, ik begin toch wat te voelen voor brakke SATA-kabels, die het met het omprikken enzo misschien iets beter zijn gaan doen. Even deze scrub afwachten, dan kabeltjes wisselen en nog eens proberen.

[nero355]

CurlyMo schreef op vrijdag 23 april 2021 @ 08:56:
Tsja, waarom heeft elektronica een eindige levensduur. Uiteindelijk komt er toch een moment dat er dingen kapot gaan. Of dat nu na 1 maand, 3 jaar, 6 jaar of 30 jaar is. Dat punt komt een keer.

Onlangs een voeding binnen 30 minuten van goed naar brak zien gaan dus naast dat ik wist dat zoiets kan gebeuren nu ook nog eens daadwerkelijk meegemaakt!

[vanaalten]

Goed, ik had dus de brakke ZFS mirror (en SSD bootschijf) op een ander moederbord/PSU/processor/geheugen geprikt, maar wel met de oorspronkelijke kabels. Dat leek beter te gaan, minder errors:

code:

Scrub #1:
        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     2     0
            sdb     ONLINE       0    22     0

Scrub #2:
        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0    16     0

Scrub #3:
        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0    16     0
            sdb     ONLINE       0    21     0

Hierna de SATA kabels vervangen door nieuwe kabels en opnieuw twee keer een scrub gedaan:

code:

Scrub #1:
        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       3    70     0
            sdb     ONLINE       2   151     0

Scrub #2:
        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     1     0
            sdb     ONLINE       0   102     0

In kern.log zie ik nog steeds dit soort meldingen:

code:

Apr 25 16:46:40 nas kernel: [100917.738805] ata2: hard resetting link
Apr 25 16:46:41 nas kernel: [100918.448564] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Apr 25 16:46:41 nas kernel: [100918.450154] ata2.00: configured for UDMA/133
Apr 25 16:46:41 nas kernel: [100918.450253] sd 1:0:0:0: [sdb] tag#11 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 25 16:46:41 nas kernel: [100918.450256] sd 1:0:0:0: [sdb] tag#11 Sense Key : Illegal Request [current]
Apr 25 16:46:41 nas kernel: [100918.450259] sd 1:0:0:0: [sdb] tag#11 Add. Sense: Unaligned write command
Apr 25 16:46:41 nas kernel: [100918.450263] sd 1:0:0:0: [sdb] tag#11 CDB: Write(16) 8a 00 00 00 00 02 6c 11 d9 a8 00 00 00 30 00 00
Apr 25 16:46:41 nas kernel: [100918.450265] print_req_error: I/O error, dev sdb, sector 10403043752
Apr 25 16:46:41 nas kernel: [100918.453030] zio pool=datapool vdev=/dev/sdb1 error=5 type=2 offset=5326357352448 size=24576 flags=40080c80
Apr 25 16:46:41 nas kernel: [100918.453051] sd 1:0:0:0: [sdb] tag#14 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 25 16:46:41 nas kernel: [100918.453061] sd 1:0:0:0: [sdb] tag#14 Sense Key : Illegal Request [current]
Apr 25 16:46:41 nas kernel: [100918.453068] sd 1:0:0:0: [sdb] tag#14 Add. Sense: Unaligned write command
Apr 25 16:46:41 nas kernel: [100918.453076] sd 1:0:0:0: [sdb] tag#14 CDB: Write(16) 8a 00 00 00 00 02 70 11 c4 78 00 00 00 08 00 00
Apr 25 16:46:41 nas kernel: [100918.453082] print_req_error: I/O error, dev sdb, sector 10470147192
Apr 25 16:46:41 nas kernel: [100918.455841] zio pool=datapool vdev=/dev/sdb1 error=5 type=2 offset=5360714313728 size=4096 flags=180880

Ofwel: moederbord en toebehoren uitgesloten, SATA kabels uitgesloten. Is dan de enige conclusie mogelijk dat beide schijven brak zijn?

SMART info ziet er nog steeds best fraai uit:

code:

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   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   202   194   021    Pre-fail  Always       -       8875
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       3186
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       5799
 10 Spin_Retry_Count        0x0032   100   100   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       -       98
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       12
193 Load_Cycle_Count        0x0032   174   174   000    Old_age   Always       -       78388
194 Temperature_Celsius     0x0022   122   098   000    Old_age   Always       -       30
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   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

...waarbij het mij wel dwars zit dat er duidelijk problemen met sectoren in de kern.log staan, maar blijkbaar niet aanleiding geven om sectors te re-allocaten of zo.

Mijn idee zou nu zijn: beide schijven weer aan het oorspronkelijke moederbord hangen en compleet te wissen & formatteren. Dan weer een ZFS mirror opbouwen en een scrub doen, kijken wat er uit komt. Dan de backup terugzetten en nog een keer een scrub.

Zinloos, of zijn er betere ideeën?

[nero355]

@vanaalten

Schop die schijven lekker richting hun RMA afdeling en zet een vers setje in!

[Thralas]

vanaalten schreef op zondag 25 april 2021 @ 20:04:
...waarbij het mij wel dwars zit dat er duidelijk problemen met sectoren in de kern.log staan, maar blijkbaar niet aanleiding geven om sectors te re-allocaten of zo.

Dat gedeelte is nu juist niet erg boeiend. Dat treedt pas op vlak nadat de HDD kennelijk reset.

De reset is je probleem, alles wat je in je laatste error log ziet is slechts een gevolg daarvan en daar zou ik me niet druk om maken. Er zijn geen 'problemen met de sectoren' - er kaatst wat I/O af vlak na de reset. Dat gebeurt bij vergelijkbare logs op het internet ook. Ik heb het vermoeden dat je disks toch SMR zijn bij gebrek aan een andere goede uitleg voor de unaligned write error. In hoeverre dat relevant is voor de reset zelf weet ik niet.

Lastly, hier nog een goed vergelijkbare casus (van @CurlyMo n.b.) waar het aanpassen van SATA LPM de oplossing bleek. Probeer dat nou eens en/of de SATA speed.

CurlyMo in "Het grote zuinige server topic - deel 2"

[vanaalten]

Thralas schreef op maandag 26 april 2021 @ 01:27:
De reset is je probleem, alles wat je in je laatste error log ziet is slechts een gevolg daarvan en daar zou ik me niet druk om maken. Er zijn geen 'problemen met de sectoren' - er kaatst wat I/O af vlak na de reset. Dat gebeurt bij vergelijkbare logs op het internet ook. Ik heb het vermoeden dat je disks toch SMR zijn bij gebrek aan een andere goede uitleg voor de unaligned write error. In hoeverre dat relevant is voor de reset zelf weet ik niet.

Lastly, hier nog een goed vergelijkbare casus (van @CurlyMo n.b.) waar het aanpassen van SATA LPM de oplossing bleek. Probeer dat nou eens en/of de SATA speed.

CurlyMo in "Het grote zuinige server topic - deel 2"

Goed punt. Waarom het dan zo plotseling opgetreden is na die stroomstoring blijft dan nog even onbeantwoord, maar dit is nog wel een zinnige (en eenvoudige) om nog even uit te proberen. En als ik het zo lees, nog best kansrijk ook.

[iGadget]

Vraag - Als je een ZFS mirror setup maakt, moeten deze schijven dan *altijd* fysiek in hetzelfde systeem zitten? Of zou dit ook een schijf in een ander systeem kunnen zijn? Wat ik wil maken is dit:


Ik vraag dit omdat ik hier 2 proxmox servertjes heb staan die elkaars fail-over zijn. Nu heb ik (naast de uitdaging van een zeer beperkt budget) nog een shared storage 'uitdaging' - ik heb 1 WD Blue 1TB SATA SSD die ik wil gaan inzetten voor 'bulk' data, maar dan wel zo dat dit gedeeld is.
Een 3e machine voor shared storage inzetten is een optie, maar liever zou ik nog één zo'n zelfde WD Blue kopen en dan in beide nodes 1 zo'n schijf stoppen, zoals op het plaatje.
In beide nodes zit een dual 10Gbit adapter, dus ik kan prima een crosslink leggen die dan dedicated voor storage zou zijn.

De systeemschijven in beide nodes zijn 'server-grade' SDD's (na er hardhandig achter te zijn gekomen dat consumer SSD's geen goede optie zijn), maar voor (gedeeld) multimedia materiaal lijkt me dit overkill.

Het idee is om deze shared 'bulk' storage toe te wijzen aan één VM (bijv. Nextcloud) die te allen tijd slechts loopt op één van de nodes, nooit tegelijk op beide. Dit voorkomt (hoop ik) access collisions.

Dus, kan wat in gedachten heb? En zo ja, hoe zou ik dit moeten opzetten? ZFS over NFS? iSCSI? Of een andere manier?

[ Voor 0% gewijzigd door iGadget op 26-04-2021 13:40 . Reden: typo ]

[CurlyMo]

@iGadget Dat kan alleen met file based vdev's. Of je dat moet willen is een tweede. Ik zou gewoon synchroniseren tussen main node en de rest via ZFS send/receive.

[iGadget]

CurlyMo schreef op maandag 26 april 2021 @ 13:45:
@iGadget Dat kan alleen met file based vdev's. Of je dat moet willen is een tweede. Ik zou gewoon synchroniseren tussen main node en de rest via ZFS send/receive.

Dank voor je reactie, @CurlyMo. Heb geen ervaring met ZFS send/receive, maar wat ik er zo snel over kan vinden is dat dit normaliter via een snapshot gaat, dus dat houdt automatisch in dat het niet 'real time' kan, klopt dat?
In dat geval zou ik het dus ook gewoon via de ingebouwde replicate functionaliteit van Proxmox kunnen doen, om het simpel te houden. Of heeft ZFS send/receive nog specifieke voordelen boven Proxmox' replicate functie?

Wat betreft file based vdev's, waarom zou ik dat *niet* willen?

[dcm360]

Laagjes tussen de hardware en ZFS stoppen (zoals een extra filesystem) doet het idee achter ZFS wel aardig teniet.
Wat ik zelf zou doen is ZFS op beide schijven, en VM's / containers met Proxmox laten repliceren. 'Losse' data kan vervolgens door iets als GlusterFS gesynchroniseerd blijven.

[Freeaqingme]

@iGadget Als je iets als dit wil doen zou ik eerder kijken naar DRBD. Zelf geen ervaring mee en ik ken het vooral van horror-verhalen, maar dat is voor dit soort scenario's gebouwd.

Als het ZFS-based moet zijn zou ik eerder aan beide kanten een volume maken en die volumes continue snapshotten en zfs-senden. Dan kan per volume weliswaar maar 1 van beide kanten master zijn, maar ben je wel vrij veilig qua data-integriteit.

[Kaspers]

@iGadget, kijk ook zeker even naar sanoid/syncoid.

[iGadget]

@dcm360 Idd, dat doe ik nu ook al - Proxmox repliceert de verschillende VM's en disks over en weer (belangrijke VM's vaker dan minder belangrijke). De vraag is even of ik ditzelfde mechanisme nu ook voor de 'bulk' data ga gebruiken, of een andere oplossing. Dank voor je suggestie van GlusterFS, die zet ik erbij op de shortlist.

@Freeaqingme DRDB, ok. Zet ik erbij! Wat mij betreft hoeft het niet persé ZFS te zijn. Als andere oplossingen geschikter zijn voor dit doel dan prima.

@Kaspers Whoah, ziet er vet uit! Nog een optie voor op de lijst

Dus, so far heb ik deze opties:
- Replicatie via ingebouwde functionaliteit Proxmox
- ZFS send / receive
- File-based vdev
- GlusterFS
- DRDB
- Sanoid/Syncoid

En dan nog 1 die ik wil uitzoeken - CEPH. Geen idee hoe dit zich verhoudt t.o.v. ZFS. Iemand hier ervaring mee toevallig?

[Freeaqingme]

Kaspers schreef op maandag 26 april 2021 @ 18:10:
@iGadget, kijk ook zeker even naar sanoid/syncoid.

[YouTube: Sanoid cryptomalware rollback demo]

De video linkt naar 'cryptomalware rollback demo', maar feitelijk is het 'gewoon' een zfs snapshot tool toch? In dat kader heb ik goede ervaring met ZnapZend.

iGadget schreef op maandag 26 april 2021 @ 20:21:


En dan nog 1 die ik wil uitzoeken - CEPH. Geen idee hoe dit zich verhoudt t.o.v. ZFS. Iemand hier ervaring mee toevallig?

Ja, dat lijkt me voor het door jou geschetste scenario ernstig overkill. Ongetwijfeld dat de tooling er omheen tegenwoordig goed genoeg is om het snel en makkelijk op te zetten. Echter, het kan ook stuk, en dan ben je wel meteen weer heel ver van huis. Zou ik voor hier voor dus niet aanraden.

[CurlyMo]

Freeaqingme schreef op maandag 26 april 2021 @ 21:51:
[...]


De video linkt naar 'cryptomalware rollback demo', maar feitelijk is het 'gewoon' een zfs snapshot tool toch? In dat kader heb ik goede ervaring met ZnapZend.

Heel veel blitzheid zonder daadwerkelijk iets anders te laten zien dan native ZFS. Ik had tenminste een fancy frontend o.i.d. verwacht.

[Kaspers]

CurlyMo schreef op maandag 26 april 2021 @ 22:30:
[...]

Heel veel blitzheid zonder daadwerkelijk iets anders te laten zien dan native ZFS. Ik had tenminste een fancy frontend o.i.d. verwacht.

Ieder z'n eigen natuurlijk!
Ik ben zelf meer fan van simplistische cli tools, configureerbaar middels config files, gescheduled middels systemd-units en timers.

sanoid config (snapshot management framework):

code:

[zfspool/koos/documents]
        use_template = frequent_longterm
[zfspool/koos/kubernetes]
        use_template = frequent_shortterm
[zfspool/koos/photos]
        use_template = nonfrequent_longterm
[zfspool/koos/videos]
        use_template = nonfrequent_longterm
[zfspool/koos/books]
        use_template = nonfrequent_longterm
[zfspool/koos/bookmarks]
        use_template = nonfrequent_longterm

#############################
# templates below this line #
#############################

#het aantal backups behouden per afgelopen <eenheid>
[template_frequent_longterm]
        frequently = 0
        hourly = 0
        daily = 30
        monthly = 12
        yearly = 1
        autosnap = yes
        autoprune = yes

[template_nonfrequent_longterm]
        frequently = 0
        hourly = 0
        daily = 0
        monthly = 12
        yearly = 1
        autosnap = yes
        autoprune = yes

[template_frequent_shortterm]
        frequently = 0
        hourly = 0
        daily = 30
        monthly = 0
        yearly = 0
        autosnap = yes
        autoprune = yes

syncoid shell script ("filesystem-level snapshot replication to move data from one machine to another, fast.")

code:

#!/bin/sh

#target:
USER=admin
HOST=backup.lan

echo "Sending snapshots of koos/configuration"
syncoid --no-sync-snap  zfspool/koos/configuration $USER@$HOST:zfspool2/koos/configuration
echo "Sending snapshots of koos/documents"
syncoid --no-sync-snap  zfspool/koos/documents     $USER@$HOST:zfspool2/koos/documents
echo "Sending snapshots of koos/kubernetes"
syncoid --no-sync-snap  zfspool/koos/kubernetes    $USER@$HOST:zfspool2/koos/kubernetes
echo "Sending snapshots of koos/photos"
syncoid --no-sync-snap  zfspool/koos/photos        $USER@$HOST:zfspool2/koos/photos
echo "Sending snapshots of koos/videos"
syncoid --no-sync-snap  zfspool/koos/videos        $USER@$HOST:zfspool2/koos/videos
echo "Sending snapshots of koos/books"
syncoid --no-sync-snap  zfspool/koos/books        $USER@$HOST:zfspool2/koos/books
echo "Sending snapshots of koos/bookmarks"
syncoid --no-sync-snap  zfspool/koos/bookmarks        $USER@$HOST:zfspool2/koos/bookmarks

.

Zoals ik al zei: ieder z'n eigen. Ik heb met bovenstaande 2 tools geen omkijken meer naar snapshot replication managment op de server op zolder én replicatie naar een tweede host in de kelder. En mocht de systemd-service eruit knallen, dan krijg ik netjes een emailnotificatie:

code:

[Unit]
Description=Run sanoid
OnFailure=email-notification@%i.service

[Service]
Type=simple
ExecStart=sanoid --cron --configdir /zfspool/koos/configuration/storage-server/sanoid/ --verbose

#deze service werkt met een timer.

failture notification service:

code:

[Unit]
Description=%i failure email notification

[Service]
Type=oneshot
ExecStart=/bin/bash -c '/bin/systemctl status %i | /usr/bin/mailx -s "[%i] failure notification" [e-mail]'

Doe er je voordeel mee mocht je 't wat vinden .

[CurlyMo]

@Kaspers ik ben het publiek ook niet hoor. Ik heb gewoon wat zelfbouw bash scripts die al jaren prima werken.

Ging mij meer om het marketing filmpje dat enkel native ZFS spul laat zien.

[vanaalten]

@Thralas en @CurlyMo (en alle anderen die zinnige suggesties gedaan hebben): probleem opgelost!

In eerste instantie op die reservemachine

code:

echo max_performance > /sys/class/scsi_host/host0/link_power_management_policy

(en host1...host5) gedaan, na een scrub nul errors.

Daarna wild (en dom) gedaan. Sowieso vergeet ik telkens netjes een zfs export/import te doen bij omprikken naar een andere machine, dus dat was al verkeerd toen ik de schijven naar de originele machine terugplaatste. En ik dacht 'even kijken of het echt aan die settings ligt', dus toen een scrub gestart zonder die link_power_management_policy optie - en dat gaf een degraded pool met 1 schijf UNAVAIL en bijna 5M aan checksum errors. Opnieuw scrubben (en nu met max_performance link_power_management_policy ) gaf hetzelfde resultaat.

Daarna een zfs export gedaan gevolgd door zfs import - en het spul ging meteen resilveren. Twaalf uur later: schone pool zonder errors.

code:

  pool: datapool
 state: ONLINE
  scan: resilvered 4.24T in 11:55:41 with 0 errors on Wed Apr 28 08:37:25 2021
config:

        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

errors: No known data errors

Bizar wel dat die link_power_management_policy de boosdoener is en dat dat zo ineens opkomt. Maar fijn dat het nu opgelost is. Enkel nog even die opties aan de opstartsequentie toevoegen.

Dank nogmaals voor het vele meedenken en de nuttige tips!

[CurlyMo]

@vanaalten Geen powertop gedraaid?

[vanaalten]

CurlyMo schreef op woensdag 28 april 2021 @ 15:11:
@vanaalten Geen powertop gedraaid?

@CurlyMo Nee. Ik draai powertop sowieso niet standaard bij het opstarten. Sommige mensen gebruiken 'powertop --auto-tune', maar ik draai powertop incidenteel om te zien of er dingen verbeterd kunnen worden en dan plaats ik eventuele verbeteringen in een eigen opstartscript. Maar goed, die dingen had ik op deze machine al een tijdje buiten gebruik.

Als ik nu powertop draai zegt 'ie wel o.a.

code:

   Bad           Enable SATA link power management for host4
   Bad           Enable SATA link power management for host5
   Bad           Enable SATA link power management for host3
   Bad           Enable SATA link power management for host1
   Bad           Enable SATA link power management for host2
   Bad           Enable SATA link power management for host0

... maar dat houden we nu dus zo. Liever een power-ongunstige setting dan low-power met disk-corruptie.

Maar goed, die link power management policy staat dus default wel enabled in deze kernel en moet je expliciet uitzetten (max_performance of medium_power zetten).

Nu eerst dit even een tijdje stabiel laten draaien en dan wellicht eens kijken of powertop dingen aanraadt die zinnig zijn zonder disk-corruptie.

[cville]

Kaspers schreef op dinsdag 27 april 2021 @ 19:11:
[...]


Ieder z'n eigen natuurlijk!
Ik ben zelf meer fan van simplistische cli tools, configureerbaar middels config files, gescheduled middels systemd-units en timers.

sanoid config (snapshot management framework):

code:

[zfspool/koos/documents]
        use_template = frequent_longterm
[zfspool/koos/kubernetes]
        use_template = frequent_shortterm
[zfspool/koos/photos]
        use_template = nonfrequent_longterm
[zfspool/koos/videos]
        use_template = nonfrequent_longterm
[zfspool/koos/books]
        use_template = nonfrequent_longterm
[zfspool/koos/bookmarks]
        use_template = nonfrequent_longterm

#############################
# templates below this line #
#############################

#het aantal backups behouden per afgelopen <eenheid>
[template_frequent_longterm]
        frequently = 0
        hourly = 0
        daily = 30
        monthly = 12
        yearly = 1
        autosnap = yes
        autoprune = yes

[template_nonfrequent_longterm]
        frequently = 0
        hourly = 0
        daily = 0
        monthly = 12
        yearly = 1
        autosnap = yes
        autoprune = yes

[template_frequent_shortterm]
        frequently = 0
        hourly = 0
        daily = 30
        monthly = 0
        yearly = 0
        autosnap = yes
        autoprune = yes

syncoid shell script ("filesystem-level snapshot replication to move data from one machine to another, fast.")

code:

#!/bin/sh

#target:
USER=admin
HOST=backup.lan

echo "Sending snapshots of koos/configuration"
syncoid --no-sync-snap  zfspool/koos/configuration $USER@$HOST:zfspool2/koos/configuration
echo "Sending snapshots of koos/documents"
syncoid --no-sync-snap  zfspool/koos/documents     $USER@$HOST:zfspool2/koos/documents
echo "Sending snapshots of koos/kubernetes"
syncoid --no-sync-snap  zfspool/koos/kubernetes    $USER@$HOST:zfspool2/koos/kubernetes
echo "Sending snapshots of koos/photos"
syncoid --no-sync-snap  zfspool/koos/photos        $USER@$HOST:zfspool2/koos/photos
echo "Sending snapshots of koos/videos"
syncoid --no-sync-snap  zfspool/koos/videos        $USER@$HOST:zfspool2/koos/videos
echo "Sending snapshots of koos/books"
syncoid --no-sync-snap  zfspool/koos/books        $USER@$HOST:zfspool2/koos/books
echo "Sending snapshots of koos/bookmarks"
syncoid --no-sync-snap  zfspool/koos/bookmarks        $USER@$HOST:zfspool2/koos/bookmarks

.

Zoals ik al zei: ieder z'n eigen. Ik heb met bovenstaande 2 tools geen omkijken meer naar snapshot replication managment op de server op zolder én replicatie naar een tweede host in de kelder. En mocht de systemd-service eruit knallen, dan krijg ik netjes een emailnotificatie:

code:

[Unit]
Description=Run sanoid
OnFailure=email-notification@%i.service

[Service]
Type=simple
ExecStart=sanoid --cron --configdir /zfspool/koos/configuration/storage-server/sanoid/ --verbose

#deze service werkt met een timer.

failture notification service:

code:

[Unit]
Description=%i failure email notification

[Service]
Type=oneshot
ExecStart=/bin/bash -c '/bin/systemctl status %i | /usr/bin/mailx -s "[%i] failure notification" [e-mail]'

Doe er je voordeel mee mocht je 't wat vinden .

Ben zelf ook sanoid/syncoid aan het inrichten. Waar ik echter nergens iets over kan vinden is een restore. Heb je dat (vanaf je syncoid data) geprobeerd en hoe doe je dat dan?

[Kaspers]

cville schreef op woensdag 28 april 2021 @ 21:21:
Ben zelf ook sanoid/syncoid aan het inrichten. Waar ik echter nergens iets over kan vinden is een restore. Heb je dat (vanaf je syncoid data) geprobeerd en hoe doe je dat dan?

Ik heb nog niet eerder een restore gedaan terug naar m'n storage host vanaf m'n backup server. Maar in feite kun je daar wederom de syncoid cli voor gebruiken. Mijn advies zou wel zijn te 'restoren' (lees: repliceren) naar een schone zfspool.

[ Voor 4% gewijzigd door Kaspers op 28-04-2021 21:34 ]

[CurlyMo]

Kaspers schreef op woensdag 28 april 2021 @ 21:32:
[...]


Ik heb nog niet eerder een restore gedaan terug naar m'n storage host vanaf m'n backup server.

Dat is wel echt een cruciale stap in je backup strategie.