Het grote ZFS topic

[leuk_he]

Splendid schreef op maandag 20 juni 2011 @ 10:23:
[...]

Jawel, maar het ligt even stil. Ze schieten niet op met OI 151

Wat ik eigenlijk niet kan vinden is een goede changelog. want

quote: http://wiki.openindiana.org/oi/oi_151

* More kernel and ZFS bug patches from Illumos_gate project

Verwijst dus min of meer naar het illumos, kernel project, waar ik dus geen samenvatting van kan vinden wat er anders is tussen 148 en 151 (zit de Oracle express encryption support er b.v. al in?)

[Anoniem: 15758]

ZFS encryption zit in ZFS v30 en die is voor zover ik weet nog niet als CDDL vrijgegeven.

[BOUBOU]

Ik ben nav. een corrupte usb stick begonnen met een herinstall van Freenas.
Na afloop van de herinstall is het mij gelukt de bestaande pool opnieuw te importeren via de web gui.
Op de pool \tank was echter een ook een dataset media en een dataset ftp aangemaakt, beide zijn nog wel aanwezig op \tank, maar zijn niet zichtbaar binnen de Freenas webgui.

Ik heb mij een ongeluk gezocht naar het juist commandline commando om deze opnieuw te importeren.

Heeft iemand enig idee of er ergens een howto te vinden is waarin dergelijke commando's terugkomen?

Wellicht dat deze url ook in de startpost kan worden opgenomen.

[Anoniem: 15758]

Met dataset bedoel je filesystem?

Heb je zpool status en zfs list commando's gebruikt om te kijken wat voor filesystems je hebt? Wat heb je al geprobeerd en wat lukt er precies niet?

[BOUBOU]

Ik bedoel het volgende
In Freenas is het vanuit de webinterface mogelijk om datasets aan te maken, waarop quotas gezet kunnen worden.

In mijn eerste Freenas installatie zijn 2 datasets aangemaakt (media en ftp), beide datasets zijn nog wel aanwezig in de pool, wanneer ik een nieuwe dataset probeer aan te maken met de naam media, dan krijg ik een foutmelding (zie screenshot)

http://imageshack.us/phot...enasdatasetwiththesa.jpg/

Wanneer ik ZFS list doe, dan krijg ik:

Name	Used	AVAIL	REFER	MOUNTPOINT
tank
tank/ftp
tank/media

Binnen de webinterface krijg ik echter alleen het /mnt/tank te zien, eventuele windowsshares kan ik dan ook alleen maar rechtstreeks op /mnt/tank maken, en niet op /mnt/tank/media of /mnt/tank/media

Nog een bijkomend nadeel is, dat ik binnen windows in de explorer van de nieuwe media share enkel nog te zien krijg, dat er 5,22TB van de 5,22TB vrije ruimte is, terwijl er binnen deze share ongeveer 8 TB aan data aanwezig is.

Vanuit de Freenas webinterface is het niet mogelijk om de genoemde datasets opnieuw te importeren, zodat deze zichtbaar worden, en dus ook weer beheerd kunnen worden.

Vanuit de commandline zou dit wel mogelijk moeten zijn, maar kan het commando hiervoor niet terugvinden.

[ Voor 10% gewijzigd door BOUBOU op 22-06-2011 20:27 ]

[Anoniem: 15758]

Als er al een tank/media filesystem bestaat, kun je niet een nieuw filesystem met dezelfde naam aanmaken; anders zou opeens je oude filesystem weg zijn inclusief alle data. Dit is dus volkomen logisch.

Het begrip dataset bestaat niet in ZFS, wat jij bedoelt zijn ZFS filesystems. Je hebt een hoofdfilesystem (tank) en twee filesystems daarin genaamd ftp en media. Om te zien waar die gemount zijn moet je de zfs list output bekijken; kun je die pasten ergens? Daarbij heb ik het over command line output, niet wat je in FreeNAS web-interface ziet. Het commando is heel simpel: zfs list

Het kan zijn dat de filesystems niet gemount zijn, of op een andere plek. Dat kun je in de zfs list output zien.

Nog een bijkomend nadeel is, dat ik binnen windows in de explorer van de nieuwe media share enkel nog te zien krijg, dat er 5,22TB van de 5,22TB vrije ruimte is, terwijl er binnen deze share ongeveer 8 TB aan data aanwezig is.

Hoezo is dat een nadeel? Als je bestanden op een ander filesystem binnen dezelfde pool hebt staan, heb je niet de volledige 8TB als vrije ruimte; dat lijkt mij heel erg logisch? Als jij iets minder dan 3TB in een of ander filesystem hebt staan, is die ruimte niet beschikbaar voor andere filesystems. Alle vrije ruimte wordt gedeeld met alle filesystems op dezelfde pool (tank in jouw geval).

Importeren doe je alleen met pools, niet met filesystems. Als je pool niet is geïmporteerd, dan zie je die ook niet in de zfs list output.

[BOUBOU]

Anoniem: 15758 schreef op woensdag 22 juni 2011 @ 20:53:
Als er al een tank/media filesystem bestaat, kun je niet een nieuw filesystem met dezelfde naam aanmaken; anders zou opeens je oude filesystem weg zijn inclusief alle data. Dit is dus volkomen logisch.

Het begrip dataset bestaat niet in ZFS, wat jij bedoelt zijn ZFS filesystems. Je hebt een hoofdfilesystem (tank) en twee filesystems daarin genaamd ftp en media. Om te zien waar die gemount zijn moet je de zfs list output bekijken; kun je die pasten ergens? Daarbij heb ik het over command line output, niet wat je in FreeNAS web-interface ziet. Het commando is heel simpel: zfs list

Het kan zijn dat de filesystems niet gemount zijn, of op een andere plek. Dat kun je in de zfs list output zien.

Als je het screenshot goed bekijk, dan zie je dat er binnen Freenas wel degelijk gesproken wordt over datasets, vandaar mijn referentie naar 'dataset'
In de tabel hierboven heb ik de output van 'zfs list' geplaats, hier is te zien, dat ik de volgende mountpoints heb in mijn pool.

tank
tank/ftp
tank/media

Vanuit Freenas kan ik helaas geen output pasten.


[...]

Hoezo is dat een nadeel? Als je bestanden op een ander filesystem binnen dezelfde pool hebt staan, heb je niet de volledige 8TB als vrije ruimte; dat lijkt mij heel erg logisch? Als jij iets minder dan 3TB in een of ander filesystem hebt staan, is die ruimte niet beschikbaar voor andere filesystems. Alle vrije ruimte wordt gedeeld met alle filesystems op dezelfde pool (tank in jouw geval).

Het is mij bekend dat alle vrije ruimte wordt gedeeld, er verwacht in de windows share echter wel te kunnen zien wat de totale grote van de tank is.
het commando zfs list geeft de volgende informatie:
Tank
Used 8,36T
Available 5,23T
Totaal is dit 13,9T

Nu heb ik vanuit de Freenas gui een windows share gemaakt met de naam media, deze is koppeld aan Tank.
Wat ik nu verwacht te zien in windows is 5,23TB free of 13,9TB, 13,9TB is immers de totale grote van Tank

Wat ik nu zie is 5,23TB free of 5,23TB
Wanneer ik de share media open, dan kom ik hier de map media tegen, met daarin 8TB aan data
8,36TB + 5,23TB is volgens mijn rekenmachine 13,9TB, en niet 5,23TB

Importeren doe je alleen met pools, niet met filesystems. Als je pool niet is geïmporteerd, dan zie je die ook niet in de zfs list output.

Aangezien Tank, Tank/media en Tank/ftp alle 3 getoond worden in de zfs list output, betekend dat deze wel zijn geïmporteerd, ik zie deze dus niet terug binnen de webinterface van FreeNas.

Ik hoop dat het nu duidelijker is.

[CurlyMo]

Ik denk dat het eerder een fout in Freenas is. Zodra je filesystems hebt aangemaakt in je zpool verschijnen deze gewoon weer tijdens je import van je pool. Heb je dus een pool gemaakt met de naam 'tank' dan is je mountpoint normaal gesproken /tank. Alle filesystems in je pool zoals 'media' en 'ftp' verschijnen gewoon als mappen in je pool dus /tank/media en /tank/ftp. Kijk gewoon of deze mappen in je tank mountpoint staan, zo ja, dan is er gewoon een probleem met Freenas.

M.b.t. je gebruik van schijfruimte het volgende:

Tank: 5TB totaal
Media: 1TB gebruikt
FTP: 1TB gebruikt

Als je nu in je tank pool benaderd via bijv. samba dan zie je dat er totaal 3TB beschikbaar is. De rest is immers als gebruikt in je andere filesystems en dus niet meer beschikbaar voor je tank pool. Vergelijk het met een beschrijfbare CD. Aangezien er na het schrijven geen ruimte meer is om aanvullende data toe te voegen, geeft windows niet de volledige grootte van de CD weer maar de totale grootte van de beschreven ruimte. Zodra je ergens in je pool bestanden verwijderd zodat je Media filesystem opeens 0,5TB wordt, dan zie je deze ruimte automatisch weer bij je pool groot toegevoegd worden.

Ik denk dat je er gewoon aan moet zullen wennen dat je gewoon andere informatie voor handen hebt dan dat je gewend bent.
________________________

Wat je zou kunnen doen als je via Samba werkt (getest onder Solaris 11) is een custom script te schrijven die bepaald hoe Samba de share grootte moet bepalen:

- Maak een apart scriptje met de volgende inhoud in bijv. /usr/bin/smbdiskspace

code:

#!/bin/bash

used=`/usr/sbin/zfs get -Hp used $1 | awk '{print $3}'`;
avail=`/usr/sbin/zfs get -Hp available $1 | awk '{print $3}'`;
total=$(($avail+$used));
print "$total $avail\n";

- Voeg de volgende code toe aan je personal shares in je smb.conf. In jouw geval bijv. onder media

code:

[media]
dfree command = /usr/sbin/smbdiskspace tank/media

[ Voor 20% gewijzigd door CurlyMo op 22-06-2011 23:59 . Reden: Samba optie toegevoegd ]

[Anoniem: 15758]

BOUBOU schreef op woensdag 22 juni 2011 @ 22:01:
[...]
Als je het screenshot goed bekijk, dan zie je dat er binnen Freenas wel degelijk gesproken wordt over datasets, vandaar mijn referentie naar 'dataset'

Aha; maar dat vind ik verwarrend aangezien deze terminologie in ZFS zelf niet wordt gebruikt. De juist benaming is ZFS filesystems; elk filesystem heeft zijn eigen attributen en staat los van andere filesystems. Filesystems lijken gewoon directories vanuit Samba (CIFS).

In de tabel hierboven heb ik de output van 'zfs list' geplaats, hier is te zien, dat ik de volgende mountpoints heb in mijn pool.

Nee daar staan alleen je filesystems, niet je mountpoints. Mountpoints beginnen met een /.

Voorbeeld:

code:

tank/nfs/archives                                 30K  751.7G    30K  /tank/nfs/archives

Vanuit Freenas kan ik helaas geen output pasten.

Als je SSH login instelt kun je heel makkelijk output pasten. Als je SSH nog nooit hebt gebruikt, kleine tip: download PuTTY (google).

Het is mij bekend dat alle vrije ruimte wordt gedeeld, er verwacht in de windows share echter wel te kunnen zien wat de totale grote van de tank is.

Dat klopt, maar de grootte van 'tank' neemt af zodra andere filesystems gevuld worden. Als media en ftp samen 90% van de vrije ruimte in gebruik hebben, zal 'tank' laten zien dat de totale grootte 10% is met eigen gebruik 1% en dus 9% vrije ruimte, waarbij 100% de maximale grootte is (13,9TiB in jouw geval). tank zal dus in grootte afnemen zodra andere filesystems gevuld worden. Dit gedrag is verwarrend voor mensen die het begrip ZFS filesystems nog niet zo kennen. Maar speel er wat mee en het wordt je vast wel duidelijk.

Aangezien Tank, Tank/media en Tank/ftp alle 3 getoond worden in de zfs list output, betekend dat deze wel zijn geïmporteerd

Importeren werkt alleen op hele pools. Wel kan het zijn dat de overige filesystems niet gemount zijn. Daarom vroeg ik om de zfs list output, zodat je dit kunt zien.

Oh en dat scriptje hierboven is erg handig! Als je dat onder FreeBSD/FreeNAS wilt gebruiken moet je hem als volgt gebruiken:

code:

#!/usr/local/bin/bash

used=`/sbin/zfs get -Hp used $1 | awk '{print $3}'`;
avail=`/sbin/zfs get -Hp available $1 | awk '{print $3}'`;
total=$(($avail+$used));
print "$total $avail\n";

[ Voor 7% gewijzigd door Anoniem: 15758 op 22-06-2011 23:54 . Reden: scriptje toegevoegd ]

[Nopel]

Dataset is officiële zfs terminologie. Uit de man-page:

DESCRIPTION
     The zfs command configures ZFS datasets within a ZFS storage
     pool,  as described in zpool(1M). A dataset is identified by
     a unique path within the ZFS namespace. For example:

       pool/{filesystem,volume,snapshot}

     where the maximum length of a  dataset  name  is  MAXNAMELEN
     (256 bytes).

     A dataset can be one of the following:

     file system

         A ZFS dataset of type filesystem can be  mounted  within
         the  standard  system  namespace  and behaves like other
         file systems. While ZFS file systems are designed to  be
         POSIX compliant, known issues exist that prevent compli-
         ance in some cases. Applications that  depend  on  stan-
         dards conformance might fail due to nonstandard behavior
         when checking file system free space.

     volume

         A logical volume exported as a raw or block device. This
         type  of  dataset should only be used under special cir-
         cumstances. File systems  are  typically  used  in  most
         environments.

     snapshot

         A read-only version of a file  system  or  volume  at  a
         given  point in time. It is specified as filesystem@name
         or volume@name.

[Anoniem: 15758]

I stand corrected.

De term dataset heb ik echter in zfs/zpool output nog niet voorbij zien komen. Maar het klinkt logisch; een dataset is de verzameling aan filesystems, zvols en snapshots in een pool.

Echter als je volumes had gehad in plaats van filesystems, was het logisch dat die niet gemount waren, omdat die dan in /dev/zvol/<volumenaam> worden geplaatst. Dus het lijkt me beter om het over filesystems te hebben.

@TS: heb je al wat meer informatie over de mountpoints, is SSH login gelukt?

[BOUBOU]

Ik zal vanmiddag of morgen via IPMI screenshots kunnen maken.
Als dit niet lukt, dan ga ik een poging wagen met Putty/SSH

Het probleem met de ontbrekende datasets heb ik voorlopig maar even omzeild, door een nieuwe dataset aan te maken, welke dus wel vanuit Freenas te beheren is, en alle data dmv. het cp command, over te kopieeren naar vanuit de oude dataset, naar de nieuwe.

Dit ging met ongeveer 266mb p/s.
Is dit een gangbare snelheid voor een 10 x 2TB RaidZ2 setup op basis van een Supermicro X8ST3-F icm. een Xeon X3440?

[FireDrunk]

lokaal? Dat is juist super toch? Dat zou betekenen dat je disks 250MB/s kunnen lezen en schrijven tegelijkertijd... Dus relatief gezien 500MB/s

[magistus]

Dit weekend eens spelen. Kijken of ik tot een ~4TB pool kan komen (2x 8 disk raidz3 met 400G disks) welke als archief (puur opslag, hoeft niet snel, wel betrouwbaar qua dataintegriteit/uitval disks) dienst gaat doen. Iemand ervaring met zfs-fuse (0.6.9-1, ik zit enigzins vast aan Debian Squeeze AMD64) of kan ik beter virtueel (ik kan mijn HBA met pci passthrough aan een KVM-virtual aanbieden) iets anders gaan draaien?

[FireDrunk]

Raidz3??? Iets met overdaad schaad

[magistus]

mjah, disks zijn wat ouder, vermoedelijke uit dezelfde batch en de storage-node gaat het grootste deel van de tijd uit staan (dus af-en-toe aan om even archief bij te werken). Zodoende leek enige overdaad mij niet geheel onbelangrijk

[Micr0mega]

magistus schreef op vrijdag 24 juni 2011 @ 14:58:
...
Iemand ervaring met zfs-fuse (0.6.9-1, ik zit enigzins vast aan Debian Squeeze AMD64) of kan ik beter virtueel (ik kan mijn HBA met pci passthrough aan een KVM-virtual aanbieden) iets anders gaan draaien?

Ik heb zelf zfs-fuse niet getest, maar in plaats daarvan er zijn ook native kernel modules beschikbaar die ook prima onder Squeeze werken: https://launchpad.net/~dajhorn/+archive/zfs
Dit zal waarschijnlijk beter werken dan fuse, maar nog steeds niet zo snel als op een (Open)Solaris/OpenIndiana/Nexenta (en misschien *BSD?).

[magistus]

Micr0mega schreef op vrijdag 24 juni 2011 @ 16:06:
[...]


Ik heb zelf zfs-fuse niet getest, maar in plaats daarvan er zijn ook native kernel modules beschikbaar die ook prima onder Squeeze werken: https://launchpad.net/~dajhorn/+archive/zfs
Dit zal waarschijnlijk beter werken dan fuse, maar nog steeds niet zo snel als op een (Open)Solaris/OpenIndiana/Nexenta (en misschien *BSD?).

In mijn zoektocht naar een nette oplossing heb ik o.a. naar deze packages gekeken maar deze kreeg ik op dat moment niet netjes aan de praat. Ik kan me ook herinneren dat er oorspronkelijk letterlijk een melding stond dat de maverick packages prima onder squeeze zouden moeten werken, maar tegen de tijd dat ik ging pielen was deze opmerking verdwenen en was het resultaat niet best. Volgens mij liep ik tegen een bug in dkms aan oid waarbij de versienummering van de modules problemen gaf. Gezien het feit dat zfs-fuse gewoon in Debian Stable zit, leek dit mij momenteel de netste keuze, vandaar het huidige idee Snelheid is niet een doel op zich, al moet het natuurlijk niet te gek worden. Maar mag ik concluderen dat jij andere ervaringen hebt met de huidige dajhorn zfs-packages en squeeze? Dan is het wellicht nog interessant om extra aandacht aan te besteden

[Micr0mega]

Echte ervaring zou ik het niet willen noemen en het is ook al een aantal weken (meer dan een maand) geleden. Ik heb toen van verschillende OSen met ZFS benchmarks gedraaid. Het werkte prima, was zo gepiept, maar het was slechts een 1-disk pool en heb geen exotische dingen geprobeerd. In mijn benchmarks zag ik dat alle ports soms enkele tientallen tot zelfs honderdmaal slechter presteerde dan de 'native' Solaris versies. Ik heb toen dus besloten een OpenSolaris afgeleidde te gaan gebruiken; in dit geval OpenIndiana, Linux heb ik daarna niet meer aangeraakt.

Maar ik zou zeggen, test het lekker in een VM op je desktop, met eventueel één (of een paar) van de disks aangesloten op de VM. Zo heb ik het gedaan, icm VMware Player.

[BOUBOU]

Doordat het niet mogelijk was om het beheer van /tank/media terug te krijgen in de gui van Freenas, heb ik de volgende workarround uitgevoerd.

Ik heb per categorie een nieuwe dataset aangemaakt, vervolgens heb ik alles vanuit de dataset media via scp over gekopieerd naar de nieuwe datasets, en heb ik de dataset media verwijderd. Doordat de windows shares nu weer rechtstreeks op de dataset gekoppeld is, worden in Windows nu ook weer de juiste waarden getoond bij totaal gebruikte en beschikbare ruimte.

Zie onderstaande resulaat.

code:

freenas# zfs list
NAME                                          USED  AVAIL  REFER  MOUNTPOINT
tank                                          8.31T  5.28T  49.3M  /mnt/tank
tank/Foto                                        4.17G  5.28T  4.16G  /mnt/tank/Foto
tank/MP3                                    174G  5.28T   174G  /mnt/tank/MP3
tank/beveiligingscamera          5.53T  5.28T  5.53T  /mnt/tank/beveiligingscamera
tank/MusicVideo                              12.6G  5.28T  12.6G  /mnt/tank/MusicVideo
tank/opgenomen_tvshows       2.60T  5.28T  2.60T  /mnt/tank/TVShows
tank/backup                                             804K  5.28T   274K  /mnt/tank/backup
tank/backup/fotoclone-auto-20110624.0900-2w   530K  5.28T  4.16G  /mnt/tank/backup/fotoclone-auto-20110624.0900-2w
tank/ftp                                      686K  5.28T   686K  /mnt/tank/ftp

Allen bedankt voor het meedenken.

[Anoniem: 187449]

BOUBOU schreef op vrijdag 24 juni 2011 @ 23:06:
Doordat het niet mogelijk was om het beheer van /tank/media terug te krijgen in de gui van Freenas, heb ik de volgende workarround uitgevoerd.

Ik heb per categorie een nieuwe dataset aangemaakt, vervolgens heb ik alles vanuit de dataset media via scp over gekopieerd naar de nieuwe datasets, en heb ik de dataset media verwijderd. Doordat de windows shares nu weer rechtstreeks op de dataset gekoppeld is, worden in Windows nu ook weer de juiste waarden getoond bij totaal gebruikte en beschikbare ruimte.

Zie onderstaande resulaat.

code:

freenas# zfs list
NAME                                          USED  AVAIL  REFER  MOUNTPOINT
tank                                          8.31T  5.28T  49.3M  /mnt/tank
tank/Foto                                        4.17G  5.28T  4.16G  /mnt/tank/Foto
tank/MP3                                    174G  5.28T   174G  /mnt/tank/MP3
tank/beveiligingscamera          5.53T  5.28T  5.53T  /mnt/tank/beveiligingscamera
tank/MusicVideo                              12.6G  5.28T  12.6G  /mnt/tank/MusicVideo
tank/opgenomen_tvshows       2.60T  5.28T  2.60T  /mnt/tank/TVShows
tank/backup                                             804K  5.28T   274K  /mnt/tank/backup
tank/backup/fotoclone-auto-20110624.0900-2w   530K  5.28T  4.16G  /mnt/tank/backup/fotoclone-auto-20110624.0900-2w
tank/ftp                                      686K  5.28T   686K  /mnt/tank/ftp

Allen bedankt voor het meedenken.

sliimme oplossing

[Micr0mega]

Slimmer, en leuker, was het geweest als hij 'zfs send' en 'zfs receive' had gebruikt Google maar eens naar 'zfs replication', zijn interessante commando's en dan weet je meteen weer waarom ZFS zo mooi is.

[Anoniem: 187449]

Micr0mega schreef op zaterdag 25 juni 2011 @ 11:33:
Slimmer, en leuker, was het geweest als hij 'zfs send' en 'zfs receive' had gebruikt Google maar eens naar 'zfs replication', zijn interessante commando's en dan weet je meteen weer waarom ZFS zo mooi is.

tja achteraf is alles makkelijk .... hij heeft het voor elkaar en daar gaat het om.

[ Voor 6% gewijzigd door Anoniem: 187449 op 25-06-2011 11:57 ]

[BOUBOU]

Micr0mega schreef op zaterdag 25 juni 2011 @ 11:33:
Slimmer, en leuker, was het geweest als hij 'zfs send' en 'zfs receive' had gebruikt Google maar eens naar 'zfs replication', zijn interessante commando's en dan weet je meteen weer waarom ZFS zo mooi is.

Ik zie de voordelen niet zo van lokale replicatie, replicatie tussen 2 verschillende locaties daarintegen weer wel, ik heb helaas niet de mogelijkheid om dit in te richten, behalve dan eventueel de mogelijkheid via VMware en passthrough een installatie van Freenas uit te zetten, met daaronder een ZFS mirror van 2 x 1 TB voor backup.

Ziet iemand van jullie wel de voordelen om binnen één pool 2 locaties te repliceren?

[Anoniem: 15758]

Lokaal != binnen één pool. Je kunt met zfs send/receive bijvoorbeeld een echte kopie van een pool maken. Dat is wat anders dan bestanden kopiëren. Met zfs send/receive worden ook alle filesystems en diens attributen en snapshots overgezet. Dat kun je nergens anders mee dan met de send/receive functionaliteit.

[vargo]

Mijn main NAS draait nog steeds op opensolaris b134. Nu vond ik het tijd om maar eens naar openindiana te gaan + napp it + netatalk (apple file sharing).

Dus ik aan de slag:

code:

# pfexec pkg set-publisher --non-sticky opensolaris.org
pkg set-publisher: 
Certificate '/home/vargo/Downloads/OpenSolaris_extras.certificate.pem' for publisher 'extra' needed to access 'https://pkg.sun.com/opensolaris/extra/', has expired.  Please install a valid certificate.

Dan maar even vernieuwen dacht ik, maar WTF! Je kan helemaal geen certificaten meer krijgen!?
Bovenstaande link leidt tot een forbidden en ook andere referenties leiden tot een dood spoor.

Ben bang dat dat dus openindiana from scratch installeren wordt? Of iemand een idee om alsnog aan nieuwe certificaten te komen / dit te omzeilen?

[Anoniem: 15758]

Volgens mij een resultaat van dat Oracle de Sun site heeft ontmanteld; nog een reden waarom je liever een écht open source OS wilt en niet afhankelijk wilt zijn van een derde partij; en al helemaal niet Oracle.

Ik vrees dat je dus een clean install moet uitvoeren.

[ Voor 58% gewijzigd door Anoniem: 15758 op 25-06-2011 16:09 ]

[BOUBOU]

Anoniem: 15758 schreef op zaterdag 25 juni 2011 @ 15:58:
Lokaal != binnen één pool. Je kunt met zfs send/receive bijvoorbeeld een echte kopie van een pool maken. Dat is wat anders dan bestanden kopiëren. Met zfs send/receive worden ook alle filesystems en diens attributen en snapshots overgezet. Dat kun je nergens anders mee dan met de send/receive functionaliteit.

Ik ben het eens met de voordelen, maar om 'echte kopie' van een pool te maken is een 2e pool op dezelfde server, of een 2e pool op een 2e server noodzakelijk, deze heb ik momenteel (nog) niet beschikbaar.

Zijn er nog voordelen te bedenken van replicatie tussen 2 ZFS datasets binnen dezelfde pool?

[vargo]

BOUBOU schreef op zaterdag 25 juni 2011 @ 16:48:
[...]


Ik ben het eens met de voordelen, maar om 'echte kopie' van een pool te maken is een 2e pool op dezelfde server, of een 2e pool op een 2e server noodzakelijk, deze heb ik momenteel (nog) niet beschikbaar.

Zijn er nog voordelen te bedenken van replicatie tussen 2 ZFS datasets binnen dezelfde pool?

Send / Receive gebruik je voor het saven en restoren van snapshots. Dit kan handig zijn als je bijv een omgeving hebt waarbij je later nog eens een restore wilt doen naar een bepaalde snapshot, zonder de originele dataset terug te rollen. Het gaat hierbij wel echt om het online brengen van die dataset, want als je simpelweg een bestand wil hebben van dat moment kan je onder .snapshot dit bestand gewoon oproepen.

[ Voor 33% gewijzigd door vargo op 26-06-2011 10:58 ]

[Skinkie]

Micr0mega schreef op zaterdag 25 juni 2011 @ 11:33:
Slimmer, en leuker, was het geweest als hij 'zfs send' en 'zfs receive' had gebruikt Google maar eens naar 'zfs replication', zijn interessante commando's en dan weet je meteen weer waarom ZFS zo mooi is.

Met diezelfde query + performance kom je ook gelijk tegen waarom je dat niet moet doen...

[vargo]

Weet iemand of er ooit een initiatief gestart is om de time slider beschikbaar te maken over bv NFS / CIFS / AFS?

Voor degenen die de time slider niet kennen: hiermee kan je in de file browser van solaris/openindiana via een slider terug gaan in de tijd (op basis van de aanwezige snapshots).

Het lijkt me dus superhandig als je dit vanaf je client kan doen op je NAS share (dus vanuit windows explorer / mac finder etc).

[CurlyMo]

vargo schreef op zondag 26 juni 2011 @ 11:07:
Weet iemand of er ooit een initiatief gestart is om de time slider beschikbaar te maken over bv NFS / CIFS / AFS?

Voor degenen die de time slider niet kennen: hiermee kan je in de file browser van solaris/openindiana via een slider terug gaan in de tijd (op basis van de aanwezige snapshots).

Het lijkt me dus superhandig als je dit vanaf je client kan doen op je NAS share (dus vanuit windows explorer / mac finder etc).

Wat je zou kunnen proberen is het volgende (intikken in google) "samba shadow copy zfs". Ik zeg proberen aangezien het mij nooit gelukt is. Je kan dus samba je snapshot directory laten gebruiken voor je windows shadow copy functionaliteit. Dat is het dichtste dat je bij een 'time slider' functionaliteit kan komen in Windows.

Je snapshots moeten natuurlijk wel op een vast moment aangemaakt worden met een bepaalde naam (anders heeft zo'n time slider natuurlijk ook geen zin).

Voor MAC moet het ook vast wel kunnen maar dat heb ik nooit geprobeerd.

[DARKLORD]

openindiana gebruiken icm snapshots!
dan krijg je in windows de mogelijkheid om gebruik te maken van previous versions. werkt zeer goed

[Splendid]

Crap! Ik heb 'per ongeluk' mijn mirror schijf van mijn syspool gedetached en ik krijg hem met geen mogelijkheid meer terug in de syspool!

Als ik de volgende manier gebruik, wat volgens mij de juiste is:

code:

zpool attach -f syspool c2t0d0s0 c1t0d0s0

Krijg ik de volgende melding;

code:

cannot attach c1t0d0s0 to c2t0d0s0: no such pool or dataset

Wat ik raar vind want syspool bestaat toch echt....

Misschien komt het omdat deze schijf de mirror schijf was van deze mirror, die nu een single disk vdev is geworden Hoe krijg ik die schijf nu terug.

Overigens wou ik een andere schijf in de pool gooien maar dan zegt hij:

code:

cannot label 'c4d1': EFI labeled devices are not supported on root pools.

Oke, ik snap er niks meer van

[CurlyMo]

Splendid schreef op maandag 27 juni 2011 @ 23:20:
Crap! Ik heb 'per ongeluk' mijn mirror schijf van mijn syspool gedetached en ik krijg hem met geen mogelijkheid meer terug in de syspool!

Als ik de volgende manier gebruik, wat volgens mij de juiste is:

code:

zpool attach -f syspool c2t0d0s0 c1t0d0s0

Krijg ik de volgende melding;

code:

cannot attach c1t0d0s0 to c2t0d0s0: no such pool or dataset

Wat ik raar vind want syspool bestaat toch echt....

Volgens mij is het commando als volgt:

code:

zpool attach -f syspool c1t0d0s0

Misschien komt het omdat deze schijf de mirror schijf was van deze mirror, die nu een single disk vdev is geworden Hoe krijg ik die schijf nu terug.

Overigens wou ik een andere schijf in de pool gooien maar dan zegt hij:

code:

cannot label 'c4d1': EFI labeled devices are not supported on root pools.

Oke, ik snap er niks meer van

Waarom wil je labels maken. Je kan toch gewoon je rauwe disk aan je mirror toevoegen.

[Splendid]

CurlyMo schreef op maandag 27 juni 2011 @ 23:27:
[...]


Volgens mij is het commando als volgt:

code:

zpool attach -f syspool c1t0d0s0

[...]


Waarom wil je labels maken. Je kan toch gewoon je rauwe disk aan je mirror toevoegen.

Nee commando klopt wel, anders krijg ik:

code:

missing <new_device> specification
usage:
        attach [-f] <pool> <device> <new-device>

En ik label niks, ik doe exact hetzelfde maar dan met een andere schijf en dan krijg ik die error. Dus met 2 schijven exact hetzelfde proberen en 2 verschillende errors krijgen...zucht

[CurlyMo]

Terwijl je toch de error krijgt dat die je c2t0d0s0 schijf als de pool of dataset interpreteerd.

M.b.t. de labels bedoel ik dat je nu je schijven in je dataset hebt zitten aan de hand van je eerste slice, c1t0d0s0. Je kan je schijven ook toevoegen aan de hand van de hele disk, dus onafhankelijk van je slices, c1t0d0. Waarom doe je het tweede niet / of heb je dat niet gedaan?

[Splendid]

CurlyMo schreef op maandag 27 juni 2011 @ 23:33:
Terwijl je toch de error krijgt dat die je c2t0d0s0 schijf als de pool of dataset interpreteerd.

M.b.t. de labels bedoel ik dat je nu je schijven in je dataset hebt zitten aan de hand van je eerste slice, c1t0d0s0. Je kan je schijven ook toevoegen aan de hand van de hele disk, dus onafhankelijk van je slices, c1t0d0. Waarom doe je het tweede niet / of heb je dat niet gedaan?

Ja ik had gelezen dat je dat moest doen, dus dat doe ik dan netjes Als ik het zonder de slices proberen dat krijg ik ook de EFI error op die schijf.

[CurlyMo]

Heb je dat label al verwijderd van je schijf via format -e?

[Splendid]

CurlyMo schreef op maandag 27 juni 2011 @ 23:41:
Heb je dat label al verwijderd van je schijf via format -e?

Ja ook allemaal al geprobeerd.

Wat ik nog wel vond is de volgende command om dit eventueel te omzeilen:

code:

prtvtoc /dev/rdsk/c2t0d0s0 | fmthard -s - /dev/rdsk/c1t0d0s0

Maar ik heb geen idee wat dit voor gevolgen heeft voor mijn pool...ben niet bekend met de prtvtoc commando...

[CurlyMo]

Dan blijf je toch weer via slices werken? Zo ja, dit al geprobeerd:

http://dd-b.net/ddbcms/20...a-solaris-efi-disk-label/

[Splendid]

CurlyMo schreef op maandag 27 juni 2011 @ 23:51:
Dan blijf je toch weer via slices werken? Zo ja, dit al geprobeerd:

http://dd-b.net/ddbcms/20...a-solaris-efi-disk-label/

Jeuh het werkt! Wel op de nieuwe schijf, maar dat is goed want ik wou de oude swappen voor de nieuwe. Thanks for the link!

[wallyberk]

Is er een mogelijkheid om naast de zfs-send / zfs-receive een echt backup te kunnen maken van je pool. De zfs-send / zfs-receive lijkt meer als een replication, dan een backup. Ik zou een tool willen zien waarmee ik ook bijvoorbeeld incrementele backups zou kunnen maken.

[CurlyMo]

wallyberk schreef op woensdag 29 juni 2011 @ 16:54:
Is er een mogelijkheid om naast de zfs-send / zfs-receive een echt backup te kunnen maken van je pool. De zfs-send / zfs-receive lijkt meer als een replication, dan een backup. Ik zou een tool willen zien waarmee ik ook bijvoorbeeld incrementele backups zou kunnen maken.

Ik gebruik zelf al een geruime tijd rdiff-backup.

[Splendid]

Je kan toch ook rsync gebruiken met je snapshots

[Ultraman]

Rsync en het er op gebaseerde rdiff-backup script is daarvoor handig.
Je kunt het zo simpel en zo gek maken als je zelf wilt.

[Dadona]

Rsync met snapshots is niet hetzelfde als rdiff-backup.
Met de snapshot ga je terug naar een bepaalde rsync-sessie (/staat van de harde schijf op een moment). Dat kan met rdiff-backup ook. Maar rdiff-backup heeft daarboven op (en als primaire functie) dat je naar een revisie van een bestand terug kunt gaan. Dat is sneller dan door middel van snapshots zoeken naar een bepaalde revisie, of er moet inmiddels iets slims zijn om dat boven tafel te krijgen uit snapshots.

[CurlyMo]

Gisteren ben ik weer met nieuwe moed begonnen aan het testen van mijn gigabit netwerk bottleneck. De eerste stap richt zich weer op mijn rauwe netwerk doorvoer. Dit heb ik getest met iperf. Nu blijkt dat de window size een aanzienlijk verschil kan maken in mijn netwerk (transfer) snelheden.

Windows 7	-->	Solaris 11
8KB (default)	252Mb/s	125KB (default)
16KB	559Mb/s	125KB
32KB	800Mb/s	125KB
64KB	1.08Gb/s	125KB
Windows 7	<--	Solaris 11
8KB (default)	1001Mb/s	48KB (default)
64KB	1009Mb/s	125KB

Zoals te zien in de tabel is er een aanzienlijk verschil in doorvoersnelheid wanneer er in Windows van een grotere tcp window size gebruik gemaakt wordt. Is er een manier om deze de default tcp window size van windows op 64KB te zetten of op andere manieren de doorvoersnelheden te halen die volgens iperf wél mogelijk zijn?

[ Voor 3% gewijzigd door CurlyMo op 01-07-2011 10:11 ]

[leuk_he]

schreef op vrijdag 01 juli 2011 @ 10:09:
Is er een manier om deze de default tcp window size van windows op 64KB te zetten of op andere manieren de doorvoersnelheden te halen die volgens iperf wél mogelijk zijn?

Niet zelf geprobeerd:

Description of Windows 2000 and Windows Server 2003 TCP Features

Click Start, click Run, type Regedit, and then click OK.
Expand the registry subkey specific to your version of Windows:
For Windows 2000, expand the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
For Windows Server 2003, expand the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
On the Edit menu, point to New, and then click DWORD Value.
Type TcpWindowSize in the New Value box, and thne press Enter
Click Modify on the Edit menu.
Type the desired window size in the Value data box.

Note. The valid range for window size is 0-0x3FFFC000 Hexadecimal.

Ik schat zo in dat je de windows 2003 optie moet gebruiken. Zelf patch ik dit soort settings bewust niet om op mijn ontwikkel machine dezelfde default settings te hebben als op andere machines waar men niet met deze settings heeft gevarieerd.

[CurlyMo]

Wanneer ik deze settings toepas blijft de standaard iperf TCP window size op 8Kbyte staan.

[leuk_he]

schreef op vrijdag 01 juli 2011 @ 11:48:
Wanneer ik deze settings toepas blijft de standaard iperf TCP window size op 8Kbyte staan.

Bij vista heeft het ook nog te maken met Autotuning

[CurlyMo]

Ook autotuning aanpassen biedt geen verbetering

[dutch_warrior]

correct autotuning doet vooral in Windows naar Windows verbindingen goed dingen maar in sommige Windows naar Unix of Windows 7 naar XP situaties werkt auto tuning niet goed.

Kijk anders even hier

EDIT: Oke aanpassen helpt dus ook niet? Doen je problemen zich echt alleen voor tussen Windows en Solaris? Een Windows naar Windows netwerk haalt wel de te verwachten snelheid?

Maar dan nog zou eigenlijk client side tuning niet zo hard nodig moeten zijn, mijn clients lezen en schrijven van en naar de open indiana test machine met ruim 100MBps zonder client side tuning. Dit is natuurlijk wel met grote sequentiele reads en writes.

[ Voor 42% gewijzigd door dutch_warrior op 01-07-2011 12:07 ]

[CurlyMo]

Ondanks een nieuwe G620T en 8GB ram ipv een Atom D510 en 2GB is er geen verbetering zichtbaar in de snelheden. Deze blijft steken op 20/25MBps.

[dutch_warrior]

Maar de windows naar windows performance binnen het netwerk is wel goed?
Welke bekabeling en switch gebruik je, ik kon zo snel niet terug vinden of dit al eens ter sprake is gekomen maar waarschijnlijk wel aangezien je probleem aan de post historie te zien al wat langer loopt .

[oddish2211]

ik zit nu te twijfelen of ik op mijn server met 4x 1.5TB schijven ubuntu met native zfs ga draaien of openindiana.
weet iemand hoe het zit met de performance van native zfs onder ubuntu? de benchmarks die ik kan vinden zijn namelijk al wat ouder.
eigenlijk hoef ik alleen maar mijn gigabit lijntje vol te trekken, meer niet

[CurlyMo]

dutch_warrior schreef op vrijdag 01 juli 2011 @ 12:53:
Maar de windows naar windows performance binnen het netwerk is wel goed?
Welke bekabeling en switch gebruik je, ik kon zo snel niet terug vinden of dit al eens ter sprake is gekomen maar waarschijnlijk wel aangezien je probleem aan de post historie te zien al wat langer loopt .

Windows naar Windows gaat in ieder geval beter. Ik weet niet of ik dan de lijn vol trek. Kan ik binnenkort wel even testen.

[Anoniem: 187449]

FAQ about SSD's and ZFS

Mean Time Between Failures is Misleading

[ Voor 34% gewijzigd door Anoniem: 187449 op 04-07-2011 10:10 ]

[CurlyMo]

Anoniem: 187449 schreef op zondag 03 juli 2011 @ 13:59:
FAQ about SSD's and ZFS

Ik weet niet zeker of dit nu een reactie is op mijn probleem maar ik ga er in mijn antwoord maar even vanuit.

Na het downloaden van het scriptje blijkt maar 1 procent in de ghost sectie te vallen waardoor ik de conclusie zou kunnen trekken dat een SSD niet écht nodig is.

[Anoniem: 187449]

[ Voor 99% gewijzigd door Anoniem: 187449 op 07-03-2013 15:26 ]

[CurlyMo]

CurlyMo schreef op vrijdag 01 juli 2011 @ 18:35:
[...]


Windows naar Windows gaat in ieder geval beter. Ik weet niet of ik dan de lijn vol trek. Kan ik binnenkort wel even testen.

Ik heb nog even naar mijn Windows --> Windows tests gekeken maar het blijkt dat ik geen derde gigabit capable systeem heb. Mijn desktop en mijn NAS zijn de enige twee. Zal proberen een systeem te regelen met gigabit adapter zodat ik op die manier kan kijken of misschien één van de systemen de bottleneck is. Als niemand andere ideeën heeft, kom ik zodra ik die tests heb gedaan weer bij jullie terug met de resultaten.

[jeanj]

Een link voor de OP met uitleg over ZIL en LARC2 en hoe dit met een SSD te realiseren

http://constantin.glez.de...flash-memory-ssds-and-zfs

[CurlyMo]

jeanj schreef op woensdag 06 juli 2011 @ 13:33:
Een link voor de OP met uitleg over ZIL en LARC2 en hoe dit met een SSD te realiseren

http://constantin.glez.de...flash-memory-ssds-and-zfs

Een paar posts terug staat precies dezelfde link

[Dadona]

Kort: hoe zit het met de snelheid van het inlezen van data die gededupliceerd is opgeslagen?

Langer:
Ik loop nu al een tijdje met een idee in mijn hoofd, maar ik kan maar niet inschatten of het echt lekker gaat werken: deduplicatie voor besturingssytemen.
Het lijk mij ideaal, een SSD van 120GB van Intel kunnen verantwoorden omdat je een deel inzet voor de caching van ZFS (waarbij je profiteert van de grootte van de SSD) en het restant inzet voor het besturingssysteem. Alleen vind ik het nogal zonde om alle computer te voorzien van SSDs. De kleinere versies zijn langzamer en daarnaast heb ik nog altijd het idee dat voor de meeste mensen, inclusief mijzelf, een SSD maar weinig echt van toevoeging is. Zeker als je, net als ik, alles openlaat en de computer altijd in slaapstand zet. Ik start dus bijna nooit een browser, emailclient, ..
Nu zat ik eraan te denken dat voor, bij gelijke versies van besturinggssystemen en een deel identieke software, een aanzienlijk deel van de data dubbel op de SSD zou staan. Met deduplication zou ik dat kunnen voorkomen, waardoor ik opeens op een 120GB schijf twee (of in sommige gevallen zelfs meer) meerdere besturingssystemen zou kunnen zetten. Maar krijg ik hier nog wel wat snelheid mee?
Ik kom er maar niet achter of dit lekker gaat werken en om een SSD aan te schaffen om het te testen en tijd te investeren om het lekker draaiende te krijgen kost allemaal geld, terwijl iemand misschien iets dergelijks heeft gezien, het kan berederen of de spullen heeft liggen om het eens te testen.

[Anoniem: 15758]

Hoe gebruik je de systeemdisk op je ZFS? Via iSCSI of AoE? In zo'n geval kan dedup wel handig zijn ja; zeker als je images vrij klein zijn zoals 10GB per stuk. Doe dat wel met een sloot aan RAM; 16GiB minimum. Als je de images op HDD bewaart heb je nog een SSD als L2ARC nodig; wat ook weer extra geheugen nodig heeft. Met een van deze setups zou je toch vrij aardige dedup performance moeten krijgen.

Als je de Intel 320 series neemt kun je hem ook voor SLOG gebruiken; dus dan kun je de SSD voor drie taken gebruiken:
1) L2ARC cache
2) SLOG buffer
3) primaire storage met deduplication (waarop je systeemdisks staan)

[Dadona]

Vooralsnog zet ik in op iSCSI.
Als ik het project uitvoer dan neem ik zeker 16GB aan geheugen, sowieso doe ik niet al te moeilijk over extra geheugen . En inderdaad, het zou de Intel 320 worden vanwege de supercap, daardoor zou ik het laatste scenario dat je schets, met drie taken, kunnen uitvoeren.

[Anoniem: 187449]

Om problemen te voorkomen moeten verschillende versies van ZFS goed van elkaar te onderscheiden zijn. Daarom komen er nu 'feature flags', die implementaties van het bestandssysteem aanduiden.

Toen alleen Oracle de controle over ZFS uitoefende, waren interoperabiliteitsproblemen eenvoudig te vermijden: bij elke nieuwe feature kreeg het schijfformaat van ZFS een nieuw versienummer. Zo introduceert ZFS 21 deduplicatie en ZFS 30 encryptie. Maar ondertussen hebben een aantal ZFS-ontwikkelaars Oracle verlaten en zich bij Illumos aangesloten, en ook de FreeBSD-ontwikkelaars focussen zich meer en meer op ZFS.

Flags in plaats van versienummers

Doordat de ontwikkeling van ZFS tegenwoordig meer gedistribueerd word ontwikkeld, is het versienummer als instrument om ondersteuning van functies aan te duiden niet meer bruikbaar. Als Oracle bijvoorbeeld een ZFS 32 uitbrengt, is het niet zeker of deze nog volledig dezelfde functies aanbiedt als Illumos ZFS 32 of FreeBSD ZFS 32. De ontwikkeling van ZFS bij die twee andere besturingssystemen gaat namelijk ook zonder Oracle verder.

Oracle is na ZFS 28 gestopt met het vrijgeven van de broncode van zijn nieuwe ontwikkelingen. Daarom heeft een groep van ZFS-ontwikkelaars het voorstel gedaan om feature flags te implementeren. Deze flags duiden de ondersteuning van specifieke functies aan, zoals een nieuw compressie-algoritme of nieuwe RAID-variant. In veel gevallen kan het besturingssysteem een ZFS-pool of -bestandssysteem nog altijd read/only benaderen als er onbekende functies aanwezig zijn. De feature flags functionaliteit wordt deze zomer ontwikkeld en in Illumos geïntegreerd.

Geheime werkgroep

Enkele maanden geleden is de ZFS-werkgroep in het geheim opgericht om alle ontwikkelaars van ZFS op verschillende besturingssystemen bij elkaar te brengen en een forum te geven om hun werk te coördineren en ideeën uit te wisselen. Tot de werkgroep behoren onder andere ontwikkelaars van Illumos/OpenIndiana, Mac OS X (Ten's Complement), FreeBSD, Linux en Solaris. Oracle, dat in de gloriejaren van OpenSolaris zowat de enige was die aan ZFS werkte, heeft ook iemand in de werkgroep, maar zal er nooit volledige controle over hebben: de meerderheid van de leden komen uit opensource-besturingssystemen.

Het doel van de ZFS-werkgroep is om samenwerking rond ZFS in de community te vergemakkelijken. De initiatiefnemers waren bezorgd dat ZFS in verschillende subcommunity's zou uiteenvallen per besturingssysteem waarop het ondersteund is. Dat zou interoperabiliteitsproblemen geven voor wie zijn gegevens in ZFS van één besturingssysteem naar een ander wil migreren.

Tot de oprichters behoren onder andere Adam Leventhal (de uitvinder van RAIDZ en één van de uitvinders van DTrace) van Delphix, Garrett D'Amore van Nexenta Systems en Matthew Ahrens van Delphix. Die laatste leidt de ZFS-werkgroep. De activiteiten van de werkgroep zijn bewust gesloten, en sommige deelnemers willen niet dat hun lidmaatschap bekend is, maar de groep zal regelmatig resultaten van besprekingen publiceren, zoals nu voor de eerste keer met het feature flags voorstel gebeurd is.

bron

[Kriss1981]

Jason, de dev van ZFSguru heeft een teken van leven gegeven op zijn forum

Het project is dus nog niet ten einde, gelukkig. Ook heeft hij een update vrijgegeven waarin een update zit naar ZFS v28

Nu maar hopen dat hij blijft.

[Anoniem: 15758]

Hmm.. ben benieuwd!

Had eigenlijk het idee om zelf (mee) te developen aan een NAS solution. Zodra ik tijd heb misschien maar eens praten met die Jason.

[DARKLORD]

ik zit nu al op openindiana met napp it. maar wel ok om te horen dat hij uberhaupt nog leeft!

[dutch_warrior]

Anoniem: 15758 schreef op vrijdag 22 juli 2011 @ 00:23:
Hmm.. ben benieuwd!

Had eigenlijk het idee om zelf (mee) te developen aan een NAS solution. Zodra ik tijd heb misschien maar eens praten met die Jason.

Goed plan, als je de mogelijkheid hebt om Jason helpen dan moet je daar zeker met hem over spreken.
Ik denk dat ZFS Guru qua visie en implementatie het beste bij jou past en jouw kennis zal zeker van waarde zijn voor het project.

Sowieso is ZFS Guru een project waar meerdere mensen met echte kennis van zaken actief bij betrokken moeten zijn en niet alleen Jason.

@Hierboven:
Ik draai momenteel ook Open Indiana met Napp-IT maar ik ga binnenkort toch wel switchen naar FreeBSD want dat werkt voor mij persoonlijk toch iets fijner.

[ Voor 23% gewijzigd door dutch_warrior op 23-07-2011 11:40 ]

[Kriss1981]

Op mijn NAS draai ik al een paar maanden ZFSguru, met volle tevredenheid.

Sinds vandaag zet ik mijn NAS ook in voor World Community Grid

Tijdens de installatie van ZFSguru heb ik voor de optie "aggressive memory tuning" gekozen, waarbij meer dan 75% van het geheugen aan ZFS wordt toegewezen. Nu is mijn (noob-)vraag: Kan andere software gebruik maken van dat geheugen wanneer ZFS het niet nodig heeft?

Dit geeft ZFSguru aan: 7.5 GiB, of which 7.2 GiB kernel memory (307.2 GiB max.)

[Anoniem: 15758]

dutch_warrior schreef op zaterdag 23 juli 2011 @ 11:35:
Goed plan, als je de mogelijkheid hebt om Jason helpen dan moet je daar zeker met hem over spreken.
Ik denk dat ZFS Guru qua visie en implementatie het beste bij jou past en jouw kennis zal zeker van waarde zijn voor het project.

Daar kan je best eens gelijk in hebben. FreeBSD ken ik redelijk en van dit platform heb je FreeNAS en ZFSguru. Probleem is dat FreeNAS een soort 'stripped' FreeBSD OS is waardoor je het niet eenvoudig kunt uitbreiden met andere dingen; en ZFSguru is FreeBSD + een webinterface en wat voorgeïnstalleerde meuk, maar dus nog steeds 100% compatible. Dat is iets wat mij erg trekt, omdat je dan als geavanceerde gebruiker nog steeds met het FreeBSD-gedeelte kunt werken.

Je kunt ook zeggen: FreeNAS is een NAS OS met delen van FreeBSD OS, ZFSguru is een FreeBSD OS met een webinterface zodat het gemakkelijk als NAS is te bedienen. Dat laatste, dus een toevoeging ipv dingen wegbezuinigen, valt bij mij veel beter.

En ZFSguru kan ook dingen die FreeNAS niet kan; sommige dingen zijn best 'clever' in elkaar gezet.

Sowieso is ZFS Guru een project waar meerdere mensen met echte kennis van zaken actief bij betrokken moeten zijn en niet alleen Jason.

Voor de survivability van een project is dat altijd beter. Toch kan het lastig zijn een klein project te runnen met meerdere mensen. Maar ik hoop dat Jason het wel oke vind als ik aan sommige delen zou werken bijvoorbeeld. Krijg er eigenlijk nu wel zin in.

Maar ik ga binnenkort op vakantie dus het zou al snel eind augustus/september worden dat ik daadwerkelijk iets toevoeg.

Kriss27 schreef op maandag 25 juli 2011 @ 00:24:
Sinds vandaag zet ik mijn NAS ook in voor World Community Grid

Mja, klinkt wel aardig enzo. Maar toch: vroeger scheelde het qua power niet zoveel tussen 100% idle en 100% stressed. Nu zit daar een wereld van verschil tussen. Een NAS kan idle enorm zuinig zijn en stressed enorm veel energie verbruiken. Als je zo'n programma installeert raak je de energiezuinigheid natuurlijk wel kwijt. Stel je gaat van 40watt naar 100 watt dan zit je aan 120 euro per jaar extra energiekosten. Het is dus zeker niet gratis.

Tijdens de installatie van ZFSguru heb ik voor de optie "aggressive memory tuning" gekozen, waarbij meer dan 75% van het geheugen aan ZFS wordt toegewezen. Nu is mijn (noob-)vraag: Kan andere software gebruik maken van dat geheugen wanneer ZFS het niet nodig heeft?

Nee, in principe niet. Maar hoeveel geheugen ZFS daadwerkelijk verbruikt houdt onder andere verband met hoe groot de ARC is. In je /boot/loader.conf kun je de arc_min en arc_max instellen. Je kunt kijken op welke waardes deze in je huidige loader.conf ingesteld staan. De arc_min is zeg maar het laagste verbruik en arc_max het hoogste; maar dit is niet al het gebruik van ZFS alleen van de ARC cache.

Je kunt ook 'top' draaien op de server (inloggen met SSH? of anders direct op de PC met monitor inloggen) dan zie je 'wired' geheugen gebruik; dat is grotendeels ZFS. Wired wil zeggen dat het niet geswapped kan/mag worden. Active = programma's (normaal maar iets van 40MB ofzo; erg laag dus!), Free = echt vrij/ongebruikt geheugen.

Het beste kun je een SWAP device ingesteld hebben; FreeBSD gebruikt die alleen als je hem echt nodig hebt. Met zoveel ruimte voor ZFS kun je af en toe die swap echt nodig hebben; anders gebeuren er vervelende dingen zoals processen die spontaan gekilled worden.

Waar zie je die 'aggressive' memory tuning eigenlijk?

[Kriss1981]

Anoniem: 15758 schreef op maandag 25 juli 2011 @ 03:04:
Mja, klinkt wel aardig enzo. Maar toch: vroeger scheelde het qua power niet zoveel tussen 100% idle en 100% stressed. Nu zit daar een wereld van verschil tussen. Een NAS kan idle enorm zuinig zijn en stressed enorm veel energie verbruiken. Als je zo'n programma installeert raak je de energiezuinigheid natuurlijk wel kwijt. Stel je gaat van 40watt naar 100 watt dan zit je aan 120 euro per jaar extra energiekosten. Het is dus zeker niet gratis.

[...]

Waar zie je die 'aggressive' memory tuning eigenlijk?

Het verbruik is bij mij idle 65watt en onder load 100watt. Daar komt bij dat mijn NAS alleen van 09:00uur tot 23:00uur is ingeschakeld. Die paar euro per maand heb ik wel over voor de bijdrage aan dit project.

Weet zo uit mijn hoofd niet waar dat aggresive tuning staat, zal het vanavond, wanneer ik thuis ben, even opzoeken.

De vraag over het geheugen stel ik, omdat er bij World Community Grid, projecten zijn die minimaal 1GB vrij geheugen vereisen. Mijn NAS bestaat uit een RAIDZ2 van 6x2TB Samsung F4 met 8GB geheugen. Ik denk dat ik liever al dit geheugen beschikbaar hou voor ZFS.

[Anoniem: 15758]

35W = 70 euro bij 24/7 gebruik. In jouw geval heb je 14/24 uur gebruik dus dan kom je uit op 40 euro per jaar ofwel 3,40 euro per maand; valt best mee ja. Natuurlijk heb je wel het nadeel van extra warmteproductie, geluid vanwege de fans, mogelijk slijtage en mindere performance; ook al gebeurt die processing op een lage prioriteit je zorgt er nog steeds voor dat de latencies voor ZFS hoger worden dus het heeft wel iets effect. Maargoed als je graag wilt bijdragen aan dat project zie ik geen echt grote bezwaren; valt opzich prima te doen.

Je kunt in top kijken hoeveel ruimte je vrij hebt. Probeer eens lokaal iets van 100 gigabyte schrijven ofzo; en dan na een aantal minuten maximale load kijken hoeveel geheugen je echt vrij hebt. Is dat minder dan 1 gigabyte dan raad ik aan je memory tuning iets te verzachten. En sowieso: gebruik SWAP! Met ZFS ZVOL kun je heel mooi swap inschakelen. Commando's kan ik voor je opzoeken als je wilt.

[FireDrunk]

Ik weet niet of dat gaat werken... Als ik de procedures goed begrijp, word IO in het geheugen altijd gealloceerd als cached, en niet als echt toegewezen... Bij een Unix machine word het geheugen altijd 100% gebruikt voor caching. Als ik 100GB schrijf is mijn geheugen gewoon vol... Dat wil niet zeggen dat mijn server traag word, maar wel dat de laatste 10GB nog in het geheugen staat... En als ik die dus weer inlees, dat gewoon uit het geheugen komt.

ZFS heeft (neem ik aan) niet een eigen process wat daadwerkelijk 10GB geheugen in beslag neemt... Dat zou lastig zijn om dan te kunnen bepalen wanneer ZFS zijn cache moet legen t.o.v. andere programma's.

Kort door de bocht, je zou niet moeten kunnen zien hoeveel geheugen er echt gebruikt word door ZFS omdat die altijd ruzied met de rest van je systeem als het gaat om cached geheugen.

top - 13:52:11 up 23:01,  2 users,  load average: 1.10, 1.06, 1.05
Tasks: 153 total,   2 running, 151 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  2.4%sy,  0.0%ni, 97.3%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  12323416k total, 12236108k used,    87308k free,   154132k buffers
Swap:        0k total,        0k used,        0k free, [b]11184404k cached[/b]

[ Voor 18% gewijzigd door FireDrunk op 25-07-2011 13:52 ]

[Anoniem: 15758]

FireDrunk: wat je zegt klopt helemaal voor UFS en NTFS en Ext2/3/4 enzo; maar juist niet voor ZFS. Althans niet onder FreeBSD.

Onder FreeBSD als je 16GB RAM hebt en je gebruikt UFS filesystem, en je leest een 100GB bestand, dan staat grofweg de laatste 16GB daarvan in de RAM. Je ziet dan vrijwel al het geheugen als "InAct" (inactive). Dat is gecached geheugen wat zo kan worden vrijgemaakt als een programma dat nodig heeft; je echte "Free" memory zou dan erg laag moeten zijn vaak maar een paar megabyte. Ook Windows werkt op exact deze manier, dat kun je volgen in Task Manager - Performance tab bij Physical Memory.

Maar ZFS zeker op FreeBSD is heel anders. Daar wordt kernel geheugen gebruikt; en dat zie je in de kolom Wired staan. Dit is speciaal geheugen wat niet/nooit geswapped mag worden. Het werkt minder elegant als het geheugengebruik van UFS en andere simpele filesystems. De geheugenallocator onder Solaris OS is compleet anders dan hoe ZFS onder FreeBSD werkt. Onder Solaris werkt het beter dan onder FreeBSD; zeker voor weinig RAM (onder de 6 gigabyte).

Bij foute FreeBSD geheugeninstellingen (te lage kmem) krijg je dan ook panic crashes met meldingen als: kmem_map too small. Dat is een nadeel van de manier hoe FreeBSD geheugen alloceert voor ZFS. In Solaris denk ik dat het OS en ZFS sterk zijn geïntegreerd en dat heeft zeker op dit vlak zijn voordelen.

[FireDrunk]

Maar dat betekend dus indirect dat ZFS andere programma's zou kunnen vertragen om meer disk performance te kunnen halen... Dat lijkt me ongewenst gedrag...

[Anoniem: 15758]

Vertragen? Voor normale programma's geldt dat ze gewoon het geheugen nodig hebben waar ze om vragen; zo niet wordt er of geswapped of worden er processen gekilled. Meer geheugen betekent niet meer performance.

Alleen voor filecache geldt wel meer geheugen betekent meer caching en dus meer performance; dus je wilt het liefst dat je filesystem al het niet-gebruikte geheugen als cache gebruikt, maar wel beschikbaar heeft als programma's het nodig hebben. Dus programma's gebruiken bijvoorbeeld 8% van je RAM en je filesystem gebruikt de overige 92%; dat is zeker voor (UNIX) servers een normale en gewenste situatie.

Het probleem is dat ZFS onder FreeBSD geheugen gebruikt wat niet zomaar teruggegeven kan worden aan de programma's als die extra RAM nodig hebben, en ook gebruikt ZFS niet al het vrije geheugen voor de ARC cache. Deze twee problemen zijn dus niet erg wenselijk; en ik hoop dat dat ooit verandert zodat de ARC cache van ZFS net als ouderwetse filesystems geheugen erg dynamisch gebruiken; alles gebruiken wat er is maar als programma's opeens 400MB nodig hebben ofzo dan ook gelijk vrij kunnen maken; dát is de gewenste situatie. Hoe het onder Solaris werkt weet ik niet precies, maar het werkt daar in elk geval wel beter dan op dit moment onder FreeBSD.

[FireDrunk]

Daar ben ik het niet helemaal mee eens...

Stel je hebt een database die ingeladen word vanaf disk, dan komt de ruwe data daarna in memory van ZFS en word daarna geleverd aan de applicatie. Die gebruikt geheugen waar hij de database weer in losse tabellen in opslaat.

Op die database worden index gebouwd (at start van een database, full-table-walk) en word daar ook weer geheugen voor toegewezen.

Stel dat ZFS die ruwe database vast zou houden, en de applicatie dus geen geheugen zou krijgen om zijn database in memory te krijgen, maar swap geheugen toegewezen krijgt, zou de database toch echt substantieel trager worden.

Dit terwijl de data niet meer nodig is voor de database applicatie. ZFS doet zijn kunstje, namelijk caching, maar de applicatie heeft hier dan van te lijden...

[Anoniem: 15758]

Ja als je swap gaat meerekenen, oke. Maar normaal mag dat niet gebeuren. Swappen = een noodmaatregel; het alternatief is het proces killen of het hele OS crashen.

Normaal als een applicatie meer geheugen wilt, snoept hij dat gewoon af van de filecache. Bij ZFS op FreeBSD werkt dat dus minder elegant; en kan een situatie zoals jij schetst dus inderdaad voorkomen. Dat ligt wel erg aan de ZFS instellingen; zo heb je arc_min en arc_max. Ik speculeer nu, maar het kan zijn dat bij memory shortage ZFS niet probeert tot de arc_max te gaan; zodat het programma toch meer geheugen krijgt. Maar hoe dan ook; het werkt heel anders dan normaal UFS waar een programma AL het geheugen van UFS kan gebruiken; als UFS 16GB RAM gebruikt dan is al dat geheugen beschikbaar voor programma's; als die dat op enig moment nodig zouden hebben. Bij ZFS werkt het minder elegant; althans onder FreeBSD.

Hoe het exact werkt, met name bij memory shortage, weet ik niet precies. Ik kan me voorstellen dat in de begindagen van ZFS op FreeBSD het stukken slechter werkt dan nu en er dus wel degelijk geprobeerd wordt de nadelen zoals geschetst te voorkomen. Maar de ideale situatie is zeker nog niet bereikt; terug naar een situatie zoals met UFS memory allocation. Nu is het bijvoorbeeld zo dat zonder tuning ZFS een heleboel geheugen gewoon niet gebruikt en dus echt als 'free' compleet ongebruikt verspild wordt. Dat is zonde want niet gebruikt geheugen is verspild geheugen. Het best is het altijd als cache te gebruiken en vrij te maken zodra programma's dat nodig hebben.

Programma RAM gebruik + filesystem cache = 100% physical RAM is dus de ideale situatie; de paar MB kernel geheugen en wat buffers uitgezonderd.

[Anoniem: 187449]

Examining ZFS At Point-Blank Range

ik wil deze code nog is (binnen napp-it) proberen

[FireDrunk]

Exact, zoals Linux het nu heeft

[Kriss1981]

Anoniem: 15758 schreef op maandag 25 juli 2011 @ 03:04:
Waar zie je die 'aggressive' memory tuning eigenlijk?

Op deze afbeelding zijn de ZFS tuning opties te zien, waar je tijdens de installatieprocedure uit kunt kiezen.

Anoniem: 15758 schreef op maandag 25 juli 2011 @ 11:58:
Je kunt in top kijken hoeveel ruimte je vrij hebt. Probeer eens lokaal iets van 100 gigabyte schrijven ofzo; en dan na een aantal minuten maximale load kijken hoeveel geheugen je echt vrij hebt. Is dat minder dan 1 gigabyte dan raad ik aan je memory tuning iets te verzachten. En sowieso: gebruik SWAP! Met ZFS ZVOL kun je heel mooi swap inschakelen. Commando's kan ik voor je opzoeken als je wilt.

Wanneer het systeem alleen gebruikt wordt door BOINC is er ongeveer 4 á 5GB vrij geheugen en tijdens het schrijven van 128GiB schommelt dit tussen 700 en 1100MB. Het is dus mogelijk om de projecten die meer geheugen vereisen mee te laten doen.

Met ZFSguru kan ik via de webinterface een ZVOL aanmaken. Hoe groot moet deze zijn? 1xRAM?

Hieronder de resultaten van de benchmark. Ben er zeer tevreden mee, want trek mijn gigabit lijntje mooi vol. Alleen wanneer het systeem tijdens het streamen van een bluray gaat parren/rarren dan wil de film nog wel eens gaan stotteren. Dit komt waarschijnlijk doordat het downloaden/parren/rarren op dezelfde pool gebeurt. Dit vanwege een tekort aan SATA poorten. Er komt binnenkort een LSI kaart bij met 8xSATA, zodat ik een aparte pool kan maken voor SABnzbd.

Pool : data
Read throughput : 443.9 MB/s
Write throughput: 242.7 MB/s

[Anoniem: 15758]

700 tot 1100MB is misschien iets te weinig als sommige projecten echt 1GB nodig hebben. Misschien kun je handmatig de arc_max nog iets naar beneden schroeven zodat je altijd tenminste 1 gig vrij hebt. Dan kun je gerust al die projecten doen. En op die screenshot zie ik ook een SWAP volume; dat lijkt mij een SWAP via ZVOL. En 2 gigabyte is opzich een goede hoeveelheid. Dus wellicht dat dit standaard allemaal al voor je geregeld wordt? Zo ja dan ben je snel klaar.

[DARKLORD]

ik ben van plan om van de week nieuwe hardware te bestellen voor mijn server. wil er esxi 4.1 VT-d op draaien met openindiana als storage en anders vm's zoals webserver etc. voornaamste doel wordt serveren van video en muziek via paar xbmc's.

in plaats van de Supermicro X8SIL-F nu een:
Supermicro X9SCM-F met Intel Xeon E3-1220L Boxed
met 16gb mem. 2x KVR1333D3E9SK2/8G

had op hardforums al berichtje gezet. heb even bevestiging nodig voordat ik ga bestellen

[FireDrunk]

Die E3-1220L schijnt amper leverbaar te zijn heb ik hier opgepikt... Misschien daar rekening mee houden?

[DARKLORD]

heb salland gemailt, 1 tot 10 dagen. zolang kan ik wel wachten.

[FireDrunk]

1 tot 10.. Das een standaard leveranciers praatje... maar het schijnt dat leveranciers ze niet hebben.. Die levertijd is dus kul (denk ik...).

En waarom niet een bordje met onboard LSI2008? Als je toch met VT-d wil werken...

http://tyan.com/product_S...=MB&pid=700&SKU=600000226

Zo eentje dus...

[ Voor 17% gewijzigd door FireDrunk op 26-07-2011 11:19 ]

[DARKLORD]

Hmmz.. Beter niet vooruit betalen dan.

ik heb zelf al een supermicro AOC-USAS-L8i kaartje die ik erin ga hangen. dan heb ik genoeg poortjes.

[Anoniem: 15758]

Wel mooi bordje opzich; lijkt me erg zuinig. Lijkt me een prima setup verder.

Ben ook benieuwd wat voor snelheden je haalt met dat ESXi; als je alles werkend hebt zou het misschien erg leuk zijn benchmarks te doen mét en zonder ESXi om te kijken hoeveel dat scheelt, bijvoorbeeld met een simpele sequential write (100GB) benchmark.

[FireDrunk]

Zeker interresant Ben ook wel benieuwd hoeveel penalty ZFS krijgt van ESXi

[Anoniem: 77995]

Op dit moment ben ik een NAS aan het bouwen met een bootable CF-kaart met FreeNAS en 8 SATA schijven.

Na veel onderzoek neig ik er nu naar om deze acht schijven te voorzien van een RAID-Z2 bestandssysteem, met als belangrijke reden dat de opslag --zoals ik het allemaal begrijp, als ZFS noob-- op die manier hardware-onafhankelijk blijft.

Voor ik me straks vast leg, zou ik dit toch graag bevestigd krijgen...

Is het inderdaad zo dat ik de 8 schijven nu op een moederbord met 8 SATA aansluitingen kan aansluiten (GA-DS3R), maar deze config op een later moment ook kan inbouwen op een ander moederbord, welke --als voorbeeld-- gebruik maakt van een PCI-E SAS kaart die via twee SFF-8087 poorten diezelfde 8 aansluitingen levert?
Of zitten daar toch nog beperkingen aan of addertjes onder het ZFS gras?

[ Voor 4% gewijzigd door Anoniem: 77995 op 26-07-2011 20:20 ]

[FireDrunk]

Zolang je een HBA (Host Based Adapter) gebruikt als die PCIe SAS controller, dan gaat dat prima werken.
Een RAID controller zou met wat kunst en vliegwerk misschien ook wel werken, maar dat wil je niet...

[Anoniem: 77995]

FireDrunk schreef op dinsdag 26 juli 2011 @ 20:45:
Zolang je een HBA (Host Based Adapter) gebruikt als die PCIe SAS controller, dan gaat dat prima werken.
Een RAID controller zou met wat kunst en vliegwerk misschien ook wel werken, maar dat wil je niet...

Dat is goed nieuws, want ik vermoed dat deze setup vrij snel gaat "verhuizen".

Ik ben niet helemaal zeker over de definitie van HBA; ik heb ook nog een HP Smart Array P400 RAID kaart liggen, zou ik die niet ook als 8-poorts SATA kaart kunnen gebruiken, als ik de hardware RAID niet gebruik, maar de kaart als "pass-through" inzet?

[FireDrunk]

Nee die P400 is nou juist een controller waarbij je problemen met TLER kan krijgen. Bovendien heeft een P400 geen passthrough modus Je kan wel RAID0 arrays van elke disk individueel maken, maar dan nog zit je met de timeout settings van de controller ipv je OS.

[Anoniem: 15758]

Een HBA (Host Bridge Adapter) is gewoon een PCI-express naar SATA bridge; dus een simpele controller zonder RAID functionaliteit. Een RAID controller is meer dan een HBA alleen; daar zit ook een RAID SOC op; een chip die in feite tussen de HBA en de PCIe zit. Dat kan zorgen voor problemen met timeouts en dus wegvallende schijven, betekent vrijwel altijd dat je geen TRIM mogelijkheid hebt, kan betekenen dat je geen of beperkte/omslachtige SMART ondersteuning hebt en verhoogt de latency omdat alle data nu via een extra chip loopt.

Voor ZFS wil je een 'echte' controller (HBA) zonder RAID functionaliteit. Passthrough of RAID0 arrays per disk is een mogelijkheid, maar kun je dus problemen krijgen zoals hierboven vermeld en in elk geval in mijn ervaring zorgt passthrough er niet voor dat het OS volledige controle heeft over de disk. Mijn Areca controller zorgte in passthrough nog steeds voor uitvallende disks; in zowel passthrough disk mode als in JBOD mode (alle disks automatisch passthrough). Kan wel zijn dat sommige controllers wel correct passthrough doen. Maar het beste is dus een 'echte' controller zonder RAID.

Populair zijn de LSI SAS controllers, bijvoorbeeld SuperMicro USAS-L8i (1068E) of de nieuwe USAS2-L8e. Die laatste doet PCI-express 2.0 en SATA/600 maar werkt niet onder alle OS. Alleen de meest recente FreeBSD ondersteunt die kaart; 8.2-RELEASE dus helaas niet. 8-STABLE inmiddels wel. Meer info kun je vinden op hardforum.

@DeKoning!: ben je je bewust van het feit dat 4K sector schijven het beste in een bepaalde configuratie kan worden gebruikt? Voor RAID-Z2 geldt dat 6 of 10 disks de beste configuratie is; veel beter dan 8 disks. Alleen met 512-byte sector schijven zoals de Hitachi 5K3000 heb je dat probleem niet. Heb je dus WD EARS of Samsung F4EG schijven, dan zou ik er 10 disks van maken in RAID-Z2. Dat is best een toffe configuratie gezien de lage redundancy overhead (weinig percentage verloren aan parity), uitstekende performance en goede bescherming. Je kunt 8 disks op een LSI controller zetten en 2 op je chipset SATA dat is geen enkel probleem.

Overweeg ook een Intel 320 SSD zodat je L2ARC en SLOG kunt gebruiken; de performance-boost die je pool tot grote hoogtes zal brengen.

[Kriss1981]

Anoniem: 15758 schreef op woensdag 27 juli 2011 @ 08:54:
Overweeg ook een Intel 320 SSD zodat je L2ARC en SLOG kunt gebruiken; de performance-boost die je pool tot grote hoogtes zal brengen.

Is een 40GB Intel 320 SSD hier ook geschikt voor? Deze heeft nog een schappelijke prijs, ongeveer 80 euro.
De leessnelheid van dit model is wel nog 200MB/s, alleen de schrijfsnelheid blijft niet veel van over, 45MB/s
Ik weet niet welke het belangrijkst is voor L2ARC en SLOG.

[Anoniem: 15758]

Ik noem de Intel 320 omdat dit de enige consumenten SSD is met supercapacitors. Deze werken momenteel overigens nog niet altijd naar behoren door een firmware defect, maar dat is iets waar aan gewerkt wordt en dat kun je binnenkort oplossen met een firmware update. Als je de Intel 320 koopt, doe je er verstandig aan nog geen SLOG te gebruiken totdat je deze firmware fix toepast.

De 40GB versie is in principe prima geschikt; alleen zoals je zegt is de write snelheid erg beperkt. Dat is een beetje het nadeel van de Intel 320; lees snelheden en random I/O is allemaal prima, maar de 40GB en 80GB versies hebben een vrij beperkte sequential write. De 120GB versie is hierin veel beter en heeft een acceptabele writesnelheid.

Echter voor L2ARC hoef je alleen te kijken naar multiqueue random read performance. Alle SSDs zijn hierin goed, behalve JMicron/Toshiba omdat die geen NCQ ondersteunen. Je hebt geen SSD met supercapacitor nodig voor L2ARC; corruptie is niet erg omdat ZFS dit detecteert. Voor SLOG is het anders, daarvoor heb je wel een supercap nodig voor acceptabele betrouwbaarheid en hiervoor is de sequential en random write snelheid belangrijk.

Voor L2ARC heb je dus random read performance nodig, voor SLOG heb je alleen sequential+random write nodig. Van een SLOG wordt alleen gelezen vlak na een stroom failure of crash; verder alleen maar writes.

[Anoniem: 77995]

@CiPHER en @FireDrunk:

Geweldige informatie! Alles wat ik in de laatste weken heb gelezen, maar niet altijd volledig begreep - en dan als een held samengevat in een paar paragrafen. Hulde.

Ik weet nu wel wat ik ga doen

P400 verkopen, 8-poorts SAS/SATA kaartje aanschaffen en op slinkse wijze 10 HDDs het huis in smokkelen want dit is net iets meer dan ik zo even kan verantwoorden, dat was met 8 al lastig, haha!

@CiPHER goed plan om er de 320 in te zetten, maar performance is in dit geval niet nodig. Het gaat om een media-archief dus als het op 100Mbit kan streamen is het al overkill. Omdat ik er verder geen backup van ga maken is enige redundantie wel belangrijk, vandaar Z2.

[ Voor 24% gewijzigd door Anoniem: 77995 op 27-07-2011 11:24 ]