Het grote ZFS topic

[Verwijderd]

Block Pointer Rewrite! Hij gaat komen! Eindelijk!

[CurlyMo]

Verwijderd schreef op zondag 18 oktober 2015 @ 19:26:
Block Pointer Rewrite! Hij gaat komen! Eindelijk!

Bron?

[Verwijderd]

Dat was sarcastisch bedoeld.

Persistent L2ARC lijkt me nog wel gaaf. Dan durf ik mijn server ook eens te herstarten/upgraden.

[ Voor 61% gewijzigd door Verwijderd op 18-10-2015 20:59 ]

[maomanna]

ik dacht dat de slechte smb performance aan mijn ZFS pool lag, omdat de bestanden zo tiegelijk langzaam worden geladen (mappen niet), maar na het installeren van win10 op mn nuc en het toevoegen van mn netwerkshare, vliegen de documenten wel snel van a naar b.
Probleempje van de client. Tijd voor een herinstallatie van mn mainpc

[FREAKJAM]

Iemand die me nog een goede distro kan aanraden voor ZoL? Ik draai al tijden naar tevredenheid CentOS 7, maar de laatste weken heb ik last van de volgende meldingen in mijn logs:

Oct 18 19:46:40 florijn kernel: end_request: I/O error, dev sde, sector 4546130752
Oct 18 21:46:55 florijn kernel: end_request: I/O error, dev sdc, sector 5013303096
Oct 18 21:46:55 florijn kernel: end_request: I/O error, dev sdd, sector 5013303096
Oct 18 21:46:55 florijn kernel: end_request: I/O error, dev sdf, sector 5013303096
Oct 18 21:46:55 florijn kernel: end_request: I/O error, dev sdg, sector 5013303096
Oct 18 21:47:08 florijn kernel: end_request: I/O error, dev sdb, sector 2373270264
Oct 18 21:47:08 florijn kernel: end_request: I/O error, dev sde, sector 5013303136

Dit gebeurt onder zowel de P19 en P20 firmware van mijn LSI 2308 (X10SL7 mobo). Ik draai ESXi 6 update 1. Het lijkt een RHEL dingetje te zijn, maar helaas kan ik niet zien wat wellicht de oplossing is voor mijn probleem.

Ik heb de afgelopen 2 weken mijn pool onder FreeNAS gedraaid maar toen was Plex enorm onstabiel (ik draai de Plex data op ZFS en wanneer ik iets keek op Plex viel mijn Plex Media server steeds weg en kwam ie 10 minuten later weer automatisch terug). Nu ik de boel weer terug heb gezet op CentOS 7 draait Plex weer stabiel, maar krijg ik bovenstaande errors. Wanneer ik de boel op FreeNAS draai heb ik weer geen i/O errors, dus beetje vervelend is het wel.

Ubuntu (vorig jaar problemen mee gehad) en alle RHEL based distro's vallen dus eigenlijk af. Debian is ook wel een optie, maar dat heb ik al eens geprobeerd, en ik ben nu eenmaal iemand die graag dingen leert en uitprobeert (ik draai nu bijv Arch Linux op mijn desktop).

[Verwijderd]

Heb je de SMART al gecontroleerd?

[FREAKJAM]

Verwijderd schreef op zondag 18 oktober 2015 @ 22:36:
Heb je de SMART al gecontroleerd?

Ik doe standaard om de zoveel tijd via crond (korte) smart tests op mijn hard-drives en die zijn allemaal in orde. (ik krijg een mail wanneer dat niet zo is).

/dev/sdb -a -n standby -d sat -o on -S on -s (S/../.././03) -m [e-mail]

Scrub is ook telkens okay. Schijven zijn 2 jaar oud, dus volgende mij zijn onderstaande waardes wel in orde.

code:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   187   177   021    Pre-fail  Always       -       5608
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       3739
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   082   082   000    Old_age   Always       -       13417
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       30
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       26
193 Load_Cycle_Count        0x0032   199   199   000    Old_age   Always       -       3712
194 Temperature_Celsius     0x0022   115   104   000    Old_age   Always       -       35
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

[ Voor 79% gewijzigd door FREAKJAM op 18-10-2015 22:48 ]

[FireDrunk]

Ik zit zelf op Fedora 22. Fedora is zoals velen weten redelijk Bleeding Edge.
Als je dat niet wil, kan je ook gewoon 1 versie ouder nemen. Fedora 22 draait nu bijvoorbeeld al kernel 4.2.3, terwijl Fedora 21 geloof ik op 4.1.x blijft.

Eigenlijk moet je Fedora gewoon zien als de volgende CentOS release, want voor de rest zijn ze gewoon gelijk.

[FREAKJAM]

Ja, ik weet het. Maar ben bang omdat het ook een RHEL product is dat ik tegen dezelfde problemen aanloop. Vanavond toch maar eens proberen in een VM.

[FireDrunk]

Ik heb jouw problemen nog nooit gehad, en draai toch al 2 jaar ofzo yum based distro's.

[jacovn]

BartNL schreef op zondag 18 oktober 2015 @ 13:47:
weet niet of het daar aan moet liggen. Zie ook meldingen van mensen die 350MB/s halen met samba 2. Kan best zijn dat ik hardware setup heb die niet goed ondersteund wordt. Daarbij dacht ik dat FreeNAS en ZFSGuru zo ver waren dat je weinig met de hand moet aanpassen.

Ik heb wel 350 MB/sec naar de zfsguru host toe (windows 7) gehaald, maar altijd maar rond de 100 MB/sec terug.
Kan het nu met windows 10 even niet testen omdat de download pc met 1 GE achter een firewall hangt voor testen. Wat me bij staat is dat het net zo is onder windows 10 nu.

Bij freebsd 10 kan een 10 GE interface snel genoeg zonder tuning, maar niet met smb is mijn ervaring..

Volgens de wiki komt toch bij versie 3 van smb pas de SMB multichannel ?
Daarmee heb je dan met windows 10 en server 2012 de snelheidswinst mee lijkt me.

[FREAKJAM]

FireDrunk schreef op maandag 19 oktober 2015 @ 08:00:
Ik heb jouw problemen nog nooit gehad, en draai toch al 2 jaar ofzo yum based distro's.

Kan natuurlijk ook de combinatie kernel/zfs zijn. Ik heb het idee dat ik last heb van de meldingen sinds ik ZFS 0.6.5.x draai. Heb het in Ubuntu en Debian nog niet kunnen testen want daar zitten ze nu in 0.6.5.2 terwijl op CentOS al 0.6.5.3 te verkrijgen is.

Ik houd alleen niet zo van frequente kernel updates en als dkms de boel opnieuw moet regelen voor spl/zfs.

[FireDrunk]

Je kan natuurlijk de kernel versie "pinnen". Dan krijg je die updates niet.
Dan krijg je van die "Held back" meldingen.

Kleine moeite, en in jouw geval, groot plezier

[FREAKJAM]

FireDrunk schreef op maandag 19 oktober 2015 @ 10:36:
Je kan natuurlijk de kernel versie "pinnen". Dan krijg je die updates niet.
Dan krijg je van die "Held back" meldingen.

Kleine moeite, en in jouw geval, groot plezier

Goed idee! Kwestie van yum.conf aanpassen dacht ik zo. Over paar weken komt Fedora 23 ook alweer uit, maar daar wacht ik nog maar even mee denk ik. OpenSUSE Tumbleweed en versie 42.1 (gebaseerd op core SUSE Linux Enterprise source code) zien er ook interessant uit.

[ Voor 5% gewijzigd door FREAKJAM op 19-10-2015 10:53 ]

[FireDrunk]

OpenSUSE Tubleweed is hetzelfde als Fedora Rawhide... De rolling releases bleeding edge versie

[FREAKJAM]

Ja klopt, maar ik vraag me af in hoeverre het verstandig is bleeding edge te draaien op je ZFS server. Stabiliteit is het meest belangrijke en frequente updates is niet echt iets wat je zoekt vind ik dan.

[dcm360]

Stabiliteit is dan ook precies de reden waarom mijn ZFS-server op OpenSUSE 13.1 zit (de laatste evergreen / lts release). Nu weet ik niet of mijn verhuizing gisteren van esxi naar kvm heel erg goed is voor de betrouwbaarheid, maar vooralsnog werkt het zonder noemenswaardige problemen.

[FireDrunk]

Tja, dan is CentOS wel weer een goed gemiddelde, maar als je daar juist problemen mee hebt...
Je kan ook gewoon Fedora -1 doen (dus nu Fedora 21 draaien). Dan heb je volgens mij een redelijk stabiel platform.

[Wasp]

Verwijderd schreef op vrijdag 02 oktober 2015 @ 23:04:
Je kunt toch je huidige 60GB SSD voor meerdere doeleinden gebruiken? Dat is volgens mij niet mogelijk voor FreeNAS enzo, maar voor ZFSguru wel. Tenzij je veel services enzo gebruikt, heb je aan een 1GiB pool al genoeg theoretisch. Zou hem zelf wel iets groter maken overigens.

Dus dan heb je bijvoorbeeld 6GiB boot/systeem pool, een 40GiB L2ARC partitie en de rest unpartitioned. Lijkt me prima.

Als je de SSD nog niet hebt gekocht: neem een MX200 die je als SLC SSD kunt gebruiken. Dit geldt echter alleen voor het 250GB model. Die kun je dan als 120GB SSD gebruiken als je alles SLC wilt. Dat is voor L2ARC enorm nuttig en zorgt ook voor extra snelheid.

Hier nog even op terugkomend. Heb de MX200 besteld (mede dankzij jouw advies ).

Zoals het nu lijkt ga ik Proxmox gebruiken. Er komen 4 3TB WD Red's in die ik in Raid10/mirrored+striped wil plaatsen. De SSD wil ik dan inderdaad gaan partitioneren.

Alleen ik begrijp dat SLC verhaal nog niet helemaal. Dat gaat alleen werken als ik niet meer dan 120 GB toewijs?

Overigens is de SSD met Proxmox + L2ARC niet redundant. Is mijn zpool nog wel te importeren mocht die SSD kapot gaan en daarmee dus de L2ARC weg is? Dat de Proxmox installatie weg is, is niet zo'n ramp.

Aanvullend, heeft ZIL toegevoegde waarde als ik VM's opsla in de ZFS pool? En kan ik dan dus die SSD wellicht opsplitsen in Ext3 voor proxmox/L2ARC/ZIL?

[FREAKJAM]

FireDrunk schreef op maandag 19 oktober 2015 @ 12:27:
Tja, dan is CentOS wel weer een goed gemiddelde, maar als je daar juist problemen mee hebt...
Je kan ook gewoon Fedora -1 doen (dus nu Fedora 21 draaien). Dan heb je volgens mij een redelijk stabiel platform.

VM met Fedora 22 en ZFS staat klaar. Vanavond mijn pool eens importeren

[aadje93]

Heren der ZFS kunde, tegenwoordig heeft Seagate de 8TB schijfjes voor een erg leuke prijs in de pricewatch staan, voor mijn 24 disk build (denk aan 4x 6disk Z2 vdevs) zou dit erg leuk zijn, echter is er bijzonder weinig over te vinden in combi met ZFS, kwam alleen deze presentatie tegen waarin ZFS als enige "mogelijkheid" met dit soort schijven gezien word.

[Verwijderd]

Ik raad het je sterk af.. niet doen zeg ik. Eigen keus uiteraard.

1) onzekerheid over betrouwbaarheid
2) performance problemen
3) helemaal niet zo goedkoop - duurder per GB dan sommige 3TB en 4TB schijven
4) door de hoge capaciteit lange rebuild tijd
5) door de hoge capaciteit heb je minder disks in je RAID-Z1/2/3 en daardoor minder efficiency (meer parity overhead)

Ik zou liever een batterij 3TB of 4TB disks kiezen en die in RAID-Z3 draaien. Dan heb je ongeveer hetzelfde effect van massa opslag maar heb je veel meer voordelen, betere rebuildtijd, betere performance, lagere prijs per bruikbare GB (parity overhead meegerekend) en neem je simpelweg het risico niet van de toch wel experimentele SMR schijven.

[ Voor 10% gewijzigd door Verwijderd op 19-10-2015 19:43 ]

[BartNL]

jacovn schreef op maandag 19 oktober 2015 @ 08:53:
[...]
Volgens de wiki komt toch bij versie 3 van smb pas de SMB multichannel ?
Daarmee heb je dan met windows 10 en server 2012 de snelheidswinst mee lijkt me.

denk ik ook en op zich heb ik geen haast. ZFS NAS valt mij tot dusver niet mee d.w.z. het voordeel ervaar ik niet als dusdanig (ben me niet bewust ooit data door bitrot te zijn kwijtgeraakt) en de nadelen wel. Hopelijk dat de FreeNAS10 beta van november i.t.t. de huidige alpha wel op mijn NAS werkt. Besteed er op dit moment te weinig tijd aan dus heeft ook nog geen zin om me nu al aan mijn ZFS systeempje te ergeren

[ Voor 4% gewijzigd door BartNL op 19-10-2015 20:19 ]

[narotic]

Wasp schreef op maandag 19 oktober 2015 @ 13:25:
[...]
Overigens is de SSD met Proxmox + L2ARC niet redundant. Is mijn zpool nog wel te importeren mocht die SSD kapot gaan en daarmee dus de L2ARC weg is? Dat de Proxmox installatie weg is, is niet zo'n ramp.

Je pool is op geen enkele wijze afhankelijk van je L2ARC, dus dat is geen enkel probleem. Je kunt als het ware gewoon de SATA kabel van je L2ARC trekken en de pool blijft zonder problemen of corruptie doordraaien. (bedenk bijv. ook dat je bij elke reboot gewoon weer met een schone L2ARC begint)

Dit geldt uiteraard niet voor SLOG/ZIL!

[Bigs]

aadje93 schreef op maandag 19 oktober 2015 @ 18:50:
Heren der ZFS kunde, tegenwoordig heeft Seagate de 8TB schijfjes voor een erg leuke prijs in de pricewatch staan, voor mijn 24 disk build (denk aan 4x 6disk Z2 vdevs) zou dit erg leuk zijn, echter is er bijzonder weinig over te vinden in combi met ZFS, kwam alleen deze presentatie tegen waarin ZFS als enige "mogelijkheid" met dit soort schijven gezien word.

Als het om de Seagate Archive lijn gaat, dan zou ik het niet doen. Dat zijn namelijk SMR schijven en daar is ZFS zich op dit moment nog niet bewust van waardoor de performance belabberd is. Zoek maar eens op SMR in dit topic, er zijn al mensen die dit proefondervindelijk hebben vastgesteld.

[aadje93]

Verwijderd schreef op maandag 19 oktober 2015 @ 19:43:
Ik raad het je sterk af.. niet doen zeg ik. Eigen keus uiteraard.

1) onzekerheid over betrouwbaarheid
2) performance problemen
3) helemaal niet zo goedkoop - duurder per GB dan sommige 3TB en 4TB schijven
4) door de hoge capaciteit lange rebuild tijd
5) door de hoge capaciteit heb je minder disks in je RAID-Z1/2/3 en daardoor minder efficiency (meer parity overhead)

Ik zou liever een batterij 3TB of 4TB disks kiezen en die in RAID-Z3 draaien. Dan heb je ongeveer hetzelfde effect van massa opslag maar heb je veel meer voordelen, betere rebuildtijd, betere performance, lagere prijs per bruikbare GB (parity overhead meegerekend) en neem je simpelweg het risico niet van de toch wel experimentele SMR schijven.

Dat klopt, maar voor 2k wat de kale server kost (en wat je dus meer moet rekenen in het totaal) word het per GB ineens wel goedkoper:

Totale server kosten (voor mijn build) bij gebruik 4TB schijven:

#	Product	Prijs	Subtotaal
1	Intel Xeon E5-1620 v3 Boxed	€ 308,90	€ 308,90
1	Supermicro X10SRL-F (Retail Pack)	€ 305,25	€ 305,25
24	WD Green HDD, 4TB	€ 139,50	€ 3.348,-
8	Samsung M393A2G40DB0-CPB	€ 122,50	€ 980,-
2	Intel DC 2.5" S3700 100GB	€ 165,75	€ 331,50
Bekijk collectie Importeer producten		Totaal	€ 5.273,65

Das dus €5.273,65 gedeeld door (24x4 = 96) = ~€55 per TB

Bij gebruik van 6TB red's (wat ik op het oog heb ivm garantie, je kan moeilijk aankomen na 2 jaar met een green die non-stop gedraaid heeft, daar zijn ze gewoon niet voor gemaakt, al zijn het fysiek de zelfde schijven als red):

#	Product	Prijs	Subtotaal
1	Intel Xeon E5-1620 v3 Boxed	€ 308,90	€ 308,90
1	Supermicro X10SRL-F (Retail Pack)	€ 305,25	€ 305,25
24	WD Red SATA 6 Gb/s WD60EFRX, 6TB	€ 254,95	€ 6.118,80
8	Samsung M393A2G40DB0-CPB	€ 122,50	€ 980,-
2	Intel DC 2.5" S3700 100GB	€ 165,75	€ 331,50
Bekijk collectie Importeer producten		Totaal	€ 8.044,45

Das dus 8.044,15 / (24x6 = 144) = €55/TB (ja ik weet even duur, maar wel meer capaciteit in dezelfde ruimte )

En dan met 8TB schijven

#	Product	Prijs	Subtotaal
1	Intel Xeon E5-1620 v3 Boxed	€ 308,90	€ 308,90
1	Supermicro X10SRL-F (Retail Pack)	€ 305,25	€ 305,25
24	Seagate Archive HDD v2 ST8000AS0002, 8TB	€ 243,95	€ 5.854,80
8	Samsung M393A2G40DB0-CPB	€ 122,50	€ 980,-
2	Intel DC 2.5" S3700 100GB	€ 165,75	€ 331,50
Bekijk collectie Importeer producten		Totaal	€ 7.780,45

das dus 7.780,45 / (24x 8 ) = 192) = €40,52/TB + het "dubbele" van die "goedkoopste" schijven

Veel mensen kijken blind naar de prijs per GB, maar je moet naar het geheel kijken, 2 servers met "goedkoper" 4TB schijven kosten me veeeel meer dan 8TB schijven ondanks dat de schijven per GB misschien duurder zijn

Het enige waar ik me nog zorgen over maak is dat de spec lijst aangeeft dat ze 24/7 maar 1 jaar aan hours (8760) hebben, dit zal inderdaad echt hun doel als tapestreamer op disk benadrukken, gek genoeg hebben ze wel load cycle count van 300k, dat ga je zelfs met 2 seconde head parking niet halen als je aan streamen van data doet in die 8760 uur

Het enige wat mij nu nog tegenhoud is inderdaad het sequentiele gedeelte, maar mijn zfs bak zal waarschijnlijk ook zeer sequentieel worden als ik deze schijven gebruik, de reds worden "gemaakt" voor 24/7, dat lijkt bij de archive disks dus wat minder (gewoon aan bij backups schrijven en dan weer uit) dat kan ik dus niet, ze moeten permanent blijven draaien.


(bij de berekeningen heb ik geen SSD's voor L2arc, voeding en cpu koeler* meegenomen, de eerste 2 heb ik hier al liggen, de laatst kost ~40 euro wat geen bar verschil in de prijs/TB zal uitmaken, het gaat om de vergelijking)

[FREAKJAM]

En verdedig nu eens de andere 4 punten die CiPHER wist op te noemen? Vergis je niet in de andere punten die CiPHER noemt, die zijn minstens zo belangrijk.

Waarom heb je eigenlijk zo veel opslag nodig als ik vragen mag? 4x een 6x8TB vdev in RAIDZ maakt 4x ~29.1TB aan netto storage en dat is aardig wat

[ Voor 74% gewijzigd door FREAKJAM op 20-10-2015 09:45 ]

[Pantagruel]

FREAKJAM schreef op dinsdag 20 oktober 2015 @ 09:35:
En verdedig nu eens de andere 4 punten die CiPHER wist op te noemen? Vergis je niet in de andere punten die CiPHER noemt, die zijn minstens zo belangrijk.

Waarom heb je eigenlijk zo veel opslag nodig als ik vragen mag? 4x een 6x8TB vdev in RAIDZ maakt 4x ~29.1TB aan netto storage en dat is aardig wat

Tja het is maar net wat je belangrijk vindt.

Als iemand graag testpersoon wilt zijn dan lezen we graag over de vorderingen met de archive disks, enige moed kan ik je op dat vlak dan niet ontzeggen.

Eerlijk gezegd is voor mij persoonlijk de data zekerheid belangrijker dan de absolute bodem prijs per TB storage. Op dit moment zou ik absoluut nog voor een PMR drive gaan, afhankelijk van je budget een 4 TB of een 6 TB model. Persoonlijk krijg ik t klamme zweet bij de gedachte dat een resilver met ca. 10 MB/sec voort sukkelt (Zie bijv. de StorageReview test van de Seagate Archive in RAID1 vs HGSTs in RAID1) en t volgende potentiële falen op de loer ligt.

[Paul]

Ik overweeg wel een SMR drive, maar enkel als backup. Momenteel heb ik (omdat de offsite backup-schijf is overleden) alleen 5x4 TB in RAIDZ als backup van wat files op mijn laptop en als opslag van een aantal andere files. Files die ik niet kwijt wil, maar die niet op mijn laptop passen.

Aan die offsite backup wordt gewerkt, maar ik had graag ook lokaal wat meer zekerheid. Maar goed, die SMR-schijf gaat dan ook niet in (een) RAID(vorm).

[Verwijderd]

aadje93 schreef op dinsdag 20 oktober 2015 @ 09:15:
Dat klopt, maar voor 2k wat de kale server kost (en wat je dus meer moet rekenen in het totaal) word het per GB ineens wel goedkoper

Dat is een beetje vreemd rekenen.

Ik reken gewoon: hoeveel bruikbare GB heb je per 4000 euro, bijvoorbeeld. Daarin zit je server (statisch) en de disks. Dus stel 2000 euro kost je server en 2000 euro heb je voor de disks. Voor 2000 euro koop je meer 3TB of 4TB disks dan je 8TB disks koopt. Dat heeft ook invloed op je redundancy overhead.

2000 euro aan Seagate 8TB SMR schijven = 2000 / 238 = 8,40.
2000 euro aan Toshiba 3TB schijven = 2000 / 84 = 23,81

Laat ik even niet afronden (wat je in de praktijk natuurlijk doet) en gewoon 8.40 versus 23.81 gebruiken.

Stel je hebt:

RAID-Z2 van 8.40 schijven = bruikbaar 6.40 * 8TB = 51,2TB
RAID-Z3 van 23,81 schijven = bruikbaar 20,81 * 3TB = 62,43TB

Nou is een RAID-Z3 van 23/24 schijven wel erg veel hoor. Maar 19 schijven zou wel goed uitkomen (=16 data disks) qua prestaties en opslagruimte.

Maar het punt is dat je makkelijk meer schijven krijgt en dus lagere overhead aan parity hebt. Vooral voor builds met een lager budget werkt dit goed in de hand, want bij hele grote builds ga je toch groeperen (dus drie keer een RAID-Z2 vdev bijvoorbeeld).

Wat wel een punt is, dat je ook betaalt per SATA poort. Dus als je een extra HBA nodig hebt om meer disks aan te kunnen sluiten, moet je dat ook meerekenen. Maar met de goedkoopste disks in de pricewatch (Toshiba 3TB) zoals hierboven, denk ik dat je nog steeds lager uitkomt dan die Seagate 8TB schijven, waarbij min of meer het enige voordeel was dat ze goedkoop zijn. Maar dat vind ik dus echt tegenvallen en totaal niet het overwegen waard. Althans niet naar mijn oordeel, ik zou lekker bij PMR blijven!

[aadje93]

Verwijderd schreef op dinsdag 20 oktober 2015 @ 15:19:
[...]

Dat is een beetje vreemd rekenen.

Ik reken gewoon: hoeveel bruikbare GB heb je per 4000 euro, bijvoorbeeld. Daarin zit je server (statisch) en de disks. Dus stel 2000 euro kost je server en 2000 euro heb je voor de disks. Voor 2000 euro koop je meer 3TB of 4TB disks dan je 8TB disks koopt. Dat heeft ook invloed op je redundancy overhead.

2000 euro aan Seagate 8TB SMR schijven = 2000 / 238 = 8,40.
2000 euro aan Toshiba 3TB schijven = 2000 / 84 = 23,81

Laat ik even niet afronden (wat je in de praktijk natuurlijk doet) en gewoon 8.40 versus 23.81 gebruiken.

Stel je hebt:

RAID-Z2 van 8.40 schijven = bruikbaar 6.40 * 8TB = 51,2TB
RAID-Z3 van 23,81 schijven = bruikbaar 20,81 * 3TB = 62,43TB

Nou is een RAID-Z3 van 23/24 schijven wel erg veel hoor. Maar 19 schijven zou wel goed uitkomen (=16 data disks) qua prestaties en opslagruimte.

Maar het punt is dat je makkelijk meer schijven krijgt en dus lagere overhead aan parity hebt. Vooral voor builds met een lager budget werkt dit goed in de hand, want bij hele grote builds ga je toch groeperen (dus drie keer een RAID-Z2 vdev bijvoorbeeld).

Wat wel een punt is, dat je ook betaalt per SATA poort. Dus als je een extra HBA nodig hebt om meer disks aan te kunnen sluiten, moet je dat ook meerekenen. Maar met de goedkoopste disks in de pricewatch (Toshiba 3TB) zoals hierboven, denk ik dat je nog steeds lager uitkomt dan die Seagate 8TB schijven, waarbij min of meer het enige voordeel was dat ze goedkoop zijn. Maar dat vind ik dus echt tegenvallen en totaal niet het overwegen waard. Althans niet naar mijn oordeel, ik zou lekker bij PMR blijven!

Wat ik ook noemde, ik heb gerekend met de dingen die op het moment nog gekocht moeten worden, er komen zowieso 24 schijven in (heb alle aansluitingen beschikbaar) in een norco rpc 4224, daarom reken ik dus met de prijs per TB die het mij zal kosten

Ik ga uit van ruwe capaciteit gezien ik qua raid hetzelfde doe (4 Z2 vedvs van 6 schijven)

[narotic]

aadje93 schreef op dinsdag 20 oktober 2015 @ 18:12:
[...]


Wat ik ook noemde, ik heb gerekend met de dingen die op het moment nog gekocht moeten worden, er komen zowieso 24 schijven in (heb alle aansluitingen beschikbaar) in een norco rpc 4224, daarom reken ik dus met de prijs per TB die het mij zal kosten

Ik ga uit van ruwe capaciteit gezien ik qua raid hetzelfde doe (4 Z2 vedvs van 6 schijven)

Maar je hebt natuurlijk ook niet een complete tweede server nodig om 48x4TB te gebruiken in plaats van 24x8TB. Een simpele SAS expander en een paar HBA's is voldoende.

[aadje93]

SAS expanders + Sata schijven + freenas is geen goede combi heb ik vaak gelezen, of dit ook zo is kan ik uiteraard niet verifieren, maar mocht het werken heb je uiteraard gelijk, maar dan houd je nog steeds dat voor het geld je zeer waarschjnlijk alsnog met 8TB (voor die prijs) goedkoper bent in 1 server, nieuw 24disk chassis kost snel 600-700 euro, expander 300, controllertje met externe poort 100-200, voeding(en) 100? Zit je zo weer "kaal" op ~1400-1500.

[narotic]

Verwijderd schreef op dinsdag 20 oktober 2015 @ 15:19:
[...]
Nou is een RAID-Z3 van 23/24 schijven wel erg veel hoor. Maar 19 schijven zou wel goed uitkomen (=16 data disks) qua prestaties en opslagruimte.

Maar het punt is dat je makkelijk meer schijven krijgt en dus lagere overhead aan parity hebt. Vooral voor builds met een lager budget werkt dit goed in de hand, want bij hele grote builds ga je toch groeperen (dus drie keer een RAID-Z2 vdev bijvoorbeeld).

Puur uit interesse, maar ik zou juist (ook?) bij budget vdevs groeperen, puur omdat je dan veel eenvoudiger je pool mee kunt schalen (of een extra groep toevoegen, of grotere schijven in een van de groepen) met de daadwerkelijke behoefte. Met 19 schijven in RAID-Z3 zit je behoorlijk vast qua uitbreidbaarheid.

Is er misschien behalve iets lagere parity overhead een ander voordeel wat ik over het hoofd zie?

[FireDrunk]

VDEV's bijschalen is leuk, maar de performance kakt flink in. ZFS gaat namelijk proberen om alle VDEV's tegelijk vol te krijgen. Dus als 1 VDEV op 90% zit, en je voegt een lege toe, gaat 1 VDEV 90% van de write krijgen, en 1 maar 10%.

Er is geen 'rebalance' in ZFS.

[Bigs]

aadje93 schreef op dinsdag 20 oktober 2015 @ 21:26:
SAS expanders + Sata schijven + freenas is geen goede combi heb ik vaak gelezen, of dit ook zo is kan ik uiteraard niet verifieren, maar mocht het werken heb je uiteraard gelijk, maar dan houd je nog steeds dat voor het geld je zeer waarschjnlijk alsnog met 8TB (voor die prijs) goedkoper bent in 1 server, nieuw 24disk chassis kost snel 600-700 euro, expander 300, controllertje met externe poort 100-200, voeding(en) 100? Zit je zo weer "kaal" op ~1400-1500.

Het is al vaker gezegd hier volgens mij: met SAS2 expanders is het gebruik van SATA schijven (met TLER) geen enkel probleem. De eerste generatie (3Gb/s) SAS lag wat lastiger en die spullen zou ik dan ook mijden.

[ Voor 7% gewijzigd door Bigs op 21-10-2015 10:54 ]

[Q]

FireDrunk schreef op dinsdag 20 oktober 2015 @ 21:58:
VDEV's bijschalen is leuk, maar de performance kakt flink in. ZFS gaat namelijk proberen om alle VDEV's tegelijk vol te krijgen. Dus als 1 VDEV op 90% zit, en je voegt een lege toe, gaat 1 VDEV 90% van de write krijgen, en 1 maar 10%.

Er is geen 'rebalance' in ZFS.

Voor een thuis file server / nas is dat geen issue toch?
Ander verhaal als je VMs gaat draaien.

[FireDrunk]

Mwoh, persoonlijk ben ik er niet zo'n fan van als mijn hardware niet peformed terwijl het sneller kan

[A1AD]

FireDrunk schreef op woensdag 21 oktober 2015 @ 13:25:
Mwoh, persoonlijk ben ik er niet zo'n fan van als mijn hardware niet peformed terwijl het sneller kan

Was jij niet degene met 4*4TB in RaidZ1

[FireDrunk]

6*4 in Z2 tegenwoordig

[HyperBart]

A1AD schreef op woensdag 21 oktober 2015 @ 19:07:
[...]


Was jij niet degene met 4*4TB in RaidZ1

[Extera]

Ik heb om die reden bij een uitbreiding zelf een ' rebalance' gedaan. Dus 50% data van het oude vdev naar een nieuwe map kopiëren. Daarna de originele data verwijderen en dit geintje nog een keer doen....

Ik heb overigens 2x een 8TB disk gekocht, en deze waren beide DOA. Dit zegt voor mij al genoeg...
Persoonlijk zou ik ook voor 24x 6TB gaan, en er rekening mee houden dat er een chassis onder kan.

Dit kost dan een extra chassis, expander en een voeding. So be it...
Ga je die server in 1 keer vol zetten?... hier groeit de data geleidelijk, en is om de zoveel tijd bijschalen prima.

Wel jammer dat ZFS geen rebalance feature heeft, een volgende uitbreiding maak ik dan liever een nieuwe pool aan denk ik. Alleen gevoelsmatig is dat kut, 1 dikke pool is toch makkelijker.

[Dadona]

FireDrunk schreef op zondag 18 oktober 2015 @ 19:17:
Voor de mensen die het leuk vinden:

Morgen begint de OpenZFS Developer Summit.

http://livestream.com/accounts/15501788/events/4422403
http://open-zfs.org/

Eerste livestream begint om 18:30 Nederlandse tijd.

De video's staan inmiddels in het Youtube kanaal. Zaten toch wel wat interessante zaken bij: YouTube: OpenZFS Vooral selective send and receive. Live migration moet ik nog eens bekijken.

[jacovn]

aadje93 schreef op dinsdag 20 oktober 2015 @ 18:12:
[...]


Wat ik ook noemde, ik heb gerekend met de dingen die op het moment nog gekocht moeten worden, er komen zowieso 24 schijven in (heb alle aansluitingen beschikbaar) in een norco rpc 4224, daarom reken ik dus met de prijs per TB die het mij zal kosten

Ik ga uit van ruwe capaciteit gezien ik qua raid hetzelfde doe (4 Z2 vedvs van 6 schijven)

Waarom moeten er per se 24 hdd's in ? Is dat om meer iops te halen met de 4 vdevs ?

Normaal kijk je toch meer vanuit opslag behoefte in de prive server sfeer.

[maomanna]

Zojuist krijg ik in mn adminpanel te zien dat er een update is voor ZoL.
0.6.5.3 is uit.

[FREAKJAM]

maomanna schreef op vrijdag 23 oktober 2015 @ 12:06:
Zojuist krijg ik in mn adminpanel te zien dat er een update is voor ZoL.
0.6.5.3 is uit.

Is er al een tijdje anders. Per distro scheelt het wanneer het natuurlijk beschikbaar is. In CentOS en Fedora volgens mij al 2 dagen later. De 0.6.5.x branch is volgens mij aardig buggy aangezien ze nu al een 3de release hebben moeten doen in een maand tijd.

[ Voor 12% gewijzigd door FREAKJAM op 23-10-2015 12:24 ]

[maomanna]

zit op Ubuntu Linux 14.04.3

[ Voor 36% gewijzigd door maomanna op 23-10-2015 12:56 ]

[FREAKJAM]

maomanna schreef op vrijdag 23 oktober 2015 @ 12:29:
zit op ubuntu.

Debian zit nog op 0.6.5.2 zie ik nu. Hopelijk daar ook snel 0.6.5.3 want ik wil mijn graag testen onder Debian met deze versie.

In navolging van Ubuntu, ZFS binnenkort ook standaard in Debian as it seems.

Libdvdcss and ZFS soon in Debian?
=================================

We received legal advice from Software Freedom Law Center about the
inclusion of libdvdcss and ZFS in Debian, which should unblock the
situation in both cases and enable us to ship them in Debian soon.

[ Voor 47% gewijzigd door FREAKJAM op 23-10-2015 14:05 ]

[FREAKJAM]

Ik zit er ernstig over na te denken om mijn pool opnieuw in te richten omdat ik van plan ben de boel te migreren naar SmartOS (ik draai nu alles op ZoL). Ik heb de afgelopen dagen gespeeld met SmartOS en het OS bevalt me wel. Ik ben van plan alles wat ik nu draai (NZBGet, Couchpotato, Sonarr, Plex/Emby etc) in een zone/docker te draaien. Ik draai nu nog pfSense in een VM, maar die wil ik gaan vervangen door een EdgeRouter Lite. Ik ga binnenkort ook glasvezel nemen en lees veel goede dingen over het apparaat. Door pfSense te ditchen kan ik mijn alles draaien in een zone/docker en komt er geen KVM/QEMU aan te pas. SmartOS spreekt ZFS direct aan, dus liefst begin ik dan met een schone pool.

Mijn huidige ZFS pool is 6x3TB (ongeveer 2 jaar oud) en neemt al ruim 7TB in beslag. Ik denk dat ik binnen een jaar mogelijk al tegen de 10TB aanloop en dan is mijn pool simpelweg te groot geworden (aangezien er wordt aangeraden genoeg ruimte over te houden op ZFS).

code:

NAME                                                    USED  AVAIL  REFER  MOUNTPOINT
tank                                                   7.02T  3.46T   240K  /tank

SmartOS draait volledig in memory wat betekent dat ik een SSD overhoud die ik vervolgens kan gebruiken als L2ARC/SLOG device. Rest mij de opzet van mijn ZFS pool. Ik moet én mijn data zien veilig te stellen (ik heb een spare 3TB drive thuis liggen inclusief een paar externe drives) en ik wil een grotere ZFS pool.

Wat is hierin wijsheid? Ik heb op dit moment 6x de WD30EFRX (met een extra reserve) en zat er aan te denken om een nieuwe vdev van 8xWD30EFRX op te gaan zetten. Zit ik met het probleem hoe de data over te zetten van pool oud naar nieuw. Aangezien ik minimaal 6TB aan data heb die ik moet overzetten dien ik minimaal 10 disks tot mijn beschikking te hebben (8 voor de nieuwe pool en 2 die zullen dienen als spare en die ik kan gebruiken om hierop tijdelijk mijn data op te zetten). Dit zou betekenen dat ik direct 8 schijven kan gebruiken voor mijn nieuwe pool en direct 2 spares heb liggen. Ander "probleem" is dat de nieuwe schijven waarschijnlijk een nieuwe batch zullen betreffen. In hoeverre is dat erg?

Een ander idee is om bijv te gaan voor de HGST Deskstar 6x4TB (RAIDZ2) + een reserve en de huidige schijven te verkopen. (6 drives hebben nog een jaar garantie, de reserve nog een jaar). Een setup van 6 drives komt me sowieso iets beter uit, omdat ik maar 7 drives max kan plaatsen in mijn case (Bitfenix Shadow). Wat is denken jullie het slimste?

[ Voor 6% gewijzigd door FREAKJAM op 29-10-2015 13:06 ]

[FireDrunk]

Ik zou juist met ZFS niet bang zijn om disken te mixen. Waar traditionele RAID controllers misschien moeilijk doen over wisselende access times denk ik dat ZFS daar niet om maalt. (je houdt gewoon de snelheid van de traagste disk)

Qua layout: 7 en 8 schijven is altijd kut als je RAIDZ* wil draaien. Maakt het je uit om een 'mooi' getal te hebben vanwege performance en ruimte verlies? Persoonlijk geef ik er niet zoveel om, maar sommigen wel.

Ik heb 4*4TB al 2 keer uitgeleend aan mensen die van array wilden switchen Is dat een optie?

[FREAKJAM]

Zit ik nog steeds het probleem met wat de meest ideale setup is. RAIDZ3 is goed vanaf een 8 drive setup, maar dat vind ik weer redelijk overkill wanneer er voornamelijk alleen media op komt te staan. Liefst behoud ik mijn huidige drives (scheelt een zakcent) en koop ik extra drives bij van hetzelfde type. Ik kan natuurlijk ook 2 pools maken van 4x3TB (RAIDZ1), dat geeft mij ~14TB aan ruimte ipv ~11TB. Maar wel weer RAIDZ1.

Je 4*4TB lenen is wellicht een idee (tof dat je het aanbiedt trouwens), ik zou je pool tijdelijk kunnen importeren op mijn desktop met een ZFSGuru live-CD of iets dergelijks en met zfs send de boel kunnen overzetten naar de nieuwe array. Maar goed, dan heb ik ook weer een HBA controllertje nodig

Uiteindelijk kan ik natuurlijk ook iets doen aan mijn tv-serie verslaving

[ Voor 11% gewijzigd door FREAKJAM op 29-10-2015 13:27 ]

[FireDrunk]

Nu nog 3TB schijven kopen zou ik niet doen. Helemaal als mensen ZFS gebruiken, raad ik toch aan om ruim in de toekomst te kijken. ZFS is nou niet het meest flexibele systeem, waardoor je graag iets verder vooruit wil kijken.

Met dat in het achterhoofd zou ik al snel naar 6+TB schijven kijken... Je kan 2*6TB in mirror zetten, en vrij makkelijk upgraden naar RAIDZ1 met 3 schijven. Daar zet je dan al je data op, en kan je langzaamaan je 3TB schijven vervangen.

Vergt uiteraard wel een investering...

[FREAKJAM]

Dan is 4x6TB in RAIDZ1 nog wellicht de beste optie (ik heb 8 poorten op mijn mobo). Geeft mij ook de ruimte om in die toekomst er een vdev van 4x6tb bij te zetten. Hiermee ga ik ook van ~11TB vrije ruimte naar ~18TB vrije ruimte.

Ik ga er eens over nadenken. Is toch wel weer een flinke investering en het is nog maar net de vraag hoeveel ik ga krijgen voor mijn huidige RED's en of deze uberhaupt nog te verkopen zijn. Lastig is het wel allemaal

[ Voor 3% gewijzigd door FREAKJAM op 29-10-2015 13:46 ]

[FireDrunk]

Zeker, upgraden blijft een lastige keuze. Ik denk dat ik in mijn geval voor een tweede array zou gaan. Je kan super makkelijk in ZFS gewoon een legacy mountpoint instellen in een map op je eerste pool.

Dus bijvoorbeeld:

PoolA/Series -> PoolA/Series
PoolA/Movies -> PoolA/Movies
PoolB/VirtualMachines -> PoolA/VirtualMachines

Dan merk je amper dat je twee pools hebt.

[Compizfox]

FireDrunk schreef op donderdag 29 oktober 2015 @ 13:30:
Nu nog 3TB schijven kopen zou ik niet doen. Helemaal als mensen ZFS gebruiken, raad ik toch aan om ruim in de toekomst te kijken. ZFS is nou niet het meest flexibele systeem, waardoor je graag iets verder vooruit wil kijken.

Met dat in het achterhoofd zou ik al snel naar 6+TB schijven kijken... Je kan 2*6TB in mirror zetten, en vrij makkelijk upgraden naar RAIDZ1 met 3 schijven. Daar zet je dan al je data op, en kan je langzaamaan je 3TB schijven vervangen.

Vergt uiteraard wel een investering...

Dat is natuurlijk ook nogal afhankelijk van hoeveel data je kwijt moet. Ik heb bijvoorbeeld een RAID-Z1 van 3x 1 TB, en dat is voor mij meer dan genoeg. Ik ben destijds bewust voor 1 TB gegaan (in plaats van 2 TB) omdat ik simpelweg niet zoveel ruimte nodig heb (nog steeds niet, trouwens).

[Verwijderd]

RAID-Z is juist extra gevoelig voor latencyverschil omdat elke I/O pas is afgerond als elke disk zijn antwoord klaar heeft. Bij RAID5 is er vaak maar één disk die een enkele read request afhandelt, soms twee. Dat geeft veel minder performancedegradatie bij wisselende latencies.

Wat ZFS wel doet is een transaction group (writes) op de hoogste snelheid wegschrijven. De tragere disk zie je dan als enige nog nakauwen terwijl de overige disks al stil liggen. Maar kleine latencyschommelingen worden automatisch afgevlakt hierdoor. Maar bij reads is dit niet zo, dus is het zo dat de traagste disk voor elke I/O request de uiteindelijke latency bepaalt.

Kortom, ik zou juist wel proberen dezelfde disks te krijgen. Zelfs firmwareverschillen kunnen voor verschil zorgen. Maargoed, ik mix ook wel eens disks. Hoeveel het scheelt weet ik niet, maar theoretisch zou ZFS RAID-Z daar dus meer last van moeten hebben dan traditioneel RAID5.

[FREAKJAM]

"Upgraden" naar RAIDZ2 met een 8 disk layout is ook de meest goedkope optie op dit moment voor mij. Rest de vraag of RAIDZ2 wel zo slim is met 8 disks. Zoals eerder gezegd vind ik 8 schijven in een RAIDZ3 lichtelijk overdreven aangezien ik voornamelijk media host. Daarnaast beschikt mijn LSI2308 ook maar over 8 poorten, dus ik kan er niet eens meerdere schijven aan hangen.

Een extra M1015 kopen en 2x 5x3TB in RAIDZ2 is ook weer een optie, maar ik wil het ook allemaal niet te moeilijk maken. (Ik moet dan ook sowieso een nieuwe case kopen). Jammer dat een schijfje erbij prikken niet mogelijk is met ZFS.

[FireDrunk]

@CiPHER, je begreep mijn opmerking verkeerd. Je hebt helemaal gelijk, maar waar ik op doel is dat ZFS je disk niet offline zal halen vanwege wat latency verschillen. Uiteraard merk je het in performance, maar het zal allemaal wel blijven werken.

[idef1x]

FireDrunk schreef op donderdag 29 oktober 2015 @ 13:30:
Met dat in het achterhoofd zou ik al snel naar 6+TB schijven kijken... Je kan 2*6TB in mirror zetten, en vrij makkelijk upgraden naar RAIDZ1 met 3 schijven. Daar zet je dan al je data op, en kan je langzaamaan je 3TB schijven vervangen.

Dat snap ik even niet....Als je je vdev mirror van 2x6TB hebt kun je er toch niet een 3e bij prikken en er raidz van maken? Je moet dan toch eerst de je pool slopen voor je er een raidz van kan maken? Of haal ik als zfs noob nu e.e.a. door elkaar?

[FireDrunk]

Je breekt de mirror. Maakt van de losse schijf en je nieuwe schijf een raidz pool met missende disk. Daarna verplaats je alle data. Daarna de losse toevoegen aan de nieuwe pool en laten resilveren.

[idef1x]

Ah ongeveer hetzelfde truukje als Cipher toevallig net schreef in Verwijderd in "Het grote DIY RAID NAS topic deel 3"

[FireDrunk]

Exact

[Compizfox]

FREAKJAM schreef op donderdag 29 oktober 2015 @ 15:49:
"Upgraden" naar RAIDZ2 met een 8 disk layout is ook de meest goedkope optie op dit moment voor mij. Rest de vraag of RAIDZ2 wel zo slim is met 8 disks. Zoals eerder gezegd vind ik 8 schijven in een RAIDZ3 lichtelijk overdreven aangezien ik voornamelijk media host. Daarnaast beschikt mijn LSI2308 ook maar over 8 poorten, dus ik kan er niet eens meerdere schijven aan hangen.

Een extra M1015 kopen en 2x 5x3TB in RAIDZ2 is ook weer een optie, maar ik wil het ook allemaal niet te moeilijk maken. (Ik moet dan ook sowieso een nieuwe case kopen). Jammer dat een schijfje erbij prikken niet mogelijk is met ZFS.

Moah, 8 schijven in RAID-Z2 kan best, lijkt me. Je hebt dan 1/4 parity.

[SymbolicFrank]

Dus, ZFS:

1. Het is volwassen, ook op Linux. Maar dan moet je wel zelf een installer maken.
2. Je kunt beter BSD gebruiken als je ZFS wilt, dan werkt het tenminste.
3. Je moet er niet van proberen te booten, of het als swap drive proberen te gebruiken. Soms werkt dat.
4. Onderhuids is het gewoon RAID 0, 5 of 6.
5. Het werkt zo problematisch omdat het eigenlijk heel veel ECC geheugen en CPU tijd nodig heeft om te voldoen aan de verwachtingen.
6. Van de visie van de ontwerper is niet veel meer over: je kunt niet gewoon drives toevoegen en verwijderen.

Volgens mij is mdadm met ext4 practischer en veelzijdiger.

Maar ik zou wel heel graag een file-systeem hebben, waarbij je makkelijk schijven toe kunt voegen en verwijderen. (Een schijf die kapot gaat verwijderd zichzelf.) Dus eigenlijk, een syteem waarbij ieder bestand op minstens twee en liefst drie schijven staat, indien de ruimte dat toelaat. En dat controleert op corruptie.

Dus eigenlijk ZFS zoals het ooit bedacht is.

[CurlyMo]

SymbolicFrank schreef op vrijdag 30 oktober 2015 @ 23:02:
Dus, ZFS:

1. Het is volwassen, ook op Linux. Maar dan moet je wel zelf een installer maken.

Is dit een onhandige verwoording dat je het zelf moet installeren wegens licentie incompatibiliteit?

2. Je kunt beter BSD gebruiken als je ZFS wilt, dan werkt het tenminste.

Dan werkt het OOTB wegens licentie compatibiliteit.

3. Je moet er niet van proberen te booten, of het als swap drive proberen te gebruiken. Soms werkt dat.

Booten werkt prima, swap ook.

4. Onderhuids is het gewoon RAID 0, 5 of 6.

Niet helemaal, dat gaat CiPHER je wel vertellen in pagina lange posts

5. Het werkt zo problematisch omdat het eigenlijk heel veel ECC geheugen en CPU tijd nodig heeft om te voldoen aan de verwachtingen.

Het werkt prima op een 1GB RAM ARM bordje, verwacht alleen geen hoge performance. Mijn eigen thuis systeem is ook vrij standaard. Core i5 met 16GB normaal geheugen en dat werkt wel snel genoeg. De kracht gebruik ik vooral voor software compilatie.

6. Van de visie van de ontwerper is niet veel meer over: je kunt niet gewoon drives toevoegen en verwijderen.

Was dat ooit de visie? Bron?

Volgens mij is mdadm met ext4 practischer en veelzijdiger.

Leg uit waarom je dat vind?

Maar ik zou wel heel graag een file-systeem hebben, waarbij je makkelijk schijven toe kunt voegen en verwijderen. (Een schijf die kapot gaat verwijderd zichzelf.) Dus eigenlijk, een syteem waarbij ieder bestand op minstens twee en liefst drie schijven staat, indien de ruimte dat toelaat. En dat controleert op corruptie.

Wat let je om alleen met mirrors te werken? Dan doet ZFS precies wat je wilt.

Dus eigenlijk ZFS zoals het ooit bedacht is.

Bron?

[Verwijderd]

SymbolicFrank schreef op vrijdag 30 oktober 2015 @ 23:02:
Dus, ZFS:

1. Het is volwassen, ook op Linux. Maar dan moet je wel zelf een installer maken.

Dat laatste gaat bijna automatisch en is geen issue meer. Het eerste is discutabel; namelijk dat ZFS al volwassen is op Linux. Daar ben ik het zelf niet helemaal mee eens. Het is zeker wel bruikbaar genoeg op Linux, maar of dat ook gelijk volwassen mag heten kun je van mening over verschillen. Geheugenmanagement loopt achter, pool features lopen ietwat achter, zaken als TRIM en dergelijke werken volgens mij nog niet, booten van RAID-Z gaat tegenwoordig wel volgens mij. Maar het grootste punt is stabiliteit. Ik hoor regelmatig dat ZFS op Linux op zijn bek gaat na een update, wat dan weer met instructies valt te herstellen. Maar dat is niet wat ik volwassen noem. BSD blijft de betere implementatie van ZFS hebben. Maar als je graag Linux gebruikt om andere redenen is dat denk ik geen reden om geen ZFS te gebruiken. Maar als iemand zegt dat ZFS onder Linux even volwassen is als onder BSD, ben ik het daar zelf niet mee eens.

2. Je kunt beter BSD gebruiken als je ZFS wilt, dan werkt het tenminste.

Op Linux werkt het ook, maar onder BSD werkt het nog iets beter en vooral meer volwassen/mature/production-ready, ook al is het op Linux ook al 'production ready' genoemd - valt daar door de problemen en missende features nog wel wat aan af te doen.

3. Je moet er niet van proberen te booten, of het als swap drive proberen te gebruiken. Soms werkt dat.

Booten werkt volgens mij ook onder Linux gewoon prima. SWAP is echter wel problematisch, ook onder BSD. Zou ZFS zijn ARC kleiner moeten maken vanwege geheugentekort, dan zijn er issues als ZFS ook als SWAP gebruikt wordt en dit tegelijkertijd gebeurt. Juist als ZFS moet inkrimpen, wordt het heftig als SWAP gebruikt en dan kunnen dingen op elkaar wachten. Althans, dat heb ik ervan begrepen. Een dedicated swap partitie is sowieso beter, ik gebruik GELI-encrypted swap hiervoor.

4. Onderhuids is het gewoon RAID 0, 5 of 6.

ZFS is technisch geen RAID omdat het een dynamisch schema gebruikt, terwijl RAID een statisch voorspelbaar schema gebruikt waarvoor geen filesystem-kennis nodig is om het te implementeren cq. na te bootsen. Dus een BSD software RAID kan nadoen wat Intel onboard RAID doet, bijvoorbeeld. Maar een RAID engine kan niet nadoen wat ZFS doet. Dus technisch geen RAID, maar voor de gebruiker zijn de kenmerken van RAID0, RAID1, RAID5 en RAID6 (en 'RAID7') wel overeenkomstig met wat ZFS biedt qua striping, mirrorring en parity (RAID-Z) schema's.

5. Het werkt zo problematisch omdat het eigenlijk heel veel ECC geheugen en CPU tijd nodig heeft om te voldoen aan de verwachtingen.

Er zijn hier (en elders) mensen die stellen dat je absoluut ECC geheugen moet gebruiken. De grap is nu juist dat ZFS vanwege zijn beschermingsmechanismes juist minder noodzaak heeft om ECC te gebruiken dan andere filesystems. Dit omdat andere filesystems juist méér geheugen gebruiken in absolute aantallen (filecache) en daar geen enkel mechanisme tegenoverstellen wat RAM corruptie kan detecteren, laat staan corrigeren. Bij ZFS werkt dat zeker niet perfect, maar heeft tenminste wel mogelijkheden tot correctie en uiteindelijk zal je alle corruptie detecteren mits het niet al corrupt was voordat ZFS het in zijn handen kreeg. Dit is althans mijn samenvatting; er zijn mensen die het anders zullen uitleggen en het mogelijk ook niet op alle punten eens zijn met deze samenvatting. Daarvoor verwijs ik naar de discussie: ECC geheugen voor zelfbouw ZFS NAS?.

Dat ZFS veel CPU tijd nodig heeft is onzin; bij legacy filesystems is dat vrijwel nul, bij ZFS iets meer door berekening van checksums en dergelijke. Maar nog steeds heel weinig; de langzaamste 64-bit processor die ik ken (AMD C60) is voldoende voor een gigabit NAS. En tegenwoordig is het goedkoopste en meest langzame de J1900 chip van Intel, en door de 4 cores is deze toch best wel snel aangezien ZFS en andere software alle cores optimaal kan benutten. Tijdens normale I/O zal je zelden 10% CPU gebruiken van een processor die drie tientjes kost. Maar als je speciale dingen gaat doen zoals GZIP-compressie of SHA256 checksums of encryptie, dan kan het anders worden. Encryptie is het enige dat veelvuldig wordt toegepast, maar dan is het gebruikelijk dat je dit op een AES-NI hardware accelerated processor doet, zodat je er vrijwel niets van merkt qua CPU performance. Zonder die acceleratie doe je tegen de 100MB/s op een J1900 chip en dat beperkt dus je performance wel enigszins, met name rebuild performance.

6. Van de visie van de ontwerper is niet veel meer over: je kunt niet gewoon drives toevoegen en verwijderen.

De visie van de ontwerper Jeff Bonwick was dat ZFS de belofte waarmaakt waar RAID mee is begonnen: om met goedkope hardware gecombineerd met slimme software een betrouwbaar opslagmechanisme te creëren.

Het on-the-fly uitbreiden van je parity volume door alle data om te spitten kent ook nadelen. Zoals: wat gebeurt er als tijdens de procedure er wat misgaat, zoals bad sectors, een disk die wegvalt, een spontane reset. ZFS is niet ontwikkeld met thuisgebruikers in het achterhoofd, daarom ook die leuke 'restore entire pool from backup' meldingen als er ook maar één file stuk is. Bedrijven hebben altijd een backup, maar thuisgebruikers die ZFS gebruiken, veelal niet. Het on-the-fly uitbreiden met ZFS kan overigens wel met mirrors en stripes, zoals CurlyMo ook al zei.

Volgens mij is mdadm met ext4 practischer en veelzijdiger.

Ext4 is legacy storage en dat kan praktischer zijn afhankelijk van je wensen. Veelzijdiger zul je moeten uitleggen, want het kent veel minder features - eigenlijk geen want Ext4 komt van Ext3 en Ext3 is Ext2+journalling en Ext2 komt van UFS en dat zijn allemaal supersimpele legacy filesystems. ZFS is van een andere generatie en véél complexer, zoals ook Btrfs en ReFS.

Maar ik zou wel heel graag een file-systeem hebben

Je kunt niet alles hebben - het perfecte filesystem is nog niet geschreven. Ook Btrfs en ReFS gaan dat niet worden. Bij definitie eigenlijk, want vanwege de licentie zullen dit gesloten filesystems worden die alleen op hun eigen platform draaien. ZFS is juist zeer uitzonderlijk omdat het - vanwege een permissive licentie - op vrijwel alle platforms (Solaris, BSD, Linux, Apple OSX) behalve Windows draait. Ik had ook begrepen dat ZFS op Linux niet out-of-the-box werkt niet zozeer vanwege incompatibiliteit van de CCDL-licentie met de GPL-licentie, maar omdat Linus een ondertekende verklaring wenst bij het committen van code in de Linux kernel.

Behalve dat parity RAID niet per disk uitgebreid kan worden, voldoet ZFS denk ik ruimschoots aan wat vele thuisgebruikers willen. Persistent L2ARC zou nog een tweede kunnen zijn, maar afgezien hiervan kan ik weinig verzinnen wat ZFS niet al uitstekend doet. Ja, op Windows draaien zodat het legacy NTFS kan worden vervangen, want ReFS is lang niet zo goed en momenteel nog zeer alpha-kwaliteit.

[idef1x]

Verwijderd schreef op zaterdag 31 oktober 2015 @ 04:33:
[...]

Dat laatste gaat bijna automatisch en is geen issue meer. Het eerste is discutabel; namelijk dat ZFS al volwassen is op Linux. Daar ben ik het zelf niet helemaal mee eens. Het is zeker wel bruikbaar genoeg op Linux, maar of dat ook gelijk volwassen mag heten kun je van mening over verschillen. Geheugenmanagement loopt achter, pool features lopen ietwat achter, zaken als TRIM en dergelijke werken volgens mij nog niet, booten van RAID-Z gaat tegenwoordig wel volgens mij. Maar het grootste punt is stabiliteit. Ik hoor regelmatig dat ZFS op Linux op zijn bek gaat na een update, wat dan weer met instructies valt te herstellen. Maar dat is niet wat ik volwassen noem. BSD blijft de betere implementatie van ZFS hebben. Maar als je graag Linux gebruikt om andere redenen is dat denk ik geen reden om geen ZFS te gebruiken. Maar als iemand zegt dat ZFS onder Linux even volwassen is als onder BSD, ben ik het daar zelf niet mee eens.

Hmmm ik meen dat Q een 71TiB ZFS NAS op Debian heeft draaien...zou hij dat doen als het nog niet volwassen genoeg is? Zo'n NAS kan ik niet echt onder test systeem rekenen
Met Ubuntu kan ik me wel indenken dat het wel eens op zijn gat gaat na het updaten van de kernel, maar in het verleden (heb een tijd ZOL op Ubuntu gedraaid) ben ik daar niet tegenaan gelopen. Het werkte prima. En dat is ook gelijk het punt: werkte het maar eens niet, dan kon ik zien hoe het fixen zou werken

[Compizfox]

idef1x schreef op zaterdag 31 oktober 2015 @ 19:56:
[...]
Hmmm ik meen dat Q een 71TiB ZFS NAS op Debian heeft draaien...zou hij dat doen als het nog niet volwassen genoeg is? Zo'n NAS kan ik niet echt onder test systeem rekenen

Dat hangt een beetje af van hoe je "volwassen" definieert. Zover ik weet, is ZoL zeker stabiel/volwassen genoeg voor normaal gebruik, maar ZFS op Solaris of FreeBSD is toch echt volwassener.

Hoe groot het verschil echt is, kan ik eigenlijk niet zoveel uitspraken over doen, want ik heb het zelf nog nooit geprobeerd. Ik baseer me voornamelijk op wat er hier in dit topic gezegd wordt, en als je sommigen (zoals CiPHER) mag geloven, is er nog steeds een aanzienlijk verschil in volwassenheid.

[Keiichi]

Ik zal ergens iets gemist hebben hoe zfs berekent hoeveel schijfruimte er gebruikt wordt en vrij is.

code:

[root@nas3 ~]# zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  9.06T  8.57T   501G         -    46%    94%  1.16x  ONLINE  -

Maar als ik 'df -h' doe, dan kan maar 65g. Het is een raid-z1 van 5 schijven van 2TB

_{ik weet dat de boel veels te vol zit}

[Verwijderd]

zpool capaciteit is inclusief parity overhead. zfs capaciteit (ook df) is bruikbare ruimte, dus exclusief parity overhead en exclusief reservations en exclusief filesystem overhead zoals checksums en filesystem metadata, enzovoorts. Dus tussen de capaciteit die zpool en zfs meldt, zit verschil.

[Keiichi]

Volgens mij heb ik ergens richting of over de 20 miljoen files, dat wil dan ook wel de nodige checksum en metadata vragen zeker

[Verwijderd]

Hangt van je ashift setting af; want met ashift=12 dus 4K optimalisatie, heb je minimaal 4K per file tenzij deze compressed zijn. Ook embedded_data feature kan helpen, aangezien de data dan in de pointer zelf wordt opgeslagen en dus geen extra plek inneemt.

[FireDrunk]

Ik dacht dat dat by default aan stond?

[Verwijderd]

Ashift moet je onder Linux volgens mij expliciet opgeven. Onder BSD werkt dat min of meer automatisch met de sysctl's:

code:

vfs.zfs.min_auto_ashift: 9
vfs.zfs.max_auto_ashift: 13

Voorts kan BSD zien of een disk 4K is of niet:

code:

# diskinfo -v /dev/ada0
/dev/ada0
    512             # sectorsize
    3000592982016   # mediasize in bytes (2.7T)
    5860533168      # mediasize in sectors
    4096            # stripesize
    0               # stripeoffset

Aan de hand van beide gegevens (sectorsize, 'stripesize') en min/max auto ashift wordt dan de uiteindelijke ashift bepaald en dat gaat 99 van de 100 keer goed.

Embedded_data feature wordt standaard geactiveerd, behalve als je ZFSguru gebruikt die activeert enkel features die elke v5000 implementatie ondersteunt en laat je per feature bepalen of je die aan of uit wilt. Via de command line kan dit ook maar is wat omslachtig geloof ik. Vervelend is namelijk wel dat standaard alle features ingeschakeld worden en je pool dan ook gelijk niet meer bruikbaar is onder andere implementaties die misschien een feature missen, terwijl je die feature helemaal nog niet in gebruik hebt genomen (niet 'active' maar enkel 'enabled'). Dat vind ik zelf geen goede zet van OpenZFS working group.

[CurlyMo]

Verwijderd schreef op maandag 02 november 2015 @ 09:23:
Via de command line kan dit ook maar is wat omslachtig geloof ik.

Het is niet omslachtig maar vooral slecht gedocumenteerd. Je moet de pool eerst aanmaken als v28. Daarna handmatig de feature flags aanzetten die je wil gebruiken. Je pool zal dan nog steeds naar v5000 gaan, maar met alleen die feature flags aangezet die je zelf wil.

[Verwijderd]

Nee je kan hem direct als v5000 aanmaken, maar dan moet je bij het zpool create commando -o <feature> enablen. Dus je moet minimaal één feature inschakelen dan kun je hem direct als v5000 aanmaken.

Je hebt onder moderne BSD releases ook de -d parameter:

code:

         -d      Do not enable any features on the new pool.  Individual fea-
                 tures can be enabled by setting their corresponding proper-
                 ties to enabled with the -o option.  See zpool-features(7)
                 for details about feature properties.

Deze -d parameter is wel vrij nieuw en is niet beschikbaar op oudere BSD releases, dus ook niet onder FreeNAS volgens mij.

[ Voor 4% gewijzigd door Verwijderd op 02-11-2015 10:37 ]

[idef1x]

Compizfox schreef op zaterdag 31 oktober 2015 @ 21:13:
[...]

Dat hangt een beetje af van hoe je "volwassen" definieert. Zover ik weet, is ZoL zeker stabiel/volwassen genoeg voor normaal gebruik, maar ZFS op Solaris of FreeBSD is toch echt volwassener.

Hoe groot het verschil echt is, kan ik eigenlijk niet zoveel uitspraken over doen, want ik heb het zelf nog nooit geprobeerd. Ik baseer me voornamelijk op wat er hier in dit topic gezegd wordt, en als je sommigen (zoals CiPHER) mag geloven, is er nog steeds een aanzienlijk verschil in volwassenheid.

Wellicht dat een ieder de volwassen defnitie anders bekijkt en is misschien wel een eigen topic waard, maar ik vind het volwassen, wanneer je :
- je raidz(2,3) vdev kan maken welke beschermd tegen diskuitval en datacorruptie
- kan scrubben om silent corruptie tegen te gaan
- snapshots kan maken en rollbacks doen indien nodig
- voldoende performed (als in moet mijn ethernet link vol kunnen stouwen)
- stabiel als in dat systeem crashed niet oid en indien wel crashed (buiten zfs om) of na power off of wat dan ook dat je data nog wel veilig is

minder belangrijk voor mij:
- snapshots (incremental) send/receive naar ander systeem

Ja features zullen op ZoL achterlopen alsmede optimalisatie slagen (memory management bijvoorbeeld als CiPher aangeeft). Maar maken deze optimalisatie missers het systeem instabiel? Ik weet het niet, want daar heb ik geen verstand van. En welke features zou ZoL nog missen die men hard nodig heeft of zijn het features die "handig, prettig, whatever" zijn? Ook geen idee, want als ik ZFSGuru's mogelijkheden zie voor finetunen laat ik ze maar default staan, want ze zeggen me niets.
Afijn in het verleden heb ik een tijd met ZoL gedraaid en vond het volwassen genoeg, maar er ging ook niets verkeerds (geen diskuitval bijvoorbeeld) en weet dus nog niet hoe dat in de praktijk met ZoL (of freenas of nas4free of zfsguru of whatever) zal gaan.

Ik ben nog aan het nadenken voor mijn nieuwe NAS wat voor smaak ik ga draaien. Het gaat wel ZFS worden, ondanks dat bij mij btrfs momenteel ook stabiel oogt, maar ik wil nu een nas bouwen die rock solid is en daar voldoet btrfs helaas nog niet aan (in raid5/6) ben ik bang (als je zo de mailinglist volgt)..
Ik neig wel uiteindelijk naar een BSD variant te gaan, maar ben Debian/Ubuntu nu eenmaal gewend

Afijn genoeg offtopic denk ik

[Verwijderd]

idef1x schreef op maandag 02 november 2015 @ 11:19:
Wellicht dat een ieder de volwassen defnitie anders bekijkt en is misschien wel een eigen topic waard, maar ik vind het volwassen, wanneer je :
- je raidz(2,3) vdev kan maken welke beschermd tegen diskuitval en datacorruptie
- kan scrubben om silent corruptie tegen te gaan
- snapshots kan maken en rollbacks doen indien nodig
- voldoende performed (als in moet mijn ethernet link vol kunnen stouwen)
- stabiel als in dat systeem crashed niet oid en indien wel crashed (buiten zfs om) of na power off of wat dan ook dat je data nog wel veilig is

Met deze definitie (behalve misschien het laatste punt) was ZFS al 'volwassen' toen het nog in patches moest worden gecompileerd vóórdat FreeBSD 7.0 uitkwam. Sinds die tijd is ZFS lange tijd als 'experimental feature' aangeduid en kreeg je ook een melding bij het opstarten:

WARNING: ZFS is considered to be an experimental feature in FreeBSD.

Die melding is pas weggegaan nadat ZFS versie 14 is geïntegreerd in de stabiele releases van FreeBSD.

Kort genomen kun je denk ik stellen dat de BSD developers iets terughoudender zijn met het zomaar stabiel en 'production ready' verklaren van nieuwe technologie. En zeker voor iets als een filesystem is daar denk ik reden genoeg voor. Bedenk dat er best een aantal datacorruptie-bugs in ZFS hebben gezeten die pas later werden ontdekt en gefixed. Tijdje geleden nog een L2ARC corruptiebug die je hele pool kan slopen. Leuk. Gelukkig heeft deze bug alleen in FreeBSD-CURRENT gezeten dus niet in een -STABLE of -RELEASE branch. Maar toch.. En onder SmartOS platform is deze bug zelfs in de stabiele releases terecht gekomen. Zelfs in de LongTermSupport (LTS) versie zo meen ik mij te herinneren (bron: Gea van napp-it). Holy shyte!

Punt is dat een complex filesystem zoals ZFS gewoon risico's kent. Het grootste nadeel van ZFS is zijn complexiteit. En Jeff Bonwick, de lead developer van ZFS, ging er zelf prat op dat essentiële onderdelen van ZFS in een zo kleine footprint (qua aantal regels code) past. Dat geeft ook al aan dat het beperken van de complexiteit en aantal regels code heel belangrijk is voor een filesystem. Bedenk dat er ook behoorlijk wat corruptiebugs in Ext4 hebben gezeten toen deze in Ubuntu tot default filesystem werd gekozen, en dat dit enorm veel schade heeft veroorzaakt. Ext4 is dan een minieme uitbreiding van Ext3, wat een kleine uitbreiding is van Ext2 door de toevoeging van Journalling. En Ext2 is bijna gelijk aan UFS/FFS wat allemaal supersimpele filesystems zijn. Kortom, corruptiebugs in Ext4 is een grote waarschuwing voor corruptiebugs in véél complexere filesystems zoals ZFS, Btrfs en ReFS.

En welke features zou ZoL nog missen die men hard nodig heeft of zijn het features die "handig, prettig, whatever" zijn?

Qua pool features loopt ZoL echt niet zoveel achter. Laatst large_blocks en nog iets, maar inmiddels zit dat ook in de stabiele release.

Maar qua implementatie features zijn er wel veel verschillen. Geen device tasting maar een statische zpool.cache file wat user error kan veroorzaken: je ziet je pool als 'corrupted' met de melding de hele pool van backup te herstellen - lijkt me niet zo goed voor je hart . En verder zaken als gebrek aan TRIM, geen automatische detectie van sectorsize/ashift, veel minder goed geheugenmanagement en het feit dat je zelf moet rommelen met modules on-the-fly compileren.

Dat gezegd, het is allemaal prima bruikbaar. Maar volwassen is voor mij toch iets dat ik reserveer voor iets wat toch minimaal een paar jaar zonder grote incidenten heeft gefunctioneerd - dat lijkt mij de absolute ondergrens van iets 'volwassen' noemen. En een paar maanden terug was er een incident dat bij een casual Ubuntu 'apt-get update' je je pool niet meer kunt importeren. Dan ben je niet gelijk alles kwijt, gelukkig niet. Maar dat soort ongein mag je niet verwachten van iets wat als 'volwassen' te boek staat.

Afijn in het verleden heb ik een tijd met ZoL gedraaid en vond het volwassen genoeg, maar er ging ook niets verkeerds (geen diskuitval bijvoorbeeld) en weet dus nog niet hoe dat in de praktijk met ZoL (of freenas of nas4free of zfsguru of whatever) zal gaan.

Ja, hier wil ik ook voor waarschuwen. Bij ZFS gaat alles perfect en werkt het zonder problemen - TOTDAT er zich problemen voordoen en dan is er gelijk stront aan de knikker. De failure modes zijn dus heel binair: òf het werkt uitstekend òf je hebt gelijk vrij grote problemen waar je zelf niet uitkomt of dat je je hele pool kwijt bent zoals met de L2ARC corruptiebug.

Juist omdat ZFS zo complex is en thuisgebruikers vaak afwijken van de paden die ontwikkelaars veelvuldig bewandelen, kun je best wel eens gebeten worden door een lelijke bug. We moeten ons realiseren dat de complexiteit gewoon de grootste vijand is van moderne opslagsystemen als ZFS.

Afijn genoeg offtopic denk ik

Volgens mij valt dat wel mee?

[idef1x]

Verwijderd schreef op maandag 02 november 2015 @ 11:38:
[...]

Kort genomen kun je denk ik stellen dat de BSD developers iets terughoudender zijn met het zomaar stabiel en 'production ready' verklaren van nieuwe technologie. En zeker voor iets als een filesystem is daar denk ik reden genoeg voor. Bedenk dat er best een aantal datacorruptie-bugs in ZFS hebben gezeten die pas later werden ontdekt en gefixed. Tijdje geleden nog een L2ARC corruptiebug die je hele pool kan slopen. Leuk. Gelukkig heeft deze bug alleen in FreeBSD-CURRENT gezeten dus niet in een -STABLE of -RELEASE branch. Maar toch.. En onder SmartOS platform is deze bug zelfs in de stabiele releases terecht gekomen. Zelfs in de LongTermSupport (LTS) versie zo meen ik mij te herinneren (bron: Gea van napp-it). Holy shyte!

Hmmm las laatst van iemand die lyrish was over smartos...

Maar qua implementatie features zijn er wel veel verschillen. Geen device tasting maar een statische zpool.cache file wat user error kan veroorzaken: je ziet je pool als 'corrupted' met de melding de hele pool van backup te herstellen - lijkt me niet zo goed voor je hart . En verder zaken als gebrek aan TRIM, geen automatische detectie van sectorsize/ashift, veel minder goed geheugenmanagement en het feit dat je zelf moet rommelen met modules on-the-fly compileren.

Device tasting? Of testing? Hoe dan ook nee een backup terug moeten zetten melding is niet goed voor mijn hart Maarre gebrek aan TRIM? Je kunt toch prima onder Linux met fstrim je SSD trimmen, of heeft zfs nog iets speciaals hiervoor? Die automatische detectie van sector/ashift is op zich maar een eenmalig iets voor wanneer je je vdev aanmaakt, dus zou dat niet als een belemmering zien (moet je wel weten/aan denken natuurlijk )
Dat "rommelen met modules on the fly compileren" begrijp ik ook niet. Je hoeft tegenwoordig slechts een ppa toe te voegen (ubuntu) of een .deb van de zfsonlinux site te plukken voor Debian en dan is het een kwestie van install en gaan met die banaan.

En een paar maanden terug was er een incident dat bij een casual Ubuntu 'apt-get update' je je pool niet meer kunt importeren. Dan ben je niet gelijk alles kwijt, gelukkig niet. Maar dat soort ongein mag je niet verwachten van iets wat als 'volwassen' te boek staat.

krijg het idee dat ubuntu daar inderdaad wel eens een handje van heeft en zou dan ook eerder Debian voor ZoL nemen dan buntu

Juist omdat ZFS zo complex is en thuisgebruikers vaak afwijken van de paden die ontwikkelaars veelvuldig bewandelen, kun je best wel eens gebeten worden door een lelijke bug. We moeten ons realiseren dat de complexiteit gewoon de grootste vijand is van moderne opslagsystemen als ZFS.

Gebeten door een lelijke bug word je toch wel eens...Heb al eens (honderd jaar geleden ) al mijn (gescande) foto's met een 0 byte grootte gezien dat ik een "he wat vervelend nou" (heeel zacht uitgedrukt) momentje had, daar ik toen nog net geen backup had

Volgens mij valt dat wel mee?

Nou ja het ging nu meer om ZoL specifiek en de definitie van volwassen dan over ZFS zelf

[FireDrunk]

Goed, nu moet ik echt maar even reageren

Verwijderd schreef op maandag 02 november 2015 @ 11:38:
Maar qua implementatie features zijn er wel veel verschillen. Geen device tasting

Er is genoeg device tasting, het is alleen niet de *default*... De linux kernel zit vol met device tasting, en de ZoL code ook. Enige, wat niet goed werkt is pools aanmaken op raw devices die in /dev/ staan (ipv in /dev/disk/*).

maar een statische zpool.cache file

Nogmaals, de *default*, niet de enige optie. Je kan dat ding gewoon weggooien, en er zijn /etc/defaults/zfs opties om het gebruik van dat ding te minimaliseren.

wat user error kan veroorzaken: je ziet je pool als 'corrupted' met de melding de hele pool van backup te herstellen - lijkt me niet zo goed voor je hart .

Production ready betekend bij mij: Een enterprise kan er veilig op vertrouwen. Er zijn in BSD nog *veel* meer zaken buiten ZFS die gevoelig zijn voor user-error (zoals mergemaster?).
Dus een hele implementatie afmatten omdat het niet production ready is, heeft *niets* te maken met user-error... Juist systemen die production ready zijn, zijn soms het moeilijkst te installeren.

En verder zaken als gebrek aan TRIM,

Ok, daar zijn ze nog mee bezig

geen automatische detectie van sectorsize/ashift

Uh, ze hebben de keuze gemaakt om een kort lijstje bij te houden van schijven die echt 4K zijn, maar toch 512bytes presenteren (zoals bijna alle schijven), en daar vanuit te gaan. Zit zorgt er voor dat je geen vieze geom hacks hoeft te doen zoals bij BSD

, veel minder goed geheugenmanagement

Dat is ook een beetje verdraaien van de werkelijkheid... Omdat ZFS (nog) geen toegang heeft tot het core kernel geheugen management, doet de Linux kernel (voor een paar onderdelen) nog intelligent caching. (vooral ZVOL's). Dat heeft weinig met de implementatie zelf te maken, maar meer met dat ZFS wat minder goed past in een OS wat al heel erg intensief zelf zijn geheugen managed.

Het is een tradeoff tussen een implementatie in een Applicatielaag te doen (meer controle) en in je OS (stabiele implementatie, meer overzicht, efficienter).

Die botsen gewoon. Dus het werkt vooral anders... Maar om nou te zeggen dat het *slecht* is...

en het feit dat je zelf moet rommelen met modules on-the-fly compileren.

Dat is echt kletskoek. Je hoeft nooit zelf make ofzo in te typen.

het is voor 99% geautomatiseerd, alleen de *trigger* om een recompile uit te voeren na een nieuwe kernel installatie (via yum of apt, oh wacht, dat heeft BSD niet eens ) gaat niet goed af in sommige specifieke gevallen..

Het is een beetje als, oh, ik heb mijn kernel geupdatet, nu moet ik even een applicatie updaten om het weer werkend te maken. Goh, dat gebeurt zeg maar in *elk* OS wel eens...

Desalniettemin zal ik niet meteen roepen dat ZoL *wel* production ready is... Maar dat heeft weinig te maken met de redenen die jij noemt.

Als je gewoon kijkt op de issuetracker op ZoL, zijn er gewoon nog meer regressiefouten dan op BSD. Simple as that... Ik denk dat hetzelfde geld voor ZFS als voor BTRFS.

In de meest simpele vorm zijn beide production ready (mirrors / raid1).

Hoe meer ingewikkelde features je hier aan toevoegt, hoe meer je het risico gaat lopen dat je minder goed geteste code gaat raken.

Ik zou zeggen: Zowel ZFS als BTRFS zijn onder Linux prima production ready te gebruiken, mits je niet de latest bleeding edge features gebruikt.

[raymonvdm]

Ik heb al een tijdje niks meer gedaan met ZFS (blijkbaar werkt het gewoon goed) maar ik heb nog wel het volgende probleem

code:

[root@freenas01] ~# zpool status tank
  pool: tank
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
    Expect reduced performance.
action: Replace affected devices with devices that support the
    configured block size, or migrate data to a properly configured
    pool.
  scan: scrub repaired 0 in 14h32m with 0 errors on Sun Nov  1 14:32:17 2015
config:

    NAME                                            STATE     READ WRITE CKSUM
    tank                                            ONLINE       0     0     0
      raidz2-0                                      ONLINE       0     0     0
        gptid/d9eec012-9605-11e0-bcc9-000c291d64cc  ONLINE       0     0     0  block size: 512B configured, 4096B native
        gptid/da4c91cc-9605-11e0-bcc9-000c291d64cc  ONLINE       0     0     0  block size: 512B configured, 4096B native
        gptid/daaa9fcf-9605-11e0-bcc9-000c291d64cc  ONLINE       0     0     0  block size: 512B configured, 4096B native
        gptid/db0931b0-9605-11e0-bcc9-000c291d64cc  ONLINE       0     0     0  block size: 512B configured, 4096B native
        da0                                         ONLINE       0     0     0  block size: 512B configured, 4096B native
        da1                                         ONLINE       0     0     0  block size: 512B configured, 4096B native

errors: No known data errors
[root@freenas01] ~#

Ik ben ooit begonnen met een ZFS machine binnen VMWare met een RawDevice mapping en hierdoor heb ik vermoedelijk een blocksize van 512. Maar hoe kan ik dit nu oplossen, moet ik inderdaad de pool opnieuw maken?

http://blog.davidwarburto...al-sata-storage-for-esxi/

[Compizfox]

FireDrunk schreef op maandag 02 november 2015 @ 13:51:
Production ready betekend bij mij: Een enterprise kan er veilig op vertrouwen. Er zijn in BSD nog *veel* meer zaken buiten ZFS die gevoelig zijn voor user-error (zoals mergemaster?).

Kleine aantekening: als je FreeBSD op de binary manier upgradet (dus met freebsd-update), hoef je geen mergemaster te draaien. (het kan zelfs niet)

Ik heb wel eens wat handmatig moeten mergen (en dat is inderdaad kut), maar dat is tot dusver alleen voorgekomen onder ZFSGuru. Bij het upgraden van vanilla FreeBSD heb ik dat nog nooit gehad.

---

raymonvdm schreef op maandag 02 november 2015 @ 15:51:
Ik ben ooit begonnen met een ZFS machine binnen VMWare met een RawDevice mapping en hierdoor heb ik vermoedelijk een blocksize van 512. Maar hoe kan ik dit nu oplossen, moet ik inderdaad de pool opnieuw maken?

http://blog.davidwarburto...al-sata-storage-for-esxi/

Als je physical RDM hebt gebruikt, zou dat geen invloed moeten hebben gehad op de sectorsize. Of gebruikte je virtual RDM?

[raymonvdm]

Ik heb waarschijnlijk virtual RDM gebruikt. Hij maakt dan van de disk een apparte datastore die niet naar File schrijft maar naar de disk. Die datastore zal toen met 512k sector size aangemaakt zijn.

[FREAKJAM]

Iemand hier RancherOS toevallig al eens getest? Minimaal OS om docker's te draaien. Afgelopen week is versie 0.4.0 uitgekomen welke beschikt over ZFS-support.

[zwittrooper]

Ik heb net mijn server herstart en zie nu een boel fouten van ZFS langskomen bij het opstarten. Ik gebruik zfsonlinux met een Ubuntu server. Is dit een indicatie dat een hardeschijf kapot aan het gaan is? Het benaderen van bestanden gaat nu ook heel langzaam. Als ik deze hardeschijf offline zet is er niks aan de hand en werkt het weer snel.

code:

Nov  6 16:47:18 server kernel: [23538.954789] ata3.00: exception Emask 0x0 SAct 0x20000 SErr 0x0 action 0x0
Nov  6 16:47:18 server kernel: [23538.963734] ata3.00: irq_stat 0x40000008
Nov  6 16:47:18 server kernel: [23538.972574] ata3.00: failed command: READ FPDMA QUEUED
Nov  6 16:47:18 server kernel: [23538.980782] ata3.00: cmd 60/e0:88:20:08:00/00:00:00:00:00/40 tag 17 ncq 114688 in
Nov  6 16:47:18 server kernel: [23538.980782]          res 41/40:00:20:08:00/00:00:00:00:00/40 Emask 0x409 (media error) <F>
Nov  6 16:47:18 server kernel: [23538.990227] ata3.00: status: { DRDY ERR }
Nov  6 16:47:18 server kernel: [23538.994963] ata3.00: error: { UNC }
Nov  6 16:47:18 server kernel: [23539.012141] ata3.00: configured for UDMA/133
Nov  6 16:47:18 server kernel: [23539.012154] sd 2:0:0:0: [sdc] Unhandled sense code
Nov  6 16:47:18 server kernel: [23539.012156] sd 2:0:0:0: [sdc]
Nov  6 16:47:18 server kernel: [23539.012157] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov  6 16:47:18 server kernel: [23539.012158] sd 2:0:0:0: [sdc]
Nov  6 16:47:18 server kernel: [23539.012159] Sense Key : Medium Error [current] [descriptor]
Nov  6 16:47:18 server kernel: [23539.012161] Descriptor sense data with sense descriptors (in hex):
Nov  6 16:47:18 server kernel: [23539.012162]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Nov  6 16:47:18 server kernel: [23539.012166]         00 00 08 20
Nov  6 16:47:18 server kernel: [23539.012168] sd 2:0:0:0: [sdc]
Nov  6 16:47:18 server kernel: [23539.012170] Add. Sense: Unrecovered read error - auto reallocate failed
Nov  6 16:47:18 server kernel: [23539.012171] sd 2:0:0:0: [sdc] CDB:
Nov  6 16:47:18 server kernel: [23539.012172] Read(10): 28 00 00 00 08 20 00 00 e0 00
Nov  6 16:47:18 server kernel: [23539.012176] end_request: I/O error, dev sdc, sector 2080
Nov  6 16:47:18 server kernel: [23539.016831] ata3: EH complete

Zfs geeft ook aan dat er een meerdere checksum errors zijn bij die hardeschijf:

code:

 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-9P
  scan: scrub in progress since Fri Nov  6 10:18:31 2015
    275G scanned out of 5.35T at 12.0M/s, 123h31m to go
    476K repaired, 5.01% done
config:

        NAME                                        STATE     READ WRITE CKSUM
        datastore                                   ONLINE       0     0     0
          raidz1-0                                  ONLINE       0     0     0
            ata-ST2000DM001-1CH164_Z1E5JG0T         ONLINE       0     0     0
            ata-SAMSUNG_HD204UI_S2H7JX0C200164      ONLINE       0     0     5  (repairing)
            ata-ST2000DM001-1CH164_Z1E5JG0W         ONLINE       0     0     0
            ata-ST2000DL004_HD204UI_S2H7JX0D100352  ONLINE       0     0     0

errors: No known data errors

[Verwijderd]

Begin eens bij de SMART?

[zwittrooper]

Verwijderd schreef op vrijdag 06 november 2015 @ 18:52:
Begin eens bij de SMART?

Volgens mij ziet de smart er nog aardig goed uit. Ik zie alleen een paar pending sectors, maar geen uncorrectable sectors. Ook niet na meerdere reboots. Het gaat trouwens om een 2TB schijf.

code:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   051    Pre-fail  Always       -       4902
  2 Throughput_Performance  0x0026   252   252   000    Old_age   Always       -       0
  3 Spin_Up_Time            0x0023   066   065   025    Pre-fail  Always       -       10436
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       100
  5 Reallocated_Sector_Ct   0x0033   252   252   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   252   252   051    Old_age   Always       -       0
  8 Seek_Time_Performance   0x0024   252   252   015    Old_age   Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       31381
 10 Spin_Retry_Count        0x0032   252   252   051    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   252   252   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       107
181 Program_Fail_Cnt_Total  0x0022   099   099   000    Old_age   Always       -       22151362
191 G-Sense_Error_Rate      0x0022   100   100   000    Old_age   Always       -       32
192 Power-Off_Retract_Count 0x0022   252   252   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0002   056   045   000    Old_age   Always       -       44 (Min/Max 12/55                                             )
195 Hardware_ECC_Recovered  0x003a   100   100   000    Old_age   Always       -       0
196 Reallocated_Event_Count 0x0032   252   252   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0030   252   252   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0036   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x002a   100   100   000    Old_age   Always       -       4
223 Load_Retry_Count        0x0032   252   252   000    Old_age   Always       -       0
225 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       107

[Verwijderd]

Dat ziet er dus niet goed uit want je hebt pending sectors - dus actieve bad sectors. Dat is zeer waarschijnlijk de oorzaak van je probleem. Je dient de scrub af te ronden en te kijken of de Current Pending Sectors verandert. Hij mag in geen geval toenemen.

Offline Uncorrectable is hetzelfde als Current Pending Sector, maar wordt niet continu geupdate - maar slechts sporadisch. Dat zie je ook bij UPDATED kolom; always is 'online' en Offline is 'offline'.

Opzich heb je bij redundante pools geen problemen met bad sectors, maar je kunt wel vertragingen ervaren. Zorg dat je de scrub afrondt, dan zou het probleem opgelost moeten zijn. Doe meerdere scrubs na elkaar en controleer de Current Pending Sector waarde.

Blijf je problemen houden, overweeg dan je schijf uit de pool te halen met zpool offline <poolname> <diskname> en daarna de disk te zero-writen met dd-commando, daarna weer toe te voegen aan de pool met zpool replace <poolname> <olddisk> <newdisk>. De oude disk heeft dan een nummer gekregen zoals 485837849759878947.

[zwittrooper]

Verwijderd schreef op vrijdag 06 november 2015 @ 21:18:
Dat ziet er dus niet goed uit want je hebt pending sectors - dus actieve bad sectors. Dat is zeer waarschijnlijk de oorzaak van je probleem. Je dient de scrub af te ronden en te kijken of de Current Pending Sectors verandert. Hij mag in geen geval toenemen.

Offline Uncorrectable is hetzelfde als Current Pending Sector, maar wordt niet continu geupdate - maar slechts sporadisch. Dat zie je ook bij UPDATED kolom; always is 'online' en Offline is 'offline'.

Opzich heb je bij redundante pools geen problemen met bad sectors, maar je kunt wel vertragingen ervaren. Zorg dat je de scrub afrondt, dan zou het probleem opgelost moeten zijn. Doe meerdere scrubs na elkaar en controleer de Current Pending Sector waarde.

Blijf je problemen houden, overweeg dan je schijf uit de pool te halen met zpool offline <poolname> <diskname> en daarna de disk te zero-writen met dd-commando, daarna weer toe te voegen aan de pool met zpool replace <poolname> <olddisk> <newdisk>. De oude disk heeft dan een nummer gekregen zoals 485837849759878947.

Okee, hartelijk bedankt voor de informatie. Ik wacht nog even totdat de scrub klaar is en kijk wat de waarden dan zijn, maar ik denk dat het een nieuwe schijf zal moeten worden.

[FireDrunk]

Dat is misschien wat voorbarig. Kijk eens of je de disk vol kan schrijven, en of dan de pending sectors weg gaan in reallocated.

[Verwijderd]

Juist voor ZFS hoef je echt niet te trippen om een paar bad sectors. Een nieuwe schijf heeft in principe hetzelfde probleem, want consumentenschijven worden met uBER 10^-14 specificatie verkocht. Dat betekent in het slechtste geval één bad sector per dag, ook als de schijf fysiek prima in orde is.

Dat kun je verifiëren doordat de Current Pending Sectors verdwijnen (raw value = 0) terwijl het aantal omgewisselde sectoren (Reallocated Sector Count) blijft steken op 0. In dat geval is dat gewoon een gevalletje uBER en daarom heb je nu juist ZFS en geen legacy filesystem. Wel is het zo dat je wat vertraging kunt merken als er zich bad sectors voordoen.

Behalve de scrub kun je een zero write overwegen. Dan hoor je van het probleem af te zijn.

[jjust]

Ik draai ZFS guru in een VM met een IBM 1115. Nu heb ik een z1 pool met 3 * 4TB Seagate ST4000DM000.

Nu kom ik ruimte te kort. De vraag is hoe dit op te lossen. De 6TB schijven vind ik eigenlijk nog wat aan de prijs. Ik heb niet heel veel extra ruimte nodig dus ik kan er een z1 pool naast zetten van 3 * 4TB. Dit is misschien zonde van de beschikbare poorten en is het slimmer om gelijk 5*4TB te doen.

Iemand nog betere ideeën?

[GioStyle]

Je data ergens parkeren en een raidz2 van 6 schijven maken? Dat is beter dan 2 vdev's van raidz1.

[jjust]

Dat is natuurlijk wel beter maar data ergens parkeren wordt wel een uitdaging.

Ik weet niet of het kan maar zou eventueel een z2 van 6 schijven degraded met 5 schijven kunnen draaien, data overzetten en daarna nr 6 toevoegen. Dan heb ik alleen tijdelijk 2 * 4TB extra nodig die ik uiteindelijk over hou. Al met al kiezen uit sub optimale oplossingen.

[GioStyle]

Ik heb zelf een pool van 6 disks raidz2 geüpgraded naar 10 disks raidz2 met 2 disks degraded. 't Zou kunnen, maar fijn is het niet. Ik had voor de zekerheid wel nog ergens een backup gemaakt.

[ Voor 4% gewijzigd door GioStyle op 08-11-2015 10:05 ]

[BCC]

Il heb voor zoiets dergelijks laatst een transip vpsje gehuurd + een aantal TB blockdevice ruimte. Met zol kun je hier zo ZFS van maken en dan een snapshot van je data oversturen. Als er iets mis gaat met schijven shuffelen dan kun je zo weer alles terug zetten.

[ Voor 0% gewijzigd door BCC op 13-11-2015 09:51 . Reden: autocorrect :) ]

[jjust]

Dat is een goede tip. Zal ik eens naar kijken.

[renedis]

Weet iemand hoe het kan waarom ik geen mirror kan instellen bij FreeNAS?




Heb een M1015 controller met firmware 20 er op staan, maar helaas

[Pantagruel]

jjust schreef op zondag 08 november 2015 @ 09:02:
Dat is een goede tip. Zal ik eens naar kijken.

2 TB voor €10,- per maand staat op de site, als je meer wilt zul je ze moeten e-mailen voor een prijsopgave lijkt me. De enige echte beperking zal je upload snelheid zijn.

[Compizfox]

renedis schreef op dinsdag 10 november 2015 @ 10:40:
Weet iemand hoe het kan waarom ik geen mirror kan instellen bij FreeNAS?

[afbeelding]


Heb een M1015 controller met firmware 20 er op staan, maar helaas

Ik ben niet echt bekend met FreeNAS, maar het lijkt erop dat je geen partities aan een vdev aan het toevoegen bent, maar vdevs aan een pool. Meerdere vdevs binnen een pool worden altijd gestriped, tenzij je hem toevoegt als SLOG of L2ARC natuurlijk (wat dan ook de overige beschikbare opties zijn).

Ik denk niet dat dit iets met je controller te maken heeft.

[ Voor 4% gewijzigd door Compizfox op 10-11-2015 11:04 ]