Het grote ZFS topic

[Snow_King]

Mattijs.id schreef op maandag 21 januari 2013 @ 16:02:
hoi allen - in plaats van een eigen topic, probeer ik het eerst hier:

- ik heb nu een raid5 opstelling met mdam met 5 schijven van dezelfde grootte. en ik heb nog 2 schijven van andere grootte (maar wel gelijk aan elkaar) die ik in raid1 wil gaan zetten, met een ssd als bootschijf..
- ik wil naar: zfs raidz2 met 5-7 schijven (dus 0-2 schijven erbij), en een raid1 equvalent van zfs met de andere 2 schuiven.

Mijn vragen?
- Ik ben bijvoorbeeld bij Nas4Free (zag er in eerste instantie beter uit, minder gestript van freebsd) de virtualbox plugin wel tegengekomen; waarbij mijn vraag is; is het enigzins performend? kan het 1-2 vmmetjes aan die ik puur voor mezelf inricht.
- ik draai nu ook: boinc, crashplan, transmission, ssh, apache2. munin, cups, tomcat, nagios, virtualbox etc. Los van het feit of deze beschikbaar zijn (of iig in alternatieve vorm). Is het wel praktisch om dit erbij te willen draaien, of kan ik dan beter richting een andere oplossing gaan denken?

Met als grootste prio virtualbox, gezien ik de web omgeving wil kunnen terugdraaien in versies mocht het struikelen. Kan met ZFS ook geloof ik alleen dat is volgens mij niet een hele zuivere manier (verkeerde niveau... op os niveau iets snapshotten om binnen een applicatie een versie terug te draaien .. >.< )

Of moet ik richting freebsd gaan denken om dit fatsoenlijk en 'netjes' te krijgen?

Heb stiekem weinig zin in commandline zfs namelijk.


Specs:
Intel g530, 5x2tb, 2x1tb, 60gb ssd,8gb geheugen, voornamelijk backups is multi-user (denk 1-3, uitzonderlijk 4-5) de rest is vooral voor mezelf. de virtualbox is een mirror omgeving van mijn vps, en oook heb ik nog een xp-vmmetje die ik aan wil zetten als het even kan

Ik zou eens gaan stoeien met ZFS on Linux.

Ik heb het al een behoorlijke tijd lekker stabiel draaien op een paar dozen.

[Mattijs.id]

FireDrunk schreef op maandag 21 januari 2013 @ 16:09:
Poeh, das een hele ingewikkelde... Ik denk persoonlijk dat het je echt teveel ellende gaat kosten om al die services op FreeBSD werkend te krijgen (als het al kan...)

ZFS Command line is wel het minste waar je je dan druk over hoeft te maken...

Dus eigenlijk zeg jij; 1 machine voor alle services, 1 voor zfs?

Is het dan niet mogelijk om het volgende te doen:

ssd: ubuntu-server o.i.d. met daarop een vm.
Die vm bevat nas4free die alle schijven regelt.

Of het in zijn geheel virtualizeren met vmware ofzeau ?

Anything? =P Anders moet ik weer een complete pc kopen Of geen zfs draaien.. kan ook =p

[jadjong]

Contagion schreef op maandag 21 januari 2013 @ 16:23:
[...]


Ik snap dat toch niet helemaal. Ik begrijp dat je slack space hebt die je verliest omdat je de recordgrootte van 128 KB niet goed kan verdelen als je geen macht van 2 aan disks hebt. Daarnaast heb je dat metadata die bij een ashift=12 array ook minimaal 4096 bytes inneemt ipv 512, zelfs als die metadata slechts een fractie van die hoeveelheid data is. Gegeven bijv. een file van 1 GB heb je toch alleen dat je slack verliest aan het laatste record van die file? 1000 files van 1 GB geven dus veel minder slack dan 1000000 van 1 MB?

Hoe zit het nou precies?

Met raid5 plaats je data op vier disks, de vijfde is parity. De mate waarin het bestand in stukjes wordt gehakt is afhankelijk van:
Disk sectorsize(512/4K)
Stripe size (variabel per raidset, meestal 4K-1MB)
Partitie blocksize
Als deze niet over elkaar passen wordt het een zooitje.
Met een 16K stripe size wordt elke 16K aan data verdeelt over de vier disks, 4K per disk. Bij raid5 op zes disks heb je vijf bruikbaren schijven, elke 16K wordt dan door vijf gedeeld. Hoe groter de stripesize, hoe kleiner de overhead.

[FireDrunk]

Mattijs.id schreef op maandag 21 januari 2013 @ 17:21:
[...]


Dus eigenlijk zeg jij; 1 machine voor alle services, 1 voor zfs?

Is het dan niet mogelijk om het volgende te doen:

ssd: ubuntu-server o.i.d. met daarop een vm.
Die vm bevat nas4free die alle schijven regelt.

Of het in zijn geheel virtualizeren met vmware ofzeau ?

Anything? =P Anders moet ik weer een complete pc kopen Of geen zfs draaien.. kan ook =p

Het is eigenlijk allemaal kut, want FreeBSD en die services gaan niet echt lekker samen. Maar een ander OS met ZFS gaat niet zo lekker samen.

En daarbij, virtualisatie en ZFS gaan weer niet zo goed samen, dan moet je weer aan een heleboel eisen voldoen...

[Contagion]

jadjong schreef op maandag 21 januari 2013 @ 17:24:
[...]

Met raid5 plaats je data op vier disks, de vijfde is parity. De mate waarin het bestand in stukjes wordt gehakt is afhankelijk van:
Disk sectorsize(512/4K)
Stripe size (variabel per raidset, meestal 4K-1MB)
Partitie blocksize
Als deze niet over elkaar passen wordt het een zooitje.
Met een 16K stripe size wordt elke 16K aan data verdeelt over de vier disks, 4K per disk. Bij raid5 op zes disks heb je vijf bruikbaren schijven, elke 16K wordt dan door vijf gedeeld. Hoe groter de stripesize, hoe kleiner de overhead.

RAID 5 is niet echt vergelijkbaar. Voor zo ver ik weet is de stripesize ook juist de ruimte die je per disk opdeelt (toch?). Een stipesize van 16 KB is dus 16KB per disk en niet gedeeld door het aantal disks. Daaroverheen ligt een filesysteem die niks te maken heeft met de stripesize, echter bij grote files is een grote stripesize handig omdat er dan meer gebruik gemaakt kan worden van de read-ahead eigenschappen en het wegvallen van de overhead om veel te wisselen tussen elke disk.

Verder geeft een stripesize geen overhead op je disk, slechts op de performance. Je kunt wel je bovenliggende filesysteem optimaliseren op de stripesize van de disk.

Bij zfs heb je echter wat meer problemen omdat je zowel het onderliggende RAID systeem hebt als het bovenliggende filesysteem. Ik vraag me alleen af of je bij het schrijven van een file van 1 GB echt zoveel verliest. Het is volgens mij niet zo dat je bij een record size van 128 KB (default van ZFS) over 5 disks elk 25.6 KB gaat schrijven en dus zo steeds 28 KB (dichtstbijzijnde 4 KB sectorwaarde) alloceert. De file is immers niet 'klaar' na 128 KB, er komt nog veel meer. Alleen bij het laatste blokje van 128 KB krijg je dus wat slack.

Tenminste, dat is mijn aanname. Ik wil graag eten hoe het precies zit . Ik heb zelf een 13x 3TB RAID-Z3 array en ik verlies heel veel ruimte zodra ik het filesysteem alleen al create, met de optie ashift=12. Met ashift=9 is het verlies veel minder maar dat zit hem waarschijnlijk aan de hoeveelheid data die de metadata kost (minstens 4096 bytes vs 512 bytes). Maar hoe zit het nu dan met de record size en de hoeveelheid overhead bij veel grote files?

[Verwijderd]

@Contagion: het schrjiven van een 10GB bestand betekent in de praktijk dat dat bestand in 128KiB requests wordt geschreven, waarbij elke 128K dus opgedeeld wordt over de beschikbare disks. Per 128K verlies je dan ook een deel ruimte, wat uiteindelijk dus flink kan optellen met een multi-TB array. 4K optimalisatie kan dus behoorlijk wat ruimte kosten afhankelijk van de configuratie.

B2 schreef op maandag 21 januari 2013 @ 11:40:
CiPHER is er al wat bekend over een nieuwe versie van ZFSGuru gebaseerd op 9.1 ipv 9.1RC3?

Ja, de beta9 web-interface duurt nog even, maar de 9.1-005 systeemversie zit er wel aan te komen. Ik durf geen ETA meer te noemen want de web-interface duurt nu ook langer dan voorzien. Maar ik verwacht dat dat nu niet lang meer kan duren.

jacovn schreef op maandag 21 januari 2013 @ 11:45:
Waarom reageert de gui niet meer als ik een 3 TB hdd wil volschrijven met 0 ?

Die zero-write gebeurt denk ik 'foreground' dus je browser-venster blijft loading zeggen. Zero-write wordt maar heel weinig gebruikt; dat heb je normaliter nooit nodig.

Ik wil 20 hdd's formateren, er moeten toch wel een aantal gelijk kunnen ?

Waarom zou je dan zero-writen? Je wilt de disks kunnen gebruiken onder ZFSguru? Formatteer dan gewoon normaal. Je kunt ze alle 20 tegelijk formatteren door ze te selecteren en dan kiezen voor Format with GPT. Dan vul je een label prefix in zoals 'disk' en je disks heten dan 'disk1' tot en met 'disk20'. Simpel zat.

Als je bestaande ZFS pools op de disks hebt en je wilt daar vanaf, importeer die pools dan eerst op de Pools pagina, en dan die pool selecteren en destroy pool onderaan klikken. Omdat je zelf hebt aangegeven die pool niet meer te hoeven, zal ZFS ook niet klagen als je de disks probeert te overschrijven met een nieuwe pool. Normaliter geeft hij dan een foutmelding als hij ziet dat er al een ZFS pool staat op één van je disks, om gebruikersfouten te verkleinen. Je moet dus actief aangeven dat je pool X niet meer wilt, voordat hij die zomaar overschrijft.

[Mattijs.id]

FireDrunk schreef op maandag 21 januari 2013 @ 17:34:
[...]

Het is eigenlijk allemaal kut, want FreeBSD en die services gaan niet echt lekker samen. Maar een ander OS met ZFS gaat niet zo lekker samen.

En daarbij, virtualisatie en ZFS gaan weer niet zo goed samen, dan moet je weer aan een heleboel eisen voldoen...

Dus fysiek gescheiden houden, als ik overga.. kayz

[FireDrunk]

Tja, dat is mijn optiek... Ik heb toch gekozen voor virtualisatie onder FreeBSD met VirtualBox.
Het werkt, maar supersnel is het niet.

Maar voor een gemiddelde thuisgebruiker is het snel zat...
Het is niet zo dat je zit te treuzelen ofzo...

[Verwijderd]

Mattijs.id schreef op maandag 21 januari 2013 @ 16:02:
- ik wil naar: zfs raidz2 met 5-7 schijven (dus 0-2 schijven erbij), en een raid1 equvalent van zfs met de andere 2 schuiven.

Voor RAID-Z is 5 disks optimaal in 4K mode, voor RAID-Z2 is 6 disks optimaal. Indien mogelijk hou je je aan deze optimale configuraties.

Mijn vragen?
- Ik ben bijvoorbeeld bij Nas4Free (zag er in eerste instantie beter uit, minder gestript van freebsd) de virtualbox plugin wel tegengekomen; waarbij mijn vraag is; is het enigzins performend? kan het 1-2 vmmetjes aan die ik puur voor mezelf inricht.

Waarom niet denk ik, zoveel rekenkracht hebben je extra services toch niet nodig? Volgens mij kan het prima wat jij wilt.

- ik draai nu ook: boinc, crashplan, transmission, ssh, apache2. munin, cups, tomcat, nagios, virtualbox etc. Los van het feit of deze beschikbaar zijn (of iig in alternatieve vorm). Is het wel praktisch om dit erbij te willen draaien, of kan ik dan beter richting een andere oplossing gaan denken?

Een heleboel hiervan kun je native op BSD draaien, zoals boinc, transmission, SSH, Apache, CUPS en VirtualBox. De dingen die overblijven die moeilijker op BSD werkend te krijgen zijn, stop je dan in een VM met Ubuntu ofzo. Lekker makkelijk.

Met als grootste prio virtualbox, gezien ik de web omgeving wil kunnen terugdraaien in versies mocht het struikelen. Kan met ZFS ook geloof ik alleen dat is volgens mij niet een hele zuivere manier (verkeerde niveau... op os niveau iets snapshotten om binnen een applicatie een versie terug te draaien .. >.< )

Dat kan, maar
1) je moet de snapshot aanmaken op het moment dat het boeltje stabiel is, dus de services niet draaien of zeker weten consistent zijn
2) als je restored moeten de services niet draaien. Restoren en rebooten is het meest praktisch denk ik.

Heb stiekem weinig zin in commandline zfs namelijk.

Mja, ik zie het probleem eigenlijk niet zo. Ik denk dat wat jij wilt wel kan met een beetje moeite erin gestoken om je services draaiende te krijgen, dat wel.

Specs:
Intel g530, 5x2tb, 2x1tb, 60gb ssd,8gb geheugen, voornamelijk backups is multi-user (denk 1-3, uitzonderlijk 4-5) de rest is vooral voor mezelf. de virtualbox is een mirror omgeving van mijn vps, en oook heb ik nog een xp-vmmetje die ik aan wil zetten als het even kan

Bedenk hierbij dat de hoeveelheid RAM-geheugen een bottleneck kan vormen. Zelf raad ik 2x8GiB aan dus 16GiB totaal met uitbreidingsmogelijkheid voor 32GiB. Gezien de lage prijs van RAM-geheugen moet je hier niet op bezuinigen IMO! Als je het zaakje al hebt kun je natuurlijk prima met 8GiB RAM beginnen. Maar met je services en VM erbij vind ik dat erg krap. Mijn Brazos NAS heeft al 16GiB.

[Contagion]

@Cipher

Verwijderd schreef op maandag 21 januari 2013 @ 19:08:
@Contagion: het schrjiven van een 10GB bestand betekent in de praktijk dat dat bestand in 128KiB requests wordt geschreven, waarbij elke 128K dus opgedeeld wordt over de beschikbare disks. Per 128K verlies je dan ook een deel ruimte, wat uiteindelijk dus flink kan optellen met een multi-TB array. 4K optimalisatie kan dus behoorlijk wat ruimte kosten afhankelijk van de configuratie.

Ok, ik heb een 13 disk RAIDZ3 array dus wordt elke 128 KB opgedeeld over 10 disks dus 12.8KB per disk. Vanwege 4 KB sectoren worden er dus 4 sectoren = 16 KB gealloceerd.Het kost me dus 160 KB om 128 KB op te slaan en dat is dus 25% verlies.

Analoog daaraan: als ik 1 file van 128 MB schijf worden dus 1000 records geschreven met gelijke overhead. Ik ben dus 160 MB kwijt voor het opslaan van 128 MB? Is dat echt zo, of alleen op de laatste paar bytes van die ene file?

Bij 512 byte sectoren zou ik voor 10 disks dus per disk dus 13KB schrijven (26 sectoren) ipv de 12.8KB en verlies je procentueel dus minder (1.5%). Is dat hoe het in elkaar zit?

[Waking_The_Dead]

Met enige vertraging: stats tijdens het afspelen van een BD-ISO.



Het afspelen start iets voor 19:00. Het geheugengebruik stijgt gedurende een dikke tien minuten tot het maximum en daarna begint het geluid weg te vallen en hapert het beeld. Dan is er soms gedurende 5 minuten geen probleem maar als er haperingen zijn, duurt het toch wel telkens een minuut ofzo.

[Contagion]

Vreemd verhaal hoor. Het stijgend geheugengebruik lijkt me gewoon caching, maar je zegt dat tegen het max. geheugen het stotteren begint. Echter blijft de doorvoer netjes rond de 40mbit/sec hangen. Als de doorvoer gelijk blijft, waarom zou hij dan gaan stotteren. Misschien echter is het plaatje vertekend omdat het gemiddeld wel 40mbit blijft maar dat er om een of andere reden soms even helemaal geen doorvoer is en daarna wat meer om de vraag in te halen, echter heeft hij dan al gestottered vanwege een 'buffer underrun'..?

[Waking_The_Dead]

Ik snap er zelf ook niets van. Ik heb nog een Synology DS211+ en als ik van daarop een ISO bekijk, dan is er geen enkel probleem. Het moet dus echt aan mijn ZFS NAS liggen en niet aan mijn netwerk.

[Contagion]

Nog even wat tests met blokgroottes, verdwenen ruimte en niet-2^n disks. Volgens mij valt het allemaal wel mee.

Ik heb eerst 2 RAID-Z3 arrays aangemaakt van 13 3TB drives. Eerst met ashift=9 en dan met ashift=12. Vervolgens geeft zfs list de volgende hoeveelheid vrije ruimte weer:

NAME                  USED  AVAIL  REFER  MOUNTPOINT
test-13d              221K  29.1T  79.2K  /test-13d
test-13d4k           1.24M  27.7T   395K  /test-13d4k

Je verliest dus van de ~30 TB zo'n 2.8 TB aan ruimte als je optimaliseert voor 4 KB sectoren. Dat is veel maar in verhouding met de array slechts 5%. Je verloor ook al 0.9 TB aan metadata bij ashift=9 (hoewel dit ook deels door GB vs GiB kan zijn).

Om verder te testen heb ik vervolgens 100 files van 100 MB geschreven en 10000 files van 1 MB. Je kan 128KB records niet efficient verdelen over 10 disks (3 disks parity) en dus zou je veel slack space kunnen hebben maar ook dat valt mee:

NAME                  USED  AVAIL  REFER  MOUNTPOINT
test-13d             19.6G  29.0T  19.6G  /test-13d
test-13d4k           19.8G  27.7T  19.8G  /test-13d4k

of met df -m om het wat duidelijker te zien:
Filesystem          1M-blocks    Used Available Use% Mounted on
test-13d             30466800   20064  30446737   1% /test-13d
test-13d4k           29060639   20237  29040403   1% /test-13d4k

Hier mis je dus op 10100 files nog geen 1% aan slack.

Er is dus in gebruik niet heel veel verschil in de hoeveelheid gealloceerde bytes. Ik heb gekozen voor de ashift=12 array omdat bij resilveren het volgens zeggen wel veel kan uitmaken als je een 4096 byte drive gebruikt terwijl de array voor 512 bytes is geoptimaliseerd. Ik heb dat risico niet genomen.

Ik zal zo nog wat tests doen met een optimale array vs een niet optimale array en hoeveel bytes je dan mist.

[Contagion]

Nog een test van (16+1)x 3 TB drive in RAID-Z1 (optimaal) vs (17+1)x 3 TB drive in RAID-Z1. Het verschil in verloren ruimte bij creeeren is nihil (niet zichtbaar waar je bij 10+3 drives wel verschil zag in AVAIL):

NAME                  USED  AVAIL  REFER  MOUNTPOINT
test-16d-512         9.79G  46.7T  9.79G  /test-16d-512
test-16d-4096        9.90G  46.7T  9.90G  /test-16d-4096
test-17d-512         9.79G  49.5T  9.79G  /test-17d-512
test-17d-4096        9.90G  49.5T  9.90G  /test-17d-4096

Na het schrijven van 10000 files van 1 MB:

NAME                  USED  AVAIL  REFER  MOUNTPOINT
test-16d-4096        9.90G  46.7T  9.90G  /test-16d-4096
test-16d-512         9.79G  46.7T  9.79G  /test-16d-512
test-17d-4096        9.90G  49.5T  9.90G  /test-17d-4096
test-17d-512         9.79G  49.5T  9.79G  /test-17d-512

Ik vind het vreemd dat tussen de optimale array met ashift=9 en ashift=12 toch nog verschil zit bij 'refer'. Ik zou denken dat een optimale array geen verschil toont omdat 128 zowel deelbaar is door 4 als door 0.5.

Verder is er ook geen verschil tussen de optimale array en niet-optimale array qua gealloceerde ruimte. Misschien is het verschil tussen 16 en 17 drives te klein om terug te gaan zien bij 10000 files.

Ik heb deze tests uitgevoerd door een zpool te maken van sparse-files op een bestaande ashift=12 array. Ik denk dat dat geen verschil in resultaten moet geven omdat ZFS geen weet heeft van de onderliggende structuur maar als mijn bevindingen niet kloppen dan hoor ik dat natuurlijk graag . Om deze reden kan ik ook geen snelheidstest uitvoeren tussen optimaal en niet optimaal.

Al met al denk ik wel dat voor thuisgebruik een array van2^n+parity disks niet per se nodig is en als je de schijven hebt, je je vooral moet focussen op de hoeveelheid vrije ruimte die je wilt creeeren. Bij niet-optimale arrays raak je wel ruimte kwijt aan slack space, maar waarschijnlijk is dat minder dan dat de drive zelf toevoegt.

Het instellen van ashift=12 lijkt meer in te boeten aan ruimte bij een 'foute' configuratie van drives. Met het oog op de toekomst van harddisks zou ik wel kiezen voor 4KB sector optimized array.

[Verwijderd]

Waking_The_Dead schreef op maandag 21 januari 2013 @ 20:40:
Met enige vertraging: stats tijdens het afspelen van een BD-ISO.

[afbeelding]

Gebruik je zowel UFS als ZFS op dat systeem? Want je inactive lijkt geheugen van ZFS (wired) weg te drukken. Dat hoort normaliter niet; je wired hoort tegen 75-85% van je RAM te zitten.

Probeer verder max_pending=1. Welk OS draai je? FreeNAS of NAS4Free lijkt mij?

[jacovn]

[b]CiPHER schreef op maandag 21 januari 2013 @ 19:08
[...]

Die zero-write gebeurt denk ik 'foreground' dus je browser-venster blijft loading zeggen. Zero-write wordt maar heel weinig gebruikt; dat heb je normaliter nooit nodig

Waarom zou je dan zero-writen? Je wilt de disks kunnen gebruiken onder ZFSguru? Formatteer dan gewoon normaal. Je kunt ze alle 20 tegelijk formatteren door ze te selecteren en dan kiezen voor Format with GPT. Dan vul je een label prefix in zoals 'disk' en je disks heten dan 'disk1' tot en met 'disk20'. Simpel zat.

Als je bestaande ZFS pools op de disks hebt en je wilt daar vanaf, importeer die pools dan eerst op de Pools pagina, en dan die pool selecteren en destroy pool onderaan klikken. Omdat je zelf hebt aangegeven die pool niet meer te hoeven, zal ZFS ook niet klagen als je de disks probeert te overschrijven met een nieuwe pool. Normaliter geeft hij dan een foutmelding als hij ziet dat er al een ZFS pool staat op één van je disks, om gebruikersfouten te verkleinen. Je moet dus actief aangeven dat je pool X niet meer wilt, voordat hij die zomaar overschrijft.

10 nieuwe en 10 bestaande hdd. Voor de nieuwe :
3 x 4 TB hitachi, 1 x DOA, start in het geheel niet op
7 x 3 TB toshiba, 1 x klik klik klik drive.

Dus ik wil de rest graag testen voor gebruik.... En dan maar in 1 keer rma doen, en niet na een paar weken of maanden moetn resilveren.

Als ik wel die zero write wil doen, en dan de smartdata voor en na wil controleren, moet ik dan op de command line dat script uitvoeren, en in de achtergrond opstarten? Is dat niet iets met & teken ?

[ Voor 0% gewijzigd door jacovn op 22-01-2013 08:46 . Reden: Typefouten ]

[Contagion]

Kan je hem ipv zero-writen dan niet beter een long selftest laten doen? In linux is dat 'smartctl -t long /dev/sd<x>'. De drive checkt dan zelf alle sectoren en als er iets mis mee is dan komt dat in het self test log te staan. Je kan de drive in de tussentijd gewoon blijven gebruiken.

[Waking_The_Dead]

Verwijderd schreef op dinsdag 22 januari 2013 @ 00:25:
[...]

Gebruik je zowel UFS als ZFS op dat systeem? Want je inactive lijkt geheugen van ZFS (wired) weg te drukken. Dat hoort normaliter niet; je wired hoort tegen 75-85% van je RAM te zitten.

Probeer verder max_pending=1. Welk OS draai je? FreeNAS of NAS4Free lijkt mij?

Ik heb een normale FreeNAS installatie gedaan en voor ZFS gekozen. Geen idee of UFS ergens via een achterpoortje binnengeslopen is. Hoe kan ik dat nagaan?

[FireDrunk]

Heb je FreeNAS op een USB stick? Dan staat daar zeer waarschijnlijk UFS op. Maar die zal ZFS niet in de weg zitten als hij niet gebruikt word.

Volgens mij helpt max_pending vooral bij schrijven, en wat minder bij lezen...

Blijft een vreemd probleem.

[ Voor 28% gewijzigd door FireDrunk op 22-01-2013 09:42 ]

[Waking_The_Dead]

FireDrunk schreef op dinsdag 22 januari 2013 @ 09:41:
Heb je FreeNAS op een USB stick? Dan staat daar zeer waarschijnlijk UFS op. Maar die zal ZFS niet in de weg zitten als hij niet gebruikt word.

Volgens mij helpt max_pending vooral bij schrijven, en wat minder bij lezen...

Blijft een vreemd probleem.

FreeNAS op USB ja.

[FireDrunk]

Dan hoef je je (in mijn ogen) niet druk te maken over UFS.

[Verwijderd]

Zolang die UFS filesystem niet gemount is, heb je geen probleem inderdaad. Maar als die wel gemount is, zal de filecache alles cachen wat je aanraakt. Deze cache (Inactive memory) zal ten koste gaan van ZFS. Dus als je een mounted UFS-filesystem hebt met 1GB files erop die je ook aanspreekt/inleest, dan heeft ZFS 1GB minder aan RAM omdat deze door UFS wordt gebruikt. Het unmounten van het UFS-filesystem zal dit geheugen weer vrijmaken.

UFS en ZFS is om die reden een slechte combinatie, omdat UFS geheugen 'steelt' van ZFS en niet terug geeft. Of dit ook de reden is van je performanceproblemen, blijft gissen. Maar je geheugenprint verraad in elk geval dat je softwareconfiguratie niet lekker is. Je hoort niet zoveel inactive geheugen te hebben. Welke FreeBSD versie draai je exact?

[FireDrunk]

FreeNAS op een USB stick, neemt volgens mij hooguit een paar honderd MB in beslag.
Dat zou dus inderdaad van je ZFS geheugen af gaan.

[Waking_The_Dead]

Verwijderd schreef op dinsdag 22 januari 2013 @ 10:17:
Zolang die UFS filesystem niet gemount is, heb je geen probleem inderdaad. Maar als die wel gemount is, zal de filecache alles cachen wat je aanraakt. Deze cache (Inactive memory) zal ten koste gaan van ZFS. Dus als je een mounted UFS-filesystem hebt met 1GB files erop die je ook aanspreekt/inleest, dan heeft ZFS 1GB minder aan RAM omdat deze door UFS wordt gebruikt. Het unmounten van het UFS-filesystem zal dit geheugen weer vrijmaken.

UFS en ZFS is om die reden een slechte combinatie, omdat UFS geheugen 'steelt' van ZFS en niet terug geeft. Of dit ook de reden is van je performanceproblemen, blijft gissen. Maar je geheugenprint verraad in elk geval dat je softwareconfiguratie niet lekker is. Je hoort niet zoveel inactive geheugen te hebben. Welke FreeBSD versie draai je exact?

kern.ostype: FreeBSD
kern.osrelease: 8.2-RELEASE-p9
kern.osrevision: 199506
kern.version: FreeBSD 8.2-RELEASE-p9 #0: Tue Jun 12 08:57:14 PDT 2012

Mijn volledige config staat hier: Waking_The_Dead in "Het grote ZFS topic"

[Verwijderd]

FreeBSD 8.2 is best wel oud onderhand. Ik zou persoonlijk zeker voor 8.3 / 9.0 / 9.1 gaan. Heeft ook ZFS patches die belangrijk kunnen zijn. Ook heeft BSD 8.2 bepaalde UFS+ZFS patches niet.

Maar FireDrunk heeft wel gelijk als het gaat om UFS: als je hooguit 200MB op de USB-stick hebt staan die is gemount; kan UFS nooit meer dan 200MB RAM-geheugen in beslag nemen. Je zou eens met 'mount' moeten kijken of je nog andere UFS filesystems hebt gemount. Ook kan ik je aanraden een modernere BSD versie uit te proberen.

[FireDrunk]

Kan je niet beter overstappen op Nas4Free? Of heb je heel veel configuratie in deze install zitten?

[Waking_The_Dead]

Allright, dan probeer ik maar eerst even te upgraden naar de meest recente versie van FreeNAS.
Is er een reden waarom ik Nas4Free boven FreeNAS zou moeten verkiezen?

[FireDrunk]

FreeBSD 9

[Waking_The_Dead]

Houdt het overschakelen naar Nas4Free risico's in mbt mijn data?
Ik vermoed dat ik gewoon Nas4Free op een USB stick zet en vervolgens mijn vdev importeer ofzo?

[FireDrunk]

Ja voor zover ik weet kan je je pool gewon importeren. Het is misschien netjes om eerst je oude pool te exporteren.

[Waking_The_Dead]

FireDrunk schreef op dinsdag 22 januari 2013 @ 14:29:
Ja voor zover ik weet kan je je pool gewon importeren. Het is misschien netjes om eerst je oude pool te exporteren.

En wat houdt dat precies in? Zet dat de pool in een bepaalde status of heb ik dan nog eens 8TiB aan opslagruimte nodig?

[Borromini]

Als je de pool niet exporteert in je vorige OS zal je in het nieuwe -f (force) moeten gebruiken.

Is hier overigens goed gegaan bij m'n switch van BSD naar Linux, maar had ik het toen geweten had ik 't ook netjes geëxporteerd.

[FireDrunk]

Het is een soort van Unmount...

[Hakker]

Als ik mijn nieuwe array een slog partitie wil geven krijg ik met het testen een wit scherm meer niet. de andere array die een slog op dezelfde SSD heeft heeft nog steeds een werkende slog tenminste wat ik zo kan zien 1-2-3

ik gebruik 9.1.004 met Beta8 maar snap niet echt waarom hij bij mijn 2de array niet wil werken.

[FireDrunk]

Je kan hem ook zonder testen toevoegen via commandline. Misschien krijg je dan een foutmelding die ZFSguru niet snapt ofzo...

[Trunksmd]

Waking_The_Dead schreef op dinsdag 22 januari 2013 @ 14:33:
[...]


En wat houdt dat precies in? Zet dat de pool in een bepaalde status of heb ik dan nog eens 8TiB aan opslagruimte nodig?

Normaal gesproken heb je het OS van FREENAS op een andere schijf/usb stick staan dan je data pool. Bij NAS4FREE of ZFSGuru kun je deze pool dan makkelijk importeren. Dit is niet hetzelfde als kopieren. Je laad gewoon je pool. En je OS kan het lezen. Dit is wel een stuk lastiger als je toevallig je OS in diezelfde pool hebt staan. ( je hebt van die mensen)
Maar als je tevreden bent met FREENAS kun je heel makkelijk je OS opgraden in de grafische interface. Van FREENAS 8,2 naar 8,3 zou dat geen probleem moeten zijn.
Ik draai zelf nu ook al 3 weken FREENAS 8,3 naar volle tevredenheid. Mijn reden hiervoor is dat FREENAS een heel goede en uitgebreide guide heeft, die NAS4FREE en ZFSGuru (nog) niet hebben.
Het nadeel is dat er een bedrijf achter zit en je nooit weet wat die ermee gaan doen in de toekomst. Maar zover ik weet, blijft FREENAS opensource. Volgens andere forumleden is de grafische interface niet altijd even ¨netjes¨geprogrammeerd. Maar volgens mij is in FREENAS 8.3 veel hersteld. Het doet wat het moet doen. En de jails werken ook perfect.
Het wordt een stuk moeilijker als je meer wil installeren dan FREENAS biedt. (bijvoorbeeld XBMC). Dan ben je beter af bij NAS4FREE en ZFSGuru, omdat je daar een volledig FREEBSD versie hebt. Wel moet je dan wat beter onderlegd zijn in BSD en niet zo een noob zijn als ik. CLI zul je hoe dan ook moeten gebruiken. (hoewel dat ook voor de jails in FREENAS geldt).

[ Voor 5% gewijzigd door Trunksmd op 23-01-2013 09:50 ]

[Squixx]

Ik ben zelf ook bezig met een ZFS servertje bouwen, dit is so-far mijn plan:

#	Product	Prijs	Subtotaal
1	Intel Pentium G860 Boxed	€ 54,95	€ 54,95
1	ASRock B75 Pro3-M	€ 57,40	€ 57,40
5	Seagate Barracuda 7200.14 ST3000DM001, 3TB	€ 113,90	€ 569,50
1	Fractal Design Define Mini	€ 81,36	€ 81,36
1	Sandisk Cruzer Blade	€ 4,71	€ 4,71
1	Corsair CMV8GX3M1A1333C9	€ 35,70	€ 35,70
1	Seasonic S12II 380W	€ 47,-	€ 47,-
Bekijk collectie Importeer producten		Totaal	€ 850,62

(oh trouwens, het moeten dus 2 van die sandisk stikkies zijn)


met de 3tb schijven in een Raid-z1 array. Freenas draaiende van usb1, de plugin jail op usb2,
en nog een oude 2,5" 200gb schijf als download schijf, zodat m'n raid array niet de hele nacht aanstaat tijdens het downloaden.

(ik ga downloaden met sabnzbd, dacht de 2,5" schijf als download schijf, die uitpakt naar de raid array)

Nu zie ik jullie net praten over een UFS schijf naast ZFS.

hoe is het voor mij het handigst om dit te configureren? ik dacht eignelijk dat ik de download schijf als UFS moest hebben? of kan ik hier een 2e zfs systeem van maken? wat is hier wijsheid in?

ten tweede twijfel ik of ik nu genoeg geheugen heb, daar ik gelezen heb dat ZFS aardig wat kan gebruiken..


edit:
nu lees ik net dat de jail ook erg veel writes heeft (logs etc) dus wellicht is dat ook beter op de download schijf?

[HyperBart]

Voor diegenen die interesse hebben (het zijn niet mijn disks) en het vooral willen omdat de MTBF wat hoger ligt EN omdat het nu eenmaal goed aangeschreven disks zijn, deze kerel verkoopt een "setje":

V&A aangeboden: Hitachi Ultrastar 7K3000, 3TB 24/7 HUA723030ALA640 Nieuw

Enige nadeel: geen garantie...

Ik worstel de laatste tijd ook met een probleempje met ZFSguru/FreeBSD, ik heb een VM met een M1015 via VT-d gepassthroughed en VMtools geïnstalleerd. So far so good. De virtuele netwerkadapter die aan die VM hangt is een E1000 (ge-emuleerd, dus veilig en 1Gbit throughput). Ik had nu graag, om maximaal rendement van mijn SSD + 5 HDD's graag gebruik gemaakt van VMXNET3, een paravirtuele netwerkadapter die alleen werkt als de benodigde drivers (vaak via vmware tools) aanwezig zijn en snelheden biedt tot 10Gbit. Ideaal om als "back-end" adapter te gebruik voor mijn ESXi zijn storage.

Nu kom ik het probleem tegen dat wanneer ik deze adapter toevoeg en reboot mijn console volloopt met:

interrupt storm detected on irq18

Iemand een idee hoe ik dit kan opvangen of kan wegwerken? Ik heb al enkele dingen afgezet in het virtuele BIOS van de machine (virtual serial oid en zo van dat soort dingen om IRQ's vrij te maken) aangezien ik mij herinner dat IRQ storms "vroegah" voorkwamen doordat 2 apparaten in een computer aanspraak maakten op dezelfde IRQ en dat je dan een van de twee dingetjes duidelijk moest maken dat hij daar niet op mocht springen... Maar daar stopt het verhaaltje voor mij ook...

[ Voor 59% gewijzigd door HyperBart op 23-01-2013 20:07 ]

[FireDrunk]

MSI/MSI-X uitzetten in de guest. Interrupts storms komen voor als een device te vaak een interrupt afroept zodat je CPU onderbroken word in zijn huidige taak om de data van het device op te halen.

Als hij dat maar vaak genoeg doet zegt je OS vanzelf: "Eeujuuuh, pleurt op, ik wil nou wel eens ff wat werk verzetten..."

FreeBSD heeft nogal een matige MSI/MSI-X implementatie, en daar kan het mee te maken hebben.

[ Voor 85% gewijzigd door FireDrunk op 23-01-2013 20:45 ]

[Verwijderd]

ESXi en FreeBSD; proprietary + ultra-opensource, dat gaat over het algemeen niet perfect samen.

Wat ik verder nog heb gelezen: soms een tweede NIC aanmaken en de eerste verwijderen. De tweede krijgt een ander IRQ-nummer en dan zijn de problemen soms weg. Uitschakelen van MSI/MSI-X is natuurlijk eigenlijk een noodmaatregel. Net zoals je vroeger soms ACPI moest uitschakelen om BSD te kunnen booten op sommige platforms.

Waar het natuurlijk echt op aankomt is of VMware/ESXi zijn hypervisor zo herschrijft dat emulatie van bijvoorbeeld de LSI controller geupgrade wordt zodat het met recente drivers werkt die door LSI zelf zijn ontworpen. Nu is dat nog niet het geval.

Tot die tijd zul je moeten prutsen om dingen als LSI adapter en VMXNET3 goed werkend te krijgen. En dan nog is de performance lager dan had gekund, volgens mij.

[HyperBart]

FireDrunk schreef op woensdag 23 januari 2013 @ 20:43:
MSI/MSI-X uitzetten in de guest. Interrupts storms komen voor als een device te vaak een interrupt afroept zodat je CPU onderbroken word in zijn huidige taak om de data van het device op te halen.

Als hij dat maar vaak genoeg doet zegt je OS vanzelf: "Eeujuuuh, pleurt op, ik wil nou wel eens ff wat werk verzetten..."

FreeBSD heeft nogal een matige MSI/MSI-X implementatie, en daar kan het mee te maken hebben.

[root@zfsguru /home/ssh]# cat /boot/loader.conf | grep "msi"
#hw.pci.enable_msix="0"
#hw.pci.enable_msi="0"
hw.pci.enable_msix="0"
hw.pci.enable_msi="0"

Sommige mensen geven aan dat je best je kaart kan verhuizen naar een ander PCIe slot? Of kan ik in het pBIOS van mijn SuperMicro bordje ergens mijn M1015 een andere IRQ geven?

Nu doet ie het met mijn E1000 adapter EN mijn VMXNET3

[ Voor 14% gewijzigd door HyperBart op 23-01-2013 21:06 ]

[jacovn]

Bij mij lijkt de m1015 te warm te worden. Er zitten er 2 naast elkaar en die in het 1 e slot (van de cpu af gezien) zit met zijn koelblokje tussen de 2 kaarten in.
Ik krijg dan foutmeldingen. Dus ik heb maar een frame besteld welke ik boven de kaarten ga hangen met daarin een cooler.

[Waking_The_Dead]

Verwijderd schreef op dinsdag 22 januari 2013 @ 00:25:
[...]

Gebruik je zowel UFS als ZFS op dat systeem? Want je inactive lijkt geheugen van ZFS (wired) weg te drukken. Dat hoort normaliter niet; je wired hoort tegen 75-85% van je RAM te zitten.

Probeer verder max_pending=1. Welk OS draai je? FreeNAS of NAS4Free lijkt mij?

Ik heb nog geen upgrade gedaan maar even max_pending op 1 gezet en dat geeft dit resultaat:



1,5GB minder geheugengebruik maar totaal anders "wired" geheugenverloop. En ook nog steeds hickups bij het afspelen... Die hickups waren er trouwens al meteen, dus ook al op het moment dat geheugengebruik nog maar rond 1GB zit (niet te zien op screenshot).

Wat doet die max_pending eigenlijk?

[ Voor 8% gewijzigd door Waking_The_Dead op 23-01-2013 23:01 ]

[FireDrunk]

Die zorgt er voor dat een transaction group (een soort van IO request in ZFS) maximaal 1 aanvraag groot kan zijn.

Normaal gesproken groupeert ZFS zijn reads en writes zodat ze op volgorde gezet kunnen worden. Een soort van NCQ (Native Command Queuing). Soms wacht ZFS te lang met het toepassen van de read en als je applicatie die data meteen nodig heeft, lijkt het alsof er hickups zijn, terwijl ZFS gewoon wacht op meer IO aanvragen.

Hieraan zie je dat ZFS eigenlijk veel meer gemaakt is met grote enterprises in mind, aangezien er in een Enterprise NAS altijd wel IO is, en dit mechanisme prima werkt.

Met max_pending forceer je dus dat IO requests direct uitgevoerd worden.

[ Voor 5% gewijzigd door FireDrunk op 24-01-2013 08:00 ]

[Verwijderd]

FireDrunk schreef op donderdag 24 januari 2013 @ 08:00:
Die zorgt er voor dat een transaction group (een soort van IO request in ZFS) maximaal 1 aanvraag groot kan zijn.

Normaal gesproken groupeert ZFS zijn reads en writes zodat ze op volgorde gezet kunnen worden. Een soort van NCQ (Native Command Queuing). Soms wacht ZFS te lang met het toepassen van de read en als je applicatie die data meteen nodig heeft, lijkt het alsof er hickups zijn, terwijl ZFS gewoon wacht op meer IO aanvragen.

Hieraan zie je dat ZFS eigenlijk veel meer gemaakt is met grote enterprises in mind, aangezien er in een Enterprise NAS altijd wel IO is, en dit mechanisme prima werkt.

Met max_pending forceer je dus dat IO requests direct uitgevoerd worden.

Euh.. Weet niet hoe je aan deze wijsheid komt maar vdev_max_pending geeft alleen maar aan hoe groot je outstanding queue is en heeft niets met "wachten op meerdere IO's" te maken. Daarnaast maakt de ZIO scheduler welke IO wel of niet direct wordt uitgevoerd op basis van prioriteiten(http://src.illumos.org/so...ts/common/fs/zfs/zio.c#45) vdev_max_pending dringt over het algemeen the service tijd terug (iostat svc_t) , het kan throughput verhogen maar heeft vaak geen of negative impact op de latency.

De NCQ zit nog een laag lager (SD) en de vdev_max_pending komt daar dus boven op.

Waar ZFS wel op wacht, is op de zfs_tgx_timeout en stuurt write throttle's (delays naar de client) als de tgx 7/8 vol is tenzij je zfs_write_limit_override tweaked.

[Pantagruel]

De heren van zfsbuild.com hebben Nexenta-vs-Freenas-vs-ZFSguru vergeleken qua performance voor hun nieuwe server2012 build.

Jammer genoeg voor ZFSguru komt de getetse versie (beta 7) er niet zo goed uit .

[matty___]

Pantagruel schreef op zondag 27 januari 2013 @ 00:22:
De heren van zfsbuild.com hebben Nexenta-vs-Freenas-vs-ZFSguru vergeleken qua performance voor hun nieuwe server2012 build.

Jammer genoeg voor ZFSguru komt de getetse versie (beta 7) er niet zo goed uit .

The performance of ZFSGuru was a fraction of the performance of FreeNAS 8.3. This led us to believe that the FreeNAS team did more than simply install their web GUI on top of FreeBSD. If we had to guess, we suspect the FreeNAS team did some tweaking in the iSCSI target to boost the performance.

Was eigenlijk ook wel benieuwd naar een iobench of bonnie++ testresult

[Verwijderd]

Wel jammer dat nergens echt wordt uitgelegd hoe er wordt getest. Zo is mij niet duidelijk of ZFSguru is getest via de LiveCD bijvoorbeeld; waar ZFS is beperkt tot 64MB. Ik heb maar gelijk een reactie geplaatst onder dat artikel; dus ik ben benieuwd.

Ik kan namelijk niet verklaren waarom ZFSguru zoveel slechter scoort dan FreeNAS. Als je zulke lage scores krijgt, kan dat een hint zijn dat je iets verkeerd doet als benchmarker. Ik hoop in elk geval dat nog boven water komt hoe de test precies is uitgevoerd; dan kan ik er tenminste wat mee.

Even IOps naar MB/s omgerekend: zij komen over 1 gigabit ethernet of 20 gigabit infiniband (dat is me nog niet duidelijk) niet verder dan 12MB/s sequential read en 10MB/s sequential write op ZFSguru?

[ Voor 16% gewijzigd door Verwijderd op 27-01-2013 01:08 ]

[Compizfox]

Lijkt er inderdaad op dat er iets niet helemaal klopt.

Wel jammer trouwens dat ze ZFS via FUSE onder Linux niet hebben meegenomen.

[B2]

Verwijderd schreef op zondag 27 januari 2013 @ 00:49:
Wel jammer dat nergens echt wordt uitgelegd hoe er wordt getest. Zo is mij niet duidelijk of ZFSguru is getest via de LiveCD bijvoorbeeld; waar ZFS is beperkt tot 64MB. Ik heb maar gelijk een reactie geplaatst onder dat artikel; dus ik ben benieuwd.

Ik kan namelijk niet verklaren waarom ZFSguru zoveel slechter scoort dan FreeNAS. Als je zulke lage scores krijgt, kan dat een hint zijn dat je iets verkeerd doet als benchmarker. Ik hoop in elk geval dat nog boven water komt hoe de test precies is uitgevoerd; dan kan ik er tenminste wat mee.

Even IOps naar MB/s omgerekend: zij komen over 1 gigabit ethernet of 20 gigabit infiniband (dat is me nog niet duidelijk) niet verder dan 12MB/s sequential read en 10MB/s sequential write op ZFSguru?

Nou de reactie is wel duidelijk. Iets met lange tenen....

[Waking_The_Dead]

Nog een probleempje: ik heb net mijn laatste 2TB schijf vervangen door een 3TB schijf en mijn pool is even groot gebleven.
Oorspronkelijk had ik 4x1TB + 2x2TB in RAID-Z2; 4TB netto dus. Na verloop van tijd heb ik die 4x1TB vervangen door 4x3TB; dus 4x3TB + 2x2TB. Na het resilveren van de laatste 3TB had ik 8TB netto zonder daar iets te moeten voor doen.
Nu heb ik die 2x2TB ook vervangen door 2x3TB en had ik 12TB netto verwacht... niet dus.
Ik heb nooit expliciet partities aangemaakt dus ik zou verwachten dat mijn schijven ten volle benut worden. Iemand?

[Dadona]

B2 schreef op zondag 27 januari 2013 @ 07:08:
[...]


Nou de reactie is wel duidelijk. Iets met lange tenen....

Mja, over en weer een beetje jammer. CiPHER had het iets tactvoller kunnen vragen. De eerste zin weglaten, obviously weglaten, ... Het gaat er echt om om even te weten te komen hoe ze ZFSguru precies hebben getest.
De giftige reactie is te verwachten. Hoewel het toch jammer is dat ze daadwerkelijk ook dusdanig reageren. De boodschap op zich is prima. Ze hebben het op zich prima getest, prima uitgangspunten (geen tuning) en laten het (naar mijn mening) terecht aan de devs over om het uit te zoeken.
Vervolgstappen zouden er in inderdeed uit bestaan dat de ZFSguru kant een soortgelijke test doet. Kom je dan tot totaal verschillende resultaten dan is het interessant om eens te babbelen.
Wat ik alleen persoonlijk minder goed vind van de testers is dat je bij dit soort resultaten niet eerst even met de ontwikkelaars gaat praten. Dit is zo extreem afwijkend dat het wel netjes zou zijn om even contact op te nemen.

[FireDrunk]

CiPHER: We installed ZFSGuru to the internal boot drives. We definitely did NOT do any benchmarks using the LiveCD. We did not do any custom memory tuning with any of the storage application software packages. We assumed Nexenta, FreeNAS, and ZFSGuru would each be tuned out of the box with performance in mind.

Before you nit-pick how we ran our benchmarks, please run benchmarks against the same hardware using Nexenta, FreeNAS, and ZFSGuru.

i LOL-ed

[Pantagruel]

B2 schreef op zondag 27 januari 2013 @ 07:08:
[...]


Nou de reactie is wel duidelijk. Iets met lange tenen....

Inderdaad, ligt nogal gevoelig gezien de reactie:

"Before you nit-pick how we ran our benchmarks, please run benchmarks against the same hardware using Nexenta, FreeNAS, and ZFSGuru. "

In de sectie die beschrijft hoe ze de benchmark hebben gedaan staat niet expliciet vermeldt dat het OS op een eigen schijf staat. Aan de ene kant kun je argumenteren dat dit voor de hand ligt, aan de andere kant is het min of meer wel normaal om alles tot op t laatste puntje te omschrijven.

[ Voor 19% gewijzigd door Pantagruel op 27-01-2013 12:06 ]

[Contagion]

@waking_the_dead: je moet je pool even online brengen met de optie -e om de expandsize ook om te zetten in daadwerkelijke ruimte.

Als je nu zpool list doet, zie je dan dat de expandsize niet gelijk is aan 0? Dan is er meer ruimte in de partities om de pool te laten groeien.

Zo uit mijn hoofd kan je dat laten gebeuren met zpool online -e <tanknaam> </dev/eendeviceuitdearray>

[ Voor 47% gewijzigd door Contagion op 27-01-2013 12:13 ]

[Waking_The_Dead]

Contagion schreef op zondag 27 januari 2013 @ 12:13:
@waking_the_dead: je moet je pool even online brengen met de optie -e om de expandsize ook om te zetten in daadwerkelijke ruimte.

Als je nu zpool list doet, zie je dan dat de expandsize niet gelijk is aan 0? Dan is er meer ruimte in de partities om de pool te laten groeien.

Zo uit mijn hoofd kan je dat laten gebeuren met zpool online -e <tanknaam> </dev/eendeviceuitdearray>

Vreemd, dat heb ik niet gedaan toen ik van 4 naar 8TB ging.
Bovendien zegt zpool list helemaal niets over expandsize en is -e een ongekende optie op de versie die ik draai. Misschien moet ik toch maar eerst even naar de laatste versie van FreeNAS gaan.

[Verwijderd]

zpool online -e <pool> <device>

code:

     zpool online [-e] pool device ...

         Brings the specified physical device online.

         This command is not applicable to spares or cache devices.

         -e      Expand the device to use all available space. If the device
                 is part of a mirror or raidz then all devices must be
                 expanded before the new space will become available to the
                 pool.

[Waking_The_Dead]

Verwijderd schreef op zondag 27 januari 2013 @ 16:01:
zpool online -e <pool> <device>

code:

     zpool online [-e] pool device ...

         Brings the specified physical device online.

         This command is not applicable to spares or cache devices.

         -e      Expand the device to use all available space. If the device
                 is part of a mirror or raidz then all devices must be
                 expanded before the new space will become available to the
                 pool.

code:

[root@movieserver] ~# zpool online -e movieserver ada5
invalid option 'e'
usage:
        online <pool> <device> ...

Oudere versie vermoed ik...

[Verwijderd]

Wat draai je dan precies? uname -a ?

Want dan heb je inderdaad een oudere ZFS versie?!

[Waking_The_Dead]

Verwijderd schreef op zondag 27 januari 2013 @ 22:45:
Wat draai je dan precies? uname -a ?

Want dan heb je inderdaad een oudere ZFS versie?!

Ik draaide FreeNAS 8.0.3 maar heb ondertussen een upgrade naar 8.3.0 gedaan.
Na de upgrade stond de disk die ik gisteren heb toegevoegd als unavailable. Ondertussen is die opnieuw aan het resilveren dus dat wordt 14 uur wachten...

[Contagion]

Hmm, volgens mij is het wel zo dat alle disks aanwezig moeten zijn voor dat je kan expanden. Stel dat je een 5disk array hebt waarvan 4x3TB en 1x1TB, dan moet de array dus max 5x1TB groot zijn. Als je de 1TB offline haalt (door error of hoe dan ook) dan kan je niet ineens expanden naar 5x3TB want ZFS weet niet anders dan dat die laatste drive niet groter was dan 1 TB.

Na het resilveren zal het wel ok zijn. Overigens helpt het bij mij enorm om tijdens resilveren zfs_top_maxinflight te verhogen. Bij mij gaat resilveren dan van 200-250MB/sec naar 650MB/sec.

[Waking_The_Dead]

Contagion schreef op maandag 28 januari 2013 @ 09:55:
Hmm, volgens mij is het wel zo dat alle disks aanwezig moeten zijn voor dat je kan expanden. Stel dat je een 5disk array hebt waarvan 4x3TB en 1x1TB, dan moet de array dus max 5x1TB groot zijn. Als je de 1TB offline haalt (door error of hoe dan ook) dan kan je niet ineens expanden naar 5x3TB want ZFS weet niet anders dan dat die laatste drive niet groter was dan 1 TB.

Na het resilveren zal het wel ok zijn. Overigens helpt het bij mij enorm om tijdens resilveren zfs_top_maxinflight te verhogen. Bij mij gaat resilveren dan van 200-250MB/sec naar 650MB/sec.

Alle 3TB drives waren online hoor maar toch had ik maar 8TB ('t is te zeggen, eerder 7TiB in de praktijk).
Nadien ben ik van FreeNAS 8.0.3 naar 8.3.0 gegaan en toen was de laatst toegevoegde disk weer unavailable.
Ondertussen zou het (opnieuw) resilveren gedaan moeten zijn maar ik kan van hier uit niet aan mijn server. (ik heb wel een Web Console package draaien op mijn Synology - waar ik wel aan kan - maar ssh naar mijn ZFS server lukt niet met die package).

[FireDrunk]

Je zou (maar dat is misschien gevaarlijk) eens de ZFSGuru live cd kunnen booten, en kijken of het daarmee kan? Als dat werkt en je boot terug naar FreeNAS kan hij zeer waarschijnlijk je oude array gewoon weer openen.

Het zal een versie verschil zijn denk ik.

[Contagion]

Of met een Ubuntu livecd en dan daarmee 'growen'. Maar als je 'expandsize' niet een paar TB is, dan is er ook niks te growen. Heb je je onderliggende partities wel groter gemaakt?

[Waking_The_Dead]

Ik heb dezelfde procedure gevolgd als toen ik van 4TB naar 8TB ging en daar moest ik helemaal niets speciaals voor doen. Maar ik wacht eerst af wat die laatste resilver heeft opgeleverd. Ondertussen zit ik met de laatste FreeNAS ook op v28 van ZFS dus hopelijk zijn daar al mijn problemen mee opgelost.

[Compizfox]

Contagion schreef op maandag 28 januari 2013 @ 10:38:
Of met een Ubuntu livecd en dan daarmee 'growen'. Maar als je 'expandsize' niet een paar TB is, dan is er ook niks te growen. Heb je je onderliggende partities wel groter gemaakt?

Ik denk niet dat Ubuntu het ZFS-filesystem 'snapt'

[FireDrunk]

Met ZFSonLinux wel, maar dat zit niet in de livecd volgens mij...

[Contagion]

Nee dat zit niet in de livecd, maar je kan wel de PPA toevoegen (links staan op https://launchpad.net/~zfs-native/+archive/stable) en dan apt-get update; apt-get install ubuntu-zfs.

Meer is er niet nodig om ZFS in Ubuntu aan de gang te krijgen.

[Waking_The_Dead]

Het resilveren is gedaan, mijn pool is weer healthy en ik zit effectief op ZFS v28.

zpool online -e heeft niets uigehaald. Niet voor alle disks apart, niet voor alle disks samen.
Of moet ik de disks een voor een offline halen hiervoor?

Wat ik nog niet geprobeerd heb is eerst een export te doen van mijn pool en vervolgens een import. Dat ga ik vanavond maar eens proberen.

[Contagion]

Wat zegt zpool list over de expandsize?

Edit: je hoeft geen disks offline te halen, maar wel opnieuw online brengen (ook al staat ie dus al in de array). Voorbeeld zoals hierboven: zpool online -e zpoolnaam /dev/eendevicenaam

En had je ook gecheckt of de partities waaruit de array bestaat ook groter zijn dan in de oude array? Of gebruik je ruwe disks?

[ Voor 80% gewijzigd door Contagion op 28-01-2013 16:04 ]

[Waking_The_Dead]

Helemaal niets. Er verschijnt geen expandzie info wanneer ik zpool list ingeef. Of ik moet er serieus overgekeken hebben.

[Contagion]

Hmm, of was het zfs list waar die info in stond ipv zpool list. Dacht het niet omdat het echt over de pool gaat. Oh wacht, het kan ook wel zpool get all <poolname> zijn.

[DrFlash]

Volgens mij moet je de option autoexpand=on aan hebben staan. deze is op te halen met

zpool get all <pool>

eventueel aanzetten als hij uit staat met:

zpool set autoexpand=on <pool>

daarna de pool offline/online brengen, of je server even rebooten en de pool zou gegroeid moeten zijn.

[Contagion]

Jep het is inderdaad zpool get all <poolname>. Bij mij was autoexpand aanzetten niet voldoende, ik moest ook echt een device in de pool online brengen, maar dat was onder ZFS-for-linux.

[Waking_The_Dead]

Contagion schreef op maandag 28 januari 2013 @ 16:02:
Wat zegt zpool list over de expandsize?

Edit: je hoeft geen disks offline te halen, maar wel opnieuw online brengen (ook al staat ie dus al in de array). Voorbeeld zoals hierboven: zpool online -e zpoolnaam /dev/eendevicenaam

En had je ook gecheckt of de partities waaruit de array bestaat ook groter zijn dan in de oude array? Of gebruik je ruwe disks?

Ik gebruik ruwe disks.

Ondertussen heb ik die autoexpand aan staan, heb ik nog eens alle disks opnieuw online gebracht met -e, een export en import gedaan, server herstart en nog niets...

Moet ik misschien een voor een de schijven offline brengen en dan met -e terug online brengen en resilveren? Dat gaat even duren...

[Contagion]

Vreemd; resilveren is echt niet nodig als alle drives daar zijn. Kan je de output geven van

zpool status
zpool get expandsize <poolnaam>
zfs list

En weet je zeker dat je ruwe disks gebruikt? In het geval van ZFSonLiunx heb je nog wel eens dat je een ruwe disk opgeeft maar dat hij toch partities aanmaakt (hoewel die dan wel de max size van de disk zijn dus dan zou het toch niet fout moeten gaan).

Voordat ik mijn 13disk array ge-onlined had met -e was mijn expandsize niet 0 en nu wel:

#zpool get expandsize Storage
NAME PROPERTY VALUE SOURCE
Storage expandsize 0 -

[ Voor 5% gewijzigd door Contagion op 28-01-2013 21:55 ]

[Waking_The_Dead]

Ik ben net met een scrub bezig...

code:

[root@movieserver] ~# zpool status
  pool: movieserver
 state: ONLINE
  scan: scrub in progress since Mon Jan 28 20:12:15 2013
        1.62T scanned out of 9.87T at 267M/s, 8h59m to go
        0 repaired, 16.42% done
config:

        NAME                                            STATE     READ WRITE CKSUM
        movieserver                                     ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/5833e197-9202-4e70-b2d5-a2f9a0bb6db2  ONLINE       0     0     0
            gptid/519ac74b-fbac-4a43-8d89-0893c0a56306  ONLINE       0     0     0
            ada2                                        ONLINE       0     0     0
            ada3                                        ONLINE       0     0     0
            ada4                                        ONLINE       0     0     0
            gptid/1ce68a8d-68d1-11e2-8d2b-f46d04d895d9  ONLINE       0     0     0

errors: No known data errors

"expandsize" vindt ie niet...

code:

[root@movieserver] ~# zpool get expandsize movieserver
bad property list: invalid property 'expandsize'

code:

[root@movieserver] ~# zfs list
NAME          USED  AVAIL  REFER  MOUNTPOINT
movieserver  6.57T   403G  6.57T  /mnt/movieserver

[Verwijderd]

Had je dit al gedaan?
zpool get autoexpand movieserver
zpool set autoexpand=on movieserver

[Waking_The_Dead]

Ja hoor:

code:

[root@movieserver] ~# zpool get autoexpand movieserver
NAME         PROPERTY    VALUE   SOURCE
movieserver  autoexpand  on      local

[Verwijderd]

Probeer exporteren en importeren. Rebooten had je al geprobeerd neem ik aan?
Anders boot even met ZFSguru livecd ofzo, en doe het daar in. Dan weer exporteren en terug naar FreeNAS 8.x.

[ Voor 42% gewijzigd door Verwijderd op 28-01-2013 22:17 ]

[Waking_The_Dead]

Export en import heb ik al geprobeerd. Rebooten ook...

Als ik nu 1 device offline breng en dan weer online, gaat ie dan sowieso resilveren?
Anders maak ik van de gelegenheid gebruik om de disks 1 voor 1 offline te halen en ondertussen een label toe te kennen...

Als het echt niet anders kan, heb ik nog schijven genoeg liggen om al mijn data te backuppen en from scratch te beginnen, Maar liever niet eigenlijk :-)

Verwijderd schreef op maandag 28 januari 2013 @ 22:17:
Anders boot even met ZFSguru livecd ofzo, en doe het daar in. Dan weer exporteren en terug naar FreeNAS 8.x.

Is dat dan fysiek een CD? Want dat zal niet lukken aangezien er geen CD lezer in mijn NAS zit. Via USB moet het wel lukken neem ik aan...

Contagion schreef op maandag 28 januari 2013 @ 21:55:
En weet je zeker dat je ruwe disks gebruikt? In het geval van ZFSonLiunx heb je nog wel eens dat je een ruwe disk opgeeft maar dat hij toch partities aanmaakt (hoewel die dan wel de max size van de disk zijn dus dan zou het toch niet fout moeten gaan).

Ik neem aan van wel. Behalve de oude disk er uit halen, fysiek vervangen door de nieuwe en dan zpool offline en zpool replace heb ik helemaal niets gedaan. Geen partities ingesteld ofzo... In elk geval ziet ie wel dat het 3TB schijven zijn:

code:

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <ST3000DM001-9YN166 CC4H> ATA-8 SATA 3.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)

ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
ada1: <ST3000DM001-9YN166 CC4H> ATA-8 SATA 3.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)

ada2 at ahcich2 bus 0 scbus2 target 0 lun 0
ada2: <ST3000DM001-1CH166 CC24> ATA-8 SATA 3.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada2: Command Queueing enabled
ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)

ada3 at ahcich3 bus 0 scbus3 target 0 lun 0
ada3: <ST3000DM001-1CH166 CC43> ATA-8 SATA 3.x device
ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada3: Command Queueing enabled
ada3: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)

ada4 at ahcich4 bus 0 scbus4 target 0 lun 0
ada4: <ST3000DM001-1CH166 CC24> ATA-8 SATA 3.x device
ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada4: Command Queueing enabled
ada4: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)

ada5 at ahcich5 bus 0 scbus5 target 0 lun 0
ada5: <ST3000DM001-1CH166 CC43> ATA-8 SATA 3.x device
ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada5: Command Queueing enabled
ada5: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)

[ Voor 108% gewijzigd door Waking_The_Dead op 28-01-2013 22:49 ]

[TiZu]

Na een tijdje dit topic te volgen ben ik van plan ZFS te gaan gebruiken. Ik heb alleen wat twijfels welke hardeschijven ik het best op moment kan aanschaffen. Ik zou graag Raidz gaan willen draaien. Geld speelt jammer genoeg wel een rol dus ik heb voor mezelf nu twee mogelijkheden. Ik heb al 2 WD20EARX schijven liggen.

Mogelijkheid 1:
3 WD20EARX erbij kopen en dan 5 disk raidz draaien

Mogelijkheid 2:
De 2 WD20EARX verkopen en 3x een Seagate barracuda kopen. En dan 3 Disk Raidz draaien.

Ik neig zelf toch naar de barracuda's alleen ik mis toch een beetje informatie welke van de 2 mogelijkheden het beste passen samen met ZFS.

[Contagion]

Ik weet niet hoe het met BSD zit maar ik zie zowel 'ada' devices (een hele disk?) als gptid devices (partities?). Ik zou toch even checken of er niet toevallig partities op die disks aanwezig zijn en indien ze er wel zijn, deze vergroten.

[timofp]

Ik vond het heel interessant om dit topic te lezen, en ga ook in de toekomst iets met ZFS opzetten denk ik, maar heb momenteel geen behoefte aan RAID of ZFS omwille van de overhead die er toch altijd bij komt kijken (ik bedoel dat je meer TB's moet kopen dan dat je netto overhoud).

Wat me het meest verbaasde is het stukje over bad sectors. Eigenlijk toch ongelooflijk dat RAID wat altijd zo opgehemeld wordt geen gebruik maakt van de aanwezige redundantie bij het vinden van een bad sector, terwijl ZFS aantoont dat dit perfect mogelijk is. Ik vind het zo iets logisch dat ik verbaasd was dat RAID dit niet deed.

[Waking_The_Dead]

Contagion schreef op dinsdag 29 januari 2013 @ 00:40:
Ik weet niet hoe het met BSD zit maar ik zie zowel 'ada' devices (een hele disk?) als gptid devices (partities?). Ik zou toch even checken of er niet toevallig partities op die disks aanwezig zijn en indien ze er wel zijn, deze vergroten.

En hoe doe ik dat precies?
Op FreeNAS 8.0.x werden alle disks als ada devices getoond. Het is pas na mijn upgrade naar 8.3.0 dat er nu plots 3 gptid devices tussen zitten....

Edit: of nee, wacht. Ik geloof dat die eerste twee als ada0p1 ofzo getoond werden. Aan die naam te zien zal dat dan toch een partitie geweest zijn zeker? Maar ik heb nooit expliciet partities aangemaakt op die schijven...

[ Voor 17% gewijzigd door Waking_The_Dead op 29-01-2013 09:23 ]

[Contagion]

Ik weet niet hoe je dat met BSD doet of waarmee je partities bekijkt. Ik vermoed wel dat het hem daarin zit en dat ergens een onderliggend device nog niet groter is (bijv ergens is nog een 1 TB partities waardoor er niks te expanden valt). Als je een xubuntu livecdtje maakt (laatste versie) dan kan ik je wel op weg helpen met ZFS on Linux (mits de poolversie niet te nieuw is. De pool kan je daarna gewoon weer in een ander OS gebruiken).

Bij offline en online halen zou je niet hoeven te resilveren. ZFS weer prima of er nog transacties zijn geweest die niet in sync zijn met een device wat even weg is geweest en lost dit zelf op.

[DrFlash]

Waking_The_Dead schreef op dinsdag 29 januari 2013 @ 09:17:
[...]


En hoe doe ik dat precies?
Op FreeNAS 8.0.x werden alle disks als ada devices getoond. Het is pas na mijn upgrade naar 8.3.0 dat er nu plots 3 gptid devices tussen zitten....

Edit: of nee, wacht. Ik geloof dat die eerste twee als ada0p1 ofzo getoond werden. Aan die naam te zien zal dat dan toch een partitie geweest zijn zeker? Maar ik heb nooit expliciet partities aangemaakt op die schijven...

Freenas 8.x maakt op een NIEUWE schijf (nieuw als in niet eerder gebruikt als zfs disk) altijd 2 partities aan. 1 partitie van 2GB voor swap, en 1 partitie van 'de rest' als ZFS disk. je adaXp0 is je swap partitie, adaXp1 je ZFS schijf. Wat gebeurt kan zijn is dat je de schijven die niet als gptid er tussen staan al eerder als ZFS schijven heb gebruikt op een andere filer.

Normaal gesproken als alles goed is zou het er ongeveer zo uit moeten zien:
* mijn systeem gebruikt raid-z over 3 disken, en dit 2x *

code:

[root@flr01] ~# zpool status
  pool: pool
 state: ONLINE
  scan: scrub repaired 0 in 0h2m with 0 errors on Mon Jan 28 16:47:12 2013
config:

        NAME                                            STATE     READ WRITE CKSUM
        pool                                            ONLINE       0     0     0
          raidz1-0                                      ONLINE       0     0     0
            gptid/86b4e4cf-470b-11e2-8651-001b21cafb55  ONLINE       0     0     0
            gptid/8792ea3f-470b-11e2-8651-001b21cafb55  ONLINE       0     0     0
            gptid/8857ceb2-470b-11e2-8651-001b21cafb55  ONLINE       0     0     0
          raidz1-1                                      ONLINE       0     0     0
            gptid/0d07fc74-59c4-11e2-8b56-3085a9a650d7  ONLINE       0     0     0
            gptid/0e9a3a85-59c0-11e2-ba2b-3085a9a650d7  ONLINE       0     0     0
            gptid/0f1a482c-59c0-11e2-ba2b-3085a9a650d7  ONLINE       0     0     0

errors: No known data errors

*edit. met "gpart" kan je info over je schijven zien. "gpart show" laat de partities zien, dit is 1 van mijn disken.

code:

[root@flr01] ~# gpart show
=>        34  3907029101  ada0  GPT  (1.8T)
          34          94        - free -  (47k)
         128     4194304     1  freebsd-swap  (2.0G)
     4194432  3902834696     2  freebsd-zfs  (1.8T)
  3907029128           7        - free -  (3.5k)
--snip--

[ Voor 9% gewijzigd door DrFlash op 29-01-2013 10:28 ]

[Waking_The_Dead]

DrFlash schreef op dinsdag 29 januari 2013 @ 10:23:
[...]


Freenas 8.x maakt op een NIEUWE schijf (nieuw als in niet eerder gebruikt als zfs disk) altijd 2 partities aan. 1 partitie van 2GB voor swap, en 1 partitie van 'de rest' als ZFS disk. je adaXp0 is je swap partitie, adaXp1 je ZFS schijf. Wat gebeurt kan zijn is dat je de schijven die niet als gptid er tussen staan al eerder als ZFS schijven heb gebruikt op een andere filer.

Vreemd. Want al deze schijven waren nieuw en hebben nooit in een ander ZFS systeem gehangen.

Wat ik wel als enige verschil kan opmerken, is dit: vorige week heb ik ada3 toegevoegd maar die heb ik wel eerst aan mijn Windows systeem gehangen om te testen; daar stonden dus wel NTFS partities op. Die onderste gptid schijf heb ik rechtstreeks aan mijn ZFS systeem gehangen. Mogelijks heb ik ada2 en ada4 ook eerst aan mijn Windows bak gehangen maar dat kan ik niet meer met zekerheid zeggen.

[DrFlash]

Je kan het overigens "repareren" als je met de hand aan de slag gaat met 'dd' (om op te schonen) en gpart als je het vervelend vind hoe het er nu uit ziet.

[Waking_The_Dead]

Allright. Dat ga ik dan straks maar even uitproberen.

Aangezien mijn huidige configuratie een beetje een soep aan het worden is, had ik gedacht om dan toch maar met al mijn disks 1 voor 1 het volgende te doen (tenzij dat allemaal kan met dd en gpart op een snellere manier):

• offline halen
• op een goede manier partitioneren
• label toekennen
• online plaatsen
• resilveren

Daar zal ik wel een paar dagen mee zoet zijn vermoed ik maar hopelijk heb ik dan op het einde van de rit alle ruimte beschikbaar.

Als ik manueel partities ga toekennen, moet ik dan ook rekening houden met die swap space? En zo ja, hoe laat ik mijn systeem dan weten welke partitie er voor swap gebruikt moet worden?

[ Voor 4% gewijzigd door Waking_The_Dead op 29-01-2013 11:08 ]

[Contagion]

Als je dd gaat gebruiken ben je inderdaad nog wel een tijd bezig omdat ZFS en GPT partities (als je die inderdaad hebt) slim genoeg zijn om op de disk te gaan zoeken naar informatie over de indeling. Als je niet alles wist, vindt hij waarschijnlijk het een en ander en schiet je er niks mee op.

Ik zou er zelf overigens niet voor kiezen om de drives ook als swap te gebruiken. Als je de drives wilt laten spin-downen omdat het ZFS deel niet wordt gebruikt dan gebeurt dat niet omdat er soms een en ander naar de swap geschreven wordt. Mijn indeling zou zijn: een GPT partitie (liefst met naam) van de hele disk, maar wel aligned vanwege 4 KB sectoren. Overigens; je hebt nu 3 TB drives dus je MOET GPT partities gebruiken, is je array wel optimized voor 4 KB sectoren (het ashift=12 verhaal). Anders kan je overwegen om de array helemaal vanaf scratch te creëren.

[Waking_The_Dead]

ashift staat op 12, ja. Gelukkig maar :-)

[FireDrunk]

Als je eerst disks en nu partities gaat gebruiken, kom je dan niet in de knoei met het feit dat de partities kleiner zijn dan de disks?

[DrFlash]

Hmm m'n laatste reactie is zo te zien weg gevallen. het dd commando is vrij simpel en snel te gebruiken om je schijven te schonen. je moet alleen het eerste en laatste block van de gpt disk weggooien om em "leeg" te maken. zie hier hoe:

https://github.com/ProtoS...agnosing-&-Managing-Disks

de stappen die ik in mijn geval zou doen (en ooit heb gedaan)

1. disk offline
2. disk "schonen" met dd
3. Freenas de disk laten initialiseren (swap en data partitie worden aangemaakt)
4. de 'offline' partitie 'replacen' met de nieuw geinitialiseerde disk. Dat zou dus adaXp1 moeten zijn, waarbij X het schijfnummer is.
5. systeem laten uitrazen (resilveren)
6. verder bij stap 1. totdat alle 'foute' schijven eruit zijn.

[ Voor 37% gewijzigd door DrFlash op 29-01-2013 12:20 ]

[Contagion]

@firedrunk. Zo lang de expandsize niet gebruikt is en er dus nog ergens een 1 TB partities 'het bewind' uitmaakt zou het nog geen probleem moeten zijn.

In mijn geval heb ik de partities wel iets kleiner gemaakt dan het totaal aantal sectoren (- 2048 ivm alignment) omdat je niet weet of elke 3 TB disk precies zo groot is als een andere (merk/typeverschillen). Als je ooit een vervangende 3 TB koopt die net een paar sectoren kleiner is, dan hang je inderdaad.

@DrFlash. Kan stap 3 niet zonder swap?

[ Voor 4% gewijzigd door Contagion op 29-01-2013 12:58 ]

[Waking_The_Dead]

Probleem gevonden; met dank aan iedereen die mij de afgelopen dagen geholpen heeft.

Ik had dus inderdaad 3 raw disks en 3 partities. De disk die onder FreeNAS 8.3.0 is toegevoegd, had ook een opdeling zoals die van DrFlash in een paar posts hierboven (1 freebsd-swap en 1 freebsd-zfs partitie). De disk op ada0 had 1 linux-zfs partitie en die op ada1 had 2 linux-zfs partities: eentje van 2 en eentje van 1 TB... Probleem gevonden dus.
Alleen heb ik geen flauw idee hoe die partities op ada0 en ada1 gekomen zijn.

Enfin. Ik heb ada0 offline gehaald, de partitie gewist, een nieuwe aangemaakt gebruik makend van een label en ondertussen is die aan het resilveren. Ik gok dat ik op die manier tegen het weekend weer een healthy NAS heb met 12TiB en 6 disk labels.

[DrFlash]

Contagion schreef op dinsdag 29 januari 2013 @ 12:56:
@DrFlash. Kan stap 3 niet zonder swap?

In theorie wel, in de praktijk is die swap wel ergens goed voor (anders zou freenas em ook niet aanmaken)

aan het eind van de rit is 2gb op 2 of 3 TB schijven natuurlijk niet zoveel. Daarnaast hou ik me liever aan de 'standaard' die distro bouwers in gedachte hebben gewoon om problemen voor te zijn. Uiteraard is verder iedereen daar vrij in.

[wjn]

Pantagruel schreef op zondag 27 januari 2013 @ 00:22:
De heren van zfsbuild.com hebben Nexenta-vs-Freenas-vs-ZFSguru vergeleken qua performance voor hun nieuwe server2012 build.

Jammer genoeg voor ZFSguru komt de getetse versie (beta 7) er niet zo goed uit .

Ik ben juist in 2012 van Nexenta naar ZFSguru overgestapt omdat die laatste een procent of 10 beter performde, draai toevallig ook beta 7. Mijn benchmarks bestonden uit kopieren van grote bestanden (100MB en groter), het is puur de backup-server. Freenas was indertijd (ca. 2 jaar geleden) nog wat trager dan Nexenta.
Wb. iscsi kan ik geen goede uitspraken doen, gebruik het puur als noodoplossing omdat ik zo Windows Server een "interne" schijf kan laten zien voor backup en moet nog een keer investeren in een separate switch. (Wat dus niet zo belangrijk is, want de backup draait toch 's nachts en dan wordt het netwerk verder niet belast.)

[webbier]

Na 6 weken lang wachten op mijn geheugen pricewatch unsorted: Crucial Ballistix Sport - Geheugen - 16 GB : 2 x 8 GB - DIMM 240-pins eindelijk ook mijn NAS compleet:

#	Product	Prijs	Subtotaal
1	Asus E35M1-I	€ 0,-	€ 0,-
6	Samsung Spinpoint F4 EG HD204UI, 2TB	€ 0,-	€ 0,-
1	Lian Li PC-Q08 Zwart	€ 88,90	€ 88,90
1	IBM ServeRAID M1015 SAS/SATA Controller for System x	€ 114,99	€ 114,99
1	Mini-box picoPSU 120 + 80W Adapter Power Kit	€ 65,40	€ 65,40
1	Intel 320 120GB	€ 160,55	€ 160,55
Bekijk collectie Importeer producten		Totaal	€ 429,84

Ik had eerst wat problemen om mijn M1015 te flashen op dit bordje, aangezien ik geen ander bord ter beschikking had. Uiteindelijk een oplossing gevonden op het forum van servethehome. Het is de 3e post op deze pagina, http://forums.servethehom...M-M1015-Experiences/page5, misschien heeft iemand er nog wat aan.

Ik heb ook nog even het verbruik gemeten, behold:

Kaal systeem (ssd + geheugen):
start-up: 22.9 W
idle: 16.7 W

Iets minder kaal systeem (ssd + geheugen + 2 ventilatoren + IBM M1015):
start-up: 29.3 W
idle: 25.3 W

Compleet systeem:
start-up: 60 W (met een piek van 114 W als de disks opspinnen)
idle: 58.7 W
load: 65.2 W
idle met spindown (na 30 minuten via spindown port): 30 W

Gemeten met een Voltcraft energy monitor 3000.

Redelijk tevreden met het idle verbruik, aangezien dat de meest voorkomende staat is. Iemand nog tips om het eventueel nog verder terug te dringen?