Het grote ZFS topic

[dcm360]

nero355 schreef op zondag 5 januari 2020 @ 23:02:
[...]
Die zitten er gelukkig niet in voor zover ik heb begrepen

_{Wie koopt die troep dan ook voor een NAS}

Volgens mij zijn SMR-schijven niet eens echt verkeerd met een workload die je zou verwachten voor een NAS. Willekeurig kleine beetjes schrijven moet je niet doen, maar dat is sowieso al niet handig met een NAS.

[RobertMe]

nero355 schreef op zondag 5 januari 2020 @ 23:02:
[...]

Dat waren de Greens inderdaad en sinds die verdwenen zijn hebben de Blue modellen die markt overgenomen, maar of ze daar ook last van hebben : Geen idee!

Met de juiste tools is dat vast wel op een hele hoge waarde te zetten net als vroeger

Als ik Blue schrijf dan bedoel ik ook Blue en niet Green . Was IIRC september 2017 dat ik ze kocht. Bij een 2TB Blue kon het wel worden uit gezet (of veel langer) bij de 6TB niet en die heb ik toen (gelukkig) kunnen ruilen voor een RED (goede service van Azerty).

Edit:
Overigens zit er in de NAS ook een 4TB Green. Bij mijn weten zonder continue head parking. Zelfde voor de 2TB Green in m'n gewone PC, en AFAIK ook bij de nog vele malen antiekere 500GB Green. Geen van allen heeft bij mijn weten continue head parking.

[...]

Die zitten er gelukkig niet in voor zover ik heb begrepen

Wat ik afgelopen dagen zo'n beetje op Reddit heb gelezen zitten die er tegenwoordig soms juist wel in. En bv ook die nieuwe 20TB schijf schijnt SMR te zijn.

_{Wie koopt die troep dan ook voor een NAS}

Het zuinige server topic staat vol met dat je deze schrijf moet kopen. Ik had bad sectors op de Blue, en met Black Friday was deze schijf super goedkoop op Amazon (€88). Maar ik heb mijn les intussen geleerd. Maar intussen hebben dus zowel @dcm360 als @FireDrunk aangetoond dat deze schijven, zeker in een RAIDZ setup, en als het voornamelijk om grote(re) bestanden gaat, wel gewoon goed zijn. Fout zit dus ook gedeeltelijk in mijn setup / wat waar staat.

[ Voor 8% gewijzigd door RobertMe op 06-01-2020 07:17 ]

[mkroes]

nero355 schreef op zondag 5 januari 2020 @ 23:02:
[...]

Dat waren de Greens inderdaad en sinds die verdwenen zijn hebben de Blue modellen die markt overgenomen, maar of ze daar ook last van hebben : Geen idee!

Met de juiste tools is dat vast wel op een hele hoge waarde te zetten net als vroeger

Ik heb dit toevallig 2 januari geprobeerd bij een 6tb wd blue. Deze kun je nog steeds met wdidle aanpassen en dus ook uitschakelen.

RobertMe schreef op maandag 6 januari 2020 @ 06:52:
[...]

Als ik Blue schrijf dan bedoel ik ook Blue en niet Green . Was IIRC september 2017 dat ik ze kocht. Bij een 2TB Blue kon het wel worden uit gezet (of veel langer) bij de 6TB niet en die heb ik toen (gelukkig) kunnen ruilen voor een RED (goede service van Azerty).

Het is mij dus wel gelukt om deze uit te schakelen, gewoon nog met de tool wdidle. Ging om een WD 6tb blue met datum november 2017.
Wel in de bios de sata aansluiting even aan moeten passen naar ide (ipv ahci).

[ Voor 37% gewijzigd door mkroes op 06-01-2020 07:29 ]

[unezra]

dcm360 schreef op zondag 5 januari 2020 @ 23:48:
[...]
Volgens mij zijn SMR-schijven niet eens echt verkeerd met een workload die je zou verwachten voor een NAS. Willekeurig kleine beetjes schrijven moet je niet doen, maar dat is sowieso al niet handig met een NAS.

Da's toch juist het idee van een NAS? Dat je er ook kleinere hoeveelheden data op schrijft?

Ik zie geen probleem. In fact, voordat ik mijn systeem verving had ik thuis een FreeNAS machine (met ZFS) waar al mijn vm's via NFS hun data op weg schrijven. Meer dan 10 vm's die die NAS als lokale HDD zien.

Zo hebben we dat op kantoor ook (servers hebben geen lokale storage, enkel een SD kaart om ESX van te starten) en dat werkt meer dan prima.

Of SMR daarvoor geschikt is durf ik niet te zeggen, met lage workload lijkt me dat geen probleem. Met hoge workload wil je iets anders. Maar dan wil je vooral veel spindles. Hoe meer spindles hoe beter. (Want hoe meer spindles, hoe meer IOPS.)

[RobertMe]

mkroes schreef op maandag 6 januari 2020 @ 07:25:
[...]


Ik heb dit toevallig 2 januari geprobeerd bij een 6tb wd blue. Deze kun je nog steeds met wdidle aanpassen en dus ook uitschakelen.


[...]


Het is mij dus wel gelukt om deze uit te schakelen, gewoon nog met de tool wdidle. Ging om een WD 6tb blue met datum november 2017.
Wel in de bios de sata aansluiting even aan moeten passen naar ide (ipv ahci).

Hmm. Da's raar. Ik heb die beide Blues toen tegelijkertijd gekocht en bij de een kon het wel en de ander niet.

unezra schreef op maandag 6 januari 2020 @ 07:29:
Of SMR daarvoor geschikt is durf ik niet te zeggen, met lage workload lijkt me dat geen probleem. Met hoge workload wil je iets anders.

Wat is een lage en hoge workload? Home-Assistant die zowel naar Postgresql als InfluxDB schrijft was blijkbaar al teveel van het goede. Naast 9 uur resilver tijd leide dat ook daarna soms nog tot "lockups" (andere software die compleet bleef hangen en ettelijke seconden moest wachten op reads). Kleine files/writes lijkt dus gewoon nog steeds funest te zijn (zonder RAIDZ waarbij alles wat verdeelt wordt?).

[dcm360]

@unezra Virtualisatie-workload valt wat mij betreft niet meer in de categorie van een NAS-workload. Thuis en kleinzakelijk doe je dat misschien nog wel op een NAS, maar verder kom je uit bij een SAN voor een dergelijke workload. Hoe dan ook, het is altijd al van belang geweest dat je schijven koopt die geschikt zijn voor de workload. Er was een markt voor 10K en 15K RPM schijven, net als dat er tegenwoordig een markt is voor SMR-schijven. Bijvoorbeeld Backblaze en Dropbox hebben geen bezwaar tegen dergelijke schijven, want voor eenmaal een bulk schrijven en daarna af en toe lezen zijn ze prima.

[unezra]

dcm360 schreef op maandag 6 januari 2020 @ 10:28:
@unezra Virtualisatie-workload valt wat mij betreft niet meer in de categorie van een NAS-workload. Thuis en kleinzakelijk doe je dat misschien nog wel op een NAS, maar verder kom je uit bij een SAN voor een dergelijke workload.

De termen lopen daar wat door elkaar heen. Wij doen het met 40 FTE, capaciteit van 100 FTE, VDI omgeving en op top rond de 80 vm's op een NetApp FAS2220 met 12+24 spindles per locatie.

Je kunt twisten of je zoiets als NAS of als SAN ziet. Het ding doet namelijk ook native CIFS en dat gebruiken we ook. Verder hangt alles er via NFS aan, op de workdisks van de VDI omgeving na. (Dat is nie te doen, die doen dat lokaal op SSD's.)

Hoe dan ook, het is altijd al van belang geweest dat je schijven koopt die geschikt zijn voor de workload. Er was een markt voor 10K en 15K RPM schijven, net als dat er tegenwoordig een markt is voor SMR-schijven. Bijvoorbeeld Backblaze en Dropbox hebben geen bezwaar tegen dergelijke schijven, want voor eenmaal een bulk schrijven en daarna af en toe lezen zijn ze prima.

Klopt.
SMR en helium disks zijn wat vroeger de 5,25" BigFoot's waren. Veel voor weinig.

Aan de andere kant is er nog steeds een markt voor 10KRPM en 15KRPM schijven, juist voor IO intensieve worloads waar IOPS belangrijk zijn en SSD te duur.

[CurlyMo]

unezra schreef op maandag 6 januari 2020 @ 10:35:
[...]
Aan de andere kant is er nog steeds een markt voor 10KRPM en 15KRPM schijven, juist voor IO intensieve worloads waar IOPS belangrijk zijn en SSD te duur.

Welke markt zou dat zijn? Ik zie het nut er niet van in als we tegenwoordig makkelijk snelle opslag als cache kunnen inzetten.

[unezra]

CurlyMo schreef op maandag 6 januari 2020 @ 10:49:
[...]
Welke markt zou dat zijn? Ik zie het nut er niet van in als we tegenwoordig makkelijk snelle opslag als cache kunnen inzetten.

Ik zou, als ik mijn huidige omgeving zou vervangen door on-prem (in plaats van te outsourcen), waarschijnlijk nog steeds voor snelle spindles gaan, mogelijk zonder cache omdat dat niet nodig is, maar mogelijk wel meer geld kost dan snelle spindles.

Van zulke omgevingen zijn er duizenden alleen al in NL.

[FireDrunk]

Dat iets er is, en nog steeds gekocht wordt, wil niet zeggen dat het de beste oplossing is.
Er bestaat nog zoiets als Marketing en Vendor Lock-In.

Veel Storage Appliances die nu nog ingezet zijn, ondersteunen geen (SSD) Caching laag, waardoor spindles nog gewoon de standaard blijven.

Koop je nu iets nieuws, ben je volgens mij in echt de meeste gevallen goedkoper uit met nearline-SAS + een SSD Caching laag.

[WeaZuL]

Ik ben na een harde schijf falen bezig (nu reeds 2h) met een resilvering na een zpool replace. Echter gaat het traag:

# zpool status
  pool: tank1
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Jan  7 10:53:00 2020
	15.1G scanned out of 6.16T at 615K/s, (scan is slow, no estimated time)
	7.14G resilvered, 0.24% done
config:

	NAME                                           STATE     READ WRITE CKSUM
	tank1                                          DEGRADED     0     0     0
	  mirror-0                                     ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S321J9CG202691  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S32WJ9FF462626  ONLINE       0     0     0
	  mirror-1                                     ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9FF717085  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9FF717543  ONLINE       0     0     0
	  mirror-2                                     DEGRADED     0     0     0
	    ata-ST5000LM000-2AN170_WCJ04XQP            ONLINE       0     0     0
	    replacing-1                                DEGRADED     0     0     0
	      12266353921450074282                     UNAVAIL      0     0     0  was /dev/disk/by-id/ata-ST5000LM000-2AN170_WCJ01VYW-part1
	      ata-ST5000LM000-2AN170_WCJ03KT3          ONLINE       0     0     0  (resilvering)
	logs
	  slog                                         ONLINE       0     0     0

errors: No known data errors

Ik heb geen idee waar het aan ligt, genoeg geheugen vrij en geen drukke processen of io:

# free -h
              total        used        free      shared  buff/cache   available
Mem:            62G        5.7G         55G        375M        1.2G         56G
Swap:          8.0G        240M        7.8G

Iemand eenn idee waar het aan zou kunnen liggen? In het verleden ging het altijd wel goed. Zou het aan de ata-ST2000LM003 mirrors kunnen liggen omdat die "vol" zitten?

[FireDrunk]

In het begin is het altijd traag. Gaat vanzelf sneller.

[RobertMe]

WeaZuL schreef op dinsdag 7 januari 2020 @ 13:58:
Ik ben na een harde schijf falen bezig (nu reeds 2h) met een resilvering na een zpool replace. Echter gaat het traag:

# zpool status
  pool: tank1
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Jan  7 10:53:00 2020
	15.1G scanned out of 6.16T at 615K/s, (scan is slow, no estimated time)
	7.14G resilvered, 0.24% done
config:

	NAME                                           STATE     READ WRITE CKSUM
	tank1                                          DEGRADED     0     0     0
	  mirror-0                                     ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S321J9CG202691  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S32WJ9FF462626  ONLINE       0     0     0
	  mirror-1                                     ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9FF717085  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9FF717543  ONLINE       0     0     0
	  mirror-2                                     DEGRADED     0     0     0
	    ata-ST5000LM000-2AN170_WCJ04XQP            ONLINE       0     0     0
	    replacing-1                                DEGRADED     0     0     0
	      12266353921450074282                     UNAVAIL      0     0     0  was /dev/disk/by-id/ata-ST5000LM000-2AN170_WCJ01VYW-part1
	      ata-ST5000LM000-2AN170_WCJ03KT3          ONLINE       0     0     0  (resilvering)
	logs
	  slog                                         ONLINE       0     0     0

errors: No known data errors

Ik heb geen idee waar het aan ligt, genoeg geheugen vrij en geen drukke processen of io:

# free -h
              total        used        free      shared  buff/cache   available
Mem:            62G        5.7G         55G        375M        1.2G         56G
Swap:          8.0G        240M        7.8G

Iemand eenn idee waar het aan zou kunnen liggen? In het verleden ging het altijd wel goed. Zou het aan de ata-ST2000LM003 mirrors kunnen liggen omdat die "vol" zitten?

Als ik die typenummers zo zie zou ik zeggen dat het om dezelfde Seagate schijf gaat als ik ook heb. Zie deze thread van mij met mijn geweldige ervaringen met deze SMR schijf: Harde schijf (extreem) traag en veroorzaakt lockups
Ik liep daarbij dus tegen een resilver tijd aan van 9 uur om maar 266GB over te zetten. Oorzaak dus het feit dat het een SMR schijf is in combinatie met veel kleine bestanden en dat de pool uiteraard ook gewoon in gebruik was (wat bij normaal gebruik ook tot lange wachttijden leide).

---

Na mijn geëxperimenteer / gepruts van afgelopen week wil ik toch maar eens gaan kijken om een extra systeempje op te zetten waar ook de belangrijkste data op staat. Een schijf ervoor heb ik al (jup, de "brakke" Seagate). Nu nog een systeempje. In principe is een kleine/goedkope Single Board Computer wat mij betreft voldoende. Maar wat zijn daarvoor de opties? Een RPi (2? 3? 4?) zal wel mogelijk zijn, maar zijn er nog betere alternatieven? Ik kwam zo snel de Odroid XU4 tegen voor $49 bv. Maar zijn er nog meer/betere opties? Ik meen dat er anderen in dit topic ook al eens geëxperimenteerd hadden met zulke SBCs puur voor backup doeleinden?

[CurlyMo]

@RobertMe
CurlyMo in "Het grote ZFS topic"

[WeaZuL]

FireDrunk schreef op dinsdag 7 januari 2020 @ 13:58:
In het begin is het altijd traag. Gaat vanzelf sneller.

Ik hoop dat je gelijk hebt!

RobertMe schreef op dinsdag 7 januari 2020 @ 14:06:
[...]

Als ik die typenummers zo zie zou ik zeggen dat het om dezelfde Seagate schijf gaat als ik ook heb. Zie deze thread van mij met mijn geweldige ervaringen met deze SMR schijf: Harde schijf (extreem) traag en veroorzaakt lockups
Ik liep daarbij dus tegen een resilver tijd aan van 9 uur om maar 266GB over te zetten. Oorzaak dus het feit dat het een SMR schijf is in combinatie met veel kleine bestanden en dat de pool uiteraard ook gewoon in gebruik was (wat bij normaal gebruik ook tot lange wachttijden leide).

---

Na mijn geëxperimenteer / gepruts van afgelopen week wil ik toch maar eens gaan kijken om een extra systeempje op te zetten waar ook de belangrijkste data op staat. Een schijf ervoor heb ik al (jup, de "brakke" Seagate). Nu nog een systeempje. In principe is een kleine/goedkope Single Board Computer wat mij betreft voldoende. Maar wat zijn daarvoor de opties? Een RPi (2? 3? 4?) zal wel mogelijk zijn, maar zijn er nog betere alternatieven? Ik kwam zo snel de Odroid XU4 tegen voor $49 bv. Maar zijn er nog meer/betere opties? Ik meen dat er anderen in dit topic ook al eens geëxperimenteerd hadden met zulke SBCs puur voor backup doeleinden?

Gewoon uitzitten dus, overigens wel mooi kak. Gevalletje "you get what you pay for"?! Maar welke schijven zouden dan een betere prijs/prestatie verhouding hebben dan deze SMR's en ook nog eens zuinig en "geschikt" voor NAS (thuis) gebruik? Of is dat een onmogelijke combinatie?

[RobertMe]

CurlyMo schreef op dinsdag 7 januari 2020 @ 14:09:
@RobertMe
CurlyMo in "Het grote ZFS topic"

Zie je wel. Ik wist vrij zeker dat ik hier iets anders had gezien. Orange Pi dus. Ik zie alleen dat je deze in april 2018 in gebruik hebt genomen en het daardoor alweer een oudje is, met maar USB 2.0 poorten. Is er misschien alweer iets nieuwers op de markt?
Die Odroid XU4 heeft wel USB 3.0, maar volgens mij is het nadeel daarvan dat deze maar 32 bit is (net zoals de oude RPis AFAIK), en ZFS liever 64 bit heeft, wat de Orange Pi ook is. Maar met een prijskaartje van ~€30 is deze natuurlijk wel zeer mooi v.w.b. prijs.

---

WeaZuL schreef op dinsdag 7 januari 2020 @ 14:20:
[...]


Ik hoop dat je gelijk hebt!

Als ik het goed zie had je de resilver al 3 uur lopen toen je poste? En dan nog maar een paar GB gescand (laat staan geschreven). Persoonlijk denk ik dat dat toch iets sneller kan.

[...]


Gewoon uitzitten dus, overigens wel mooi kak. Gevalletje "you get what you pay for"?! Maar welke schijven zouden dan een betere prijs/prestatie verhouding hebben dan deze SMR's en ook nog eens zuinig en "geschikt" voor NAS (thuis) gebruik? Of is dat een onmogelijke combinatie?

Als leek denk ik inderdaad dat het een gevalletje het een of het ander is. Goedkoop en zuinig kom je al snel uit op 2,5". Maar door de beperkte grote moet er iets verzonnen worden om wel de capaciteit te behalen, en SMR is een techniek daarvoor. (Komt dus neer op dat de baan die geschreven wordt technisch niet smaller gemaakt kan worden, terwijl die voor lezen niet zo breed hoeft te zijn, daardoor worden de banen gedeeltelijk over elkaar geschreven om alsnog smallere banen te hebben. Nadeel is dus wel dat één write effectief veel meer opnieuw moet wegschrijven op de HDD (de overlappende banen moeten dan ook opnieuw worden geschreven)).
Wil je wel performance zul je uit komen bij PMR schijven, maar ik denk dat die er niet zijn met deze capaciteiten, in 2,5" formaat. En 3,5" is dus weer niet zo zuinig.

[CurlyMo]

RobertMe schreef op dinsdag 7 januari 2020 @ 14:46:
[...]

Zie je wel. Ik wist vrij zeker dat ik hier iets anders had gezien. Orange Pi dus. Ik zie alleen dat je deze in april 2018 in gebruik hebt genomen en het daardoor alweer een oudje is, met maar USB 2.0 poorten. Is er misschien alweer iets nieuwers op de markt?
Die Odroid XU4 heeft wel USB 3.0, maar volgens mij is het nadeel daarvan dat deze maar 32 bit is (net zoals de oude RPis AFAIK), en ZFS liever 64 bit heeft, wat de Orange Pi ook is. Maar met een prijskaartje van ~€30 is deze natuurlijk wel zeer mooi v.w.b. prijs.

Met 32bit ga je uiteindelijk tegen allemaal ellende aanlopen. Daarnaast is het offsite backup, dus boeie dat het wat langzamer is

Als je iets zoekt voor één schijf, dan zou ik deze halen:
https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/

[RobertMe]

CurlyMo schreef op dinsdag 7 januari 2020 @ 14:51:
[...]

Met 32bit ga je uiteindelijk tegen allemaal ellende aanlopen. Daarnaast is het offsite backup, dus boeie dat het wat langzamer is

Als je iets zoekt voor één schijf, dan zou ik deze halen:
https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/

Als ik het goed zie is die Exynos 5422 ook een 32 bit CPU, dus niet handig dan? En in dat geval lijkt me die Odroid XU4 ook beter, zelfde CPU (Exynos 5422 dus) maar wel een aantal USB 3.0 poorten. Die sata poort kan me dan gestolen worden

Maar Orange Pi is overall dan dus beter/makkelijker, want 64 bit. Maar als nadeel dus USB 2.0, wat qua offsite backup inderdaad minder uit maakt.

Edit:
De Lite 2 kan ook nog interessant zijn. Wel maar één USB 3.0 poort, maar voor de rest ook "compleet" (64 bit, 1GB RAM, Gigabit ethernet, ...). Of de 3, maar die kost meteen het dubbele van de PC2 en kun je ongeveer net zo goed voor een RPi4 gaan.

[ Voor 19% gewijzigd door RobertMe op 07-01-2020 17:23 ]

[nero355]

@RobertMe : Waarom neem je geen Synology NAS met 2 bays voor de vaak gebruikte data en gebruik je de ZFS NAS daarnaast alleen als Offline Backup

Dat is in ieder geval iets waar ik steeds meer aan zit te denken

[CurlyMo]

@RobertMe Inderdaad 32bit. Uiteindelijk ben ik zelf ook voor de duurzame oplossing gegaan en heb een NUC bemachtigd (gratis van een medetweaker )

[RobertMe]

nero355 schreef op dinsdag 7 januari 2020 @ 18:59:
@RobertMe : Waarom neem je geen Synology NAS met 2 bays voor de vaak gebruikte data en gebruik je de ZFS NAS daarnaast alleen als Offline Backup

Dat is in ieder geval iets waar ik steeds meer aan zit te denken

Omdat ik geen ZFS NAS heb Het is meer een thuisserver met ZFS filesystem waar ik ook backups van PCs naar maak. Waarschijnlijk dit jaar ergens de hardware eens upgraden en dan ook de overstap maken naar Proxmox (i.p.v. lekker rolling release Arch Linux. Living on the edge zullen we maar zeggen).

Waar ik nu zo snel voornamelijk naar aan het kijken ben is een simpele & goedkope (in aanschaf en gebruik) oplossing om nog een tweede locatie van de ZFS snapshots te hebben. Een goedkoop SBC leek mij daarvoor dus wel een mooie oplossing.

CurlyMo schreef op dinsdag 7 januari 2020 @ 19:04:
@RobertMe Inderdaad 32bit. Uiteindelijk ben ik zelf ook voor de duurzame oplossing gegaan en heb een NUC bemachtigd (gratis van een medetweaker )

Gratis lijkt mij dat wel leuk, maar gezien ik al een thuisserver heb vind ik nog eens een systeem van wat is het, €100 tot €200 iets te veel van het goede. Dan kan ik bij wijze van net zo goed een oud systeem recyclen voor mijn gevoel.

[CurlyMo]

Dan zou ik gewoon voor de Orange Pi PC2 gaan.

[nero355]

RobertMe schreef op dinsdag 7 januari 2020 @ 19:31:
Omdat ik geen ZFS NAS heb Het is meer een thuisserver met ZFS filesystem waar ik ook backups van PCs naar maak. Waarschijnlijk dit jaar ergens de hardware eens upgraden en dan ook de overstap maken naar Proxmox (i.p.v. lekker rolling release Arch Linux. Living on the edge zullen we maar zeggen).

Proxmox heeft inderdaad leuke ZFS Support!

Waar ik nu zo snel voornamelijk naar aan het kijken ben is een simpele & goedkope (in aanschaf en gebruik) oplossing om nog een tweede locatie van de ZFS snapshots te hebben. Een goedkoop SBC leek mij daarvoor dus wel een mooie oplossing.

Gratis lijkt mij dat wel leuk, maar gezien ik al een thuisserver heb vind ik nog eens een systeem van wat is het, €100 tot €200 iets te veel van het goede. Dan kan ik bij wijze van net zo goed een oud systeem recyclen voor mijn gevoel.

Maar hoe zuinig of flexibel is dat systeem als er wat stuk gaat

Ik zou dan twee dingen overwegen :
- Dat leuke ARM + USB HDD Cage systeem van @Q nabouwen.
- Een leuke x86-64 oplossing zoals dit : pricewatch: ASRock J3455-ITX
of dit : pricewatch: ASRock DeskMini A300

[unezra]

nero355 schreef op dinsdag 7 januari 2020 @ 18:59:
@RobertMe : Waarom neem je geen Synology NAS met 2 bays voor de vaak gebruikte data en gebruik je de ZFS NAS daarnaast alleen als Offline Backup

Dat is in ieder geval iets waar ik steeds meer aan zit te denken

Synology gebruikt voor zover ik weet geen ZFS en laat net dát leuk en nuttig zijn voor offsite (niet offline) backups. Kun je mooi ook je snapshots overschieten naar de andere kant en heb je niet alleen een kopie van je actuele data, maar ook van je snapshots.

Handig, want zo'n offsite backup wil je OOK in geval je door malware geraakt word. De malware raakt wel je actieve data, maar niet je snapshots. (Die zijn immutable.) Als je alleen je actieve data synct, is je kopie geïnfecteerd. Sync je ook je snapshots, heb je ook een kopie daarvan.

Dat is waarom ik heb gekozen voor Sanoid/Syncoid:
https://github.com/jimsalterjrs/sanoid

Het is niet meer dan een wrapper om zfs snapshots en zfs-send heen, maar wel een fijne wrapper. Het enige dat ik nog moet uitvogelen is hoe ik SAMBA vertel over het snapshot formaat, dat is me nog niet goed gelukt. (Dat is echt een SAMBA ding.)

Ik ben op dit moment een 2e machine aan het optuigen die volledig offsite gaat en en-passant ook nog een vm-etje of 2, 3 er bij gaat krijgen voor wat random taken zoals externe monitoring. Vooral omdat het kan en omdat de machine er tóch is. Ik heb iets overcapaciteit op die machine, dus dat zet ik in voor lichte taken. (Waarvan ik vervolgens de data weer repliceer naar huis en ik dus ook van die data altijd een backup heb.)

[RobertMe]

nero355 schreef op dinsdag 7 januari 2020 @ 23:27:
Ik zou dan twee dingen overwegen :
- Dat leuke ARM + USB HDD Cage systeem van @Q nabouwen.

Je bedoelt deze? https://blog.quindorian.o...er-storage-hardware.html/
Zo te zien is dat x86 en gaan ARM. En je komt dan ook op het punt van hieronder

- Een leuke x86-64 oplossing zoals dit : pricewatch: ASRock J3455-ITX
of dit : pricewatch: ASRock DeskMini A300

Dan kom je dus weer op een compleet nieuw systeem uit en dus "hoge" kosten. En dat is het mij niet waard voor iets wat ik potentieel dit jaar nog ga opvolgen door alsnog iets NAS/server achtigs buiten de deur te plaatsen waar dan ook de ZFS snapshots naartoe kunnen. Dan zou ik nu dus minimaal €150 uitgeven terwijl het misschien over 6 maanden al niet meer gebruikt wordt. Waar zo'n "Pi" maar een paar tientjes kost en eenvoudig te repurposen is.

Waarschijnlijk wordt het dan dus toch een Orange Pi, PC 2 of 3. Prijsverschil is iets kleiner dan ik initieel schreef. PC 2 kost dan €19 en de 3 €37 schreef ik eerst, maar die laatste is dan wel inc. 8GB eMMC opslag waar bij de PC 2 dan nog SD of whatever erbij komt. Juiste vergelijking is dan ook €19 vs €32

[CurlyMo]

RobertMe schreef op woensdag 8 januari 2020 @ 07:49:
[...]

Dan kom je dus weer op een compleet nieuw systeem uit en dus "hoge" kosten. En dat is het mij niet waard voor iets wat ik potentieel dit jaar nog ga opvolgen door alsnog iets NAS/server achtigs buiten de deur te plaatsen waar dan ook de ZFS snapshots naartoe kunnen. Dan zou ik nu dus minimaal €150 uitgeven terwijl het misschien over 6 maanden al niet meer gebruikt wordt. Waar zo'n "Pi" maar een paar tientjes kost en eenvoudig te repurposen is.

En dit:

Sinned123 schreef op zaterdag 7 december 2019 @ 14:15:
[...]

Ik had nog een kastje nodig omdat de slimme meter op de begane grond staat en 3d printer op zolder.
https://www.amazon.de/dp/B081B2GNR8
Af en toe zijn er 20% coupons voor. Heb zelf €79,19 betaald.
Wederom Z8350 met 2GB ram en 32GB eMMC.
Deze haalt nog betere resultaten.
HDMI/LAN/USB stick van draadloze 2-1 tobo/muis 2,2w
LAN/USB 1,8w
LAN 1,7w

Bedenk dat je er met de aanschaf van alleen een Pi ook niet bent. Daar moet ook nog een adapter, case, en evt. SD kaart bij.

[WeaZuL]

RobertMe schreef op dinsdag 7 januari 2020 @ 14:46:
[...]

[...]

Als ik het goed zie had je de resilver al 3 uur lopen toen je poste? En dan nog maar een paar GB gescand (laat staan geschreven). Persoonlijk denk ik dat dat toch iets sneller kan.


[...]

Verbetering zoals @FireDrunk al aangaf, hieronder de situatie van vanochtend.

#zpool status
  pool: tank1
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Jan  7 10:53:00 2020
        90.9G scanned out of 6.16T at 1.19M/s, (scan is slow, no estimated time)
        42.2G resilvered, 1.44% done
config:

        NAME                                           STATE     READ WRITE CKSUM
        tank1                                          DEGRADED     0     0     0
          mirror-0                                     ONLINE       0     0     0
            ata-ST2000LM003_HN-M201RAD_S321J9CG202691  ONLINE       0     0     0
            ata-ST2000LM003_HN-M201RAD_S32WJ9FF462626  ONLINE       0     0     0
          mirror-1                                     ONLINE       0     0     0
            ata-ST2000LM003_HN-M201RAD_S34RJ9FF717085  ONLINE       0     0     0
            ata-ST2000LM003_HN-M201RAD_S34RJ9FF717543  ONLINE       0     0     0
          mirror-2                                     DEGRADED     0     0     0
            ata-ST5000LM000-2AN170_WCJ04XQP            ONLINE       0     0     0
            replacing-1                                DEGRADED     0     0     0
              12266353921450074282                     UNAVAIL      0     0     0  was /dev/disk/by-id/ata-ST5000LM000-2AN170_WCJ01VYW-part1
              ata-ST5000LM000-2AN170_WCJ03KT3          ONLINE       0     0     0  (resilvering)
        logs
          slog                                         ONLINE       0     0     0

[FireDrunk]

Hmm, na 24h nog steeds 1MB/s is wel behoorlijk slecht
Kan je eens blktrace draaien ondertussen?

https://tunnelix.com/debu...btt-in-linux-environment/
(stukje naar beneden in het artikel)

[WeaZuL]

FireDrunk schreef op woensdag 8 januari 2020 @ 10:04:
Hmm, na 24h nog steeds 1MB/s is wel behoorlijk slecht
Kan je eens blktrace draaien ondertussen?

https://tunnelix.com/debu...btt-in-linux-environment/
(stukje naar beneden in het artikel)

Zal ik doen, wordt wel vnvd. Hopen dat het resilvering process dan niet ineens klaar is

[FireDrunk]

Dat zal wel mee (of juist tegen ) vallen.

[CyberJack]

code:

  pool: storage
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
    still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
    the pool may no longer be accessible by software that does not support
    the features. See zpool-features(5) for details.
  scan: scrub repaired 0B in 0 days 12:28:47 with 0 errors on Mon Jan  6 12:28:54 2020
config:

    NAME        STATE     READ WRITE CKSUM
    storage     ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
        sdd     ONLINE       0     0     0
        sde     ONLINE       0     0     0

errors: No known data errors

Mijn zpool status geeft aan dat sommige features blijkbaar niet enabled zijn. Vermoedelijk komt dit doordat de pool aangemaakt is op een oudere versie van zfs en ik momenteel een up-to-date versie draai.

De pool draait al sinds het aanmaken zonder problemen, dus ik heb ook geen idee welke features ik zou missen momenteel. Weet iemand of ik mijn zpool veilig kan updaten (dus het "zpool upgrade" kan draaien)?

[FireDrunk]

Ligt er aan of je ooit van plan bent om van platform te wisselen, en of oudere ZFS versies wil kunnen blijven gebruiken.

Als je features activeert (en in gebruik neemt) die net nieuw zijn, kan je nooit meer 'downgraden'.

[CurlyMo]

FireDrunk schreef op woensdag 8 januari 2020 @ 11:07:
Ligt er aan of je ooit van plan bent om van platform te wisselen, en of oudere ZFS versies wil kunnen blijven gebruiken.

Als je features activeert (en in gebruik neemt) die net nieuw zijn, kan je nooit meer 'downgraden'.

Niet helemaal waar. Als je bijv. de bookmark feature activeert dan wordt die enabled. Dan is er nog niks aan de hand qua compatibiliteit. Als je vervolgens een bookmark maakt, dan wordt die active waardoor je vast zit aan support voor die feature flag bij importeren. Als je vervolgens weer alle bookmarks verwijderd, dan wordt de status weer enabled i.p.v. active waardoor er dus weer geen problemen zijn.

[FireDrunk]

Ahzo, ik was in de veronderstelling dat iets nooit meer van Active naar Enabled kon.
Thanks voor de verheldering!

[CyberJack]

Thanks voor de uitleg. Het wordt tijd dat ik me hier wat meer in ga verdiepen, want ik heb nu geen idee wat de meeste features doen. Tot die tijd laat ik de update maar even zitten. Momenteel is dit de lijst die "zpool get all" aangeeft (even zelf gesorteerd).

code:

Active:
    embedded_data
    empty_bpobj
    enabled_txg
    extensible_dataset
    hole_birth
    lz4_compress
    spacemap_histogram
    userobj_accounting

Enabled:
    async_destroy
    bookmarks
    edonr
    filesystem_limits
    large_blocks
    large_dnode
    multi_vdev_crash_dump
    sha512
    skein

Disabled:
    allocation_classes
    bookmark_v2
    device_removal
    encryption
    obsolete_counts
    project_quota
    resilver_defer
    spacemap_v2
    zpool_checkpoint

[CurlyMo]

@CyberJack Lekker laten zo

[WeaZuL]

FireDrunk schreef op woensdag 8 januari 2020 @ 10:37:
Dat zal wel mee (of juist tegen ) vallen.

Het scheelt niet veel, momenteel een whopping 15M/s es kijken wat die commando's aangeven ..

# zpool status
  pool: tank1
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Jan  7 10:53:00 2020
	1.66T scanned out of 6.16T at 15.3M/s, 85h31m to go
	655G resilvered, 26.89% done
config:

	NAME                                           STATE     READ WRITE CKSUM
	tank1                                          DEGRADED     0     0     0
	  mirror-0                                     ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S321J9CG202691  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S32WJ9FF462626  ONLINE       0     0     0
	  mirror-1                                     ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9FF717085  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9FF717543  ONLINE       0     0     0
	  mirror-2                                     DEGRADED     0     0     0
	    ata-ST5000LM000-2AN170_WCJ04XQP            ONLINE       0     0     0
	    replacing-1                                DEGRADED     0     0     0
	      12266353921450074282                     UNAVAIL      0     0     0  was /dev/disk/by-id/ata-ST5000LM000-2AN170_WCJ01VYW-part1
	      ata-ST5000LM000-2AN170_WCJ03KT3          ONLINE       0     0     0  (resilvering)
	logs
	  slog                                         ONLINE       0     0     0

errors: No known data errors

[FireDrunk]

15M/s is al een stuk aannemelijker voor SMR schijven.

[WeaZuL]

FireDrunk schreef op woensdag 8 januari 2020 @ 10:04:
Hmm, na 24h nog steeds 1MB/s is wel behoorlijk slecht
Kan je eens blktrace draaien ondertussen?

https://tunnelix.com/debu...btt-in-linux-environment/
(stukje naar beneden in het artikel)

Pff daar komt een bootload aan informatie uit, is er nog iets specifieks waar ik op moet letten? Ik zie vooralsnog geen gekke dingen. Ik zie wel een hoop processen (pid's) met performance metrics maar vooralsnog niets geks.

[ Voor 12% gewijzigd door WeaZuL op 08-01-2020 21:42 ]

[FireDrunk]

Wat de gemiddelde block / request size is.

[ Voor 3% gewijzigd door FireDrunk op 08-01-2020 21:42 ]

[WeaZuL]

FireDrunk schreef op woensdag 8 januari 2020 @ 21:42:
Wat de gemiddelde block / request size is.

Ik stuur je een DM, teveel details en onwetendheid hier. Ondertussen zitten we op 20M/s, story continues ....

[GioStyle]

@WeaZuL

En hoe is het afgelopen?

[Zorc]

Iemand al ervaring met native ZFS encryptie? Ik lees er namelijk verschillende opvattingen over of het wel/niet betrouwbaar/stabiel genoeg is.

Ik zit momenteel nog te twijfelen of ik voor root on ZFS installatie (Arch linux) ga op mijn laptop of toch weer bij ext4 blijf. Met trim support en native encryptie begint het wel steeds aantrekkelijker te worden.

[Borromini]

@RobertMe Als ARM64 een optie is kan je misschien ook es naar de Helios64 kijken. Ik ben er zelf ook erg in geïnteresseerd. ARM64, hexacore, 4 GB RAM, plaats voor vijf S-ATA-schijven (of vier en één M.2 S-ATA SSD), en ook ondersteuning voor hotplugging zelfs. En een geïntegreerde 'UPS' als je wil.

@Zorc Zolang ZFS niet standaard in de Linux-kernel zit zou ik mijn root niet op ZFS zetten, maar ik ben daar nogal conservatief in. Je kan je /boot apart op ext4 zetten en / op ZFS, da's een compromis.

[Freeaqingme]

Zorc schreef op zaterdag 11 januari 2020 @ 12:26:
Iemand al ervaring met native ZFS encryptie? Ik lees er namelijk verschillende opvattingen over of het wel/niet betrouwbaar/stabiel genoeg is.

Wat lees je dan specifiek? Overigens goed opletten of het gaat om 0.8 GA, of release candidates/beta releases die daarvoor kwamen.

[Zorc]

Freeaqingme schreef op zaterdag 11 januari 2020 @ 13:52:
[...]


Wat lees je dan specifiek? Overigens goed opletten of het gaat om 0.8 GA, of release candidates/beta releases die daarvoor kwamen.

Bugs, issues etc i.v.m. encryptie,. maar inderdaad niet altijd duidelijk over welke versie het zou gaan Als ik het zo lees moet het nu in orde zijn.

[Zorc]

Borromini schreef op zaterdag 11 januari 2020 @ 12:53:

@Zorc Zolang ZFS niet standaard in de Linux-kernel zit zou ik mijn root niet op ZFS zetten, maar ik ben daar nogal conservatief in. Je kan je /boot apart op ext4 zetten en / op ZFS, da's een compromis.

Dat is wat mij betreft wel een dingetje ja. Maar het lijkt er niet op dat het in de kernel gaat komen dus tja.
Maar ik zie niet echt het voordeel van alleen /boot op ext4?

[CurlyMo]

Borromini schreef op zaterdag 11 januari 2020 @ 12:53:
@RobertMe Als ARM64 een optie is kan je misschien ook es naar de Helios64 kijken. Ik ben er zelf ook erg in geïnteresseerd. ARM64, hexacore, 4 GB RAM, plaats voor vijf S-ATA-schijven (of vier en één NVMe SSD), en ook ondersteuning voor hotplugging zelfs. En een geïntegreerde 'UPS' als je wil.

Hier komt de Rockchip er nog altijd niet in.

[Borromini]

Waarom niet?

[CurlyMo]

Borromini schreef op zaterdag 11 januari 2020 @ 14:53:
Waarom niet?

Slechte reputatie qua kernel support.

[Borromini]

Ik vreesde al zoiets. Dat maakt het ook een vreemde keuze voor zo'n systeem vind ik. Ben benieuwd wat daar de motivatie achter is, want dat moet de ontwikkelaars ook extra geld kosten, ondersteuning (hoe beperkt ook) voor hardware die extra tijd en geld kost.

[nero355]

CurlyMo schreef op zaterdag 11 januari 2020 @ 14:55:
Slechte reputatie qua kernel support.

Ze claimen daar in de reacties dat het deze keer niet tot rare outdated toestanden zal leiden

[Borromini]

Eén van de ontwikkelaars zegt het volgende:

We will use kernel based on mainline kernel. RK3399 is supported on Armbian CURRENT branch that use LK 5.4. We will also submit the device tree to mainline kernel.

Regarding binary blobs, there are only 2 in use, the pre-bootloader (before u-boot stage) which is pretty common in most SoC, and the DisplayPort driver.

[RobertMe]

Borromini schreef op zaterdag 11 januari 2020 @ 12:53:
@RobertMe Als ARM64 een optie is kan je misschien ook es naar de Helios64 kijken. Ik ben er zelf ook erg in geïnteresseerd. ARM64, hexacore, 4 GB RAM, plaats voor vijf S-ATA-schijven (of vier en één NVMe SSD), en ook ondersteuning voor hotplugging zelfs. En een geïntegreerde 'UPS' als je wil.

Ik ben dus eigenlijk op zoek naar een goedkope manier om een (redundant) backup te maken van de data op mijn NAS/thuisserver die (gedeeltelijk) al een backup is van meerdere PCs (maar gedeeltelijk dus data op staat van software die op het systeem draait waar geen backup van is buiten ZFS snapshots en de HDDs in mirror). Een $189 kostend moederbord vind ik eerlijk gezegd dus zeer fors aan de prijs.
Zeker met in mijn achterhoofd het idee om wellicht bij familie ook nog een NAS/thuisserver op te zetten en daar dan ook de data naar te repliceren. Iets waarvoor ik dan weer voor een x86(_64) systeem zou gaan (i.v.m. "thuisserver") en deze Helios dus weer meteen afgeschreven zou worden.
Vandaar dat het mij meer gaat om goedkoop dan om toekomst bestendigheid. Na mijn vorige posts heb ik er ook niet meer naar gekeken, maar waarschijnlijk wordt het dan een Orange Pi PC 2 of Orange Pi 3. Afhankelijk van of ik uiteindelijk wel of niet USB3 wil hebben (met meerprijs van €10 / 50% duurder)

[RobertMe]

Zorc schreef op zaterdag 11 januari 2020 @ 14:33:
[...]


Dat is wat mij betreft wel een dingetje ja. Maar het lijkt er niet op dat het in de kernel gaat komen dus tja.

Maak daarvan maar gewoon "ZFS gaat niet in de kernel komen". De licentie kwestie an zich is wel bekend (licentie van ZFS is niet compatible met GPL en daardoor issues). Maar Canonical meent dan weer een manier daar omheen gevonden te hebben.
Maar dit schreef Linus Torvalds himself er deze week nog over:

And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd.

Other people think it can be ok to merge ZFS code into the kernel and that the module interface makes it ok, and that's their decision. But considering Oracle's litigious nature, and the questions over licensing, there's no way I can feel safe in ever doing so.

And I'm not at all interested in some "ZFS shim layer" thing either that some people seem to think would isolate the two projects. That adds no value to our side, and given Oracle's interface copyright suits (see Java), I don't think it's any real licensing win either.

Bron

[Borromini]

Ik heb ZFS ook op al mijn opslagschijven draaien. Het stoort me persoonlijk niet dat het niet in de kernel komt; met DKMS en upstream Debian-pakketten werkt het netjes. Maar mijn / houd ik wel op BTRFS of ext4.

[WeaZuL]

GioStyle schreef op zaterdag 11 januari 2020 @ 11:03:
@WeaZuL

En hoe is het afgelopen?

# zpool status
  pool: tank1
 state: ONLINE
  scan: resilvered 2.81T in 77h0m with 0 errors on Fri Jan 10 15:53:30 2020
config:

	NAME                                           STATE     READ WRITE CKSUM
	tank1                                          ONLINE       0     0     0
	  mirror-0                                     ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S321J9CG202691  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S32WJ9FF462626  ONLINE       0     0     0
	  mirror-1                                     ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9FF717085  ONLINE       0     0     0
	    ata-ST2000LM003_HN-M201RAD_S34RJ9FF717543  ONLINE       0     0     0
	  mirror-2                                     ONLINE       0     0     0
	    ata-ST5000LM000-2AN170_WCJ04XQP            ONLINE       0     0     0
	    ata-ST5000LM000-2AN170_WCJ03KT3            ONLINE       0     0     0
	logs
	  slog                                         ONLINE       0     0     0

errors: No known data errors

Resilvering iets meer dan drie dagen. Tja, dat is aardig lang voor 2.81T naar mijn mening, oorzaak voorlopig nog onbekend?! Verder functioneert de server gewoon "normaal", maar meten is weten.

[nero355]

RobertMe schreef op zaterdag 11 januari 2020 @ 17:46:
Een $189 kostend moederbord vind ik eerlijk gezegd dus zeer fors aan de prijs.

Ik vind de huidige aanbieding voor het gehele kastje met een NAS uiterlijk eigenlijk wel een koopje, want een QNAP/Synology is veel duurder en om zoiets te DIY-en i.c.m. een reguliere kast kost nog veel meer!

Het is geen ideale oplossing, maar het is wel een verdomd interessante optie voor jouw doeleinde IMHO

Zeker met in mijn achterhoofd het idee om wellicht bij familie ook nog een NAS/thuisserver op te zetten en daar dan ook de data naar te repliceren. Iets waarvoor ik dan weer voor een x86(_64) systeem zou gaan (i.v.m. "thuisserver") en deze Helios dus weer meteen afgeschreven zou worden.

Wat voor spannends ben je dan van plan dat het geen ARM mag zijn met 4 GB RAM

Vandaar dat het mij meer gaat om goedkoop dan om toekomst bestendigheid. Na mijn vorige posts heb ik er ook niet meer naar gekeken, maar waarschijnlijk wordt het dan een Orange Pi PC 2 of Orange Pi 3. Afhankelijk van of ik uiteindelijk wel of niet USB3 wil hebben (met meerprijs van €10 / 50% duurder)

Dus toch weer een ARM oplossing ?!

[Borromini]

Het is inderdaad geen gewoon 'moederbord'. Er zit al een processor op, RAM en 16 GB flash gesoldeerd, dus je opstartschijf heb je al. Er zit ook een voeding in/bij. Het is niet te vergelijken met een simpele SBC qua functionaliteit en aansluitingen. Ontwerp is ook van een ander niveau.

Een RPi kan zijn werk best goed doen, maar als je betrouwbare opslag wil voor je OS, en iets dat stroomuitval overleeft zonder kleerscheuren, dan staat een RPi niet op de lijst.

Maar ieder zijn ding natuurlijk.

[ Voor 44% gewijzigd door Borromini op 12-01-2020 09:58 ]

[RobertMe]

nero355 schreef op zondag 12 januari 2020 @ 01:31:
[...]

Ik vind de huidige aanbieding voor het gehele kastje met een NAS uiterlijk eigenlijk wel een koopje, want een QNAP/Synology is veel duurder en om zoiets te DIY-en i.c.m. een reguliere kast kost nog veel meer!

Het is geen ideale oplossing, maar het is wel een verdomd interessante optie voor jouw doeleinde IMHO


[...]

Wat voor spannends ben je dan van plan dat het geen ARM mag zijn met 4 GB RAM

[...]

Dus toch weer een ARM oplossing ?!

Nogmaals: voor nu ben ik op zoek naar een systeem om een (extra) backup van de data op mijn NAS/thuisserver te maken. Het enige vinkje dat gezet hoeft te worden is dus "kan ik ZFS er op draaien?" En een plusje voor "is USB 3 / SATA ondersteund" en "kunnen meerdere schijven worden aangesloten", maar dat zijn dus beiden geen vereisten.

Daarnaast wil ik misschien later dit jaar een systeem opzetten voor bij een familielid. Maar dat systeem moet dan twee dingen kunnen: 1. Opslag (= NAS), 2. Software/services draaien (= thuisserver). En voor thuisserver wil ik mij niet vastleggen aan ARM. Omdat ik 1. Niet weet of Proxmox op ARM draait, 2. Er bv voor Docker veeel meer images zijn voor x86_64 dan voor ARM.

Maar omdat ik nu nog niet weet of dat systeem er gaat komen, maar na mijn gepruts met ZFS met die nieuwe schijf, ik wel zo snel mogelijk al backups van mijn NAS/thuisserver wil gaan maken ben ik dus zoekende naar een oplossing daarvoor. Maar daarbij wil ik dus niet een berg geld uitgeven aan een systeem wat mogelijk over een paar maanden/jaar alweer uit gebruik gaat. Vandaar dus eerder een Orange Pi dan een Helios. Beiden voldoen aan "draait ZFS" maar de afschrijving op een Orange Pi is toch echt een stuk lager (ook met opslag voor OS + adapter + behuizing + ... meegerekend).
Hell, ik ga maar eens zoeken of ZFS op een RPi Model B kan (jip, uit de tijd dat er nog geen RPi 2 Model B was. AKA: de aller eerste RPi). Want die heb ik toch nog liggen, ik vermoed alleen dat die echt zwaar te under-powered is.

[CurlyMo]

RobertMe schreef op zondag 12 januari 2020 @ 09:37:
[...]
Hell, ik ga maar eens zoeken of ZFS op een RPi Model B kan (jip, uit de tijd dat er nog geen RPi 2 Model B was. AKA: de aller eerste RPi). Want die heb ik toch nog liggen, ik vermoed alleen dat die echt zwaar te under-powered is.

Been there, done that. Gaat niet werken.

[nero355]

RobertMe schreef op zondag 12 januari 2020 @ 09:37:
Nogmaals: voor nu ben ik op zoek naar een systeem om een (extra) backup van de data op mijn NAS/thuisserver te maken. Het enige vinkje dat gezet hoeft te worden is dus "kan ik ZFS er op draaien?" En een plusje voor "is USB 3 / SATA ondersteund" en "kunnen meerdere schijven worden aangesloten", maar dat zijn dus beiden geen vereisten.

Dat kan dat systeem prima!

Daarnaast wil ik misschien later dit jaar een systeem opzetten voor bij een familielid. Maar dat systeem moet dan twee dingen kunnen: 1. Opslag (= NAS), 2. Software/services draaien (= thuisserver). En voor thuisserver wil ik mij niet vastleggen aan ARM. Omdat ik 1. Niet weet of Proxmox op ARM draait, 2. Er bv voor Docker veeel meer images zijn voor x86_64 dan voor ARM.

In dat geval zou ik voor een Atom/Celeron/Pentium achtige oplossing gaan, zoals ik al eerder had gepost, want Proxmox draait prima op iets als een Intel NUC 2820FYKH begreep ik laatst : Je hebt alleen genoeg geheugen nodig voor al je VM's en Containers

Maar omdat ik nu nog niet weet of dat systeem er gaat komen, maar na mijn gepruts met ZFS met die nieuwe schijf, ik wel zo snel mogelijk al backups van mijn NAS/thuisserver wil gaan maken ben ik dus zoekende naar een oplossing daarvoor. Maar daarbij wil ik dus niet een berg geld uitgeven aan een systeem wat mogelijk over een paar maanden/jaar alweer uit gebruik gaat. Vandaar dus eerder een Orange Pi dan een Helios. Beiden voldoen aan "draait ZFS" maar de afschrijving op een Orange Pi is toch echt een stuk lager (ook met opslag voor OS + adapter + behuizing + ... meegerekend).
Hell, ik ga maar eens zoeken of ZFS op een RPi Model B kan (jip, uit de tijd dat er nog geen RPi 2 Model B was. AKA: de aller eerste RPi). Want die heb ik toch nog liggen, ik vermoed alleen dat die echt zwaar te under-powered is.

Ouder dan de Raspberry Pi 4 met 4 GB RAM wil je niet als NAS hebben denk ik, want dat is echt baggertraag!

[RobertMe]

Nogmaals:

nero355 schreef op zondag 12 januari 2020 @ 18:47:
[...]

In dat geval zou ik voor een Atom/Celeron/Pentium achtige oplossing gaan, zoals ik al eerder had gepost, want Proxmox draait prima op iets als een Intel NUC 2820FYKH begreep ik laatst : Je hebt alleen genoeg geheugen nodig voor al je VM's en Containers

Daarom ga ik dus niet ga voor een Helios

[...]

Ouder dan de Raspberry Pi 4 met 4 GB RAM wil je niet als NAS hebben denk ik, want dat is echt baggertraag!

Het is dan ook geen NAS. 1x per dag een send & receive vanaf m'n NAS/thuisserver en klaar. Voor nu een mooi stopgap om een extra disk/pool te hebben met de data. Vooral gezien ik laatst met issues eigenlijk veel meer heb zitten prutsen dan me lief was. (Op "productie" systeem even een nieuwe zpool aanmaken, en destroyen, en weer aanmaken, .... Had zomaar de echte pool kunnen destroyen en dan was ik heel ver van huis geweest).
Zoals gezegd. Als die offsite backup locatie er komt (in vorm van NAS/thuisserver bij familielid) is de noodzaak voor deze oplossing een stuk lager en gaat de Orange Pi 3 (vanmiddag besteld) wellicht alweer de kast in.

[DXaroth]

RobertMe schreef op zondag 12 januari 2020 @ 19:06:
Nogmaals:

[...]

Daarom ga ik dus niet ga voor een Helios


[...]

Het is dan ook geen NAS. 1x per dag een send & receive vanaf m'n NAS/thuisserver en klaar. Voor nu een mooi stopgap om een extra disk/pool te hebben met de data. Vooral gezien ik laatst met issues eigenlijk veel meer heb zitten prutsen dan me lief was. (Op "productie" systeem even een nieuwe zpool aanmaken, en destroyen, en weer aanmaken, .... Had zomaar de echte pool kunnen destroyen en dan was ik heel ver van huis geweest).
Zoals gezegd. Als die offsite backup locatie er komt (in vorm van NAS/thuisserver bij familielid) is de noodzaak voor deze oplossing een stuk lager en gaat de Orange Pi 3 (vanmiddag besteld) wellicht alweer de kast in.

Let er ook wel op dat RasPi's enkel een 100mbit ethernet poort hebben, dus dat gaat sowieso je upper limit zijn aan transfer speed, ongeacht of de RasPi meer aan kan of niet.

[mcDavid]

DXaroth schreef op dinsdag 14 januari 2020 @ 12:01:
[...]


Let er ook wel op dat RasPi's enkel een 100mbit ethernet poort hebben, dus dat gaat sowieso je upper limit zijn aan transfer speed, ongeacht of de RasPi meer aan kan of niet.

Da's alleen waar voor de modellen t/m 2b.

Hoewel de 3b weliswaar GbE heeft, maar je hier uiteraard maar een fractie van kunt gebruiken, gezien alle i/o over één USB2 bus moet (samen met de i/o naar je usb-disk dus).

[nero355]

mcDavid schreef op dinsdag 14 januari 2020 @ 12:17:
Da's alleen waar voor de modellen t/m 2b.

Hoewel de 3b weliswaar GbE heeft, maar je hier uiteraard maar een fractie van kunt gebruiken, gezien alle i/o over één USB2 bus moet (samen met de i/o naar je usb-disk dus).

- 3B is 100 Mbps
- 3B+ is 1 Gbps, maar 300 Mbps daadwerkelijk bruikbaar.

De 4 heeft echt 100% bruikbare 1 Gbps en knal je gewoon ergens tegen de 950 Mbps of zo aan

En ook qua CPU kracht is de laatste eigenlijk als enige echt als "USB NAS" bruikbaar voor zover ik het goed heb begrepen!

[RobertMe]

Nu ook de HDD in mijn PC overleden lijkt te zijn wil ik toch maar eens beginnen aan de nieuwe NAS/thuisserver zodat ik deze ook meer als NAS ga inzetten met network shares en ik geen nieuwe HDD in PC hoef te zetten.

Ik ben alleen nog wat in dubio over hoe en wat. Momenteel heb ik twee pools. Een 6TB "storage" pool met "Linux ISOs" en een 2TB "backup" pool die dan mirrored is/was. Netto dus 8TB en aangezien ik aan de storage pool al lang niks heb opgeruimd betekent dat ook dat er niet veel bij komt.

Qua "veiligheid" klinkt een nieuwe opzet met RAIDZ2 natuurlijk het leukste omdat er dan twee willekeurige disks kunnen falen zonder wegvallen van data noch uptime. De vraag voor mij is alleen hoe hard ik dat nodig heb, omdat ik de echte data (dus zeg maar alles behalve de "Linux ISOs") ook nog wil gaan replicaten naar die 5TB Seagate aan de onderweg zijnde Orange Pi.

In theorie zou ik dus ook kunnen gaan voor twee 8TB schijven in een mirror. Qua data voldoende en door de mirror redundancy. Maar wellicht naar de toekomst gericht wat krap berekend. Alternatief is dan uiteraard grotere disks in een mirror. Of juist een overstap naar RAIDZ waarbij de write performance toeneemt en evt. zelfs goedkopere SMR schijven weer in the picture komen. Maar ik heb te weinig kennis van zaken om hier een juiste afweging in te maken.

Wat zijn dus dingen waar ik op moet letten en op basis waarvan kan ik het beste een keuze maken? Kijkende naar minimaal 10TB aan netto opslag en een vorm van redundantie in opslag (naast dat snapshots ook nog dagelijks gerepliceerd zullen worden naar een los systeem, dus RAIDZ2 is waarschijnlijk overkill).
Ik ken wel de verhalen van dat RAID5 niet handig is bij grote disks (2TB+ IIRC) omdat de kans op een leesfout bij een resilver te groot is en daarmee het array helemaal kapot is. Maar speelt dit ook bij RAIDZ1? En is het risico dan zo groot dat het de RAID5/RAIDZ1 opzet te niet doet (redundancy die in 90% van de gevallen faalt bij de resilver wil ik geen redundancy noemen).
En is het bij een "bulk" aankoop dan nog handig om of verschillende modellen/merken te kopen, of van verschillende winkels? Om dus te voorkomen dat de schijven om en nabij hetzelfde moment beginnen te falen doordat ze en uit dezelfde batch komen, en soortgelijk gebruik en dus ook soortgelijke draaiuren, omstandigheden, etc.

Op het moment hink ik zelf naar een RAIDZ1 pool met 3x 8TB disks (specifiek om te shucken uit WD Elements, wellicht wel gekocht bij verschillende winkels). Netto dan 16TB storage. Een mirror zal dan én kleiner zijn tenzij die later wordt uitgebreid door nog een mirror er aan te hangen met striping) én geen performance voordeel geven bij writes. En aangezien ik het systeem dan ook als NAS met network drives wil inzetten is extra performance van RAIDZ dus ook wel een nice-to-have omdat het de kans op veel random I/O vergroot. Maar misschien dat ik iets over het hoofd zie of dat er betere opties zijn.

En ja, de 2,5" 5TB Seagates shucken valt waarschijnlijk af. Dan betaal ik liever extra wetende dat ik geen SMR schijven heb en dus geen risico loop op die slechte performance. Tenzij iemand kan garanderen dat het in setup X altijd goed gaat, ook bij volle disk met kleine random writes.

[Q]

RobertMe schreef op zaterdag 18 januari 2020 @ 10:24:
Ik ken wel de verhalen van dat RAID5 niet handig is bij grote disks (2TB+ IIRC) omdat de kans op een leesfout bij een resilver te groot is en daarmee het array helemaal kapot is. Maar speelt dit ook bij RAIDZ1? En is het risico dan zo groot dat het de RAID5/RAIDZ1 opzet te niet doet (redundancy die in 90% van de gevallen faalt bij de resilver wil ik geen redundancy noemen).

Ik reageer even op dit stukje. Wat mij betreft is dit allemaal bangmakerij over RAID 5 of RAIDZ. https://louwrentius.com/r...-fine-for-home-usage.html

Mensen doen panisch over RAID5 maar een rebuild hoeft helemaal niet langer te duren en een read error is net zo 'gevaarlijk' voor een mirror als voor een RAID 5/Z.

https://louwrentius.com/z...various-raid-schemas.html

Want bij een mirror rebuild moet de overgebleven non-redundante schijf heel hard werken. Precies de schijf die je niet wilt laten falen. Het risico bij een mirror is iets kleiner, want er moeten minder schijven mee doen, dus minder risico op disk falen.

Zelfs met grote schijven is RAID5 prima, maar stop er niet teveel in een enkele array, 6-7 disks is eigenlijk max wat mij betreft. Wil je meer disks in een array ga dan voor RAID6/Z2.

RobertMe schreef op zaterdag 18 januari 2020 @ 10:24:
Een mirror zal dan én kleiner zijn tenzij die later wordt uitgebreid door nog een mirror er aan te hangen met striping) én geen performance voordeel geven bij writes. En aangezien ik het systeem dan ook als NAS met network drives wil inzetten is extra performance van RAIDZ dus ook wel een nice-to-have omdat het de kans op veel random I/O vergroot. Maar misschien dat ik iets over het hoofd zie of dat er betere opties zijn.

Ik lees hier een misconceptie: ik heb ooit geleerd dat je de random I/O performance krijgt van een enkele disk per VDEV. Wil je dus meer random I/O performance dan moet je meer VDEVs gaan toevoegen. Vandaar dat mensen voor performance juist voor mirrors kiezen.

Voor thuis zou ik me niet zo druk maken om random I/O performance, zeker niet voor netwerk shares. Zolang je geen VMs draait is dat geen issue en die paar files maken niet echt uit. Grote bestanden kopieren, dus sequentiële transfers hebben wel baat bij RAIDZ van 3 disks tegen een 2-disk mirror. Maar ik denk dat je met een 2-disk mirror al gigabit dicht trekt dus wat heb je werkelijk nodig?

[ Voor 31% gewijzigd door Q op 18-01-2020 12:38 ]

[Q]

RobertMe schreef op zaterdag 18 januari 2020 @ 10:24:
Ik ben alleen nog wat in dubio over hoe en wat.
Wat zijn dus dingen waar ik op moet letten en op basis waarvan kan ik het beste een keuze maken?

Als ik zo je verhaal lees dan is mijn eerste reactie: waarom ben je met zelfbouw en ZFS in de weer? Waarom maak je het jezelf niet gewoon makkelijk en koop je een Synology of QNAP?

Je kunt dan gewoon beginnen met een RAID5 van 3 disks, meer dan zat voor je, maar je kunt gewoon groeien door een disk toe te voegen als je wilt. Die doosjes werken en schelen een hoop gedoe. Ik vraag me sterk af waarom zelfbouw en ZFS meerwaarde levert in jouw situatie.

Misschien vind je het gewoon een leuk hobby project, dat is ook prima. Misschien dat je ook goedkoper uit bent met een ZFS build maar zeker niet qua tijd.

Maar als je voor een ZFS build gaat (en mijn stokpaardje: zonder ECC vind ik dat onzin, MDADM is ook prima en flexibeler voor de meeste mensen) dan is de enige vraag, koop zoveel storage als je denkt te gaan gebruiken in de komende 3 jaar, gebaseerd op je gedrag in het verleden. Ik zou verdubbelen of verdrievoudigen van wat je nu hebt. Afhankelijk van die rekensom is mirrors of RAIDZ de betere (economische) optie, ik denk dat laatste. Maar let wel: je kunt geen disks toevoegen aan RAIDZ, dus als je een 3-disk RAIDZ draait dan moet je wederom een 3-disk RAIDZ toevoegen (minimaal) om uit te breiden.

[RobertMe]

Q schreef op zaterdag 18 januari 2020 @ 12:32:
[...]


Ik reageer even op dit stukje. Wat mij betreft is dit allemaal bangmakerij over RAID 5 of RAIDZ. https://louwrentius.com/r...-fine-for-home-usage.html

Mensen doen panisch over RAID5 maar een rebuild hoeft helemaal niet langer te duren en een read error is net zo 'gevaarlijk' voor een mirror als voor een RAID 5/Z.

https://louwrentius.com/z...various-raid-schemas.html

Want bij een mirror rebuild moet de overgebleven non-redundante schijf heel hard werken. Precies de schijf die je niet wilt laten falen. Het risico bij een mirror is iets kleiner, want er moeten minder schijven mee doen, dus minder risico op disk falen.

Zelfs met grote schijven is RAID5 prima, maar stop er niet teveel in een enkele array, 6-7 disks is eigenlijk max wat mij betreft. Wil je meer disks in een array ga dan voor RAID6/Z2.

Goed punt inderdaad, dat 5/Z1 vs 1/mirror niet veel uit maakt qua kans op falen bij rebuild. Hoogstens dat 6/Z2 dan helpt maar dat vind ik persoonlijk overkill.

[...]


Ik lees hier een misconceptie: ik heb ooit geleerd dat je de random I/O performance krijgt van een enkele disk per VDEV. Wil je dus meer random I/O performance dan moet je meer VDEVs gaan toevoegen. Vandaar dat mensen voor performance juist voor mirrors kiezen.

Voor thuis zou ik me niet zo druk maken om random I/O performance, zeker niet voor netwerk shares. Zolang je geen VMs draait is dat geen issue en die paar files maken niet echt uit. Grote bestanden kopieren, dus sequentiële transfers hebben wel baat bij RAIDZ van 3 disks tegen een 2-disk mirror. Maar ik denk dat je met een 2-disk mirror al gigabit dicht trekt dus wat heb je werkelijk nodig?

Met random I/O doelde ik voornamelijk op random writes. Naar aanleiding van mijn eigen topic: Harde schijf (extreem) traag en veroorzaakt lockups. Na aanleiding van falende disk in mirror dus zo'n Seagate schijf gekocht die, blijkbaar, op basis van SMR werkt en daardoor totaal niet paste bij mijn gebruik (random writes van databases als PostgreSQL & InfluxDB). Bij nieuwe thuisserver wil ik dat meteen oplossen v.w.b. databases (draaien vanaf SSD en qua backup elke dag bv een export op redundant filesystem zetten). Maar ik wil ook proberen te voorkomen nog een keer tegen die lamp aan te lopen (al dan niet weer met SMR schijven). Een mirror geeft qua writes dus wel een nadeel omdat de write pas gesynced is als die op alle disks staat. Daar waar bij RAIDZ1 de data wordt verdeeld over de disk en dus de load door meerdere disks wordt gedragen.

Q schreef op zaterdag 18 januari 2020 @ 12:45:
[...]


Als ik zo je verhaal lees dan is mijn eerste reactie: waarom ben je met zelfbouw en ZFS in de weer? Waarom maak je het jezelf niet gewoon makkelijk en koop je een Synology of QNAP?

Je kunt dan gewoon beginnen met een RAID5 van 3 disks, meer dan zat voor je, maar je kunt gewoon groeien door een disk toe te voegen als je wilt. Die doosjes werken en schelen een hoop gedoe. Ik vraag me sterk af waarom zelfbouw en ZFS meerwaarde levert in jouw situatie.

Misschien vind je het gewoon een leuk hobby project, dat is ook prima. Misschien dat je ook goedkoper uit bent met een ZFS build maar zeker niet qua tijd.

Het is een combinatie. Enerzijds hobby / "voor de leuk", anderzijds omdat het niet een dedicated NAS zal zijn (zoals het nu ook niet is). In de nieuwe situatie wil ik Proxmox erop gaan draaien met een aantal containers en/of VMs. Met een dedicated "prefab" NAS (Syno / QNap / ...) zal dat niet gaan. Vandaar zelfbouw.

Maar als je voor een ZFS build gaat (en mijn stokpaardje: zonder ECC vind ik dat onzin, MDADM is ook prima en flexibeler voor de meeste mensen) dan is de enige vraag, koop zoveel storage als je denkt te gaan gebruiken in de komende 3 jaar, gebaseerd op je gedrag in het verleden. Ik zou verdubbelen of verdrievoudigen van wat je nu hebt. Afhankelijk van die rekensom is mirrors of RAIDZ de betere (economische) optie, ik denk dat laatste. Maar let wel: je kunt geen disks toevoegen aan RAIDZ, dus als je een 3-disk RAIDZ draait dan moet je wederom een 3-disk RAIDZ toevoegen (minimaal) om uit te breiden.

Met een 3x 8TB RAIDZ pool verwacht ik zeker een aantal jaren vooruit te kunnen, ook omdat het 2x zoveel is als ik nu netto heb en 2,5 tot 3x zoveel als het huidige "verbruik" (kleine 5TB + nog geen 300GB dus samen nog geen 6TB). En om die reden dat het misschien ook een beetje overkill is en iets als een 8TB of 10TB mirror ook voldoende is en die later makkelijker uit te breiden is door nog een mirror van twee disks er aan toe te voegen of juist de bestaande schijven in-place te vervangen door grotere schijven waardoor AFAIK de beschikbare ruimte zich ook aanpast. Iets wat RAIDZ volgens mij ook niet kan? Alle schijven vervangen door grotere exemplaren waarna de hele pool de nieuwe grote aanneemt. (Naast dat je bij RAIDZ inderdaad geen schijven kunt toevoegen).

Ik ga in ieder geval even verder rekenen en denken of het 2x 8 of 10TB in mirror wordt of een RAIDZ van 3x 8TB. Overduidelijke conclusie daarbij is uiteraard dat een mirror met 2x dezelfde disk goedkoper is dan 3x diezelfde disk in RAIDZ. Maar per GB natuurlijk RAIDZ wint (want voor 16TB in mirror moet je al 4 disks hebben tegen 3 van RAIDZ).

Maar denk dat intussen dan ook wel alle verschillen/beweegredenen tussen mirror en RAIDZ1 benoemd zijn:
1. Kosten van de HDDs
2. Verwachte read performance (mirror sneller omdat elk blok van elke HDD gelezen kan worden waar bij RAIDZ het blok maar van een specifieke HDD gelezen kan worden)
3. Verwachte write performance (RAIDZ1 sneller omdat op elke HDD een deel wordt geschreven vs mirror waarbij alles naar elke HDD geschreven moet worden en één langzame HDD dus alles ophoud).

[Q]

Juist! Inderdaad geen SMR schijven gebruiken. Als je die hebt gekocht per abuis: terug sturen of als verlies afschrijven. Misschien dat ze een backup target kunnen zijn. Idealiter, zou ik zelfs voor 7200 RPM schijven gaan om nog een beetje knappe random performance te hebben.

[ocaj]

[b]RobertMe schreef op zaterdag 18 januari 2020 @ 14:21:
is en die later makkelijker uit te breiden is door nog een mirror van twee disks er aan toe te voegen of juist de bestaande schijven in-place te vervangen door grotere schijven waardoor AFAIK de beschikbare ruimte zich ook aanpast. Iets wat RAIDZ volgens mij ook niet kan? Alle schijven vervangen door grotere exemplaren waarna de hele pool de nieuwe grote aanneemt. (Naast dat je bij RAIDZ inderdaad geen schijven kunt toevoegen).

Dat in-place vervangen van schijven werkt ook gewoon met RAIDZ. Al krijg je de schijfruimte er pas bij nadat je de 3e schijf vervangt. Ik doe dat zo al vele jaren. Als er een schijf stuk gaat dan koop ik een schijf die groter is en redelijk geprijsd. (ooit begonnen met 3 x 1,5TB, daarna 3, 4 en inmiddels 3x6TB) Voor Raid-Z hoeven de schijven niet even groot te zijn, de hele raid-set gedraagt zich als een raid-set met 3 x de omvang van de kleinste schijf. Alle extra ruimte blijft ongebruikt.

Maar stel je hebt een set met 1 x 4TB en 2 x 6TB (bruikbare ruimte 8TB) en je vervangt de 4TB schijf door een 8TB-schijf, dan groeit de set naar een bruikbare ruimte van 12TB. Mocht je daarna de 6TB-schijven ook door 8TB-schijven vervangen dan heb je 16TB bruikbare ruimte.

[RobertMe]

ocaj schreef op zondag 19 januari 2020 @ 15:47:
[...]


Dat in-place vervangen van schijven werkt ook gewoon met RAIDZ. Al krijg je de schijfruimte er pas bij nadat je de 3e schijf vervangt. Ik doe dat zo al vele jaren. Als er een schijf stuk gaat dan koop ik een schijf die groter is en redelijk geprijsd. (ooit begonnen met 3 x 1,5TB, daarna 3, 4 en inmiddels 3x6TB) Voor Raid-Z hoeven de schijven niet even groot te zijn, de hele raid-set gedraagt zich als een raid-set met 3 x de omvang van de kleinste schijf. Alle extra ruimte blijft ongebruikt.

Maar stel je hebt een set met 1 x 4TB en 2 x 6TB (bruikbare ruimte 8TB) en je vervangt de 4TB schijf door een 8TB-schijf, dan groeit de set naar een bruikbare ruimte van 12TB. Mocht je daarna de 6TB-schijven ook door 8TB-schijven vervangen dan heb je 16TB bruikbare ruimte.

Dat is goed om te weten en nuttige info. Dat dit bij een mirror kon wist ik (twijfel of ik dit in het verleden al gedaan heb, hetzelfde als dat jij zegt, begonnen met twee verschillende schijven, de kleinste vervangen en daarmee de mirror vergroot). Dat dit ook bij raidz kon wist ik niet.

Dan zou ik voor nu zelfs ervoor kunnen kiezen om iets te proberen met mijn 6TB schijf. I.p.v. 3x 8TB nieuw kopen met 2x 8TB + de oude 6TB (moet ik alleen een migratiepad verzinnen). Enige ding is dat die volgens SMART ook bijna de 30000 uren aantikt / ongeveer 3, 3,5 jaar continu heeft gedraaid dus eigenlijk ook wel aan vervanging toe is (ondanks dat ik een 4TB heb die nog iets ouder is en ook nog in goede staat).

---

Hoe doen jullie dit? Vervangen jullie schijven als ze issues geven (bad sectors of whatever). Of als ze te klein zijn geworden en alles wordt vervangen? Of schrijven jullie ze na een X aantal jaar / draaiuren af? Toevallig dat ik vanmorgen ergens iets tegen kwam van "na 30000 uur doe ik ze vervangen". Is dat een goede rule of thumb? Of kan het best langer? Of gewoon gebruiken totdat ze beginnen te falen?

[Brahiewahiewa]

RobertMe schreef op zondag 19 januari 2020 @ 16:18:
[...]
Toevallig dat ik vanmorgen ergens iets tegen kwam van "na 30000 uur doe ik ze vervangen". Is dat een goede rule of thumb? Of kan het best langer? Of gewoon gebruiken totdat ze beginnen te falen?

30000 uur is natuurlijk een arbitratir getal (3 jaar en 3 maanden). Ik zou het van de fabrieksgarantie laten afhangen; schijven komen in de regel met 6, 12, 24, 36 of 60 maanden garantie.
En het maakt natuurlijk uit waar je ze gebruikt. Een disk vervangen op het moment dat-ie nog goed draait is in een professionele omgeving veel goedkoper dan een disk vervangen die de geest gegeven heeft. Voor thuisgebruik tellen jouw uren lang niet zo hard mee in de kosten

[RobertMe]

Brahiewahiewa schreef op zondag 19 januari 2020 @ 16:59:
[...]

30000 uur is natuurlijk een arbitratir getal (3 jaar en 3 maanden). Ik zou het van de fabrieksgarantie laten afhangen; schijven komen in de regel met 6, 12, 24, 36 of 60 maanden garantie.
En het maakt natuurlijk uit waar je ze gebruikt. Een disk vervangen op het moment dat-ie nog goed draait is in een professionele omgeving veel goedkoper dan een disk vervangen die de geest gegeven heeft. Voor thuisgebruik tellen jouw uren lang niet zo hard mee in de kosten

Tegelijkertijd kan een disk vervangen die het nog goed doet toch goed zijn voor de gemoedstoestand. Met één fakende disk op 1 december (/halfmaandelijkse scrub die dat aangaf), die nog steeds niet vervangen is (want vervangende was crappy Seagate SMR) en nu afgelopen week dan een tweede falende disk (ditmaal in mijn PC, AFAIK geen belangrijke data, maar ook geen backup) is het zeker niet echt prettig.

Daarom ook dat ik nu maar meteen wil doorpakken. Nieuwe schijven in de NAS/thuisserver, die crappy Seagate als extra daily backup (dadelijk aan Orange Pi en daily snapshots syncen), en of dan zo'n "afgeschreven" schijf uit NAS naar PC of zorgen dat alles op PC op SSD staat (met backups) en grote files op NAS met network share.

[Brahiewahiewa]

RobertMe schreef op zondag 19 januari 2020 @ 17:32:
[...]

Tegelijkertijd kan een disk vervangen die het nog goed doet toch goed zijn voor de gemoedstoestand...

Jij kunt het je kennelijk permitteren om een paar honderd €uro te investeren in je gemoedstoestand.
Dat geld(t) niet voor iedereen ;o)

[CurlyMo]

RobertMe schreef op zondag 19 januari 2020 @ 17:32:
[...]

Tegelijkertijd kan een disk vervangen die het nog goed doet toch goed zijn voor de gemoedstoestand.

Terwijl de meeste HDD's juist falen in de eerste paar maanden. Net mensen eigenlijk

[RobertMe]

Brahiewahiewa schreef op zondag 19 januari 2020 @ 17:38:
[...]

Jij kunt het je kennelijk permitteren om een paar honderd €uro te investeren in je gemoedstoestand.
Dat geld(t) niet voor iedereen ;o)

Dat is inderdaad een afweging die erin gemaakt moet worden. Maar hangt natuurlijk ook samen met backups & backup regime. In dit geval is één falende disk in mirror nogal crap (zeker nu het al 1,5e maand zo is). En in geval van PC ook een wake-up-call qua "er staat toch niks belangrijks op?".

Daarom nu ook maar even doorpakken met op z'n minst nog die extra Orange Pi waarop ook nog eens alles op een los systeem komt te staan (zodat bv een faal van NAS niet alle schijven kan slopen en alle backups alsnog weg zijn).

Maar zeker nu in de situatie waarin ik zit met dat de ene falende HDD nog niet goed is opgelost een tweede ook nog de geest geeft is het een zeer grote wake-up-call. Ook al is het 100% toeval, want andere schijven (2TB Green vs 2TB Blue), verschillende systemen (PC vs NAS), verschillende leeftijden (8 vs 3 jaar), verschillende draaiuren (??? voor PC vs 23.000 voor NAS), etc.

Maar gelukkig is het ook pas de tweede en derde keer dat ikzelf een falende HDD heb. Vorige was een Seagate Barracuda die een stuk sneller de geest gaf en daarin nogal hoorbaar was (NAS in de kelder, in de woonkamer hoorde je hem nog lawaai maken).

[zx9r_mario]

De read performance met L2ARC kun je opkrikken binnen FreeNAS door de parameters vfs.zfs.l2arc_write_max en vfs.zfs.l2arc_write_boost en eventueel vfs.zfs.l2arc_noprefetch aan te passen.

De read performance hiervan kun je hier zien YouTube: Accelerating FreeNAS to 10G with Intel Optane 900P

Standaard is dit 8MB en deze dan verhogen naar de max write speed van de L2ARC SSD. Er wordt dan wel veel meer weggeschreven naar de L2ARC SSD. Mij lijkt het wel aardig invloed te hebben op de levensduur van de SSD.

[GioStyle]

Ik zou graag van een pool de naam willen wijzigen.

Op internet lees ik dat ik de pool moet exporteren en dan weer weer importeren met de juiste naam.

Dus voorbeeld:

code:

zpool export data
zpool import data nieuwe_naam

Wat zijn de gevolgen als ik dit zo doe voor mijn smb shares? Moet ik die allemaal opnieuw aanmaken?

Zijn er nog andere gevolgen waar ik rekening mee moet houden?

OS is trouwens FreeNAS 11.2

[ Voor 8% gewijzigd door GioStyle op 23-01-2020 18:44 ]

[CurlyMo]

GioStyle schreef op donderdag 23 januari 2020 @ 18:23:
Wat zijn de gevolgen als ik dit zo doe voor mijn smb shares? Moet ik die allemaal opnieuw aanmaken?

SMB shares of samba configuratie niveau aangemaakt of als parameter van je ZFS? Op samba niveau is het natuurlijk afhankelijk van je mountpoints, die je weer zelf kan beïnvloeden.

[GioStyle]

Ja, ik kan in FreeNAS de mountpoints wijzigen. Ik heb 5 smb shares, dus dat is zo gebeurd.

Straks even proberen de naam van de pool te wijzigen.


Gedaan en gelukt. Heb het volgende gedaan:

- In GUI pool geëxporteerd
- 'zpool import old_name new_name
- 'zpool export new_name
- In Gui pool geïmporteerd

Mountpoints van de smb shares veranderd en alles werkt weer. Heb niet eens hoeven te rebooten.

[ Voor 47% gewijzigd door GioStyle op 23-01-2020 19:22 ]

[RobertMe]

Gisteren de Orange Pi 3 ontvangen om dan wat extra backups naar te maken.

Na wat trial & error werkt ZFS*, en nu bezig met Syncoid om de snapshots binnen te halen. Hiervoor heb ik een losse user gemaakt en met zfs allow vanalles toegestaan (eerlijk gezegd niet heel uitgebreid naar de specifieke permissies gekeken). Maar Syncoid geeft nu een permission error bij de rollback.

Uiteraard kan ik die rollback met allow ook toestaan. Maar uiteraard ben ik ook benieuwd wat het doet. En als ik het goed zie is een rollback het terugdraaien van alle bestandswijzigingen zodat alles weer gelijk is aan dat snapshot? En mijn directe gedachte daarna was dat ik natuurlijk überhaupt geen wijzigingen wil hebben in de backup. En als ik het goed zie kan dat ook door de dataset? mount? op readonly te zetten. Maar waarom zou Syncoid dan die rollback etc doen / waarom lijken andere backup oplossingen dat niet te doen? (heb nu znapzend ook nog draaien en die doet dat zo te zien niet)

Hoe denken jullie daar dus over / hoe doen jullie dat? Met rollback of zonder rollback? En in geval dan zonder dan wel met read only?

offtopic:
*

1. Armbian repo bevat kernel versie X maar headers Y, dat gaat natuurlijk niet werken om de kernel module te compilen
2. spl-dkms package compiled niet omdat er niks te compilen is...
3. Wat oudere versie (0.7 vs 0.8)
4. Dan maar zelf compilen, maar uit packaging instructies komt een deb package dat niet echt bij Buster past (geen systemd units en nog wat dingen)

Maar nu draait het dus met zelf compilen.

[FireDrunk]

Zag toevallig dit berichtje langskomen op de ZFS Mailing List:

Dear OpenZFS,

the last couple of months I have been working on getting L2ARC persistence to work in ZFSonLinux.
This effort was based on previous work by Saso Kiselkov (@skiselkov) in Illumos (https://www.illumos.org/issues/3525), which was later ported by Yuxuan Shui (@yshui) to ZoL (https://github.com/zfsonlinux/zfs/pull/2672), subsequently modified by Jorgen Lundman (@lundman), and rebased to master with multiple additions and changes by me (@gamanakis).

The end result is in: https://github.com/zfsonlinux/zfs/pull/9582

I would like to raise awareness about this upcoming feature and invite all to test and review the work done there.

Best regards,
George Amanakis

Toffe ontwikkeling!

[RobertMe]

Wat zijn hier nu de populaire opties qua auto snapshotting?

Ik ben begonnen met znapzend, maar vindt die als nadeel hebben dat die alleen snapshots naar remotes kan pushen. Terwijl ik liever "lokaal" de snapshots laat pullen van mijn VPS (en daarmee dus geen credentials (/ssh keys) op een extern systeem hoef te zetten).

Sanoid/syncoid is ook een erg populaire optie. Maar nadeeltje daarvan vind ik dan weer dat send/receive niet zit ingebakken in de configuratie maar dat je dat zelf moet doen (cronjob / systemd timer die syncoid uitvoert)

Maar ik kwam ook nog Pyznap tegen dat is gemaakt door iemand die niet helemaal tevreden was over Sanoid. O.a. dat Sanoid geen recursieve snapshots maakt (denk ik voor nu niet nodig te hebben), maar ook dat Sanoid niet de send/receive heeft ingebakken in de configuratie. In die zin lijkt mij dat dus ook wel wat.

Ik probeer nu alleen door de bomen het bos te zien wat nu het beste is. Nu heb ik dan znapzend draaien, maar nieuwe dingen met Sanoid. Maar eigenlijk neig ik nu meer naar pyznap. Maar wellicht zijn er nog andere/betere opties. Dus voordat ik nu weer op een derde spring eerst maar eens inventariseren wat de experts gebruiken

---

Met even snel zoeken in dit topic kwam ik deze post tegen:

unezra schreef op zondag 29 september 2019 @ 20:48:
Hmm.
For those interested.

1 grote onhebbelijkheid ontdekt van Sanoid: Het maakt snapshots aan in een formaat / naming dat niet compatible is met Windows Shadow Copy.

Vooralsnog voor mij een won't fix, ik laat het voor nu even zo, maar ga later toch een keer kijken of er een zfs snapshot én sender is (zoiets als sanoid/syncoid), die qua snapshots maken en senden het nodige werk uit handen neemt, maar wel dusdanig te configureren is dat de snapshots als Windows Shadow Copy zichtbaar zijn. (SMB snapt dit prima, het is echt Sanoid dat net kiest voor een naming waar SMB mee overweg kan.)

En intussen is er een oplossing voor: https://github.com/jimsal...42#issuecomment-580979656

code:

shadow: snapdir = .zfs/snapshot
shadow: sort = desc
shadow: format = %Y-%m-%d%H:%M:%S
shadow: snapprefix = ^autosnap
shadow: delimiter = _
shadow:localtime = yes

[CurlyMo]

Ik heb hier een zfs waarvan ik een incremental snapshot wil binnenhalen. Echter heb ik de volgende problemen:

code:

[root@server /usr/home/ssh]# ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null XXXX zfs send -RI array/Foto@auto-20200208.0007-1y array/Foto@auto-20200210.0007-1y | zfs receive -Fvu XXXX/users/Foto
receiving incremental stream of array/Foto@auto-20200209.0007-1y into XXXX/users/Foto@auto-20200209.0007-1y
cannot receive incremental stream: dataset is busy

Ik kom er niet achter waar hij "busy" mee is. Ik zie wel dit:

code:

zfs get receive_resume_token XXXX/users/Foto                                         NAME                PROPERTY              VALUE                                                                                                                                                                                                                                                                      SOURCE
XXXX/users/Foto  receive_resume_token  1-bac8dc692-d0-789c636064000310a500c4ec50360710e72765a526973030886c6402abc1904f4b2b4e2d01c9f8b1c2e4d990e4932a4b528b817487fab374172cfa4bf2d34b33531818dc4e4ef19f9a3ca5cd01499e132c9f97989bcac09058549458a9ef965f92ef90585a92af6b6460686900847a40c240d7289701090000d0351e13  -

Maar daar heb ik niks aan want een resume werkt niet:

code:

[root@server /usr/home/ssh]# ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null XXXXX zfs send -vt 1-bac8dc692-d0-789c636064000310a500c4ec50360710e72765a526973030886c6402abc1904f4b2b4e2d01c9f8b1c2e4d990e4932a4b528b817487fab374172cfa4bf2d34b33531818dc4e4ef19f9a3ca5cd01499e132c9f97989bcac09058549458a9ef965f92ef90585a92af6b6460686900847a40c240d7289701090000d0351e13 | zfs receive -Fdvu XXXX/users
resume token contents:
nvlist version: 0
        object = 0x2b114
        offset = 0x54e0000
        bytes = 0x4467e62788
        toguid = 0x869463954f94c946
        toname = array/Foto@auto-20190909.0900-2m
cannot resume send: 'array/Foto@auto-20190909.0900-2m' used in the initial send no longer exists
cannot receive: failed to read from stream

Nog raarder, ik kan de resume niet annuleren.

code:

[root@server /usr/home/ssh]# zfs recv -A XXXXX/users/Foto
'XXXX/users/Foto' does not have any resumable receive state to abort

Hoe los ik dit op zonder de hele zfs opnieuw binnen te moeten halen

[kattenbeld]

Hallo allemaal,

Ik ga mijn i3 -7300 systeem ombouwen tot een NAS.
Nu draait er gewoon Windows 10 op met shares welke ik vanaf mijn NVIDIA shield benader.
De NAS gaat enkel dienen om films/series op te slaan en te downloaden mbv sonarr en radarr via sabnzbd.

Ik heb 2 bestaande 2TB desktop hdd's, 2x WD RED 4TB en een 120GB SSD.

Ik hoef geen redundancy, het maakt niet uit als een een drive kapot gaat en als ik mijn data kwijt ben. er komt geen belangrijke data op te staan.

Ik zat eraan te denken om FreeNAS te gebruiken maar dan gewoon met stripes en geen RAID.

Is FreeNAS dan iets wat jullie aanraden of kan ik beter andere software gebruiken daarvoor?
Zou ik met FreeNAS wel gewoon gebruik kunnen maken van jails als ik alleen maar stripes heb.
Ik ben ook van plan om domoticz op deze server te installaren.

[CurlyMo]

Ik zou gewoon lekker Windows blijven draaien en daarin software raid configureren.

[jbhc]

Ik heb op zolder al een hele tijd een backup pc staan welke gebruik maakt van ZFSGuru. Omdat dit project nogal dood is (wat zou er toch gebeurd zijn met @Anoniem: 15758 ??) wil ik dit omzetten naar FreeNAS.

Kan ik gewoon FreeNAS installeren en dan de Pool daar importeren? Of is dit niet zo eenvoudig en zitten hier nog haken en ogen aan?

De kans op dataverlies is verder minimaal omdat ik ondertussen een Backup server voor de Backup server heb draaien waar de data op dit moment naartoe gekopieerd wordt maar ik ben benieuwd of mensen hier verder ervaring mee hebben.

[Q]

jbhc schreef op zaterdag 22 februari 2020 @ 15:55:
Ik heb op zolder al een hele tijd een backup pc staan welke gebruik maakt van ZFSGuru. Omdat dit project nogal dood is (wat zou er toch gebeurd zijn met @Anoniem: 15758 ??) wil ik dit omzetten naar FreeNAS.

Als je echt zeker wilt zijn kun je beter even in een VM een ZFSGURU install maken op basis van de versie die je draait. Test daarop je upgrade uit.

Voor wat betreft CiPHER, ik kan mij herinneren dat hij ok is maar dat hij wegens een nieuwe relatie er voor kiest om tijd aan andere dingen te besteden. Dit is geparafraseerd, ik weet niet of dit klopt.

Ah: Firedrunk wist meer:

brederodekater in "Het grote ZFS topic"

[ Voor 6% gewijzigd door Q op 22-02-2020 16:23 ]

[mdbraber]

Ik gebruik op mijn ZFS server encrypted datasets voor o.a. backups. Op dit moment zijn dat automatische backups en zijn de datasets altijd 'live' (encryption keys loaded). Wat ik overweeg is om de backups 'semi-live' te maken, door ze te starten vanaf een ander device, via bijv SSH dan de encryption keys te laden, en na de backup weer de encryption keys te unloaden.

Heeft er iemand ervaring met zo'n soort backup oplossing op basis van ZFS?

[CurlyMo]

mdbraber schreef op vrijdag 13 maart 2020 @ 09:59:
Heeft er iemand ervaring met zo'n soort backup oplossing op basis van ZFS?

Wat voor een ervaring zoek je? Als het voor je werkt, dan werkt het toch voor je

[mdbraber]

CurlyMo schreef op vrijdag 13 maart 2020 @ 10:04:
[...]

Wat voor een ervaring zoek je? Als het voor je werkt, dan werkt het toch voor je

Ik heb de oplossing die ik daarboven beschreef nog niet gemaakt, wellicht zijn er goede implementaties / scripts van hoe mensen zoiets al eerder hebben gedaan.

[CurlyMo]

mdbraber schreef op vrijdag 13 maart 2020 @ 10:16:
[...]


Ik heb de oplossing die ik daarboven beschreef nog niet gemaakt, wellicht zijn er goede implementaties / scripts van hoe mensen zoiets al eerder hebben gedaan.

Ik heb ooit wel eens blog gelezen van iemand die dat unlocken via een initramfs had geïmplementeerd. Dat lijkt me wel de netste weg.

[vanaalten]

Mja, weet niet of het is wat je bedoelt en sowieso niet ZFS gerelateerd, maar: hier een always-on machine en een backup-machine (die vrijwel altijd uit staat). Identiek geinstalleerd, beide met volledige LUKS harddisk-encryptie (uitgezonderd /boot).

's-Nachts wordt een cron-job gestart die met WOL de backup-machine wakker maakt. Die wacht vervolgens op een wachtwoord voor schijf-unlock - dat ook geautomatiseerd via SSH aangeleverd wordt, waarna de backup machine z'n backup-werk doet en zichzelf uitschakelt.

En dan inderdaad via initramfs een SSH server die op een alternatieve poort wacht voor het unlocken van de harddisk.

Werkt op zich prima. Voelt wat gekunsteld, maar zou geen betere oplossing kunnen bedenken. En wellicht is zo iets voor jou ook geschikt.

[FireDrunk]

Je hoeft toch niet perse bij boot dat te doen? Als je boot van USB / SSD en je ZFS array los mount kan je toch gewoon je systeem booten en dan het luks volume alleen niet unlocken?
Dan is het gewoon een pre-backup en post-backup script waarin luks geunlocked en weer gelocked wordt?

[nero355]

CurlyMo schreef op vrijdag 13 maart 2020 @ 10:19:
Ik heb ooit wel eens blog gelezen van iemand die dat unlocken via een initramfs had geïmplementeerd. Dat lijkt me wel de netste weg.

Volgens mij was er hier iemand op GoT die tijdens het booten een kleine BusyBox omgeving liet opstarten met SSH access om zodoende de boel te unlocken op afstand en daarna weer het normale OS in te laden

De server stond ergens als colo of gehuurd in een datacenter namelijk

[CurlyMo]

@FireDrunk Wat betreft ZFS on SMR. Wat is dan dan te raden voor een aparte PostgreSQL database en een aparte (C software) dev omgeving? Dat louter op SSD's doen (waar ook de root en de VM's op staan). Of SSD's als SLOG toevoegen?

[FireDrunk]

Dat ligt totaal aan de belasting. 1 query per minuut kan op een HDD, 1 per seconde bijna altijd ook wel.
(Hoewel het natuurlijk aan dr query ligt...)

Doorgaans krijg je in thuissituaties echt niet zomaar te maken met sitaties waarbij het ook maar iets boeit.

[vanaalten]

nero355 schreef op vrijdag 13 maart 2020 @ 15:05:
[...]

Volgens mij was er hier iemand op GoT die tijdens het booten een kleine BusyBox omgeving liet opstarten met SSH access om zodoende de boel te unlocken op afstand en daarna weer het normale OS in te laden

De server stond ergens als colo of gehuurd in een datacenter namelijk

Dat heb ik dus op mijn privé-server in de meterkast ook zo ingericht en is echt niet zo exotisch als het misschien klinkt - daar heeft Debian bijvoorbeeld gewoon standaard packages voor.
https://www.pbworks.net/u...unlock-luks-encrypted-pc/
...maar goed, dat is hier best wel off-topic, want heeft niets met ZFS te maken - meer als je complete OS op een encrypted disk staat, ongeacht welk filesystem er onder zit.