Het grote ZFS topic

[Durandal]

FireDrunk schreef op donderdag 16 april 2015 @ 21:46:
[...]

Die symlinks komen omdat je wel gpt gebruikt maar je disks allemaal hetzelfde label hebben. In mijn ogen niet aan te raden, maar by-id werkt idd wel.

Hmm.. Ik heb, afgezien van een externe backup disk, nog nooit een label gezet. Is meer iets voor Windows geloof ik. Nooit geweten dat dat via een symlink systeem werkte. Weer wat geleerd.
Wat moet er dan in die labels staan? Serie nummer?

[ikkeenjij36]

Met enige hulp en advies van CIPHER draait het nu netjes op mijn ssd.
CIPHER bedankt weer voor de hulp.

[FireDrunk]

Durandal schreef op donderdag 16 april 2015 @ 22:02:
[...]

Hmm.. Ik heb, afgezien van een externe backup disk, nog nooit een label gezet. Is meer iets voor Windows geloof ik. Nooit geweten dat dat via een symlink systeem werkte. Weer wat geleerd.
Wat moet er dan in die labels staan? Serie nummer?

Windows maakt wel wat labels aan, maar niet super spannend. Juist onder linux (en bsd) heb je 100% controle over de labels.

Groot nadeel (vind ik persoonlijk) van linux is dat by-design standaard bij een aantal disk partition tools een aangemaakte partitie een label geven met het type partitie. Vandaar dat je maar een symlink hebt. Er zijn waarschijnlijk meerdere disks met hetzelfde label, en in dat geval 'wint' de laatste disk die online komt.

Je kan volgens mij zonder verlies van data met gparted je labels wijzigen.
Als je daarna een zpool export en weer een import -d doet zie je je disks netjes via disk labels.

[thibautb]

GioStyle schreef op donderdag 16 april 2015 @ 21:21:
[...]


Kortgezegd: nee.

Wat je eigenlijk doet is je maakt een pool aan dat uit 1 vdev bestaat. In jouw voorbeeld dus 5x 4TB raidz1. Vervolgens wil je uitbreiden met nog eens 5x 4TB raidz1. Dat wordt dan nog een vdev die je vervolgens aan je pool toevoegt.

Dan heb je uiteindelijk een pool die uit 2 vdev's bestaat. En elk vdev bestaat uit 5x 4TB raidz1.

Dat is niet veiliger dan pool die bestaat uit 1 vdev van 10x 4TB raidz2.

Eigenlijk is dat dan een soort raidz0 dan?

[FireDrunk]

Eerder RAID 50

[jacovn]

Als je meerder vdevs onder 1 pool hebt en een vdev gaat ofline (als in raid-z1 met 2 disk failures) is je hele pool down..

[jacovn]

ikkeenjij36 schreef op vrijdag 17 april 2015 @ 00:49:
Met enige hulp en advies van CIPHER draait het nu netjes op mijn ssd.
CIPHER bedankt weer voor de hulp.

Wat was het probleem ?
Wellicht kunnen anderen er ook van leren.

[Durandal]

FireDrunk schreef op vrijdag 17 april 2015 @ 07:24:
[...]
Je kan volgens mij zonder verlies van data met gparted je labels wijzigen.
Als je daarna een zpool export en weer een import -d doet zie je je disks netjes via disk labels.

Dank je, ga ik proberen.

[FireDrunk]

Test het wel ff, ik durf er geen geld op in te zetten dat het zonder data verlies kan.

[ikkeenjij36]

jacovn schreef op vrijdag 17 april 2015 @ 09:08:
[...]

Wat was het probleem ?
Wellicht kunnen anderen er ook van leren.

Verkeerde instelling met de pool aanmaken.
v5000 instellen werkt niet als ik hem gewoon op 28 hou staan is er niks aan de hand en razendsnel.

[CurlyMo]

Ook dat is je al tenminste twee keer eerder verteld:

Anoniem: 15758 schreef op zaterdag 25 januari 2014 @ 19:32:
ikkeenjij, heb je de bootcode al gecontroleerd van al je disks? Je draait beta9? Via DM mag ook.

Bootcode updaten: Disks pagina. Klik op een disk, klik op rode boot partitie, klik op knop Update bootcode. Doe dat voor alle disks. Nu kun je booten van v5000.

FireDrunk schreef op zaterdag 25 januari 2014 @ 11:48:
@Ikkeenjij36 en EnergQi, Waarschijnlijk is jullie bootcode niet geupdate naar de versie van gptzfsboot die van v5000 kan booten. Je kan proberen met een live cd te booten, de freebsd-boot partitie verwijderen, en opnieuw aan te maken. Volgens mij schrijft ZFSguru dan een nieuwe gptzfsboot weg. Probleem is alleen, hoe kom je aan die nieuwe gptzfsboot, met een oude ZFSguru livecd....

Overigens weet ik dit allemaal niet zeker, dus vraag zeker CiPHER om bevestiging...

[FREAKJAM]

vier keer.

ikkeenjij36 schreef op dinsdag 13 mei 2014 @ 19:07:
[...]

Ja idd .
Heb dit natuurlijk al eerder aan de hand gehad.
Wat stom van mij,maar misschien makkelijk voor nieuwe gebruikers die dit ook meemaken,ik heb nu alles schijven per stuk een update system bootcode gedaan,eens kijken of tie nu op wil starten zonder live cd.

EDIT:HELAAS ik krijg nu een rondraaiend streepje met een streepje eronder,wat heb ik nu weer fout gedaan
?

Mm de pols staan nog steeds op spa 28,ik neem aan dat dat de versie is?
Moet ik nu gewoon de pool updaten naar v33 of niet?

Anoniem: 15758 schreef op dinsdag 10 juni 2014 @ 16:22:
@ImmortalSoul: update naar beta9

@ikkeenjij36: dat probleem had je omdat je van 11.x naar 10.1 bent gegaan; 11.x ondersteunt ZFS features die andere versies niet ondersteunen. Je bootcode hoort altijd up to date te zijn, tenzij je beta8 of ouder hebt gebruikt. De SSD dien je te formatteren en in partities op te delen (dus niet één grote partitie!) en daarna maak je een pool aan op de systeem/boot partitie en daar kun je ZFSguru op installeren.

[ Voor 28% gewijzigd door FREAKJAM op 17-04-2015 11:08 ]

[jacovn]

De zfsguru gui installatie is op dat punt niet de meest duidelijke denk ik.
Je wordt netjes door installatie proces geleid, maar dan is de boot ssd 1 partitie van de hele disk.
Als je dan denkt ik wil alle nieuwste features kies je v5000 en dan kom je dus waar ikkeenjij36 was denk ik.
Als je met de hand de hdd partitioneert, en dan een boot partitie maakt en die aanwijst gaat het wel goed (en je geen v5000 kiest)

Waarom zou je v5000 op je boot pool nodig hebben ? lZ4 compressie ?

[jbhc]

Sinds een tijdje heb ik ZFSGuru draaien als vervanger voor mijn linux raid1 thuis server. Dit omdat ik nu al 2x last heb gehad van een falende raid wegens overlijdende schijven.

Vandaag ben ik eens een scrub gaan doen maar nu blijkt 1 van de HD's (wederom) defect.

Iemand een idee wat ik nu het beste kan doen?
De scrub door laten gaan of het systeem uitzetten.

De pool is via de webinterface ook niet meer te bekijken. ik zie allen dit in de logs:

code:

(ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 00 d8 af 39 40 11 00 00 01 00 00
(ada1:ahcich1:0:0:0): CAM status: ATA Status Error
(ada1:ahcich1:0:0:0): ATA status: 41 (DRDY ERR), error: 40 (UNC )
(ada1:ahcich1:0:0:0): RES: 41 40 80 b0 39 40 11 00 00 00 00
(ada1:ahcich1:0:0:0): Retrying command
(ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 00 d8 af 39 40 11 00 00 01 00 00
(ada1:ahcich1:0:0:0): CAM status: ATA Status Error
(ada1:ahcich1:0:0:0): ATA status: 41 (DRDY ERR), error: 40 (UNC )
(ada1:ahcich1:0:0:0): RES: 41 40 80 b0 39 40 11 00 00 00 00
(ada1:ahcich1:0:0:0): Retrying command
(ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 00 d8 af 39 40 11 00 00 01 00 00
(ada1:ahcich1:0:0:0): CAM status: ATA Status Error
(ada1:ahcich1:0:0:0): ATA status: 41 (DRDY ERR), error: 40 (UNC )
(ada1:ahcich1:0:0:0): RES: 41 40 80 b0 39 40 11 00 00 00 00
(ada1:ahcich1:0:0:0): Error 5, Retries exhausted
(ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 00 e0 bc 39 40 11 00 00 01 00 00
(ada1:ahcich1:0:0:0): CAM status: ATA Status Error
(ada1:ahcich1:0:0:0): ATA status: 41 (DRDY ERR), error: 40 (UNC )
(ada1:ahcich1:0:0:0): RES: 41 40 18 bd 39 40 11 00 00 00 00
(ada1:ahcich1:0:0:0): Retrying command

En dit haal ik uit de smart van de desbetreffende disk:

code:

1   Raw_Read_Error_Rate     0x002f  178     178     051     -   1660
3   Spin_Up_Time    0x0027  136     136     021     -   4191
4   Start_Stop_Count    0x0032  100     100     000     -   20
5   Reallocated_Sector_Ct   0x0033  198     198     140     -   124
7   Seek_Error_Rate     0x002e  200     200     000     -   0
9   Power_On_Hours  0x0032  100     100     000     -   90
10  Spin_Retry_Count    0x0032  100     253     000     -   0
11  Calibration_Retry_Count     0x0032  100     253     000     -   0
12  Power_Cycle_Count   0x0032  100     100     000     -   20
192     Power-Off_Retract_Count     0x0032  200     200     000     -   3
193     Load_Cycle_Count    0x0032  200     200     000     -   171
194     Temperature_Celsius     0x0022  108     105     000     -   35
196     Reallocated_Event_Count     0x0032  199     199     000     -   1
197     Current_Pending_Sector  0x0032  200     200     000     -   2
198     Offline_Uncorrectable   0x0030  100     253     000     -   0
199     UDMA_CRC_Error_Count    0x0032  200     200     000     -   0
200     Multi_Zone_Error_Rate   0x0008  100     253     000     -   0

En de reallocated sector count loopt op.
De schijf is overigens pas 90 uur online

[ Voor 76% gewijzigd door jbhc op 17-04-2015 11:50 ]

[Anoniem: 15758]

Bad sectors maakt nog geen defecte schijf; hij doet het gewoon nog, toch?

Je hebt wel bad sectors; en voor een schijf met 90 draaiuren mag dat niet; retourneren dus.

Aangezien je ZFS gebruikt kun je het beste de probleemdisk eerst vervangen, terwijl de probleemdisk nog aangesloten blijft. Zo kun je rebuilden terwijl je je redundancy niet verliest.

[jbhc]

Ik heb niet zomaar bad sectors.
Hij is volgens mij nog steeds met een scrub bezig maar ik kan via de web interface de pool NIET bekijken.
De reallocated sector count loopt momenteel nog steeds op. Voor de scrub waren het er 0 nu al 169 en hij blijft oplopen. (tijdens het tikken van dit stukje al opgelopen naar de 175)

Als ik je goed begrijp is het dus het handigst om een nieuwe schijf aan te schaffen, deze er bij te prikken, de array laten rebuilden met de nieuwe schijf, en dan de defecte te verwijderen?

[FireDrunk]

Bij ZFSguru gebeurt het wel vaker dat de webinterface niet reageert als je server druk is...

[jbhc]

Toch om nog even hierop terug te komen. Kan ik mijn server gewoon uitzetten tijdens de scrub?

[CurlyMo]

Ja, hij vervolgt de scrub nadat je de pool weer importeert.

[ Voor 3% gewijzigd door CurlyMo op 17-04-2015 12:50 ]

[Anoniem: 15758]

jbhc schreef op vrijdag 17 april 2015 @ 11:58:
Ik heb niet zomaar bad sectors.
Hij is volgens mij nog steeds met een scrub bezig maar ik kan via de web interface de pool NIET bekijken.
De reallocated sector count loopt momenteel nog steeds op. Voor de scrub waren het er 0 nu al 169 en hij blijft oplopen. (tijdens het tikken van dit stukje al opgelopen naar de 175)

Als ik je goed begrijp is het dus het handigst om een nieuwe schijf aan te schaffen, deze er bij te prikken, de array laten rebuilden met de nieuwe schijf, en dan de defecte te verwijderen?

Je hebt last van hoge timeouts waardoor zaken als de web-interface niet reageert. Je kunt in de /boot/loader.conf de TLER-tweaks activeren zodat je timeout veel minder groot is. Dan heb je niet het probleem van een non-responsive system in geval van veel bad sectors.

Het voordeel van rebuilden met je oude schijf is dat je tijdens de rebuild nog gewoon redundancy hebt. Zou je andere schijf ook een bad sector hebben, dan kan dit worden opgevangen.

[jbhc]

OK, dan ga ik de server nu uitzetten. Morgen heb ik een andere schijf en dan zal ik de pool late rebuilden.

[tvwes]

jbhc schreef op vrijdag 17 april 2015 @ 11:37:
Sinds een tijdje heb ik ZFSGuru draaien als vervanger voor mijn linux raid1 thuis server. Dit omdat ik nu al 2x last heb gehad van een falende raid wegens overlijdende schijven.

Vandaag ben ik eens een scrub gaan doen maar nu blijkt 1 van de HD's (wederom) defect.

Iemand een idee wat ik nu het beste kan doen?
De scrub door laten gaan of het systeem uitzetten.

ik geloof dat ik net te laat ben
Voordat je het systeem uitzet of reboot
Als je systeem niet of traag reageert door de scrub kan je deze stopen met zpool scrub -s [zpool name]
Kan je dan hier even de output posten van zpool status -v [zpool name]
Heb je nog sata poorten over?

[jbhc]

Te laat. Ik zet m net uit

Ik weet niet wat je wilde weten van zpool status -v. Had dat wel gedaan en hij gaf aan dat er nog geen data errors waren.

Ja, ik heb nog 2 sata poorten over.

Overigens is dit mijn configuratie:

Moederbord: Asus M4A88T-M/USB3
Processor: AMD Athlon II X2 245e
Geheugen: 3x 2GB Hynix DDR3 PC-8500 (1066 MHz) ECC

Schijven: 1x SSD Bootschijf
3x WD Green 1TB in RaidZ

[ Voor 37% gewijzigd door jbhc op 17-04-2015 13:22 ]

[tvwes]

Ik graag de errors wil zien.

Bij ZFS wil je over het algemeen in je live zpool (met de kapotte disk dus nog aanwezig) de vervangende disk in een vrije sas/sata poort pluggen en zpool replace [old dev] [new dev] uitvoeren. zie ook HyperBart schreef op zaterdag 18 april 2015 @ 21:48

Voordelen
-je data blijft beschikbaar
-je behoud je maximale redundancy (wat er nog van over is), maar in jouw geval meer dan de haperende disk er compleet uit trekken
-veel drives maar ook andere componenten (die lang aanstaan) hebben de vervelende eigenschap soms niet aan te gaan. Je had een drive met een probleem en na het opstarten heb je plots meerdere drives met een probleem. (gebeurt best vaak maar vooral bij systemen die al jaren aan staan, niet zo vaak bij nieuwe spullen)

Voorwaarde is dat je een vrije poort hebt en budget om een extra drive te kopen. (Na het resilveren kan je de kapotte drive opsturen en heb je daarna permant een reserve exemplaar!)

Voordat iemand begint dat ik veel te voorzichtig ben: @jbhc zijn drive was pas 90 uur oud, als er een faalt lijkt het me niet onwaarschijnlijk dat er nog een faalt. Omdat de meesten hier raidz1 of max raidz2 hebben is een beetje voorzichtigheid wel op zijn plaats.

[ Voor 7% gewijzigd door tvwes op 18-04-2015 22:02 ]

[ikkeenjij36]

Nou na het gisteren toch goed aan de gang krijgen van zfsguru heb ik geprobeerd sonarr aan de paat te krijgen wat niet wil lukken.
Moet ik daarvoor hier vragen of kan ik dat misschien beter hier [Ervaringen] CouchPotato, Sickbeard, Headphones e.a. deel 3 doen?
Het heeft iets te maken met start/stop scripts en waar ze te plaatsen enz.

[ Voor 18% gewijzigd door ikkeenjij36 op 17-04-2015 13:48 ]

[FREAKJAM]

Ik zou de vraag in het andere topic stellen of je kunt een eigen topic aanmaken. Zie het algemene beleid.
Het algemeen beleid #quickstart

[tvwes]

jbhc schreef op vrijdag 17 april 2015 @ 13:17:
Te laat. Ik zet m net uit

Ik weet niet wat je wilde weten van zpool status -v. Had dat wel gedaan en hij gaf aan dat er nog geen data errors waren.

Ja, ik heb nog 2 sata poorten over.

Overigens is dit mijn configuratie:

Moederbord: Asus M4A88T-M/USB3
Processor: AMD Athlon II X2 245e
Geheugen: 3x 2GB Hynix DDR3 PC-8500 (1066 MHz) ECC

Schijven: 1x SSD Bootschijf
3x WD Green 1TB in RaidZ

Wat leuk, ik gebruik al jaren de M2A-VM's met een AMD dual core ??? 4x1 of 2GB KVR ECC met WD1000FYPS schijven in 2 of 3 mirrors. Ik boot vanaf twee IDE naar CF adapters draai het OS op een mirror.
Heb je wel een losse intel nic toegevoegd? Echt doen, betere drivers, performance en lagere cpu overhead. Dit is een goedkope maar echt goede upgrade.

Kan jij de output van dmidecode posten? Ik wil graag weten of en hoe je ECC wordt weergegeven.

Voorbeeld van Solaris (niet FreeBSD)

code:

ID    SIZE TYPE
67    84   SMB_TYPE_MEMDEVICE (memory device)

  Manufacturer: Manufacturer3
  Serial Number: SerNum3
  Asset Tag: AssetTagNum3
  Location Tag: DIMM_B2
  Part Number: PartNum3

  Physical Memory Array: 59
  Memory Error Data: Not Supported
  Total Width: 64 bits
  Data Width: 72 bits
  Size: 1073741824 bytes
  Form Factor: 9 (DIMM)
  Set: None
  Memory Type: 19 (DDR2)
  Flags: 0x80
        SMB_MDF_SYNC (synchronous)
  Speed: 1ns
  Device Locator: DIMM_B2
  Bank Locator: BANK3

[ikkeenjij36]

FREAKJAM schreef op vrijdag 17 april 2015 @ 13:50:
Ik zou de vraag in het andere topic stellen of je kunt een eigen topic aanmaken. Zie het algemene beleid.
Het algemeen beleid #quickstart

Ok ga ik daar even verder bedankt.
Nu nog hopen dat ze daar net zo snel reageren als jullie hier

[ Voor 9% gewijzigd door ikkeenjij36 op 17-04-2015 14:01 ]

[Durandal]

Ik kan het even niet zo snel vinden;
Ik ben aan het Resilveren - impliceert dat ook een gelijktijdige Scrub?

[ikkeenjij36]

Morgen ga ik het toch proberen om zfsguru live te gooien en even zonder xpenology te draaien.
Nu vanaf scratch beginnen maar met de nieuwe ssd.
Misschien ga ik eerst zoals jullie adviseerden de ssd opdelen in 2 partities dus 1 voor os en dan 1 voor l2arc?
Of is dat niet handig omdat de ssd dan met 2 dingen tegelijk bezig is?
Zoals os en l2arc?
Sorry voor deze vragen weer maar nu alles goed maken en dan even goed doen.
Dan maar even zonde sonarr draaien en kijken of dat straks met de nieuwe versie er wel op te zetten is?
O en dan nog de vraag hoe mijn data storage indelen.
1x4Tb hdd 1x3Tb hdd 9x2Tb hdd's en dan de vertex3 ssd 60Gb en de nieuwe ssd samsung 850 evo 120Gb.
Graag de beste manier om dit alles goed in te delen zodat zfsguru lekker draait en de schijven goed bij elkaar pasen en ik een max aan storage heb om van gebruik te maken!!
Daarna zal hoop ik jullie allen nog maar lastig vallen met kleine afstel vraagjes zoals hoe de apm en spindown in te stellen,dat soort kleine dingen hoop ik dadelijk nog in te stellen met jullie hulp.
Jullie zien het heeft even geduurd maar ik word toch eindelijk een beetje wijs.
Enige "voorwaarde"is dat ik hem wel kan blijven gebruiken als dl bak met sabnzbd/couchpotato/headphones/spotweb en plexserver.
Graag jullie eerlijke maar ik hoop niet al te harde meningen hierover ove hoe en wat.

[FREAKJAM]

Hoe je de SSD moet indelen is je al eerder uitgelegd: (zoekfunctie for the win )

CurlyMo schreef op dinsdag 10 juni 2014 @ 16:38:
[...]

Je gedraagt je er in ieder geval nogal naar.

Wat is het verschil tussen CiPHER die je vertelt wat je moet doen of dat je deze blog leest: http://blog.ociru.net/2013/04/05/zfs-ssd-usage waarin redelijk letterlijk voor je uitgelegd staat:

[...]

Hij vertelt je zelfs de exacte commando's die je moet invoeren om het voor elkaar te krijgen. Dat ga je zelfs van CiPHER niet te horen krijgen.

Als ik zo zie wat je allemaal doet ben je (met alle respect en deels compliment) niet zozeer een noob, maar vooral lui.

Omdat je Sonarr nu niet werkend krijgt, wil dat niet zeggen dat het de nieuwe versie wel gaat werken. Focus van ZFSGuru ligt vooral op het ZFS gebeuren zelf en niet op de services die aangeboden worden. (@CiPHER correct me when wrong) Zoals ik en CiPHER al eerder zeiden, mono + FreeBSD is geen goeie combinatie.

Met betrekking tot je disks, er zijn denk ik genoeg best practices guides te vinden op het internet (waaronder dit topic). Spindown en APM heeft CiPHER al eens uitgelegd in dit topic.

[ Voor 6% gewijzigd door FREAKJAM op 18-04-2015 00:58 ]

[fluppie007]

Tegen alle advies (lees vooral van de fabrikant) in toch Green drives gekozen in plaats van Red schijven. We zien wel over een poosje of dit een idiote zet was of niet.

code:

Detected 3 disks, select a disk for formatting options.
Disk    Label   Size (legacy)   Size (binary)   Sector  Identified as   
ada0    GPT: StoragePool6TB-disk1   6 TB    5.5 TiB     512 B   <WDC WD60EZRX-00MVLB1 80.00A80> ATA-9 SATA 3.x device   
ada1    GPT: StoragePool6TB-disk2   6 TB    5.5 TiB     512 B   <WDC WD60EZRX-00MVLB1 80.00A80> ATA-9 SATA 3.x device   
ada2    GPT: StoragePool6TB-disk3   6 TB    5.5 TiB     512 B   <WDC WD60EZRX-00MVLB1 80.00A80> ATA-9 SATA 3.x device

[ikkeenjij36]

Ok de ssd ga ik dan zo indelen en in orde krijgen.
In betrekking tot mijn hdd's staat er hier idd veel geschreven maar door mijn zeg maar ongelukkige samenstelling van schijven twijfel ik wat te doen
De 4tb opdelen in 2x2tb?
De 3tb op2delen in 1x2tb en 1x1tb?
Waatmee als ik het goed begrepen heb 11x2tb storage krijg en dat in een raid z? kan gaan zetten?
Waardoor ik 3tb loze ruimte heb die ik niet kan gebruiken omdat niet goed gaat als er 2x op een en dezelde schijf geschreven wordt en daarom niet wenselijk is.
Daarbij was/ben ik dan in de war dat zfsguru meer een zfs server is dan als nas(services) te gebruiken is?
Ik was/ben er van overtuigd dat jason/CIPHER juist tbe best of 2 worlds wouden/willen neerzetten/aanbieden zodat jullie als in mijn ogen "experts" er alles mee kunnen en mensen zoals "ik" dit als een mooie nas kunen/willen gebruiken met het grootste voordeel de zfs opties/veiligheid erbij/in.
Ook voor mij is dit en nog steeds een best steile leercurve vwb zfs-linux/unix en wat er allemaal bij komt kijken.
Ook heb ik jullie regelmatig horen adviseren draai zfsguru en de dl meuk via vm's maar naar mijn idee wordt dit allemaal nog ingwiKkelder voor mij om dan ook mijn storage goed te kunnen koppelen/aanspreekbaar voor mij te houden.
En toch heb ik al veel van jullie geleerd over zfs en ben ik er toch van overtuigd dat dit wel de toekomst is/wordt,ook voor een huis hobbyer als ik en ik denk dat er meer mensen er zo onstaan.
Pff een hele lap tekst maar vriendelijk bedoelt en ik blijf toch van jullie leren en dingen aan nemen ook al duurt dat even.

[vanaalten]

fluppie007 schreef op zaterdag 18 april 2015 @ 01:03:
Tegen alle advies (lees vooral van de fabrikant) in toch Green drives gekozen in plaats van Red schijven. We zien wel over een poosje of dit een idiote zet was of niet.

code:

Detected 3 disks, select a disk for formatting options.
Disk    Label   Size (legacy)   Size (binary)   Sector  Identified as   
ada0    GPT: StoragePool6TB-disk1   6 TB    5.5 TiB     512 B   <WDC WD60EZRX-00MVLB1 80.00A80> ATA-9 SATA 3.x device   
ada1    GPT: StoragePool6TB-disk2   6 TB    5.5 TiB     512 B   <WDC WD60EZRX-00MVLB1 80.00A80> ATA-9 SATA 3.x device   
ada2    GPT: StoragePool6TB-disk3   6 TB    5.5 TiB     512 B   <WDC WD60EZRX-00MVLB1 80.00A80> ATA-9 SATA 3.x device

Ik heb exact dezelfde in m'n ZFS mirror, maand of drie ondertussen. En gaat vooralsnog prima, meest frustrerende aan die dingen is de hoge spin-up tijd: zo'n tien seconde van stilstand tot volledig werkzaam.

[jacovn]

ikkeenjij36 schreef op zaterdag 18 april 2015 @ 01:06:
In betrekking tot mijn hdd's staat er hier idd veel geschreven maar door mijn zeg maar ongelukkige samenstelling van schijven twijfel ik wat te doen
De 4tb opdelen in 2x2tb?
De 3tb op2delen in 1x2tb en 1x1tb?
Waatmee als ik het goed begrepen heb 11x2tb storage krijg en dat in een raid z? kan gaan zetten?
Waardoor ik 3tb loze ruimte heb die ik niet kan gebruiken omdat niet goed gaat als er 2x op een en dezelde schijf geschreven wordt en daarom niet wenselijk is.

10x 2 TB in raid-z2 lijkt me een goed idee. (Met 2 TB hdds, maar die heb je niet)
Verder schreef je op htforum dat je nog 2 maal een 4 TB had gekocht, dus daar heb je er 3 van. Wellicht nog 2 kopen en dan 5 hdds in raid-z doen.
Dan heb je 2 vdevs die goed in elkaar zitten. Weet niet zo of ze in combinatie wel lekker onder 1 pool lopen.
Een losse 3 TB is wellicht als download disk te gebruiken, als je 200 mbps down hebt en de nas de nacht door laat lopen te downloaden.

Als je niet optimale vdevs wilt maken kun je ook je 8 * 2TB hdds in een vdev stoppen met raid-z2, en 3x4 TB kan ook werken in raid-z1

Maar zoals ik het zie moet je gewoon beginnen met een vdev die goed in elkaar zit en de benodigde hdds kopen.

Wil je alles door elkaar gebruiken kun je beter shr op je synology software blijven doen denk ik.

[tvwes]

Ik heb zeer goed ervaringen met de WD greens, hoofdzakelijk de oude WD1000FYPS RE2-GP wat wel een enterprise disk was. Wel wil ik opmerken dat de disken bij mij nooit zijn gaan slapen. Ja de greens zijn echt traag en je moet het niet vergelijken met 10K of snellere drives en al helemaal niet met flash. Maar voor de media collecties hier zijn ze prima, ze streamen opzich prima. Wil je iets van performance hebben zorg dan dat je (veel) vdev's hebt in je zpool. Redelijk zuinig en stil prima voor thuis.
Ik las net wat aantekeningen na en die drives die ik gebruikte kon je de TLER gewoon instellen. Later is WD daarmee gestopt bij de consumenten disken.

[Anoniem: 15758]

De 6TB Greens doen 175MB/s wat niet slecht is voor een 5400rpm-class schijf. De RE2-GP die jij bedoelt is een fysiek andere schijf volgens mijn weten; de RE-serie is fysiek anders dan de normale Greens. Maar de Greens en Reds zijn fysiek hetzelfde, op een vibratiesensor na.

Bij lage rpm mis je natuurlijk IOps, maar voor een ZFS server met vooral grote bestanden is dat eigenlijk geen issue. Random writes doet ZFS sowieso al sequential. Dus dan gaat het om sequential read en random read. Dat eerste doen de schijven uitstekend en random reads kun je verzachten met L2ARC als dat nodig is. Het cachen van metadata is iets waar ik zelf nogal fan van ben. Dan hoeven je schijven dit ook niet meer te doen en dat scheelt al random reads zodat je schijven nog meer aan sequential read toekomen.

Kortom, WD Green is denk ik dé perfecte schijf voor ZFS servers voor thuisgebruikers, die vooral grote bestanden opslaan zoals audio/video/archives. Heb je daarnaast ook virtual machines, dan kan het lonend zijn een paar SSDs hiervoor aan te schaffen, die kun je dan voor L2ARC, sLOG, systeem/boot gebruiken alsmede voor de opslag van VM images.

Voor weinig geld heb je dan een mooie ZFS server.

[jbhc]

Ik heb mijn vervangende schijf ondertussen in de server gestopt en ben die nu aan het formateren.
Wat is nu de beste manier om de defecte schijf te vervangen? Kan ik gewoon via de GUI naar de defecte schijf gaan en dan klikken op replace disk? Of is er een betere manier.

@tvwes

dmidecode geeft dit voor het geheugen:

code:

[root@zfsguru /home/ssh]# dmidecode -t memory
# dmidecode 2.12
SMBIOS 2.5 present.

Handle 0x0033, DMI type 16, 15 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: Single-bit ECC
        Maximum Capacity: 16 GB
        Error Information Handle: Not Provided
        Number Of Devices: 4

Handle 0x0035, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0033
        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: 2048 MB
        Form Factor: DIMM
        Set: None
        Locator: DIMM0
        Bank Locator: BANK0
        Type: Other
        Type Detail: Synchronous
        Speed: 1066 MHz
        Manufacturer: Manufacturer0
        Serial Number: SerNum0
        Asset Tag: AssetTagNum0
        Part Number: PartNum0

Handle 0x0037, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0033
        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: 2048 MB
        Form Factor: DIMM
        Set: None
        Locator: DIMM1
        Bank Locator: BANK1
        Type: Other
        Type Detail: Synchronous
        Speed: 1066 MHz
        Manufacturer: Manufacturer1
        Serial Number: SerNum1
        Asset Tag: AssetTagNum1
        Part Number: PartNum1

Handle 0x0039, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0033
        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: 2048 MB
        Form Factor: DIMM
        Set: None
        Locator: DIMM2
        Bank Locator: BANK2
        Type: Other
        Type Detail: Synchronous
        Speed: 1066 MHz
        Manufacturer: Manufacturer2
        Serial Number: SerNum2
        Asset Tag: AssetTagNum2
        Part Number: PartNum2

Handle 0x003B, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0033
        Error Information Handle: Not Provided
        Total Width: Unknown
        Data Width: Unknown
        Size: No Module Installed
        Form Factor: DIMM
        Set: None
        Locator: DIMM3
        Bank Locator: BANK3
        Type: Unknown
        Type Detail: None
        Speed: Unknown
        Manufacturer: Manufacturer3
        Serial Number: SerNum3
        Asset Tag: AssetTagNum3
        Part Number: PartNum3

[ikkeenjij36]

CIPHER om nog even op het L2ARC en sLOG terug te komen.
Ik wil het nu dus zo gaan doen,de evo 850 3 partities maken 40Gb voor L2ARC/30Gb voor sLOG en dan 70Gb over houden voor het os(zfsguru) en dan op de 2e ssd(vertex3)30Gb vooL2ARC en 30Gb voor sLOG
en dan voor L2ARC en sLOG eemirrored pool van maken,kan jij je daar in vinden?
Is dat beetje een goede indeling?
Ik denk dat ik dan mijn gewone schijven ontlast hiermee?

[jacovn]

tvwes schreef op zaterdag 18 april 2015 @ 10:05:
Ik heb zeer goed ervaringen met de WD greens, hoofdzakelijk de oude WD1000FYPS RE2-GP wat wel een enterprise disk was. Wel wil ik opmerken dat de disken bij mij nooit zijn gaan slapen. Ja de greens zijn echt traag en je moet het niet vergelijken met 10K of snellere drives en al helemaal niet met flash. Maar voor de media collecties hier zijn ze prima, ze streamen opzich prima.

Die heb ik in mijn pc zitten, 2 x setje van 5. Wel 7 jaar oud of zo, maar nooit 1 issue mee gehad. Nu paar vervangen voor hgst 3TB met tlre.
Ze zijn zeker niet snel, heb er nu 6 in een raid-5 array zitten, maar de 4 hgst ook in raid-5 zijn 1.5x sneller of meer zelfs.

[CurlyMo]

@ikkeenjij36, CurlyMo in "Het grote ZFS topic"

[tvwes]

jbhc schreef op zaterdag 18 april 2015 @ 12:33:
Ik heb mijn vervangende schijf ondertussen in de server gestopt en ben die nu aan het formateren.
Wat is nu de beste manier om de defecte schijf te vervangen? Kan ik gewoon via de GUI naar de defecte schijf gaan en dan klikken op replace disk? Of is er een betere manier.

@jbhc
Ik weet niet wat de procedure is in ZFSGuru.

Wel wil ik je bedanken voor de dmidecode. Je kan aan twee zaken zien dat de kans op een echt werkend ECC implementatie aanwezig is:

• De mobo meld: Error Correction Type: Single-bit ECC
• Het geheugen is 8+1 bytes = 72 bits breed

Als tweakers op FreeBSD willen weten of ze ECC ondersteuning en ECC ram hebben onder FreeBSD is het command: dmidecode -t memory

Succes met je rebuild en hou een reserve schijf bij de hand want er zou in eerste maanden zo nog maar een kunnen uitvallen. (badkuip kurve, veel uitval in het begin en op het einde)

@tvwes

dmidecode geeft dit voor het geheugen:

code:

[root@zfsguru /home/ssh]# dmidecode -t memory
# dmidecode 2.12
SMBIOS 2.5 present.

Handle 0x0033, DMI type 16, 15 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: Single-bit ECC
        Maximum Capacity: 16 GB
        Error Information Handle: Not Provided
        Number Of Devices: 4

Handle 0x0035, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0033
        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: 2048 MB
        Form Factor: DIMM
        Set: None
        Locator: DIMM0
        Bank Locator: BANK0
        Type: Other
        Type Detail: Synchronous
        Speed: 1066 MHz
        Manufacturer: Manufacturer0
        Serial Number: SerNum0
        Asset Tag: AssetTagNum0
        Part Number: PartNum0

[ikkeenjij36]

Nou ssd´s opgedeeld zoals aangegeven door jullie en dat is gelukt.
Bootcode geupdate en dan eerst een pool maken om het os op te zetten lukt niet.
Ik krijg dan geen repsons vd server terug en moet ik de pagina verversen en dus weer opnieuw beginnen.
Wat gaat er nou toch fout,doe alles zoals jullie het zeggen zoals gui mij er doorheen leidt en nog niks.

[jbhc]

Wat ik vreemd vind is dat hier:

code:

Handle 0x0035, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0033
        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: 2048 MB
        Form Factor: DIMM

Dit staat:

code:

 Error Information Handle: Not Provided

Daarvan krijg ik toch het idee dat ECC niet lekker werkt.


Ik heb trouwens nogal wat tijd besteed aan het bij elkaar zoeken van ecc hardware.
Voor zover ik kon vinden is ASUS het enige merk wat ECC officieel ondersteund op consumenten hardware en dan alleen in combinatie met de AMD processoren tot en met de AM3 sockets. Bij de FMx sockets wordt ECC niet meer ondersteund.

Bij Intel varianten vond ik het helemaal een erg lastig uit te zoeken verhaal.

[ Voor 3% gewijzigd door jbhc op 18-04-2015 15:05 ]

[ikkeenjij36]

Nou schiet mij maar lek,ik kan geen enkele pool maken,dan krijg ik een time out ofzo vd server en is er niks gebeurt.
Wat nu,ik zit er toch aan te denken om heel zfsguru maar op te geven zo,wat jammer toch.

[CurlyMo]

ikkeenjij36 schreef op zaterdag 18 april 2015 @ 14:50:
Wat nu,ik zit er toch aan te denken om heel zfsguru maar op te geven zo,wat jammer toch.

Vrijwel iedereen hier probeert je dat al tijden met alle goede bedoelingen duidelijk te maken. Blijkbaar is een custom NAS niet aan je besteed. Daar hoef je je echt niet voor te schamen, want men doet het hier allemaal veel makkelijker voorkomen dan het is.

Wikipedia: Dunning-krugereffect

Doe dus jezelf een plezier en neem gewoon een kant-en-klare oplossing.

[ikkeenjij36]

CurlyMo schreef op zaterdag 18 april 2015 @ 15:05:
[...]

Vrijwel iedereen hier probeert je dat al tijden met alle goede bedoelingen duidelijk te maken. Blijkbaar is een custom NAS niet aan je besteed. Daar hoef je je echt niet voor te schamen, want men doet het hier allemaal veel makkelijker voorkomen dan het is.

Wikipedia: Dunning-krugereffect

Doe dus jezelf een plezier en neem gewoon een kant-en-klare oplossing.

MJA ik weet maar ben gewoon eigenwijs,het/probleem-problemen doen zich alleen voor bij zfsguru terwijl er tig mense hier het voor elkaar krijgen ook met gewone consumenten hardware,noem me eigenwijs maar waarom wil het bij mij niet lukken dan.
Zelfs een gewone pool maken op een disk lukt-wil niet,ik verlies de verbinding naar de server en klaar is het weer,maakt niet uit welke hdd of ssd pak hij doet het gewoon niet.
Ik krijg error empty response terug.

[ Voor 10% gewijzigd door ikkeenjij36 op 18-04-2015 15:20 ]

[CurlyMo]

ikkeenjij36 schreef op zaterdag 18 april 2015 @ 15:15:
[...]

MJA ik weet maar ben gewoon eigenwijs,het/probleem-problemen doen zich alleen voor bij zfsguru terwijl er tig mense hier het voor elkaar krijgen ook met gewone consumenten hardware,noem me eigenwijs maar waarom wil het bij mij niet lukken dan.

Zeer waarschijnlijk een gebrek aan de juiste kennis, kunde en ervaring. Precies zoals in het wikipedia artikel beschreven.

[jbhc]

ikkeenjij36 schreef op zaterdag 18 april 2015 @ 15:15:
[...]

MJA ik weet maar ben gewoon eigenwijs,het/probleem-problemen doen zich alleen voor bij zfsguru terwijl er tig mense hier het voor elkaar krijgen ook met gewone consumenten hardware,noem me eigenwijs maar waarom wil het bij mij niet lukken dan.
Zelfs een gewone pool maken op een disk lukt-wil niet,ik verlies de verbinding naar de server en klaar is het weer,maakt niet uit welke hdd of ssd pak hij doet het gewoon niet

Misschien omdat je het gewoon niet kan? Mensen kunnen nu eenmaal niet alles. Ik kan bijvoorbeeld geen instrumenten bespelen. (en geloof me ik zou dat best graag willen en heb het ook echt geprobeerd). Andere mensen kunnen niet zingen. Om je maar wat voorbeelden te geven.

[jbhc]

@tvwes:

Net na wat speurwerk kwam ik er achter dat dit commando een wat meer heldere output geeft :

code:

dmidecode | grep -i error\ correct
        Error Correction Type: Single-bit ECC
        Error Correction Type: Single-bit ECC
        Error Correction Type: Unknown
        Error Correction Type: Single-bit ECC

[FREAKJAM]

ikkeenjij36 schreef op zaterdag 18 april 2015 @ 15:15:
[...]

MJA ik weet maar ben gewoon eigenwijs,het/probleem-problemen doen zich alleen voor bij zfsguru terwijl er tig mense hier het voor elkaar krijgen ook met gewone consumenten hardware,noem me eigenwijs maar waarom wil het bij mij niet lukken dan.
Zelfs een gewone pool maken op een disk lukt-wil niet,ik verlies de verbinding naar de server en klaar is het weer,maakt niet uit welke hdd of ssd pak hij doet het gewoon niet.
Ik krijg error empty response terug.

FREAKJAM schreef op donderdag 16 april 2015 @ 21:08:
Het is al vaker tegen je geroepen in dit topic en ik zeg het weer:

Is ZFSGuru wel de juiste oplossing voor jou? Elke keer weer probeer je het opnieuw (wat ik trouwens aanmoedig, want doorzettingsvermogen heb je zeker), maar keer op keer raak je met ZFSGuru of vooral jezelf in de knoop. Ik ben bang dat deze oplossing en ZFS wellicht te hoog gegrepen voor je is.

Je had laatst nog Xpenology draaien en dat draaide letterlijk (het waren je eigen woorden) als een tierelier. Ik weet niet wat daar is mis gegaan, maar ik denk dat dat pakket toch beter bij je past. Idem dito voor OpenMediaVault. In de laatste versie kun je alles draaien wat jij zoekt (Plex, Sab, Sonarr etc). OpenMediavault is Debian (linux) based en dat is denk ik toch iets makkelijker dan FreeBSD met ZFS.

Zoals ik al eerder zei, probeer OMV nog eens. Alle plugins binnen handbereik en zij zijn erg actief bezig met een ZFS plugin.

[jacovn]

ikkeenjij36 schreef op zaterdag 18 april 2015 @ 15:15:
[...]

MJA ik weet maar ben gewoon eigenwijs,het/probleem-problemen doen zich alleen voor bij zfsguru terwijl er tig mense hier het voor elkaar krijgen ook met gewone consumenten hardware,noem me eigenwijs maar waarom wil het bij mij niet lukken dan.
Zelfs een gewone pool maken op een disk lukt-wil niet,ik verlies de verbinding naar de server en klaar is het weer,maakt niet uit welke hdd of ssd pak hij doet het gewoon niet.
Ik krijg error empty response terug.

Het lijk wel hetzelfde als wat bij mij mis was..

Verkeerd geheugen gekregen en niet gecontroleerd. Alles boot goed, maar in de installatie procedure van freebsd/zfsguru liep er wat mis.

Wilde gok, maar probeer eens memtest op je pc of dat allemaal wel klopt.

Ik heb zfsguru op 5 verschillende moederborden geinstalleerd en behalve met dat memory probleem nooit een issue.

[jbhc]

Ondertussen heb ik toch behoorlijk gegoogled maar heb ik nog steeds het antwoord op mijn vraag niet gevonden.

Ik heb dus een defecte schijf die ik wil gaan vervangen voor een andere.
Is het de juiste procedure om de nieuwe schijf er bij te prikken en vervolgens in de gui de defecte schijf te selecteren en hier te kiezen voor replace disk? Of is er een andere/betere metode?

Of is er misschien een up to date handleiding zodat ik eea zelf op kan zoeken

[ikkeenjij36]

jacovn schreef op zaterdag 18 april 2015 @ 17:26:
[...]

Het lijk wel hetzelfde als wat bij mij mis was..

Verkeerd geheugen gekregen en niet gecontroleerd. Alles boot goed, maar in de installatie procedure van freebsd/zfsguru liep er wat mis.

Wilde gok, maar probeer eens memtest op je pc of dat allemaal wel klopt.

Ik heb zfsguru op 5 verschillende moederborden geinstalleerd en behalve met dat memory probleem nooit een issue.

Memtest gedaan en er komen geen fouten naar boven.
Ik moet wel zeggen dat ik geen ecc geheugen erin heb zitten.
Ook durf ik niet te zeggen of mijn moederbord ecc geheugen kan hebben herkennen?
Mijn moederbord is een msi970..g65. Amd amd3+ socket.

[A1AD]

ikkeenjij36 schreef op zaterdag 18 april 2015 @ 18:25:
[...]

Memtest gedaan en er komen geen fouten naar boven.

Laat dat maar eens een hele nacht lopen hoor

[dcm360]

ikkeenjij36 schreef op zaterdag 18 april 2015 @ 18:25:
[...]
Ook durf ik niet te zeggen of mijn moederbord ecc geheugen kan hebben herkennen?
Mijn moederbord is een msi970..g65. Amd amd3+ socket.

Het is mogelijk dat ECC-geheugen op dat bord werkt (maar geen garantie daarop). Het schijnt meer af te hangen van de CPU, zover ik weet werkt ECC alleen met processors uit de FX- en Opteron-series.

[ Voor 3% gewijzigd door dcm360 op 18-04-2015 19:23 ]

[ikkeenjij36]

cpu is amd phenom2x4 955

[ph0t0nix]

@ikkeenjij36: nog een ding over de SSD partitie die je als sLOG wilt gebruiken. Ik zou daar geen 30 GB voor gebruiken. Een paar GB is meer dan genoeg. Ik gebruik een sLOG van 4 GB en dat is meer dan genoeg, ik zie hoogstens een GB in gebruik, terwijl ik mijn ZFS server voornamelijk als NFS server inzet.

[HyperBart]

jbhc schreef op zaterdag 18 april 2015 @ 17:26:
Ondertussen heb ik toch behoorlijk gegoogled maar heb ik nog steeds het antwoord op mijn vraag niet gevonden.

Ik heb dus een defecte schijf die ik wil gaan vervangen voor een andere.
Is het de juiste procedure om de nieuwe schijf er bij te prikken en vervolgens in de gui de defecte schijf te selecteren en hier te kiezen voor replace disk? Of is er een andere/betere metode?

Of is er misschien een up to date handleiding zodat ik eea zelf op kan zoeken

Dat is inderdaad de juiste procedure, even in "laymansterms":

Stel je hebt disk
1 2 3 4 5

Disk 5 begint rot te doen (sectors, bokken, whatever).

Wat je nu doet met een replace is zeggen tegen ZFS:

"ik wil mijn beschikbare, benaderbare, maar early-failing disk VERVANGEN door een nieuw model"

ZFS gaat nu de data die disk 5 bevat aan de hand van 1 2 3 4 5 wegschrijven naar disk 6 om 'm zo maar even te noemen.

Het voordeel is nu dat tijdens dat "berekenen van de weg te schrijven data", als er toevallig op dat moment op disk 3 een gek foutje voorkomt, dat hij (hopelijk) disk 5 op dat moment nog kan bereiken om de data on the fly te reconstrueren en goed weg te schrijven naar disk 6... Heb je disk 5 op dat moment niet, dan zegt ZFS "woeps, die data kon ik niet meer goed wegschrijven, oh ja aangezien ik ook weet heb van het filesystem wat op je pool draait kan ik je nu ineens ook vertellen dat de data die ik niet kon reconstrueren deel uitmaakte van het volgende bestandje, en dat bestandje is nu kapot!"

[tvwes]

dcm360 schreef op zaterdag 18 april 2015 @ 19:22:
[...]

Het is mogelijk dat ECC-geheugen op dat bord werkt (maar geen garantie daarop). Het schijnt meer af te hangen van de CPU, zover ik weet werkt ECC alleen met processors uit de FX- en Opteron-series.

"A long time ago in a galaxy far, far away...."

Toen het er goed uitzag voor AMD...

[rant]gloeiende gloeiende, logisch dat lui bijna door het putje zijn ... probeer je de datasheet of wat voor nuttige info dan ook te vinden bij amd.com helemaal niets[/rant]

Ik weet niet hoe ik iets kan uploaden maar hier is een andere site met een datasheet over de athlon x2. Het antwoord staat rechts onderin. Ja, AMD Athlon X2's ondersteunden ECC maar wel alleen met die ASUS bordjes voorzover ik weet. Dat was de reden dat ik destijds een hoop thuis NAS'en kon maken voor deze en genen. Opterons en Xeons waren geen optie. Maar deze AM2, AM2+ en AM3 bordjes waren prima hiervoor. Wel moest je altijd een intel nic toevoegen, want die sommige van die realteks waren een ramp of nog erger die Atheros L1 waar alleen een windows driver voor was. En ik heb nog steeds een aantal van die bordjes draaien in het land. Nee je kan er niet op downloaden, transcoden of koffiezetten maar als NAS met een enkele gbit poort prima voor veel mensen thuis.

Ik heb destijds met een programmeerbare signalgenerator, een opgeblazen mobo een drie ddr2 modules verder, met succes weten te valideren de ECC op een M2A-VM werkte. De uitdaging zat hem in het proberen te manipuleren van een, twee of drie bits in een 64 bit word. Hele words veranderen geen probleem. Maar juist een enkele bitje en niets meer is veel lastiger. Ik heb destijds wel hulp gekregen om deze test setup aan de gang te krijgen. Je kan wel een aantal draden aan de DDR2 socket solderen maar dat levert allerlei capacitieve effecten die met direct aangesloten meet- en testapparatuur ervoor zorgden dat het systeem niet eens wilden booten. Een kennis van mij heeft uiteindelijk de zaak elektrisch goed voor elkaar gemaakt. Toen nog een tijd aan het vogelen geweest om een geschikte trigger te maken en vervolgens op een of meer datalijntjes uit je siggen precies een 1.5v pulsje van 1 ck lang overheen zetten. Dan moet je nog hopen dat je niet je kernel omzeep helpt. Veel trial en nog meer error voordat het werkt, bij gebrek aan echt deftige meetapparatuur. Maar uiteindelijk werkte het prima, 1 data bit waarschuwing welke bit en reparatie, 2 bits waarschuwing welke bits en coredump, 3bits waarschuwing zonder bit positie en coredump.
Voor diegene die wat meer lowtech aan de slag willen" een (rework) fohn richten op een geheugen chip en die dan net niet te warm maken. Trust me heel lastig! Maar je kan wel een bult fouten genereren. Begin met memtest en een niet-ECC module om te kijken of en wanneer je een chip gaat beinvloeden. Nogmaals: niet een hele dimm maar een enkele chip op een dimm verwarmen! Dan de niet-ECC module wisselen voor een ECC exemplaar en weer testen. Dan pas met een OS testen, zegt je systeem niets dan ondersteunt iets geen ECC. Super leuk, wel een project wat tijd en geduld kost.

Alle bovenstaande experimenten waren proefdier vrij.
Alle bovenstaande experimenten werden niet op een droge winterdag met een wolle trui of trainingspak aan gedaan.
En nog duizend disclaimers...

Kortom doe dit niet op je net nieuw bord met een 8GB DDR3 module of iets anders stoms.

[tvwes]

HyperBart schreef op zaterdag 18 april 2015 @ 21:48:
[...]

Dat is inderdaad de juiste procedure, even in "laymansterms":

"ik wil mijn beschikbare, benaderbare, maar early-failing disk VERVANGEN door een nieuw model"

ZFS gaat nu de data die disk 5 bevat aan de hand van 1 2 3 4 5 wegschrijven naar disk 6 om 'm zo maar even te noemen.

Het voordeel is nu dat tijdens dat "berekenen van de weg te schrijven data", als er toevallig op dat moment op disk 3 een gek foutje voorkomt, dat hij (hopelijk) disk 5 op dat moment nog kan bereiken om de data on the fly te reconstrueren en goed weg te schrijven naar disk 6... Heb je disk 5 op dat moment niet, dan zegt ZFS "woeps, die data kon ik niet meer goed wegschrijven, oh ja aangezien ik ook weet heb van het filesystem wat op je pool draait kan ik je nu ineens ook vertellen dat de data die ik niet kon reconstrueren deel uitmaakte van het volgende bestandje, en dat bestandje is nu kapot!"

Helemaal mee eens, dat is in "layman's terms", precies wat ik gisteren in tvwes schreef op vrijdag 17 april 2015 @ 13:37 probeerde duidelijk te maken. Als er nog een disk faalt voordat disk 5 is geresilverd heb je een kans dat op disk 5 nou net dat blockje wel te lezen is. Heb je disk 5 verwijdert heb je met RAIDZ1 echt een probleem op dat moment.
@HyperBart, goed voorbeeld.

[HyperBart]

ikkeenjij36 schreef op zaterdag 18 april 2015 @ 18:25:
[...]

Memtest gedaan en er komen geen fouten naar boven.
Ik moet wel zeggen dat ik geen ecc geheugen erin heb zitten.
Ook durf ik niet te zeggen of mijn moederbord ecc geheugen kan hebben herkennen?
Mijn moederbord is een msi970..g65. Amd amd3+ socket.

Heb je het eigenlijk uberhaupt al eens opgezocht? Ik begin hier echt het gevoel te krijgen dat het hier de vraagbak geworden is.

Gooi dat nu eens gewoon in Google, kijk eerst eens component per component na of je boeltje wel ECC geheugen ondersteunt en wat er allemaal insteekt.

Ik heb echt het idee dat je zoiets hebt van ik koop en grabbel en dan klik ik 300x en dan moet het wel eens goed gaan.

Heb je al eens stap voor stap een aantal guides gevolgd? Heb je bv. al eens LETTER voor letter een guide van FireDrunk gevolgd? OK, dat is met Linux, maar in jouw leefwereld gaat dat echt geen fluit uitmaken lijkt me...

Doe eens stap voor stap. Je gaat ook al weer hollen en lopen: "mijn NAS/SERVER/COMPUTER/DATABAK wil ik NAS van maken moet zoveel mogelijk data kunnen huisvesten met een hele gekke verzameling en ik wil ineens ook downloaden met SickBeard, Sonarr, Sabnzbd, Couchpotato"...

Ja natuurlijk gaat het dan ERGENS mis, je doet 48 dingen tegelijk terwijl je al problemen hebt om het OS deftig te installeren...

En nog het ergste van al: mensen geven je hier meermaals al verschillende "fouten" en problemen de oplossingen van, en telkens bots je tegen hetzelfde aan. Dat is bij mij een klassiek gevalletje "vertikt het om goed te lezen en procedures te volgen"...

CurlyMo schreef op zaterdag 18 april 2015 @ 15:05:
[...]

Doe dus jezelf een plezier en neem gewoon een kant-en-klare oplossing.

Dat dus, begin daar eerst eens mee te spelen...

[ Voor 6% gewijzigd door HyperBart op 18-04-2015 22:31 ]

[jbhc]

@Hyperbart & tvwes:

Bedankt voor jullie uitgebreide antwoord.
Ik had al een vermoeden dat het zo ongeveer zou werken maar ik wist het niet helemaal zeker en vind het over het algemeen dan wel wat spannend om zomaar wat dingen aan te klikken.

Ik ben normaal gesproken trouwens iemand die zoveel mogenlijk zelf uitzoekt, ik kom er nu alleen achter dat er voor ZFSGuru zo goed als geen documentatie bestaat.

Is er trouwens een reden dat er op het ZFSGuru forum ook zo weinig terug te vinden is? Bij elk subforum zie ik maar een pagina terwijl het aantal posts impliceerd dat er veel meer pagina's zouden moeten zijn.

De boel is nu trouwens aan het resilveren. Wat gebeurd er straks? Wordt de falende schijf straks door zfsguru uit de pool gegooid? En kan ik daarna de falende schijf afkoppelen en de nieuwe schijf op de sata aansluiting van de oude aansluiten?

/edit:

Om even antwoord te geven op mijn eigen vraag:

Na het resilveren is de falende schijf inderdaad uit de pool gegooid. (Ondertussen met 869 reallocated sectors) Dit werkt wel erg mooi

[ Voor 26% gewijzigd door jbhc op 18-04-2015 23:12 ]

[tvwes]

Anoniem: 15758 schreef op zaterdag 18 april 2015 @ 11:52:
De 6TB Greens doen 175MB/s wat niet slecht is voor een 5400rpm-class schijf. De RE2-GP die jij bedoelt is een fysiek andere schijf volgens mijn weten; de RE-serie is fysiek anders dan de normale Greens. Maar de Greens en Reds zijn fysiek hetzelfde, op een vibratiesensor na.

Ik weet niet hoe fysiek verschillend de gewone greens en de RE2-GP van destijds zijn. Ik dacht dat die RE2-GP ook boven een lager hadden. Voor mij is het heel simpel: als de fabrikant iets spec'ed dan volg ik dat. De RE2-GP voldeden aan de mijn specs een daarmee was de kous af. Natuurlijk doet het pijn om 6 van die drives af te rekenen. Maar 6 of 7 jaar verder doet het gebrek aan gezeur de pijn van de portemonnee vergeten. Ik snap dat zo'n lange tijd met een NAS doen niet voor iedereen is. Maar zolang je niet met video aan de slag gaat kan je heel wat email, vakantie foto's, muziek, muziek, timecapsules, backups kwijt. Sommige kennissen hebben er een film NAS naast gezet.
Die 175MB/sec haal je neem ik aan alleen vooraan? Je zal niet resilveren op die snelheid

Bij lage rpm mis je natuurlijk IOps, maar voor een ZFS server met vooral grote bestanden is dat eigenlijk geen issue. Random writes doet ZFS sowieso al sequential. Dus dan gaat het om sequential read en random read. Dat eerste doen de schijven uitstekend en random reads kun je verzachten met L2ARC als dat nodig is. Het cachen van metadata is iets waar ik zelf nogal fan van ben. Dan hoeven je schijven dit ook niet meer te doen en dat scheelt al random reads zodat je schijven nog meer aan sequential read toekomen.

Eens. Zolang je maar geen NFS van vSphere krijgt. Je oplossing zometeen onderschrijf ik vanharte, een extra pool op basis ssd's voor je vm's. Het cachen van metadata is lastiger materie dan je zou vermoeden, dit in relatie tot de ARC. Mijn ervaring is dat je echt moet kijken naar de workload en dat blind metadata cachen geen goed idee is. Het is alleen geen discussie voor hier.

Kortom, WD Green is denk ik dé perfecte schijf voor ZFS servers voor thuisgebruikers, die vooral grote bestanden opslaan zoals audio/video/archives. Heb je daarnaast ook virtual machines, dan kan het lonend zijn een paar SSDs hiervoor aan te schaffen, die kun je dan voor L2ARC, sLOG, systeem/boot gebruiken alsmede voor de opslag van VM images.

Voor weinig geld heb je dan een mooie ZFS server.

Nogmaals mee eens. En vooral het opsplitsen van je zpool in twee losse zpool's en met ssd en een met disks, juich ik ontzettend toe. Je geeft de iops aan die dataset die het nodig heeft, je streams en backups kunnen met minder iops ook terecht.
Het enige wat ik niet weet, is of het het enablen van spindown voor die greens een goed idee is. Ik doe het nooit, maar mijn zpool's zijn ook altijd lekker bezig dus die zullen nooit gaan slapen. Als jouw media NAS 20 uur per dag niet gebruikt wordt dan is het een ander verhaal. Maar mijn home zpool's hosten eigenlijk altijd mail en dat gaat 24 uur per dag door, en nog wat van die continu zaken. Dan wil je niet dat als de zpool na 5 minuten slapen weer wakker wordt omdat er een mailtje komt. Dan gaat geen enkele drive het jaren volhouden.

[jbhc]

Zo langzamerhand begin ik toch een beetje terug te komen van de WD-Greens. Van de 7 die ik er afgelopen jaren ingezet heb voor een thuis-nas zijn er al 4 in meer of mindere maten overleden en dat begint nu toch wel een beetje behoorlijk irritant te worden.

Overigens was dat ook dé reden om over te stappen van raid1 naar ZFS.

[ Voor 15% gewijzigd door jbhc op 18-04-2015 23:08 ]

[tvwes]

jbhc schreef op zaterdag 18 april 2015 @ 23:06:
Zo langzamerhand begin ik toch een beetje terug te komen van de WD-Greens. Van de 7 die ik er afgelopen jaren ingezet heb voor een thuis-nas zijn er al 4 in meer of mindere maten overleden en dat begint nu toch wel een beetje irritant te worden.

Ik was even vergeten dat er consumenten en enterprise greens zijn. Ik heb alleen ervaring met de enterprise greens. Wat ik al eerder schreef ik ben er geen voorstander van om spullen in te zetten waar ze niet voor bedoeld zijn. Blijkbaar zijn die consumenten greens echt bestemd voor incidenteel gebruik en is een nas te veel gebruik voor deze dingen. Het bescheiden energie verbruik tov 7200rpm schijven was voor mij echt het argument om ze te gebruiken. Misschien omdat ik altijd de enterprise versie heb gebruikt en nooit enige vorm van energiebesparing heb geactiveerd, dat ik er jaren mee doe zonder gezeur.

[Anoniem: 15758]

jbhc schreef op zaterdag 18 april 2015 @ 23:06:
Zo langzamerhand begin ik toch een beetje terug te komen van de WD-Greens. Van de 7 die ik er afgelopen jaren ingezet heb voor een thuis-nas zijn er al 4 in meer of mindere maten overleden

Ja en een ander heeft dezelfde ervaring, maar dan met Hitachi of Seagate. Dat is nu eenmaal het grillige met statistiek en een laag aantal samples. In het casino kun je ook óf heel erg winnen óf heel erg verliezen. Je kunt alleen met enige betrouwbaarheid iets zeggen over een groot aantal samples.

Veel mensen beschouwen bad sectors of zelfs kabelfouten al als een defecte schijf; of als SMART ook maar iets aangeeft, sturen ze de schijven direct terug. Voor mij is een schijf 'stuk' als hij het helemaal niet meer doet; niet opspinnen en niet gedetecteerd worden. Een schijf met bad sectors kan prima binnen de specificatie van uBER=10^-14 vallen - kortom dan valt het aantal bad sectors binnen de marge die de fabrikant zelf opgeeft. 10^-14 komt overeen met één bad sector per dag tot één per half jaar - afhankelijk van de duty cycle. Voor consumentengebruik is eens per half jaar of enkele maanden een reële schatting.

WD Green en andere lage rpm schijven met hoge datadichtheid zijn juist enorm geschikt voor ZFS. Dit omdat ze door de hoge datadichtheid (WD Green 6TB doet 1200GB per platter) een hogere sequential speed hebben en het nadeel van hoge datadichtheid namelijk bad sectors, is vrijwel irrelevant voor ZFS. Kortom, de perfecte combinatie van goedkope hardware met slimme software. Jeff Bonwick heeft hier ook wat over gezegd; dat het hele idee van RAID vroeger was om kosten te besparen: een betrouwbare schijf creëren met goedkope hardware aangestuurd door intelligente software. Terwijl de conventionele route is om dure schijven te kopen. Dat laatste geldt nu nog voor legacy RAID oplossingen; dan wil je Enterprise-schijven hebben met uBER 10^-15 of zelfs -16. Dat is dus een factor 100 minder bad sectors. ZFS is juist precies het tegenovergestelde.

De BackBlaze-studie zou ook suggereren dat WD Green het helemaal niet slecht doet. Al moet je enorm oppassen met dit soort studies vertalen naar consumentensituaties omdat er tig factoren zijn die verschillen tussen Enterprise en consumentengebruik.

[ Voor 6% gewijzigd door Anoniem: 15758 op 18-04-2015 23:18 ]

[jbhc]

Anoniem: 15758 schreef op zaterdag 18 april 2015 @ 23:17:
[...]

Mijn samples zijn echter van verschillende batches op verschillende tijdstippen. Er zijn natuurlijk ook prima schijven. De vervangende schijf (ook een green) is volgens de smart al 2,4 jaar. Maar ik geloof niet dat ik zoveel pech heb dat juist bij mij 50% van de schijven defect gaat

En defect is bij mij niet een bad sector en zeker geen kabelfout maar een veelvoud hiervan.

Ik was even vergeten dat er consumenten en enterprise greens zijn. Ik heb alleen ervaring met de enterprise greens. Wat ik al eerder schreef ik ben er geen voorstander van om spullen in te zetten waar ze niet voor bedoeld zijn. Blijkbaar zijn die consumenten greens echt bestemd voor incidenteel gebruik en is een nas te veel gebruik voor deze dingen. Het bescheiden energie verbruik tov 7200rpm schijven was voor mij echt het argument om ze te gebruiken. Misschien omdat ik altijd de enterprise versie heb gebruikt en nooit enige vorm van energiebesparing heb geactiveerd, dat ik er jaren mee doe zonder gezeur.

Het is natuurlijk wel een beetje onzin dat die "Consumenten Greens" er alleen zijn voor incidenteel gebruik. Een thuis pc gaat ook vaak genoeg aan en uit en het is nou niet zo dat mijn nas heel veel te doen heeft. Die staat 90 van de tijd te idlen.

Overigens begreep ik van een kennis dat bij hem de enterprise schijven momenteel ook bij bosjes gingen. Ik heb dus het idee dat het bij de hd fabrikanten momenteel ook niet helemaal lekker gaat en gok dat dat iets te maken heeft met de opkomende ssd's. Ze moeten natuurlijk steeds sneller grotere schijven uitbrengen.

[ Voor 54% gewijzigd door jbhc op 18-04-2015 23:34 ]

[Anoniem: 15758]

Ja als je zo weinig schijven hebt dan kunnen die percentages wild fluctueren. Pas als je duizend schijven hebt kun je er iets over zeggen; en dan nog zijn er veel gemeenschappelijke factoren zoals hoe jij de schijven gebruikt; hoe ze zijn vervoerd, waar ze vandaan komen (batch/productie-eigenschappen/fabriek).

Dat gezegd is het natuurlijk hartstikke balen dat 4 van jouw 7 schijven al zo vroeg defect zijn. Dat is zeker een afwijkende 'score' - maar om dan gelijk de conclusie te trekken dat Greens ruk zijn, zou veel te kort door de bocht zijn. Het is ook gewoon een beetje geluk of pech hebben - dus bouw marge in wat betreft redundancy en echt belangrijke zaken backups. Dan hoeft disk failure niet zoveel uit te maken; mits dat binnen de garantieperiode gebeurt. De Backblaze-studie suggereert ook dat Greens vooral in het begin stuk gaan, en in hun 2e en 3e jaar heel stabiel zijn. Als dat klopt is dat gunstig nieuws ivm garantie.

[ikkeenjij36]

Even een update:Ik heb nu omv erop gezet en draaiend gekregen.
Ook een zfspool maken ging zonder problemen en was in no time up and running.
Misschien is zfsguru wel te moeilijk voor mij maar als de gui/livecd geen pool aan kan maken zelfs niet op een nieuwe ssd die gewoon werkt lijkt het me misschien niet alleen aan mij te liggen en mijn skils.
Misschien dat jullie alles via cli instaleren maar dan ben je volgens mij geen gebruiker van/voor zfsguru maar freebsd gebruiker.
ZO dit gezegd hebbende(moest er even uit) waardder ik toch jullie hulp/advies ten zeerste.
Groet

[FREAKJAM]

ZFSGuru werkt op basis van een ZFS on Root installatie en OMV niet. Groot verschil :-)

Bij ZFSGuru werkt je altijd met minimaal twee pools. Een voor ZFSGuru zelf en de andere pool voor je hard disks. OMV installeer je gewoon direct in jouw geval op je SSD. OMV is debian linux based, en de installatie heeft niets met ZFS van doen.

[ Voor 60% gewijzigd door FREAKJAM op 19-04-2015 15:58 ]

[Anoniem: 15758]

ZFSguru kan ook met één pool overweg. Je hoeft niet apart een systeem pool aan te maken. Soms wel handig; een multi-disk mirror van 5x 15GiB partitie. Mis je toch niet op je 3TB+ schijf.

[ikkeenjij36]

Ach ja ik wedt dat jullie allemaal veel verder in de materie zitten en er meer van weten.
Ik denk dat ik gewoon wacht met zfs en eerst even wacht op de nieuwe zfsguru.
Als daar ook het nieuwe forum draait ga ik me er weer verder mee bezig houden en kijken of het dan wel wil lukken.
Toch gek dat guru zelfs geen enkele pool kon maken zonder time out error vd server.
Ook geen losse pool voor zfsguru,ik ben dan wel zo nieuwschierig wat daar het probleem/oorzaak van kan zijn.

[Bigs]

Lekker FreeNAS gebruiken dan.. dat werkt aardig foolproof in mijn ervaring

[ikkeenjij36]

Bigs schreef op zondag 19 april 2015 @ 21:12:
Lekker FreeNAS gebruiken dan.. dat werkt aardig foolproof in mijn ervaring

Freenas heeft wmb teveel restricties vwb mijn hdd hardware.
Nu draait ie op omv en ga ik ff sparen om alle 2TB schijven te vervangen voor 4TB en ook de 3TB gaat mettertijd vervangen worden,tot dan wacht ik zfsguru nieuwe stijl af.
Dan heb ik wat te doen deze herfst als het buiten koud en nat is😊😊

[jbhc]

Àls je toch zo verschrikkelijk veel last hebt om zfsguru werkend te krijgen waarom probeer je het dan niet gewoon eens werkend te krijgen in een VM? Daar kun je naar hartelust lekker experimenteren zonder als het fout gaat helemaal opnieuw te moeten beginnen.

[tvwes]

Anoniem: 15758 schreef op zaterdag 18 april 2015 @ 23:17:
[...]

Ja en een ander heeft dezelfde ervaring, maar dan met Hitachi of Seagate. Dat is nu eenmaal het grillige met statistiek en een laag aantal samples. In het casino kun je ook óf heel erg winnen óf heel erg verliezen. Je kunt alleen met enige betrouwbaarheid iets zeggen over een groot aantal samples.

Geen commentaar.

Veel mensen beschouwen bad sectors of zelfs kabelfouten al als een defecte schijf; of als SMART ook maar iets aangeeft, sturen ze de schijven direct terug. Voor mij is een schijf 'stuk' als hij het helemaal niet meer doet; niet opspinnen en niet gedetecteerd worden. Een schijf met bad sectors kan prima binnen de specificatie van uBER=10^-14 vallen - kortom dan valt het aantal bad sectors binnen de marge die de fabrikant zelf opgeeft. 10^-14 komt overeen met één bad sector per dag tot één per half jaar - afhankelijk van de duty cycle. Voor consumentengebruik is eens per half jaar of enkele maanden een reële schatting.

Geen spelt tussen te krijgen.

WD Green en andere lage rpm schijven met hoge datadichtheid zijn juist enorm geschikt voor ZFS. Dit omdat ze door de hoge datadichtheid (WD Green 6TB doet 1200GB per platter) een hogere sequential speed hebben en het nadeel van hoge datadichtheid namelijk bad sectors, is vrijwel irrelevant voor ZFS.

Dit ben ik niet met je eens. Iedere fout is relevant, ook herstelbare fouten. Als eerste wil ik terug wijzen naar je bovenstaande paragraaf waarin je frequentie en kansen terecht noemt. ZFS kan de fout vaak herstellen zonder een complete resilver maar het kost wel wat. Maar bij je genoemde 6TB drive heb je het over een kans van .48 op een UBE bij een volle drive read. De kans op een probleem bij grote vdevs icm grote drives bij een lage betrouwbaarheid zijn vooral tijdens een resilver niet klein. De backblaze usecase is bijna een worm bij een hele lage dutycycle. Dat is niet te vergelijken met een NAS of een VM store. Dit is precies waarom er vaak kleine capaciteiten met een lage UBER worden ingezet als drive. Backblaze, coldstorage, disk-based backup zijn allemaal hele gespecialiseerde gevallen, en zijn niet algemene NAS'en.

Kortom, de perfecte combinatie van goedkope hardware met slimme software. Jeff Bonwick heeft hier ook wat over gezegd; dat het hele idee van RAID vroeger was om kosten te besparen: een betrouwbare schijf creëren met goedkope hardware aangestuurd door intelligente software. Terwijl de conventionele route is om dure schijven te kopen. Dat laatste geldt nu nog voor legacy RAID oplossingen; dan wil je Enterprise-schijven hebben met uBER 10^-15 of zelfs -16. Dat is dus een factor 100 minder bad sectors. ZFS is juist precies het tegenovergestelde.

Ik denk dat je hier het precies omkeert. RAID = RedundantArrayInexpensiveDisk's RAID was inderdaad opgezet om kosten te besparen. Maar dmv een dure controller (met niet echt hele slimme software) met goedkope schijven. De definitie van goedkoop in deze is betrekkelijk. Maar komende vanaf systemen met brede datapaden en drives met dmv extern ck gesynchroniseerde spindles die dan in een read 8x8bits leverden was raid een hele verbetering (veel lezers waren nog niet eens geboren!). Want dat waren pas echt dure opslag systemen. Later, bij de eerste raid controllers werden nog steeds spindles gesynced om de latency wat te verkorten. Vandaag de dag is dit volkomen achterhaald.
Ik denk dat ik weet welke uitspraak van Bonwick je bedoeld. Bonwick liet zien dat je dmv oa de ARC en de txg gelijkwaardige performance met ZFS zonder raid controller met 7200rpm drives kon behalen als een (dure)raid controller met (dure)10K drives. Wat Bonwick niet bedoelde dat dit een vrijbrief was om desktop drives in te zetten. Drives met een hoge UBER worden in RAID en in ZFS ingezet om hoge beschikbaarheid en betrouwbaarheid te realiseren. Het is bijv niet acceptabel als de vmware omgeving instort omdat er een rebuild aan de gang is. Liever zo min mogelijk rebuilds en als het moet zo snel mogelijk. Bij dat laatste helpen kleine snelle enterprise drives. Custom usecases als Backblaze of Amazon Glacier zijn geen goede vergelijkingen met onze thuis ZFS NAS omdat het volkomen geintegreerde oplossingen zijn.

De BackBlaze-studie zou ook suggereren dat WD Green het helemaal niet slecht doet. Al moet je enorm oppassen met dit soort studies vertalen naar consumentensituaties omdat er tig factoren zijn die verschillen tussen Enterprise en consumentengebruik.

De BackBlaze studies lieten zien dat zelfs in hun omgeving sommige drives echt onbetrouwbaar waren. Dat andere drives in hun gebruik met hun duty cycle het goed doen zegt niet over deze drives bij gebruik in een normale omgeving. Dat sommigen hier eenmalig hun NAS vol laden met media en daarna gedurende een paar uur dag er iets vanaf lezen, net als BackBlaze, komt niet overeen met algemeen gebruik. Waar de verhouding read write anders ligt.

Samenvattend:

• Nee, ik verbied niemand om desktop drives te gebruiken in z'n zpool. Toen het enkele posts terug ging over de WD greens en ik zei dat ik er goede ervaring mee had. Alleen bleek ik ervaring te hebben met oude enterprise modellen en niet de desktop modellen, beide hebben green in de naam.
• Nee, ik ben niet tegen grote drives in een ZFS pool. Maar het vereist planning als je niet al te snel je data wil verliezen.
• Sommige grote drives spec'en zelfs een maximum dutycycle van zoveel TB per jaar. Aan de onderkant van de markt (desktop) wordt dit niet gespec'ed maar geimpliceerd. Drives die bestemd zijn voor 24x7 werking zijn daarvoor gemaakt, desktop drives niet.
• moderne drives met hoge capaciteiten zijn een wonder der techniek. Dat het uberhaubt mogelijk is om van een schijf die met een paar duizend rpm nog iets terug te lezen valt bij dergelijke dichtheden is een mirakel. Mijn ervaring is dat de datadichtheid omgekeerd evenredig is met de betrouwbaarheid. Ik zie veel meer issues de afgelopen twee jaar dan daarvoor. Allemaal issues met moderne drives, oude drives niks aan de hand.
• De BackBlaze studies zijn zeer waardevol en informatief en statistisch significant. Echter hun gebruik, de pod eenmalig volschrijven en daarna af en toe lezen, is niet representief voor de NAS sector. Sommige tweakers hier met hun media servers hebben een gelijkwaardig gebruik. Maar er zijn ook tweakers die er vm's op draaien en weet ik wat nog meer.

[HyperBart]

tvwes schreef op maandag 20 april 2015 @ 00:23:
• Nee, ik ben niet tegen grote drives in een ZFS pool. Maar het vereist planning als je niet al te snel je data wil verliezen.

Kan je hier even dieper op ingaan? Vind het namelijke reuze-interessant en uit persoonlijke paranoia (die me het nu waard is, daarvoor vond ik het relatief gezien te duur) ga ik nu ook een hoger niveau van redundantie (RAIDZ2) implementeren, omdat ik met de overstap van 5 naar 10 disks van 4TB niet het risico wil lopen (zeker als je de "badkuipcurve" van failures van disks in het achterhoofd houdt, een ongeluk komt nooit alleen maw) op data-verlies. Dit is uiteraard maar in een basale setup van een stel hobbyisten,wat bedoel je specifiek met die planning? Een setup zoals velen van ons hier, of richtte je je theorieën vooral op enterprise omgevingen?

[ Voor 11% gewijzigd door HyperBart op 20-04-2015 00:52 ]

[GioStyle]

Als jij je huidige pool wil upgraden, dan kan je er ook voor kiezen om een nieuwe vdev aan je pool toe te voegen. Echter is dat niet verstandig omdat je dan een soort raid50 (2x 5x 4TB raidz1) krijgt. Verstandiger is om je pool te verwijderen en er 1 vdev van maken: 10x 4TB raidz2. Dan heb je meer redundantie, maar dat vereist wel planning, want je huidige pool zal je moeten verwijderen.

[tvwes]

Jack Flushell schreef op maandag 20 april 2015 @ 19:27:
Ik ben nu 2 weken aan het inlezen over ZFS en het kernwoord is: Angst. Ik heb het idee dat een harddisk "uberhaupt" niet meer veilig is en de kans op falen 150%.

HyperBart schreef op maandag 20 april 2015 @ 00:49:
[...]

Kan je hier even dieper op ingaan? Vind het namelijke reuze-interessant en uit persoonlijke paranoia (die me het nu waard is, daarvoor vond ik het relatief gezien te duur) ga ik nu ook een hoger niveau van redundantie (RAIDZ2) implementeren, omdat ik met de overstap van 5 naar 10 disks van 4TB niet het risico wil lopen (zeker als je de "badkuipcurve" van failures van disks in het achterhoofd houdt, een ongeluk komt nooit alleen maw) op data-verlies. Dit is uiteraard maar in een basale setup van een stel hobbyisten,wat bedoel je specifiek met die planning? Een setup zoals velen van ons hier, of richtte je je theorieën vooral op enterprise omgevingen?

Eerst de "open deur", "de dooddoener", maar wel waar:

Betrouwbaar , Prestatie, Goedkoop

je kan er altijd maar twee van drie hebben. Kies maar.

Onderstaand artikel is niet compleet en laat overwegingen, technieken en criteria weg die in de enterprise markt van toepassing zijn. Het is gericht op de SOHO gebruiker en niet voor TIER-1 en 2 storage inkoper op admin. Mochten er opmerkingen voor zover relevant voor de doelgroep dan hoor ik dat natuurlijk graag.

Laat niemand zich nu schrik aanjagen door onderstaand artikel. Het is geschreven op verzoek. Harddisken zijn van 0.1 Gigabit/ vierkante inch in 1990 naar 10 Gb/sq. in. naar 1200 Gb/sq. in. gegaan tegelijk met hogere toerentallen en doorvoersnelheden en zeer lage prijzen. Terwijl de betrouwbaarheid de afgelopen tien jaar op papier niet is verbeterd en de afgelopen jaren misschien wel is verslechterd.
ZFS kan je helpen om toch een betrouwbare opslag te realiseren ondanks dat de harddisken niet echt betrouwbaar zijn. Het vereist wel wat planning. Onderstaand artikel probeert daarin wat ondersteuning te bieden. Veel lees plezier.

Ook bij het inrichten van je zpool en schijf model selectie moeten wederom afwegingen gemaakt worden:

• netto opslag vs MTTDL
• Kosten vs MTTDL
• Resilver prioriteit tov reguliere io's

Factoren die van invloed zijn

• De opslag grootte van de schijf
• IOPS van de schijf
• UBER van de schijf (niet echt van belang maar enige "officiele" houvast mbt tot betrouwbaarheid)
• MTBF van de schijf (niet echt van belang maar enige "officiele" houvast mbt tot betrouwbaarheid)
• zpool layout en vdev grootte
• De onderliggende data (kleine of grote files)
• De belasting van het systeem
• Model schijf, is de schijf bestemd voor jouw workload?
• De bedrijfscondities van de schijven (hitte, vibratie)
• Hoe oud zijn de schijven?
• Zijn het schijven uit een batch?
• Zijn de schijven vervoerd buiten hun spec's? Oftewel heeft Michael Jordan jouw paketje met schijven in het busje gedunkt?
• backplanes, kabels en hba's kunnen ook fouten veroorzaken of falen maar dat laat ik hier buitenbeschouwing.

Wat ik bedoel met planning is dat je eigenlijk al deze zaken mee moet nemen in je beslissing voor een opslag systeem. Deze lijst ziet misschien wat overweldigend uit maar ik zal proberen wat praktische handvaten aan te reiken om hier toch uit te komen.

Laten we eerst naar een enkele disk kijken. Hier zijn twee failure modes: een UBE of device fault. Bij de device fault is de complete disk kaput, bijv de motor of controller. Het is duidelijk dat je alles kwijt bent. Maar waarom? Was de schijf qua levensduur aan het begin of einde van de badkuip curve? Wat het een slechte batch of model (bijv Deathstar)? Had de schijf transportschade? Was de schijf veel te warm geworden?
"Wat maakt het uit? Alles is weg, toch?" Ja, maar waarom stopte die schijf uitgerekend nu? Want als jij een rijtje van deze schijven in je RAIDZx stopt en ze stoppen allemaal tegelijk dan ben je ondanks je redundancy toch alles kwijt.
Bovengeschetste uitval is lastig te quantificeren. Toch valt het risico met wat planning wel te verminderen, maar later daarover meer.
De fabrikant specificeert een UBER van 10^14 bij low end / consumenten schijven en 10^15 of zelfs 10^16 bij enterprise schijven. Dit betekent gemiddeld 1 foute gelezen bit per UBER gelezen bits. Bij een schijf met een UBER van 10^14 is dat een UBE per 12.5TB gelezen data. Dus als je een twee keer een 6TB helemaal leest is de kans op een UBE niet zo klein meer. Het is geen garantie dat na 12.5TB aan gelezen data je een UBE krijgt. De fabrikant specced alleen dat de kans niet groter is dan 1 op 10^14. Ook moet alleen de gebruikte data in beschouwing worden genomen, niet de bruto opslag capaciteit van de schijf. Als je maar een byte in gebruikt hebt op je schijf een je zou die altijd vanaf media lezen dan zou je dat 12.5 * 10^12 keer kunnen doen voordat je een UBE tegenkomt. Dus een grote lege schijf is wat dat betreft hetzelfde als een kleine volle schijf.
Al zou je de UBE tegen komen bij een enkele schijf met een ZFS erop dan nog is alles niet verloren. Van sommige essentiele data zijn standaard meerdere copieen aanwezig. Je zal waarschijnlijk een file verliezen maar niet zomaar de zpool. Ook hier heeft ZFS nog een optie voor, namelijk zfs set copies=2 [fs] Je gaat dan ook van je data copieen maken. Kom je nu een UBE tegen dan probeer je de andere kopie. Ja, je schijf halveert in netto cappaciteit.

Na wat achtergrond informatie, nu naar de zpool layout. Ik begin met een zpool met een enkele vdev. Er zijn mirror1,mirror2, RAIDZ1, RAIDZ3, RAIDZ3 vdevs. Naast de echte mirror(1) met een enkele pariteit schijf ondersteunt ZFS ook mirror's met twee pariteit schijven. Bij RAIDZn kan je n schijven van p (p>n+1) schijven verliezen zonder gegevens verlies.
De mirror vs RAIDZ afweging is een van performance samen met MTTDL vs opslag capaciteit. Een mirror vdev levert 2 of 3 maal het aantal IOPS van een enkele schijf bij lezen, de reads worden gestriped. Bij een RAIDZ vdev levert worst case het aantal iops van een enkele schijf. Bij streaming reads van een RAIDZ vdev is het minder erg, maar de IOPS en performance schaalt niet zo als bij mirrors.
Omdat de kansen onvoorwaardelijk zijn is de kans min of meer linear met het aantal disks in een vdev. Je hebt een bijv 4x zo grootte kans bij 20 schijven in een enkel RAIDZ1 vdev dan bij 4 RAIDZ1 vdevs met elk 5 schijven.
De keuze van type vdev is een afweging van MTTDL vs netto opslag.

Nu de fysieke schijf. Het ene model is niet het andere. Soms brengt een fabrikant een ramp model uit, een deathstar of die barracuda 7200.11. Maar hoe kom je hier achter? Het korte antwoord is: NIET. Wij hebben simpel weg geen toegang tot de QA van de fabrikant en niet genoeg vergelijkings materiaal om hier uitspraken over te doen. Wat bij de een jaren zonder probleem werkt gaat bij de ander na een half jaar stuk. Dit zijn kansen. Het enige wat iets van houvast bied zijn de BlackBlaze harddisk betrouwbaarheids cijfers. Ja, het zijn statistisch significante samples per model. Mijn bezwaar tegen deze cijfers is dat BlackBlaze een zeer specifieke workload heeft. De schijf wordt eenmalig volgeschreven en daarna incidenteel gelezen. Dat is een specifieke workload, voor diegene hier die eenmalig zijn NAS vol schrijft met films en daarna een uurtje wat per dag een filmpje eraf streamt. Is het zeker waardevol, maar algemeen gebruik is het niet. De betrouwbaarheids cijfers zouden er heel anders uit kunnen zien bij een andere (lees jouw!) workload.
Naast selectie op basis van ervaring zijn er nog enkele zaken die in overweging genomen kunnen worden.
Als eerste de beroemde TLER/ERC of hoe de fabrikant het ook noemt, de tijd die een schijf besteed aan het proberen een lees fout te voorkomen door het opnieuw en opnieuw en .. te lezen. Als dit de enige schijf is dan is het buitengewoon vriendelijk van je schijf dat het je data probeert te redden. Dat dit tijd kost zal je op dat moment weinig kunnen schelen. In je ZFS NAS tijdens normaal bedrijf kan het van vervelend (je film stream hapert/stopt) tot onacceptabel in druk belaste bedrijfsomgeving. Maar op zich geen probleem. Anders is het tijdens resilveren. Op dat moment heb je minder redundancy. Doel is zo snel mogelijk weer de extra redundancy te verkrijgen. Anders gezegd het venster van verminderde bescherming dient zo kort mogelijk te zijn. Als tijdens het resilveren door gebrek aan TLER je minuut per sector aan het proberen bent ipv de normale 14-16 milliseconden dan kan het resilver proces van een lange tijd veranderen in een bijna eeuwigheid. Nogmaals het is geen fout maar het duurt langer. En al die tijd heb je verminderde bescherming en des te langer het duurt des te groter de kans dat zich een probleem met een volgende schijf zich voordoet. Als je schijf aan het proberen gaat is dat vaak niet een enkele sector maar een heel gebied met ellende.
De volgende feature wil ik illustreren aan de hand van deze classic: Shouting in the Datacenter Vibratie is een niet te verwaarlozen factor. Nu is schreeuwen niet hetzelfde als resonantie maar de gevolgen zijn hetzelfde, de schijf heeft moeite om te tracken. Letwel het gaat om de Rotational Vibration Sensors niet om de valbeveiliging sensor die de koppen intrekt bij een val. Weer is het ontbreken van de vibratie compensatie op zich geen probleem maar het kan de performance tijdens bedrijf alsmede de resilver tijd negatief beinvloeden.
Nu wat subjectieve factoren. "Het waren allemaal schijven uit een batch" Ik denk niet dat er maandag ochtend batches zijn. Fabrikage is een volledige geautomatiseerd proces. Kwaliteits verschillen tussen exemplaren zullen klein zijn. Wat wel kan is dat een doos tijdens transport is gevallen. De doos passeert een aantal partijen voordat hij bij jouw komt. De bulkverpakking van de fabrikant is vaak erg goed. Maar jij krijgt zelfden je schijven in zo'n goede verpakking gelevert. Met pech schuift alles op de bodem van een dun kartonnen doosje. Het grootste risico zit in de handling en transport van de winkel, paket dienst naar jouw toe. Jij koopt 8 drives bij een winkel en daar falen er snel een paar van wordt dan als "slechte batch" bestempeld. Terwijl de drives eigenlijk prima waren.
Temperatuur is ook subjectief. Weer een classic is deze Google study Daaruit bleek dat hoge temperaturen pas vanaf jaar 2 voor een hogere uitval zorgen. Koeling en airflow kunnen nooit kwaad. Te hoge temperaturen zijn niet goed.
Iets wat ik niet kan onderbouwen met externe cijfers maar wel vermoed is dat met het toenoemen van de capaciteit van de schijfen de complexiteit en gevoeligheid is toegenomen en de betrouwbaarheid is afgenomen. Ik zie veel meer uitval de laatste twee jaar dan daarvoor. Vroeger konden goede modellen jaren mee. Ik zie dat bij de nieuwste generaties niet terug, terwijl ze de dezelfde betrouwbaarheids specificaties hebben als modellen van enkele jaren terug.
Tot slot deelt de fabrikant schijven niet voor niets op in segmenten. Als de fabrikant meent dat een bepaald model bestemd is voor een desktop en jij gaat die toch in een ZFS array opnemen en dan 24x7 gebruiken dan ben je daar natuurlijk vrij in. Maar als jij het allemaal zo goed weet wat doe je dan hier op tweakers?
Het kiezen van een bepaald model is ook weer een afweging. Wil je een model met meer features of hogere betrouwbaarheid dan betaal je daarvoor.

Tot slot de resilver tijd. Ieder moment dat je zpool in degraded toestand is loop je een risico. Naarmate deze toestand langer aanhoud zal het risico op data verlies toenemen. De duur van de degraded toestand hangt af van een aantal factoren.

• Wanneer begint de resilver actie? Dit wordt bepaald door het moment dat de vervangende schijf beschikbaar komt. En eventuele actie van de admin, soms moet de resilver handmatig gestart worden.
• Hoeveel data moet er geresilverd worden?
• Wat voor soort data moet er geresilverd worden?
• Hoeveel prioriteit krijgt het resilver proces?

Voor een mirror vdev is de resilver tijd behoorlijk gecorreleerd met de snelheid van de schijf en de te resilveren hoeveelheid data. Het is niet zo simpel dat je de tijd kan uitrekenen door de hoeveelheid te resilveren data delen door de gemiddelde snelheid van de schijf. Maar als je een factor toepast komt het grotendeels wel overeen. Mirror vdevs resilveren het snelste, vooral bij druk belaste zpools en de load is veel lager.
Voor een RAIDZ vdev is het wat lastiger te verspellen hoe lang de resilver gaat duren. Het hangt af van de ZFS implementatie, soort data, aantal schijven in het RAIDZ vdev en de zpool load. Maar het kan tussen een paar MB/sec en de gem. snelheid van de nieuwe schijf liggen.
Als je 4TB aan data met 30MB/sec moet resilveren dan kost dat zo'n 36 uur. Al die tijd is het vdev (alle schijven) heel druk. Geen io's is weinig risico maar continu io's is wel een risico. Lange rebuild tijden zijn niet goed voor je MTTDL. Niet alleen de duur maar ook de stress van de continue io's verhogen het risico behoorlijk.

Samenvattend:
Mag je 6TB schijven gebruiken in je zpool? Alles mag.
Is het handig om in een bestelling 6 desktop schijven te kopen van 6TB die door een slam dunkende paket bezorger te laten bezorgen. Vervolgens een zpool te maken met een enkel RAIDZ1 vdev van deze schijven op een mobo met slechts 6 sata poorten. Vervolgens dit snel helemaal vol te copieren met data. Om na deze geslaagde build even met vakantie te gaan. Dat lijkt mij een minder goed plan.

Iedereen moet voor zichzelf uitmaken wat voor schijven en zpool layout hij wil.

Wel heb ik enkele tips en best-practices

• Probeer schijven fysiek af te halen.
• Als het om veel schijven gaat probeer bij verschillende winkels of met enig interval te kopen.
• Gebruik bij drives groter dan 1TB minimaal RAIDZ2 (bij voldoende drives in je vdev)
• Voor efficient gebruik van de ruimte; gebruik dan voldoende schijven in je vdev.
• Meer schijven in een vdev is een hoger risico; splits het vdev of gebruik een betere RAIDZ
• Heb je meerdere vdevs, probeer dan als het even kan een hotspare toe te voegen. Kost wat, maar de schijf slijt niet. Als je weg bent loop je veel minder risico. Bij zes sata poorten is dat misschien wat veel van het goede maar de mensen met bijv 24+bays kunnen eigenlijk niet zonder. Het je een enkel RAIDZ1 of RAIDZ2 vdev kan je ipv de hotspare beter je RAIDZ met 1 verhogen.
• Als je geen hotspare kan of wil plaatsen zorg dan dat je een coldspare hebt liggen. Dat niet op het moment zelf je nog weken moet wachten op een vervanging omdat er een fabriek in Thailand was overstroomd.
• Als er schijf niet volledige defect is maar wel fouten geeft, voeg dan de vervangende schijf toe. Je hebt dan ook nog informatie van de oude schijf.
• Probeer het wisselen en/of toevoegen van een schijf als het maar even kan op een live systeem te doen. Dus niet uitzettten maar eerst de zpool weer in een gezonde toestand brengen. Is dat lastig? Overweeg dan een beter chassis. Het hoeft geen fancy chassis te zijn met echte drive caddies, maar wel zo dat je de schijven eruit kan schroeven of klikken.
• Test je resilver proces. Schrijf je hele zpool vol met realistische data. Dat mogen gedeeltelijk best copieen zijn. Trek een schijf eruit. Meet wat erover blijf van je performance. Misschien is de performance wel zo slecht geworden dat je niet meer naar je stream kan kijken. Pak je coldspare en start het resilver proces. En meet hoelang het duurt, meet de load, test of je nog voldoende preformance overhoud voor je workload.
• Om de badkuip curve tegen te gaan kan je de vdevs over langere tijd plaatsen. Niet in een keer 4 vdevs maar pas als de eerste 60 procent vol is schijven voor de volgende kopen. "Maar .. onbalans..." Je kan een of twee schijven per eerder gemaakt vdev vervangen door je nieuwe schijven. Die nieuwe schijven hebben zich nog niet bewezen maar de rest je bestaande vdevs wel. Door wat nieuwe en oude in een juiste verhouding te mengen kan je hier iets tegen doen. Maar het vereist wel een redelijk aantal schijven voordat het werkt. De onbalans kan je oplossen door de files te herschrijven of door een locale send en receive te doen. YMV. En als een enkel vdev voor jouw genoeg is qua performance dan zou ik me geen zorgen maken over de onbalans. Dit is een procedure voor de liefhebber
• Alle enterprise schijven, ECC memory, RAIDZ3 vdevs bij elkaar zijn nooit zo betrouwbaar als een (offsite) backup. Als bijv je voeding raar doet en een flink overspanning op al je schijven zet ben je nergens met al je mooie spullen

Niks moet (behalve de backup)

Het spijt me dat ik niet een aantal hapklare recepten kan geven maar dat als je bovenstaand verhaal het gelezen en begrepen snap je dat er niet 1 oplossing is. Het is maatwerk. Wel zal ik proberen een beter beeld te krijgen van de verschillende workloads hier en dan kunnen we kijken of we misschien wel enkele aanbevelingen kunnen doen. Ook al betwijfel ik of dat zin heeft. De wensen en budgetten zijn daarvoor te verschillend. Ook zal ik de komende tijd proberen wat performance data te verzamelen om resilver tijden te illustreren.

edit 2 Nav CurlyMo heb ik het hotspare advies aangepast..

[ Voor 8% gewijzigd door tvwes op 20-04-2015 20:56 ]

[Jack Flushell]

[slightly offtopic]
Ik ben nu 2 weken aan het inlezen over ZFS en het kernwoord is: Angst. Ik heb het idee dat een harddisk "uberhaupt" niet meer veilig is en de kans op falen 150% tenzij je 18 schijven in RAIDZ3 plaatst. Dan is de kans nog maar 145% dat je al je data verliest. Jeui 5 % winst.

[ Voor 30% gewijzigd door Jack Flushell op 20-04-2015 19:28 ]

[GioStyle]

Jack Flushell schreef op maandag 20 april 2015 @ 19:27:
[slightly offtopic]
Ik ben nu 2 weken aan het inlezen over ZFS en het kernwoord is: Angst. Ik heb het idee dat een harddisk "uberhaupt" niet meer veilig is en de kans op falen 150% tenzij je 18 schijven in RAIDZ3 plaatst. Dan is de kans nog maar 145% dat je al je data verliest. Jeui 5 % winst.

ZFS is juist enorm betrouwbaar in meerdere opzichten, mits je het goed toepast.

[tvwes]

Jack Flushell schreef op maandag 20 april 2015 @ 19:27:
[slightly offtopic]
Ik ben nu 2 weken aan het inlezen over ZFS en het kernwoord is: Angst. Ik heb het idee dat een harddisk "uberhaupt" niet meer veilig is en de kans op falen 150% tenzij je 18 schijven in RAIDZ3 plaatst. Dan is de kans nog maar 145% dat je al je data verliest. Jeui 5 % winst.

Don't Panic

Lees de inleiding van mijn artikel hierboven nog even. Als je kan opgeven wat je wensen zijn, hoeveel sata poorten, waar gebruik je het voor etc dan zijn er genoeg mensen die je een goed advies kunnen geven. Met een klein beetje planning kan je jaren vooruit.

[CurlyMo]

Mooi verhaal, alleen twijfel ik over je hot-spare advies. Naar mijn idee kan je beter van een 10 RAIDZ2 pool + hot-spare een 11 RAIDZ3 pool maken. Een hot-spare helpt je geen enkele manier mee met het veilig stellen van data totdat hij in de pool daadwerkelijk data bevat. In een RAIDZ3 zorgt de hot-spare wel ten alle tijden voor extra redundantie.

[tvwes]

CurlyMo schreef op maandag 20 april 2015 @ 20:35:
Mooi verhaal, alleen twijfel ik over je hot-spare advies. Naar mijn idee kan je beter van een 10 RAIDZ2 pool + hot-spare een 11 RAIDZ3 pool maken. Een hot-spare helpt je geen enkele manier mee met het veilig stellen van data totdat hij in de pool daadwerkelijk data bevat. In een RAIDZ3 zorgt de hot-spare wel ten alle tijden voor extra redundantie.

Goed punt. De enige zpool waar ik aan werk met een enkel vdev is de root / boot zpool. Ik werk nooit aan een zpool met een enkel vdev. Maar je hebt helemaal gelijk bij een enkel vdev kan je bij RAIDZ1 of RAIDZ2 beter de hotspare als extra pariteit toevoegen. Dat is betrouwbaarder, het kost wel meer energie en de disk slijt. Bij meerdere RAIDZ vdevs zijn een of enkele hotspares wel de aangewezen route.

Ik zal mijn artikel aanpassen, bedankt.

[ikkeenjij36]

jbhc schreef op zondag 19 april 2015 @ 23:22:
Àls je toch zo verschrikkelijk veel last hebt om zfsguru werkend te krijgen waarom probeer je het dan niet gewoon eens werkend te krijgen in een VM? Daar kun je naar hartelust lekker experimenteren zonder als het fout gaat helemaal opnieuw te moeten beginnen.

Al eens gedaan op mn w7 laptop.
werkte gewoon.
Ook guru gewoon werkend gehad op de server maar door experimenteer(probeersels) gong t niet helemaal goef.
Ook het gebeuren dat de apps/services niet makkelijk te updaten zijn is iets wat ik niet fijn vindt/vond bv. sabnzbd loopt al 2 versies achter.
Misschien ligt ook gewoon aan mij/mijn hardware.
Ik wacht het nu maar gewoon af hoe de nieuwe versie wordt.
Dan eerst maar goed inlezen op het nieuwe forum hoe te gaan gebruiken,of mijn hardware goed genoeg is,of mijn skills goed genoeg zijn?
Omv had ik in een half uur draaien met een zfspool erop.
Xpenology draait ook goed erop en daar kon/kan ik de config files aanpassen om meer als 12 disks te gebruiken ipv de max 12 die gewoon is op/in een 3615.
Ligt aan mijn skills?
Misschien maar waarom wil er geen pool aangemaakt worden op een 850evo die nieuw uit doos is.
Ik hoop dat ik niemand beledig maar als vrij nieuwe zfs/guru/unix/linux gebruiker denk ik dat ik redelijk veel voor elkaar gekregen heb maar niet zoveel kennis heb als sommige hier.
Mijn doel is een redelijk veilige server te maken.
Die ik volledig als media storage/server en dl bak wil gebruiken.
Ik dacht dat zfsguru het os voor mij was maar waarschijnlijk niet dus wat ik best jammer vindt.
Omdat zfs toch het veiligste is imho voor de toekomst.
Ok ik heb mijn belangrijkste dingen zoals foto's/doccumenten/formulieren ook op een externe disk backup staan maar het zou fijn zijn als dat ook op de server kan staan zodat mijn vrouw er ook makkelijk bij kan als ik onderweg voor werk ben.
Voor goedbedoeld commentaar/advies stond en sta ik altijd open,ook per pm natuurlijk.

[Jack Flushell]

tvwes schreef op maandag 20 april 2015 @ 20:20:
[...]


Don't Panic

Lees de inleiding van mijn artikel hierboven nog even. Als je kan opgeven wat je wensen zijn, hoeveel sata poorten, waar gebruik je het voor etc dan zijn er genoeg mensen die je een goed advies kunnen geven. Met een klein beetje planning kan je jaren vooruit.

Goed advies . Het was een beetje een onderbuik gevoel mijn eerdere post.

Mijn gear:
- HP Proliant MicroServer Gen8 G1610T
- 3x WD Red SATA 6 Gb/s WD20EFRX, 2TB
- 8 GB ECC geheugen: Crucial CT2KIT51272BA186DJ (2x 4GB)

Het systeem moet een NAS systeem worden met minimaal 4 GB bruikbare opslag.
Ik wil er evt ook een extra website (lichtgewicht en eenvoudig) op draaien (naast de webinterface van ZFSguru). Mijn thuisnetwerk is 1Gbps. Mijn ervaringen met ZFSguru de afgelopen weken waren goed op een VM. Ik heb van alles gebrobeerd (FreeNAS, NAS4Free, OpenBSD), maar mijn keuze is gevallen op ZFSguru.


Ik heb nog 1 bay over, nog een WD Red 2GB kopen om de laatste bay te vullen?
Ik wilde in eerste instantie op drie disks RAIDZ1 gaan draaien en ZFSguru gaan booten vanaf een USB-stick of vanaf een SSD (dus vanaf 1 disk / RAID0). Ik krijg echter het idee dat RAIDZ1 ongeveer hetzelfde is als bungee jumpen met PTT-elastiek en minimaal moet gaan voor RAIDZ2. Dat kan met 4 disks wel, maar overal wordt minimaal 5 aangeraden en zoveel bays heb ik niet...

Tips, gedachten?

[ Voor 6% gewijzigd door Jack Flushell op 20-04-2015 21:05 ]

[HyperBart]

Grappig dat je die setup net wilt
V&A aangeboden: HP Proliant MicroServer Gen8 G1610T + 6,5TB

[HyperBart]

tvwes schreef op maandag 20 april 2015 @ 20:43:
[...]


Goed punt. De enige zpool waar ik aan werk met een enkel vdev is de root / boot zpool. Ik werk nooit aan een zpool met een enkel vdev. Maar je hebt helemaal gelijk bij een enkel vdev kan je bij RAIDZ1 of RAIDZ2 beter de hotspare als extra pariteit toevoegen. Dat is betrouwbaarder, het kost wel meer energie en de disk slijt. Bij meerdere RAIDZ vdevs zijn een of enkele hotspares wel de aangewezen route.

Ik zal mijn artikel aanpassen, bedankt.

In welke mate zorgt het toevoegen van meerdere VDEV's in één pool eigenlijk voor meer veiligheid? Qua onderbuik-gevoel lijkt me het hebben van 3 x RAIDZ1 bestaande uit 5 x 4TB toch niet veiliger dan dan 15 x 4TB in RAIDZ3?

Ik ben het wel met je eens dat bij meerdere VDEV's een hotspare als shared potential resource wel beter is.

[tvwes]

Jack Flushell schreef op maandag 20 april 2015 @ 20:59:
[...]


Goed advies . Het was een beetje een onderbuik gevoel mijn eerdere post.

Mijn gear:
- HP Proliant MicroServer Gen8 G1610T
- 3x WD Red SATA 6 Gb/s WD20EFRX, 2TB
- 8 GB ECC geheugen: Crucial CT2KIT51272BA186DJ (2x 4GB)

Het systeem moet een NAS systeem worden met minimaal 2 GB bruikbare opslag.
Ik wil er evt ook een extra website (lichtgewicht en eenvoudig) op draaien (naast de webinterface van ZFSguru). Mijn thuisnetwerk is 1Gbps. Mijn ervaringen met ZFSguru de afgelopen weken waren goed op een VM. Ik heb van alles gebrobeerd (FreeNAS, NAS4Free, OpenBSD), maar mijn keuze is gevallen op ZFSguru.


Ik heb nog 1 bay over, nog een WD Red 2GB kopen om de laatste bay te vullen?
Ik wilde in eerste instantie op drie disks RAIDZ1 gaan draaien en ZFSguru gaan booten vanaf een USB-stick of vanaf een SSD (dus vanaf 1 disk / RAID0).

Tips, gedachten?

Goed om eerst wat dingen uit te proberen. Voor de rest lijkt het me prima, goed systeem, ECC, goede schijven. Ik zou die extra bay voorlopig leeglaten en een externe 3 of 4 TB USB disk kopen. Dan kan je met ZFS send en receive backups maken.
Met je RAIDZ1 uit 3 schijven met 1 vrije poort zijn er verschillende upgrade scenarios mogelijk. Het toevoegen van de hotspare sluit die upgrade niet uit want kan de hotspare zo weghalen.

[tvwes]

HyperBart schreef op maandag 20 april 2015 @ 21:06:
[...]

In welke mate zorgt het toevoegen van meerdere VDEV's in één pool eigenlijk voor meer veiligheid? Qua onderbuik-gevoel lijkt me het hebben van 3 x RAIDZ1 bestaande uit 5 x 4TB toch niet veiliger dan dan 15 x 4TB in RAIDZ3?

Ik ben het wel met je eens dat bij meerdere VDEV's een hotspare als shared potential resource wel beter is.

Dat klopt, de MTTDL van de zpool als geheel is zo goed als die van het vdev met de laagste MTTDL. Dus het opsplitsen van een RAIDZ3 vdev in meerdere RAIDZ1 vdevs leidt tot een (erge) verslechtering van de MTTDL. Maar de io prestaties nemen toe en je resilver tijd neemt af.
Betrouwbaar , Prestatie, Goedkoop Kies maar twee.
Toch denk ik dat hier tussen in ook nog wel wat te vinden is. Bijv 2 RAIDZ2 vdevs met ieder 7 schijven en 1 hotspare is ook een prima combinatie. Net wat meer iops net wat kortere resilver en redelijke MTTDL.

Als voor jouw workload een enkel RAIDZ3 vdev voldoende performance geeft. Dan levert dat je het meeste opslag bij de hoogste betrouwbaarheid. Verwacht bijvoorbeeld niet dat dit een fijne VMware datastore gaat worden.

Voordat je een NAS in gebruik neem probeer de verschillende vdevs uit. "Gaat de film stream haperen als ik tegelijk een backup van mijn laptop maak?" "Welke compressie voor welke data?" Testen testen testen pas dan ben je aan het tweaken , leer je wat en weet je het onderste uit de kan te wringen.

Nu voordat iedereen gaat ROEPEN: "neee je mag niet 7 drives in een RAIDZ2 vdev plaatsen"

"JAAA dat mag wel" en kids I'm a trained professional.

Lees even dit artikel van een nog grotere professional.
Die (oude) adviezen over optimale vdev samenstellingen hebben alleen betrekking op zeer specifieke use cases. (zie artikel)
De vertaling van de samenvatting van het artikel uit de link:
Gebruik raidz. Stop niet te veel schijven in een vdev. Zet compressie aan.

[Kortfragje]

Zelf ook te kijken, what about:

-6*6TB in RaidZ2

-12*2TB in RaidZ2

Die laatste kan misschien beter in 2 vdev's?

[FREAKJAM]

ikkeenjij36 schreef op maandag 20 april 2015 @ 20:52:
[...]

Klein advies: Geef geen enter na elke zin die je tikt op dit forum. Ik vind het onprettig om je posts op deze manier te lezen. (je mag me een zeurpiet noemen als je wilt trouwens )

2de advies: Als OMV nu lekker draait en je hebt dat in een half uur werkend, waarom dan nog overstappen? Never change a winning team! Leuk weetje trouwens (al vaker gemeld in dit topic): De ontwikkelaar achter OMV is de oorspronkelijke ontwikkelaar achter FreeNAS. Zo "slecht" is OMV dus niet. Het is dat een jaar terug de ontwikkeling best traag verliep en dat het vrij lang duurde eerdat een nieuwe OMV was uitgebracht op basis van Debian Wheezy (en natuurlijk nog geen ZFS-ondersteuning), anders had ik OMV nu waarschijnlijk ook gedraaid in VMWare.

[ Voor 96% gewijzigd door FREAKJAM op 20-04-2015 23:57 ]

[ikkeenjij36]

FREAKJAM schreef op maandag 20 april 2015 @ 23:46:
[...]


Klein advies: Geef geen enter na elke zin die je tikt op dit forum. Ik vind het onprettig om je posts op deze manier te lezen. (je mag me een zeurpiet noemen als je wilt trouwens )

2de advies: Als OMV nu lekker draait en je hebt dat in een half uur werkend, waarom dan nog overstappen? Never change a winning team! Leuk weetje trouwens (al vaker gemeld in dit topic): De ontwikkelaar achter OMV is de oorspronkelijke ontwikkelaar achter FreeNAS. Zo "slecht" is OMV dus niet. Het is dat een jaar terug de ontwikkeling best traag verliep en dat het vrij lang duurde eerdat een nieuwe OMV was uitgebracht op basis van Debian Wheezy (en natuurlijk nog geen ZFS-ondersteuning), anders had ik OMV nu waarschijnlijk ook gedraaid in VMWare.

Ok ik zal mijn best doen.Dan toch nog een klein vraagje want ik ben toch een beetje eigenwijs.
Als straks de nwe versie van zfsguru uit is wil ik het toch nog een keer proberen.Wat is dan jouw advies in vetrekking tot mijn hdd's om de beste pools te maken?Dus 9x2TB schijven 1x4TB en 1x3TB en dan nog 1x60GB ssd ocz vertex3 en 1x120GB ssd samsung 850evo.
En dan is het gebruik dus media storage en server en dan misschien nog wat kleine dingen zoals een mailserver erbij omdat upc/ziggo erg veel mail problemen veroorzaakt bij mij.

[FireDrunk]

Allereerst: Mooi stukje! Ik ben het echt op heeeeel veel vlakken met je eens, en met een paar kleine aanpassingen mag dit van mij in de topic start, maar toch wil ik je graag uitnodigen om een paar dingen uit te leggen, want ik kan vooral de conclusie die je uit bepaalde onderdelen trekt niet volgen. Zie het alsjeblieft niet als een aanval, maar meer om een nederige vraag om verduidelijking.

tvwes schreef op maandag 20 april 2015 @ 19:09:
Eerst de "open deur", "de dooddoener", maar wel waar:

Betrouwbaar , Prestatie, Goedkoop

je kan er altijd maar twee van drie hebben. Kies maar.

Onderstaand artikel is niet compleet en laat overwegingen, technieken en criteria weg die in de enterprise markt van toepassing zijn. Het is gericht op de SOHO gebruiker en niet voor TIER-1 en 2 storage inkoper op admin. Mochten er opmerkingen voor zover relevant voor de doelgroep dan hoor ik dat natuurlijk graag.

Laat niemand zich nu schrik aanjagen door onderstaand artikel. Het is geschreven op verzoek. Harddisken zijn van 0.1 Gigabit/ vierkante inch in 1990 naar 10 Gb/sq. in. naar 1200 Gb/sq. in. gegaan tegelijk met hogere toerentallen en doorvoersnelheden en zeer lage prijzen. Terwijl de betrouwbaarheid de afgelopen tien jaar op papier niet is verbeterd en de afgelopen jaren misschien wel is verslechterd.
ZFS kan je helpen om toch een betrouwbare opslag te realiseren ondanks dat de harddisken niet echt betrouwbaar zijn. Het vereist wel wat planning. Onderstaand artikel probeert daarin wat ondersteuning te bieden. Veel lees plezier.

Ook bij het inrichten van je zpool en schijf model selectie moeten wederom afwegingen gemaakt worden:

• netto opslag vs MTTDL
• Kosten vs MTTDL
• Resilver prioriteit tov reguliere io's

Factoren die van invloed zijn

• De opslag grootte van de schijf
• IOPS van de schijf
• UBER van de schijf (niet echt van belang maar enige "officiele" houvast mbt tot betrouwbaarheid)
• MTBF van de schijf (niet echt van belang maar enige "officiele" houvast mbt tot betrouwbaarheid)
• zpool layout en vdev grootte
• De onderliggende data (kleine of grote files)
• De belasting van het systeem
• Model schijf, is de schijf bestemd voor jouw workload?
• De bedrijfscondities van de schijven (hitte, vibratie)
• Hoe oud zijn de schijven?
• Zijn het schijven uit een batch?
• Zijn de schijven vervoerd buiten hun spec's? Oftewel heeft Michael Jordan jouw paketje met schijven in het busje gedunkt?
• backplanes, kabels en hba's kunnen ook fouten veroorzaken of falen maar dat laat ik hier buitenbeschouwing.

Wat ik bedoel met planning is dat je eigenlijk al deze zaken mee moet nemen in je beslissing voor een opslag systeem. Deze lijst ziet misschien wat overweldigend uit maar ik zal proberen wat praktische handvaten aan te reiken om hier toch uit te komen.

Laten we eerst naar een enkele disk kijken. Hier zijn twee failure modes: een UBE of device fault. Bij de device fault is de complete disk kaput, bijv de motor of controller. Het is duidelijk dat je alles kwijt bent. Maar waarom? Was de schijf qua levensduur aan het begin of einde van de badkuip curve? Wat het een slechte batch of model (bijv Deathstar)? Had de schijf transportschade? Was de schijf veel te warm geworden?
"Wat maakt het uit? Alles is weg, toch?" Ja, maar waarom stopte die schijf uitgerekend nu? Want als jij een rijtje van deze schijven in je RAIDZx stopt en ze stoppen allemaal tegelijk dan ben je ondanks je redundancy toch alles kwijt.
Bovengeschetste uitval is lastig te quantificeren. Toch valt het risico met wat planning wel te verminderen, maar later daarover meer.
De fabrikant specificeert een UBER van 10^14 bij low end / consumenten schijven en 10^15 of zelfs 10^16 bij enterprise schijven. Dit betekent gemiddeld 1 foute gelezen bit per UBER gelezen bits. Bij een schijf met een UBER van 10^14 is dat een UBE per 12.5TB gelezen data. Dus als je een twee keer een 6TB helemaal leest is de kans op een UBE niet zo klein meer. Het is geen garantie dat na 12.5TB aan gelezen data je een UBE krijgt. De fabrikant specced alleen dat de kans niet groter is dan 1 op 10^14. Ook moet alleen de gebruikte data in beschouwing worden genomen, niet de bruto opslag capaciteit van de schijf. Als je maar een byte in gebruikt hebt op je schijf een je zou die altijd vanaf media lezen dan zou je dat 12.5 * 10^12 keer kunnen doen voordat je een UBE tegenkomt. Dus een grote lege schijf is wat dat betreft hetzelfde als een kleine volle schijf.

Dit vraag ik mij af. Dit zou betekenen dat een error te maken heeft met tijd en kans, en 0,0 met de disk zelf. Dat is volgens mij niet zo. Een UBER heeft ook te maken met sectoren die bijvoorbeeld lang niet gelezen zijn, en waarvan de elektrische lading lager is.

De conclusie die jij trekt, dat je 12.5* meer kan lezen bij een (vrijwel) lege schijf, kan ik dus moeilijk geloven. Als je maar 1 sector beschreven hebt, maar daarna die sector 10 jaar niet aanraakt, en daarna pas weer leest, denk ik dat het risico op een UBER toch redelijk significant is.

Harde cijfers hierover zijn er uiteraard niet, dus het is en blijft speculeren.

Al zou je de UBE tegen komen bij een enkele schijf met een ZFS erop dan nog is alles niet verloren. Van sommige essentiele data zijn standaard meerdere copieen aanwezig. Je zal waarschijnlijk een file verliezen maar niet zomaar de zpool. Ook hier heeft ZFS nog een optie voor, namelijk zfs set copies=2 [fs] Je gaat dan ook van je data copieen maken. Kom je nu een UBE tegen dan probeer je de andere kopie. Ja, je schijf halveert in netto cappaciteit.

Na wat achtergrond informatie, nu naar de zpool layout. Ik begin met een zpool met een enkele vdev. Er zijn mirror1,mirror2, RAIDZ1, RAIDZ3, RAIDZ3 vdevs. Naast de echte mirror(1) met een enkele pariteit schijf ondersteunt ZFS ook mirror's met twee pariteit schijven. Bij RAIDZn kan je n schijven van p (p>n+1) schijven verliezen zonder gegevens verlies.
De mirror vs RAIDZ afweging is een van performance samen met MTTDL vs opslag capaciteit. Een mirror vdev levert 2 of 3 maal het aantal IOPS van een enkele schijf bij lezen, de reads worden gestriped. Bij een RAIDZ vdev levert worst case het aantal iops van een enkele schijf. Bij streaming reads van een RAIDZ vdev is het minder erg, maar de IOPS en performance schaalt niet zo als bij mirrors.
Omdat de kansen onvoorwaardelijk zijn is de kans min of meer linear met het aantal disks in een vdev. Je hebt een bijv 4x zo grootte kans bij 20 schijven in een enkel RAIDZ1 vdev dan bij 4 RAIDZ1 vdevs met elk 5 schijven.
De keuze van type vdev is een afweging van MTTDL vs netto opslag.

Nu de fysieke schijf. Het ene model is niet het andere. Soms brengt een fabrikant een ramp model uit, een deathstar of die barracuda 7200.11. Maar hoe kom je hier achter? Het korte antwoord is: NIET. Wij hebben simpel weg geen toegang tot de QA van de fabrikant en niet genoeg vergelijkings materiaal om hier uitspraken over te doen. Wat bij de een jaren zonder probleem werkt gaat bij de ander na een half jaar stuk. Dit zijn kansen. Het enige wat iets van houvast bied zijn de BlackBlaze harddisk betrouwbaarheids cijfers. Ja, het zijn statistisch significante samples per model. Mijn bezwaar tegen deze cijfers is dat BlackBlaze een zeer specifieke workload heeft. De schijf wordt eenmalig volgeschreven en daarna incidenteel gelezen. Dat is een specifieke workload, voor diegene hier die eenmalig zijn NAS vol schrijft met films en daarna een uurtje wat per dag een filmpje eraf streamt. Is het zeker waardevol, maar algemeen gebruik is het niet. De betrouwbaarheids cijfers zouden er heel anders uit kunnen zien bij een andere (lees jouw!) workload.
Naast selectie op basis van ervaring zijn er nog enkele zaken die in overweging genomen kunnen worden.
Als eerste de beroemde TLER/ERC of hoe de fabrikant het ook noemt, de tijd die een schijf besteed aan het proberen een lees fout te voorkomen door het opnieuw en opnieuw en .. te lezen. Als dit de enige schijf is dan is het buitengewoon vriendelijk van je schijf dat het je data probeert te redden. Dat dit tijd kost zal je op dat moment weinig kunnen schelen. In je ZFS NAS tijdens normaal bedrijf kan het van vervelend (je film stream hapert/stopt) tot onacceptabel in druk belaste bedrijfsomgeving. Maar op zich geen probleem. Anders is het tijdens resilveren. Op dat moment heb je minder redundancy. Doel is zo snel mogelijk weer de extra redundancy te verkrijgen. Anders gezegd het venster van verminderde bescherming dient zo kort mogelijk te zijn. Als tijdens het resilveren door gebrek aan TLER je minuut per sector aan het proberen bent ipv de normale 14-16 milliseconden dan kan het resilver proces van een lange tijd veranderen in een bijna eeuwigheid. Nogmaals het is geen fout maar het duurt langer. En al die tijd heb je verminderde bescherming en des te langer het duurt des te groter de kans dat zich een probleem met een volgende schijf zich voordoet. Als je schijf aan het proberen gaat is dat vaak niet een enkele sector maar een heel gebied met ellende.
De volgende feature wil ik illustreren aan de hand van deze classic: Shouting in the Datacenter Vibratie is een niet te verwaarlozen factor. Nu is schreeuwen niet hetzelfde als resonantie maar de gevolgen zijn hetzelfde, de schijf heeft moeite om te tracken. Letwel het gaat om de Rotational Vibration Sensors niet om de valbeveiliging sensor die de koppen intrekt bij een val. Weer is het ontbreken van de vibratie compensatie op zich geen probleem maar het kan de performance tijdens bedrijf alsmede de resilver tijd negatief beinvloeden.
Nu wat subjectieve factoren. "Het waren allemaal schijven uit een batch" Ik denk niet dat er maandag ochtend batches zijn. Fabrikage is een volledige geautomatiseerd proces. Kwaliteits verschillen tussen exemplaren zullen klein zijn. Wat wel kan is dat een doos tijdens transport is gevallen. De doos passeert een aantal partijen voordat hij bij jouw komt. De bulkverpakking van de fabrikant is vaak erg goed. Maar jij krijgt zelfden je schijven in zo'n goede verpakking gelevert. Met pech schuift alles op de bodem van een dun kartonnen doosje. Het grootste risico zit in de handling en transport van de winkel, paket dienst naar jouw toe. Jij koopt 8 drives bij een winkel en daar falen er snel een paar van wordt dan als "slechte batch" bestempeld. Terwijl de drives eigenlijk prima waren.

Ook hier heb ik mijn vragen bij. Een schijf met een goed geparkeerde kop kan volgens mij 150-250 g hebben. Nou is mijn wiskunde erg gedateerd (lees: 10 jaar oud), maar dat is niet niks. Het is ook niet dat je het ding met 160KM/h tegen de grond aan kan gooien, maar van een beetje hobbelen in karton zou het ding niet stuk moeten gaan.

Nogmaals: het is geen aanval, meer een geval van: Ik denk dat het subjectief is, en dat jouw ervaringen voor je spreken. Persoonlijk heb ik namelijk nog nooit een kapotte disk gezien vanwege transport. En als dat wel zo is, moet je even met je postbode praten denk ik, want dan gaat hij er slechter mee om dan een blok beton

Temperatuur is ook subjectief. Weer een classic is deze Google study Daaruit bleek dat hoge temperaturen pas vanaf jaar 2 voor een hogere uitval zorgen. Koeling en airflow kunnen nooit kwaad. Te hoge temperaturen zijn niet goed.
Iets wat ik niet kan onderbouwen met externe cijfers maar wel vermoed is dat met het toenoemen van de capaciteit van de schijfen de complexiteit en gevoeligheid is toegenomen en de betrouwbaarheid is afgenomen. Ik zie veel meer uitval de laatste twee jaar dan daarvoor. Vroeger konden goede modellen jaren mee. Ik zie dat bij de nieuwste generaties niet terug, terwijl ze de dezelfde betrouwbaarheids specificaties hebben als modellen van enkele jaren terug.
Tot slot deelt de fabrikant schijven niet voor niets op in segmenten. Als de fabrikant meent dat een bepaald model bestemd is voor een desktop en jij gaat die toch in een ZFS array opnemen en dan 24x7 gebruiken dan ben je daar natuurlijk vrij in. Maar als jij het allemaal zo goed weet wat doe je dan hier op tweakers?

Hier heb je in veel gevalen gelijk in, maar er is 1 maar, en dat is: marketing.
Bedrijven verkopen features in naam vanwege geld, niet omdat ze zogenaamd echt nodig zijn.
Ja, de echte top schijven zoals de Hitachi Ultrastars zijn echt wel beter dan de Western Digital Blue's (Enterprise SAS / Fibre Channel even buiten beschouwing gelaten).

Maar het verschil tussen de Western Digital RED en GREEN's is alleen TLER Firmware en Garantie.

Dat wil niet zeggen dat je ongelijk hebt, maar het is van mij uit meer een kanttekening om goed te kijken waar je voor kiest, en niet blind kijkt naar het label Enterprise.

Het kiezen van een bepaald model is ook weer een afweging. Wil je een model met meer features of hogere betrouwbaarheid dan betaal je daarvoor.

Tot slot de resilver tijd. Ieder moment dat je zpool in degraded toestand is loop je een risico. Naarmate deze toestand langer aanhoud zal het risico op data verlies toenemen. De duur van de degraded toestand hangt af van een aantal factoren.

• Wanneer begint de resilver actie? Dit wordt bepaald door het moment dat de vervangende schijf beschikbaar komt. En eventuele actie van de admin, soms moet de resilver handmatig gestart worden.
• Hoeveel data moet er geresilverd worden?
• Wat voor soort data moet er geresilverd worden?
• Hoeveel prioriteit krijgt het resilver proces?

Voor een mirror vdev is de resilver tijd behoorlijk gecorreleerd met de snelheid van de schijf en de te resilveren hoeveelheid data. Het is niet zo simpel dat je de tijd kan uitrekenen door de hoeveelheid te resilveren data delen door de gemiddelde snelheid van de schijf. Maar als je een factor toepast komt het grotendeels wel overeen. Mirror vdevs resilveren het snelste, vooral bij druk belaste zpools en de load is veel lager.
Voor een RAIDZ vdev is het wat lastiger te verspellen hoe lang de resilver gaat duren. Het hangt af van de ZFS implementatie, soort data, aantal schijven in het RAIDZ vdev en de zpool load. Maar het kan tussen een paar MB/sec en de gem. snelheid van de nieuwe schijf liggen.
Als je 4TB aan data met 30MB/sec moet resilveren dan kost dat zo'n 36 uur. Al die tijd is het vdev (alle schijven) heel druk. Geen io's is weinig risico maar continu io's is wel een risico. Lange rebuild tijden zijn niet goed voor je MTTDL. Niet alleen de duur maar ook de stress van de continue io's verhogen het risico behoorlijk.

Heb je een bron waarin staat dat een schijf die het druk heeft sneller slijt dan een schijf die niets doet? Ik moet daar namelijk nog harde cijfers van zien. Niet dat het theoretisch gezien raar is, maar ik heb er gewoon nog geen harde cijfers over gezien...

Samenvattend:
Mag je 6TB schijven gebruiken in je zpool? Alles mag.
Is het handig om in een bestelling 6 desktop schijven te kopen van 6TB die door een slam dunkende paket bezorger te laten bezorgen. Vervolgens een zpool te maken met een enkel RAIDZ1 vdev van deze schijven op een mobo met slechts 6 sata poorten. Vervolgens dit snel helemaal vol te copieren met data. Om na deze geslaagde build even met vakantie te gaan. Dat lijkt mij een minder goed plan.

Iedereen moet voor zichzelf uitmaken wat voor schijven en zpool layout hij wil.

Wel heb ik enkele tips en best-practices
[list]
• Probeer schijven fysiek af te halen.
• Als het om veel schijven gaat probeer bij verschillende winkels of met enig interval te kopen.
• Gebruik bij drives groter dan 1TB minimaal RAIDZ2 (bij voldoende drives in je vdev)
• Voor efficient gebruik van de ruimte; gebruik dan voldoende schijven in je vdev.
• Meer schijven in een vdev is een hoger risico; splits het vdev of gebruik een betere RAIDZ

Op zich is de quote in beginsel waar, maar meerdere VDEV's gebruiken is een *nog* hoger risico... Ik zou liever zien dat je dan 2 pools maakt. Dat is administratief minder handig (maar zeker niet onmogelijk om hetzelfde te bereiken), maar veiliger omdat je ipv een RAID0+RAIDZ array maakt, maar 2 losse RAIDZ array's. Daarvan is de kans lager dat je al je data verliest.

• Heb je meerdere vdevs, probeer dan als het even kan een hotspare toe te voegen. Kost wat, maar de schijf slijt niet. Als je weg bent loop je veel minder risico. Bij zes sata poorten is dat misschien wat veel van het goede maar de mensen met bijv 24+bays kunnen eigenlijk niet zonder. Het je een enkel RAIDZ1 of RAIDZ2 vdev kan je ipv de hotspare beter je RAIDZ met 1 verhogen.
• Als je geen hotspare kan of wil plaatsen zorg dan dat je een coldspare hebt liggen. Dat niet op het moment zelf je nog weken moet wachten op een vervanging omdat er een fabriek in Thailand was overstroomd.

Voor de gemiddelde gebruiker hier, is dat een hele dure optie... Een Coldspare kost je al snel ~100-140 euro (voor een 4-6TB schijf). Daarvoor heb je ook onbeperkte online backup per jaar.
Dus mits je internetverbinding het niet toestaat, zou ik liever zien dat mensen een fatsoenlijke backup regelen. Dan maakt het een stuk minder uit dat je disk er een dag of twee langer over doet.

• Als er schijf niet volledige defect is maar wel fouten geeft, voeg dan de vervangende schijf toe. Je hebt dan ook nog informatie van de oude schijf.
• Probeer het wisselen en/of toevoegen van een schijf als het maar even kan op een live systeem te doen. Dus niet uitzettten maar eerst de zpool weer in een gezonde toestand brengen. Is dat lastig? Overweeg dan een beter chassis. Het hoeft geen fancy chassis te zijn met echte drive caddies, maar wel zo dat je de schijven eruit kan schroeven of klikken.
• Test je resilver proces. Schrijf je hele zpool vol met realistische data. Dat mogen gedeeltelijk best copieen zijn. Trek een schijf eruit. Meet wat erover blijf van je performance. Misschien is de performance wel zo slecht geworden dat je niet meer naar je stream kan kijken. Pak je coldspare en start het resilver proces. En meet hoelang het duurt, meet de load, test of je nog voldoende preformance overhoud voor je workload.
• Om de badkuip curve tegen te gaan kan je de vdevs over langere tijd plaatsen. Niet in een keer 4 vdevs maar pas als de eerste 60 procent vol is schijven voor de volgende kopen. "Maar .. onbalans..." Je kan een of twee schijven per eerder gemaakt vdev vervangen door je nieuwe schijven. Die nieuwe schijven hebben zich nog niet bewezen maar de rest je bestaande vdevs wel. Door wat nieuwe en oude in een juiste verhouding te mengen kan je hier iets tegen doen. Maar het vereist wel een redelijk aantal schijven voordat het werkt. De onbalans kan je oplossen door de files te herschrijven of door een locale send en receive te doen. YMV. En als een enkel vdev voor jouw genoeg is qua performance dan zou ik me geen zorgen maken over de onbalans. Dit is een procedure voor de liefhebber

Ik vind persoonlijk dat je hier wel heel makkelijk over doet. Het mixen van ongebalanceerde VDEV's is haast een wetenschap op zich. ZFS gaat namelijk zorgen dat de VDEV's tegelijkertijd vol raken. Je nieuwe VDEV gaat dus veel meer IO te verduren krijgen. Je plaatst dus een ongetest VDEV naast een goed VDEV om vervolgens al je data op het nieuwe VDEV geschreven te zien worden. Faalt dat VDEV ben je *al* je data kwijt...

• Alle enterprise schijven, ECC memory, RAIDZ3 vdevs bij elkaar zijn nooit zo betrouwbaar als een (offsite) backup. Als bijv je voeding raar doet en een flink overspanning op al je schijven zet ben je nergens met al je mooie spullen
[/list]

Niks moet (behalve de backup)

Het spijt me dat ik niet een aantal hapklare recepten kan geven maar dat als je bovenstaand verhaal het gelezen en begrepen snap je dat er niet 1 oplossing is. Het is maatwerk. Wel zal ik proberen een beter beeld te krijgen van de verschillende workloads hier en dan kunnen we kijken of we misschien wel enkele aanbevelingen kunnen doen. Ook al betwijfel ik of dat zin heeft. De wensen en budgetten zijn daarvoor te verschillend. Ook zal ik de komende tijd proberen wat performance data te verzamelen om resilver tijden te illustreren.

edit 2 Nav CurlyMo heb ik het hotspare advies aangepast..

[FREAKJAM]

ikkeenjij36 schreef op dinsdag 21 april 2015 @ 07:27:
[...]

Ok ik zal mijn best doen.Dan toch nog een klein vraagje want ik ben toch een beetje eigenwijs.
Als straks de nwe versie van zfsguru uit is wil ik het toch nog een keer proberen.Wat is dan jouw advies in vetrekking tot mijn hdd's om de beste pools te maken?Dus 9x2TB schijven 1x4TB en 1x3TB en dan nog 1x60GB ssd ocz vertex3 en 1x120GB ssd samsung 850evo.
En dan is het gebruik dus media storage en server en dan misschien nog wat kleine dingen zoals een mailserver erbij omdat upc/ziggo erg veel mail problemen veroorzaakt bij mij.

Beetje eigenwijs? Je bent super eigenwijs. Bovendien heb je exact dezelfde vraag afgelopen week ook al gesteld en toen is daar gewoon netjes antwoord op gegeven. Ik zou lekker OMV blijven draaien als ik jou was.

[dcm360]

FireDrunk schreef op dinsdag 21 april 2015 @ 08:42:
[...]

Dit vraag ik mij af. Dit zou betekenen dat een error te maken heeft met tijd en kans, en 0,0 met de disk zelf. Dat is volgens mij niet zo. Een UBER heeft ook te maken met sectoren die bijvoorbeeld lang niet gelezen zijn, en waarvan de elektrische lading lager is.

De conclusie die jij trekt, dat je 12.5* meer kan lezen bij een (vrijwel) lege schijf, kan ik dus moeilijk geloven. Als je maar 1 sector beschreven hebt, maar daarna die sector 10 jaar niet aanraakt, en daarna pas weer leest, denk ik dat het risico op een UBER toch redelijk significant is.

Harde cijfers hierover zijn er uiteraard niet, dus het is en blijft speculeren.

Ik vermoed dat je een 10^14 (deze is als je zoveel bits hebt 12.5TB) en 10^12 (deze is als je zoveel bytes hebt een TB) aan het verwarren bent, aangezien hij aangeeft dat de kans hetzelfde blijft.

Om er verder op in te haken, denk ik overigens dat dezelfde byte heel vaak lezen betrouwbaarder is (als ik de cache op de schijf nog even negeer), aangezien de schijf dan 12.5 maal 10^12 keer kan bepalen of de byte nog leesbaar is, en waar nodig de sector te herschrijven of vervangen. 'Schade' aan de data kan dus eerder worden vastgesteld dan in de situatie dat je nog steeds dezelfde hoeveelheid bytes leest, maar een specifieke byte grofweg een factor 10^12 minder vaak,

[FireDrunk]

Hoe kom je bij die 12.5 *?

De specificatie van 10^12 of 10^14 is toch niet gerelateerd aan de grootte van de schijf? Die is toch gerelateerd aan de hoeveelheid die je leest? Dus of de schijf nou 1, 10 of 100TB groot is, de hoeveelheid fouten die hij maakt blijft gelijk...

(Dit gaat over de specificatie, niet over de significatie van het getal zelf. Technisch gezien wordt die foutspecificatie hoger omdat een grotere schijf een hogere datadichtheid met zich meebrengt. Als ik het heb over 1, 10 of 100TB heb ik het dus over eenzelfde Gb/inch, maar een fysiek grotere schijf dus.)

[dcm360]

Die 12.5 komt uit het stuk van tvwes...

[tvwes]

dcm360 schreef op dinsdag 21 april 2015 @ 11:43:
Die 12.5 komt uit het stuk van tvwes...

Het was FireDrunk schreef op dinsdag 21 april 2015 @ 08:42 die "12.5*" schreef, niet ik. Dit is wat ik schreef:

De fabrikant specificeert een UBER van 10^14 bij low end / consumenten schijven en 10^15 of zelfs 10^16 bij enterprise schijven. Dit betekent gemiddeld 1 foute gelezen bit per UBER gelezen bits. Bij een schijf met een UBER van 10^14 is dat een UBE per 12.5TB gelezen data. Dus als je een twee keer een 6TB helemaal leest is de kans op een UBE niet zo klein meer. Het is geen garantie dat na 12.5TB aan gelezen data je een UBE krijgt. De fabrikant specced alleen dat de kans niet groter is dan 1 op 10^14.

De eenheid UBER is een kans per hoeveelheid gelezen BITS. Als je het omrekend kom je uit op een kans van 1 UBE per 12.5 teraBYTE aan gelezen data.
@dcm360, mijn voorbeeld van 12.5*10^12 keer diezelfde byte lezen was natuurlijk absurd. Mijn latere stelling dat het niet uitmaakt of je nu een volle of een lege schijf hebt voor de kans op een UBE blijf ik nog steeds achter staan.
De UBER spec zegt niets over leespatronen, verspreiding van data op de schijf etc. Het zegt alleen dat je een kans hebt van zoveel bij zoveel gelezen data ongeacht waar die vandaan komt. Sterker nog, de JEDEC maakt dit ook expliciet. Zij definieren de UBER inclusief alle caches en error correctie, dus pas als de data het device verlaat.
Wij weten niet wat er binnenin gebeurt en ik hoef dat ook niet te weten. Het enige wat ik kan doen is vragen om de data op lba x te geven aan mij. Hoe de harddisk dat doet is geen zorg voor mij. Waar binnen in de harddisk UBE uiteindelijk optreed hoef ik niet te weten. (Het zou informatief zijn dat wel) Pas bij de sata of sas interface krijg ik dit te horen. En precies daar zegt de UBER iets over, er is een bepaalde kans per zoveel gelezen bits op een UBE.

Mocht er nog opmerkingen zijn, let dan goed op wat je er bij haalt. Ik deed alleen een uitspraak op basis van de UBER spec van de fabrikant. Koffie tafel theorieen genoeg maar daar neem dan ik geen genoegen mee. Dan wil ik echt bewijzen zien. Ik heb niet meer informatie dan de specificaties van de fabrikant. Hierna zal je al snel toegang moeten hebben tot werking van de firmware en uitkomsten van experimenten en testen. Dit zijn nu net de kroonjuwelen van de fabrikant, ik denk niet dat iemand dat snel zal kunnen produceren laat begrijpelijk uitleggen. Want harddisken met een dichtheid van 1000Gbit/vierkant inch vandaag de dag zijn echt hele complexe wondertjes der techniek. En niet iets wat je qua complexiteit moet onderschatten. Ik overschat mijn kennis zeker niet en hou het bij de zaken die ik zeker weet zoals de UBER en niet de interne werking van de harddisk.

Verder ben ik nog bezig met het beantwoorden een post van @Firedrunk