Het grote ZFS topic

[InflatableMouse]

RobertMe schreef op dinsdag 26 mei 2020 @ 18:35:
[...]

Wat beter en sneller/performanter is weet ik niet. Maar qua redundancy: bij RAIDZ2 kunnen er maximaal twee schijven uitvallen zonder dataverlies, omdat je de twee parity disks hebt. Bij de mirror + stripe kunnen er één t/m drie schijven uitvallen zonder dataverlies. Als je immers disk 1 & 2 in een mirror zet, en die striped met 3 & 4 en 5 & 6 dan heb je best een probleem als een mirror uitvalt (dus 1 & 2, of 3 & 4, of 5 & 6 tegelijkertijd uitvallen). Potentieel kunnen er bij een stripe + mirror dus meer schijven uitvallen, maar je loopt ook het risico dat er bij twee falende schijven al dataverlies is.

Ach ja natuurlijk. Er kunnen er max 3 uitvallen, maar inderdaad als de mirror sneuvelt van een disk die net zelf ook is gesneuveld, heb ik een probleem. Daar had ik even niet bij stil gestaan.

Eigenlijk is dat dus al geen optie.

Oke dus hoe regel ik de uitbreiding van een bestaande raidz1 pool van 3 disksen met 3 extra disken?

[CurlyMo]

InflatableMouse schreef op dinsdag 26 mei 2020 @ 19:22:
[...]


Ach ja natuurlijk. Er kunnen er max 3 uitvallen, maar inderdaad als de mirror sneuvelt van een disk die net zelf ook is gesneuveld, heb ik een probleem. Daar had ik even niet bij stil gestaan.

Eigenlijk is dat dus al geen optie.

Oke dus hoe regel ik de uitbreiding van een bestaande raidz1 pool van 3 disksen met 3 extra disken?

Eén schijf weghalen uit je RAIDZ1. Daarna een RAIDZ2 maken je 4 schijven en direct twee missende. Daarna data kopiëren van RAIDZ1 naar RAIDZ2. Als dat is gelukt je overgebleven RAIDZ1 schijven toevoegen aan je RAIDZ2. Er is geen mogelijkheid om zonder twee degraded array te zitten (zonder redundancy). Anders moet je er één schijf bij kopen.

[InflatableMouse]

CurlyMo schreef op dinsdag 26 mei 2020 @ 19:38:
[...]

Eén schijf weghalen uit je RAIDZ1. Daarna een RAIDZ2 maken je 4 schijven en direct twee missende. Daarna data kopiëren van RAIDZ1 naar RAIDZ2. Als dat is gelukt je overgebleven RAIDZ1 schijven toevoegen aan je RAIDZ2. Er is geen mogelijkheid om zonder twee degraded array te zitten (zonder redundancy). Anders moet je er één schijf bij kopen.

Ow? Ik meende altijd juist begrepen te hebben dat je een zfs pool alleen kon uitbreiden met een gelijk aantal schijven dat al in de pool zit (verdubbelen dus). Vandaar dat ik zelf al suggereerde om een van de raidz1 pools te verdubbelen naar een enkele raidz2 pool.

Nu zit ik daarover na te denken over wat je net uitlegt, ze bedoelen daarmee dus niet het totaal aantal disks maar het aantal minus de redundantie. In mijn geval 3 disks raidz1, 2 data disks, 1 redundant uitbreiden met 2 extra (totaal dus 5) maar nog steeds maar raidz1.

Een raidz2 van vier disks uitbreiden met 2 extra is dus een verdubbeling van het aantal datadisks.

Begrijp ik dat zo nu goed dan?

Ik heb overigens altijd minimaal 1 spare liggen, ik kan die alleen niet er bij aansluiten omdat alle sata aansluitingen vol zitten.

[dcm360]

Een raid-z-array is niet uit te breiden. Wat wel kan, is een zpool met daarin een raid-z-array uitbreiden door er een extra raid-z-array aan toe te voegen, in een soort van stripe. In de zpool wordt nieuwe data dan gebalanceerd tussen de 2 raid-z-arrays, oude data wordt niet verplaatst.

[CurlyMo]

InflatableMouse schreef op dinsdag 26 mei 2020 @ 19:53:
[...]
Begrijp ik dat zo nu goed dan?

Ik vind het lastig te volgen, maar wat @dcm360 klopt sowieso.

Ik heb overigens altijd minimaal 1 spare liggen, ik kan die alleen niet er bij aansluiten omdat alle sata aansluitingen vol zitten.

Liever een redundantie niveau hoger dan een spare disk. Dat eerste is een stuk veiliger.

[dcm360]

Nog ter aanvulling:

Conceptueel gezien bestaat een zpool uit vdevs, en data wordt verdeeld over deze vdevs. Een vdev kan een enkele disk zijn, een bestand, een mirror van meerdere disks, een raid-z-array of iets dat geen capaciteit toevoegt (cache, log of spare). Een mirror en een raid-z-array bestaan zelf dan weer uit meerdere vdevs (al heb je geen keuze uit de laatstgenoemde groep). Het enige type vdev waar je onderliggende vdevs aan kan toevoegen of uit kan verwijderen is de mirror. Ook kan je vdevs toevoegen aan een zpool, maar niet verwijderen tenzij het een vdev uit de laatste groep is.

[InflatableMouse]

Thanks!

Ik ben overigens niet nieuw met zfs, ik gebruik het hobbymatig al meer dan 6 jaar, exclusief op Arch Linux. Flink geexperimenteerd, onlangs nog met native encryptie, met eerder ook met slog en l2arc devices en in een gekke bui daar pci-e kaartjes met nvme drives voor gekocht (3x256GB). Heb Arch een tijdje ook met root op zfs gedraaid, echter te intensief qua aandacht dat dat nodig heeft.

Dit soort wijzigingen zoals uitbreiden of migreren doe ik eigenlijk nooit, vandaar de enigzins newbie vraagjes daarover.

De "nieuwe" setup wil ik een enkele pool hebben met dubbele redundantie. Geen l2arc meer, misschien nog een slog device maar dat wil ik eerst nog eens goed testen. Ik denk dat ik met die 3 nvme disks namelijk beter een pool kan maken om daar een specifieke workload op draaien zoals een databases voor een aantal vm's die op zich wel profiteerde van de slog, maar ik vermoed dat tie meer zullen profiteren van de snelheid van zo'n nvme-pool. Voor die nvme pool denk ik eraan geen redundantie te gebruiken, maar scheduled snapshots (elk uur of zo) en zfs send/receive met bookmarks te gebruiken naar de grote pool. In geval van failure is er max een uur weg, voor vm's in een lab omgeving geen enkel probleem.

Ik sta altijd open voor suggesties overigens!

[FireDrunk]

YouTube: Testing WD Red 4TB SMR vs CMR HDDs in a ZFS NAS Array - Skip SMR

TL:DR; Skip even naar ~3:20 & (vooral) ~4:20

https://www.servethehome....cmr-tested-avoid-red-smr/

* FireDrunk begint zich een beetje zorgen te maken...

[ Voor 43% gewijzigd door FireDrunk op 29-05-2020 14:54 ]

[Pantagruel]

FireDrunk schreef op vrijdag 29 mei 2020 @ 14:33:
YouTube: Testing WD Red 4TB SMR vs CMR HDDs in a ZFS NAS Array - Skip SMR

TL:DR; Skip even naar ~3:20 & (vooral) ~4:20

https://www.servethehome....cmr-tested-avoid-red-smr/

* FireDrunk begint zich een beetje zorgen te maken...

Dat kun je wel zeggen als je naar zijn commentaar luistert

Zit zelf met 5 WD Blue's (6 TiB, WD60EZAZ) in een ZFS pool van 7 stuks in totaal (RAID-Z1). Ik zie op zich geen rare dingen als kicks ofzo, maar krijgt kloppingen bij de gedachte aan een ZFS replace en t volgende slachtoffer dat op de loer ligt.

De vraag is wat is wijsheid, nu al cold spares aanschaffen (CMR drives) of de hele pool uit voorzorg al vervangen en deze 'SMR pool of death' in de back-up server steken (gaat 1x per week aan).

[ Voor 31% gewijzigd door Pantagruel op 29-05-2020 18:06 . Reden: them blue's dabedi dabeda.... ]

[CurlyMo]

FireDrunk schreef op vrijdag 29 mei 2020 @ 14:33:
YouTube: Testing WD Red 4TB SMR vs CMR HDDs in a ZFS NAS Array - Skip SMR

TL:DR; Skip even naar ~3:20 & (vooral) ~4:20

https://www.servethehome....cmr-tested-avoid-red-smr/

* FireDrunk begint zich een beetje zorgen te maken...

Een aantal dingen:
1. Ze vertellen niet welke ZFS versie ze hebben gebruikt en of dat dus met sequential scrub and resilver is.
2. Het is bekend dat alle load dient te stoppen zolang ze resilveren. Doe dat dan ook.
3. Het is bekend dat dan nog een resilver lang duurt.

Oftewel, hou er rekening mee.

Ik ben van plan een drie weg mirror te maken, nu nog twee-weg mirror.

Nog weer wat later ben ik van plan om twee twee-weg mirror pools te maken. De meeste data zal ik dan enkelvoudig balanceren tussen beide pools. De belangrijkste data zal ik dan semi-synchroon houden tussen beide pools. Dan is volgens mij voor deze soort pools de best-practice. Helemaal omdat je reads en writes bij een resilver zo synchroon mogelijk te houden zijn.

Ik geloof niet dat er dan nog véél risico is, maar SMR 5TB schijven zijn dan nog steeds wel een stuk goedkoper en zuiniger.

Via een incrontab is vrij makkelijk aan de hand van filesystem events een synchronisatieschema te starten zodat je data semi-realtime synchroon blijft.

[FireDrunk]

Oh zeker, allemaal valide. Maar wat hij ook wel zegt. Het is intended use... Je moet in theorie je pool kunnen gebruiken ondertussen. Ook met ZFS...

Ik zie een resilver van 16 dagen niet echt zitten....

[CurlyMo]

FireDrunk schreef op vrijdag 29 mei 2020 @ 18:04:
Oh zeker, allemaal valide. Maar wat hij ook wel zegt. Het is intended use... Je moet in theorie je pool kunnen gebruiken ondertussen. Ook met ZFS...

Ik zie een resilver van 16 dagen niet echt zitten....

Dan moet je dus geen SMR gebruiken.

Als je overigens je cruciale data semi-synchroon houdt tussen twee pools, dan kan je gewoon door met gebruiken van de werkende pool.

[ Voor 16% gewijzigd door CurlyMo op 29-05-2020 18:18 ]

[mdbraber]

Ik ben een Kubernetes setup aan het maken en wil daar eerst virtueel mee experimenteren. Mijn idee is om ZFS op de worker nodes te gebruiken (via OpenEBS). Ik kan vrij makkelijk een ZVOL via Proxmox bij iedere worker node maken en daar in de node ZFS op draaien. Ik had alleen gehoopt dat ik die ZVOL ook als ZFS buiten de node kon mounten. Ik krijg echter met zpool import -d /dev/zvol/rpool/vmdata/vm-103-disk-1 geen pools te zien. Klopt dit of zou het mogelijk moeten zijn om een "ZFS in een ZVOL" te mounten?

/EDIT: ik had het niet door, maar er zijn op de ZVOL 2 partities, dit werkt wel: zpool import -d /dev/zvol/rpool/vmdata/vm-103-disk-1-part1

[ Voor 12% gewijzigd door mdbraber op 01-06-2020 22:24 ]

[CurlyMo]

@mdbraber Weet je zeker dat er zfs in je KVM machines draaien? Anders dient de zvol's eerst tot loop devices te maken met kpartx.

[FireDrunk]

Nou het moment is daar. 1 van de schijven in mijn RAIDZ2 pool van 6 SMR schijven is geen hemelen na een geplande scrub. (440 reallocated sectors and counting)

Nieuwe schijf is besteld, nu maar kijken wat de rebuild gaat doen...

[CurlyMo]

FireDrunk schreef op zondag 14 juni 2020 @ 10:52:
Nou het moment is daar. 1 van de schijven in mijn RAIDZ2 pool van 6 SMR schijven is geen hemelen na een geplande scrub. (440 reallocated sectors and counting)

Nieuwe schijf is besteld, nu maar kijken wat de rebuild gaat doen...

En vooral wat de rebuild gaat doen bij het compleet uitschakelen van andere activiteit op die schijven.

[FireDrunk]

Mja, dat was ik niet eens van plan

[CurlyMo]

FireDrunk schreef op zondag 14 juni 2020 @ 11:31:
Mja, dat was ik niet eens van plan

Voor de validatie is dat wel een goeie aanvulling. Deel met andere activiteit en deel zonder.

[BCC]

Tijdens de installatie van Ubuntu Focal heb ik in al mijn wijsheid ZFS als boot medium gekozen op een enkele nvme drive. Nou is de implementatie daarvan op dit moment nogal... bijzonder. Wat ik vooral vreemd vind is dat het heel veel iowaits oplevert op een nvme drive. Heeft iemand hier ervaring mee en misschien wat tweak tips? Anders wordt het denk ik een herinstall van het os op ext4 oid.

[ Voor 3% gewijzigd door BCC op 15-06-2020 07:55 ]

[XAEROCOOL]

Hallo allemaal,

Ik heb weer hulp nodig.
Een tijdje geleden had ik het volgende systeem samengesteld:

#	Category	Product	Prijs	Subtotaal
1	Moederborden	Supermicro X10SDV-8C-TLN4F	€ 943,23	€ 943,23
6	Interne harde schijven	WD Green HDD, 6TB	€ 0,-	€ 0,-
1	Behuizingen	Fractal Design Node 304 Wit	€ 74,75	€ 74,75
1	Ventilatoren	be quiet! Shadow Wings PWM, 140mm	€ 21,49	€ 21,49
1	Ventilatoren	Noctua NF-A6x25 PWM, 60mm	€ 14,14	€ 14,14
1	Geheugen intern	Samsung M393A4K40BB1-CRC	€ 203,34	€ 203,34
1	Voedingen	Seasonic G-series 450 watt	€ 0,-	€ 0,-
1	Solid state drives	Crucial MX200 M.2 80mm 500GB	€ 0,-	€ 0,-
Bekijk collectie Importeer producten			Totaal	€ 1.256,95

Waar zfsguru was geconfigureerd volgens de suggesties:
1) Bootstrap partition (automatically created by ZFSguru) 1MiB
2) SWAP partition: 4GiB to maximum of RAM size
3) sLOG partition for sLOG (dedicated ZIL) of your HDD pool: 4GiB
4) L2ARC partition for your HDD pool: 60GiB
5) System partition for ZFSguru and your VM images: 120GiB
https://gathering.tweaker...message/46160751#46160751

Nu wil ik overstappen naar FreeNas vanwege toekomst zfsguru.
Ik heb nu freenas geinstalleerd op een usbstick en vanaf daar de pools geimporteerd om te testen en dat lijkt goed te werken.
Maar welke stappen moet ik nemen om de freenas op de m.2 schijf te installeren met de bovengenoemde suggesties voor swap, slog, etc.
Is alles wel mogelijk op freenas en heb ik het nog steeds nodig?

Om samen te vatten:
Ik heb een systeem met 6 HDDs van 6TB die een ZFS2 pool vormen waar alleen maar data opgeslagen wordt.
Er is een M.2 SLC ssd beschikbaar voor de OS
Ram is 32GB
huidige situatie te zien in freenas:


Graag een aanwijzing in de goede richting. Alvast bedankt.

[Chocola]

XAEROCOOL schreef op zondag 14 juni 2020 @ 21:44:
Hallo allemaal,

Ik heb weer hulp nodig.

Waar zfsguru was geconfigureerd volgens de suggesties:
1) Bootstrap partition (automatically created by ZFSguru) 1MiB
2) SWAP partition: 4GiB to maximum of RAM size
3) sLOG partition for sLOG (dedicated ZIL) of your HDD pool: 4GiB
4) L2ARC partition for your HDD pool: 60GiB
5) System partition for ZFSguru and your VM images: 120GiB
https://gathering.tweaker...message/46160751#46160751

Nu wil ik overstappen naar FreeNas vanwege toekomst zfsguru.
Ik heb nu freenas geinstalleerd op een usbstick en vanaf daar de pools geimporteerd om te testen en dat lijkt goed te werken.
Maar welke stappen moet ik nemen om de freenas op de m.2 schijf te installeren met de bovengenoemde suggesties voor swap, slog, etc.
Is alles wel mogelijk op freenas en heb ik het nog steeds nodig?

Om samen te vatten:
Er is een M.2 SLC ssd beschikbaar voor de OS
Ram is 32GB
Graag een aanwijzing in de goede richting. Alvast bedankt.

1. Heb je per se SLOG en/of L2ARC nodig? Voegt complexiteit en evt. later ook beperkingen toe terwijl dat in de meeste gevallen helemaal niet nodig is. 32 GB ram is niet superveel voor FreeNAS-begrippen, maar voor zo een klein pooltje is het dikke prima.
2. Voor de installatie van FreeNAS (boot) heb je aan elke SSD (liefst met power protection) genoeg. Dus ook een MLC, TLC, QLC of zelfs een simpele SATA DOM SSD is meer dan adequaat voor FreeNAS. Dan kun je het dure SLC-NAND lekker voor iets nuttigers gebruiken. Zelfs een HDD of USB-stick werkt als bootschijf, maar dit raad ik nooit aan vanwege de beperkte betrouwbaarheid.
3. Ik vind 4GB voor SLOG wat gek, want als je totale bandbreedte beperkt is door gigabit dan is ~600 MB voldoende, terwijl 10 Gb/s eerder zo een ~6GB is. Of heb je het op basis van de totale snelheid van de pool toegerust ofzo?
4. Niet dat het een regel is, maar ik zou sowieso denk ik zelf caching fysiek willen scheiden van de bootschijf. Het kost je een SATA- of NVMe-slot, maar als je maar zes schijfjes hebt dan heb je er daar waarschijnlijk nog genoeg van.

Tl;dr weet je zeker dat je caching nodig hebt voor jouw use-case? Zo nee: dan raad ik je af om dit te configureren. Less == more .

[Giesber]

Chocola schreef op maandag 15 juni 2020 @ 01:16:
[...]
2. Voor de installatie van FreeNAS (boot) heb je aan elke SSD (liefst met power protection) genoeg. Dus ook een MLC, TLC, QLC of zelfs een simpele SATA DOM SSD is meer dan adequaat voor FreeNAS. Dan kun je het dure SLC-NAND lekker voor iets nuttigers gebruiken. Zelfs een HDD of USB-stick werkt als bootschijf, maar dit raad ik nooit aan vanwege de beperkte betrouwbaarheid.

Met die beperkte betrouwbaarheid van een USB stick valt het in de praktijk nog wel mee, aangezien je FreeNAS kan instellen dat hij daar niet naar schrijft. Enkel bij updates zal er naar de stick geschreven worden, dus dat valt nog wel mee. Er is zelfs een procedure voorzien om 2 sticks tegelijk te gebruiken, zodat er altijd 1 kan uitvallen.

Hier draait de server al een jaar of 5 op een stick. Er ligt hier nog wel een reserve, en ik maar regelmatig een backup van mijn configuratie. Bij een defect ben ik normaal gezien rap weer up and running.

Moest je een stick gebruiken, koop dan wel een degelijke. Pik er geen uit de budgetbak in de Action of zo.

[Q]

Chocola schreef op maandag 15 juni 2020 @ 01:16:
32 GB ram is niet superveel voor FreeNAS-begrippen

Ik vind het idee een beetje gek dat 32 GB niet veel is voor FreeNAS / ZFS. Dat is meer dan zat. Verder ben ik het eens met je opmerkingen / advies.

[ Voor 9% gewijzigd door Q op 15-06-2020 12:24 ]

[Kaspers]

XAEROCOOL schreef op zondag 14 juni 2020 @ 21:44:
Nu wil ik overstappen naar FreeNas vanwege toekomst zfsguru.

Wat is de reden om nu te kiezen voor FreeNas, nu je wegbeweegt van zfsguru?
Heb je Ubuntu + Cockpit ZFS manager ook overwogen? Ik merk dat ZFS support binnen Ubuntu alsmaar beter wordt, en met ZFS support in de laatste LTS zit het qua stabiliteit wel aardig goed.

[FireDrunk]

Misschien ben ik wel gek, maar je vraagt heel simpel wat je moet doen om FreeNAS op de M.2 drive te krijgen.

Ik zou zeggen

- Verwijder SLOG en L2ARC
- Exporteer je pool
- Koppel al je drives behalve de M.2. los
- Installeer FreeNAS op de schijf.
- Koppel al je drives weer aan.
- Importeer je pool.

En eens met @Kaspers, FreeBSD is voor mij wel een beetje passe, dus als je FreeNAS alleen wil gebruiken vanwege ZFS support, zou ik dat niet doen. Als je het gebruikt vanwege ease-of-use, is het een prima keuze.

[Paul]

Ligt er aan waar je het voor inzet. FreeNAS zelf wil iets meer (8 GB minimum, al kom je soms weg met minder), voor ZFS zelf is het na de eerste (paar?) honderd MB is het toch voornamelijk cache.

[ Voor 3% gewijzigd door Paul op 15-06-2020 13:03 ]

[XAEROCOOL]

Bedankt voor jullie antwoorden.

- SLOG en L2ARC kan dus weg.
- Over de schijven, op de moederbord zijn er maar 6 sata poorten en een m.2 poort, welk nu allemaal gevuld zijn. Het is wel uit te bereiden met een pci-e slot maar zelfs dan is er geen plaats meer in de kast voor meer HDD os SSD schijven. Extra m.2 schijven zouden ook dan ook wel een beetje te veel zijn om boot en cache te scheiden.
Ik ben dus van plan om m.2 te gebruiken als boot en OS gerelateerd handelingen.
- RAM kan altijd verhoogd worden als het blijkt dat het niet genoeg is, voor nu hou ik het zoals het is en kijk ik hoe het gaat.
- Freenas leek mij een logische keuze, ik had niet aan ubuntu gedacht.
Ik gebruik het systeem voornamelijk als zfs opslag en af en toe voor VMs en nog een aantal andere plugin programma's.

Ik wil wel eerst ubuntu uit proberen, welke versie raden jullie aan?
Ik heb een en ander gelezen en er wordt debian aangeraden, maar wat vinden jullie?
Weten jullie een betrouwbare pagina met een how to install and configure ubuntu server?

Nogmaals bedankt.

[CurlyMo]

@XAEROCOOL ik zou proxmox proberen. Kan je gelijk met VM's of containers aan de slag.

[Giesber]

XAEROCOOL schreef op maandag 15 juni 2020 @ 19:20:
Bedankt voor jullie antwoorden.

- SLOG en L2ARC kan dus weg.
- Over de schijven, op de moederbord zijn er maar 6 sata poorten en een m.2 poort, welk nu allemaal gevuld zijn. Het is wel uit te bereiden met een pci-e slot maar zelfs dan is er geen plaats meer in de kast voor meer HDD os SSD schijven. Extra m.2 schijven zouden ook dan ook wel een beetje te veel zijn om boot en cache te scheiden.
Ik ben dus van plan om m.2 te gebruiken als boot en OS gerelateerd handelingen.
- RAM kan altijd verhoogd worden als het blijkt dat het niet genoeg is, voor nu hou ik het zoals het is en kijk ik hoe het gaat.
- Freenas leek mij een logische keuze, ik had niet aan ubuntu gedacht.
Ik gebruik het systeem voornamelijk als zfs opslag en af en toe voor VMs en nog een aantal andere plugin programma's.

Ik wil wel eerst ubuntu uit proberen, welke versie raden jullie aan?
Ik heb een en ander gelezen en er wordt debian aangeraden, maar wat vinden jullie?
Weten jullie een betrouwbare pagina met een how to install and configure ubuntu server?

Nogmaals bedankt.

Freenas was voor mij vroeger een logische keuze, omdat ZFS on Linux nog wat "experimenteel" aanvoelde een vijftal jaar geleden. Vooral de licensing leek misschien nog voor problemen te kunnen zorgen.
Tegenwoordig lijkt ZFS op Linux een heel goede keuze. Het enige waarvoor je Freenas nog kan overwegen is de webinterface en het plugin systeem, waardoor je een volledige server kan opzetten (met Nextcloud/Plex/...) zonder de commandline aan te raken.

Verder is SLOG en L2ARC schrappen een goed idee bij thuisgebruik/licht gebruik, en lijkt 32GB zat genoeg. Als Freenas daarmee vlot uit de voeten kan gaat Linux dat ook kunnen.

[FireDrunk]

root@nas:~# zpool status
  pool: archivev2
 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 Jun 16 18:06:14 2020
        385G scanned at 21.4G/s, 135M issued at 7.49M/s, 8.62T total
        0B resilvered, 0.00% done, no estimated completion time
config:

        NAME                      STATE     READ WRITE CKSUM
        archivev2                 DEGRADED     0     0     0
          raidz2-0                DEGRADED     0     0     0
            ST-WDZ5EL7E           ONLINE       0     0     0
            ST-WDZ5EKBK           ONLINE       0     0     0
            ST-WDZ5G0TB           ONLINE       0     0     0
            ST-WDZ5G06A           ONLINE       0     0     0
            ST-WDZ5EKNF           ONLINE       0     0     0
            replacing-5           DEGRADED     0     0     0
              743745518414247252  UNAVAIL      0     0     0  was /dev/disk/by-partlabel/ST-WDZ5G0P4
              ST-WDZQ8GPQ         ONLINE       0     0     0

errors: No known data errors

*fingers crossed*

_{Online replace kan niet, niet genoeg sata poorten.}

[Q]

FireDrunk schreef op dinsdag 16 juni 2020 @ 18:06:
> failed drive <

Geen SMR hoop ik

offtopic:
Ik ben vergeten welke schijven jij gebruikte in je systeem.

offtopic:
Tijdens het schrijven aan mijn "don't be afraid of RAID" artikel ervaarde ik ook een failed drive tijdens een scrub (MDADM). Heel veel bad sectors. Dat was wel ironie

Als jij regelmatig je disks scrubt dan heb ik er alle vertrouwen in.
Edit: En met een RAIDZ2 is er eigenlijk helemaal niets aan de hand.

[ Voor 12% gewijzigd door Q op 16-06-2020 19:07 ]

[Freeaqingme]

FireDrunk schreef op dinsdag 16 juni 2020 @ 18:06:
_{Online replace kan niet, niet genoeg sata poorten.}

usb naar sata connector? Vertraagt wel je hele vdev tot de lowest common denominator.

[RobertMe]

Q schreef op dinsdag 16 juni 2020 @ 19:05:
[...]


Geen SMR hoop ik

offtopic:
Ik ben vergeten welke schijven jij gebruikte in je systeem.

Dat had hij al aangegeven:

FireDrunk schreef op zondag 14 juni 2020 @ 10:52:
Nou het moment is daar. 1 van de schijven in mijn RAIDZ2 pool van 6 SMR schijven is geen hemelen na een geplande scrub. (440 reallocated sectors and counting)

Nieuwe schijf is besteld, nu maar kijken wat de rebuild gaat doen...

Ik denk dus dat hij peentjes zit te zweten
Voordeel is dan wel de RAIDZ2 waarschijnlijk waardoor die niet neem ik aan niet heel snel compleet zal falen. Voornaamste zal lijkt mij zijn dat de rebuild extreem traag zal gaan. Maar kans op (read) failures zal niet groter zijn dan bij CMR/PMR schijven.

[CurlyMo]

RobertMe schreef op dinsdag 16 juni 2020 @ 19:11:
[...]
Voornaamste zal lijkt mij zijn dat de rebuild extreem traag zal gaan.

Als je doorgaat met je normale gebruik inderdaad wel.

[FireDrunk]

Ik zweet absoluut geen peentjes.
Het is RAIDZ2, dus kapot gaat het niet.
En ik heb een recente versie van ZFS die beter werkt icm SMR. Ik verwacht dat alle tests van STH op FreeNAS gedaan zijn, welke die verbeteringen nog niet heeft.

@CurlyMo ik heb alle services nog aan laten staan. Eerst eens kijken hoe het gaat. Als het te lang gaat duren doen we gewoon "systemctl stop docker" en dan is het stil

root@nas:~#
root@nas:~# zpool status
  pool: archivev2
 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 Jun 16 18:06:14 2020
        3.37T scanned at 724M/s, 1.27T issued at 272M/s, 8.62T total
        216G resilvered, 14.68% done, 0 days 07:52:32 to go
config:

        NAME                      STATE     READ WRITE CKSUM
        archivev2                 DEGRADED     0     0     0
          raidz2-0                DEGRADED     0     0     0
            ST-WDZ5EL7E           ONLINE       0     0     0
            ST-WDZ5EKBK           ONLINE       0     0     0
            ST-WDZ5G0TB           ONLINE       0     0     0
            ST-WDZ5G06A           ONLINE       0     0     0
            ST-WDZ5EKNF           ONLINE       0     0     0
            replacing-5           DEGRADED     0     0     0
              743745518414247252  UNAVAIL      0     0     0  was /dev/disk/by-partlabel/ST-WDZ5G0P4
              ST-WDZQ8GPQ         ONLINE       0     0     0  (resilvering)

errors: No known data errors

Gaat prima met 270MB/s, planning is dus 8h, dat is sneller dan verwacht

[ Voor 88% gewijzigd door FireDrunk op 16-06-2020 19:28 ]

[RobertMe]

CurlyMo schreef op dinsdag 16 juni 2020 @ 19:20:
[...]

Als je doorgaat met je normale gebruik inderdaad wel.

Zal lijkt mij ook maar er aan liggen. SMR zal ook issues geven als het CMR deel vol is, eventueel met een volle schijf verder. Gezien de 270MB/s die @FireDrunk nu aangeeft zou het ook best kunnen dat de HDD nu wel snel kan schrijven doordat die nog niet in shingles schrijft en die alsnog later tegen de lamp loopt. Maar kan uiteraard ook zijn dat de performance fixes van ZoL 0.8 een flink steentje bijdragen.

Zelf heb ik afgelopen weekend een send & receive gedaan naar een beruchte 2,5" 5TB Seagate. Ging om een paar honderd GB en van wat ik zo zag heeft die lange tijd op XMB/s gelopen (dus ja, single digit / < 10MB/s). Ben er verder niet in gedoken, maar gevoelsmatig moet het issue daarbij ook aan de SMR schijf gelegen hebben. Vandaar dat ik naderhand in het zuinige server topic nog heb gevraagd of je deze Seagates niet kunt TRIMmen, wat bij de WDs dan wel kan. Overigens hangt die Seagate aan een Orange Pi puur als "extra" backup, moet ooit nog off site worden geplaatst, maar verder draait dus niks erop. En bron was een oudere WD CMR schijf dus ik verwacht niet dat daar het issue in zat.

[FireDrunk]

270MB/s haal je zelfs op een CMR 10k 3.5" schijf niet. Dus ik verwacht dat dat een fout berekend gemiddelde is.

[RobertMe]

FireDrunk schreef op dinsdag 16 juni 2020 @ 19:41:
270MB/s haal je zelfs op een CMR 10k 3.5" schijf niet. Dus ik verwacht dat dat een fout berekend gemiddelde is.

Dat was ik mij ook al aan het afvragen ja... Waarschijnlijk dat die dus een volledige scrub/resilver doet, en data op deze disk niet nodig is? Alhoewel juist bij RAIDZ alle disks nodig zijn omdat of striped data erop staat of de parity?

[FireDrunk]

Hij scanned ook over lege blocks heen denk ik. En rekent parity mee.

[CurlyMo]

FireDrunk schreef op dinsdag 16 juni 2020 @ 19:24:
Gaat prima met 270MB/s, planning is dus 8h, dat is sneller dan verwacht

Heb je geen live stream? Kunnen we allemaal meekijken.

[FireDrunk]

Zal eens kijken of ik de output kan automatiseren, leuk mini projectje

root@nas:~# zpool status
  pool: archivev2
 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 Jun 16 18:06:14 2020
	3.83T scanned at 341M/s, 2.19T issued at 195M/s, 8.62T total
	373G resilvered, 25.37% done, 0 days 09:37:29 to go
config:

	NAME                      STATE     READ WRITE CKSUM
	archivev2                 DEGRADED     0     0     0
	  raidz2-0                DEGRADED     0     0     0
	    ST-WDZ5EL7E           ONLINE       0     0     0
	    ST-WDZ5EKBK           ONLINE       0     0     0
	    ST-WDZ5G0TB           ONLINE       0     0     0
	    ST-WDZ5G06A           ONLINE       0     0     0
	    ST-WDZ5EKNF           ONLINE       0     0     0
	    replacing-5           DEGRADED     0     0     0
	      743745518414247252  UNAVAIL      0     0     0  was /dev/disk/by-partlabel/ST-WDZ5G0P4
	      ST-WDZQ8GPQ         ONLINE       0     0     0  (resilvering)

errors: No known data errors

Snelheid is al aan het afnemen.

Via netdata zie ik al erg grillig gedrag van de schijven. Het gaat een beetje met horten en stoten. Nou is een replace volgens mij wel vaker met vlagen 'horterig', dus we gaan het zien.

Low zijn 3-4MB/s, 'high' is nu ~60-80MB/s. (Volgens netdata)

[Q]

FireDrunk schreef op dinsdag 16 juni 2020 @ 19:24:
Gaat prima met 270MB/s, planning is dus 8h, dat is sneller dan verwacht

Ik heb even zitten rekenen: als het tijdstip van je 2e post vrijwel gelijk is aan de tijdsduur tussen het moment van starten en dat moment:

Ik kom op een schrijfsnelheid van 218 GB / 78 minuten = ~46 MB/s. Dat lijkt me geen gekke waarde aangezien het hier om SMR schijven blijkt te gaan.

Je zou eens kunnen kijken met iostat of zpool iostat 10 of dit klopt. Ik ben wel benieuwd. Wat eigenlijk het meest interessant is, is de schrijfsnelheid richting de nieuwe schijf.

Gelukkig is de dataset van ongeveer 8+ TB niet zo heel groot, dus die ~8 uur valt mee. Maar als iemand met bijvoorbeeld een dataset zit van - pak 'm beet - 30 TB heeft, wat tegenwoordig niet meer zo gek is, dan zou dat al snel zo'n 30 uur duren om een schijf te herstellen, als ik mij niet vergis.

Dat is relatief langzaam, maar super erg is dat niet, zeker niet als je regelmatig scrubt. De enige vraag is dus of de schijf de snelheid - ook al is die niet hoog - gewoon constant vast kan houden zonder extreme latency of timeouts.


Edit: als je ook wat mappen met veel kleine bestanden hebt dan is het volgens mij normaal dat de snelheid wat afneemt. Ik hoop dat de bulk grote files zijn.

CurlyMo schreef op dinsdag 16 juni 2020 @ 20:09:
[...]

Heb je geen live stream? Kunnen we allemaal meekijken.

[Afbeelding]

Firedrunk weet wel hoe hij het hier een beetje spannend kan houden

[ Voor 16% gewijzigd door Q op 16-06-2020 21:35 ]

[FireDrunk]

U vraagt, wij draaien:

http://prv.cloud:10000



@Q Pool bestaat voor 98% uit grote files (media archief ), er zitten wel wat backups tussen (van andere systemen) waar wat directories met veel bestanden in zitten, maar qua grootte zal dat hooguit 200GB zijn.

[ Voor 67% gewijzigd door FireDrunk op 16-06-2020 22:26 ]

[CurlyMo]

FireDrunk schreef op dinsdag 16 juni 2020 @ 22:19:
U vraagt, wij draaien:

http://prv.cloud:10000

Ik maar op refresh drukken, heeft hij maar een interval van een minuut

[FireDrunk]

CurlyMo schreef op dinsdag 16 juni 2020 @ 22:26:
[...]

Ik maar op refresh drukken, heeft hij maar een interval van een minuut

Ja, ik ben niet gek, hij voert het commando natuurlijk niet direct uit.
Zit ik mijn server hier te rebuilden, ga jij dat ding DDOS-en

[CurlyMo]

FireDrunk schreef op dinsdag 16 juni 2020 @ 22:27:
[...]


Ja, ik ben niet gek, hij voert het commando natuurlijk niet direct uit.
Zit ik mijn server hier te rebuilden, ga jij dat ding DDOS-en

Samen met @Q @RobertMe @Freeaqingme @Paul was dat inderdaad ons idee. Een beetje load creëren op die server van je.

[FireDrunk]

Leef je uit, voordat je met dat piepkleine beetje flat html traffic die server plat legt, heb ik al een mailtje van netdata dat ie het te druk heeft

Die data staat gelukkig op de boot SSD, dus de pool wordt er niet mee lastig gevallen.

[CurlyMo]

FireDrunk schreef op dinsdag 16 juni 2020 @ 22:30:
Leef je uit, voordat je met dat piepkleine beetje flat html traffic die server plat legt, heb ik al een mailtje van netdata dat ie het te druk heeft

Die data staat gelukkig op de boot SSD, dus de pool wordt er niet mee lastig gevallen.

Nou weet je alleen wel mijn ip

[FireDrunk]

CurlyMo schreef op dinsdag 16 juni 2020 @ 22:32:
[...]

Nou weet je alleen wel mijn ip

Niet eens, mijn router doet gewoon een port-forward, dus geen X-Forwarded-For headers.

[Q]

FireDrunk schreef op dinsdag 16 juni 2020 @ 22:19:
U vraagt, wij draaien:

http://prv.cloud:10000

@Q Pool bestaat voor 98% uit grote files (media archief ), er zitten wel wat backups tussen (van andere systemen) waar wat directories met veel bestanden in zitten, maar qua grootte zal dat hooguit 200GB zijn.

Nou, dan zou het wel goed gaan. Doe je ook aan largefiles of largeblocks (hoe het heet in ZFS)?

[FireDrunk]

Nee, heb geen extra grote recordsize (1MB kan tegenwoordig dacht ik). Staat gewoon op 128K.
Compression staat wel overal aan.

[ Voor 16% gewijzigd door FireDrunk op 16-06-2020 22:35 ]

[Q]

CurlyMo schreef op dinsdag 16 juni 2020 @ 22:32:
[...]

Nou weet je alleen wel mijn ip

Dat is het minste van je problemen. Firedrunk heeft je computer nu gehacked via de browser met een unicode character parsing zero-day. Gerafineerd hoor.

FireDrunk schreef op dinsdag 16 juni 2020 @ 22:34:
Nee, heb geen extra grote recordsize (1MB kan tegenwoordig dacht ik). Staat gewoon op 128K.

Misschien voor de toekomst qua space efficiency wel handig. Dat ik destijds mijn NAS 7+ jaar geleden opzette kon dat niet en dat scheelt een hoop capaciteit.

Ik denk - weet het niet zeker - dat daardoor ook resilvers nog wel vlotter zullen gaan.

[ Voor 42% gewijzigd door Q op 16-06-2020 22:36 ]

[CurlyMo]

FireDrunk schreef op dinsdag 16 juni 2020 @ 22:19:
@Q Pool bestaat voor 98% uit grote files (media archief ), er zitten wel wat backups tussen (van andere systemen) waar wat directories met veel bestanden in zitten, maar qua grootte zal dat hooguit 200GB zijn.

Die grote bestanden boeit volgens mij nauwelijks meer met de sequential scrub and resilver.

[FireDrunk]

Q schreef op dinsdag 16 juni 2020 @ 22:35:
Misschien voor de toekomst qua space efficiency wel handig. Dat ik destijds mijn NAS 7+ jaar geleden opzette kon dat niet en dat scheelt een hoop capaciteit.

Ik denk - weet het niet zeker - dat daardoor ook resilvers nog wel vlotter zullen gaan.

Ik heb 6 schijven in RAIDZ2, dus met 128K records is dat 32KB per disk. Dus geen verlies (mits de records vol geschreven worden uiteraard).

[RobertMe]

CurlyMo schreef op dinsdag 16 juni 2020 @ 22:37:
[...]

Die grote bestanden boeit volgens mij nauwelijks meer met de sequential scrub and resilver.

Volgens mij bedoelde @Q het juist andersom. Kleine bestanden die de boel vertragen. Maar ook daarbij heb je denk ik gelijk. Door de sequential scrub & resilver doet die IIRC alles op sector/blok volgorde? Dus dan leest die toch al alles "achter elkaar" en niet op basis van filesystem hiërarchie. Grote bestanden waren uiteraard al sequential reads.

[CurlyMo]

RobertMe schreef op dinsdag 16 juni 2020 @ 22:43:
[...]

Dus dan leest die toch al alles "achter elkaar" en niet op basis van filesystem hiërarchie. Grote bestanden waren uiteraard al sequential reads.

Dat inderdaad.

[FireDrunk]

Je zit natuurlijk wel met fragmentatie. Ookal zijn de blokken op het laagste niveau sequentieel, hij moet wel doorspitten wat nuttige data is en wat rommel is.
Dat gaat dus per record volgens mij.

[RobertMe]

FireDrunk schreef op dinsdag 16 juni 2020 @ 22:50:
Je zit natuurlijk wel met fragmentatie. Ookal zijn de blokken op het laagste niveau sequentieel, hij moet wel doorspitten wat nuttige data is en wat rommel is.
Dat gaat dus per record volgens mij.

Ik vermoed dat dat de scanned vs issued is. Scanned leest alleen de filesystem table / layout en "indexeert" de boel. Daarna gaat die pas scrubben / resilveren op basis van wat de data die die daarvoor verzameld heeft. Daardoor dat scanned ook met een vele hogere snelheid zal zijn vermoed ik. Paar KB van layout lezen maar die verwijst wel naar paar MB aan data.

[RobertMe]

FireDrunk schreef op dinsdag 16 juni 2020 @ 22:19:
U vraagt, wij draaien:

http://prv.cloud:10000

En zo zit je een paar uur later alsnog op een verwachte resilvertijd van 20 uur. En is die nog niet klaar en kan het nog wel even duren.

Overigens heb je nu een gewone iostat in je script zitten? zpool iostat (met een aantal args) is dan ook wel een interessante. In mijn geval zag ik toentertijd daarin waits van seconden terug komen.

Edit:
Dit dus (met -vql)

[robert@nas ~]$ sudo zpool iostat backup -vql 10
                                                capacity     operations     bandwidth    total_wait     disk_wait    syncq_wait    asyncq_wait  scrub   trim   syncq_read    syncq_write   asyncq_read  asyncq_write   scrubq_read   trimq_write
pool                                          alloc   free   read  write   read  write   read  write   read  write   read  write   read  write   wait   wait   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ
--------------------------------------------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----
backup                                         623G  1.20T      3     19  1.15M   568K  101ms   15ms    8ms  962us  531us  173ms   28ms    1ms  124ms      -      0      0      0      0      0      0      0      0      0      0      0      0
  mirror                                       623G  1.20T      3     19  1.15M   568K  101ms   15ms    8ms  962us  531us  173ms   28ms    1ms  124ms      -      0      0      0      0      0      0      0      0      0      0      0      0
    ata-WDC_WD20EZRZ-00Z5HB0_WD-WCC4M1ZZ9803      -      -      1      9   573K   284K  119ms   16ms   10ms    1ms  547us  183ms   32ms    1ms  148ms      -      0      0      0      0      0      0      0      0      0      0      0      0
    ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0VYJ8F8      -      -      1      9   608K   284K   87ms   14ms    7ms  879us  516us  163ms   25ms    1ms  105ms      -      0      0      0      0      0      0      0      0      0      0      0      0
--------------------------------------------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----

[ Voor 66% gewijzigd door RobertMe op 17-06-2020 07:05 ]

[FireDrunk]

Mwoh, hij staat nu op 6h resterend. Als hij er ~24h over doet (wat ik verwacht), heeft de schijf onder deze load gemiddeld 20MB/s gedaan. Dat is genoeg voor mij tijdens een rebuild. In 'normale' gebruiksomstandigheden presteren de schijven een stuk beter (maar ook niet extreem snel).

zpool iostat is toegevoegd overigens. Wel vet overzicht, die kende ik nog niet.
Ik zie daar waits van ~500ms max. Dat valt relatief mee denk ik.

[ Voor 20% gewijzigd door FireDrunk op 17-06-2020 07:50 ]

[CurlyMo]

FireDrunk schreef op woensdag 17 juni 2020 @ 07:37:
Mwoh, hij staat nu op 6h resterend. Als hij er ~24h over doet (wat ik verwacht), heeft de schijf onder deze load gemiddeld 20MB/s gedaan. Dat is genoeg voor mij tijdens een rebuild. In 'normale' gebruiksomstandigheden presteren de schijven een stuk beter (maar ook niet extreem snel).

De resultaten tot nu toe vind ik inderdaad ook hoopgevend.

[RobertMe]

FireDrunk schreef op woensdag 17 juni 2020 @ 07:37:
Mwoh, hij staat nu op 6h resterend. Als hij er ~24h over doet (wat ik verwacht), heeft de schijf onder deze load gemiddeld 20MB/s gedaan. Dat is genoeg voor mij tijdens een rebuild.

Vraag is natuurlijk wel of die dit vast houd, of dat die uiteindelijk zover inzakt dat het alsnog (veel) langer induurt.

Ik zie daar waits van ~500ms max. Dat valt relatief mee denk ik.

Dat is in ieder geval een stuk beter als wat ik toen zag. Toen zag ik waits van letterlijk in de seconden.

[FireDrunk]

De inzak fase van 'SLC' -> 'MLC' heb ik al gehad, ik begon met > 150MB/s op de schijf.
Ik verwacht dat deze snelheid wel ongeveer zo blijft, en alleen de vertraging van vol raken van de schijf nog effect gaat hebben. (Dichter bij het midden van de platter, dus minder data per omwenteling...)

[ Voor 14% gewijzigd door FireDrunk op 17-06-2020 08:45 ]

[RobertMe]

FireDrunk schreef op woensdag 17 juni 2020 @ 08:44:
De inzak fase van 'SLC' -> 'MLC' heb ik al gehad, ik begon met > 150MB/s op de schijf.
Ik verwacht dat deze snelheid wel ongeveer zo blijft, en alleen de vertraging van vol raken van de schijf nog effect gaat hebben. (Dichter bij het midden van de platter, dus minder data per omwenteling...)

In mijn ervaring met de 2,5" variant bleef de snelheid echter zakken. We weten natuurlijk niet hoe de Seagates werken, maar het kan uiteraard ook dat die initieel, zolang het qua capaciteit niet nodig is, juist wel via CMR doet schrijven, en pas als de schijf voller raakt over stapt op SMR. Dan zou je dus "later" alsnog tegen issues kunnen aanlopen als die voller raakt. Omdat die dan dus de bestaande data moet gaan omschrijven van "naast elkaar" naar "over elkaar".

Om welke schijven gaat het overigens? In mijn herinnering had je 8TB disks? Dus daarbij hoeft die dan ook maar ongeveer 2TB te schrijven? Dus heel vol wordt de schijf dan ook niet.

[FireDrunk]

Ik heb juist 2.5" 2TB Seagate SMR schijven (pricewatch: Seagate Barracuda Compute 2,5", 2TB)

Schijven hebben 1.8TiB ruwe capaciteit, en er is al 1.09TiB geschreven, dus ik verwacht dat hij sowieso al in SMR mode staat.

[RobertMe]

FireDrunk schreef op woensdag 17 juni 2020 @ 08:50:
Ik heb juist 2.5" 2TB Seagate SMR schijven (pricewatch: Seagate Barracuda Compute 2,5", 2TB)

Schijven hebben 1.8TiB ruwe capaciteit, en er is al 1.09TiB geschreven, dus ik verwacht dat hij sowieso al in SMR mode staat.

Magische schijfjes dan, met die 8,62TB aan totaal gebruik

Of dat is natuurlijk het totale aantal bytes door ZFS in gebruik, dus incl. parity etc, en niet alleen de totale grote van opgeslagen bestanden. Of hij telt compressie mee (8,62TB aan data maar door compressie maar 7TB op disk.

[FireDrunk]

Dat is inderdaad inclusief parity, `zpool` geeft altijd inclusief parity, `zfs` geeft effectief gebruik van filesystems.

Er is 5.74T in gebruik op mijn pool, en 1.28T vrij.

[ Voor 18% gewijzigd door FireDrunk op 17-06-2020 09:13 ]

[RobertMe]

FireDrunk schreef op woensdag 17 juni 2020 @ 09:12:
Dat is inderdaad inclusief parity, `zpool` geeft altijd inclusief parity, `zfs` geeft effectief gebruik van filesystems.

Dat verklaart. Vroeg mij al af waar de 21TB capaciteit vandaan kwam met mijn 3x8TB in RAIDZ1

Edit:
Overigens vind ik het wel jammer dat je met bv een zpool list -v niet het gebruik per schijf kunt zien. Dat je dus ook weet hoe de verdeling is. Alhoewel dat als het goed is dus totale capaciteit / aantal schijven is. En als je bv weer een stripe maakt tussen meerdere RAIDZ sets zie je wel weer per set het gebruik. (neem ik aan, gezien die nu ook een regel per pool en een regel per mirror / raidz laat zien met overal de gegevens, terwijl juist de regels per disk "leeg" zijn).

[ Voor 46% gewijzigd door RobertMe op 17-06-2020 09:25 ]

[FireDrunk]

93%. w00t w00t, we zijn er bijna

Valt me alleszins mee, nog geen 24h (als er geen gekke dingen gebeuren).

[CurlyMo]

Ben ik de enige die al aan het aftellen is

[Q]

CurlyMo schreef op woensdag 17 juni 2020 @ 15:14:
Ben ik de enige die al aan het aftellen is

Nope, spannend

99.08% done, 0 days 00:11:54 to go

[FireDrunk]

It's finished! 21 uur met een gemiddelde van 19.4MB/s
Best acceptabel dus!

[CurlyMo]

FireDrunk schreef op woensdag 17 juni 2020 @ 15:42:
It's finished! 21 uur met een gemiddelde van 19.4MB/s
Best acceptabel dus!

Inderdaad. Hoeft mijn idee van twee mirrors inderdaad ook niet meer.

Had ik toch ook gelijk met deze reactie:
CurlyMo in "Het grote ZFS topic"

[FireDrunk]

Overigens heb ik uiteindelijk dus geen enkele 'service' gestopt. Nou was er toevallig ook niet zoveel te doen, dus veel zal het niet gescheeld hebben.

[Q]

21 uur voor krap 6 TB aan data vind ik niet echt schaalbaar. Je moet bij grotere builds bijna in weken rebuild tijd gaan rekenen.

Reden genoeg om bij grotere datasets het verlies eventueel te nemen en de SMR schijven door CMR exemplaren te vervangen.

Zelfs als omruilen kosteloos mogelijks zou zijn is het nogal een tour om zonder de array te verbreken de schijven om te wisselen.

Al met al is dit SMR-verhaal echt vervelend voor de getroffenen.

[FireDrunk]

Het rebuilden van een grotere array duurt niet perse langer. Het duurt langer als de te rebuilden disk groter is.
Ik zou voor SMR dan ook een max van 8TB disks aanhouden. Dan duurt het dus 4 keer zo lang als mijn rebuild.

[RobertMe]

FireDrunk schreef op woensdag 17 juni 2020 @ 17:46:
Het rebuilden van een grotere array duurt niet perse langer. Het duurt langer als de te rebuilden disk groter is.
Ik zou voor SMR dan ook een max van 8TB disks aanhouden. Dan duurt het dus 4 keer zo lang als mijn rebuild.

Maar dan ben je dus alsnog ruim drie dagen bezig. Persoonlijk lijkt mij dat nogal fors. En dat is in jouw situatie dan ook nog eens geweest met grotendeels idle schijven. Als je dus wel data erop hebt staan die meer gebruikt wordt zal de rebuild tijd alleen maar toenemen.

En gezien een van de redenen om RAID (/ZFS) toe te passen kan zijn om bij een falende disk alsnog up te blijven is het dus potentieel ook niet wenselijk om maar even alle services stop te zetten zodat de rebuild het enige is dat gebruik maakt van de schijven.

[Xantis]

FireDrunk schreef op dinsdag 16 juni 2020 @ 18:06:
.... 385G scanned at 21.4G/s, 135M issued at 7.49M/s, 8.62T total....

Damn... Wat zijn dat voor drives

[ Voor 26% gewijzigd door Xantis op 17-06-2020 18:05 ]

[FireDrunk]

Eerste deel komt uit io cache

[CurlyMo]

Q schreef op woensdag 17 juni 2020 @ 17:38:
Al met al is dit SMR-verhaal echt vervelend voor de getroffenen.

Ik vind het hele SMR-verhaal voor thuisgebruik juist overtrokken. @FireDrunk laat zien dat rebuilden prima gaat voor een vrij standaard array. Zolang je gewoon je veel gebruikte services vanaf een SSD laat draaien en de minder veranderlijke dingen van je SMR array, dan is er volgens mij vrij weinig aan de hand.

[Q]

Voor relatief kleine datasets zoals die van Firedrunk is het misschien acceptabel. Maar voor grotere datasets wordt de doorlooptijd wel extreem.

Dat is op zichzelf nog niet een probleem, een lange doorlooptijd is niet meer dan dat. Het hoeft geen problemen op te leveren, zeker niet met een RAID6/Z2.

Maar ik zou het voor mijzelf niet acceptabel vinden dat ik meer dan een week moet wachten tot dat de array weer gerebuild zou zijn.

FireDrunk schreef op woensdag 17 juni 2020 @ 17:46:
Het rebuilden van een grotere array duurt niet perse langer. Het duurt langer als de te rebuilden disk groter is.
Ik zou voor SMR dan ook een max van 8TB disks aanhouden. Dan duurt het dus 4 keer zo lang als mijn rebuild.

Ik bedoelde met een grote array eentje met veel grotere drives en ook veel meer data. Maar ik zou een krappe werkweek nog steeds niet OK vinden als rebuild tijd.

[FireDrunk]

Waarom niet? Als je RAIDZ2 gebruikt, heb je nog steeds gewoon je redundancy? Ik zou wel minimaal RAIDZ2 aanraden bij SMR drives (als je niet strikt wil vertrouwen op je backup uiteraard).

De kans dat je array faalt in 1 dag of in 5 wordt denk ik niet extreem veel groter. De stress van 1 dag rebuilden is qua temperatuur bijvoorbeeld niet heel erg verschillend met een week.

Schijven bereiken hun maximale temperatuur in een aantal uren, wat volgens mij een van de grotere oorzaken is van falende schijven tijdens een lopende rebuild.

[XAEROCOOL]

Hoi,

Ik heb ubuntu geinstalleerd en probeer nu mijn pool te importeren, maar hoe moet ik nu verder?



Ik ga voorzichtig aan het werk om geen verkeerde dingen te doen.
Alvast bedankt.

[RobertMe]

FireDrunk schreef op woensdag 17 juni 2020 @ 18:54:
Waarom niet? Als je RAIDZ2 gebruikt, heb je nog steeds gewoon je redundancy? Ik zou wel minimaal RAIDZ2 aanraden bij SMR drives (als je niet strikt wil vertrouwen op je backup uiteraard).

Als de pool tijdens de rebuild gebruikt wordt dan wordt de data uiteraard meteen op alle schijven weggeschreven zoals onder normale omstandigheden. Daarmee breek je dan meteen het sequentieel schrijven wat SMR wel vlot kan (en door ZoL 0.8 gedaan wordt). De kans dat je daarmee dan ook writes gaat triggeren die seconden lang duren is dan ook aanzienlijk, en daarmee heeft het dus een (zeer) grote impact op het normale gebruik, wat mij betreft dus onacceptabel.

Zoals ik dus toentertijd die 2,5" 5TB met een WD in mirror had. En ja, ik had ook DB erop draaien, maar zelfs zonder rebuild/resilver genereerde dat die IO die seconden duurde. Als je dus wat IO genereert tijdens rebuild ben je ook gegarandeerd de sjaak.

[ Voor 3% gewijzigd door RobertMe op 17-06-2020 19:18 ]

[RobertMe]

XAEROCOOL schreef op woensdag 17 juni 2020 @ 19:01:
[Afbeelding]

Dit geeft aan dat de pool succesvol is geïmporteerd. Alleen zijn er wat features niet ingeschakeld, maar dat is geen probleem. Schakel je die features wel in loop je het risico dat je deze pool niet kunt importeren op een ander systeem, als de ZFS versie daarop die features niet ondersteund.

[Afbeelding]

Deze error zei mij niks. Maar als ik hierop Google lijkt het erop dat jij, of Ubuntu, probeert te mounten (sudo mount /dev/sdc2) en dat kan niet. Dit omdat ZFS dus op een andere manier werkt met mounten etc.

Wat geven de volgende commando's aan?

• zfs mount
• zfs get mountpoint tank

Zfs mount geeft daarbij in principe aan welke ZFS filesystems gemount zijn, en waar. Potentieel geeft dat al voldoende aan waar je de data kunt terugvinden. Waarbij er een grote kans is dat dat /tank/ is, dus dat zou je al meteen kunnen controleren.

[Mystic Spirit]

FireDrunk schreef op woensdag 17 juni 2020 @ 18:54:
Waarom niet? Als je RAIDZ2 gebruikt, heb je nog steeds gewoon je redundancy? Ik zou wel minimaal RAIDZ2 aanraden bij SMR drives (als je niet strikt wil vertrouwen op je backup uiteraard).

De kans dat je array faalt in 1 dag of in 5 wordt denk ik niet extreem veel groter. De stress van 1 dag rebuilden is qua temperatuur bijvoorbeeld niet heel erg verschillend met een week.

Schijven bereiken hun maximale temperatuur in een aantal uren, wat volgens mij een van de grotere oorzaken is van falende schijven tijdens een lopende rebuild.

Ik dacht dat luchtvochtigheid een grotere invloed heeft op het falen van disks, dan temperatuur. Zie dit artikel uit 2016 . Of zijn die inzichten de laatste jaren weer verandert? Ik zou mij dus niet zo'n zorgen maken over de temperatuur bij een rebuild. Ook de tijd dat het duurt is minder interessant als de andere SMART of scrub indicatoren goed zijn. Alleen de verminderde beschikbaarheid is dan vervelend, maar in een thuis situatie niet zo'n ramp.

[XAEROCOOL]

RobertMe schreef op woensdag 17 juni 2020 @ 19:11:

Wat geven de volgende commando's aan?

• zfs mount
• zfs get mountpoint tank

Zfs mount geeft daarbij in principe aan welke ZFS filesystems gemount zijn, en waar. Potentieel geeft dat al voldoende aan waar je de data kunt terugvinden. Waarbij er een grote kans is dat dat /tank/ is, dus dat zou je al meteen kunnen controleren.

Nu ik het opnieuw heb opgestart zie ik ook L2ARC die niet beschikbaar is, kan ik dit ook verwijderen?

[FireDrunk]

@XAEROCOOL

Je pool is gewoon netjes online en gemount op /tank.
Wil je de pool graag op een andere locatie gemount hebben? Want standaard zal ZFS de pool mounten op / met daaronder een directory met de naam van de pool.

Dat is aan te passen mocht je dat echt willen, maar aan te raden is het niet.

Waarom je L2ARC er niet is, kunnen we hier niet zo makkelijk zien. Het device had ook de naam L2ARC, maar dat kan zowel de disk als de partitienaam zijn.

Hoe heb je de L2ARC aangemaakt?

@Mystic Spirit Ik dacht dat in die grote blog(s) van BlackBlaze stond dat schijven vooral dood gingen aan grote temperatuursverschillen in korte tijd. Luchtvochtigheid zal ook zeker een rol spelen, maar die is onze gemiddelde situatie redelijk stabiel denk ik?

[ Voor 46% gewijzigd door FireDrunk op 17-06-2020 19:56 ]

[Mystic Spirit]

XAEROCOOL schreef op woensdag 17 juni 2020 @ 19:48:
[...]


Nu ik het opnieuw heb opgestart zie ik ook L2ARC die niet beschikbaar is, kan ik dit ook verwijderen?
[Afbeelding]
[Afbeelding]

Zit je L2ARC schijf er nog wel in? Lijkt namelijk alsof hij er helemaal niet is.

Overigens ben ik er onlangs achter gekomen dat een L2ARC in de meeste situaties zinloos is. Het concept is leuk, maar in de praktijk levert het heel weinig op. Zeker in thuis situaties. Het levert wel wat op bij het draaien van veel VM's of databases, maar die zou ik sowieso liever rechtstreeks op een SSD zetten en dan is de L2ARC weer overbodig.

@FireDrunk Volgens mij zegt BackBlaze juist dat ze geen verband hebben kunnen vinden tussen fails en temperatuur. De data daarvoor was te inconsistent. Google heeft wel eens een verband gerapporteerd, maar dat is volgens mij alweer langer gelden. Luchtvochtigheid schommelt in NL wel, dus is dat wel een factor maar echt hoge luchtvochtigheid hebben we in NL volgens mij minder en is de invloed dus ook minder in ons klimaat.

[XAEROCOOL]

L2ARC zat dus wel in vorige zfsguru configuratie, was op de m.2 ssd waar nu ubuntu op zit.
Volgens de suggesties was het ook niet meer nodig, ik weet niet waarom die nu weer te zien is op de tank pool. Maar die zou ik als het goed is kunnen verwijderen met commando?:
- zpool remove tank L2ARC

[Q]

Over schijftemperaturen:

Het Backblaze onderzoek laat zien dat als de schijf temperaturen ver onder het maximum liggen, dat er dan geen relatie is tussen temperatuur en kans op falen.

Concreet betekent dit dat als een schijf in hun datacenter ergens tussen de 20-35 graden zit dan maakt het dus niet uit of een schijf 25 graden of 30 graden is.

Helaas dachten een hoop mensen ten onrechte, oh, dus als temperatuur niet uitmaakt is 60 graden ook wel prima. Nee, dat was niet de boodschap.

[ Voor 3% gewijzigd door Q op 17-06-2020 21:20 ]

[FireDrunk]

XAEROCOOL schreef op woensdag 17 juni 2020 @ 21:18:
L2ARC zat dus wel in vorige zfsguru configuratie, was op de m.2 ssd waar nu ubuntu op zit.
Volgens de suggesties was het ook niet meer nodig, ik weet niet waarom die nu weer te zien is op de tank pool. Maar die zou ik als het goed is kunnen verwijderen met commando?:
- zpool remove tank L2ARC

Ja hoor, dat kan prima. ZFS haalt niet automatisch het device uit je pool als die niet meer aangesloten is. Dat moet je even los doen.

[_JGC_]

Mystic Spirit schreef op woensdag 17 juni 2020 @ 20:24:
[...]
Overigens ben ik er onlangs achter gekomen dat een L2ARC in de meeste situaties zinloos is. Het concept is leuk, maar in de praktijk levert het heel weinig op. Zeker in thuis situaties. Het levert wel wat op bij het draaien van veel VM's of databases, maar die zou ik sowieso liever rechtstreeks op een SSD zetten en dan is de L2ARC weer overbodig.

Ik had een HP Microserver N40L met 2x2TB WD Green en 16GB geheugen op FreeBSD. Dat ding had maar 1 taak: elke nacht een rsync backup trekken van een aantal servers en daarna snapshotten.

Hoe voller de disk kwam te staan, hoe meer dat ding ging rammelen. OS stond op een Crucial M550 van 240GB, ik heb daar een partitie van 100GB op gemaakt en die als L2ARC ingesteld, rammel was daarna zo goed als weg.

[Q]

_JGC_ schreef op donderdag 18 juni 2020 @ 00:39:
[...]

Ik had een HP Microserver N40L met 2x2TB WD Green en 16GB geheugen op FreeBSD. Dat ding had maar 1 taak: elke nacht een rsync backup trekken van een aantal servers en daarna snapshotten.

Hoe voller de disk kwam te staan, hoe meer dat ding ging rammelen. OS stond op een Crucial M550 van 240GB, ik heb daar een partitie van 100GB op gemaakt en die als L2ARC ingesteld, rammel was daarna zo goed als weg.

Ik vraag me af wat er zou gebeuren zonder L2ARC maar als je primarycache=metadata zou gebruiken.

[FireDrunk]

primarycache is toch een setting van ARC, niet van L2ARC? De setting zegt dat er geen last/most-frequently used data in ARC mag, maar alleen metadata? Die snap ik niet zo goed.

[_JGC_]

Q schreef op vrijdag 19 juni 2020 @ 10:39:
[...]


Ik vraag me af wat er zou gebeuren zonder L2ARC maar als je primarycache=metadata zou gebruiken.

Dan zou ie waarschijnlijk een stuk minder rammelen tijdens het bepalen wat er gebackupt moet worden, maar gaat de daadwerkelijke sync gewoon nog steeds rammelen, mogelijk zelfs nog erger.

Backups schrijven met rsync zorgt, zeker op een copy on write volume, voor heel veel fragmentatie. Als je dan bepaalt dat er alleen metadata in de cache mag, zal rsync bij het binnentrekken van bestanden die veranderd zijn dus van een gefragmenteerde disk moeten lezen zonder cache.

Edit: Zou de oude setup weer moeten afstoffen, kijken of ik rsync wel met --inplace gebruikte...

[ Voor 6% gewijzigd door _JGC_ op 19-06-2020 11:48 ]

[Q]

FireDrunk schreef op vrijdag 19 juni 2020 @ 10:54:
primarycache is toch een setting van ARC, niet van L2ARC? De setting zegt dat er geen last/most-frequently used data in ARC mag, maar alleen metadata? Die snap ik niet zo goed.

Het idee is dat het geratel met name komt vanwege metadata inlezen en als je daar je RAM volledig voor inzet dan heb je geen L2ARC nodig.

Uiteindelijk is de vraag dus: wil je om je HDDs minder te belasten een SSD verslijten.

Ik vind dat zelf niet zo logisch want harde schijven zijn niet snel qua random I/O maar ze kunnen die belasting prima aan.

Dus wat resteert is het lawaai. Tja. Als je een NAS niet ergens anders neer kan zetten dan is dat wel vervelend.

Ik vraag me af in hoeverre je niet precies het zelfde issue hebt op een regulier filesystem als op ZFS, tot op een zekere hoogte.

[ Voor 8% gewijzigd door Q op 19-06-2020 12:01 ]

[CurlyMo]

@_JGC_ Waarom rsync als je ZFS draait?

[_JGC_]

CurlyMo schreef op vrijdag 19 juni 2020 @ 12:43:
@_JGC_ Waarom rsync als je ZFS draait?

zfs send vanaf een ext4 FS werkt niet echt volgens mij.
De servers waar backups van getrokken werden zijn linux machines met ext4.

@Q ZFS werkt met Copy On Write. Als je rsync daar gebruik van laat maken (--inplace) krijg je gefragmenteerde doelbestanden. Je kunt ook besluiten om niet --inplace te gebruiken, dan krijg je gewoon een nieuw doelbestand, maar dan groeien je snapshots de pan uit qua opslagruimte.

[ Voor 33% gewijzigd door _JGC_ op 19-06-2020 13:02 ]

[CurlyMo]

_JGC_ schreef op vrijdag 19 juni 2020 @ 12:56:
[...]

zfs send vanaf een ext4 FS werkt niet echt volgens mij.
De servers waar backups van getrokken werden zijn linux machines met ext4.

ZFS is je dus je target en niet je source? Jammer dat dat niet anders gaat.