Het grote ZFS topic

[dutch_warrior]

InflatableMouse schreef op donderdag 14 februari 2019 @ 13:34:
[...]
Kan iemand dit bevestigen danwel ontkrachtigen met een min of meer betrouwbare bron?

Wat zijn de ideeen? iemand hier ervaring mee?

ZFS needs to be able to trigger the device's onboard cache to flush when a synchronous write is requested, to ensure that the write is really on stable storage before returning to the application. It can only do this if it controls the whole device. If using a slice, ZFS cannot issue the cache flush and you risk losing data during an unexpected shutdown.

Soortgelijke info kwam ik ook tegen toen ik aan het kijken was naar pool op basis van partlabels.
Waar had je dit gelezen, serverfault?
Op basis van posts op de FreeBSD forums lijkt het erop dat dit alleen op gaat voor Solaris gebaseerde systemen vanwege de wijze waarop disk caching is geïmplementeerd. Ik weet niet of de disk caching implementatie onder Linux vergelijkbaar is met het systeem van FreeBSD maar het lijkt me geen onredelijke aanname dat Linux hierin net als FreeBSD een meer moderne aanpak hanteert dan Solaris.

Het maken van partities om potentiële verschillen in het aantal sectors tussen verschillende devices op te vangen lijkt ook niet meer nodig omdat vendoren zich daarin beter aan standaarden houden zoals CurlyMo al aangaf en daarnaast reserveert ZFS blijkbaar ook een klein beetje ruimte aan het einde van een disk om eventuele problemen af te vangen.

[InflatableMouse]

Oke er is iets mis gegaan met een pool waar ik deels maar een backup van heb helaas.

Omdat ik de SSD's die als slog en cache aan die pool hingen opnieuw moest inrichten heb ik ze verwijderd. Cache ging goed maar bij de slog kreeg ik een kryptische foutmelding die ik kwijt ben. Had een foto gemaakt maar die is mislukt.

PC zat helemaal vast en enige optie was nog om de stekker er uit te trekken.

Nu zegt zpool import dat er onbekende devices deel uitmaakte van die pool die hij niet meer kent en wil de pool daarom niet importeren. Maar ik weet dat die devices slog mirror was die geflushed was en leeg.

Kan ik die pool op een of andere manier forceren toch online te komen of hoe fix ik dit?

Dank!

[CurlyMo]

InflatableMouse schreef op dinsdag 19 februari 2019 @ 19:52:
Kan ik die pool op een of andere manier forceren toch online te komen of hoe fix ik dit?

Pool versie groter dan v28?

[InflatableMouse]

CurlyMo schreef op dinsdag 19 februari 2019 @ 19:54:
[...]

Pool versie groter dan v28?

Gemaakt met de huidige archzfs (AUR) versie (niet git). Package versie zit op zfs-linux 0.7.12_4.20.8.arch1.1-1.

zpool get version poolname geeft niets weer, tenminste niet op mijn draaiende systemen (zelfde tijd gemaakt met dezelfd zfs versie).

edit:
Fixed it!

Bij een import -d /dev/disk/by-id gaf tie aan dat tie devices miste, maar hij zei er bij 'use -m to import anyway'.

Daarna kon ik de slog mirror verwijderen en de pool is weer in orde!

Few, dat was effe zweten . Nu dan toch maar eerst een backup maken

[ Voor 26% gewijzigd door InflatableMouse op 19-02-2019 21:48 ]

[InflatableMouse]

Heeft iemand een idee waarom ik fio niet kan draaien met direct=1optie?

Ik krijg:

code:

fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT

Oudere versies ondersteunden O_DIRECT inderdaad niet maar in 2018 is het al gemerged en ik zie overal voorbeelden van fio tests op zfs met die optie?

[HyperBart]

Ik moet dit weekend een oude pool (bestaande uit 2 RAIDZ2 VDEV's met beide 10 disks van ieder 4TB) uitbreiden door in één VDEV alle disks 1 per 1 te vervangen door grotere 10TB exemplaren.

Die pool is indertijd aangemaakt volgens @FireDrunk's blogpost: The ZFS Storage Blog!: ZFSonLinux - Hoe partitioneer ik nou mijn schijven?

@FireDrunk, geniet dit nog altijd de voorkeur op Linux of gebruik ik gewoon een /dev/by-iets-anders om de disks mee te vervangen?

[ Voor 3% gewijzigd door HyperBart op 01-03-2019 20:32 ]

[CurlyMo]

HyperBart schreef op vrijdag 1 maart 2019 @ 20:01:
Die pool is indertijd aangemaakt volgens @FireDrunk's blogpost: The ZFS Storage Blog!: ZFSonLinux - Hoe partitioneer ik nou mijn schijven?

Diezelfde vraag is echt heel recent langsgekomen.

[Kortfragje]

Kan iemand hiermee helpen, kom er niet helemaal uit.

Ik had tot voor kort een grote share met persoonlijke documenten, foto's, en videos (backup). Eind vorig jaar heb ik nieuwe shares voor foto's en video's aangemaakt (met het idee een digitaal fotolijstje aan te schaffen).

Echter in de snapshots van backup staat alle foto / video data nog, dus neemt het nu 2 maal de benodigde ruimte in. Omdat het systeem vol loopt wilde ik ruimte vrijmaken (bijv door de backup share weer te herstellen en losse foto/video shares te verwijderen).

Ik nam aan dat de ruimte dan niet weer 'dubbel' afgeschreven zou worden. Maar zelfs als ik de foto's en videos uit de snapshot restore terug kopieer neemt het de ruimte dubbel in. Enig idee hoe ik dit op zou kunnen lossen? Is een volledige rollback de enige optie?

[EnerQi]

Kortfragje schreef op zondag 3 maart 2019 @ 08:14:
Kan iemand hiermee helpen, kom er niet helemaal uit.

Ik had tot voor kort een grote share met persoonlijke documenten, foto's, en videos (backup). Eind vorig jaar heb ik nieuwe shares voor foto's en video's aangemaakt (met het idee een digitaal fotolijstje aan te schaffen).

Echter in de snapshots van backup staat alle foto / video data nog, dus neemt het nu 2 maal de benodigde ruimte in. Omdat het systeem vol loopt wilde ik ruimte vrijmaken (bijv door de backup share weer te herstellen en losse foto/video shares te verwijderen).

Ik nam aan dat de ruimte dan niet weer 'dubbel' afgeschreven zou worden. Maar zelfs als ik de foto's en videos uit de snapshot restore terug kopieer neemt het de ruimte dubbel in. Enig idee hoe ik dit op zou kunnen lossen? Is een volledige rollback de enige optie?

Snapshot verwijderen. Het klopt dat ie nu +-2x plaats inneemt omdat ZFS de snapshot wil kunnen gebruiken om je bestanden te herstellen. Ook door de bestanden weer terug te zetten, ziet ZFS het als "nieuwe" bestanden (tijd is aangepast aan de bestanden bijvoorbeeld) en durft de snapshot dus niet te verwijderen/vervangen. Het is namelijk slim genoeg om te tracken of files gewijzigd zijn of niet. Op die nieuwe share kan ie dat natuurlijk niet. Voor hem is dat een nieuwe entry.

Overigens heb ik geen idee hoe je een snapshot zou moeten verwijderen

[ Voor 13% gewijzigd door EnerQi op 03-03-2019 08:39 ]

[Kortfragje]

Dank voor je reactie! verwijderen met

code:

zfs destroy POOLNAME/DATASET@SNAPSHOT

punt is dat ik de historie in snapshot wel wil behouden...

Kwam hier een potentiele oplossing tegen:
https://serverfault.com/q...ving-files-from-snapshots

code:

Clone the oldest snapshot into a new filesystem (call it fsnew).
Promote the clone (fsnew) to allow you to destroy the snapshot the filesystem is based on.
Remove the offending files.
Create a snapshot of fsnew.
Now foreach snapshot after, rsync with the --inplace flag from the snapshot to fsnew skipping over files you do not want. The --inplace flag reduces the number of writes and allows for smaller snapshots.

Create a snapshot of fsnew.
Destroy the original snapshot.
When this is done, you should have a snapshot on fsnew that corresponds to the snapshots from the original filesystem with the offending files removed.

zal dit gaan proberen..

--> update, 'cannot promote clone dataset is busy'

Omdat het maar 6 snapshots sinds de split zijn ga ik:

• snapshots zenden naar een tweede temp set (6*)
• rollback naar de oude snapshot
• met rsync de gewijzigde bestanden bijschrijven per snapshot

[ Voor 17% gewijzigd door Kortfragje op 03-03-2019 08:58 ]

[CurlyMo]

Kortfragje schreef op zondag 3 maart 2019 @ 08:40:
zal dit gaan proberen..

Die clone / promote optie is wel de snelste optie voor je probleem. Dataset is busy heeft natuurlijk een oorzaak. Als gezocht wat die kan zijn?

[Kortfragje]

Een aantal maar geen definitieve oorzaak (eigenlijk altijd in context waarbij men een clone probeerde te verwijderen). Omdat ik weet dat zend / receive goed werkt en ik de onderligende oorzaak van problemen met clone niet goed snap, ga ik voor de (in mijn ogen) meer robuuste manier waar ik meer ervaring mee hebt.

Dat het dan iets langer duurt is maar zo

[martijndierckx]

Ik heb een pool met 2 raidz2 vdevs, waarvan ik alle disks in 1 van die vdevs ga vervangen door grotere disks.
Nu ben ik die replace 1 per 1 aan het doen. Kan ik er meerdere tegelijk laten lopen?

Ik heb 4 spare drive bays. Dus ik kan perfect de oude disks laten zitten, terwijl de nieuwe al geplaatst is.

Thx
M

[CurlyMo]

Martinoswebdsgn schreef op zondag 3 maart 2019 @ 12:53:
Ik heb een pool met 2 raidz2 vdevs, waarvan ik alle disks in 1 van die vdevs ga vervangen door grotere disks.
Nu ben ik die replace 1 per 1 aan het doen. Kan ik er meerdere tegelijk laten lopen?

Ik heb 4 spare drive bays. Dus ik kan perfect de oude disks laten zitten, terwijl de nieuwe al geplaatst is.

Waarschijnlijk kan het wel. Ik zou het anders gewoon eens in een test situatie proberen.

[martijndierckx]

Ik heb niet de ruimte/setup om dat eens te testen helaas.
Maar misschien zijn er anderen die er al ervaring mee hebben?

CurlyMo schreef op zondag 3 maart 2019 @ 13:23:
[...]

Waarschijnlijk kan het wel. Ik zou het anders gewoon eens in een test situatie proberen.

[CurlyMo]

Martinoswebdsgn schreef op zondag 3 maart 2019 @ 13:55:
Ik heb niet de ruimte/setup om dat eens te testen helaas.

Tuurlijk heb je die wel. Maak gewoon een nieuwe RAIDZ2 op basis van 4 bestandjes van 1GB. VDEV's hoeven niet alleen HDD's of SSD's zijn. Vul die met random data. Vervang 2 van die 4 bestandjes met 2 nieuwe bestandjes.

[DataGhost]

Ja, je kan het natuurlijk doen, maar je redundancy is dan weg. Als je een leesfout krijgt is die fataal voor tenminste dat blok / die file, en ik zou even niet uit m'n hoofd weten hoe je dat fixt zonder backup.

[HyperBart]

DataGhost schreef op zondag 3 maart 2019 @ 14:45:
Ja, je kan het natuurlijk doen, maar je redundancy is dan weg. Als je een leesfout krijgt is die fataal voor tenminste dat blok / die file, en ik zou even niet uit m'n hoofd weten hoe je dat fixt zonder backup.

Dat klopt niet, het is geen -1 +1 vervanging, hij vervangt/replacet de nog online zijnde disks, dus dat wil zeggen dat op het moment van resilveren er 3 andere disks moeten falen in dezelfde ‘stripe’ voor het bestand waar het om gaat omvalt. Dat is net de hele kracht van ZFS.

[FireDrunk]

Kan gewoon, vraag me wel of hoe parallel die replace acties gaan. Default is het 1 tegelijk dacht ik. Is wel met kernel params te wijzigen denk ik.

[DataGhost]

HyperBart schreef op zondag 3 maart 2019 @ 15:43:
[...]


Dat klopt niet, het is geen -1 +1 vervanging, hij vervangt/replacet de nog online zijnde disks, dus dat wil zeggen dat op het moment van resilveren er 3 andere disks moeten falen in dezelfde ‘stripe’ voor het bestand waar het om gaat omvalt. Dat is net de hele kracht van ZFS.

Overheen gelezen Maar hoe gaat dat dan precies? Je kan alleen devices adden aan een vdev, niet weghalen toch?

[CurlyMo]

DataGhost schreef op maandag 4 maart 2019 @ 03:22:
[...]

Overheen gelezen Maar hoe gaat dat dan precies? Je kan alleen devices adden aan een vdev, niet weghalen toch?

Elk te vervangen schijf wordt tijdelijk in een mirror gezet. Als je mirror resilvered is dan wordt de oude schijf uit de mirror gehaald.

[martijndierckx]

CurlyMo schreef op maandag 4 maart 2019 @ 06:33:
[...]

Elk te vervangen schijf wordt tijdelijk in een mirror gezet. Als je mirror resilvered is dan wordt de oude schijf uit de mirror gehaald.

Eerst eentje apart gedaan
Daarna getest met 2 disks
Daarna met 3 disks
En nu lopen de laatste 4 disks

Seems to work fine.

Leuk om weten. Of je nu 1 disk resilvert of 4 tegelijk. De resilver time is altijd ongeveer gelijk, of nauwelijks langer.

[imdos]

martijndierckx schreef op dinsdag 5 maart 2019 @ 09:50:

Eerst eentje apart gedaan
Daarna getest met 2 disks
Daarna met 3 disks
En nu lopen de laatste 4 disks

Seems to work fine.

Daredevil! Maar goed dat je de ruimte had om tegelijk te resilveren.

Leuk om weten. Of je nu 1 disk resilvert of 4 tegelijk. De resilver time is altijd ongeveer gelijk, of nauwelijks langer.

Dat is ook niet zo vreemd toch? je moet een hele schijf inlezen en wegschrijven. Maargoed; blijkbaar is je SAS- of SATA-controller dan niet gesatureerd en heb je ruimte over voor extra devices

[Kortfragje]

Ik ben een systeem op aan het zetten met 10*10TB disks. Enige tijd terug was er een aversie om een 'te laag' raidz niveau aan te houden bij dergelijke disk groottes ivm rebuild tijd en disk stress. Nu zou ik zelf ook eigenlijk nooit meer voor raidz1 gaan omdat ik de piece of mind van bestand zijn tegen een extra disk failure wel waardeer..

Maar ik zie de laatste tijd toch redelijk wat >8TB disks in een RaidZ2 opstelling langs komen. Zijn mensen hier van terug gekomen?

Zoals ik het zie heb ik een aantal opties:

• 1 VDEV RaidZ1 --> 90 TB netto (1 parity disk)
• 1 VDEV RaidZ2 --> 80 TB netto (2 parity disks, 2 willekeurige disk failures)
• 1 VDEV RaidZ3 --> 70 TB netto (3 parity disks, 3 willekeurige disk failures)
• 2 VDEV RaidZ2 --> 60 TB netto (4 parity disks, max 2 willekeurige disk failures, 4 failures in 2 vdevs)
• 5 VDEV Mirrors --> 50 TB netto (5 mirror disks, max 1 willekeurige disk failure, max 5 over 5 vdevs)
• 2 VDEV RaidZ3 --> 40 TB netto (6 parity disks! , max 3 willekeurige disk failures)

Mis ik hier iets? Ik zou zelf neigen naar de 1 VDEV Raidz3 optie (doel van server is 'archive' backup van data van andere systemen dmv snapshots). Lijkt me ebste compromis tussen betrouwbaarheid en capaciteit.

Ik begreep dat een multiple vdev opstelling wellicht sneller is maar minder secure (en kunnen geen willekeurig 3 disks falen zoals bij raidz3, vdev failure = pool failure)

[FireDrunk]

Ligt 100% aan hoe belangrijk je data is. Als je 8*10TB aan een unieke collectie foto's van je vakantie in zimbabwe hebt, en die voor de levensduur van de aarde wil bewaren, is RAIDZ3 met een drie dubbele offsite backup goed.

Is het vooral 'meuk' (you know what I mean...) en is het meer een 'inconvenience' als het weg is, is RAIDZ2 voldoende.

RAIDZ1 zou ik inderdaad ook niet doen, omdat de kans dat er een disk uitvalt tijdens de resilver, toch best aanwezig is. Maar ook dat is subjectief.

Als je data echt vervangbaar is, is ZFS sowieso overkill. Daarnaast moet je *ALTIJD* een goede backup buiten ZFS hebben voor de meest kritieke data.

Als je die backup al hebt, is RAIDZ3 dan zoveel meer rust dan RAIDZ2?

[DataGhost]

Kortfragje schreef op dinsdag 26 maart 2019 @ 10:10:
Maar ik zie de laatste tijd toch redelijk wat >8TB disks in een RaidZ2 opstelling langs komen. Zijn mensen hier van terug gekomen?

Ik denk dat je hier redelijk goed mee weg kan komen (afhankelijk van hoe kritisch natuurlijk, maar dat is je eigen afweging) aangezien disk failures in mijn ervaring een tijdje voorafgegaan worden door een stapel R/W/C errors op delen van de disk, SMART values die oplopen, I/O errors en timeouts. Ik heb eigenlijk nog nooit een volledig onverwachte complete disk failure gehad op een draaiend systeem, alleen maar als de handel jaren uit heeft gestaan.

Nou is het bij normaal RAID6 doorgaans zo dat als je een disk failure hebt en gaat rebuilden, een enkele (sector) leesfout op een van de schijven ervoor zorgt dat je tweede parity er helemaal uit geflikkerd wordt en je zonder redundancy blijft zitten. Als ervolgens later op een andere schijf ook een dergelijke leesfout optreedt crasht heel je array. Met ZFS gebeurt dit niet, en wordt je device gewoon nog gebruikt voor zover er zinnige (checksummed) data uit komt. Dat betekent dus dat als je onafhankelijke leesfouten krijgt op 2, 3 of zelfs alle disks, er een grote kans is dat de hele array nog prima werkt zonder aan je data-integriteit te tornen. De kans is immers klein dat onafhankelijke errors tegelijk in dezelfde stripe optreden. Je moet natuurlijk die schijven/hardware wel gaan vervangen, maar goed.

Case in point: mijn thuis-servertje heeft hoogstwaarschijnlijk gaar RAM (kan ik nu niet vervangen) richting het einde van de adresruimte, SMART is allemaal dikke prima op m'n disks maar als het geheugen te vol zit, begint m'n array op alle schijven te erroren:

code:

  pool: main
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-9P
  scan: scrub repaired 27.8M in 23h54m with 0 errors on Tue Mar 26 05:33:07 2019
config:

        NAME        STATE     READ WRITE CKSUM
        main        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            sda4    DEGRADED     0     0   162  too many errors  
            sdb4    DEGRADED     0     0   138  too many errors  
            sdc4    DEGRADED     0     0   144  too many errors  
            sdd4    DEGRADED     0     0   144  too many errors  
            sde4    DEGRADED     0     0   153  too many errors  
            sdf4    DEGRADED     0     0   148  too many errors  

errors: No known data errors

De errors zijn "ontstaan" toen 'ie begon te scrubben met weinig vrij RAM, ik had op elke schijf iets van 1.5k C errors en op m'n raidz2-0 ook 11, maar geen data errors. Scrub gecanceld, een grote niet-essentiele service gekilled waardoor ik weer 4GB extra speelruimte had, alle devices gecleard en scrubben maar. Toen kwam 'ie op deze getallen uit en dat is waarschijnlijk verkeerd weggeschreven data. Dit is m'n root, de hele server is niet down geweest en ik heb het hier vanuit het buitenland zonder issues kunnen troubleshooten terwijl de hele handel vrolijk door bleef ratelen. Als dit met md-raid of wat dan ook was gebeurd was het binnen twee seconden al huilen geblazen.

[WTM]

Blijft een mooi systeem ZFS. Mijn Freenas build heeft een zfs volume waar 6x 4tb (wd red) schijven inhangen. Helaas is 1 schijf dood:
pool: six4tb
state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
repaired.
scan: resilvered 12K in 0 days 00:00:04 with 0 errors on Tue Mar 26 04:06:10 2019
config:

NAME STATE READ WRITE CKSUM
six4tb DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
gptid/39dbdb0d-8506-11e7-bbff-d050996ff8e2 ONLINE 0 0 0
gptid/3ae1fb29-8506-11e7-bbff-d050996ff8e2 ONLINE 0 0 0
gptid/3beb6715-8506-11e7-bbff-d050996ff8e2 ONLINE 0 0 0
gptid/3cf2d990-8506-11e7-bbff-d050996ff8e2 ONLINE 0 0 0
gptid/3e00c5e4-8506-11e7-bbff-d050996ff8e2 FAULTED 0 89 0 too many errors
gptid/3f071745-8506-11e7-bbff-d050996ff8e2 ONLINE 0 0 0

errors: No known data errors

Checking status of gmirror( devices:
Name Status Components
mirror/swap0 COMPLETE ada1p1 (ACTIVE)
ada0p1 (ACTIVE)
mirror/swap1 DEGRADED da6p1 (ACTIVE)
mirror/swap2 COMPLETE da4p1 (ACTIVE)
da3p1 (ACTIVE)
mirror/swap3 COMPLETE da2p1 (ACTIVE)
da1p1 (ACTIVE)

Nu heb ik geen idee wat met schijf aan de hand is maar die doet niets meer. Ik heb 'm vervangen ondertussen. De defecte schijf kan ik niet meer benaderen ik ga 'm RMA sturen. Maar stel dat ze 'm nog aan de praat krijgen wat kan je nog aan data afhalen van een schijf (1 van de 6) zonder de andere 5 schijven? Moet ik bang zijn dat die data die daarop ergens terecht kan komen?

[CurlyMo]

WTM schreef op woensdag 27 maart 2019 @ 14:36:
Nu heb ik geen idee wat met schijf aan de hand is maar die doet niets meer. Ik heb 'm vervangen ondertussen. De defecte schijf kan ik niet meer benaderen ik ga 'm RMA sturen. Maar stel dat ze 'm nog aan de praat krijgen wat kan je nog aan data afhalen van een schijf (1 van de 6) zonder de andere 5 schijven? Moet ik bang zijn dat die data die daarop ergens terecht kan komen?

Kunnen ze niks mee. Enige wat ze wellicht kunnen zien is dat de schijf bij een zpool hoorde genaamd h0m3p0rn

[ Voor 8% gewijzigd door CurlyMo op 27-03-2019 14:44 ]

[WTM]

CurlyMo schreef op woensdag 27 maart 2019 @ 14:43:
[...]

Kunnen ze niks mee. Enige wat ze wellicht kunnen zien is dat de schijf bij een zpool hoorde genaamd h0m3p0rn

Ok, dat is mooi. Ik stuur 'm dan zo weg ;-). (ben wel bang dat ik gehackt ben, je had precies door wat erop stond! )

[FireDrunk]

Theoretisch gezien kunnen ze een _heel_ klein beetje van je data lezen. Hele kleine bestanden worden namelijk opgeslagen in de metadata zelf, en niet gestriped. Maar dan moet het bestandje dacht ik < 4K zijn.

[azerty]

En als je dat niet wil, dan gooi je je disks eerst nog eens door LUKS voor je er een pool op maakt

[Dutch2007]

WTM schreef op woensdag 27 maart 2019 @ 14:36:


Nu heb ik geen idee wat met schijf aan de hand is maar die doet niets meer. Ik heb 'm vervangen ondertussen. De defecte schijf kan ik niet meer benaderen ik ga 'm RMA sturen. Maar stel dat ze 'm nog aan de praat krijgen wat kan je nog aan data afhalen van een schijf (1 van de 6) zonder de andere 5 schijven? Moet ik bang zijn dat die data die daarop ergens terecht kan komen?

https://www.quora.com/How...drive-from-a-RAID-5-array

In jouw geval dus ~1/6 van de data (lees: per bestand, niet van de gehele data in z'n geheel) en mogelijk iets meer wat binnen je stripe size zit / past

[ Voor 4% gewijzigd door Dutch2007 op 27-03-2019 21:42 ]

[Verwijderd]

Misschien iemand met meer ZFS kennis.
Ik heb op 3 servers:
scrub repaired 0B in 0h40m with 0 errors on Sun Mar 10 01:04:12 2019
scrub repaired 0B in 0h5m with 0 errors on Sun Mar 10 00:29:13 2019
scrub repaired 0B in 0h0m with 0 errors on Sun Mar 10 00:24:07 2019

Is dit normaal gedrag? Het zijn aparte servers met DDR4 (non-ecc) met alle drie 2 nvme modules (local storage) Ik probeer de melding te begrijpen, maar dat lukt niet helemaal. Disken zijn gezond.

[ Voor 10% gewijzigd door Verwijderd op 03-04-2019 15:39 ]

[Brent]

Er is gescrubt, en er zijn geen fouten gevonden, en dus ook niet gecorrigeerd. Op zich zou je normaal gesproken ook heel weinig tot geen fouten verwachten.

Wat volg je niet?

[Verwijderd]

Brent schreef op woensdag 3 april 2019 @ 15:46:
Er is gescrubt, en er zijn geen fouten gevonden, en dus ook niet gecorrigeerd. Op zich zou je normaal gesproken ook heel weinig tot geen fouten verwachten.

Wat volg je niet?

Gevonden.. dank.

code:

# Scrub the second Sunday of every month.
24 0 8-14 * * root [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ] && /usr/lib/zfs-linux/scrub

[ Voor 32% gewijzigd door Verwijderd op 03-04-2019 15:50 ]

[Brent]

Daarvoor moeten we wat meer weten van je OS en config. Ubuntu lijkt elke tweede zondag van de maand een automatische scrub te doen, dus dat klopt mooi met jouw log.

In principe is dat dus ook wat je wil (een scheduled scrub), tenzij je een specifieke reden hebt het niet te doen.

[edit] Net te laat

[ Voor 3% gewijzigd door Brent op 03-04-2019 15:53 ]

[FabiandJ]

Ik heb tijden via ESXi en daar een VM in met OpenSuse ZFS gedraaid.
De harde schijven zijn niet aangeraakt, maar ESXi met de VM van OpenSuse met ZFS is wel verloren gegaan. Nu heb ik ESXi opnieuw geïnstalleerd en hier weer een VM met OpenSuse opgezet.
Hoe krijg ik nu mijn oude ZFS datastore terug, is dat mogelijk?

En volgens mij hoort deze melding niet, maar en de suggestie helpt ook niet:
zpool status
/dev/zfs and /proc/self/mounts are required.
Try running 'udevadm trigger' and 'mount -t proc proc /proc' as root.

[CurlyMo]

Even een livecd van FreeBSD proberen en kijken of je de pool kan importeren. Dat sluit je het meest aan bij de ZFS basis.

[FabiandJ]

CurlyMo schreef op donderdag 4 april 2019 @ 16:48:
Even een livecd van FreeBSD proberen en kijken of je de pool kan importeren. Dat sluit je het meest aan bij de ZFS basis.

Ik heb mfsBSD op een USB stick gezet.

zpool import -a
cannot import 'datastore': pool may be in use from other system
use '-f' to import anyway

zpool import -a -f
Hij vind mijn datastore terug.

zpool status:
pool: datastore
state: ONLINE
status: Some supported feature are not enabled on the pool. The pool can still be used, but some features are unavailable.
action: Enable all feature using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the feature. See zpool-feature(7) for deatils.
scan: scrub canceled on Wed Jan 4 23:31:21 2017 ( whoops) als 2 jaar niet meer aangeraakt dus
config:
mijn hdd's met state online.
errors: No know data errors.

Volgens mij kunnen we concluderen dat de ZFS datastore er nog is en werkt, alleen mijn ZFS installatie op mijn OpenSuse VM is op één of andere reden niet goed, ik snap alleen niet waarom
Ik heb nu deze repo gepakt https://software.opensuse.org/package/zfsonlinux-zfs ipv https://software.opensuse.org/package/zfs
Als ik nu "zpool status" of "zpool import" krijg ik geen vreemde foutmelding meer, maar zit nu wel met het volgende:

code:

zpool import -a
cannot import 'datastore': pool was previously in use from another system.
Last accessed by mfsbsd (hostid=c4c3f25f) at Fri Apr  5 11:09:52 2019
The pool can be imported, use 'zpool import -f' to import the pool.

zpool import -f
   pool: datastore
     id: 8656163497243173429
  state: DEGRADED
 status: The pool was last accessed by another system.
 action: The pool can be imported despite missing or damaged devices.  The
        fault tolerance of the pool may be compromised if imported.
   see: http://zfsonlinux.org/msg/ZFS-8000-EY
 config:

        datastore                  DEGRADED
          raidz2-0                 DEGRADED
            sdb                    ONLINE
            sdc                    ONLINE
            sdd                    ONLINE
            sde                    ONLINE
            sdf                    ONLINE
            sdg                    ONLINE
            zfs-f41cc292fbabffe1   UNAVAIL
            DISK-PK1331PAH2LGLSp1  UNAVAIL

Als ik terug ga in dit topic, kan ik terug vinden dat ik ooit de datastore heb aangemaakt middels:

code:

zpool create -f datastore -o ashift=12 raidz2 scsi-SATA_Hitachi_HDS72404_PK1331PAH2JM7S scsi-SATA_Hitachi_HDS72404_PK1331PAH2JJ8S scsi-SATA_Hitachi_HDS72404_PK1331PAH2JL8S scsi-SATA_Hitachi_HDS72404_PK1331PAH2X17S scsi-SATA_HGST_HDN724040AL_PK2334PEK0WH4T scsi-SATA_HGST_HDN724040AL_PK2338P4HZ21RC scsi-SATA_Hitachi_HDS72404_PK1311PAGN9BJX scsi-SATA_Hitachi_HDS72404_PK1331PAH2LGLS

Volgens mij is dat toch wel wat anders dan hierboven staat.

[ Voor 67% gewijzigd door FabiandJ op 05-04-2019 12:00 ]

[CurlyMo]

FabiandJ schreef op vrijdag 5 april 2019 @ 11:06:
[...]
Volgens mij is dat toch wel wat anders dan hierboven staat.

Je moet ZFS vertellen dat hij moet importeren op partitielabels of disk id's. Commando daarvoor is vaker besproken in dit topic.

[FabiandJ]

CurlyMo schreef op vrijdag 5 april 2019 @ 12:10:
[...]

Je moet ZFS vertellen dat hij moet importeren op partitielabels of disk id's. Commando daarvoor is vaker besproken in dit topic.

Als ik dat doe krijg ik dit:

code:

zpool import -d /dev/disk/by-id/
   pool: datastore
     id: 8656163497243173429
  state: ONLINE
 status: The pool was last accessed by another system.
 action: The pool can be imported using its name or numeric identifier and
        the '-f' flag.
   see: http://zfsonlinux.org/msg/ZFS-8000-EY
 config:

        datastore                                      ONLINE
          raidz2-0                                     ONLINE
            wwn-0x5000cca22bcf3ea3                     ONLINE
            wwn-0x5000cca22bcf3e47                     ONLINE
            wwn-0x5000cca22bcf3e85                     ONLINE
            wwn-0x5000cca22bcf6981                     ONLINE
            wwn-0x5000cca250eaadb3                     ONLINE
            wwn-0x5000cca249dbc25a                     ONLINE
            scsi-SATA_Hitachi_HDS72404_PK1311PAGN9BJX  ONLINE
            wwn-0x5000cca22bcf4595                     ONLINE

Hij pakt maar één keer scsi* alle andere keren wwn*

[CurlyMo]

FabiandJ schreef op vrijdag 5 april 2019 @ 12:39:
[...]

Als ik dat doe krijg ik dit:[code]zpool import -d /dev/disk/by-id/

What's in a name. Het werkt nu toch?

[FabiandJ]

CurlyMo schreef op vrijdag 5 april 2019 @ 12:41:
[...]

What's in a name. Het werkt nu toch?

Klopt, maar vind het raar dat die niet voor alle de scsi naamgeving gebruikt.

[FireDrunk]

Om de labels opnieuw goed te zetten (nadat je vanalles gewijzigd hebt) moet je UDEV triggeren.

udevadm trigger

, normaal gebeurt dat bij boot.

Overigens kan ik je aanraden om partitielabels te gebruiken, en je pool te importeren door

zpool import -d /dev/disk/by-partlabel/

te gebruiken.
Als je ooit zonder die -d je pool geimporteerd hebt, zitten die namen in je zpool cache file. Beste is dan om even al je pools te exporteren, zpool cache file weggooien, en opnieuw te importeren met die -d optie.
Daarna staat alles by default goed als het goed is.

[FabiandJ]

FireDrunk schreef op vrijdag 5 april 2019 @ 14:36:
Om de labels opnieuw goed te zetten (nadat je vanalles gewijzigd hebt) moet je UDEV triggeren.

udevadm trigger

, normaal gebeurt dat bij boot.

Overigens kan ik je aanraden om partitielabels te gebruiken, en je pool te importeren door

zpool import -d /dev/disk/by-partlabel/

te gebruiken.
Als je ooit zonder die -d je pool geimporteerd hebt, zitten die namen in je zpool cache file. Beste is dan om even al je pools te exporteren, zpool cache file weggooien, en opnieuw te importeren met die -d optie.
Daarna staat alles by default goed als het goed is.

Oke, ik heb nu alleen een scrub lopen deze begon netjes met 750M/s en zou die in 6 uur klaar zijn, maar nu 1 uur verder is die gedaald naar 100M/s, iemand tips? Als ik zoek op Google vind ik wel tips maar dat is allemaal op FreeBSD/FreeNAS terwijl ik op Linux draai.

[FireDrunk]

In het begin loopt een scrub altijd wat langzamer, dat stijgt meestal na de eerste paar % wel.

[FabiandJ]

FireDrunk schreef op vrijdag 5 april 2019 @ 15:14:
In het begin loopt een scrub altijd wat langzamer, dat stijgt meestal na de eerste paar % wel.

Ik had de scrub gestopt en een zpool update gedaan, nu doe ik weer een scrub maar dit is niet heel snel

code:

  pool: datastore
 state: ONLINE
  scan: scrub in progress since Fri Apr  5 14:38:05 2019
        59.0G scanned out of 12.4T at 9.67M/s, 372h59m to go
        0B repaired, 0.46% done

[FireDrunk]

FireDrunk schreef op vrijdag 5 april 2019 @ 15:14:
In het begin loopt een scrub altijd wat langzamer, dat stijgt meestal na de eerste paar % wel.

[DataGhost]

Je kan de boel gewoon gebruiken tijdens het scrubben, dus ik mis even waarom je hier zo weinig geduld voor hebt? Zoals FireDrunk al zegt wil het in het begin nog wel eens langzaam zijn. Ik heb zelf het idee dat bijvoorbeeld het hebben van veel kleine bestanden ook een negatieve impact kan hebben op de snelheid, maar er kunnen tig redenen zijn. Buiten dat hoort een scrub op een lage I/O prio te lopen dus als je systeem verder druk is zal je scrubsnelheid ook laag zijn.

[FabiandJ]

FireDrunk schreef op vrijdag 5 april 2019 @ 16:24:
[...]

Ik wacht het af.

DataGhost schreef op vrijdag 5 april 2019 @ 16:38:
Je kan de boel gewoon gebruiken tijdens het scrubben, dus ik mis even waarom je hier zo weinig geduld voor hebt? Zoals FireDrunk al zegt wil het in het begin nog wel eens langzaam zijn. Ik heb zelf het idee dat bijvoorbeeld het hebben van veel kleine bestanden ook een negatieve impact kan hebben op de snelheid, maar er kunnen tig redenen zijn. Buiten dat hoort een scrub op een lage I/O prio te lopen dus als je systeem verder druk is zal je scrubsnelheid ook laag zijn.

Dat is het nou juist, het systeem doet helemaal niks volgens ESXi 62Mhz en gebruikt die 12GB aan memory, ik verwacht dus dat die sneller zou gaan.

[Freeaqingme]

Ik heb laatst in een nieuwe dedicated server een keer geen SSD's gezet, maar enkel 2 2TB HDD's (kostenbewust, zeg maar. Is alleen voor intern gebruik). Nou is 't allemaal toch niet heel snel, en overweeg ik 't geheel toch nog wat te optimaliseren.

Ik overweeg nu om hier 1 SSD van 120G bij te zetten. Hiervan zou ik bijv. 4G als ZIL kunnen inzetten, en 110G als L2ARC. Ik realiseer me dat met 1 enkele ZIL je na een fsync() nog data loss kan hebben als je ZIL zelf stuk zou gaan. Maar klopt mijn veronderstelling dat, omdat het allemaal journalled is, je nooit een corrupted FS krijgt op je HDD's?

Verder zijn eventuele verdere suggesties welkom of dit logisch is, of ik wellicht iets anders kan doen

offtopic:
Systeem heeft 8 cores, 32G RAM. Debian/Proxmox/ZoL

[ Voor 4% gewijzigd door Freeaqingme op 05-04-2019 16:42 ]

[dcm360]

FabiandJ schreef op vrijdag 5 april 2019 @ 16:42:
[...]

Ik wacht het af.

[...]

Dat is het nou juist, het systeem doet helemaal niks volgens ESXi 62Mhz en gebruikt die 12GB aan memory, ik verwacht dus dat die sneller zou gaan.

CPU load is geen indicatie of een scrub sneller kan of niet. De disks zijn altijd de limiterende factor, tenzij je extreem snelle SSD's combineert met een trage CPU.

[jeppert]

Tijd om het spulletje eens een update te geven, na de update overigens niet meer welkom hier

[FireDrunk]

9.2... old skool. Dat is bijna hetzelfde als nog gebruik maken van Windows XP

[jeppert]

Onder het mom van 'If it aint broke..."

Nee ik heb deze server in 2013 neergezet, en alleen aangehad wanneer ik zelf backups maakte of een backup nodig had. Rond 2015 een aantal schijven verwisselt. Toch tevreden: 6 jaar zonder updates en hij draait nog als een zonnetje.

[FabiandJ]

Hmm volgens mij gaat er iets fout bij mij

code:

  pool: datastore
 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 Thu Apr 11 15:19:21 2019
        107G scanned out of 12.4T at 41.1M/s, 87h26m to go
        17.0G resilvered, 0.84% done
config:

        NAME                          STATE     READ WRITE CKSUM
        datastore                     DEGRADED     0     0  155K
          raidz2-0                    DEGRADED     0     0  311K
            scsi-35000cca22bcf3ea3    DEGRADED     0     0     0  too many errors  (resilvering)
            wwn-0x5000cca22bcf3e47    DEGRADED     0     0     0  too many errors
            wwn-0x5000cca22bcf3e85    DEGRADED     0     0     0  too many errors
            wwn-0x5000cca22bcf6981    DEGRADED     0     0     0  too many errors  (resilvering)
            wwn-0x5000cca250eaadb3    REMOVED      0     0     0  (resilvering)
            replacing-5               DEGRADED     0     0     2
              wwn-0x5000cca249dbc25a  REMOVED      0     0     0  (resilvering)
              wwn-0x5000cca22bc1166c  ONLINE       0     0     0  (resilvering)
            9873598484677272452       UNAVAIL      0     0     0  was /dev/disk/by-id/wwn-0x5000cca22bc93a9a-part1
            replacing-7               DEGRADED     0     0 2.96K
              wwn-0x5000cca22bcf4595  REMOVED      0     0     0
              wwn-0x5000cca23dc853f1  ONLINE       0     0     0  (resilvering)

errors: Permanent errors have been detected in the following files:

        datastore/backup:<0x0>
        /mnt/backup/iRacing/replay/subses5519119.rpy
        /mnt/backup/iRacing/replay/subses5525441.rpy
        /mnt/backup/iRacing/replay/subses5526102.rpy
        /mnt/backup/iRacing/replay/subses5526797.rpy
        /mnt/backup/iRacing/replay/subses5531163.rpy
        /mnt/backup/iRacing/replay/subses5531724.rpy
        /mnt/backup/iRacing/replay/subses5532922.rpy
        /mnt/backup/iRacing/replay/subses5533571.rpy
        /mnt/backup/iRacing/replay/subses5539055.rpy
        /mnt/backup/iRacing/replay/subses5540261.rpy
        /mnt/backup/iRacing/replay/subses5540906.rpy
        /mnt/backup/iRacing/replay/subses5541626.rpy
enzenzenz

Hij blijft ook telkens de disk "wwn-0x5000cca250eaadb3" eruit gooien terwijl er volgens SMART niks mee aan de hand is.

[Freeaqingme]

FabiandJ schreef op donderdag 11 april 2019 @ 15:39:
Hmm volgens mij gaat er iets fout bij mij

Hoe is het aangesloten? Mijn eerste ingeving is "kapotte raid controller", maar het kan natuurlijk van alles zijn. Kan je iets in dmesg of andere log files over mogelijke hardware problemen vinden?

Edit: Ter toevoeging, ik weet niet tot in hoeverre de data nu nog accessible is, maar indien mogelijk zou ik 't even read-only mounten.

[ Voor 16% gewijzigd door Freeaqingme op 11-04-2019 16:45 ]

[CurlyMo]

En even een dag memtest86 draaien.

[Q]

FabiandJ schreef op donderdag 11 april 2019 @ 15:39:
Hmm volgens mij gaat er iets fout bij mij

Wat zijn de specs van de machine, wat voor geheugen zit er in?

[FabiandJ]

Freeaqingme schreef op donderdag 11 april 2019 @ 15:51:
[...]


Hoe is het aangesloten? Mijn eerste ingeving is "kapotte raid controller", maar het kan natuurlijk van alles zijn. Kan je iets in dmesg of andere log files over mogelijke hardware problemen vinden?

Edit: Ter toevoeging, ik weet niet tot in hoeverre de data nu nog accessible is, maar indien mogelijk zou ik 't even read-only mounten.

Ik heb er nog niks op geschreven probeer op dit moment alleen maar mijn zfs pool te fixen

Q schreef op donderdag 11 april 2019 @ 20:44:
[...]


Wat zijn de specs van de machine, wat voor geheugen zit er in?

Er zit geen ECC geheugen is, maar standaard 2x8GB Kingston uit mijn hoofd.
Verder zitten de disks op een HBA controller van LSI 2116, welke middels passthrough direct doorgegeven wordt naar de ESXi VM. Ik wil testen of het mogelijk de controller is, dus heb nu de disk die er telkens uitvliegt op het moederbord aangesloten, maar ik krijg die disk niet in de VM te zien...

Heb nu op een andere disk OpenSuse gezet en probeer het direct daarmee dus zonder tussenkomst van ESXi, maar dat gaat ook niet goed:

code:

zpool import -d /dev/disk/by-id/ 
   pool: datastore
     id: 8656163497243173429
  state: FAULTED
 status: The pool metadata is corrupted.
 action: The pool cannot be imported due to damaged devices or data.
    The pool may be active on another system, but can be imported using
    the '-f' flag.
   see: http://zfsonlinux.org/msg/ZFS-8000-72
 config:

    datastore                     FAULTED  corrupted data
      raidz2-0                    ONLINE
        scsi-35000cca22bcf3ea3    ONLINE
        wwn-0x5000cca22bcf3e47    ONLINE
        wwn-0x5000cca22bcf3e85    ONLINE
        wwn-0x5000cca22bcf6981    ONLINE
        wwn-0x5000cca250eaadb3    ONLINE
        replacing-5               ONLINE
          wwn-0x5000cca249dbc25a  ONLINE
          wwn-0x5000cca22bc1166c  ONLINE
        wwn-0x5000cca22bc93a9a    ONLINE
        replacing-7               ONLINE
          wwn-0x5000cca22bcf4595  ONLINE
          wwn-0x5000cca23dc853f1  ONLINE

zpool import -d -f /dev/disk/by-id/ 
cannot import '/dev/disk/by-id/': no such pool available

zpool import datastore
cannot import 'datastore': I/O error
    Destroy and re-create the pool from
    a backup source.

[ Voor 14% gewijzigd door FabiandJ op 11-04-2019 21:25 ]

[Operations]

Ik ga toch maar is beginnen aan een FreeNAS setup. Dit zou dan als backup van mijn normale Areca RAID6 array zijn. Ik ben een typisch hardware RAID jongetje Elke server van mij heeft een Areca kaart. Tot nu toe maak ik de backup van de primaire Array gewoon op een exacte dezelfde secundaire array (op andere machine). Tot zover stukje inleiding, ik weet niet zeker of mijn vraag nou hardware is (en dus hier niet hoort) of software/installatie en hier wel mag.

Mijn vraag gaat over dit stukje (uit startpost):

Met meerdere SSDs wil je alle taken spreiden over alle SSDs. LARC doe je altijd in striping (RAID0) terwijl SLOG je voor mirroring kunt kiezen.

Hoe groot moet ik de partities dan maken?
Stel je heb twee SSDs van 128GB, dus totaal 256GB. Op je SSD maak je dan partities aan zoals:
- partitie 1 voor systeem/boot pool: 28GiB
- partitie 2 voor L2ARC cache: 60GiB
- partitie 3 voor SLOG: 4GiB
- rest van de ruimte onbenut laten als overprovisioning

Voor LARC gebruik je RAID0 en voor SLOG RAID1. Maar het moet wel allebei op dezelfde 2x128GB SSD's. Maar ik kan toch maar 1 array aanmaken op die 2x128GB? Dus of RAID0 of 1 toch? En in dit voorbeeld wordt 92GB gebruikt (van die 256GB) is er dan zoveel nodig voor overprovising? Mocht vraag toch in het DIY topic horen, dan mag de vraag uiteraard verplaatst worden (incl. mijn welgemeende excuses dan )

[mdbraber]

Op mijn homeserver heb ik in totaal 4x5TB (shucked Seagate) in een 2x2x5TB mirrored setup. Daarvan is nu 1 disk FAULTED:

code:

    NAME                STATE     READ WRITE CKSUM
    tank0               DEGRADED     0     0     0
      mirror-0          ONLINE       0     0     0
        ata-QT85_crypt  ONLINE       0     0     0
        ata-RSSY_crypt  ONLINE       0     0     0
      mirror-1          DEGRADED     0     0     0
        ata-R2QJ_crypt  ONLINE       0     0     0
        ata-RTSJ_crypt  FAULTED      0     4     0  too many errors

Is er een manier om nog te checken of de ata-RTSJ_crypt disk te redden is op eoa manier? Ik zag elders dat je evt. kan proberen om 'm te overschrijven met `dd` en opnieuw te gebruiken, maar het lijkt me handiger ergens een soort 'sanity' check te doen wat er uberhaupt mis is met de disk.

Wat zou jullie advies zijn?

[FireDrunk]

Eerst wat SMART waardes bekijken?

[mdbraber]

FireDrunk schreef op vrijdag 12 april 2019 @ 08:28:
Eerst wat SMART waardes bekijken?

Excuus, dat had ik inderdaad ook gedaan, maar daarbij lijkt het wel alsof de disk helemaal niets meer doet...

root@zark:~# smartctl -a /dev/disk/by-id/ata-ST5000LM000-2AN170_WCJ0RTSJ
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.17-1-pve] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

Short INQUIRY response, skip product id
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
root@zark:~# smartctl -a -T permissive /dev/disk/by-id/ata-ST5000LM000-2AN170_WCJ0RTSJ
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.15.17-1-pve] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

Short INQUIRY response, skip product id

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature: 0 C
Drive Trip Temperature: 0 C

Read defect list: asked for grown list but didn't get it
Error Counter logging not supported

Device does not support Self Test logging

[Giesber]

Operations schreef op donderdag 11 april 2019 @ 21:48:
Ik ga toch maar is beginnen aan een FreeNAS setup. Dit zou dan als backup van mijn normale Areca RAID6 array zijn. Ik ben een typisch hardware RAID jongetje Elke server van mij heeft een Areca kaart. Tot nu toe maak ik de backup van de primaire Array gewoon op een exacte dezelfde secundaire array (op andere machine). Tot zover stukje inleiding, ik weet niet zeker of mijn vraag nou hardware is (en dus hier niet hoort) of software/installatie en hier wel mag.

Mijn vraag gaat over dit stukje (uit startpost):

[...]

Voor LARC gebruik je RAID0 en voor SLOG RAID1. Maar het moet wel allebei op dezelfde 2x128GB SSD's. Maar ik kan toch maar 1 array aanmaken op die 2x128GB? Dus of RAID0 of 1 toch? En in dit voorbeeld wordt 92GB gebruikt (van die 256GB) is er dan zoveel nodig voor overprovising? Mocht vraag toch in het DIY topic horen, dan mag de vraag uiteraard verplaatst worden (incl. mijn welgemeende excuses dan )

Dat stukje gaat over een optionele cache en een aparte logging device (ook optioneel). Misschien moet je je eerst de vraag stellen of je dat wel nodig hebt voor de backup van een backup.

[Operations]

Giesber schreef op vrijdag 12 april 2019 @ 10:54:
[...]

Dat stukje gaat over een optionele cache en een aparte logging device (ook optioneel). Misschien moet je je eerst de vraag stellen of je dat wel nodig hebt voor de backup van een backup.

Nou ja ik had een beetje bedacht van als het nou echt goed werkt en ik vind het leuk dan ga ik het wel meer inzetten. Dus vandaar dat ik wel meteen voor de meest complete / meest optimale setup wil gaan. Ik heb een 10GB netwerk dus qua performance zou het wel prettig zijn als ik er het maximale uithaal anders geeft dat een vertekend beeld die wellicht negatieve invloed heeft op mijn eindconclusie. (Ook als is het nu dan nog voor de backup)

[ Voor 6% gewijzigd door Operations op 12-04-2019 10:58 ]

[Q]

FabiandJ schreef op donderdag 11 april 2019 @ 21:23:

Er zit geen ECC geheugen is, maar standaard 2x8GB Kingston uit mijn hoofd.

Ik zou het advies van CurlyMo even opvolgen: memtest draaien en 24 uur. Ik zou ook niets met die disks of data proberen te doen totdat je die test hebt gedaan.

[FireDrunk]

mdbraber schreef op vrijdag 12 april 2019 @ 08:45:
[...]


Excuus, dat had ik inderdaad ook gedaan, maar daarbij lijkt het wel alsof de disk helemaal niets meer doet...


[...]

Dat is wel vreemd, SMART zou gewoon moeten werken... Hangt die schijf aan een specifieke controller of je moederbord? In het geval van dat tweede, staat SMART toevallig uit in je BIOS/UEFI?

[mdbraber]

FireDrunk schreef op zaterdag 13 april 2019 @ 10:35:
[...]

Dat is wel vreemd, SMART zou gewoon moeten werken... Hangt die schijf aan een specifieke controller of je moederbord? In het geval van dat tweede, staat SMART toevallig uit in je BIOS/UEFI?

Bij alle andere schijven geeft ie gewoon SMART terug en dat heeft hij bij deze ook wel gedaan daarvoor. Ik ga nog kijken of het evt een kapotte kabel is...

[revox862]

Voor een nieuwe ZFS build twijfel ik tussen de volgende pool configuraties:

• 3x RAIDZ2 6x 4TB (42.14TiB)
• 2x RAIDZ2 6x 6TB (41.97TiB)
• 1x RAIDZ2 10x 6TB (40.22TiB)
• 1x RAIDZ3 11x 6TB (42.27TiB)

Wat zouden jullie doen? Het is voornamelijk archiefopslag.

[Giesber]

revox862 schreef op woensdag 8 mei 2019 @ 15:33:
Voor een nieuwe ZFS build twijfel ik tussen de volgende pool configuraties:

• 3x RAIDZ2 6x 4TB (42.14TiB)
• 2x RAIDZ2 6x 6TB (41.97TiB)
• 1x RAIDZ2 10x 6TB (40.22TiB)
• 1x RAIDZ3 11x 6TB (42.27TiB)

Wat zouden jullie doen? Het is voornamelijk archiefopslag.

De keuze tussen RAIDZ2 en RAIDZ3 is vooral geleid door hoe groot de kans op dataverlies door een defecte schijf mag zijn (heel klein of onnoemelijk klein). Dat hangt af van het soort data, of ze nog ergens anders staat (en wat dan de restore snelheid moet zijn), ...
Wat zijn de beweegredenen om wel of niet voor meerdere pools te gaan (waarom zou 1 grote pool niet voldoen)?

[revox862]

Giesber schreef op donderdag 9 mei 2019 @ 10:08:
De keuze tussen RAIDZ2 en RAIDZ3 is vooral geleid door hoe groot de kans op dataverlies door een defecte schijf mag zijn (heel klein of onnoemelijk klein). Dat hangt af van het soort data, of ze nog ergens anders staat (en wat dan de restore snelheid moet zijn), ...
Wat zijn de beweegredenen om wel of niet voor meerdere pools te gaan (waarom zou 1 grote pool niet voldoen)?

Oh, ja, ik bedoelde ook 1 grote pool met de genoemde punten als vdev configuratie.
Het zou jammer zijn als de data weg was, maar niet rampzalig. De meerderheid is meuk

[Paul]

Het blijft één pool, maar met meerdere vdevs Wat vooral voordelen biedt aan IOPS / doorvoer.

revox862 schreef op woensdag 8 mei 2019 @ 15:33:
Wat zouden jullie doen? Het is voornamelijk archiefopslag.

@work gaan we op advies van de leverancier (IBM) tot (volgens mij) 24 schijven in een DRAID6 (2 schijven distributed parity, 1 schijf al distributed spare), al zijn de traagste / grootste daarvan 10k schijven van 1.8 TB, geen SATA-schijven van 3x zo groot.

Optie 1 is het meest veilig (1/3e van de schijven is parity disk) maar kost 18 aansluitingen, optie 3 is het goedkoopst. Ik denk dat ik voor optie 4 zou gaan; bijna net zo veilig als optie 1 en een stuk goedkoper.

[Freeaqingme]

Paul schreef op donderdag 9 mei 2019 @ 11:02:
@work gaan we op advies van de leverancier (IBM) tot (volgens mij) 24 schijven in een DRAID6 (2 schijven distributed parity, 1 schijf al distributed spare) [...]

Uit pure nieuwsgierigheid, wat voor dienst of product nemen jullie van IBM af dat zij advies geven over ZFS? Ik associeer dat toch vooral met Sun/Oracle, Nexenta & Joyent.

[FireDrunk]

@Freeaqingme Waar lees je dat hij ZFS gebruikt? DRAID6 != ZFS.

[Paul]

Niet Geen idee wat een Storwize draait als filesystem / erasure coding mechanisme / onderliggende techniek, maar ik betwijfel of het ZFS is. En DRAID6 is iets anders dan ZRAID2.

De onderliggende principes (de noodzaak te rebuilden / resilveren na een uitval, dat dit alle data van alle schijven moet bekijken en parity berekenen, doorloopzijd etc) zijn redelijk gelijk. Ik bedoel vooral aan te geven dat IBM niet heel bang is voor veel schijven in één array.

[Freeaqingme]

FireDrunk schreef op donderdag 9 mei 2019 @ 11:39:
@Freeaqingme Waar lees je dat hij ZFS gebruikt? DRAID6 != ZFS.

Ah. We zitten in het ZFS topic, zodoende mijn associatie. Nvm

[revox862]

Paul schreef op donderdag 9 mei 2019 @ 11:02:
Optie 1 is het meest veilig (1/3e van de schijven is parity disk) maar kost 18 aansluitingen, optie 3 is het goedkoopst. Ik denk dat ik voor optie 4 zou gaan; bijna net zo veilig als optie 1 en een stuk goedkoper.

Een stuk goedkoper valt tegen Ik weet nog niet of ik WD Red of HGST DC HC310 neem.

#	Category	Product	Prijs	Subtotaal
11	Interne harde schijven	HGST Ultrastar 7K6 SATA (512e, SE), 6TB	€ 223,75	€ 2.461,25
18	Interne harde schijven	WD Red (64MB cache), 4TB	€ 119,50	€ 2.151,-
11	Interne harde schijven	WD Red (64MB cache), 6TB	€ 189,60	€ 2.085,60
Bekijk collectie Importeer producten			Totaal	€ 6.697,85

[Paul]

Je rekent nu alleen met (dure) schijven. Je zit ook met bays en controllers

[revox862]

Paul schreef op donderdag 9 mei 2019 @ 16:18:
Je rekent nu alleen met (dure) schijven. Je zit ook met bays en controllers

True Ik leun ook steeds meer naar 11x 6TB. Bedankt in ieder geval.

[mdbraber]

ZFSonLinux 0.8 (met oa native encryption) is sinds 23 mei officieel uit: https://zfsonlinux.org/

[nero355]

revox862 schreef op donderdag 9 mei 2019 @ 16:36:
True Ik leun ook steeds meer naar 11x 6TB. Bedankt in ieder geval.

Waarom niet 6x 10 of 12 TB of zelfs 14 TB

Ik had ook 6x 11 TB in RAIDZ3 plannen, maar dat heb ik maar lekker gelaten voor wat het is met de huidige nieuwe grote HDD modellen

[revox862]

nero355 schreef op zaterdag 25 mei 2019 @ 12:36:
Waarom niet 6x 10 of 12 TB of zelfs 14 TB

Ik had ook 6x 11 TB in RAIDZ3 plannen, maar dat heb ik maar lekker gelaten voor wat het is met de huidige nieuwe grote HDD modellen

Voornamelijk om niet een te lange resilver tijd te hebben.

[dcm360]

mdbraber schreef op zaterdag 25 mei 2019 @ 12:24:
ZFSonLinux 0.8 (met oa native encryption) is sinds 23 mei officieel uit: https://zfsonlinux.org/

Ah, en TRIM heeft het ook gehaald zo te zien. Kan ik LVM weer inruilen voor ZFS zodra het in de repositories terechtkomt

[mdbraber]

Ik heb voor de tweede keer in korte tijd een drive in mijn ZFS pool die op FAULTED staat:

code:

root@zark:~# zpool status tank0
  pool: tank0
 state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
    repaired.
  scan: scrub repaired 0B in 3h11m with 0 errors on Sun May 12 03:35:35 2019
config:

    NAME            STATE     READ WRITE CKSUM
    tank0           DEGRADED     0     0     0
      mirror-0      DEGRADED     0     0     0
        QT85_crypt  FAULTED      0    20     0  too many errors
        RSSY_crypt  ONLINE       0     0     0
      mirror-1      ONLINE       0     0     0
        R2QJ_crypt  ONLINE       0     0     0
        CFPR_crypt  ONLINE       0     0     0

Hoe kan ik het beste nagaan wat er met deze drive is? Een vorige drive die een zelfde soort error had heb ik vervangen door een nieuwe, maar toen ik de oude (FAULTED) drive weer probeerde te gebruiken in een nieuwe ZFS pool (na 'm gezapt te hebben) was er niets aan de hand.

Kan ik 'gewoon' zpool clear doen en kijken wat er gebeurt of zijn er manieren om uit te vinden of er echt iets mis is met de drive?

[dcm360]

Hm, dat zijn write errors als ik de uitlijning correct interpreteer? (Ah, dat is gefixt ondertussen) De eerste stap is sowieso om te kijken naar de SMART-waardes van de schijf, mijn verwachting is dat dat misschien wat zegt over kabelfouten.

[ Voor 7% gewijzigd door dcm360 op 26-05-2019 14:20 ]

[Freeaqingme]

Wat voor device zijn die _crypt dingen? Verwijst dat rechtstreeks naar een fysieke disk, is dat een LUKS iets, of nog iets anders?

[mdbraber]

dcm360 schreef op zondag 26 mei 2019 @ 14:15:
Hm, dat zijn write errors als ik de uitlijning correct interpreteer? (Ah, dat is gefixt ondertussen) De eerste stap is sowieso om te kijken naar de SMART-waardes van de schijf, mijn verwachting is dat dat misschien wat zegt over kabelfouten.

Het interessante is dus dat net als de vorige keer smartctl niets meer teruggeeft. Ik heb nu echter de disk die eerder is stuk gegaan teruggezet die nu wel weer reageert op smartctl. Het was een andere SATA kabel de vorige keer, dus daar kan het niet aan liggen (of beide kabels moeten brak zijn, dat kan theoretisch nog)

Freeaqingme schreef op zondag 26 mei 2019 @ 14:22:
Wat voor device zijn die _crypt dingen? Verwijst dat rechtstreeks naar een fysieke disk, is dat een LUKS iets, of nog iets anders?

Dat verwijst inderdaad naar LUKS - ik gebruik LUKS encrypted disks voor de pool. De naamgeving _crypt is mijn eigen schema en verwijst naar de /dev/mapper versie van de disk onder LUKS.

/EDIT de SATAIII kabels zijn trouwens Delock kabels - wel benieuwd of mensen daar goede of minder goede ervaringen mee hebben.

[ Voor 5% gewijzigd door mdbraber op 26-05-2019 14:57 ]

[nero355]

mdbraber schreef op zondag 26 mei 2019 @ 14:48:
Het interessante is dus dat net als de vorige keer smartctl niets meer teruggeeft.

Dat is wel erg raar!

Ik heb nu echter de disk die eerder is stuk gegaan teruggezet die nu wel weer reageert op smartctl. Het was een andere SATA kabel de vorige keer, dus daar kan het niet aan liggen (of beide kabels moeten brak zijn, dat kan theoretisch nog)

Poorten en Controllers kunnen ook stuk gaan hé!

/EDIT de SATAIII kabels zijn trouwens Delock kabels - wel benieuwd of mensen daar goede of minder goede ervaringen mee hebben.

Ik vind het persoonlijk geen geweldig merk, maar een kabeltje moeten ze nog net wel kunnen maken lijkt mij...

[Sando]

ZoL 0.8 met native encryption is uitgegeven.

Draait erg soepel.

[mdbraber]

nero355 schreef op zondag 26 mei 2019 @ 22:47:
Poorten en Controllers kunnen ook stuk gaan hé!

Als het nu nog een keer gebeurt ga ik de kabels eens verwisselen. Tot nu toe waren het verschillende poorten en verschillende kabels, maar wie weet...

[mdbraber]

Sando schreef op maandag 27 mei 2019 @ 13:38:
ZoL 0.8 met native encryption is uitgegeven.

Op de Proxmox fora is ook al aangekondigd dat het in Proxmox 6.0 komt.

[Freeaqingme]

mdbraber schreef op maandag 27 mei 2019 @ 14:49:
[...]


Op de Proxmox fora is ook al aangekondigd dat het in Proxmox 6.0 komt.

Nice! Weet je wanneer we die ongeveer kunnen verwachten?

[FireDrunk]

ZFS ZRAID Expansion Alpha Preview:
https://github.com/zfsonlinux/zfs/pull/8853

It's coming!!

[Freeaqingme]

Nice!

Sponsored by: The FreeBSD Foundation

Geen idee waar ZoL devs normaal gesproken hun inkomen vandaan halen(?), maar de FreeBSD-samenwerking werpt in ieder geval z'n vruchten af.

[FireDrunk]

FreeBSD is zelfs bezig om de ZFSonLinux base repo BSD compatible te maken, zodat zfsonlinux de officiele repo wordt van BSD.

Dat is pas gek

Bron: https://www.phoronix.com/...m&px=FreeBSD-ZFS-On-Linux

[ Voor 22% gewijzigd door FireDrunk op 04-06-2019 09:48 ]

[mdbraber]

Freeaqingme schreef op maandag 27 mei 2019 @ 14:51:
[...]
Nice! Weet je wanneer we die ongeveer kunnen verwachten?

Op de Proxmox fora wordt aangegeven dat die pas te verwachten is enige tijd nadat Debian 10 (buster) uitkomt, omdat Proxmox 6 zal draaien op die nieuwe versie. Ik gok dus niet voor het einde van het jaar.

[nero355]

FireDrunk schreef op dinsdag 4 juni 2019 @ 09:47:
FreeBSD is zelfs bezig om de ZFSonLinux base repo BSD compatible te maken, zodat zfsonlinux de officiele repo wordt van BSD.

Dat is pas gek

Bron: https://www.phoronix.com/...m&px=FreeBSD-ZFS-On-Linux

Raar... maar uiteindelijk alleen maar beter voor beide kampen denk ik

Wat ik wel echt raar vind ik dat stukje tekst is dat blijkbaar ZoL meer features heeft dan de FreeBSD ZFS implementatie
Ik dacht altijd dat FreeBSD voorop liep ?!

Onlangs mijn "VMbakkie" van ESXi naar Proxmox omgegooid en uiteraard meteen alles ZFS gemaakt maar was nog van plan om daarnaast een FreeBSD ZFS NAS te bouwen, echter ga ik nu twijfelen...

<sub>FreeBSD blijft toch wel mijn favoriet van alle systemen, maar je wordt zo doodgegooid met afgeleiden van Debian en Red Hat dat het beroepsmatig erg moeilijk is om daar niet mee in aanraking te komen...

Niet dat ik iets tegen de andere OS'en heb of zo, maar ik kom gewoon niet aan mijn FreeBSD lol toe!</sub>

[FireDrunk]

nero355 schreef op woensdag 5 juni 2019 @ 13:57:
[...]

Raar... maar uiteindelijk alleen maar beter voor beide kampen denk ik

Zeker, die werelden communiceren al jaren prima met elkaar.

Wat ik wel echt raar vind ik dat stukje tekst is dat blijkbaar ZoL meer features heeft dan de FreeBSD ZFS implementatie
Ik dacht altijd dat FreeBSD voorop liep ?!

Nope, al een flinke tijd niet meer.

Onlangs mijn "VMbakkie" van ESXi naar Proxmox omgegooid en uiteraard meteen alles ZFS gemaakt maar was nog van plan om daarnaast een FreeBSD ZFS NAS te bouwen, echter ga ik nu twijfelen...

<sub>FreeBSD blijft toch wel mijn favoriet van alle systemen, maar je wordt zo doodgegooid met afgeleiden van Debian en Red Hat dat het beroepsmatig erg moeilijk is om daar niet mee in aanraking te komen...

Niet dat ik iets tegen de andere OS'en heb of zo, maar ik kom gewoon niet aan mijn FreeBSD lol toe!</sub>

Ik ben juist echt afgestapt van BSD, enige waar ik het nog gebruik is met pfSense op mijn router
Verbruik is relatief hoog, onderhoud is matig, patchen blijft lastig, lang niet alle software werkt (goed).
Dingen als Docker werken amper. Nee, geen BSD meer voor mij.

[nero355]

FireDrunk schreef op woensdag 5 juni 2019 @ 14:00:
Ik ben juist echt afgestapt van BSD, enige waar ik het nog gebruik is met pfSense op mijn router

Die trend zie ik dus overal...

Verbruik is relatief hoog, onderhoud is matig, patchen blijft lastig, lang niet alle software werkt (goed).
Dingen als Docker werken amper. Nee, geen BSD meer voor mij.

Tja, Docker... Leuk idee, maar persoonlijk vind ik het meer iets voor developers om hun software makkelijk te testen of met custom dependencies en dergelijke te leveren dan een tool voor een beheerder zeg maar...

Ondertussen lijkt echter iedereen verslaafd eraan te zijn en zal ik waarschijnlijk daarin mee moeten gaan

FreeBSD vind ik persoonlijk echt geweldig :
- Veel meer controle over de software die je installeert.
- Veel meer keuze wat betreft de software versie die je installeert.
- Heel logisch ingedeeld en wordt meer als een geheel OS ontwikkeld dan de rest naar mijn mening