Het grote ZFS topic

[Q]

sam_vde schreef op woensdag 23 maart 2016 @ 17:38:
Je draait alles om. Ik kan aantonen dat het probleem bestaat en dat er een relatief eenvoudige en goedkope oplossing voor is. Jij kan helemaal niet aantonen dat het probleem niet relevant is maar toch blijf je dat maar aanhalen.

Wil jij het risico nemen alhoewel je het eigenlijk helemaal niet kent? Prima. Dat maakt het niet mijn probleem aan jou aan te tonen welk risico je neemt. Je kent de feiten net als ik. Iedereen moet zelf maar uitmaken hoe belangrijk hun data is.

Nee, je draait het zelf om. De bewijslast ligt bij degene die iets wil aantonen. Jij meent dat het een risico is waar thuisgebruikers zich zorgen over moeten maken, toon dan maar aan.

Het argument 'we weten het niet' is niet waar, we weten donders goed dat het risico op silent data corruption op zijn minst zo klein is dat het uitermate weinig voorkomt. En dat is ook heel erg goed te verklaren. Als we een corrupte foto vinden weten we nog steeds niet waarom deze corrupt is geraakt.

Misschien zijn er wel een stel post-millenial punk elfjes met machine geweren en een half opgerookte vuvuzela naar je op pad om je te versmaden!.

Misschien wel niet.

We weten het niet.

Ik zou je uit voorzorg maar alvast gaan verstoppen.



Inderdaad moeten mensen zelf uitmaken wat ze willen investeren in tijd en geld om hun data te beschermen. Om hun te helpen bij deze keuze zou ik zo min mogelijk bangmakerij willen gebruiken en mensen eerlijke informatie geven.

Legacy is goed genoeg. ZFS is beter. Als je de tijd, geld en moeite er in wilt stoppen, kun je met ZFS een veiliger nas bouwen dan met legacy platformen. Kies maar.

[ Voor 12% gewijzigd door Q op 23-03-2016 20:02 ]

[revox862]

Ach, hoeveel data is nou echt belangrijk. Was het maar "gevaarlijk", dan was ik het eindelijk kwijt.

[sam_vde]

Q schreef op woensdag 23 maart 2016 @ 19:59:
Jij meent dat het een risico is waar thuisgebruikers zich zorgen over moeten maken, toon dan maar aan.

Haha. Toon jij eerst maar eens aan dat ik dat beweerd heb, want dat meen ik helemaal niet.


Het verschil uitleggen tussen elfjesverhalen en aangetoonde technische feiten laat ik over aan iemand anders, dat soort gedoe heb ik even geen zin in.

[FireDrunk]

Deze discussie is (op een iets volwassener niveau) ook uitgebreid gevoerd in dit topic: ECC geheugen voor zelfbouw ZFS NAS?

Er zijn geen goede of foute antwoorden, er is een middenweg.

Wat Q kort door de bocht zegt is: Als het zo'n groot probleem is/was, waarom klagen mensen dan niet bij QNAP en Synology dat ze veel corrupte files hebben?

En wat jij zegt is: Dat is geen bewijs dat het probleem er niet is.

Beide is waar... Ze sluiten elkaar niet uit... Misschien moet je het vergelijken met het broeikaseffect. We kunnen met aan zekerheid grenzende waarschijnlijkheid zeggen dat het er is, maar of we er echt last van hebben?

De keuze om iets te doen aan iets waar je niet zeker last van hebt (verzekeringen bijvoorbeeld?) is hoogstepersoonlijk. Ik heb een inboedel verzekering inclusief diefstalverzekering. Daarentegen ben ik nog nooit bestolen... En ik ken letterlijk niemand waarvan het huis echt leeggeroofd is. Dus waar maken we ons druk om?

Het is een beetje kans vs impact. Als jij je data zo belangrijk vind dat die kleine kans gemitigeerd wordt prima.

[ Voor 24% gewijzigd door FireDrunk op 24-03-2016 08:30 ]

[Q]

sam_vde schreef op donderdag 24 maart 2016 @ 03:21:
[...]


Haha. Toon jij eerst maar eens aan dat ik dat beweerd heb, want dat meen ik helemaal niet.


Het verschil uitleggen tussen elfjesverhalen en aangetoonde technische feiten laat ik over aan iemand anders, dat soort gedoe heb ik even geen zin in.

Jij maakt je wel degelijk druk over QNAPs en Synology devices en vind die dingen onveilig maar in zie geen onderbouwing eigenlijk dat deze dingen ook echt 'gevaarlijk' zijn.

Je kan helemaal niet beoordelen wat acceptabel is. Die frequentie en risico, daar weet je echt helemaal niets van omdat het net stille corruptie betreft. Er zijn bergen data die vaak decennia meegaan en gekopieerd worden telkens er een nieuwe computer komt, en die jarenlang niemand bekijkt.

Nog 1 opmerking: ik raad niemand commerciële nas boxen zoals Synology aan zolang ze dit probleem niet oplossen en mensen een vals gevoel van veiligheid blijven aanpraten.

Mensen moeten zelf bepalen wat ze willen investeren in hun data, maar wij zijn vaak de techno nerds en geven andere mensen advies. Laten we zo eerlijk mogelijk zijn met dat advies en mensen niet ongefundeerd bang maken.

[ Voor 40% gewijzigd door Q op 24-03-2016 09:00 ]

[idef1x]

Verwijderd schreef op dinsdag 22 maart 2016 @ 21:43:
Soulcrusher, het is bad practise om een ZFS pool aan te maken op ruwe disks. Gebruik altijd GPT partities en geen ruwe disks!

Hmm doet ZFS on Linux dat dan automatisch goed? Volgens hun eigen wiki/faq wordt aangeraden om /dev/disk/by-id/<id> te gebruiken en dat lijkt me toch aardig "ruw".
Als ik dan later kijk naar de partitie tabel is er wel een gpt partitie aangemaakt.
Dus mijn conclusie is dat ZFS on Linux dat zelf regelt

[Q]

idef1x schreef op donderdag 24 maart 2016 @ 09:00:
[...]

Hmm doet ZFS on Linux dat dan automatisch goed? Volgens hun eigen wiki/faq wordt aangeraden om /dev/disk/by-id/<id> te gebruiken en dat lijkt me toch aardig "ruw".
Als ik dan later kijk naar de partitie tabel is er wel een gpt partitie aangemaakt.
Dus mijn conclusie is dat ZFS on Linux dat zelf regelt

Ik kan dit bevestigen.

[idef1x]

Mooi, dan kan ik weer rustig slapen vannacht

[Verwijderd]

idef1x schreef op donderdag 24 maart 2016 @ 09:00:
[...]

Hmm doet ZFS on Linux dat dan automatisch goed? Volgens hun eigen wiki/faq wordt aangeraden om /dev/disk/by-id/<id> te gebruiken en dat lijkt me toch aardig "ruw".

ZFS-on-Linux is daarin inderdaad een uitzondering. Niet helemaal fijn, want zo wijkt ZFS af van andere platforms en het is niet aan ZFS om te bepalen of er partities moeten worden aangemaakt; misschien wilt de gebruiker wel ruwe disks gebruiken bijvoorbeeld voor compatibiliteit met Solaris die de GPT partities van BSD/Linux niet ondersteunt. Je zegt A, maar je krijgt B.

Dat gezegd, je kunt het dus prima doen zo. Alleen raad ik nog steeds aan dat je zelf je partities aanmaakt. De reden is dat je labels kunt geven aan je partities en zo met zelfgekozen namen kunt werken. Je kunt je disk bijvoorbeeld 'samsung01' noemen ipv een GPT ID wat een door de computer gegenereerd uniek nummer is, maar veel minder makkelijk te onthouden. Het gevaar zou kunnen zijn dat je zelf een fout maakt bij het verwijderen/formatteren van de disk bijvoorbeeld. Dat gevaar heb je veel minder als je gebruik maakt van zelfgekozen label namen, wat dus kan met GPT partities.

Dus wat mij betreft maak je zelf je GPT partities en geef je daarbij een naam aan elke disk/partitie en gebruik je vervolgens de GPT labels om je ZFS pool te maken. Je ziet dan in de zpool status output ook netjes de label namen en niet computer-gegenereerde IDs. Zoals bij mij dus:

code:

  pool: green-mirror
 state: ONLINE
  scan: scrub canceled on Thu Mar 24 16:24:55 2016
config:

    NAME                       STATE     READ WRITE CKSUM
    green-mirror               ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        gpt/green-mirror1.eli  ONLINE       0     0     0
        gpt/green-mirror2.eli  ONLINE       0     0     0

Je kunt overigens wel achteraf de label naam van een GPT partitie aanpassen. Maar je moet dan ook op een speciale manier importeren wil je dat ZFS gebruik maakt van de label namen ipv de GPT IDs. Daarom raad ik aan om zelf je partities te maken en het 'gelijk goed te doen' ipv achteraf te corrigeren met wat omwegen.

[Kortfragje]

Je kan in ZoL ook zelf labels definiëren met vdev labels en dan de pool dmv die labels aanmaken.

http://zfsonlinux.org/faq.html#HowDoISetupVdevIdConf

[Verwijderd]

Dat staat dan dus in een configuratiefile; dat is niet hoe ik het graag zie. Ik wil dat die informatie op de disks zelf wordt opgeslagen. Als ik de ZFS pool importeer op een ander platform, wil ik dat deze hetzelfde herkend wordt en ook door middel van de labels. Zo'n losse configuratiefile met hoe de disks heten vind ik maar 'hackerig'. Ook vind ik het jammer dat door dit soort fratsen ZFS anders werkt afhankelijk van het platform, terwijl de cross-platform compatibiliteit juist als één van de grote voordelen geldt van ZFS, boven Btrfs en ReFS die allemaal gebonden zijn aan één platform (Linux en Microsoft respectievelijk).

[sam_vde]

Q schreef op donderdag 24 maart 2016 @ 08:54:
[...]
Jij maakt je wel degelijk druk over QNAPs en Synology devices en vind die dingen onveilig maar in zie geen onderbouwing eigenlijk dat deze dingen ook echt 'gevaarlijk' zijn.

Mijn tweede reactie: "Wat ik schreef over Synology had niet direkt te maken met bitrot." Laat ons dus on-topic blijven: toon nu eens aan waar ik algemeen stel dat de thuisgebruikers zich moeten zorgen maken over bitrot, wat je beweerde in je vorige reactie.

Die NAS discussie waar ik beweer dat de huidige generatie geen meerwaarde biedt tov een offline disk in de kast is een heel ander verhaal, dat ik gerust wil voeren in een andere topic.

Mensen moeten zelf bepalen wat ze willen investeren in hun data, maar wij zijn vaak de techno nerds en geven andere mensen advies. Laten we zo eerlijk mogelijk zijn met dat advies en mensen niet ongefundeerd bang maken.

Zeggen dat iets niet relevant is als je daar geen enkele inhoudelijke motivatie kan tegenover zetten categoriseer ik niet als "zo eerlijk mogelijk advies geven".

[Q]

sam_vde schreef op donderdag 24 maart 2016 @ 19:32:
Zeggen dat iets niet relevant is als je daar geen enkele inhoudelijke motivatie kan tegenover zetten categoriseer ik niet als "zo eerlijk mogelijk advies geven".

What is stated without evidence, can be dismissed without evidence.

[sam_vde]

Q schreef op donderdag 24 maart 2016 @ 20:28:
What is stated without evidence

Niet, dus. Maar ok, we zijn wel klaar denk ik.


Edit: ter info: Synology brengt btrfs ondersteuning naar DSM 6.0. Ik heb nog niet bekeken hoe de implementatie gedaan is, maar je mag er vanuit gaan dat daarmee de "beter een offline disk" opmerking vervalt.

[ Voor 36% gewijzigd door sam_vde op 24-03-2016 21:09 ]

[Q]

Ik heb geen evidence gezien. Alleen maar what-if? Wat voor bewijs heb je als mensen je om advies vragen?
Zolang je geen bewijs hebt, zijn we inderdaad wel klaar. En let op: het gaat hier om het risico voor een thuis gebruiker.

Het is bemoedigend dat Synology BTRFS gaat ondersteunen, maar op dit moment zou ik BTRFS eerder als een risico voor je data veiligheid zien dan als een benefit. Ik volg de status van BTRFS niet van dag tot dag maar met name RAID5/6 lijkt nog steeds niet 100%.

Officieel is de stabiliteit van BTRFS: 'maybe'.

[ Voor 18% gewijzigd door Q op 25-03-2016 11:22 ]

[FireDrunk]

Ik ben al heel lang lid van de mailing list, en zie gelukkig wel steeds minder issues rondom RAID5/6 langskomen. Waar dat een jaar geleden nog meerdere malen per week een issue was, is het nu eerder eens per zoveel maanden.

Het beginnen ook steeds meer de edge-cases te worden. Iemand met een mixed array van 250GB schijven tot 4TB schijven die bij een rebalance wat vage errors krijgt, maar geen data verliest.

Dat soort fouten zitten ze nu.

Zeker niet productie ready

[Q]

Toch leuk om te horen dat BTRFS echt wel progressie maakt. Maar zoals goede wijn moet rijpen, denk ik dat
pas 2017 wel eens het jaar van BTRFS zou kunnen gaan worden.

[FireDrunk]

Voor NAS/Storage (thuis)gebruikers misschien ja. Voor gewoon dagdagelijks desktop/laptop gebruik zou ik het al prima aanraden hoor.

Draai al een jaar stabiel BTRFS op mijn laptop. Werkt prima, merk er niks van.

[ Voor 3% gewijzigd door FireDrunk op 25-03-2016 15:48 ]

[jacovn]

Q schreef op dinsdag 22 maart 2016 @ 08:49:

Ik denk dat het risico van bitrot helemaal niet zo groot is en dat mensen zich helemaal geen zorgen hoeven te maken over de aanschaf van een Synology. Een zelfbouw systeem met ECC en ZFS kan veiliger zijn voor je data, dat is zeker waar. Maar de kant-en-klare NAS systeempjes krijgen wel een voldoende. ZFS krijgt alleen een hoger cijfer.

Ik krijg een beetje de indruk dat ZFS wordt verspreid op basis van Fear, Uncertainty and Doubt. Een beetje de boel dik aanzetten om het evangelie maar te verspreiden. Zoals ik ooit schreef: ZFS lost problemen en risico's op waarvan we niet eens wisten dat we die hadden.

Maar ik wil niet negatief eindigen over ZFS, het is inderdaad een 'veiliger' file system voor je data en dat de optie er is voor de mensen die graag alle risico's willen wegnemen, dat is natuurlijk geweldig.

Ik denk dat ik bitrot gehad heb met unraid (linux met reiserfs in die versie toen)
Alleen was het met data move naar zfsguru toe. De parity veranderde omdat ik telkens als ik een hdd leeg had gecopieerd die hdd eruit trok en dan opnieuw parity moest berekeken. Dat ging met alle hdds goed, behalve 2 samsung 1.5TB krengen waar files op corrupt waren. Ik kon ze destijds niet repareren omdat de parity niet in orde was op dat moment.

Dus het had wellicht gerepareerd kunnen worden door het OS/filesysteem als de parity informatie had geklopt. Echter hij herberekening van de parity was er wellicht niet kloppende parity gemaakt als die data disks issues hadden.

Aangezien ik dit gezeur niet meer wilde heb ik maar zfs in raid-z2 (10 disks) gedaan op alle systemen behalve de kleinste nas (5 disks)

Oudste systeem is nu 3 jaar en nog geen issues gekregen.

[wayward]

Beste Allemaal,


Al een tijdje ben ik bezig met FreeBSD en heb besloten mijn ervaringen te delen. Ik denk dat dit een prima beginners handleiding is als je wilt beginnen met FreeBSD, encryptie en zfs met compressie.

http://www.bsd05.nl/index.php/start-hier

Ik hoop dat iemand een snelle start door mijn handleiding kan maken.

[Q]

jacovn schreef op vrijdag 25 maart 2016 @ 21:18:
[...]

Ik denk dat ik bitrot gehad heb met unraid (linux met reiserfs in die versie toen)
...
Oudste systeem is nu 3 jaar en nog geen issues gekregen.

Ik sluit zeker niet uit dat je last van silent data corruptie hebt gehad, maar zoals je het uitlegt heb ik wel het idee dat het zich onder speciale omstandigheden voordeed. Het lastige is dat juist met silent corruptie je eigenlijk ZFS moet draaien om het detecteren, anders weet je het nooit echt. Tot nu toe heb ik nog geen enkele checksum error gezien op de systemen die ik nu al weer jaren draai met ZFS. Ik raak mijn systemen bijna niet aan, dat moet ik er wel bij aangeven.

wayward schreef op vrijdag 25 maart 2016 @ 22:00:
Al een tijdje ben ik bezig met FreeBSD en heb besloten mijn ervaringen te delen.

Leuk initiatief, daar heeft wel wat werk in gezeten.

[ Voor 14% gewijzigd door Q op 25-03-2016 23:23 ]

[wayward]

Dankje! Zeker weten! Ik hoop dat de kennis zal floreren, zoals ik gebruik heb kunnen maken van de FreeBSD communitie!

[jacovn]

Q schreef op vrijdag 25 maart 2016 @ 23:21:
Ik sluit zeker niet uit dat je last van silent data corruptie hebt gehad, maar zoals je het uitlegt heb ik wel het idee dat het zich onder speciale omstandigheden voordeed. Het lastige is dat juist met silent corruptie je eigenlijk ZFS moet draaien om het detecteren, anders weet je het nooit echt.

Bij de copy slag vanaf die disk kreeg ik read errors. (Op beide hdds elk een keer)
Resultaat was 2 films minder, maar goed dat was niet een probleem.

Maar de mond op mond reclame van freebsd met zfs heeft me wel doen besluiten het maar goed te doen met raid-z2.

Afkloppen maar..

Overigen op oude post terug komen. Die server die af en toe reset deed, werkt prima met nieuwe versie zfsguru.

[Q]

Read errors zijn geen silent data corruptie. Silent data corruptie is 'stil', je merkt het niet totdat je een file opent en die faalt. Je hebt mogelijk gewoon last gehad van bad blocks. Normale RAID zou dat prima moeten kunnen afhandelen.

[Dutch2007]

Denk dat ik toch m'n raid waar nu 4 van de 6 4K disks zijn wil converten naar de juiste versie qua Shift gebeuren..

Kan ik wel de shares enzo zoals de share nu ingesteld staat exporteren en qua settings (compression enzo) daarna weer importeren? of wordt het daarmee zelf maar weer de boel instellen?

m'n samba share zal 't minste problem zijn... (als de pool maar de zelfde naam krijgt...)

[narotic]

Dutch2007 schreef op dinsdag 29 maart 2016 @ 15:26:
Denk dat ik toch m'n raid waar nu 4 van de 6 4K disks zijn wil converten naar de juiste versie qua Shift gebeuren..

Kan ik wel de shares enzo zoals de share nu ingesteld staat exporteren en qua settings (compression enzo) daarna weer importeren? of wordt het daarmee zelf maar weer de boel instellen?

m'n samba share zal 't minste problem zijn... (als de pool maar de zelfde naam krijgt...)

Ja, voor zover mogelijk blijven alle properties behouden bij een send/receive.

[Mattie112]

Mattie112 schreef op donderdag 17 maart 2016 @ 10:45:
[...]


So far heeft het nog niet geholpen: volgende stap de SATA-kabel vervangen. En mocht dat niet helpen dan wissel ik wel even 2 disks om kijken of het aan de disk of aan de poort ligt.

Nog even een update (mocht iemand het interesseren )

Het lijkt aan de disk te liggen, kabel vervangen, andere poort geprobeerd zelfde probleem. Zal even een wat uitgebreide scan doen op dit disk om hardware fouten uit te sluiten.

[Q]

Als je de errors alleen op die disk krijgt en met andere kabel en andere poort zie je geen verschil dan is het wel helder. Ik vraag me alleen op dit moment af wat er nu werkelijk aan de hand is. Is er echt wat mis met de disk, is het een BSD bug, misschien eens de error codes opzoeken wat het precies betekent. Wat laten de smart waardes van de disk zien?

[ Voor 6% gewijzigd door Q op 01-04-2016 17:02 ]

[F-Tim]

Ik heb even een tijdje een voltmeter aan mijn NAS gehangen om te kijken wat het daadwerkelijke verbruik nou is, en eigenlijk... is het vrij stabiel.

Idle: 47W
Load: 49W

Ik durf alleen niet te zeggen of dit wel goed is ik heb het vermoeden dat het aan de hoge kant is.
Er zitten 6 WD Red's in met een G1840, en volgens mij gaan ze nooit in spindown?

Ik heb iig 2 VDEV's aangemaakt,
een boot array (mirror op disk 1 en disk 2)
een tank array (Z2 over alle 6 de disks)

Als ik naar de disks pagina ga zie ik ze altijd netjes "Ready", ik kan dan wel op Spin-down klikken, maar hij gaat dan vrijwel direct weer opspinnen. Er draait dan geen enkel actief proces. Enkel het Plex proces draait op de achtergrond die elke 2 uur een keer een index uitvoert.

Doe ik iets fout met mijn configuratie van ZFSGuru? Werkt de spindown (nog) niet goed? Of is de 47W in jullie optiek een prima waarde? Ik had namelijk verwacht dat ik in Idle maar 2 disks actief zou hebben (en dit ook in de WebUI zou zien) en dan ongeveer iets van 20W verbruik zou hebben.

[Q]

Ze gaan waarschijnlijk nooit in spindown. Ik weet niet of en hoe dat werkt onder BSD.

47 Watt is niet zo zuinig. Je betaalt per watt 2 euro per jaar voor 24/7 gebruik. Dus je mag zelf bepalen wat je van het verbruik vindt. 10 watt minder = 20 euro per jaar bespaard.

[FireDrunk]

Zonder complete lijst van onderdelen is het lastig zeggen of 47W hoog of laag is.

Voor een Supermicro bord met onboard IPMI en SAS controller is het ok-ish, voor een uberzuinig MSI of ASRock plankje zonder poespas is het wat aan de hoge kant

Heb je onder ZFSguru al gekeken naar de C & P-State instellingen? Volgens mij doen de laatste versies van ZFSguru dit prima, maar de wat oudere versies hadden daar nog geen instellingen voor dacht ik.

[ Voor 18% gewijzigd door FireDrunk op 05-04-2016 10:30 ]

[Verwijderd]

Die heeft ZFSguru automatisch ingeschakeld. Maar het klopt wel ongeveer. 6 disks * 4W = 24W idle. Dan zit hij dus op 47 - 24 = 23 watt voor de rest van het systeem. Dat klopt wel ongeveer bij gebruik van een ATX voeding.

Spindown is mogelijk. Daarvoor edit je /etc/rc.conf en schakel je spindown in voor je disks, mogelijk alleen disks 3-6 zodat je boot disks altijd opgespint blijven. Zoek naar dit stukje:

code:

# To enable your disks to spindown whenever inactive for a number of seconds,
# configure both the timer (in seconds) and the disks you want to be spun down.
zfsguru_tuning_spindown_enable="NO"
zfsguru_tuning_spindown_disks="ada0 ada1 ada2 ada3"
zfsguru_tuning_spindown_timer="7200"

Vrij duidelijk wat je hier moet doen; NO in YES veranderen en de disk nodes aanpassen naar disks 2-6. Bedenk dat er vanaf 0 geteld wordt. Zie de Disks pagina op ZFSguru pagina hoe de disks daadwerkelijk heten.

[RudolfR]

Ik heb net de instellingen voor APM en spindown inschakeld door "NO" in "YES" te veranderen in de onderstaande code in /etc/rc.conf van zfsguru.

code:

## ZFSguru tuning performed after boot
zfsguru_tuning_enable="YES"
# APM or Advanced Power Management controls power saving features of your hard
# drives. To disable the dreaded 'headparking' feature, it is common to enable
# APM to a setting of 254, to disable headparking altogether.
# Caution: enabling APM may cause harddrive spindown to stop functioning!
zfsguru_tuning_apm_enable="YES"
zfsguru_tuning_apm_disks="ada0 ada1 ada2 ada3"
zfsguru_tuning_apm_level="254"
# To enable your disks to spindown whenever inactive for a number of seconds,
# configure both the timer (in seconds) and the disks you want to be spun down.
zfsguru_tuning_spindown_enable="YES"
zfsguru_tuning_spindown_disks="ada0 ada1 ada2 ada3"
zfsguru_tuning_spindown_timer="7200"

Maar na een reboot is APM voor alle disks disabled (128), maar ik had 254 verwacht.
Klopt mijn verwachting niet of mis ik iets?

Ik herinner me dat er ooit output van dit script in dmesg terecht kwam, daar zie ik niets van, maar andere daemons uit het script worden wel correct gestart.

[Verwijderd]

Heb je gecontroleerd dat je disks inderdaad 'ada' heten en niet bijvoorbeeld 'da' ?

Wat zegt 'service zfsguru-tuning start' ?

[ Voor 21% gewijzigd door Verwijderd op 05-04-2016 21:43 ]

[Verwijderd]

In FreeBSD hebben ATA schijven sinds 8.0 de ada driver, daarvoor de ad driver. De da driver is voor SCSI.

[Verwijderd]

Dat klopt, alleen krijgen SATA schijven op een SAS controller ook gewoon een 'da' device node en geen ada. ada is enkel wanneer de AHCI-driver wordt gebruikt. Alle andere drivers geven je een 'da' device node, behalve wat RAID controllers die speciale nodes hebben.

[FireDrunk]

ZFSonLinux 0.6.5.6 is uit:

Supported Kernels
Compatible with 2.6.32 - 4.5 Linux kernels.

Bug Fixes

Remove artificial architecture restrictions in packaging
Add support for s390[x] zfsonlinux/zfs#4425
Handle negative dentries in case insensitive filesystem #4243
Fix casesensitivity=insensitive deadlock #4136
Correctly parse zdb -R flag arguments #4304
Fix lock order inversion with zvol_open() #3681
Add support for asynchronous zvol minor operations #2217
Make zvol minor functionality more robust #4344
Prevent zpool_find_vdev() from truncating vdev path #4312
Add -gLP to zpool subcommands for alt vdev names #4341
Fix zpool list -v output for spares and log devices #4313
Fix ZFS send fails to transmit some holes

https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5.6

[ Voor 7% gewijzigd door FireDrunk op 06-04-2016 14:18 ]

[CurlyMo]

FireDrunk schreef op woensdag 06 april 2016 @ 09:52:
ZFSonLinux 0.6.5.6 is uit:

Supported Kernels
Compatible with 2.6.32 - 4.5 Linux kernels.

Bug Fixes

Remove artificial architecture restrictions in packaging
Add support for s390[x] zfsonlinux/zfs#4425
Handle negative dentries in case insensitive filesystem #4243
Fix casesensitivity=insensitive deadlock #4136
Correctly parse zdb -R flag arguments #4304
Fix lock order inversion with zvol_open() #3681
Add support for asynchronous zvol minor operations #2217
Make zvol minor functionality more robust #4344
Prevent zpool_find_vdev() from truncating vdev path #4312
Add -gLP to zpool subcommands for alt vdev names #4341
Fix zpool list -v output for spares and log devices #4313
Fix ZFS send fails to transmit some holes

https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5.6

CurlyMo schreef op donderdag 10 maart 2016 @ 13:31:
@FireDrunk, nu op naar de device tasting

[FireDrunk]

Hahaha, so much to do, so little time

[Q]

Zie niet zo veel spannends in deze release eigenlijk, meer een minor bug fix release.

[FireDrunk]

Belangrijkste is vooral compatibility met kernel 4.5 (die was er nog niet). Die was er blijkbaar ook al bij 0.6.5.5 maar is nu nog wat verbeterd

Vergeten dikgedrukt te maken

[ Voor 27% gewijzigd door FireDrunk op 06-04-2016 14:23 ]

[F-Tim]

Verwijderd schreef op dinsdag 05 april 2016 @ 11:30:
Die heeft ZFSguru automatisch ingeschakeld. Maar het klopt wel ongeveer. 6 disks * 4W = 24W idle. Dan zit hij dus op 47 - 24 = 23 watt voor de rest van het systeem. Dat klopt wel ongeveer bij gebruik van een ATX voeding.

Spindown is mogelijk. Daarvoor edit je /etc/rc.conf en schakel je spindown in voor je disks, mogelijk alleen disks 3-6 zodat je boot disks altijd opgespint blijven. Zoek naar dit stukje:

code:

# To enable your disks to spindown whenever inactive for a number of seconds,
# configure both the timer (in seconds) and the disks you want to be spun down.
zfsguru_tuning_spindown_enable="NO"
zfsguru_tuning_spindown_disks="ada0 ada1 ada2 ada3"
zfsguru_tuning_spindown_timer="7200"

Vrij duidelijk wat je hier moet doen; NO in YES veranderen en de disk nodes aanpassen naar disks 2-6. Bedenk dat er vanaf 0 geteld wordt. Zie de Disks pagina op ZFSguru pagina hoe de disks daadwerkelijk heten.

Thanks voor de tip heb het doorgevoerd met een timer van 900 (15 mins), eens kijken of het wat uitmaakt op termijn!

Wel vraag ik me nu af, wat is beter... spindown op YES of APM op YES? Immers, in de conf staat duidelijk dat APM ervoor kan zorgen dat Spindown niet meer werkt. Dus voorlopig heb ik alleen Spindown geactiveerd.

FireDrunk schreef op dinsdag 05 april 2016 @ 10:30:
Zonder complete lijst van onderdelen is het lastig zeggen of 47W hoog of laag is.

Voor wat betreft de onderdelen, het is gewoon standaard consumenten meuk zonder IPMI/SAS...

Mobo: Gigabyte GA-H97N-WIFI
CPU: Celeron G1840
Koeler: Noctua NH-L12
RAM: Crucial 1x 8GB DDR3
PSU: BeQuiet Straight Power 10 400W

En daarbij dan 6 WD Red's Niet heel spannend dus allemaal. Ik zal nog eens kijken wat op het mobo allemaal enabled is, wellicht dat k daar ook nog wat mee kan besparen.

[ Voor 18% gewijzigd door F-Tim op 07-04-2016 10:09 . Reden: Onderdelenlijst toegevoegd ]

[FireDrunk]

6 RED's doen ~24W DC. Laten we hopen op 85% efficiëntie, dat betekend dat je uit de muur iets van 27W aan disk power trekt.

Dan blijft er 20W over voor de rest van je componenten. Niet heel slecht, maar ook niet super goed. Met een Linux installatie kom je misschien nog een fractie lager.

Je kan sowieso nog een keer PowerTOP proberen om te kijken of je P-, PC- & C-States goed gaan.

[Verwijderd]

PowerTOP is een Linux applicatie, die niet zomaar werkt onder BSD.

Je kunt echter kijken met 'sysctl dev.cpu.0.freq' wat de huidige frequentie is. ZFSguru heeft die functionaliteit ook ingebouwd op de status pagina, zodat je kunt controleren of throttling werkt.

Gigabyte is doorgaans niet enorm zuinig; dus zo heel vreemd zijn de scores niet. Ook het gebruik van een ATX-voeding betekent dat idle stijgt. Gebruik van een CPU-fan ook weer, sommige doen meer dan 3W op vol vermogen en op laag vermogen nog altijd over de 1W.

Wat je wel kunt doen is een heleboel overbodige meuk uitschakelen in het BIOS. Alle dingen die je niet gebruikt, zoals Audio enzovoorts.

[riwi]

Q schreef op woensdag 06 april 2016 @ 13:37:
Zie niet zo veel spannends in deze release eigenlijk, meer een minor bug fix release.

D'r zat een vette nare bug in 6.5.5. Dat is denk ik de reden om 14 dagen na 6.5.5 al de 6.5.6 te releasen.
Niet dat veel mensen er last van zouden hebben, maar wel data corruptie in de backup als gevolg.

Ik bevat het niet geheel maar toch wat ik ervan begrijp: Als je zvols filesystems met zfs send verstuurd naar een andere pool. Als je daarna zaken op de eerste zijde verwijderd en een sparse file maakt dan krijg je "empty blocks" of zoiets. Als je daarna een incremental zfs send doet dan werden deze nieuwe empty blocks niet verstuurd met als gevolg dat de "backup" niet compleet was of corrupt.

Dus inderdaad een snelle bug fix.

[ Voor 3% gewijzigd door riwi op 07-04-2016 16:33 ]

[Kortfragje]

riwi schreef op donderdag 07 april 2016 @ 16:14:
[...]


D'r zat een vette nare bug in 6.5.5. Dat is denk ik de reden om 14 dagen na 6.5.5 al de 6.5.6 te releasen.
Niet dat veel mensen er last van zouden hebben, maar wel data corruptie in de backup als gevolg.

Ik bevat het niet geheel maar toch wat ik ervan begrijp: Als je zvols hebt en je hebt deze met zfs send verstuurd naar een andere pool. Als je daarna zaken op de eerste zijde verwijderd dan krijg je "empty blocks" of zoiets. Als je daarna een incremental zfs send doet dan werden deze nieuwe empty blocks niet verstuurd met als gevolg dat de "backup" niet compleet was of corrupt.

Dus inderdaad een snelle bug fix.

Volgens mij niet, het zou juist niet om zvols gaan, het zijn juist datasets die hier last van hadden (edit zie deze post Kortfragje in "Het grote ZFS topic").

[ Voor 4% gewijzigd door Kortfragje op 07-04-2016 16:27 ]

[riwi]

Ik heb mijn RocketRaid 2740 (16x sata) vervangen door een RocketRaid 2760 (24x sata) en er 6 disks bij geplaatst. Totaal score is nu 14x4T, 12x3T en 10x2T telkens in een eigen pool met 1 RAIDZ2 vdev.
Heb mooie LianLi rackjes gevonden voor 20 euro waar 4 disken in kunnen.




Ik heb nu nog 2 vrije bays en 2 vrije sata aansluitingen. Dus op termijn kan de 10x2T vervangen worden door 12x een grotere schijf. Maar ik heb nu nog geen behoefte aan meer ruimte.

Ik vind dat de hoeveelheid verlies aan ruimte bij 10 disk raidz2 aan de hoge kant is. Vandaar de move naar 12 disk raidz2 en 14 disk raidz2.

[ Voor 27% gewijzigd door riwi op 07-04-2016 16:40 ]

[riwi]

Kortfragje schreef op donderdag 07 april 2016 @ 16:24:
[...]


Volgens mij niet, het zou juist niet om zvols gaan, het zijn juist datasets die hier last van hadden (edit zie deze post Kortfragje in "Het grote ZFS topic").

Inderdaad. Ik gebruik meestal niet de incremental zfs send maar doe gelijk een complete send. Dus ik had er geen last van.

[Kortfragje]

riwi schreef op donderdag 07 april 2016 @ 16:28:
Ik heb mijn RocketRaid 2740 (16x sata) vervangen door een RocketRaid 2760 (24x sata) en er 6 disks bij geplaatst. Totaal score is nu 14x4T, 12x3T en 10x2T telkens in een eigen pool met 1 RAIDZ2 vdev.
Heb mooie LianLi rackjes gevonden voor 20 euro waar 4 disken in kunnen.

[afbeelding]
[afbeelding]

Ik heb nu nog 2 vrije bays en 2 vrije sata aansluitingen. Dus op termijn kan de 10x2T vervangen worden door 12x een grotere schijf. Maar ik heb nu nog geen behoefte aan meer ruimte.

Ik vind dat de hoeveelheid verlies aan ruimte bij 10 disk raidz2 aan de hoge kant is. Vandaar de move naar 12 disk raidz2 en 14 disk raidz2.

Nice, sta je al in het show off topic? Storage showoff topic - 20+ TB storage systems

[Compizfox]

riwi schreef op donderdag 07 april 2016 @ 16:28:
Ik vind dat de hoeveelheid verlies aan ruimte bij 10 disk raidz2 aan de hoge kant is. Vandaar de move naar 12 disk raidz2 en 14 disk raidz2.

Veel ruimteverlies bij 10-disk RAID-Z2? Het ligt er natuurlijk een beetje aan hoe kostbaar je data is, maar voor RAID-Z2 is rond de 6 disks veel gebruikelijker (dan heb je 1/3 parity). Met 12 of 14 disks zit je dus vrij laag qua parity (1/6 en 1/7 respectievelijk).

[riwi]

Kortfragje schreef op donderdag 07 april 2016 @ 22:37:
Nice, sta je al in het show off topic? Storage showoff topic - 20+ TB storage systems

Daar sta ik nog niet in, maar vind ik ook niet zo nodig. Topic is ook al wat ouder volgens mij. Tegenwoordig met de 8T disks kom je zo aan de 20TB grens.

Compizfox schreef op vrijdag 08 april 2016 @ 00:45:
Veel ruimteverlies bij 10-disk RAID-Z2? Het ligt er natuurlijk een beetje aan hoe kostbaar je data is, maar voor RAID-Z2 is rond de 6 disks veel gebruikelijker (dan heb je 1/3 parity). Met 12 of 14 disks zit je dus vrij laag qua parity (1/6 en 1/7 respectievelijk).

Het zal altijd een afweging zijn tussen veiligheid en meer netto ruimte. Ik heb wel een goed gevoel bij 12 en 14 disk raidz2. Ik had ook kunnen kiezen voor raidz3 omdat ik de pools opnieuw heb aangemaakt. Maar daar heb ik dus niet voor gekozen.

Wat ik wel interessant vond is dat kwa performance met zfs send -ev pool3/films@20160404 | zfs receive -v pool4/films ik toch rond de 490-500MB/sec haalde over filesystems van 2 tot 8 TB per stuk. Dan zie je in top wel dat de CPU ook behoorlijk belast wordt (180% met een dual core i3 T model). Geheugen gebruik (24GB aanwezig) valt mee. Er blijft altijd minimaal 10GB Free.

Ik moest ook wat data naar een andere NAS PC verhuizen tijdelijk. Daar zit dual gigabit tussen met round robin bonding en een Cisco slm2008 switch. Daar komt het tot 137MB/sec. Net wat meer dan 1Gbit link dus, maar de 2Gbit haal ik niet.

[ Voor 23% gewijzigd door riwi op 09-04-2016 19:23 ]

[Compizfox]

riwi schreef op zaterdag 09 april 2016 @ 19:12:
[...]

Het zal altijd een afweging zijn tussen veiligheid en meer netto ruimte. Ik heb wel een goed gevoel bij 12 en 14 disk raidz2. Ik had ook kunnen kiezen voor raidz3 omdat ik de pools opnieuw heb aangemaakt. Maar daar heb ik dus niet voor gekozen.

Wat ik wel interessant vond is dat kwa performance met zfs send -ev pool3/films@20160404 | zfs receive -v pool4/films ik toch rond de 490-500MB/sec haalde over filesystems van 2 tot 8 TB per stuk. Dan zie je in top wel dat de CPU ook behoorlijk belast wordt (180% met een dual core i3 T model). Geheugen gebruik (24GB aanwezig) valt mee. Er blijft altijd minimaal 10GB Free.

Ik moest ook wat data naar een andere NAS PC verhuizen tijdelijk. Daar zit dual gigabit tussen met round robin bonding en een Cisco slm2008 switch. Daar komt het tot 137MB/sec. Net wat meer dan 1Gbit link dus, maar de 2Gbit haal ik niet.

Klopt, daarom zei ik ook "het is maar net hoe kostbaar je data is"

Eigenlijk kun je het zelfs doortrekken naar een afweging tussen drie dingen: betrouwbaarheid, netto ruimte en snelheid. Daar komt dan ook een extra factor bij kijken: de grootte van je disks. De grootte van je disks bepaalt de verhouding tussen snelheid en schijfruimte (bij gelijke parity). Voorbeeldje: 6x 1,5TB in RAID-Z2 levert net zoveel netto ruimte en parity op als 3x 3TB in RAID-Z1 (in beide gevallen heb je 6 TB netto en 1/3 parity), maar de eerste setup is sneller omdat je meer disks hebt. Ook is het niet moeilijk te zien dat 3x 1TB in RAID-Z1 en 3x 3TB in RAID-Z1 dezelfde snelheid en parity opleveren, maar een verschillende netto ruimte.

Ik heb zelf maar weinig opslagruimte nodig, maar liefst wel lekker snel, dus ik gebruik kleine schijven (1 TB). Mijn data is me kostbaarder dan die van jou, dus ik ga voor 1/3 parity (in plaats van 1/6)

Nette snelheden trouwens

[idef1x]

FireDrunk schreef op donderdag 07 april 2016 @ 11:26:
Dan blijft er 20W over voor de rest van je componenten. Niet heel slecht, maar ook niet super goed. Met een Linux installatie kom je misschien nog een fractie lager.

Je kan sowieso nog een keer PowerTOP proberen om te kijken of je P-, PC- & C-States goed gaan.

Ik heb toevallig hetzelfde mobo en cpu, maar dan 6 WD Greens van 3TB en stock koeler en kom op ongeveer dezelfde waarden uit (zfs 0.6.5 en kernel 4.1.15).

Heb wel even powertop gedraait en daar staan bij mij wel wat tunables op bad vwbt de disken...Misschien daar maar even aan knutselen...

[Q]

Hee dit is interessant:

Op mijn download server:

ZFS on Linux module crash:
essage from syslogd@server at Apr 10 12:16:02 ...
kernel:[1879354.343257] VERIFY3((arc_stats.arcstat_c.value.ui64) >= 2ULL << 24) failed (33221377 >= 33554432)

Pool reageert niet meer. Een `LS` geeft bovenstaande error.

Na een reboot kom ik weer bij de data.

Het issue deed zich voor toen ik flink wat load op de pool aan het zetten was.

Misschien deze

https://github.com/zfsonlinux/zfs/issues/3904

[ Voor 10% gewijzigd door Q op 10-04-2016 12:28 ]

[terror538]

Van de zomer zodra de belastingteruggave binnenkomt weer is een flinke upgrade uitvoeren aan mijn pool. De meest kost efficiënte upgrade is naar SMR schijven, alleen performen die (nog) niet geweldig in raid situaties.

De 8TB schijven van seagate (archive ST8000AS0002 ) zijn helaas niet host-aware, 13 april (als ik deze franse webshop mag geloven: http://www.materiel.net/d...+3.5+HDD+-+8+To#FicheDesc) komen de nieuwe ST8000AS0022 uit die wel host aware zijn (volgens de product handleiding van seagate).
En binnen FreeBSD is de ontwikkeling ook al op gang gekomen, er zijn al een aantal patches uit voor camcontrol (https://lists.freebsd.org...2015-November/058522.html) diezelfde dev geeft ook aan al te werken aan patches voor ZFS.

Nou vraag ik mij af of het zinnig is over te stappen naar SMR schijven als nog niet alle patches uit zijn; kan je later upgraden naar een ZFS versie die wel SMR begrijpt en daar de voordelen van hebben of veranderd het zoveel on-disk dat het vele malen beter is om direct met een SMR compatible versie te werken? (wat in mijn geval dus betekent dat ik nog een jaar wacht met upgraden naar SMR).

[Q]

Persoonlijk ben ik redelijk behoudend wat storage betreft. Ik zou voor de oude vertrouwde technologie gaan in dit geval, dus mogelijk 4 of 6 TB schijven. Liever 1 zwaluw in de hand dan 10 in de lucht: je weet niet hoe lang het duurt voordat SMR support 100% ok is en je wilt niet degene zijn die moet concluderen dat dit nog niet het geval is.

[FireDrunk]

SMR schijven betekend niet meteen dat ZFS niet werkt, maar je moet wel ernstig rekening houden met de nadelen van SMR. Als je de patches *nodig* acht, moet je het niet doen. Als je het ziet als leuke extra, kan je er over nadenken, maar lees je goed in over SMR voor je er aan begint.

[idef1x]

Iemand wel eens met BTRFS op een ZVOL (zfsonlinux) aan de slag geweest en zo ja wat de ervaringen daar mee waren/zijn?

Brian Behlendorf vind het zelf al wellicht gek en maakte er dan maar een soort "voor de fun" probeerseltje van in zijn bug report (https://github.com/zfsonlinux/zfs/issues/469), maar ik zit er serieus naar te kijken om BTRFS op een ZVOL te zetten. Het lijkt inmiddels wel te werken, dus wellicht heeft hier iemand nog iets zinnigs over te zeggen, want uit het bugreport komt geen antwoord of het daadwerkelijk gek is om te doen.

Wat ik in gedachte heb is dus een BTRFS op een ZVOL op mijn nas, zodat ik die kan gebruiken om mijn Linux laptop/desktop, welke op btrfs draait te backuppen met btrfs send/receive (a la zfs send/receive).
Leek me een stuk handiger dan de btrfs snapshots naar een file op de ZFS nas te zetten.
ZFS maakt dan zijn eigen snapshots en stuurt die weer met zfs send/receive naar mijn backup ZFS server.

Het voelt inderdaad wel gek aan (cow on cow), maar is dat het ook?

[FireDrunk]

Mijn VM's draaien op BTRFS? Telt dat ook?
BTRFS in VM -> iSCSI -> ZVOL

Niet wat jij hebt, maar het werkt prima.

[idef1x]

Euh nee dat telt niet, want dan wordt het het btrfs volume (via iscsi) door je VM gemount en niet door de ZFS server zelf

Het gaat mij erom dat je dan dus 2 cow filesystemen op 1 en dezelfde machine draait, waarbij de ene cow (btrfs) dus gebruikt maakt van de andere cow (zfs)...ZFS vind geheugen wel fijn, maar btrfs wil ook wel wat..

Nou ja misschien maar gewoon gaan proberen/gebruiken en hopen dat ie goed blijft werken tot een volgende regenachtig zondagmiddag

[terror538]

FireDrunk schreef op maandag 11 april 2016 @ 07:03:
SMR schijven betekend niet meteen dat ZFS niet werkt, maar je moet wel ernstig rekening houden met de nadelen van SMR. Als je de patches *nodig* acht, moet je het niet doen. Als je het ziet als leuke extra, kan je er over nadenken, maar lees je goed in over SMR voor je er aan begint.

Met mijn huidige workload is het inderdaad geen heel groot probleem, de grootste problemen zitten in random writes (iets wat je dus wel merkt als je een schijf rebuild)
Wat ik vooral kan zien is dat er situaties kunnen ontstaan waardoor mijn workload net zo veranderd dat random writes wel belangrijker worden, als ik eerst een ongepatchte ZFS kan gebruiken en dan later kan ugpraden naar gepatchte dan geeft dat weinig problemen verwacht ik.

[FireDrunk]

Ik verwacht niet dat het on-disk formaat van ZFS zou wijzigen bij een SMR patch, ik verwacht eerder dat ze meer "stream-like" gaan schrijven bij rebuilds. En een beetje met timeouts gaan spelen misschien.

Ik heb er ooit eens een berichtje op de zfs-mailing list geplaatst of ze bij SMR schijven de SLOG / ZIL konden gebruiken om er voor te zorgen dat SMR schrijven sequentieel blijven schrijven. Dat gebeurd nu namelijk niet, rebuilds zijn synchroon en relatief random.

Hier dus: https://www.listbox.com/m...t/from/page/1/entry/3:76/

[ Voor 14% gewijzigd door FireDrunk op 11-04-2016 10:51 ]

[HyperBart]

Iemand nog wat interessante benches of tests die ik kan laten lopen op een 20 x 4TB HGST array van een goede vriend?

Ik was sowieso van plan om het script van Q nog eens te laten runnen, eventueel met wat afwijkende parameters.

Ik heb nog 3 x een M4 en een onbekend SSD'tje liggen wat uit een HP 6550b komt om eventueel aanvullende tests te doen.

Ik heb ook nog 6 x 3TB HGST liggen, maar daar staat de data op die uiteindelijk naar de 4TB-array moet gaan, dus het script van Q icm 4TB en 3TB disks valt dan al af aangezien dat een wipe doet.

Daarnaast ligt ook nog een setje Chelsio 10Gbit kaartjes met SFP+, die kan ik eventueel opkoppelen naar mijn NAS om wat data tijdelijk weg te zetten.

Hardware is:

Intel E3-1270 V5 + Scythe Mugen 4
X11SSM-F
4 x M391A2K43BB1-CPB
3 x M1015
Inter-Tech IPC 4U-4424

[FireDrunk]

BTRFS?

[HyperBart]

FireDrunk schreef op maandag 11 april 2016 @ 14:08:
BTRFS?

Schrijf maar een testplan uit

[idef1x]

btrfs is wel een ander topic, maar ben wel benieuwd naar ervaringen van anderen mbt snapshots over te sturen. Net na een 1e test mijnerzijds krijg ik de indruk dat zfs (zo weer ontopic ) dat efficiënter doet. Bij btrfs kreeg ik mijn 1Gb link niet vol, maar bij zfs nagenoeg wel.

[RudolfR]

Sinds kort weer last van AHCI timeouts bij een disk van m'n pool onder ZFSGuru,
Heb destijds ook al 'ns om advies gevraagd:
RudolfR in "Het grote ZFS topic" &
http://gathering.tweakers..._keywords]=AHCI%20Timeout

SMART toont aan dat er niets aan mankeert (afgezien van een wat hoge load cycle count).
RudolfR in "Check je SMART"

Onder (write)load faalde die disk, waardoor m'n pool degraded werd. Na een reboot kwam-ie wel weer bij
en kon ik er ook prima van lezen, maar bij schrijven viel-ie vrij snel om.

APM instellingen inmiddels (nu hopelijk persistent) aangepast via CrystalDiskInfo.
Ben nu (tijdelijk?) uitgeweken naar Ubuntu + ZFSoL en dat werkt prima.

Wel 'mis' ik de web-interface van ZFSguru, is er iets vergelijkbaars voor Ubuntu? Of Fedora o.i.d.?
Nog andere dingen die ik op een verantwoorde manier kan proberen met ZFSguru?

[BCC]

idef1x schreef op maandag 11 april 2016 @ 08:59:
Iemand wel eens met BTRFS op een ZVOL (zfsonlinux) aan de slag geweest en zo ja wat de ervaringen daar mee waren/zijn?
Het voelt inderdaad wel gek aan (cow on cow), maar is dat het ook?

Transip bigstorage is ZFS wat ze exposen als een blockdevice, dus daar draai ik ook vrolijk weer ZFS On Linux op. Werkt als een trein (ook qua throughput). maar transip er ook best wel wat storagehardware achter hebben staan . Zeker als het enkel voor snapshot syncing is zie ik geen reden waarom het niet zo werken / stuk zou gaan.

[CurlyMo]

Iemand als eens gemaild met TransIp om te vragen of we hun Stack niet als offsite ZFS backup kunnen gebruiken?

[InflatableMouse]

Geinig, ik zal al een tijdje te dubben om m'n root partitie ZFS te maken maar het leek omslachtig met Arch, ik las ook behoorlijk veel problemen op Arch forum met root op zfs.

Vandaag een en ander geprobeert in een VM en het bleek bijzonder eenvoudig, m'n eigen systeem draait nu ook met root op ZFS.

Met Arch kan je met de tool archiso een nieuwe live media bouwen met customizations. Ik heb (gewoon uit de arch wiki) de instructies gevolgd om zfs-git in te bakken, iso'tje gemaakt en kon zo in een vm'tje testen.

Ik heb daarna op een secundaire disk in m'n systeem getest, zfs root partitie aangemaakt (wederom archwiki), boot partitie aangemaakt en gemount, rsync -av van m'n huidige ext4 root naar de zfs root, chroot naar de zfs root en bootctl install, configje aangepast, UUID van de boot partitie in fstab gezet en reboot!

Uiteraard ging dat niet goed, want: vergeten HOOKS regel aan te passen en mkinitcpio -p linux te draaien . Nadat ik dat gedaan had werkte het.

Nu dat ik een werkende backup heb op een secundaire disk en de procedure werkend, heb ik mn ext4 root partitie omgezet naar zfs en hetzelfde gedaan als hierboven, maar dan voor m'n echte root op m'n primaire disk.

Werkt fantastisch! Nu nog een paar mooie systemd unit filetjes maken voor geautomatiseerde snapshots en backups middels zfs send | zfs receive naar m'n data pool. Daar was het me allemaal om te doen namelijk.

[FireDrunk]

@InflatableMouse,

https://antergos.com/

ArchLinux based, heeft een installer die ZFS-on-Root voor je installeert

(nog maar 1 keer in een VirtualBox VM geprobeerd, en daar gaf de GUI problemen, maar systeem bootte wel, geen aandacht verder aan gespendeerd)

[InflatableMouse]

FireDrunk schreef op dinsdag 12 april 2016 @ 07:44:
@InflatableMouse,

https://antergos.com/

ArchLinux based, heeft een installer die ZFS-on-Root voor je installeert

Thanks but no thanks.

Ik doe het liever zelf, leren hoe het zit en werkt en als er dan iets mis gaat, snap ik tenminste hoe en wat, en heb je veel minder moeite met uitzoeken en oplossen. Dat is van begin af aan de hoofdreden voor mij geweest om op Arch over te stappen.

[FireDrunk]

Ook zeker leuk hoor! Daarom heb ik regelmatig Gentoo gebruikt, dan leer je hoe de meuk onderwater werkt, altijd goed voor het leren debuggen!

[InflatableMouse]

Gentoo is ook zeker leuk! Ik ben laatst met LFS begonnen maar ik ben afgehaakt. Niet omdat het niet lukte maar omdat er zoveel tijd in gaat zitten, dat heb ik gewoonweg niet meer.

[Bigs]

Hebben jullie deze ZFS bak van QNAP al ooit gezien? ES1640dc Enterprise ZFS NAS

Ze doen wel een aantal dingen die we in open source nog niet zo makkelijk doen, zoals dual active controllers en NVRAM schrijfcache (wat naar het lijkt geen ZIL is maar een losse cache voor de schijven zodat ook async writes gecached worden).

Jammer dat FreeBSD en ZFS geen GPL zijn, dan hadden we er misschien nog van de ontwikkelingen van QNAP kunnen profiteren.

[FireDrunk]

Als ze losse caching introduceren buiten ZFS om, mag het ding wat mij betreft direct in de prullenbak... Waarom de open source geteste code van ZFS by-passen met iets proprietaries?

Op zich een leuk ding als alle QNAP software er ook op zit, maar ik vrees dat dit niet een standaard QNAP is.

[Bigs]

ZFS heeft geen write cache. Dit is geen bypass maar gewoon een extra cache tussen ZFS en de schijven, zoals sommige mensen ook doen met Areca RAID kaarten in JBOD mode.

Hij draait inderdaad geen QTS, dus het is in die zin geen standaard QNAP.

[matty___]

Bigs schreef op dinsdag 12 april 2016 @ 09:12:

Jammer dat FreeBSD en ZFS geen GPL zijn, dan hadden we er misschien nog van de ontwikkelingen van QNAP kunnen profiteren.

Wat doet je denken dat patchen niet ook upstream gaan? Het is voor QNAP goedkoper patchen daar te laten dan elke keer anders om te patchen.

[matty___]

Bigs schreef op dinsdag 12 april 2016 @ 11:19:
ZFS heeft geen write cache.

SLOG/ZIL wordt hier wellicht bedoeld.

[FireDrunk]

Bigs schreef op dinsdag 12 april 2016 @ 11:19:
ZFS heeft geen write cache.

Ik doelde inderdaad op SLOG/ZIL.

Dit is geen bypass maar gewoon een extra cache tussen ZFS en de schijven,

Dat is juist het probleem, dat doet inbreuk aan de integriteit van ZFS.

zoals sommige mensen ook doen met Areca RAID kaarten in JBOD mode.

En dat ook. Areca is juist een nogal brakke implementatie van JBOD (vraag maar aan CiPHER). Areca kaarten gooien disks gewoon offline als ze bad sectors bevatten.

Hij draait inderdaad geen QTS, dus het is in die zin geen standaard QNAP.

Dat is wel jammer, dat zou nou juist net een leuke extra zijn

[InflatableMouse]

Ik dacht ik heel goed wist hoe snapshots van ZFS (en snapshotting in het algmeen) werkte. Echter, nu ik m'n root op ZFS heb, snapshots maak en deze met zfs send > /mnt/backups/zroot-datum/... backups maak zie ik iets dat ik neit had verwacht.

Stel, ik heb 20GB gebruikt in mijn root volume. Ik maak een snapshot genaamd 11-04-2016. 100MB wordt gewijzigd. Op 12-04-2016 en ik maak een snapshot. Er wordt weer 100MB gewijzigd, op 13-04-2016 maak ik weer een snapshot met de datum als naam. Ik zie de 20GB en 100MB per snapshot ook terug in respectievelijk 'zfs list' en 'zfs list -t snapshot'.

Mijn eerste backup met zfs send zou 20GB moeten zijn, maar de tweede en de derde elk maar 100MB. Uiteraard gebruik ik de snapshot namen (zroot@13-04-2016) met zfs send.

Al mijn dumps zijn 20GB. Dat klopt toch niet?

[FireDrunk]

Dus je hebt: A1, A2 en A3 als punten.
Die worden B1, B2 en B3 op je ontvangende systeem.

Je begint met A1 full te senden naar B1. (100GB)
Je draait een zfs send van een diff van A1 -> A2 op B1, en krijgt B2 als resultaat. (20GB)

Daarna wijzig je iets (100MB) in A2 en snapshot naar A3.
Daarna send je vanaf A3 naar B2, zodat je B3 krijgt, en dat is weer 20GB? of begrijp ik je nu niet?

[InflatableMouse]

zfs list:

code:

zroot                     22,5G  35,1G  20,6G  /

zfs list -t snapshot:

code:

zroot@firstboot-11042016                25,2M      -  19,8G  -
zroot@12042016_2014                     13,2M      -  19,8G  -
zroot@13042016_1902                      437M      -  20,5G  -

code:

zfs send zroot@firstboot-11042016 > /mnt/data/backups/[e-mail]
zfs send zroot@12042016_2014 > /mnt/data/backups/zroot@12042016_2014.zfsraw
zfs send zroot@13042016_1902 > /mnt/data/backups/zroot@13042016_1902.zfsraw

ls -al:

code:

-rw-r--r--  1 root    root    21658239048 12 apr 20:22 zroot_firstboot-11042016.zfsraw
-rw-r--r--  1 root    root    21659594736 12 apr 20:25 zroot_12042016_2014.zfsraw

Zoals je ziet is de 12042016 bijna even groot als de firstboot. De firstboot is de eerste die ik gemaakt heb, de 1204 is een dag later, waar volgens zfs list -t snapshot 13,2M in gewijzigd is. Ik had dus verwacht dat die dump 13MB zou zijn. Idem met de volgende snapshot, 437M. Maar die is ook 21GB.

[CurlyMo]

Je stuurt ook geen incremental stream, maar elke keer de volledige dataset.

[InflatableMouse]

Ik stuur toch de snapshot? De eerste is de hele dataset (1), daarna verandert er een paar MB, dan maak ik een nieuwe snap (2), er verandert weer wat, snap (3). Als ik dan snap 2 send, dan moet tie toch maar een paar MB doen?

Als ik dat verkeerd doe, hoe moet het dan wel? Want dan gebruik ik zfs send dus verkeerd?

[CurlyMo]

Nee, want je stuurt de volledige dataset op het moment van een bepaalde snapshot. Dat is iets anders. Hoe het wel moet is uitgebreid te vinden op internet en heet gewoon "incremental" send/receive met zfs.

[InflatableMouse]

-i dus ... snap niet hoe ik dat heb kunnen missen want ik heb die pagina (Oracle ZFS) meerdere keren gelezen.

Mooi, weten we dat ook weer .

[soulcrusher]

Dit betekent dus meteen dat als je enkel de data zonder voorgaande snapshots wil senden dat het dan voldoende is om alleen de laatste snapshot te senden? (zonder -i dus)

[CurlyMo]

Klopt.

[wmn79]

CurlyMo schreef op maandag 11 april 2016 @ 21:39:
Iemand als eens gemaild met TransIp om te vragen of we hun Stack niet als offsite ZFS backup kunnen gebruiken?

Nog niet volgens mij, probeer het nu voor elkaar te krijgen via cadaver of duplicity maar daar kom ik nog niet helemaal uit. Zou mooi zijn als we het gewoon als ZFS backup locatie kunnen gebruiken inderdaad.

[kaaas]

Ik heb een vraag over de bruikbare ruimte in zfs als iemand weet hoe het precies zit ik ben erg benieuwd.

Met een 6x4TB raidz heb ik een beschikbare schijf ruimte van 17TiB
MAaar volgens mijn berekeningen zou ik 17,6 Tib moeten hebben.
24TB - 4 = 20 TB =18.18989404 TiB
haal daar de 3.125% spa_slop_shift reservering van af en ik kom op 17.6TiB uit.
Maar ik heb 17TiB beschikbaar waar is mijn .6 TiB

En hoe kun je deze beschikbare ruimte vergelijken met bijv een md raid5 hiermee kom je met de zelfde disks uit op 19TiB wat nogal een verschil is waar komt dit vandaan. En hoe kan het dat als je bij raid 5 1 disk voor paritie gebruikt je op 19Tib uit komt dat zou 18.2 moeten zijn.

[BCC]

CurlyMo schreef op maandag 11 april 2016 @ 21:39:
Iemand als eens gemaild met TransIp om te vragen of we hun Stack niet als offsite ZFS backup kunnen gebruiken?

Ja en het antwoord was: dat kan via een vps. Dus zo doe ik het nu ook

[CurlyMo]

BCC schreef op vrijdag 15 april 2016 @ 13:52:
[...]

Ja en het antwoord was: dat kan via een vps. Dus zo doe ik het nu ook

Dat antwoord ken ik, alleen moet je dan dus een extra VPS afnemen terwijl Stack gewoon gratis is voor 1TB.

[BCC]

CurlyMo schreef op vrijdag 15 april 2016 @ 13:56:
[...]

Dat antwoord ken ik, alleen moet je dan dus een extra VPS afnemen terwijl Stack gewoon gratis is voor 1TB.

Ja maar stack is een vps die een shared owncloud draait. Je zult ergens het filesystem moeten mounten en transip is niet duur

[CurlyMo]

BCC schreef op vrijdag 15 april 2016 @ 14:01:
[...]

Ja maar stack is een vps die een shared owncloud draait. Je zult ergens het filesystem moeten mounten en transip is niet duur

Je zegt dus dat wanneer je een VPS afneemt, je vervolgens de gratis stack kan gebruiken via een FS mount?

[Compizfox]

wmn79 schreef op donderdag 14 april 2016 @ 11:05:
[...]

Nog niet volgens mij, probeer het nu voor elkaar te krijgen via cadaver of duplicity maar daar kom ik nog niet helemaal uit. Zou mooi zijn als we het gewoon als ZFS backup locatie kunnen gebruiken inderdaad.

Ik gebruik het met duplicity als off-site backup

Als je hulp nodig hebt met duplicity kan ik je misschien wel helpen.

Echter, denk niet dat er ook support komt voor ZFS send/receive. Stack is onderhuids wel ZFS-backed, maar dat betekent niet dat je als gebruiker ook direct bij die laag kunt. Voor gebruikers is het gewoon WebDav...

[BCC]

CurlyMo schreef op vrijdag 15 april 2016 @ 14:04:
[...]

Je zegt dus dat wanneer je een VPS afneemt, je vervolgens de gratis stack kan gebruiken via een FS mount?

Nee 😀 Ik vind een VPS met 2TB ZFS voor 20 euro per maand niet duur. Mijn server thuis staat nu standaard uit en is nu de offsite backup

[Verwijderd]

Die licentie van ZFS. Wie begrijpt waarom Oracle liever geld stak in de ontwikkeling van BTRFS (Chris Mason's salaris e.d.) dan de licentie van ZFS aan te passen ?

[base_]

BCC schreef op vrijdag 15 april 2016 @ 15:04:
[...]

Nee 😀 Ik vind een VPS met 2TB ZFS voor 20 euro per maand niet duur. Mijn server thuis staat nu standaard uit en is nu de offsite backup

Hoe mount je die ZFS in een TransIP VPS? Ik zie bij TransIP wel een heel verhaal over linux davfs2, geen idee wat de FreeBSD support is. Daarnaast: ik neem aan dat data tussen de stack en VPS gewoon als internet verkeer meegeteld wordt? incremental (file of blockbased) backup lijkt me dan ook noodzakelijk.

[revox862]

Waar BCC over praat is geen Stack maar een "direct attached" disk (https://www.transip.nl/vps/big-storage/). Waar je vervolgens een filesysteem op kan zetten.

[ Voor 18% gewijzigd door revox862 op 15-04-2016 16:24 ]