Het grote ZFS topic

[DjCoke]

Thanks voor deze script. Dat ziet er goed uit!

[secretdk]

Hoe groot is de kans dat een rebuild faalt bij een 4x 3 TB RAID-Z array?

[FireDrunk]

50%, hij kan wel falen of niet...


Maar serieus, dat kan niemand voorspellen, dat is van teveel factoren afhankelijk.

[HyperBart]

DjCoke schreef op zaterdag 02 mei 2015 @ 10:32:
Thanks voor deze script. Dat ziet er goed uit!

Allemaal CurlyMo zijn werk, mij komt niks toe.

FireDrunk schreef op zaterdag 02 mei 2015 @ 20:23:
50%, hij kan wel falen of niet...


Maar serieus, dat kan niemand voorspellen, dat is van teveel factoren afhankelijk.

Der is der ene boel aant zoeken met tvwes

[ Voor 41% gewijzigd door HyperBart op 02-05-2015 20:29 ]

[HyperBart]

Ik weet niet hoeveel animo er is voor dit soort dingen, maar ik ben in de namiddag op dit (onafgewerkte) juweeltje gestoten.

https://github.com/damicon/zfswatcher

Ik heb het op dezelfde test machine gezet als waar ik het backup script van CurlyMo heb op draaien.

zfswatcher ziet er wel leuk uit, het biedt de meest basale (read-only) functionaliteit (namelijk statistiekjes over je pool, de status er van, en that's it) en daarnaast ook notifications als er iets misloopt...

Jammer dat het project blijkbaar al 2 jaar stil ligt...

[Jack Flushell]

Ik heb 4 (gelijke) 2TB harddisks. Meer passen niet in het systeem. Het liefst zou ik voor RAIDZ2 gaan, maar dan moet je eigenlijk 6 of meer disks hebben. Ik vind RAIDZ1 geen optie, te onveilig, dus dan kom je uit bij mirroring, me dunkt (toch?), want ik wil graag een systeem met enige redundancy.

Ik twijfel tussen:

1 mirror, nadeel: je hebt maar de capaciteit van 1 disk...

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    sde     ONLINE       0     0     0
	    sdf     ONLINE       0     0     0
	    sdg     ONLINE       0     0     0
	    sdh     ONLINE       0     0     0

2-way mirror: voordeel: je hebt de capaciteit van 2 disks

NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    sde     ONLINE       0     0     0
	    sdf     ONLINE       0     0     0
	  mirror-1  ONLINE       0     0     0
	    sdg     ONLINE       0     0     0
	    sdh     ONLINE       0     0     0

Het systeem is een fileserver (samba en nfs) om verschillende apparaten in huis te voorzien van films en muziek. Er komt een SSD voor l2arc en het OS boot vanaf een andere SSD.

Is de 2e aan te raden, of eigenlijk toch nog erg onveilig? Of zouden jullie met deze config iets anders doen? Meer harddisks is geen optie. NB ik ga daarnaast uiteraard ook nog backups maken.

[ Voor 5% gewijzigd door Jack Flushell op 03-05-2015 13:52 ]

[HyperBart]

Ik vind het best wel netjes van je dat je mirrors overweegt.

Met backups heb ik zoiets van: doe een RAIDZ. Bij mij is de paranoia nu toegeslagen en bij de volgende upgrade ga ik over naar RAIDZ2... Met 4tb disks that is.

[tvwes]

Jack Flushell schreef op zondag 03 mei 2015 @ 13:42:
Ik heb 4 (gelijke) 2TB harddisks. Meer passen niet in het systeem. Het liefst zou ik voor RAIDZ2 gaan, maar dan moet je eigenlijk 6 of meer disks hebben.

Nee, je hebt N+2 disks nodig. Al zijn configuraties onder de 5 disk beter niet als RAIDZ2 in te richten. Dus 5 en meer.

Ik vind RAIDZ1 geen optie, te onveilig, dus dan kom je uit bij mirroring, me dunkt (toch?), want ik wil graag een systeem met enige redundancy.

Ik twijfel tussen:

1 mirror, nadeel: je hebt maar de capaciteit van 1 disk...

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    sde     ONLINE       0     0     0
	    sdf     ONLINE       0     0     0
	    sdg     ONLINE       0     0     0
	    sdh     ONLINE       0     0     0

2-way mirror: voordeel: je hebt de capaciteit van 2 disks

NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    sde     ONLINE       0     0     0
	    sdf     ONLINE       0     0     0
	  mirror-1  ONLINE       0     0     0
	    sdg     ONLINE       0     0     0
	    sdh     ONLINE       0     0     0

Het systeem is een fileserver (samba en nfs) om verschillende apparaten in huis te voorzien van films en muziek. Er komt een SSD voor l2arc en het OS boot vanaf een andere SSD.

Is de 2e aan te raden, of eigenlijk toch nog erg onveilig? Of zouden jullie met deze config iets anders doen? Meer harddisks is geen optie. NB ik ga daarnaast uiteraard ook nog backups maken.

Optie 1 is wel heel erg over the top. Dat zijn 3 extra copien. De kans op een andere failure mode is veel groter, als brand en ander ongemak als elektrische overspanning. Je bent echt nergens zonder een backup. Je moet de redundancy meer zien als een middel om de beschikbaarheid van de data te vergroten. De vraag zou moeten zijn hoe lang kost het mij om mijn NAS weer in optimale toestand te krijgen? Afhankelijk van de failure mode hangen daar verschillende tijden aan, varierend van een complete nieuwe bestellen, inrichten en backup terug zetten tot een paar uur bij het resilveren van een hotspare.
Als je weinig poorten en budget hebt maar wel een echte backup en de downtime (van misschien wel dagen) niet erg is dan zou ik voor RAIDZ1 gaan. Veel opslag voor weinig geld, gaat het mis dan moet je de backup terug zetten.
Heb je meer poorten en budget, en natuurlijk nog steeds de backup, dan kan je ook RAIDZ2 overwegen. De MTTDL neemt enorm toe maar je hebt minder opslag bij hetzelfde aantal schijven.

Alles kan en mag, het is een persoonlijke afweging.
Veel opslag, betrouwbaar, goedkoop. Je mag er twee kiezen.

PS Ik gebruik meestal mirrors. Kost wat maar de performance is top en de rebuild tijd is veel korter dan bij RAIDZx.

[Jack Flushell]

tvwes schreef op zondag 03 mei 2015 @ 14:20:
[...]
PS Ik gebruik meestal mirrors. Kost wat maar de performance is top en de rebuild tijd is veel korter dan bij RAIDZx.

Dank voor het uitgebreide antwoord... Jij zou dan dus eerder voor optie 2 gaan (2-way mirror) (of RAIDZx met de beschreven overwegingen)?

[tvwes]

Jack Flushell schreef op zondag 03 mei 2015 @ 14:30:
[...]


Dank voor het uitgebreide antwoord... Jij zou dan dus eerder voor optie 2 gaan (2-way mirror) (of RAIDZx met de beschreven overwegingen)?

@Jack Flushell,
inderdaad een enkele keer gebruik ik voor het werk wel eens een 3-way mirror, maar meestal 2-way. Je moet even terug lezen in dit topic maar een week of wat heb ik al uitgelegd dat je qua betrouwbaarheid beter af bent met meer vdevs dan minder vdevs dit bij een gelijk totaal aantal schijven en dezelfde pariteit. 10 disks in een enkel raidz2 is minder betrouwbaar dan 2 raidz2 vdevs met elk 5 disks.
Zelf gebruik ik mirrors puur voor de performance, het aantal random iops schaalt lineair met het aantal vdevs. En bij mirrors worden reads gestriped, dus zelfs met harddisken kan je dan redelijke prestaties halen. Vraag maar eens aan @HyperBart, die heb ik laatste een benckmark laten zien van 2x2 5400rpm Samsung 204UI disks. Hij was behoorlijk onder de indruk geloof ik.
Ik weet niet hoeveel poorten je hebt maar als je maar zes poorten hebt dan zou ik kijken of je het OS op een goede usb stick kan zetten. Ik verwacht niet je heel veel gaat doen met je OS. En die L2ARC zou ik ook heroverwegen. Kijk eerst eens hoe het gaat zonder, als het allemaal normaal draait kijk dan na een week naar je arcstats. Zie je daar een extreme hoeveelheid cache misses dan kan je een L2ARC proberen. Maar voor thuis en zeker voor media toepassingen is het bijna altijd zonde van het geld en de poort. Stop dat geld liever in een goed mobo (lees iets met ecc) en zoveel mogelijk ram. Daar zit de grootste winst.

[Mr Alfabet]

Ik probeer om permissies te zetten op mijn datapool zodat ik ook als niet-root de status kan checken, echter wil het commando een dataset als argument, en ik heb alleen een poolnaam.

Het commando wat ik uitvoer:

code:

zfs allow list user1 datatank

Wat ik dan krijg:

code:

cannot set permissions on 'datatank': operation not applicable to datasets of this type

Weet iemand hoe ik dit op kan lossen?

Dit is overigens de output van zfs list:

code:

root@bacchus:/data# zfs list
NAME         USED  AVAIL  REFER  MOUNTPOINT
backuptank  1,35T   448G  1,35T  /backup
datatank    13,1T  7,38T  13,1T  /data

[ Voor 3% gewijzigd door Mr Alfabet op 03-05-2015 16:47 ]

[tvwes]

Mr Alfabet schreef op zondag 03 mei 2015 @ 16:45:
Ik probeer om permissies te zetten op mijn datapool zodat ik ook als niet-root de status kan checken, echter wil het commando een dataset als argument, en ik heb alleen een poolnaam.

Het commando wat ik uitvoer:

code:

zfs allow list user1 datatank

Wat ik dan krijg:

code:

cannot set permissions on 'datatank': operation not applicable to datasets of this type

Weet iemand hoe ik dit op kan lossen?

Dit is overigens de output van zfs list:

code:

root@bacchus:/data# zfs list
NAME         USED  AVAIL  REFER  MOUNTPOINT
backuptank  1,35T   448G  1,35T  /backup
datatank    13,1T  7,38T  13,1T  /data

Welk OS gebruik je? Voor zover mij bekend is list niet een permissie die je kan zetten. Check dit via man zfs bijna onderaan bij zfs allow.
Ik vermoed dat de gebruiker nu al zfs list mag uitvoeren.
Heb je in een andere terminal als user1 zfs list geprobeerd?

[ Voor 18% gewijzigd door tvwes op 03-05-2015 17:15 ]

[Mr Alfabet]

tvwes schreef op zondag 03 mei 2015 @ 17:00:
[...]

Welk OS gebruik je? Voor zover mij bekend is list niet een permissie die je kan zetten. Check dit via man zfs bijna onderaan bij zfs allow.
Ik vermoed dat de gebruiker nu al zfs list mag uitvoeren.
Heb je in een andere terminal als user1 zfs list geprobeerd?

Ik gebruik Ubuntu 14.04 LTS, maar het het inmiddels al opgelost:

Oude permissies voor /dev/zfs:

code:

crw-------  1 root root  10,  57 mei  2 23:19 zfs

Nieuwe groep zfsadmin aangemaakt, nieuwe permissies:

code:

crw-rw----  1 root zfsadmin  10,  57 mei  2 23:19 zfs

En dan natuurlijk de users member maken van zfsadmin group.

[tvwes]

Mr Alfabet schreef op zondag 03 mei 2015 @ 17:28:
[...]

Ik gebruik Ubuntu 14.04 LTS, maar het het inmiddels al opgelost:

Oude permissies voor /dev/zfs:

code:

crw-------  1 root root  10,  57 mei  2 23:19 zfs

Nieuwe groep zfsadmin aangemaakt, nieuwe permissies:

code:

crw-rw----  1 root zfsadmin  10,  57 mei  2 23:19 zfs

En dan natuurlijk de users member maken van zfsadmin group.

Nu weet ik weinig van ZoL maar dit is iets heel anders dan zfs allow [perm] [principal] [dataset].
Fijn dat het is opgelost.

[Mr Alfabet]

tvwes schreef op zondag 03 mei 2015 @ 17:49:
[...]

Nu weet ik weinig van ZoL maar dit is iets heel anders dan zfs allow [perm] [principal] [dataset].
Fijn dat het is opgelost.

Dat is het inderdaad, het enige wat ik wilde is elke user 'zpool status' kunnen laten doen.

[tvwes]

Mr Alfabet schreef op zondag 03 mei 2015 @ 18:08:
[...]

Dat is het inderdaad, het enige wat ik wilde is elke user 'zpool status' kunnen laten doen.

Apart dat je dat niet als gewone gebruiker kan bij ZoL. Het is zeker niet iets van ZFS want daar maakt dit recht geen onderdeel uit van de codebase. Ik zal zometeen even mijn ubuntu crusty erbij pakken en dit met eigen ogen aanschouwen. TBC...

[FireDrunk]

Die chmod / chown is idd de goede oplossing, maar die is als het goed is niet persistent bij een reboot.

http://blog.gjpvanwesten....s-virtual.html#userrights

Hier een random voorbeeldje hoe je dat met udev regelt.

[jvhaarst]

@tvwes

Ik heb het expres kort gehouden, die info leek me niet zo relevant.

Maar omdat je er om vraagt, dan geef ik het graag :
Het systeem is in gebruik als scratch space, voor opslag van tussen resultaten van bioinformatica analyses.
Dat vreet nogal wat ruimte, vandaar de redelijke grootte.

De id's zijn zo hoog, omdat op de servers waar de analyses op draaien, we in loggen met gegevens uit de Active Directory, dan hoef ik niet voor iedere user op alle machines users en wachtwoorden te regelen.

De user (ik dus) gebruikt ruimte (in bytes):

code:

sysop@scratch:/scratch/data/haars001$ sudo find . -type f -uid 16825946 -exec stat --format=%s {} \; | awk '{ SUM += $1} END { print SUM }'
3481260688298

Wat ik het raarst vind, is dat als ik de quota aanpas, de quota inderdaad veranderd, maar dan van user 1023. Voor mij is 1023 nogal opvallend, als je 0-based telt is dat netjes 2^10....

Het grote verschil tussen jouw en mijn installatie lijkt de versie van ZoL te zijn, ik zal als het kan het OS updaten, hopelijk lost dat het dan op.

Anders moet jet OS maar naar BSD of Solaris, hoewel ik liever alles hetzelfde hou.

[tvwes]

jvhaarst schreef op maandag 04 mei 2015 @ 10:29:
@tvwes

Ik heb het expres kort gehouden, die info leek me niet zo relevant.

Maar omdat je er om vraagt, dan geef ik het graag :
Het systeem is in gebruik als scratch space, voor opslag van tussen resultaten van bioinformatica analyses.
Dat vreet nogal wat ruimte, vandaar de redelijke grootte.

Bdankt voor de achtergrond. Ik was niet geinteresseerd in de quota size maar in de hoogte en herkomst van de UID.

De id's zijn zo hoog, omdat op de servers waar de analyses op draaien, we in loggen met gegevens uit de Active Directory, dan hoef ik niet voor iedere user op alle machines users en wachtwoorden te regelen.

Ook al is het niet echt relevant, denk ik, zou je mij nog iets meer evt in een pm over die uid's kunnen uitleggen. Als dit tijdelijke uid's zijn dan heb je alsnog een probleem.

De user (ik dus) gebruikt ruimte (in bytes):

code:

sysop@scratch:/scratch/data/haars001$ sudo find . -type f -uid 16825946 -exec stat --format=%s {} \; | awk '{ SUM += $1} END { print SUM }'
3481260688298

Wat ik het raarst vind, is dat als ik de quota aanpas, de quota inderdaad veranderd, maar dan van user 1023. Voor mij is 1023 nogal opvallend, als je 0-based telt is dat netjes 2^10....

Ik je helaas niet helemaal volgen.

Het grote verschil tussen jouw en mijn installatie lijkt de versie van ZoL te zijn, ik zal als het kan het OS updaten, hopelijk lost dat het dan op.
Anders moet jet OS maar naar BSD of Solaris, hoewel ik liever alles hetzelfde hou.

Als je mij vertelt hoe je ZoL 0.6.3 op ubuntu 13 (saucy) krijgt dan wil ik dat ook nog wel proberen.

Was mijn test representatief? (Op de size na) Snap je dat het commando

code:

#sudo zfs userspace scratch/data

niet een lijst van ingestelde quota geeft? Volgens mij was dat jouw verwachting namelijk.

[yamahabest]

Misschien zou dit in een los topic moeten, maar het is maar een kleine vraag.

Ik heb een probleempje met de ZFSGuru CD in combinatie met IPMI op een SuperMicro bordje.
Ik krijg tijdens de boot een stel errors:

"[ZFSGURU-BOOT] ERROR: could not detect LiveCD or Embedded distribution!
FATAL ERROR: LiveCD or Embedded medium not found!
Device node expected at one of:
/dev/gpt/ZFSGURU-EMBEDDED
/dev/iso9660/ZFSGURU-LIVECD
/dev/label/ZFSGURU-LIVECD
/dev/gpt/ZFSGURU-LIVECD
Neither of those have been found! Aborting boot sequence!"

Is dit een bekend probleem? En moet ik een USB CD-spelertje aansluiten?

[ Voor 7% gewijzigd door yamahabest op 04-05-2015 14:28 ]

[FireDrunk]

Die IPMI virtuele cd speler is juist usb, denk dat daar juist het probleem zit...

[Bigs]

yamahabest schreef op maandag 04 mei 2015 @ 14:28:
Misschien zou dit in een los topic moeten, maar het is maar een kleine vraag.

Ik heb een probleempje met de ZFSGuru CD in combinatie met IPMI op een SuperMicro bordje.
Ik krijg tijdens de boot een stel errors:

"[ZFSGURU-BOOT] ERROR: could not detect LiveCD or Embedded distribution!
FATAL ERROR: LiveCD or Embedded medium not found!
Device node expected at one of:
/dev/gpt/ZFSGURU-EMBEDDED
/dev/iso9660/ZFSGURU-LIVECD
/dev/label/ZFSGURU-LIVECD
/dev/gpt/ZFSGURU-LIVECD
Neither of those have been found! Aborting boot sequence!"

Is dit een bekend probleem? En moet ik een USB CD-spelertje aansluiten?

Heb je al gecontroleerd of je iso niet corrupt is? Dit zou gewoon moeten werken namelijk.

[Verwijderd]

Niet detecteren van de ISO label kan verschillende oorzaken hebben. Maar yamahabest, vertel eerst eens hoe je precies boot? Heb je de .iso gebrand naar een CD-R of boot je middels CD emulatie of heb je geprobeerd de .iso op een USB stick te schrijven, etc?

@FireDrunk: ik heb een Zalman VE-300 USB3 hardeschijf met .iso CD/DVD/BR emulatie, en dat werkt altijd perfect met ZFSguru ISO-images. Op vrijwel alle systemen werkt dat prima.

Maar wat niet gaat werken is de .iso naar een USB stick schrijven bijvoorbeeld.

[ Voor 33% gewijzigd door Verwijderd op 04-05-2015 16:12 ]

[yamahabest]

Ik heb via de IPMI console de ISO "virtueel" in de machine geplugged. Ik heb verder geen fysieke media gebruikt.
En dat gaat een heel eind goed, totdat hij met deze foutmelding komt.

[FireDrunk]

@CiPHER. Die heb ik ook
De IPMI USB cd speler werkt geloof ik net wat anders waardoor het ding nogal brakke detectie heeft onder BSD.
Heb er zelf ook wel eens problemeb mee gehad. Wat wel eens helpt is de cd speler op always attach zetten ipv auto attach.

[Verwijderd]

Ah zo. Nou een makkelijke oplossing kan zijn om de installatie eerst op een ander systeem uit te voeren. Of virtueel met Virtualbox bijvoorbeeld. En daarmee te booten op het echte systeem en zodra je ZFSguru draait kun je ook weer installeren dus dan ben je 'binnen'. Je moet eerst zorgen dat je ZFSguru kunt booten.

Dus een hardeschijf in een ander systeem laten installeren en dan in je server plaatsen kan, of een USB stick maken via VirtualBox kan ook.

Andere oplossing is om ook zo'n Zalman VE-300 te kopen; want dat is echt wel handig voor dit tijdperk waarbij je geen cd-brander enzo wilt hebben; maar soms wel cd-tjes wilt booten. En dat kun je dan combineren met een externe USB3 hardeschijf voor backups of wat. Lekker handig en ben je in één klap af van de optical media.

[ Voor 26% gewijzigd door Verwijderd op 04-05-2015 19:00 ]

[FireDrunk]

Eerlijk gezegd: In dit tijdperk moet een OS gewoon van USB stick kunnen booten
99.99% van de Linux ISO's kan je gewoon naar een USB stick 'dd-en'

(De Gentoo admin-cd, kan zelfs USB, ISO, Netwerk, UEFI en BIOS aan )

[ Voor 19% gewijzigd door FireDrunk op 04-05-2015 20:07 ]

[Mr Alfabet]

FireDrunk schreef op maandag 04 mei 2015 @ 07:07:
Die chmod / chown is idd de goede oplossing, maar die is als het goed is niet persistent bij een reboot.

http://blog.gjpvanwesten....s-virtual.html#userrights

Hier een random voorbeeldje hoe je dat met udev regelt.

Bij het commando

code:

leafpad /etc/udev/rules.d/91-zfs-permissions.rules

krijg ik de melding:

code:

leafpad: Cannot open display

EDIT: nevermind, leafpad is natuurlijk gewoon een editor.

[ Voor 5% gewijzigd door Mr Alfabet op 04-05-2015 20:48 ]

[yamahabest]

Las ik niet ergens dat dat met aanstaande versie 0.3 ook zou moeten kunnen?

Begrijp ik het goed dat het met een gewone USB CDROM speler wel zou moeten kunnen werken?
Anders ga ik morgen wel met VMware/Virtualbox aan het klussen.

[FireDrunk]

Die kans is groot ja. Die IPMI usb speler doet een hele oude usb controller na volgens mij, en die is/was een beetje bugged in BSD.

'Gewone' USB cdrom spelers zouden het gewoon moeten doen.

[yamahabest]

Ga ik dat proberen, scheelt wat tijd. Thanks.
Heb even wat gezocht naar zo'n Zalman VE-300, maar die lijken slecht leverbaar.

[dcm360]

Mijn ervaring is dat het met een Zalman VE-300 ook af en toe niet lukt om op te starten vanaf een virtuele CD. De meest interessante vond ik in combinatie met mijn gloednieuwe laptop, maar het lukte me geloof ik ook niet om een pfSense-installatie te starten.
Dat die wat lastig verkrijgbaar is komt denk ik door de financiële situatie van Zalman, die is niet al te best. Het is echter een rebrand van een ander merk, dus misschien is hetzelfde kastje beter verkrijgbaar onder een andere naam.

[A1AD]

Ik heb eindelijk wat tijd gevonden om te experimenteren met Proxmox op mijn test machine. Ja kan Proxmox nu installeren op ZoR. Het idee is om Proxmox te installeren op een RaidZ1 van 3*1.5TB. De RaidZ1 pool zou dan enkel dienen voor root en als "NAS". Samba wordt geregeld via een OpenVZ container.

Ik heb een enkele SSD waarop ik mijn VM's wil draaien en mijn vraag is of ZFS een voordeel heeft tov EXT4 in dit geval? Snelheid primeert want er wordt elke nacht een backup gemaakt op de ZFS pool (door Proxmox zelf)

[FREAKJAM]

Wat ik me kon herinneren is dat je geen bestaande pool kunt selecteren tijdens de installatie en alleen kunt kiezen voor een nieuwe pool. Volgens mij is Proxmox installeren op een bepaalde pool dus geen optie.

Ik ben ook nog steeds aan het zoeken naar iets nieuws. Ik ben eigenlijk een beetje uitgekeken op VMWare ESXi. Ik wil oVirt eens proberen, maar ik vind de installatie nogal complex doen overkomen.

[ Voor 15% gewijzigd door FREAKJAM op 07-05-2015 09:53 ]

[A1AD]

FREAKJAM schreef op donderdag 07 mei 2015 @ 09:52:
Wat ik me kon herinneren is dat je geen bestaande pool kunt selecteren tijdens de installatie en alleen kunt kiezen voor een nieuwe pool. Volgens mij is Proxmox installeren op een bepaalde pool dus geen optie.

Backup maken en data overzetten? Dit is voor mij geen probleem.
edit: ik moet dit sowieso doen omdat ik encryptie gebruik op mijn FreeNAS ZFS pool

[ Voor 10% gewijzigd door A1AD op 07-05-2015 09:57 ]

[FREAKJAM]

Ik heb 5TB aan data, voornamelijk media. Ik heb een spare 3TB schijf op de plank liggen en wat losse kleine schijven, dus theoretisch kan ik de boel backuppen.

code:

NAME             USED  AVAIL  REFER  MOUNTPOINT
tank/kodi       3.58G  5.53T  3.58G  /tank/kodi
tank/movies     2.63T  5.53T  2.63T  /tank/movies
tank/music      47.7G  5.53T  47.7G  /tank/music
tank/photos     3.32G  5.53T  3.32G  /tank/photos
tank/pms        14.9G  5.53T  14.9G  /tank/pms (plex data)
tank/tvshows    2.39T  5.53T  2.39T  /tank/tvshows

[A1AD]

FREAKJAM schreef op donderdag 07 mei 2015 @ 09:52:
Ik wil oVirt eens proberen, maar ik vind de installatie nogal complex doen overkomen.

^{offtopic:
Ik heb hier ook eens naar gekeken, nadeel is dat je dan aan KVM "vast zit". Je kan de live cd versie eens proberen.}

[Bigs]

A1AD schreef op donderdag 07 mei 2015 @ 09:23:
Ik heb eindelijk wat tijd gevonden om te experimenteren met Proxmox op mijn test machine. Ja kan Proxmox nu installeren op ZoR. Het idee is om Proxmox te installeren op een RaidZ1 van 3*1.5TB. De RaidZ1 pool zou dan enkel dienen voor root en als "NAS". Samba wordt geregeld via een OpenVZ container.

Ik heb een enkele SSD waarop ik mijn VM's wil draaien en mijn vraag is of ZFS een voordeel heeft tov EXT4 in dit geval? Snelheid primeert want er wordt elke nacht een backup gemaakt op de ZFS pool (door Proxmox zelf)

Als je geen ZFS features snapshots of compressie wilt gebruiken zou ik gewoon EXT4 gebruiken (snapshots kun je dan maken via LVM), aangezien ZFS ook nadelen heeft (bijvoorbeeld de performance die inkakt als je je pool >80% vol schrijft).

[Verwijderd]

Dat geldt ook voor andere filesystems; nog meer eigenlijk omdat andere filesystems aan random writes doen en ZFS niet. Maar bij ZFS kan de random read wel harder teruglopen; daar heb je dan L2ARC voor. Dat missen andere filesystems weer.

Maar je kiest ZFS toch vanwege de bescherming voor je bestanden? Niet omdat je compressie of deduplicatie kunt gebruiken? ZFS is een modern 3e generatie filesystem voor moderne hardeschijven met hoge datadichtheid (waar bad sectors normaal zijn en erbij horen). Ext4 is gewoon ouderwetse opslag zonder enige vorm van bescherming; te vergelijken met UFS en NTFS. Corruptie zal niet worden gedetecteerd, laat staan gecorrigeerd. Silent corruption is dus een groot probleem. Bovendien ben je erg gevoelig voor bad sectors zeker als je daar nog eens traditioneel RAID bij gebruikt.

[A1AD]

Verwijderd schreef op donderdag 07 mei 2015 @ 16:57:
Allemaal info dat we hier allemaal al lang weten

Heb je mijn vraag wel goed gelezen?

Het gaat hier om 1 enkele SSD waar enkel VM's op komen te draaien. Mijn data en vm backups komen uiteraard op ZFS

[ Voor 21% gewijzigd door A1AD op 07-05-2015 17:42 ]

[Compizfox]

Wat is tegenwoordig een goede Linux-distributie voor ZoL?

Ik heb namelijk momenteel een fileserver draaien op basis van FreeBSD (ZFSGuru) die maar niet lekker wil werken. Regelmatig freezende smbd-processen, zie https://serverfault.com/q...-in-uninterruptable-sleep.

Ik kan het probleem helaas niet oplossen (en in de ServerFault-thread is het ook stil) dus ik ga overstappen naar ZFS on Linux in de hoop dat het probleem daarmee is opgelost/omzeild.

Ik weet echter praktisch niets van ZFS on Linux, dus ik heb een aantal vragen.

• Is het zo dat bepaalde distributies betere ZFS-support hebben dan andere? Zo ja, welke zijn dit dan?
• Wordt ZFS tegenwoordig meegeleverd met Linux-distibuties? Vroeger was er een licentieprobleem dat dat verhinderde en had je de keuze uit ofwel ZFS draaien onder FUSE (bah ) of zelf een kmod compileren, maar ik weet niet of dit nog steeds zo is.
• Kan ik mijn ZFS-pool (SPA v5000, GPT) aangemaakt onder FreeBSD zomaar importeren onder Linux?

[ Voor 24% gewijzigd door Compizfox op 07-05-2015 20:38 ]

[Rolfie]

Compizfox schreef op donderdag 07 mei 2015 @ 20:34:
Wat is tegenwoordig een goede Linux-distributie voor ZoL?

Ik heb namelijk momenteel een fileserver draaien op basis van FreeBSD (ZFSGuru) die maar niet lekker wil werken. Regelmatig freezende smbd-processen, zie https://serverfault.com/q...-in-uninterruptable-sleep.

Ik kan het probleem helaas niet oplossen (en in de ServerFault-thread is het ook stil) dus ik ga overstappen naar ZFS on Linux in de hoop dat het probleem daarmee is opgelost/omzeild.

Ik weet echter praktisch niets van ZFS on Linux. Is het bijvoorbeeld zo dat bepaalde distributies betere ZFS-support hebben dan andere? Zo ja, welke zijn dit dan?

Gewoon FreeNAS? Ook op basis van FreeBSD maar iets andere insteek dan ZFSGuru.....

[Compizfox]

FreeNAS is ook FreeBSD en dat gaat dus niets aan de situatie veranderen.

Het gaat me niet om de insteek; ik ben niet op zoek naar een ander OS omdat ik niet tevreden ben met ZFSGuru, ik wil echt doelgericht van FreeBSD weg omdat het blijkbaar niet werkt in de situatie die ik hier heb. Misschien ligt het aan de hardware, misschien is m'n pool op een rare manier corrupt, ik weet het niet, maar mijn ideeën voor troubleshooting zijn op. Ik heb ook al een reinstall gedaan en nog blijf ik hetzelfde probleem houden.

offtopic:
Ik heb trouwens niets tegen FreeBSD hoor. De probleemserver is niet van mijzelf, maar ik heb thuis zelf ook een fileserver op FreeBSD, ZFS en Samba en daar werkt het wel prima.

Ik zie wel in dat FreeBSD simpelweg het beste platform is voor ZFS en ik zou graag bij FreeBSD blijven, maar die server moet gewoon werken en ik krijg het niet werkend onder FreeBSD.

[ Voor 115% gewijzigd door Compizfox op 07-05-2015 22:58 ]

[HyperBart]

Compizfox schreef op donderdag 07 mei 2015 @ 20:34:
Wat is tegenwoordig een goede Linux-distributie voor ZoL?

Ik heb namelijk momenteel een fileserver draaien op basis van FreeBSD (ZFSGuru) die maar niet lekker wil werken. Regelmatig freezende smbd-processen, zie https://serverfault.com/q...-in-uninterruptable-sleep.

Ik kan het probleem helaas niet oplossen (en in de ServerFault-thread is het ook stil) dus ik ga overstappen naar ZFS on Linux in de hoop dat het probleem daarmee is opgelost/omzeild.

Ik weet echter praktisch niets van ZFS on Linux, dus ik heb een aantal vragen.

• Is het zo dat bepaalde distributies betere ZFS-support hebben dan andere? Zo ja, welke zijn dit dan?
• Wordt ZFS tegenwoordig meegeleverd met Linux-distibuties? Vroeger was er een licentieprobleem dat dat verhinderde en had je de keuze uit ofwel ZFS draaien onder FUSE (bah ) of zelf een kmod compileren, maar ik weet niet of dit nog steeds zo is.
• Kan ik mijn ZFS-pool (SPA v5000, GPT) aangemaakt onder FreeBSD zomaar importeren onder Linux?

Ik heb FireDrunk wel weer wat lovends horen zeggen over fedora en ZOL. Maar ik draai hier al tijden naar volle tevredenheid ubuntu en zol... Niks aan de hand hoor...

[A1AD]

Compizfox schreef op donderdag 07 mei 2015 @ 20:39:
FreeNAS is ook FreeBSD en dat gaat dus niets aan de situatie veranderen.

Ik heb ook last van een onbetrouwbaar smb proces. Veel timeouts/resets. Op FreeNAS trouwens. Zelf nog geen tijd gehad om het probleem te bekijken. Als ik de service herstart werkt het wel weer even goed...

[Compizfox]

Mijn probleem is iets vervelender, smbd komt namelijk in een uninterruptable sleep state. Dat betekent dus dat ik het probleemproces in zo'n geval niet eens kan killen, hij reageert niet op SIGKILL. Reboot is de enige optie en zelfs dat gaat verkeerd omdat FreeBSD helemaal niet wil afsluiten in zo'n geval (blijft hangen op "All buffers synced")

[DXaroth]

HyperBart schreef op donderdag 07 mei 2015 @ 21:54:
[...]


Ik heb FireDrunk wel weer wat lovends horen zeggen over fedora en ZOL. Maar ik draai hier al tijden naar volle tevredenheid ubuntu en zol... Niks aan de hand hoor...

Hier redelijk hetzelfde verhaal, de enige reden dat ik zelf een niet-debian-esque systeem zal installeren op mn esx host is waarschijnlijk om libzfs-python op dat systeem te testen.

Ga je de richting op dat je het 'extreem' gaat gebruiken (lees: als san gebruiken voor 100+ instances) dan wil je wellicht even dubbelchecken wat je wilt gebruiken, maar voor het normale hobbyverkeer dat een tweaker kan genereren houdt ZoL zich prima stand.

[FREAKJAM]

ZFS werkt alweer een tijdje met Fedora 21. Voordeel van Fedora is dat het ook komt met cockpit project, een soort van monitoring tool. Volgens mij alleen nog niet volledig geïntegreerd met ZFS.

Ontwikkeling van Cockpit voorloopt voorspoedig. Ik idle al een paar maanden in hun irc-kanaal en ze zijn ontzettend actief op github. Misschien ooit in een verre toekomst Fedora draaien met dockers ipv VM's? Ik bedoel ik gebruik Plex en dergelijke en hier zijn allemaal dockers voor. Enige wat niet te docken is, is pfSense denk ik.

Ik draai zelf trouwens al een paar maanden CentOS 7 met de laatste ZFS versie en het werkt hier als een zonnetje.

[ Voor 38% gewijzigd door FREAKJAM op 08-05-2015 09:29 ]

[Compizfox]

Aangezien ik eigenlijk voornamelijk persoonlijke voorkeuren qua distro's hoor, begrijp ik dat er qua ZoL-support geen noemenswaardig verschil zit tussen distributies? In dat geval pleur ik er fijn Debian op denk ik

[thespeed]

Na een crash en dataverlies heb ik mijn server draaien op Raid-Z2 met Openmediavault.
Ik draaide met 4 drives (4x2TB) en 1 drive was gesneuveld.
Deze drives Seagate ST2000DM001 blijken bij sommigen na een aantal jaar defect te gaan.
De defecte drive heb ik vervangen door een WD Red 2TB.

Op de server staat verder nog niets en nu twijfel ik toch als Raid-Z2 de beste oplossing is.
Dit ook omdat ik nu maar 3,46TB tot mijn beschikking heb.
Voor mijn gevoel is dit genoeg maar voor de toekomst heb ik toch wat twijfels.
Raid-Z2 kun je wat ik heb gelezen alleen vergroten door of alle drives te vervangen, of een backup te maken en gewoon weer opnieuw beginnen, of door hem uit te breiden met hetzelfde aantal schijven.

Wat ik begrepen heb kun je Raid 6 wel met een enkele schijf uitbreiden, dus misschien is dit toch een betere oplossing. In hoeverre zou voor thuisgebruik Raid 6 betrouwbaar zijn ten opzichte van ZFS?

Op mijn HP microserver N40L heb ik 5 Sata poorten en nog 1 extra Esata poort die ik nog zou kunnen gebruiken. De installatie zou ik dan uiteindelijk nog via een usb schijfje kunnen laten laden.
Wat ik zo zie heb ik 1x4GB ECC geheugen en 1x4GB non ECC geheugen.
Dit is wel wat nadelig voor ZFS heb ik gelezen.
Twijfels twijfels

[FREAKJAM]

Compizfox schreef op vrijdag 08 mei 2015 @ 09:33:
Aangezien ik eigenlijk voornamelijk persoonlijke voorkeuren qua distro's hoor, begrijp ik dat er qua ZoL-support geen noemenswaardig verschil zit tussen distributies? In dat geval pleur ik er fijn Debian op denk ik

Zo kun je het eigenlijk wel stellen ja Ik had veel geneuzel met ZoL op Ubuntu dus heb uiteindelijk voor CentOS 7 gekozen. Debian (Wheezy) ook een tijdje geprobeerd maar die vond het gebruik van partlabels in ZFS niet zo leuk. Debian Jesse is trouwens geen probleem.

[ Voor 5% gewijzigd door FREAKJAM op 08-05-2015 09:39 ]

[FireDrunk]

Mijn ervaringen met OSs en ZFS:

Gentoo: Near perfect, je kan ZFS zelfs in de kernel meecompileren.
CentOS 6: Werkt, maar eigenlijk te oude kernele voor ZFS.
CentOS 7: Prima, loopt keurig in de pas.
Fedora 21: Prima, loopt keurig in de pas.
ArchLinux: Alleen beschikbaar via AUR, maar doet lastig met compileren omdat er wat vage dependencies zijn. Heb het niet snel aan de praat gekregen, en daarom maar opgegeven.

Ubuntu: Wisselende ervaring, als het werkt, werkt het prima, maar er zijn wat bugs in combinatie met M1015 controllers dat ZFS eerder start dan dat je controller klaar is met initialiseren. Hierdoor wil het nog wel eens voorkomen dat je pool niet gemount is na een reboot. Er zijn wat vieze fixes om dit op te lossen.

In alle distro's met een fatsoenlijke UDEV implementatie is dit wel netjes geregeld, je ziet netjes tijdens het booten: "Waiting for udev devices to settle..."

Ik draai persoonlijk Fedora 21 Server, en dat bevalt mij prima, wil je iets minder bleeding edge draaien, kan ik van harte CentOS 7 aanraden.

(Mocht je graag Cockpit proberen, wat ik van harte aan kan raden, werkt dat ook prima op CentOS7 hoor, dat is 1 repo toevoegen, en 1 yum install commando om dat te installeren.)

[ Voor 7% gewijzigd door FireDrunk op 08-05-2015 10:23 ]

[Pantagruel]

FireDrunk schreef op vrijdag 08 mei 2015 @ 10:22:
Mijn ervaringen met OSs en ZFS:

Gentoo: Near perfect, je kan ZFS zelfs in de kernel meecompileren.
CentOS 6: Werkt, maar eigenlijk te oude kernele voor ZFS.
CentOS 7: Prima, loopt keurig in de pas.
Fedora 21: Prima, loopt keurig in de pas.
ArchLinux: Alleen beschikbaar via AUR, maar doet lastig met compileren omdat er wat vage dependencies zijn. Heb het niet snel aan de praat gekregen, en daarom maar opgegeven.

Ubuntu: Wisselende ervaring, als het werkt, werkt het prima, maar er zijn wat bugs in combinatie met M1015 controllers dat ZFS eerder start dan dat je controller klaar is met initialiseren. Hierdoor wil het nog wel eens voorkomen dat je pool niet gemount is na een reboot. Er zijn wat vieze fixes om dit op te lossen.

In alle distro's met een fatsoenlijke UDEV implementatie is dit wel netjes geregeld, je ziet netjes tijdens het booten: "Waiting for udev devices to settle..."

Ik draai persoonlijk Fedora 21 Server, en dat bevalt mij prima, wil je iets minder bleeding edge draaien, kan ik van harte CentOS 7 aanraden.

(Mocht je graag Cockpit proberen, wat ik van harte aan kan raden, werkt dat ook prima op CentOS7 hoor, dat is 1 repo toevoegen, en 1 yum install commando om dat te installeren.)

Mbt de ervaring rondom Linux en ZoL kan ik me hierbij aansluiten.

CentOS 7: Als de bekende gesmeerde bliksem.

Fedora 21: Idem, alleen jammer dat de Cockpit integratie inderdaad nog niet rond is want dat is wel een zeer handige beheer oppervlakte.

Ubuntu: Problemen rondom de foutloze ondersteuning van de M1015 controller die te ondervangen zijn met het inbouwen van harde waits/sleeps tijdens de opstart fase zodat de controller up is voordat ZFS de pool wilt mounten. Geen andere HBA's getest dus geen idee of die ook vatbaar zijn voor dit gezeur.

[FireDrunk]

Ik moet me nog een keer kwaad maken en het support voor ZFS zelf inbouwen in Cockpit
Die tool zit best wel heel erg goed in elkaar qua codering (veel, veel, *veel* beter dan webmin bijvoorbeeld.)

Maar ja, tijd...

[HyperBart]

FireDrunk schreef op vrijdag 08 mei 2015 @ 11:20:eld.)
Maar ja, tijd...

Tsja, mijnheer heeft het druk natuurlijk met al die huwelijken die hij moet bijwonen he

thespeed schreef op vrijdag 08 mei 2015 @ 09:36:
Na een crash en dataverlies heb ik mijn server draaien op Raid-Z2 met Openmediavault.
Ik draaide met 4 drives (4x2TB) en 1 drive was gesneuveld.
Deze drives Seagate ST2000DM001 blijken bij sommigen na een aantal jaar defect te gaan.
De defecte drive heb ik vervangen door een WD Red 2TB.

Op de server staat verder nog niets en nu twijfel ik toch als Raid-Z2 de beste oplossing is.
Dit ook omdat ik nu maar 3,46TB tot mijn beschikking heb.
Voor mijn gevoel is dit genoeg maar voor de toekomst heb ik toch wat twijfels.
Raid-Z2 kun je wat ik heb gelezen alleen vergroten door of alle drives te vervangen, of een backup te maken en gewoon weer opnieuw beginnen, of door hem uit te breiden met hetzelfde aantal schijven.

Wat ik begrepen heb kun je Raid 6 wel met een enkele schijf uitbreiden, dus misschien is dit toch een betere oplossing. In hoeverre zou voor thuisgebruik Raid 6 betrouwbaar zijn ten opzichte van ZFS?

Op mijn HP microserver N40L heb ik 5 Sata poorten en nog 1 extra Esata poort die ik nog zou kunnen gebruiken. De installatie zou ik dan uiteindelijk nog via een usb schijfje kunnen laten laden.
Wat ik zo zie heb ik 1x4GB ECC geheugen en 1x4GB non ECC geheugen.
Dit is wel wat nadelig voor ZFS heb ik gelezen.
Twijfels twijfels

Ik vind die N40L's prachtige bakbeestjes om een NAS van te maken. Vergeet niet dat ze EIGENLIJK ook 16GB ondersteunen, ok, dat kost dan wel wat geld, maar dan heb je meer als voldoende.

Voor een ZFS NAS at home is 8GB prima, koop nog een latje bij en je zit gebeiteld.

Ik heb hier zelfs nog van mijn speel-build met die N40L (ondertussen al van de hand gedaan) een eSATA naar SATA kabeltje liggen.

Even zoeken naar mijn blogpost.

HyperBart in "Storage showoff topic - 20+ TB storage systems"


Wat betreft het draaien van ZoL of gewoon uberhaupt ZFS en dan de vraag welke onderliggend OS je wilt draaien:

Ik heb al een tijdje een DM thread lopen met tvwes, en hij is er in geslaagd om op Illumos een volledige NAS/SAN icm zones Sick Beard, Sabnzbd en Couchpotato op te draaien. Iets wat volgens mij voor de meeste mensen al meer als genoeg is.

Aangezien (voor wat ik er van begrijp) ZFS daar zijn oorsprong vindt lijkt dat ook wel een piste die ik hier eens wil volgen, al dan niet virtueel om er even bekend mee te geraken.


Wat betreft het ZFS on Linux verhaal: ik heb nog zo wel een "quirk" met Ubuntu en ZFS, maar ik heb nu even niet de ballen om dat soort risico's te nemen.

Als je bij Ubuntu en ZFS *al* je disks er uit trekt (van één pool natuurlijk), dan begint zpool status wat te bokken. Dat is naar het schijnt niet alleen bij Ubuntu, ook bij FreeBSD (ServerFault threadje), dus ik veroordeel het niet, maar het was toch ook weer zoiets waar bij ik had van

[ Voor 89% gewijzigd door HyperBart op 08-05-2015 12:36 ]

[Pantagruel]

HyperBart schreef op vrijdag 08 mei 2015 @ 12:10:
[...]

Tsja, mijnheer heeft het druk natuurlijk met al die huwelijken die hij moet bijwonen he

[...]

Trouwpartijtje HyperBart ?, If yes then feli else never mind

Ik vind die N40L's prachtige bakbeestjes om een NAS van te maken. Vergeet niet dat ze EIGENLIJK ook 16GB ondersteunen, ok, dat kost dan wel wat geld, maar dan heb je meer als voldoende.

Voor een ZFS NAS at home is 8GB prima, koop nog een latje bij en je zit gebeiteld.

Ik heb hier zelfs nog van mijn speel-build met die N40L (ondertussen al van de hand gedaan) een eSATA naar SATA kabeltje liggen.

Even zoeken naar mijn blogpost.

HyperBart in "Storage showoff topic - 20+ TB storage systems"


Wat betreft het draaien van ZoL of gewoon uberhaupt ZFS en dan de vraag welke onderliggend OS je wilt draaien:

Ik heb al een tijdje een DM thread lopen met tvwes, en hij is er in geslaagd om op Illumos een volledige NAS/SAN icm zones Sick Beard, Sabnzbd en Couchpotato op te draaien. Iets wat volgens mij voor de meeste mensen al meer als genoeg is.

In de zin van Sick/Sab en Couch op Illumos zoals hier voor OpenIndiana is beschreven?
Of in de vorm van een AiO mbv verschillende VM's? Ik draai zelf onder ESXi een OpenIndiana storage VM die o.a. opslag aanbiedt aan de download vm (Ubuntu met Sick/Sab/AutoSub/Torrent).

Aangezien (voor wat ik er van begrijp) ZFS daar zijn oorsprong vindt lijkt dat ook wel een piste die ik hier eens wil volgen, al dan niet virtueel om er even bekend mee te geraken.

OI/Illumos in combi met Napp-it is eigenlijk Appeltje-Eitje

Wat betreft het ZFS on Linux verhaal: ik heb nog zo wel een "quirk" met Ubuntu en ZFS, maar ik heb nu even niet de ballen om dat soort risico's te nemen.

Daar is de 'rammelbak' voor (bonte verzameling van oude hardware), deze mag naar hartenlust worden afgeschoten zonder dat de gevolgen pijnlijk zijn.

Als je bij Ubuntu en ZFS *al* je disks er uit trekt (van één pool natuurlijk), dan begint zpool status wat te bokken. Dat is naar het schijnt niet alleen bij Ubuntu, ook bij FreeBSD (ServerFault threadje), dus ik veroordeel het niet, maar het was toch ook weer zoiets waar bij ik had van

Dat heb ik persoonlijk nog nooit gedaan, ging er min of meer vanuit dat de melding een droge "no pool found" zou zijn en verder weinig spannends.

[tvwes]

Ik heb voor HyperBart een howto gemaakt voor SickBeard en SABnzbd en wat algemene zaken op basis van OmniOS.

Ik sta eigenlijk nog steeds verbaast te kijken hoe simpel dat is. Ik heb wel wat uren in die Sickbeard en SAB moeten steken, want dat had ik nog nooit gedaan. Het werk zat hem niet in het draaiend krijgen maar meer in het gebruik maken van de faciliteiten van het OS. Bijvoorbeeld het schrijven van SMF manifest's Maar ik heb die nu helemaal clean draaien in zones. Vooral de (zone) snapshots zijn erg handig om te recoveren van een mislukte upgrade. Ik geef wel onmiddelijk toe dat ik naderend tot niets weet van deze applicaties, en niet geholpen door de overvloedige documentatie en mijn hulp verzoek hier op tweakers, wat het optimaal inregelen van deze apps niet mogelijk maakt. Nog een disclaimer, ik heb geen volledige pkg ontwikkeld maar een script wat alle dependencies en apps installeert. Maar het maken van een pkg met oa binaries, scripts, default users is op zich prima te doen. Ik wilde in eerste instantie alleen zien hoe moeilijk het was om dit soort apps aan de gang te krijgen en gebruik te maken van de bijzondere faciliteiten van het OS.

Leuk was om bijv een memory cap in te stellen en SAB vervolgens pijn te zien lijden...
Geen van deze applicaties kan ooit op hol slaan en het systeem onder uit halen, door resource control en isolatie.
Voor systemen met weinig RAM is dit ook een uitkomst, Illumos gebaseerde distro's zullen bij memory pressure veel beter hun ARC verminderen en dit aan de applicatie geven. Dat doet Linux lang niet zo goed. Als SABnzbd bijvoorbeeld na een download veel geheugen nodig heeft is dat geen enkel probleem. Ik dat dit zelfs met 4GB nog geen probleem is.

Wat ik nog wil testen of ik op een systeem met een bescheiden cpu(zo'n celeron of pentium), ipv deze 2 socket xeon v3, QoS voor streaming kan garanderen. Anders gezegd kan ik een test maken die een of twee streams zonder haperen kan afspelen terwijl anderen taken, als SABnzbd, misschien ook druk bezig zijn. Transcoding even buitenbeschouwing gelaten. Technisch maakt dat niet zoveel uit maar de verhouding is helemaal scheef tussen de benodigde rekenkracht voor transcoding en wat taken als SABnzbd.

Zaken je hier ook makelijk kan regelen, in tegen stelling tot andere OS'es (behalve iets als vSphere), is dat je al deze services bijv achter een frontend incusief firewall kan verstopen. Onderwater draait alles in zijn eigen OS maar dmv vSwitches kan je de services achter een frontend verstoppen. Je dan niks meer te maken met allemaal ip adressen en poorten per service, nee 1 start pagina maken en wat url mappings definieren en klaar. De firewall in de frontend kan ervoor zorgen dat de services alleen naar het internet kunnen en niet zomaar op je thuis netwerk gaan kijken.

[FireDrunk]

Hoe regel je de filesystem toegang van de zones richting je 'media' zfs pool? Ik bedoel, erg leuk dat je die applicaties kan limiteren op je thuis netwerk, maar die applicaties hebben toegang nodig tot je media library

[HyperBart]

Pantagruel schreef op vrijdag 08 mei 2015 @ 13:12:
[...]


Trouwpartijtje HyperBart ?, If yes then feli else never mind

Yes! Morgen!

[tvwes]

Leuk dat je dat vraagt. Daar heb ik een tijd mee geworsteld, vooral door het ontbreken van iedere vorm van technische documentatie en architectuur beschrijving (bij apps als SB en SAB). Wel een heleboel howto's, bestemd voor ome Henk en geschreven door zijn puisterige neefje, maar niet iets echt technisch. Het was mij in eerste instantie ook helemaal niet duidelijk hoe de datastromen verliepen en nog steeds niet helemaal. Maar ik weet nu wel dat sickbeard ctrl cmd's verstuurd naar SAB. Die vervolgens wat download, wat post processing doet en weer een signaal aan SB stuurt. Die twee doen dat op een gemeenschappelijke directory (bij mij op dit moment in ieder geval) Nu zijn er vier manieren om storage aan een zone toe te kennen, remote(NFS ed.), twee vormen met ZFS en een op basis van LOFS. In eerste instantie wilde ik een (zfs) dataset delegeren aan de zone. Wat op zich een prima plan is maar dan heeft de zone volledige controle over de dataset. Bij nader inzien was dat toch geen goed idee. Ik stel nu zfs datasets ter beschikken via LOFS, zo heeft en de global-zone en 1 of meerdere zone toegang tot die dataset. De global-zone verzorgt NAS taken en ZFS acties als snapshot's. Mits je wel een snapshot maakt, kan zelfs SickRansomWare™ niet ook even snel je downloads onklaar maken zelfs niet je snapshot's deleten.

Samenvattend: Ik heb een "moeder" zone gemaakt met daarin een mount (in de zone /export/media en in de global-zone /mpool/media) via lfos. Van deze moeder zone maak ik vervolgens clones waarin ik dan een app installeer. Het OS regelt dit via ZFS snapshot's. Elke zone die deze mount heeft kan bij de data, de global-zone natuurlijk altijd. Let op dat je zones ook gewoon een root user hebben die ook almachtig is op dat filesystem. Nu kan je een hoop schade beperken door de apps niet als root te draaien maar toch. Voor alle volledigheid, wat in de zone zit kan niet ontsnappen daaruit. De root in de zone kan wel shutdown doen maar dat stopt alleen de zone. Ja in de zone zie je wel de zfs datasets (bijv mpool/zones/sickbeard/ROOT) die het root filesystem bevatten maar administratieve handelingen als zpool destroy of zfs snapshot falen (in de zone).

[FireDrunk]

Als je de daadwerkelijke stromen van SickBeard, SabNZBd enzo wil begrijpen, kan ik je dat best eens via PM uitgebreid uitleggen, maar wat jij zegt klopt al aardig, alleen zit daar de API koppelingen nog niet bij in.

Waar het mij meer om gaat is:

Als je zones al bij je ZFS Filesystems kunnen, en daar mogen schrijven, wat heeft het dan nog voor zin om de applicaties binnen zones te plaatsen? Ik draai ze hier gewoon native, maar uiteraard niet onder root.

Het is natuurlijk mooi dat je de resources kan beperken van de zones, maar ik heb dat eerlijk gezegd niet nodig. In mijn geval denk ik dus niet dat zones een substantieel voordeel is...

[Pantagruel]

HyperBart schreef op vrijdag 08 mei 2015 @ 14:48:
[...]


Yes! Morgen!

Van harte met de en t feest

[FREAKJAM]

Interessante post tvwes! Ik had je vraag al voorbij zien komen in het sab/cp topic en dat je opzoek was naar iemand die wist uit te leggen hoe de techniek precies in elkaar steekt.

Uiteindelijk wil ik toch van VMWare in combinatie met een ZFS VM af en gewoon direct op de bare metal laag KVM draaien met ZFS. Heb al wat gelezen over SmartOS, CoreOS en dergelijke maar moet nog even een goed geschikt OS vinden. Iets met een webschilletje erom heen is toch wel gewenst.

[tvwes]

FireDrunk schreef op vrijdag 08 mei 2015 @ 15:16:
Als je de daadwerkelijke stromen van SickBeard, SabNZBd enzo wil begrijpen, kan ik je dat best eens via PM uitgebreid uitleggen, maar wat jij zegt klopt al aardig, alleen zit daar de API koppelingen nog niet bij in.

Waar het mij meer om gaat is:

Als je zones al bij je ZFS Filesystems kunnen, en daar mogen schrijven, wat heeft het dan nog voor zin om de applicaties binnen zones te plaatsen? Ik draai ze hier gewoon native, maar uiteraard niet onder root.

Het is natuurlijk mooi dat je de resources kan beperken van de zones, maar ik heb dat eerlijk gezegd niet nodig. In mijn geval denk ik dus niet dat zones een substantieel voordeel is...

Binnen een zone heb je alleen toegang tot wat je kan mounten. Als de global-zone niet iets doorgeeft is er geen toegang. Stel dat je ook timemachine backups host op je nas dan kunnen deze zones (uit mijn voorbeeld) daar niet bij. Zij kunnen alleen bij /mpool/media en weten uberhaubt niet van het bestaan van /mpool/timemachine af. Je kan wel zfs list doen in de zone maar ziet maar een subset.
Als jij een configuratie fout maakt of lui bent en iets snel even aan de gang maakt en het als root laat draaien in een zone dan kan er nooit meer misgaan dan waar de zone bij kan. En standaard is dat nergens, jij moet expliciet filesystems doorgeven.
Daarnaast is het testen en eventueel ongedaan maken van upgrades (van applicaties binnen zones) supersimpel. Eigenlijk net als vmware snapshot's (alleen zonder geheugen state). Bevalt het niet dan doe je een rollback. Ik heb veel klachten gezien dat er vaak kapotte upgrades zijn bij apps als SB en SAB.
Ook is het veel schoner om specifieke versies van dependencies erop na te houden met zones. Je kan in de een zone python 2.6 en de andere python 3 installeren zonder al te moeilijk te moeten doen.
Ik denk dat het wel een substantieel voordeel is. Ik ken ook bijna niemand die niet z'n apps in een zone draait. De overhead is bijna nul en de voordelen zijn talrijk. Het enige wat je vanuit de global zone doet zijn NAS taken als iSCSI, NFS en CIFS. Sinds kort kan je ook CIFS shares aanmaken vanuit je zones.

Misschien heb ik het niet goed uitgelegd maar de voordelen om iets in een zone te draaien zijn echt heel groot. En de kosten (tijd en resources) zijn heel laag, dus ik zie weinig redenen om het niet te doen. Nieuwe clone vanaf een moeder zone zijn drie commando's die ik een scriptje heb staan.

code:

zonecfg -z master export | sed 's/master/sickbeard/g' | tee sickbeard.conf
zonecfg -z sickbeard -f sickbeard.conf
zoneadm -z sickbeard clone master

In een script heb je een seconde later een nieuwe zone.
En als je wil kan je natuurlijk een complete zpool doorgeven aan je zone, maar of dat een goed idee is weet ik niet.

FreeNAS doet dit ook, SB en SAB worden daar ook in een jail gestopt. Jails lijken op zones. Zones zijn alleen zoveel makkelijker te beheren dan jails, los van wat subtiele andere features.

Ik hoop dat ik het nu beter heb uitgelegd. Vragen en opmerkingen? Graag.

[FREAKJAM]

Een zone is eigenlijk hetzelfde als een docker of lxc (linux container) toch?
sorry als ik off-topic ga.

Ik share nu alles via zfs + nfs trouwens.

Op mijn ZFS VM share ik de boel:

code:

sudo zfs get sharenfs
NAME            PROPERTY  VALUE                                                                      SOURCE
tank            sharenfs  off                                                                        default
tank/backup     sharenfs  rw=@10.10.0.90/24,async,no_subtree_check,no_root_squash                    local
tank/downloads  sharenfs  rw=@10.10.0.70/24,async,no_subtree_check,no_root_squash                    local
tank/kodi       sharenfs  off                                                                        default
tank/movies     sharenfs  rw=@10.10.0.40/24,rw=@10.10.0.80/24,async,no_subtree_check,no_root_squash  local
tank/music      sharenfs  rw=@10.10.0.40/24,rw=@10.10.0.80/24,async,no_subtree_check,no_root_squash  local
tank/photos     sharenfs  ro=@10.10.0.40/24,async,no_subtree_check,no_root_squash                    local
tank/pms        sharenfs  rw=@10.10.0.40/24,rw=@10.10.0.50/24,async,no_subtree_check,no_root_squash  local
tank/tvshows    sharenfs  rw=@10.10.0.40/24,rw=@10.10.0.80/24,async,no_subtree_check,no_root_squash  local

Op de clients mount ik alles via /etc/fstab. Op deze manier hou ik toch alles een soort van gescheiden. Een aantal servers zijn zich namelijk bewust van bijvoorbeeld tank/pms maar een aantal ook weer niet.

[ Voor 150% gewijzigd door FREAKJAM op 08-05-2015 16:48 ]

[FireDrunk]

Dat heb ik ook heel lang gehad, maar dat gaat altijd stuk als je je nas reboot. Dan valt nfs weg en gaan al die applicaties op hun smoel.

Juist dat (en de performance) was voor mij een reden om naar native over te gaan.

Plus het feit dat ESXi ruk is qua verbruik

[FREAKJAM]

Oh, bij mij doet alles het netjes na een reboot! (CentOS 7). Echt heel soms moet ik mount -a opnieuw draaien op de clients, maar dat komt zo weinig voor dat ik me het niet eens kan herinneren. Je draait nu dus Fedora 21 met ZFS en KVM?

[ Voor 61% gewijzigd door FREAKJAM op 08-05-2015 16:52 ]

[HyperBart]

Pantagruel schreef op vrijdag 08 mei 2015 @ 16:02:
[...]


Van harte met de en t feest

Dank je . We hopen dat het weer morgen wat mee zit!

FireDrunk schreef op vrijdag 08 mei 2015 @ 16:49:
Dat heb ik ook heel lang gehad, maar dat gaat altijd stuk als je je nas reboot. Dan valt nfs weg en gaan al die applicaties op hun smoel.

Juist dat (en de performance) was voor mij een reden om naar native over te gaan.

Plus het feit dat ESXi ruk is qua verbruik

Dat zijn dus nu eigenlijk allemaal dingen die tvwes via een andere set van gereedschap dus eigenlijk allemaal opgelost heeft.

Ik ben alleen benieuwd hoe makkelijk het weer te beheren gaat zijn, er lijkt al weer een heel steile leercurve zich aan te dienen om dit soort dingen te beheren of bij probleempjes wat te fixen...

[ Voor 13% gewijzigd door HyperBart op 08-05-2015 16:53 ]

[FREAKJAM]

@HyperBart

Geniet van je dag morgen!

[tvwes]

FREAKJAM schreef op vrijdag 08 mei 2015 @ 16:08:
Interessante post tvwes! Ik had je vraag al voorbij zien komen in het sab/cp topic en dat je opzoek was naar iemand die wist uit te leggen hoe de techniek precies in elkaar steekt.

Uiteindelijk wil ik toch van VMWare in combinatie met een ZFS VM af en gewoon direct op de bare metal laag KVM draaien met ZFS. Heb al wat gelezen over SmartOS, CoreOS en dergelijke maar moet nog even een goed geschikt OS vinden. Iets met een webschilletje erom heen is toch wel gewenst.

SmartOS is zeker een interessant alternatief voor vSphere. Het is technisch is helemaal top, maar niet helemaal direct bestemd voor de thuis gebruiker. Het is ontwikkeld voor een datacenter voor het hosten van applicaties en niet als algemeen OS. Je ziet dat terug in tal van keuzes. Bijvoorbeeld dat je het niet echt kan installeren nauwelijks support voor de global-zone. Maar dank zij zones (en de minimale overhead die daar bij hoort) kan je op SmartOS machines veel meer "huurders", applicaties en VM's kwijt dan op andere systemen. vSphere of KVM komen nooit aan zo'n dichtheid, juist die efficientie maakt dat het bedrijf achter SmartOS winstgevend is. Iets wat lang niet alle aanbieders kunnen waarmaken.
Ja je kan SmartOS prima installeren op je whitebox en van alles hosten. Maar je moet wel even de documentatie erop na slaan.
Helemaal super is dat je nu Centos en Ubuntu kan uitvoeren in een zone in SmartOS. Support voor andere distro's zal wel snel komen of is er al. Deze feature zal ook wel snel beschikbaar komen in de algemene Illumos kernel verwacht ik. Wat is het bijzondere hiervan? Nou dat je zonder virtualisatie je Linux kan draaien in SmartOS, eerder moest je hiervoor de kvm feature in SmartOS gebruiken. Wat zeker ook prima werkte maar nooit zo snel ging als native/bare metal
Omdat voor de meeste applicaties gewoon een port beschikbaar is in pkgsrc wordt bijna alles in native zones gehost. Alleen hele speciefieke gevallen, meestal binaries van commerciele paketten, heb je Linux nodig. Tot op heden deed je dat via kvm, nu kan je het in LX-zone draaien.

Voor wat betreft webschilletjes...
Natuurlijk heeft de GUI een plaats. En zeker voor dashboards ben ik er een groot voorstander van. Maar voor een enkele machine kan ik prima die paar die commando's copy pasten. Dan leer je ook nog wat.
Voor ZFS zijn wel schillen voor FReeBSD is FreeNAS een schil die ook jails kan maken. Op SDC na is er bij mijn weten niet iets voor zone's. Maar gezien de doelgroep en de eenvoud snap ik ook waarom dat er niet is.

FREAKJAM schreef op vrijdag 08 mei 2015 @ 16:26:
Een zone is eigenlijk hetzelfde als een docker of lcx (linux container) toch?

Linux containers , FreeBSD Jails en Solaris Zones zijn allemaal vergelijkbaar. De verschillen zijn subtiel, maar reeel. Een ding hebben ze gemeen, de (cpu) overhead is bijna nihil. En dat is de kracht tov virtualisatie. Docker is een framework wat alle management taken zoals container creation en deployment regelt. Het is een hogere laag bovenop het OS. Overigens is Docker nu ook beschikbaar op SmartOS.

[tvwes]

LETOP onderstaand verhaal is alleen interessant voor diegene die block storage gebruiken, zoals iSCSI.

Vraag maar eens een @Hyperbart wat een top performance ik haalde met mijn Illumos iSCSI target, multipath via GBit en 4G FC!!! om vSphere datastores te hosten. Ik geloof dat ik met twee 5400rpm mirror sneller was dan zijn SSD's in de meeste gevallen. In de echte random testen verlies ik het.
Die howto is ook inprincipe klaar. Het accent lag natuurlijk op die fibrechannel support. Ik liet zien hoe je heel goedkoop een san kan maken, op basis van FC. Goedkoop en stil want zonder FC switch. Wel max 4 clients. Maar wel per client een eigen poort, dus 4x volle bandbreedte. Leuk voor je vmware lab of video editing. Veel sneller dan GBit ethernet en veel goedkoper dan 10GBit ethernet. Hoe koop per client een 1 poort 4G FC kaartje, ong 20EUR marktplaats of ebay. En een 1,2 of 4 poort kaart voor je server. Die haal je het beste van ebay. 8G FC kan ook maar is duurder. Multimode FC kabel kost ook bijna niks.
Paar commando's en voila een volwaardig san voor ongeveer 100EUR. Bied je de lun ook aan via iSCSI dan heb je een redundant multipath gemaakt. vSphere herkent de paden direct. Trek je de glasvezel eruit dan schakelt het over op het langzame gbit, of omgekeerd. NIET op round robin zetten want dan gaat het verkeer de helft van de tijd over het langzame gbit.
Deze eenvoud en performance haal je op geen ander OS.

[tvwes]

HyperBart schreef op vrijdag 08 mei 2015 @ 16:52:
Dat zijn dus nu eigenlijk allemaal dingen die tvwes via een andere set van gereedschap dus eigenlijk allemaal opgelost heeft.

Ik ben alleen benieuwd hoe makkelijk het weer te beheren gaat zijn, er lijkt al weer een heel steile leercurve zich aan te dienen om dit soort dingen te beheren of bij probleempjes wat te fixen...

Nee, de learing curve is ongeveer nul.
Ik heb alles getest en gedocumenteerd. Alle ins en outs over SMF manifests hoef je natuurlijk niet te weten. Straks kan je mijn git repo clonen en wat scripts draaien en klaar.
En voor het beheer zijn er wat oneliners voor alledaagse taken. Zoals het aan maken van een lun. Of het stoppen van een zone of clonen van een zone. Nee het valt allemaal reuze mee.
Voorlopig kan je denk ik prima vooruit zonder gui. En je SickBeard en anderen hebben natuurlijk hun eigen gui.

Disclaimer: ik pretendeer niet dat ik de ultimate SickBeard doos heb gemaakt. Wel laat ik zien hoe je zoiets kan maken, door bruikbare bouwstenen aan te bieden. Hoe je die uiteindelijk configureert is aan ieder zelf.

[ Voor 10% gewijzigd door tvwes op 08-05-2015 17:32 ]

[FireDrunk]

De learning curve is niet nul. Een goede beheerder weet wat commando's onder water doen.
Dat iets weinig commando's kost om voor elkaar te krijgen wil niet zeggen dat iets simpel is.
Het principe van Zones/Jails is niet altijd even makkelijk te begrijpen voor de reguliere gebruiker.

Uiteraard is het mooi dat als je een concept begrijpt je het met maar een paar commando's kan implementeren.

Maar datzelfde geld voor het compileren van de Linux kernel, dat kost je maar 2 commando's, maar je moet wel degelijk snappen waar je mee bezig bent.

[HyperH]

inleiding:
Ik wil graag een betrouwbaar systeem om mijn data zo veilig mogelijk te kunnen opslaan. Mijn huidige workflow functioneert niet goed heb ik gemerkt.

Mijn situatie is als volgt. Ik heb nu deze apparatuur:

• Werk-laptop
• Privé-Laptop
• Desktop

De werk-laptop wordt hoofdzakelijk op het werk gebruikt, maar gaat altijd mee naar huis om thuis bijvoorbeeld nog wat te kunnen voorbereiden, mail te checken etc.

Mijn privé-laptop wordt voor de normale thuis dingetjes gebruikt, zoals internetten, emaillen etc. Ik speel ook in een band en gebruik de laptop regelmatig bij het jammen. We maken ook vaak audio opnames om later dan weer mee te knutselen. Behalve de muziek ben ik veel bezig met fotografie.

Mijn privé laptop genereert dus veel data en laptop HDD's zijn nu eenmaal minder groot dan desktop HDD's.
Daarom maak ik veel backups met rsync naar de desktop zodat de laptop HDD dan weer kan worden opgeschoond. De desktop wordt nu eigenlijk voor niets anders meer gebruikt dan het opslaan van alle belangrijke backups.

Ik heb ook een externe usb-HDD waar ik de belangrijkste bestanden ook met rsync naar toe schrijf vanaf de desktop. De belangrijkste data is dus op twee verschillende schijven opgeslagen.
Helaas heb ik gemerkt dat dit niet foolproof is en dat er toch enkele bestanden corrupt zijn geraakt in beide backups.

Ik ben tot de conclusie gekomen dat ik mijn data beter in ZFS kan opslaan. Aangezien ik toch al meer HDD ruimte nodig ben om onze huidige data produktie te kunnen bewaren heb ik het plan opgevat om zelf een NAS te gaan bouwen met ZFS.

Vragen:

[1] In mijn huidige workflow rsync ik data naar de desktop. Deze data wordt alleen geaccessed wanneer ik het nodig ben. Dan kopieer ik de data terug naar mijn laptop HDD om bijvoorbeeld audio te bewerken of foto's te bekijken c.q. bewerken. Er zijn dus geen devices die per ongeluk de originele data kunnen veranderen.
Eigenlijk zou ik het nog te bouwen NAS systeem wel wat breder willen inzetten. Het zou super zijn als ik de data niet eerst terug naar de laptop hoef te kopiëren voor ik de foto's ga bekijken of audio wil luisteren. Kan ik beide laptops de NAS als remote HDD laten benaderen of moet ik vasthouden aan mijn oude workflow?

[2] Stel dat ik de data twee keer opsla op de NAS. Een backup met bestanden die ik origineel wil houden. Een kopie van die backup zou dan in bijvoorbeeld een smb share geplaatst kunnen worden. Dit idee heb ik zodat mijn laptops, maar ook mijn TV bijvoorbeeld dan de bestanden in die share kunnen accessen zonder risico dat de backup (die elders op de ZFS HDD's is opgeslagen) wordt aangetast bij eventuele aanpassingen.
Wat gebeurt er dan echter als deduplication geactiveerd is? Zou dat deze geschetste situatie kunnen of loop ik daarmee dan toch het risico dat de originele backup wordt aangetast bij het bewerken van de kopieën in de share?

[3] Ik ben er van overtuigd dat ZFS betrouwbaarder gaat zijn. Toch zal ik voor de zekerheid nog wel de belangrijkste data naar een externe HDD backuppen.
Zou het dan verstandig zijn om die externe HDD dan ook als ZFS te formatteren?

[Verwijderd]

HyperH, proficiat voor de mooiste first-post. Je doet precies zoals het hoort.

Antwoord op je vragen:

• 1) het makkelijkst is natuurlijk wanneer je de data op ZFS gewoon direct aanspreekt, bijvoorbeeld met Samba (CIFS) oftewel Windows filesharing, or met NFS in geval van Linux. Bovendien, kun je bij ZFS beter ZFS send/receive gebruiken in plaats van rsync. Dan gebruik je de native checksums van ZFS en haal je ook alle metadata mee en instellingen, ipv alleen de data. Maar ik zou send/receive voor je backup inzetten, en je laptops en desktop gewoon direct op de share laten werken. Let wel dat Photoshop en andere Adobe-programma's niet altijd een netwerkdrive accepteren. In dat geval zijn er trucjes om je netwerkdrive als local drive te laten zien, of je moet ipv Samba (CIFS) naar iSCSI overstappen. Nadeel is dan wel dat je in feite NTFS filesystem bovenop ZFS draait. Dan kan ZFS intact zijn maar je NTFS filesystem nog steeds corrupt. Het is geen ideale opstelling. Maar je kunt ook prima beide doen; iSCSI voor Adobe en de rest allemaal Samba. Dan staan de bestanden direct op ZFS en genieten die dus ook alle bescherming van ZFS.
• 2) de-duplication werkt pool-wide. Dus filesystem x en filesystem y delen dus dezelfde dedup-table. Maar dit werkt niet tussen pools; die hebben elk hun eigen dedup-table. Met de-duplicatie heb je inderdaad maar één locatie voor bijvoorbeeld twee files op filesystem x en y. Maar het is vooral erg traag en behalve in zeer specifieke situaties kun je beter geen de-duplicatie gebruiken! Gebruik wel LZ4-compressie, dat is snel en kost je niet de extreme resources die de-duplication vraagt.
• 3) Zeker kan je externe schijf ook ZFS worden. Het grote voordeel is dan dat je ZFS Send/Receive kunt gebruiken. Dan werk je met native checksums. Dus corruptie tijdens het overzetten zou dan niet voor mogen komen. Als de actie voltooid is zonder error, zou dat moeten betekenen dat de files ook echt intact zijn overgekomen. Bij rsync is dit normaliter niet het geval; alleen de -c checksum optie doet dat maar dit is zeer traag bij grote hoeveelheden data omdat rsync dat elke keer opnieuw moet doen. ZFS weet zelf al checksums, dus dit werkt gewoon veel beter.
  Bovendien kun je met ZFS snapshots heel mooi gebruiken. Snapshots zijn een soort foto van het filesystem, waarna je altijd terug kunt. Exact zoals de bestanden toen waren. dus mutaties, veranderde filenamen, verwijderde bestanden; alles komt weer tevoorschijn als je een snapshot bekijkt. Dat werkt zo: je maakt eerst een snapshot en daarna kun je die als een read-only directory benaderen, of het hele filesystem terug laten zetten naar precies dat punt. Uiteindelijk kun je hiermee incremental backups maken van zeer hoge kwaliteit.

Succes!

[tvwes]

Helemaal mee eens. En vergeet niet dat zfs send en receive meestal veel sneller is dan rsync (ongeacht de opties). ZFS heeft de delta's immers al, dankzij de COW architectuur.
Toch blijft rsync erg handig, platform onafhankelijk en een herstart is mogelijk terwijl zfs send en receive een "alles of niets" actie is. Als het zfs send en receive faalt moet je weer opnieuw beginnen. Dat moet bij rsync ook maar daar hoef je alleen nog de data over te sturen die je mist, bij zfs moet je weer opnieuw beginnen.

[FireDrunk]

HyperH schreef op maandag 11 mei 2015 @ 00:46:
Vragen:

\[1] In mijn huidige workflow rsync ik data naar de desktop. Deze data wordt alleen geaccessed wanneer ik het nodig ben. Dan kopieer ik de data terug naar mijn laptop HDD om bijvoorbeeld audio te bewerken of foto's te bekijken c.q. bewerken. Er zijn dus geen devices die per ongeluk de originele data kunnen veranderen.
Eigenlijk zou ik het nog te bouwen NAS systeem wel wat breder willen inzetten. Het zou super zijn als ik de data niet eerst terug naar de laptop hoef te kopiëren voor ik de foto's ga bekijken of audio wil luisteren. Kan ik beide laptops de NAS als remote HDD laten benaderen of moet ik vasthouden aan mijn oude workflow?

Een ZFS Snapshot maken hier lijkt mij ideaal. Je logt in op je server (of je gebruikt een webinterface zoals ZFSguru) voordat je aan de slag gaat, en maakt een snapshot van je werk directory. Ben je tevreden over het resultaat, prima, lekker laten staan. Wil je iets terughebben, kan je de snapshots terugrollen of de snapshot directory openen om je files terug te halen.

\[2] Stel dat ik de data twee keer opsla op de NAS. Een backup met bestanden die ik origineel wil houden. Een kopie van die backup zou dan in bijvoorbeeld een smb share geplaatst kunnen worden. Dit idee heb ik zodat mijn laptops, maar ook mijn TV bijvoorbeeld dan de bestanden in die share kunnen accessen zonder risico dat de backup (die elders op de ZFS HDD's is opgeslagen) wordt aangetast bij eventuele aanpassingen.
Wat gebeurt er dan echter als deduplication geactiveerd is? Zou dat deze geschetste situatie kunnen of loop ik daarmee dan toch het risico dat de originele backup wordt aangetast bij het bewerken van de kopieën in de share?

Waarom niet gewoon een snapshot? Je kan zelfs (als je wil) een specifiek snapshot delen via SMB. Maar aan de andere kant, waarom zou je? Je kan veel beter snapshots synchroniseren tussen systemen ipv de 'live' filesystems.

\[3] Ik ben er van overtuigd dat ZFS betrouwbaarder gaat zijn. Toch zal ik voor de zekerheid nog wel de belangrijkste data naar een externe HDD backuppen.
Zou het dan verstandig zijn om die externe HDD dan ook als ZFS te formatteren?

Ja en nee, dat ligt aan het protocol. Persoonlijk heb ik slechte ervaringen met USB(2/3). Maar eSATA zou bijvoorbeeld perfect moeten werken.

Er zijn genoeg mensen waar ZFS wel goed werkt, dus het zal waarschijnlijk aan het chipset gelegen hebben. (in mijn geval JMicron).

Het advies hier is dus: kijk even goed welk chipset je externe schijf gebruikt, en zoek online of er meer mensen zijn die ZFS gebruiken icm dat chipset.

[Xudonax]

HyperH schreef op maandag 11 mei 2015 @ 00:46:
\[2] Stel dat ik de data twee keer opsla op de NAS. Een backup met bestanden die ik origineel wil houden. Een kopie van die backup zou dan in bijvoorbeeld een smb share geplaatst kunnen worden. Dit idee heb ik zodat mijn laptops, maar ook mijn TV bijvoorbeeld dan de bestanden in die share kunnen accessen zonder risico dat de backup (die elders op de ZFS HDD's is opgeslagen) wordt aangetast bij eventuele aanpassingen.
Wat gebeurt er dan echter als deduplication geactiveerd is? Zou dat deze geschetste situatie kunnen of loop ik daarmee dan toch het risico dat de originele backup wordt aangetast bij het bewerken van de kopieën in de share?

Ik zou even moeten kijken hoe het ook al weer precies zat, maar je kunt Samba vertellen dat iedere keer dat er een verbinding gemaakt word er een nieuw ZFS snapshot gemaakt moet worden. Hierdoor heb je automatisch "backups", zeker als je dit combineert met een snapshot welke iedere 30 minuten aangemaakt word.

Backup tussen aanhalingstekens, want als je pool dood neervalt ben je natuurlijk alsnog alles kwijt.

EDIT: Oh, en met de juiste opties kun je de snapshots beschikbaar maken als Windows Shadow Copy, waardoor je vanuit Windows vanzelf de oude snapshots kunt bekijken Samba 4 heeft een hoop van dit soort leuke features erin zitten

[ Voor 9% gewijzigd door Xudonax op 11-05-2015 10:41 ]

[HyperBart]

Xudonax schreef op maandag 11 mei 2015 @ 10:40:
[...]


Ik zou even moeten kijken hoe het ook al weer precies zat, maar je kunt Samba vertellen dat iedere keer dat er een verbinding gemaakt word er een nieuw ZFS snapshot gemaakt moet worden. Hierdoor heb je automatisch "backups", zeker als je dit combineert met een snapshot welke iedere 30 minuten aangemaakt word.

Backup tussen aanhalingstekens, want als je pool dood neervalt ben je natuurlijk alsnog alles kwijt.

EDIT: Oh, en met de juiste opties kun je de snapshots beschikbaar maken als Windows Shadow Copy, waardoor je vanuit Windows vanzelf de oude snapshots kunt bekijken Samba 4 heeft een hoop van dit soort leuke features erin zitten

Mag je altijd eens laten weten hoe je dat werkend krijgt, op OpenIndiana is dat ooit gelukt, maar met Ubuntu nog niet...

[CurlyMo]

@HyperBart, http://www.oreilly.com/openbook/samba/book/ch06_06.html kopje 6.6.4.

[FireDrunk]

Das eigenlijk best handig voor User Home directories

[HyperBart]

CurlyMo schreef op dinsdag 12 mei 2015 @ 13:40:
@HyperBart, http://www.oreilly.com/openbook/samba/book/ch06_06.html kopje 6.6.4.

Ik had het eigenlijk over het publiceren van snapshots via SMB als Previous Versions

[Xudonax]

Dan moet ik even graven, volgens mij heb ik het ooit opgebouwd aan de hand van Daniel Washburn - FreeBSD + Samba 4 + ZFS Recipe. Let wel op dat je de ACL spullen niet wilt hebben tenzij je aan de gang gaat met een Windows AD omgeving.

Komt er op neer dat je dit bij iedere share moet neerzetten waar je de functionaliteit wilt:

code:

[public]
    path = /export/CIFSRoot
    public = yes
    guest only = yes
    guest ok = yes
    writable = yes
    read only = no

    ## Enable the zfsacl and shadow_copy2 modules for this share
    vfs objects = zfsacl shadow_copy2

    ## Hide the .zfs directory from clients
    veto files = /.zfs/
    delete veto files = yes

    ## Present the contents of the .zfs/snapshot directory as Volume Shadow
    ## copies. These will appear as Previous Versions to Windows clients.
    shadow:snapdir = .zfs/snapshot
    shadow:format = %Y-%m-%d
    shadow:sort = desc

Vervolgens kun je dan met de root preexec dan een snapshot maken zodra er verbinding gemaakt word, zoals CurlyMo ook al aangeeft. Om het helemaal fancy te maken kun je met de root postexec weer een oude snapshot terugzetten. Ik weet niet waarom je dat zou willen, maar dat is een voorbeeld welke ik eens gevonden had bij de demonstratie van deze functionaliteit

Dit doet me er trouwens aan denken dat ik dit ook weer moet instellen voor mijn nieuwe installatie, de meuk draait nu niet meer op Fedora bij mij maar op CentOS. Het lijstje met issues dat ik met Fedora had was niet leuk meer

EDIT: Bedenk trouwens wel dat je de snapshots de juiste naam moet geven, deze krijg je met behulp van date +"%Y-%m-%d". Echter, ik vond het ook wel prettig om de uren, minuten en seconden erbij te hebben. Mijn datespec was dus %Y-%m-%d %H:%M:%S voor zowel Samba als date. Mijn exacte snapshot scripts ben ik helaas wel verloren, maar dat kost niet zo heel veel moeite om te schrijven, toch?

[ Voor 15% gewijzigd door Xudonax op 12-05-2015 14:14 ]

[FireDrunk]

En die post is bookmarked Thanks!

[HyperH]

Verwijderd schreef op maandag 11 mei 2015 @ 01:00:

1) het makkelijkst is natuurlijk wanneer je de data op ZFS gewoon direct aanspreekt, bijvoorbeeld met Samba (CIFS) oftewel Windows filesharing, or met NFS in geval van Linux.

Direct de data op ZFS aanspreken zou inderdaad mooi zijn, omdat je dan van alle mooie ZFS functies kunt profiteren. Gevoelsmatig vind ik het direct werken op de files van de backup geen goed idee. Ongemerkt kunnen er wijzigingen optreden die je ontgaan.

Bovendien, kun je bij ZFS beter ZFS send/receive gebruiken in plaats van rsync. Dan gebruik je de native checksums van ZFS en haal je ook alle metadata mee en instellingen, ipv alleen de data. Maar ik zou send/receive voor je backup inzetten, en je laptops en desktop gewoon direct op de share laten werken.

De send/receive mogelijkheid kende ik helemaal niet. Ik heb er nu een artikel over gelezen en hoewel ik het concept snap moet ik er nog meer tijd aan besteden voor het helemaal duidelijk is. Het is wel een hele vette feature die ik graag zou willen gaan gebruiken!

Let wel dat Photoshop en andere Adobe-programma's niet altijd een netwerkdrive accepteren. In dat geval zijn er trucjes om je netwerkdrive als local drive te laten zien, of je moet ipv Samba (CIFS) naar iSCSI overstappen. Nadeel is dan wel dat je in feite NTFS filesystem bovenop ZFS draait. Dan kan ZFS intact zijn maar je NTFS filesystem nog steeds corrupt. Het is geen ideale opstelling. Maar je kunt ook prima beide doen; iSCSI voor Adobe en de rest allemaal Samba. Dan staan de bestanden direct op ZFS en genieten die dus ook alle bescherming van ZFS.

Maar kan dat wel tegelijk? Ik dacht dat met iSCSI een netwerkschijf als een lokale schijf geëmuleerd wordt? Die HDD is dan exclusief aan één systeem toegekend. Dan kunnen andere processen geen toegang meer hebben tot die schijf toch?

2) de-duplication werkt pool-wide. Dus filesystem x en filesystem y delen dus dezelfde dedup-table. Maar dit werkt niet tussen pools; die hebben elk hun eigen dedup-table. Met de-duplicatie heb je inderdaad maar één locatie voor bijvoorbeeld twee files op filesystem x en y. Maar het is vooral erg traag en behalve in zeer specifieke situaties kun je beter geen de-duplicatie gebruiken! Gebruik wel LZ4-compressie, dat is snel en kost je niet de extreme resources die de-duplication vraagt.

De-duplication laat ik dan maar voor wat het is. LZ4-compressie is interessant, maar ben je eigenlijk wel vier cpu cores voor nodig om je data troughput niet te veel in te laten zakken las ik?
Eigenlijk zou ik ook wel een deel van de backup willen encrypten en dan ben je een processor met hardwarematige AES iondersteuning nodig. Dan zou je al snel op een i5 of i7 uitkomen ook met meerdere cores dus dat is dan complementerend aan elkaar.

3) Zeker kan je externe schijf ook ZFS worden. Het grote voordeel is dan dat je ZFS Send/Receive kunt gebruiken. Dan werk je met native checksums. Dus corruptie tijdens het overzetten zou dan niet voor mogen komen. Als de actie voltooid is zonder error, zou dat moeten betekenen dat de files ook echt intact zijn overgekomen. Bij rsync is dit normaliter niet het geval; alleen de -c checksum optie doet dat maar dit is zeer traag bij grote hoeveelheden data omdat rsync dat elke keer opnieuw moet doen. ZFS weet zelf al checksums, dus dit werkt gewoon veel beter.
Bovendien kun je met ZFS snapshots heel mooi gebruiken. Snapshots zijn een soort foto van het filesystem, waarna je altijd terug kunt. Exact zoals de bestanden toen waren. dus mutaties, veranderde filenamen, verwijderde bestanden; alles komt weer tevoorschijn als je een snapshot bekijkt. Dat werkt zo: je maakt eerst een snapshot en daarna kun je die als een read-only directory benaderen, of het hele filesystem terug laten zetten naar precies dat punt. Uiteindelijk kun je hiermee incremental backups maken van zeer hoge kwaliteit.
Succes!

Het klinkt te mooi om waar te zijn! Ik zou bijna willen dat ik op mijn laptops ook ZFS kon gebruiken.
Kun je de read-only directory representaties van de snapshots non-lineair in de tijd benaderen of alleen de voorlaatste versie?
Dan zou je het bijna als een versiebeheer systeem kunnen inzetten voor projecten.

[CurlyMo]

Wat betreft je laatste vraag Non-linear. Voor versiebeheer zijn snapshots inderdaad ideaal.

[HyperH]

FireDrunk schreef op maandag 11 mei 2015 @ 10:24:
[...]
Een ZFS Snapshot maken hier lijkt mij ideaal. Je logt in op je server (of je gebruikt een webinterface zoals ZFSguru) voordat je aan de slag gaat, en maakt een snapshot van je werk directory. Ben je tevreden over het resultaat, prima, lekker laten staan. Wil je iets terughebben, kan je de snapshots terugrollen of de snapshot directory openen om je files terug te halen.

Het is natuurlijk wel zo dat ik niet altijd toegang heb tot de server. In de studio of oefenruimte hebben we geen internetverbinding om contact te kunnen maken met de server thuis. Dan moet ik dus lokaal / offline kunnen werken.

[...]
Waarom niet gewoon een snapshot? Je kan zelfs (als je wil) een specifiek snapshot delen via SMB. Maar aan de andere kant, waarom zou je? Je kan veel beter snapshots synchroniseren tussen systemen ipv de 'live' filesystems.

Ik zal mij hier in verdiepen. Die snapshots klinken super handig.

[HyperH]

Xudonax schreef op maandag 11 mei 2015 @ 10:40:
[...]
Ik zou even moeten kijken hoe het ook al weer precies zat, maar je kunt Samba vertellen dat iedere keer dat er een verbinding gemaakt word er een nieuw ZFS snapshot gemaakt moet worden. Hierdoor heb je automatisch "backups", zeker als je dit combineert met een snapshot welke iedere 30 minuten aangemaakt word.

Backup tussen aanhalingstekens, want als je pool dood neervalt ben je natuurlijk alsnog alles kwijt.

Een pool die dood neervalt? Wat bedoel je daarmee precies? Gebeurt dat vaak?
Ik mag toch hopen dat wanneer de s-ata controller of het mobo van je NAS het begeeft dat ik de HDD's dan gewoon in een ander systeem kan hangen en de pool rebuilden? Dan raak je toch gaan data kwijt hoop ik? Of is dat een geïdealiseerde theorie en valt het in de praktijk nog wel eens tegen?

EDIT: Oh, en met de juiste opties kun je de snapshots beschikbaar maken als Windows Shadow Copy, waardoor je vanuit Windows vanzelf de oude snapshots kunt bekijken Samba 4 heeft een hoop van dit soort leuke features erin zitten

Ik ben hopeloos met Windows maar kan er helaas niet zonder i.v.m. de geluidskaart en scanner die alleen goede windowsdrivers hebben. Ook zijn er enkele software pakketten die alleen op windows goed draaien. Het laatste zou nog in een virtualmachine kunnen doch het eerstgenoemde niet.
Shadow copy ken ik niet. Ik ben geen Windows kenner. Mijn ervaringen met windows en backup tools zijn echter niet heel positief. Daarom wil ik graag een betrouwbaar backup systeem bouwen waar ik wel op kan vertrouwen.

[Xudonax]

HyperH schreef op woensdag 13 mei 2015 @ 00:09:
[...]

Een pool die dood neervalt? Wat bedoel je daarmee precies? Gebeurt dat vaak?
Ik mag toch hopen dat wanneer de s-ata controller of het mobo van je NAS het begeeft dat ik de HDD's dan gewoon in een ander systeem kan hangen en de pool rebuilden? Dan raak je toch gaan data kwijt hoop ik? Of is dat een geïdealiseerde theorie en valt het in de praktijk nog wel eens tegen?

Het zal niet vaak gebeuren, er zijn wat discussies geweest omtrent hoe waarschijnlijk dit is. Heeft vooral te maken met of je op tijd je schijven vervangt zodra dit aangegeven word en of je ECC gebruikt of niet. Vooral dat laatste leid tot wat verhitte discussies, je kunt er enkele terugvinden in de geschiedenis van het topic.

Kort samengevat, zolang je goed voor je machine en pool zorgt dan kan er weinig fout gaan.

HyperH schreef op woensdag 13 mei 2015 @ 00:09:
[...]

Ik ben hopeloos met Windows maar kan er helaas niet zonder i.v.m. de geluidskaart en scanner die alleen goede windowsdrivers hebben. Ook zijn er enkele software pakketten die alleen op windows goed draaien. Het laatste zou nog in een virtualmachine kunnen doch het eerstgenoemde niet.
Shadow copy ken ik niet. Ik ben geen Windows kenner. Mijn ervaringen met windows en backup tools zijn echter niet heel positief. Daarom wil ik graag een betrouwbaar backup systeem bouwen waar ik wel op kan vertrouwen.

Dit is een functionaliteit van ZFS welke op een handige manier aan Windows beschikbaar word gemaakt. Hetgeen dat het echte werk doet draait dus op je ZFS machine, Windows bied enkel een handige interface hiervoor. De moeite waard, vond ik. Zeker aangezien een snapshot je praktisch niets kost zolang de bestanden niet veranderen

[Paul]

HyperH schreef op dinsdag 12 mei 2015 @ 23:55:
Dan moet ik dus lokaal / offline kunnen werken.

Photoshop ken ik niet zo, in Lightroom kun je je catalog en smart previews op je lokale schijf zetten en de bron-bestanden op je NAS, zo doe ik het zelf ook Het meest recente werk staat wel lokaal maar op gegeven moment gaan die ook naar de NAS.

Ik laat Windows 8 met File History backups maken naar diezelfde NAS, en zowel de File History als de RAW-bestanden staan in een filesystem dat ik ZFS Zend naar een NAS bij mijn zwager. Ik ben enkel niet zo tevreden over File History; ik heb er geen grip op en als ik handmatig op die share ga kijken dan lijken er regelmatig zaken te missen, dus ik denk dat ik daarvoor iets anders ga zoeken

[Streamert]

Ik heb een vraag over log gebruik. Al enige tijd geleden is het me opgevallen dat er totaal geen log disk gebruikt wordt, ondanks dat deze wel netje geconfigureerd is. Zie de output van zpool iostat.

code:

                                                    capacity     operations    bandwidth
pool                                             alloc   free   read  write   read  write
-----------------------------------------------  -----  -----  -----  -----  -----  -----
pool1                                            4.40T  2.85T     12    276  20.0K  1.74M
  mirror                                         1.10T   729G      0     94      0  1.17M
    ata-WDC_WD2000FYYZ-01UL1B0_WD-WCC1P0067577       -      -      0     45      0  1.18M
    ata-WDC_WD2000FYYZ-01UL1B0_WD-WMC1P0023148       -      -      0     36      0   293K
  mirror                                         1.10T   729G      3      0  7.49K      0
    ata-WDC_WD2000FYYZ-01UL1B0_WD-WCC1P0060648       -      -      2      3  5.50K  4.00K
    ata-WDC_WD2000FYYZ-01UL1B1_WD-WCC1P1254574       -      -      0      3  2.00K  4.00K
  mirror                                         1.10T   728G      4     90  9.49K   291K
    ata-WDC_WD2000FYYZ-01UL1B0_WD-WCC1P0067941       -      -      1     36  3.50K   291K
    ata-WDC_WD2000FYYZ-01UL1B1_WD-WCC1P1326532       -      -      2     35  6.00K   291K
  mirror                                         1.10T   728G      3     90  3.00K   291K
    ata-WDC_WD2000FYYZ-01UL1B1_WD-WCC1P1323992       -      -      1     39  1.50K   295K
    ata-WDC_WD2000FYYZ-01UL1B0_WD-WCC1P0034568       -      -      1     37  1.50K   295K
logs                                                 -      -      -      -      -      -
  ata-M4-CT128M4SSD2_0000000012400917FA4B-part2      0  19.1G      0      0      0      0
cache                                                -      -      -      -      -      -
  ata-M4-CT128M4SSD2_0000000012400917FA4B-part1  93.5G  6.48G      7     13  9.99K  1.75M
-----------------------------------------------  -----  -----  -----  -----  -----  -----
pool2                                             139G  82.5G      0      0      0      0
  mirror                                          139G  82.5G      0      0      0      0
    wwn-0x5f8db4c144361621                           -      -      0      0      0      0
    wwn-0x5f8db4c144361938                           -      -      0      0      0      0
-----------------------------------------------  -----  -----  -----  -----  -----  -----

Dit alles draait op Ubuntu 14.04, naar volle tevredenheid moet ik zeggen.

[CurlyMo]

Er staat dat er 139G in gebruik is.

[Streamert]

Volgens mij kijk je bij pool2, waar geen log device gebruikt wordt. Zie:

code:

logs                                                 -      -      -      -      -      -
  ata-M4-CT128M4SSD2_0000000012400917FA4B-part2      0  19.1G      0      0      0      0

[CurlyMo]

Aha, klopt. Maak het mij dan makkelijker en plaats volgende keer een zpool iostat -v pool1

[Verwijderd]

log disks worden enkel gebruikt voor sync writes. Hoeveel I/O je log device krijgt hangt dus af van het soort writes dat je applicaties doen, en van de 'sync' instelling van het filesystem.

Doe maar eens:

zfs set sync=always <poolnaam>

En zie dan hoe je log device wel gebruikt wordt. Wel even terugzetten op de standaardwaarde:

zfs set sync=standard <poolnaam>

[Streamert]

Er begint me iets te dagen.... Volgens mij had ik dit uitgezet vanwege ESXi performance. Bedankt voor jullie reacties, het is me weer duidelijk.

[FireDrunk]

ESXi goed krijgen via NFS op ZFS is idd niet de makkelijkste opgave

[Verwijderd]

Je kunt de 'sync' setting per filesystem aanpassen. Dus je kunt sync=disabled op de filesystems die ESXi via NFS gebruikt. En sync=standard op de rest. Bedenk wel dat alles wat ESXi dan doet, onveilig is. Als er VM-images via ESXi->NFS->ZFS gaan, dan kunnen die inconsistent worden wanneer ZFS niet netjes wordt afgesloten. ZFS is dan helemaal intact, maar de data hoeft dat niet zo te zijn vanuit het perspectief van de applicatie.

[Hakker]

Ik had eigenlijk ondertussen wel gehoopt dat Tweakers met een artikel zou komen mbt tot smr schijven en hoe het zich houd als JBOD en in verschillende raid vormen als hardware, BTRFS en ZFS. In HDD's is het tenslotte iets nieuws wat we waarschijnlijk wel meer in de toekomst gaan zien. Behalve een halve reddit en 1 review van storagereview is er niet echt veel te vinden. En echte stress tests heb ik nog niet echt kunnen vinden.

[Verwijderd]

Genoeg reden om ze voorlopig links te laten liggen, zoveel goedkoper per TB zijn ze niet. Met ZFS zouden ze het nog best aardig kunnen doen, omdat ZFS random writes als sequential writes wegschrijft. De random reads zijn minder ernstig dan random writes, waarbij de schijf eerst moet gaan lezen en de I/O dus in 3-fasen moet gebeuren (read-modify-write). Traditioneel RAID5 zou best wel eens erg traag kunnen zijn zodra je wat random writes krijgt. Want RAID5 heeft vanzichzelf al een read-modify-write. Het zou zo maar kunnen dat bepaalde configuraties extreem traag zijn, door een amplificatie van performance-issues.

Ik ben in elk geval geen voorstander van dit soort schijven. Vraag is ook hoe het met uBER en retentie zit. Beter even de kat uit de boom kijken, totdat er meer bekend is over deze schijven en ze gunstiger worden geprijsd.