Het grote ZFS topic

[]Byte[]

FireDrunk schreef op maandag 06 januari 2014 @ 23:26:
Zvol stuk?

Ramdisk?

PS.
Tnx voor de trigger.
Het lijkt er op dat 1 van de disken (da9) aan het overlijden is.
Een scrub van de hdd_pool1 zit nu op bijna 25%:

code:

Scrub   scrub in progress since Mon Jan 6 23:34:32 2014
456G scanned out of 1.82T at 226M/s, 1h46m to go
23.5M repaired, 24.48% done

in de /var/log/messages veel meldingen als:

code:

Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(16). CDB: 88 00 00 00 00 01 d1 c0 ac 10 00 00 00 10 00 00 length 8192 SMID 495 terminated ioc 804b scsi 0 state 0 xfer 0
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(16). CDB: 88 00 00 00 00 01 d1 c0 ae 10 00 00 00 10 00 00 length 8192 SMID 542 terminated ioc 804b scsi 0 state 0 xfer 0
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(10). CDB: 28 00 0f 03 b8 a0 00 00 68 00 length 53248 SMID 86 terminated ioc 804b scsi 0 state 0 xfer 0
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(10). CDB: 28 00 0f 03 c4 38 00 00 e8 00 length 118784 SMID 984 terminated ioc 804b scsi 0 state 0 xfer 0
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(10). CDB: 28 00 0f 03 c5 20 00 00 e8 00 length 118784 SMID 371 terminated ioc 804b scsi 0 state 0 xfer 0
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(10). CDB: 28 00 0f 03 c6 10 00 00 a0 00 length 81920 SMID 757 terminated ioc 804b scsi 0 state 0 xfer 0
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(10). CDB: 28 00 66 6c 0b 40 00 00 08 00 length 4096 SMID 893 terminated ioc 804b scsi 0 state 0 xfer 0
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(10). CDB: 28 00 19 ee 3d c0 00 00 18 00 length 12288 SMID 848 terminated ioc 804b scsi 0 state 0 xfer 0
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(10). CDB: 28 00 63 37 8d c8 00 00 18 00 length 12288 SMID 777 terminated ioc 804b scsi 0 state 0 xfer 0
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): READ(10). CDB: 28 00 0f 03 b7 b8 00 00 e8 00 
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): CAM status: SCSI Status Error
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): SCSI status: Check Condition
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): Info: 0xf03b7c8
Jan  7 00:01:10 zfsguru kernel: (da9:mps1:0:9:0): Error 5, Unretryable error

en SMART...

code:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   199   199   051    Pre-fail  Always       -       205
  3 Spin_Up_Time            0x0027   170   170   021    Pre-fail  Always       -       8475
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       43
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1432
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       41
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       40
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       2466
194 Temperature_Celsius     0x0022   131   116   000    Old_age   Always       -       21
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

[ Voor 95% gewijzigd door ]Byte[ op 07-01-2014 00:11 ]

[PuijkeN]

FireDrunk schreef op zondag 05 januari 2014 @ 09:53:
Bekijk de daadwerkelijke load inderdaad eens met zpool iostat -v 1 1. Dan zie je vrij snel wat er gebeurt.
Mocht je heel veel 'breathing' zien, kan je de txg_timeout eens naar 1 seconde zetten, dat helpt vaak.

mkroes schreef op zondag 05 januari 2014 @ 19:55:
[...]


Wat FireDrunk zegt.. Denk dat je geheugen vol loopt omdat de schijven het niet bij kunnen houden.
Heb zelf ook Ubuntu met ZFS on Linux virtueel draaien (op hyper-v nog wel) maar deze trekt constant de Gigabit verbinding vol.

Bedankt! Ik heb nog geen tijd gehad om dit even na te kijken maar ga dit deze week zeker eens doen. Het is een Vmware VM op Windows 8 dat ik draai. De files van de drie vdisks die ik gebruik voor mijn pool staan echter wel op drie aparte harde schijven. De VM zelf draait vanaf een 4de harde schijf...

Is het dan realistisch dat de schijven niet mee komen? Een Windows kopie tussen interne schijven levert gewoon 130-140 MB/s op. Het zijn WD 3TB ERZX schijven.

In ieder geval probeer ik deze week nog wat extra testen, ik ga ook even aan de slag met ZFSGuru en FreeBSD zelf. De server moet ook een Plex Media server draaien en blijkt dat deze ondertussen ook op FreeBSD kan geïnstalleerd worden. Kan dus een meevaller zijn want dan is er gelijk een deftige interface beschikbaar voor het beheer van het storage gedeelte.

[Verwijderd]

Plex zit in ZFSguru als service, dus kun je eenvoudig installeren. Heb je volgens mij wel de nieuwe 10.0 voor nodig. Staat allemaal op de site.

[MikeVM]

@CiPHER
hoe kan je de FreeBSD updaten in ZFSGURU, kan dit remote? zijn hier risicos aan verbonden?

[CU2morO]

Ik snap nog niet precies het verschil en nut van het aanmaken van verschillende filesystems binnen een zpool. Heb nu 4x4TB in RAIDZ gezet met zpool create en 'tank' genoemd (zoals vele tutorials doen).

Hier binnen met zfs create een filesystem tank/media aangemaakt waar ik straks mijn media files wil opslaan, etc.

Als ik nu ook workstation backups, privé data en databases voor media server / couchpotato wil opslaan is het dan handig om hier met zfs create een aparte filesystem voor aan te maken, of zou ik gewoon één filesystem 'media' moeten blijven gebruiken en hierbinnen subdirs aanmaken?

[Verwijderd]

@MikeVM
In ZFSguru kun je via de web-interface het systeem updaten simpelweg door een nieuwe installatie te doen. Dit kan terwijl je draait van een installatie op dezelfde pool, dat bijt elkaar niet. Pas bij het herstarten boot je in je nieuwe installatie.

Risico van remote updaten kan zijn dat de nieuwe installatie niet wilt booten. Daarnaast mist ZFSguru op dit moment nog de Migration functionaliteit, waardoor je je instellingen makkelijk kunt meenemen naar een nieuwe installatie.

@CU2morO
Je kunt ZFS filesystems zien als speciale directories die meer kunnen dan normale subdirectories. Zo kun je compressie en andere instellingen regelen met filesystems. Denk aan documenten die sterke compressie krijgen en extra bescherming, en bulkdata waar dat niet voor geldt. Kortom, filesystems zorgen dat je onderscheid kan aanbrengen in je data.

In sommige gevallen is het echter fijn om het gewoon bij één filesystem te houden. Zo moet je weten dat een verstand verplaatsen van het ene naar het andere filesystem, in feite kopiëren+verwijderen betekent, waarmee ik bedoel dat het tijd kost om de bestanden naar een ander filesystem te verplaatsen; dat gaat niet middels een verwijzing.

ZFSguru maakt bijvoorbeeld een 'share' filesystem aan zodat je 'tank/share' hebt in het begin om bestanden mee te delen. Ik raad altijd wel aan dat je van het hoofdfilesystem ('tank') afblijft. Altijd lekker in filesystems werken.

[FireDrunk]

@]Byte[, Een ramdisk is weg na een reboot natuurlijk Die moet je helemaal opnieuw aanmaken en koppelen.

[]Byte[]

FireDrunk schreef op dinsdag 07 januari 2014 @ 08:33:
@]Byte[, Een ramdisk is weg na een reboot natuurlijk Die moet je helemaal opnieuw aanmaken en koppelen.

Misschien ken je die reclame van IBM van heel vroeger... "Of je stopt de stekker er in!"
Het mag duidelijk zijn dat je die na een reboot uiteraard wel weer moet aanmaken.
Dat was dusdanig voor de hand dat ik dit maar achterwege had gelaten. Ook doordat je 'm al zag in de 'camcontrol devlist -l'

[FireDrunk]

Ik denk dat je daarna die disk ook weer opnieuw moet publiceren. Het Serial ID is immers veranderd.

[]Byte[]

Welk commando heb ik dan over het hoofd gezien?
Ik dacht dat ik ze allemaal gehad had.

Het is toch de:

code:

[root@zfsguru ~]# ctladm startup
(7:0:0:0): <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device 
(7:0:0:0):  LUN is now online
(7:0:0:1): <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device 
(7:0:0:1):  LUN is now online

[DXaroth]

@CiPHER: Wat is trouwens de redenatie geweest om ZFSGuru een compleet OS te zijn; tov enkel een front-end om zfs te beheren op een systeem?

[mkools24]

Hallo luitjes,

Ik wil een Plex media server op gaan zetten op basis van FreeBSD en ZFS. Daar heb ik nieuwe hardware voor aangeschaft en colocatie voor gehuurd bij Evoswitch (aangezien ik al m'n maten en familie ook wil aansluiten) maar dat is momenteel helemaal uit de hand gelopen kun je gerust zeggen.

Ik heb dus een belachelijke zwaar overpowered machine aangeschaft en ik ben benieuwd wat jullie vinden van mijn config. Ik zoek een goede balans tussen beschikbare schijfruimte en redundancy.

De meeste hardware komt van azerty, hier zie je een handig overzichtje:

http://azerty.nl/winkelma...=10&product%5B656218%5D=2

Dit alles gaat draaien op een jawel, 10 gigabit link bij Evoswitch in Haarlem (Die Intel 10G kaart komt er dus ook nog bij )

Hoe dan ook, ik heb dus 10 x 4 TB en 128 GB RAM Hoe zouden jullie dit inzetten?

Ik dacht zelf aan een Raidz2, dus dan ben ik mn array pas kwijt als de 3e disk uitvalt maar met 10 disken is dit misschien toch net te weinig. Het is wel aanlokkelijk dat ik dan 32 TB netto storage heb dus voorlopig hoef ik dan niks meer te wissen alleen zodra er één schijf uitklapt kan ik gelijk gaan rijden en het rebuilden duurt waarschijnlijk dagen dus bestaat er nog steeds risico dat er meer uitvalt.

Ik zou dus liever een Z3 hebben, netto 28 TB en er mogen 3 schijven uitvallen voor ik degraded ben, alleen wil ik dit niet met 10 schijven ivm de perfomance impact en het ruimteverleis zoals beschreven in de OP, maar 11 schijven past nou eenmaal niet in die server.

Volgens mij, alle opties overwegen is Z2 dus de beste optie qua netto ruimte, redundancy en perfomance, wat denken jullie?

Een andere vraag is of het met zoveel RAM nog zin heeft om een SSD disk in te zetten voor caching? Je kan vast al wel raden dat het om bestanden gaat van vele gigabytes, 15 - 30 GB zeg maar.

Ik wil Netflix 5.0 gaan maken voor privé gebruik

Thx!

[DXaroth]

Ik denk dat een z3 wellicht wat overdreven is, als je meer dan 2 disks hebt die binnen 3 dagen uitvallen, dan is de kans groot dat de batch waar ze uit kwamen een probleem heeft gehad (en daarmee dus ook eventueel de andere 7 disks in je systeem)...

Qua SSD is een mening; ik zou het persoonlijk niet doen gezien wat je er mee wilt (weinig random-read/writes), en wat je al hebt (128GB RAM).

[Tsurany]

Hoeveel mensen wil je gaan bedienen? Is het geen gigantische overkill aan hardware?

[mkools24]

Tsurany schreef op dinsdag 07 januari 2014 @ 11:39:
Hoeveel mensen wil je gaan bedienen? Is het geen gigantische overkill aan hardware?

Yep is het ook maar dat zei ik ook al Maar wellicht groeit het nog in de toekomst. Ik weet niet hoeveel mensen, wellicht 20 ofzo.

Het zijn wel allemaal 1080p streams, dus veel CPU power en netwerkbelasting. Vraag is natuurlijk hoeveel concurrend streams er zullen zijn, dat zal zeker mee gaan vallen.

[ Voor 20% gewijzigd door mkools24 op 07-01-2014 11:56 ]

[mkools24]

DXaroth schreef op dinsdag 07 januari 2014 @ 11:38:
Ik denk dat een z3 wellicht wat overdreven is, als je meer dan 2 disks hebt die binnen 3 dagen uitvallen, dan is de kans groot dat de batch waar ze uit kwamen een probleem heeft gehad (en daarmee dus ook eventueel de andere 7 disks in je systeem)...

Qua SSD is een mening; ik zou het persoonlijk niet doen gezien wat je er mee wilt (weinig random-read/writes), en wat je al hebt (128GB RAM).

Yep dat is waar, z2 gaat het dan zeker worden denk ik. 32 TB staat ook wel mooi

[jadjong]

mkools24 schreef op dinsdag 07 januari 2014 @ 11:08:
Een andere vraag is of het met zoveel RAM nog zin heeft om een SSD disk in te zetten voor caching? Je kan vast al wel raden dat het om bestanden gaat van vele gigabytes, 15 - 30 GB zeg maar.

Hoeveel van die zooi wordt er tegelijk gelezen? Met een bitrate van 4MB/s moet de array 80MB/s kunnen leveren als 20 man een film wil kijken. 80MB/s sequentieel moet geen probleem zijn. Alleen staan die 20 films niet allemaal strak achter elkaar op schijf. Film A staat aan het begin, film Z aan het einde van de platter. Met 20 gebruikers moet de leeskop flink heen en weer skippen.Of dit een beperking oplevert zal je moeten testen.
Als dit een probleem op gaat leveren kan je dat oplossen met cache, maar alleen met een specifiek leespatroon. Wanneer 20 man de hele week random series en films bekijkt heeft cache weinig nut, het volgende bestand zal er toch niet in zitten. Als iedereen dezelfde smaak heeft en dezelfde series volgt kan het meer zoden aan de dijk zetten.
Alleen jij kan bepalen of de huidige 128GB aan cache genoeg is of dat er nog een stapeltje SSD's bij mag.

Je kan ook even in dit topic kijken:
Storage showoff topic - 10+ TB storage systems
Dat is bedoelt voor kansloze inversteringen in overkill aan hardware.

[MikeVM]

heb net de nieuwe FreeBSD geinstalleerd (ZFSGURU), nu blijkt dat Virtualbox (X) niet beschikbaar is.
kan iemand me uitleggen hoe ik de nomale Virtualbox aan de praat krijg (remote)

[mkools24]

jadjong schreef op dinsdag 07 januari 2014 @ 12:14:
[...]

Hoeveel van die zooi wordt er tegelijk gelezen? Met een bitrate van 4MB/s moet de array 80MB/s kunnen leveren als 20 man een film wil kijken. 80MB/s sequentieel moet geen probleem zijn. Alleen staan die 20 films niet allemaal strak achter elkaar op schijf. Film A staat aan het begin, film Z aan het einde van de platter. Met 20 gebruikers moet de leeskop flink heen en weer skippen.Of dit een beperking oplevert zal je moeten testen.
Als dit een probleem op gaat leveren kan je dat oplossen met cache, maar alleen met een specifiek leespatroon. Wanneer 20 man de hele week random series en films bekijkt heeft cache weinig nut, het volgende bestand zal er toch niet in zitten. Als iedereen dezelfde smaak heeft en dezelfde series volgt kan het meer zoden aan de dijk zetten.
Alleen jij kan bepalen of de huidige 128GB aan cache genoeg is of dat er nog een stapeltje SSD's bij mag.

Je kan ook even in dit topic kijken:
Storage showoff topic - 10+ TB storage systems
Dat is bedoelt voor kansloze inversteringen in overkill aan hardware.

Tjonge daar kom ik op plek 10 met 32 TB

En nee ik denk niet dat het zo gek zal worden. En de kop moet inderdaad flink heen en weer maar het zijn dan wel 10 disks, of iig 8. Ik ga het wel eens flink testen uiteraard

[Verwijderd]

MikeVM schreef op dinsdag 07 januari 2014 @ 12:15:
heb net de nieuwe FreeBSD geinstalleerd (ZFSGURU), nu blijkt dat Virtualbox (X) niet beschikbaar is.
kan iemand me uitleggen hoe ik de nomale Virtualbox aan de praat krijg (remote)

De normale Virtualbox (zonder X) is wel beschikbaar. Een aantal ports werkte nog niet op FreeBSD 10 ten tijde van die systeemversie. Zodra 10.0-final uit is zal Jason ook een nieuwe image produceren.

Maar wil je gewoon Virtualbox via web-interface dan heb je de X-versie niet nodig; dat is de grafische versie met grafische frontend. Zoals je op Windows Virtualbox ook gebruikt. Dat mis je, maar de web-interface heb je wel gewoon. Systeemversie 9.2 heeft wel alle services.

mkools24 schreef op dinsdag 07 januari 2014 @ 11:08:
Hallo luitjes,

Ik wil een Plex media server op gaan zetten op basis van FreeBSD en ZFS.
Hoe dan ook, ik heb dus 10 x 4 TB en 128 GB RAM Hoe zouden jullie dit inzetten?

Kolere, jij had ff geld teveel.

Maar natuurlijk wel mooie config, ik wil wel ruilen.

RAID-Z2 in 10 disks is optimaal voor je dus die configuratie kan ik wel aanraden. Seeken valt ook wel mee door de prefetching. Hij leest grotere blokken vooruit in. Bovendien wordt je RAM gebruikt voor ARC caching, dat zal al heel veel reads besparen omdat deze door je cache kunnen worden afgewerkt. Je cache vult zich automatisch met meest gebruikte elementen. Dus niet zo dat iemand die eventjes alle zeldzame dingen van je server plukt de RAM-cache dan weer opnieuw moet beginnen. Dat is alleen met oudere filesystem/VFS zo. ZFS maakt onderscheid tussen (MRU; Most-Recently-Used) and (MFU; Most-Frequently-Used). Dat laatste is belangrijker dan het eerste.

Een andere vraag is of het met zoveel RAM nog zin heeft om een SSD disk in te zetten voor caching? Je kan vast al wel raden dat het om bestanden gaat van vele gigabytes, 15 - 30 GB zeg maar.

Metadata cachen zou kunnen helpen, maar verder niet zoveel. Omdat je al zoveel RAM hebt, zou ik het eerst even aankijken. Merk je dat je schijven wel erg veel aan het seeken zijn, dan kun je alsnog maatregelen treffen.

DXaroth schreef op dinsdag 07 januari 2014 @ 10:43:
@CiPHER: Wat is trouwens de redenatie geweest om ZFSGuru een compleet OS te zijn; tov enkel een front-end om zfs te beheren op een systeem?

Om ook een bruikbare oplossing te zijn. ZFSguru maakt van FreeBSD een laagdrempelig server OS, maar als het enkel een web-interface zou zijn zou het voor velen nauwelijks te installeren zijn, omdat de BSD installatie toch niet zo simpel is ook al is dat nu verbeterd met de nieuwe installer. ZFSguru installeert vele malen makkelijker.

Daarnaast hoe krijg je addons gemakkelijk werkend. Dan zit je aan een addonframework en voor je het weet heb je een OS in plaats van een web-interface. Dat laatste is toch iets te beperkt voor de ambities die ZFSguru heeft: ZFS naar de grote massa brengen.

[Eagleman7]

]Byte\[ schreef op maandag 06 januari 2014 @ 23:09:
<<zucht>>

Afgelopen weekend waren mijn servers plat gegaan doordat er rond 03:12 uur een aardlek uitgesprongen was.
Toen ik daar rond 06:00 achter kwam, had de UPS het inmiddels ook al even opgegeven.
Nahja... Alles weer opgestart, en alles lijkt weer goed te zijn.
Alleen zie ik nu dat ik de disken op FC niet meer te zien krijg op mijn ESX.

code:

[root@zfsguru ~]# ctladm startup
(7:0:0:0): <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device 
(7:0:0:0):  LUN is now online
(7:0:0:1): <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device 
(7:0:0:1):  LUN is now online
[root@zfsguru ~]# ctladm port -o on
Front End Ports enabled
[root@zfsguru ~]# ctladm port -l   
Port Online Type     Name         pp vp WWNN               WWPN              
0    YES    IOCTL    CTL ioctl    0  0  0                  0                 
1    YES    INTERNAL ctl2cam      0  0  0x5000000cb063fb00 0x5000000cb063fb02
2    YES    INTERNAL CTL internal 0  0  0                  0                 
3    YES    FC       isp0         0  0  0x500110a0001725ff 0x500110a0001725fe

[root@zfsguru ~]# camcontrol devlist -v
[...]
scbus9 on ctl2cam0 bus 0:
<FREEBSD CTLDISK 0001>             at scbus9 target 1 lun 0 (da14,pass16)
<FREEBSD CTLDISK 0001>             at scbus9 target 1 lun 1 (da15,pass17)
<>                                 at scbus9 target -1 lun -1 ()
[...]
[root@zfsguru ~]#

Wat zie ik over het hoofd?

Heb je je UPS niet ingesteld om alles uit te zetten als er nog een "aantal" minuten over is?

[Midas.e]

mkools24 schreef op dinsdag 07 januari 2014 @ 11:08:
Hallo luitjes,

Ik wil een Plex media server op gaan zetten op basis van FreeBSD en ZFS. Daar heb ik nieuwe hardware voor aangeschaft en colocatie voor gehuurd bij Evoswitch (aangezien ik al m'n maten en familie ook wil aansluiten) maar dat is momenteel helemaal uit de hand gelopen kun je gerust zeggen.

Ik heb dus een belachelijke zwaar overpowered machine aangeschaft en ik ben benieuwd wat jullie vinden van mijn config. Ik zoek een goede balans tussen beschikbare schijfruimte en redundancy.

De meeste hardware komt van azerty, hier zie je een handig overzichtje:

http://azerty.nl/winkelma...=10&product%5B656218%5D=2

Dit alles gaat draaien op een jawel, 10 gigabit link bij Evoswitch in Haarlem (Die Intel 10G kaart komt er dus ook nog bij )

Hoe dan ook, ik heb dus 10 x 4 TB en 128 GB RAM Hoe zouden jullie dit inzetten?

Ik dacht zelf aan een Raidz2, dus dan ben ik mn array pas kwijt als de 3e disk uitvalt maar met 10 disken is dit misschien toch net te weinig. Het is wel aanlokkelijk dat ik dan 32 TB netto storage heb dus voorlopig hoef ik dan niks meer te wissen alleen zodra er één schijf uitklapt kan ik gelijk gaan rijden en het rebuilden duurt waarschijnlijk dagen dus bestaat er nog steeds risico dat er meer uitvalt.

Ik zou dus liever een Z3 hebben, netto 28 TB en er mogen 3 schijven uitvallen voor ik degraded ben, alleen wil ik dit niet met 10 schijven ivm de perfomance impact en het ruimteverleis zoals beschreven in de OP, maar 11 schijven past nou eenmaal niet in die server.

Volgens mij, alle opties overwegen is Z2 dus de beste optie qua netto ruimte, redundancy en perfomance, wat denken jullie?

Een andere vraag is of het met zoveel RAM nog zin heeft om een SSD disk in te zetten voor caching? Je kan vast al wel raden dat het om bestanden gaat van vele gigabytes, 15 - 30 GB zeg maar.

Ik wil Netflix 5.0 gaan maken voor privé gebruik

Thx!

Vraag me vooral af hoe je de 10 schijven erin krijgt, aangezien je chassis maar 8 disks ondersteund.

[DXaroth]

[...]

Om ook een bruikbare oplossing te zijn. ZFSguru maakt van FreeBSD een laagdrempelig server OS, maar als het enkel een web-interface zou zijn zou het voor velen nauwelijks te installeren zijn, omdat de BSD installatie toch niet zo simpel is ook al is dat nu verbeterd met de nieuwe installer. ZFSguru installeert vele malen makkelijker.

Daarnaast hoe krijg je addons gemakkelijk werkend. Dan zit je aan een addonframework en voor je het weet heb je een OS in plaats van een web-interface. Dat laatste is toch iets te beperkt voor de ambities die ZFSguru heeft: ZFS naar de grote massa brengen.

Zo ontiegelijk veel verschilt er niet tussen de gemiddelde installatie (per distro), dus een web-interface bouwen met een systeem dat veel informatie detecteert (config file locatie, command line tools die moeten draaien, etc).. maar ik snap je redenering

Midas.e schreef op dinsdag 07 januari 2014 @ 13:46:
[...]

Vraag me vooral af hoe je de 10 schijven erin krijgt, aangezien je chassis maar 8 disks ondersteund.

In veel SM chassis zit nog ruimte voor 1-4 disks aan de binnenkant.. dat zijn geen hot-swap bays, dus mochten die kapot zijn, dan moet je systeem uit.

[ Voor 17% gewijzigd door DXaroth op 07-01-2014 13:53 ]

[Verwijderd]

Ik snap je niet zo? Punt is dat bij FreeBSD de installatie nog steeds te moeilijk is voor het soort gebruikers wat ZFSguru óók probeert te gebruiken. In feite probeert ZFSguru een ZFS server zo laagdrempelig te maken als Synology, met als uitzondering de hardware; dát moet je nog steeds zelf doen.

Installeren in ZFSguru gaat dus via de web-interface, voor alle duidelijkheid. Een beginner zou het binnen 5 minuten geklaard hebben, een gevorderde gebruiker op een SSD misschien 10 seconden. Dat vind ik wel heerlijk laagdrempelig. De installer is één van de redenen waarom mensen ZFSguru gebruiken.

[]Byte[]

Eagleman7 schreef op dinsdag 07 januari 2014 @ 13:46:
[...]

Heb je je UPS niet ingesteld om alles uit te zetten als er nog een "aantal" minuten over is?

[opendeurmodus]
Euhhh..... Dan moet deze UPS dat wel ondersteunen (NEE dus)
[/opendeurmodus]

Maargoed... het staat ff verder los van de ramdisk waarmee ik aan het testen was die ik nu niet meer zichtbaar kan krijgen op mijn ESX-doos.
(JA, ik heb de ramdisken weer aangemaakt na het booten...)

[CU2morO]

Zo, mijn eerste ZFS server die mijn Synology NAS gaat vervangen is geinstalleerd. Dan begint nu het tunen van de dramatische performance...

Bedankt voor de info op mn vorige post, Cipher! Precies wat ik wilde horen

Het is geen hoogstaande hardware:
- Asus H87I bordje
- 4x WD40EZRX (Green 4TB's),
- Intel G3420 CPU
- 8GB Crucial Ram
- 60GB Kingston SSD als bootschijf voor het OS.

Ik heb gekozen voor een RAIDZ setup, aangezien ik beschermd wil zijn tegen het hardware falen van een schijf terwijl nog steeds optimaal gebruik te maken van de ruimte met het beperkt aantal schijven.

Ik weet dat Green's en performance eigenlijk niet in dezelfde zin geplaatst mogen worden, en dat 4 schijven niet optimaal is voor een RAIDZ setup, maar voor 5 had ik geen ruimte en 3 vond ik te weinig

Welke configuratie raden jullie aan om meteen aan te passen en wat voor snelheden zou ik hiermee moeten kunnen halen?

Als ik test met deze commands dan krijg ik een gigantisch hoge write speed... dat lijkt me niet helemaal accuraat. Test ik wel op de goede manier? (10 files van 1GB per stuk uit /dev/zero)

code:

chris@DingesNas:/tank/media$ sudo dd if=/dev/zero of=/tank/media/sometestfile bs=1024M count=10
10+0 records in
10+0 records out
10737418240 bytes (11 GB) copied, 32.5463 s, 330 MB/s

[ Voor 21% gewijzigd door CU2morO op 07-01-2014 16:37 ]

[EnerQi]

Als ik test met deze commands dan krijg ik een gigantisch hoge write speed... dat lijkt me niet helemaal accuraat. Test ik wel op de goede manier? (10 files van 1GB per stuk uit /dev/zero)

Als je test, test dan grotere files als je RAM. Nu ben je je RAM aan het meten ipv harde schijven

[syl765]

@CU2morO

Wat meer info over de manier waarop je kopieerd is wel handig.
Wat is een dramatische performance?

Even kort, graag wat meer info....

[ Voor 5% gewijzigd door syl765 op 07-01-2014 16:42 ]

[CU2morO]

EnerQi schreef op dinsdag 07 januari 2014 @ 16:41:
[...]


Als je test, test dan grotere files als je RAM. Nu ben je je RAM aan het meten ipv harde schijven

code:

chris@DingesNas:/tank/media$ sudo dd if=/dev/zero of=/tank/media/sometestfile bs=16G count=10
dd: memory exhausted by input buffer of size 17179869184 bytes (16 GiB)

Dat gaat helaas niet vanuit mn /dev/zero Ben nu aan het proberen met 1GB files maar een hogere count. Zou dat wel een accurate test zijn?

syl765 schreef op dinsdag 07 januari 2014 @ 16:41:
@CU2morO

Wat meer info over de manier waarop je kopieerd is wel handig.
Wat is een dramatische performance?

Even kort, graag wat meer info....

Je hebt gelijk! Heb inmiddels mn post aangepast met wat console output. Ik gebruik 'dd' vanuit mn /dev/zero om te testen. Schijnbaar is dd niet accuraat om te testen, maar als 'ballpark indicator' is het prima.

[Verwijderd]

Pas op met bs= heel hoog te maken. In elk geval onder BSD platform betekent dat je ook die hoeveelheid in RAM nodig hebt. Je kunt beter bs=1M gebruiken en de count gewoon hoog maken, count=80000 is dus grofweg 80GB (80000MiB om precies te zijn, maar boeie).

[CU2morO]

Dat is inderdaad waar ik ook tegenaan liep. Maar zelfs als bs en count samen vele malen groter zijn dan mijn RAM, blijf ik zulke onrealistisch hoge write speeds houden:

code:

chris@DingesNas:/tank/media$ sudo dd if=/dev/zero of=/tank/media/sometestfile bs=1M count=80000
80000+0 records in
80000+0 records out
83886080000 bytes (84 GB) copied, 264.015 s, 318 MB/s

[Verwijderd]

Het je compressie ingeschakeld of dedup?
zfs get compression,dedup tank/media

[CU2morO]

Beide off

code:

NAME        PROPERTY     VALUE          SOURCE
tank/media  compression  off            default
tank/media  dedup        off            default

Lijkt mij prima met deze setup, toch? Te weinig RAM voor dedup en te weinig CPU / RAM voor compression

[Verwijderd]

Dit is geen single disk maar een 4-disk RAID-Z? In dat geval is het toch niet te hoog? Juist prima snelheden. Max snelheid is dat van (4-1=)3-disks * sequential I/O dus 3*150MB/s = 450MB/s is de absolute max. Nu werk je ook in minder snelle gedeeltes van de HDD dus dan gaat het al wat omlaag, en RAID-Z is ook niet 100% efficiënt. Desalniettemin prima.

[CU2morO]

Ok klinkt goed! Bedankt voor je toelichting.

Hoef ik me dus ook geen zorgen te maken over 512 / 4k block sizes en de bijbehorende tuning waar in de topic start over wordt gesproken?

Wil graag alles 100% geconfigureerd hebben voordat ik straks alles ga overzetten en blijkt dat ik overnieuw moet beginnen omdat ik ergens een flag ben vergeten

[Verwijderd]

Ja, je moet een afweging doen tussen performance (4k optimalisatie, dus ashift=12) en diskspace (512-byte sectors, ashift=9). Voor 4 disks in RAID-Z is er slechts een klein beetje penalty dus dan is 4K optimalisatie wel gewenst. Zie: Verwijderd in "Het grote DIY RAID NAS topic deel 3"

[]Byte[]

@CiPHER....
Ik ga morgen even 1 disk uit m'n RAID-Z2 vervangen omdat ie errors aan de lopende band genereert.
(op dit moment 74 read- en bijna 3500 write errors - Active bad sectors en zwik relocated sectors)
Een scrub loopt ongeveer 1 uur op een 10 * 4 TB RAID-Z2 set.
Afgelopen nacht... 84 MB repaired, vanochtend nogmaals 18 MB, vanmiddag nogmaals 1,5 MB.

Wat is de beste procedure?
Gewoon platgooien en de disk vervangen en dan resilveren?
Of kan ik het beter via de 'Remove the device' doen nu hij nog gewoon benaderbaar is?

[CU2morO]

Alles even opnieuw aangemaakt met ashift=12, maar vreemd genoeg lijk ik nu MEER diskspace te hebben:

vóór het opnieuw aanmaken, default ashift (df):

code:

tank           11053386880      128 11053386752   1% /tank

na het zpool destroy en opnieuw aanmaken met ashift=12:

code:

tank           11135285888     256 11135285632   1% /tank

dd vanuit /dev/zero met 80.000x 1M files laat nog steeds ongeveer dezelfde write speed zien (328MB/s)


Verder, moet ik nog iets met de SWAP doen? Aangezien OS op zijn eigen SSD buiten de ZFS pool staat, heb ik swap compleet uitgeschakeld. Dit wordt aangeraden wanneer je een SSD hebt en veel RAM. Geldt dat voor een combinatie met ZFS ook nog steeds? Of moet ik toch ergens een SWAP aanmaken?

[PuijkeN]

FireDrunk schreef op zondag 05 januari 2014 @ 09:53:
Bekijk de daadwerkelijke load inderdaad eens met zpool iostat -v 1 1. Dan zie je vrij snel wat er gebeurt.
Mocht je heel veel 'breathing' zien, kan je de txg_timeout eens naar 1 seconde zetten, dat helpt vaak.

capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 16.3G 13.4G 3 393 3.28K 44.8M
raidz1 16.3G 13.4G 3 393 3.28K 44.8M
sdb - - 0 193 13.7K 22.5M
sdc - - 0 192 11.8K 22.5M
sdd - - 0 192 11.7K 22.5M
---------- ----- ----- ----- ----- ----- -----


Dit is een gemiddelde tijdens een kopie... er wordt inderdaad heel veel gecached naar het geheugen want zelfs als volgens Windows de kopie al klaar is, blijft er nog een redelijk tijd activiteit in de zpool.

Er is dus wel iets mis denk ik met de performance naar de schijven... wat hopelijk veroorzaakt wordt door VMWare!

[mkroes]

]Byte\[ schreef op dinsdag 07 januari 2014 @ 18:14:
@CiPHER....
Ik ga morgen even 1 disk uit m'n RAID-Z2 vervangen omdat ie errors aan de lopende band genereert.
(op dit moment 74 read- en bijna 3500 write errors - Active bad sectors en zwik relocated sectors)
Een scrub loopt ongeveer 1 uur op een 10 * 4 TB RAID-Z2 set.
Afgelopen nacht... 84 MB repaired, vanochtend nogmaals 18 MB, vanmiddag nogmaals 1,5 MB.

Wat is de beste procedure?
Gewoon platgooien en de disk vervangen en dan resilveren?
Of kan ik het beter via de 'Remove the device' doen nu hij nog gewoon benaderbaar is?

@CiPHER
Ben eigenlijk ook wel even benieuwd wat nou de beste methode is om een schijf met bad sectors te vervangen. Tot nu toe altijd (lees 2 maal) 'zfs replace' gebruikt. Maar is dit ook de beste methode?

@PuijkeN
Is volgens mij een normaal verschijnsel dat het geheugen wordt gebruikt als buffer/cache.

[]Byte[]

mkroes schreef op woensdag 08 januari 2014 @ 06:33:
[...]

@CiPHER
Ben eigenlijk ook wel even benieuwd wat nou de beste methode is om een schijf met bad sectors te vervangen. Tot nu toe altijd (lees 2 maal) 'zfs replace' gebruikt. Maar is dit ook de beste methode?

Is het niet zo dat je dit ('zfs replace') alleen doet wanneer je een vrije disk (hot spare) in je systeem hebt?

[HyperBart]

mkroes schreef op woensdag 08 januari 2014 @ 06:33:
[...]


@CiPHER
Ben eigenlijk ook wel even benieuwd wat nou de beste methode is om een schijf met bad sectors te vervangen. Tot nu toe altijd (lees 2 maal) 'zfs replace' gebruikt. Maar is dit ook de beste methode?

Wat anders qua commando?

Het is altijd het beste om je bad-sectors-schijf online te houden en dan gewoon inline de replace te doen. ZFS gaat die vervanger zo snel mogelijk opvullen, maar als tijdens de rebuild een van de andere disks een foutje teruggeeft, dan kan die bad-sector-schijf toch nog zijn data aanleveren (of misschien net ook niet als daar toevallig zijn bad sector in zit). Zo loop je echt bijna geen risico om data te verliezen.

Het voordeel/gevolg is dat je array NOOIT degraded wordt ,maar continu online en "groen" blijft. Dat is wel zo geruststellend . Ik heb het hier meegemaakt, fluitje van een cent, daarna een paar keer een scrub gedraaid en hupsakee.

[]Byte[]

HyperBart schreef op woensdag 08 januari 2014 @ 12:24:
[...]

Het voordeel/gevolg is dat je array NOOIT degraded wordt ,maar continu online en "groen" blijft. Dat is wel zo geruststellend . Ik heb het hier meegemaakt, fluitje van een cent, daarna een paar keer een scrub gedraaid en hupsakee.

Ik moest helaas mijn schijf terug brengen ivm garantie en had geen spare (4TB WD Red) op de plank liggen.
Moest 'm wel ff degraden. Maargoed, ik hem 'm in een RAID-Z2 draaien en maak mij daar ff minder zorgen om.

Maar het is wel een idee om er toch maar eentje spare te leggen.

[ Voor 5% gewijzigd door ]Byte[ op 08-01-2014 12:50 ]

[HyperBart]

Mja, ok, dan zou ik me ook minder zorgen maken, bij mij is dat wel even anders...

[matty___]

Voor die gene die 10-stable draaien:

svn commit: r260385 waar onder andere deze commit inzit:

r256880:
Merge GEOM direct dispatch changes from the projects/camlock branch.

When safety requirements are met, it allows to avoid passing I/O requests
to GEOM g_up/g_down thread, executing them directly in the caller context.
That allows to avoid CPU bottlenecks in g_up/g_down threads, plus avoid
several context switches per I/O.


Weer een extra performance update. Er werd in dit topic al een keer over gepost over de 1m IO/s testcase na wat aanpassingen. Daar is dit dus onderdeel van.

edit: deze dus http://people.freebsd.org/~mav/camlock.pdf

[ Voor 4% gewijzigd door matty___ op 08-01-2014 13:09 ]

[Gralgrathor]

]Byte\[ schreef op woensdag 08 januari 2014 @ 10:40:
[...]
Is het niet zo dat je dit ('zfs replace') alleen doet wanneer je een vrije disk (hot spare) in je systeem hebt?

Standaard methode om brakke schijven te vervangen, dacht ik zo...

$ zpool status myfirstpool
Your storage pool is degraded, dude! Do something!

Trek de stukke schijf uit je pc, prop er een vervanger in, en

$ zpool replace myfirstpool olddiskid /dev/disk/by-id/newdiskid
Yay! A new disk! I'm resilvering your data, see you in about a day.

Ik heb overigens nog nooit een schijf in mijn ZoL array gehad die ik wegens toenemend aantal bad sectors uit de array heb getrokken. Mijn schijven liggen er keer op keer gewoon ineens finaal uit. Binnenkort toch eens naar de ventilatie in mijn storage box gaan kijken.

[SadisticPanda]

volgens Cipher denk ik dat je het beste bent, dat je de nieuwe disk erbij propt (samen met de brakke disk). En dan resilvered. Dan heb je nog de 'redundancy' van de brakke schijf, anders draai je degraded RAIDZ.

Na resilver, dan pas de oude schijf verwijderen.

(Niet zeker, ik ben nog ZFS noob)

[ Voor 6% gewijzigd door SadisticPanda op 08-01-2014 14:34 ]

[Gralgrathor]

azz_kikr schreef op woensdag 08 januari 2014 @ 14:33:
Na resilver, dan pas de oude schijf verwijderen.

Zeker best practice - Als je ruimte hebt in je frame voor de extra schijf, en als de oude schijf uberhaupt nog iets doet. Helaas voldoet mijn oplossing consistent niet aan deze voorwaarden. Altijd spanning en avontuur als je goedkope rommel gebruikt.

[HyperBart]

CiPHER, kan je dit nog eens bekijken?
HyperBart in "Het grote ZFS topic"

[HyperBart]

Gralgrathor schreef op woensdag 08 januari 2014 @ 14:16:
[...]


Standaard methode om brakke schijven te vervangen, dacht ik zo...
[...]

Nain nain nain nain!

Trek de stukke schijf uit je pc, prop er een vervanger in, en

$ zpool replace myfirstpool olddiskid /dev/disk/by-id/newdiskid
Yay! A [s]new [/s] replacing disk! I'm resilvering your data, see you in about a day.

Ik heb overigens nog nooit een schijf in mijn ZoL array gehad die ik wegens toenemend aantal bad sectors uit de array heb getrokken. Mijn schijven liggen er keer op keer gewoon ineens finaal uit. Binnenkort toch eens naar de ventilatie in mijn storage box gaan kijken.

Dat heb ik gelukkig nog nooit aan de hand gehad, als ik SMART errors detecteer vervang ik mijn disk. Als ik RAIDZ2 draaide deed ik dat misschien iets minder snel... Nu ik er eigenlijk over nadenk... Waarom heb ik in hemelsnaam niet 6 disks besteld ipv 5

[Gralgrathor]

HyperBart schreef op woensdag 08 januari 2014 @ 15:05:Nain nain nain nain!

Als je geen ruimte hebt en je oude schijf morsdood is: toch wel

HyperBart schreef op woensdag 08 januari 2014 @ 15:05:Als ik RAIDZ2 draaide deed ik dat misschien iets minder snel

ZFS maakt van RAID -> RACD, met de C van 'crappy'. Ik ken systeembeheerders die partijen opgebruikte enterprise disks verzamelen omdat je met een niet al te belachelijk aantal bad sectors nog steeds een leuke array voor je mediaserver thuis kunt bouwen (doorgaans onveranderlijke data).

Overigens is er twee weken terug bij mij opnieuw keer een schijf overleden - en wederom: gelijk dood, terwijl SMART indicators voorheen allemaal groen waren. Temperaturen van de HDD's in mijn box liggen gemiddeld rond de 35C, wat toch niet buitensporig warm is voor die dingen. Een beetje off-topic, maar heb ik misschien gremlins?

[HyperBart]

Gralgrathor schreef op woensdag 08 januari 2014 @ 16:06:
[...]


Als je geen ruimte hebt en je oude schijf morsdood is: toch wel

*smack* Mierenneuqer!

[...]


ZFS maakt van RAID -> RACD, met de C van 'crappy'. Ik ken systeembeheerders die partijen opgebruikte enterprise disks verzamelen omdat je met een niet al te belachelijk aantal bad sectors nog steeds een leuke array voor je mediaserver thuis kunt bouwen (doorgaans onveranderlijke data).

Mwoah, er zijn ook grenzen aan wat ZFS eigenlijk het onderliggende OS tolereert. We hebben die discussie een tijdje geleden al eens gehad, redelijk verhit. Het is niet ZFS zelf wat een disk wegtrapt uit zijn array, het is het OS wat die disk gewoon er onder uit "yankt" waardoor ZFS zijn eigen recovery mechanismes aftrapt.

Ik heb hier nog 2 mega-rotte disks liggen en ik wil dat gerust in de loop van de week nog eens testen op zowel een M1015 als de onboard SATA poortjes van mijn Supermicro plankje...

Overigens is er twee weken terug bij mij opnieuw keer een schijf overleden - en wederom: gelijk dood, terwijl SMART indicators voorheen allemaal groen waren. Temperaturen van de HDD's in mijn box liggen gemiddeld rond de 35C, wat toch niet buitensporig warm is voor die dingen. Een beetje off-topic, maar heb ik misschien gremlins?

Kabels al eens nagekeken? Is die schijf echt dood? Nog eens geprobeerd via standaard SATA kabeltje?

[BCC]

Gralgrathor schreef op woensdag 08 januari 2014 @ 16:06:
[...]
Overigens is er twee weken terug bij mij opnieuw keer een schijf overleden - en wederom: gelijk dood, terwijl SMART indicators voorheen allemaal groen waren. Temperaturen van de HDD's in mijn box liggen gemiddeld rond de 35C, wat toch niet buitensporig warm is voor die dingen. Een beetje off-topic, maar heb ik misschien gremlins?

Ik weet niet of het al genoemd is, maar is je voeding ook een beetje een fatsoenlijk ding?

[]Byte[]

Ik heb mijn disk inmiddels vervangen.
En idd met een 'zpool replace' is het een eitje.
Dit heeft mij wel getriggerd om misschien toch maar eens 1 disk op spare te leggen in de toekomst.

[HyperBart]

BCC schreef op woensdag 08 januari 2014 @ 19:03:
[...]


Ik weet niet of het al genoemd is, maar is je voeding ook een beetje een fatsoenlijk ding?

Afhankelijk van zijn antwoord op mijn vorige vragen was dat inderdaad mijn volgende vraag ook ja .

[mkroes]

Heb nog nooit meegemaakt dat een harde schijf in een keer de geest gaf. Normaal gesproken zijn er wel wat voortekenen en heb (tot nu toe dan) altijd ruim de tijd gehad om een nieuwe te halen en hem te vervangen.

@Gralgrathor
Dat je nu al een aantal keer mee maakt dat een harde schijf in een keer dood is doet mij ook sterk aan een slechte voeding denken. (maar ben niet de enige)

[ Voor 0% gewijzigd door mkroes op 08-01-2014 20:55 . Reden: typo ]

[PuijkeN]

Ik heb net ZFSGuru proberen installeren. Opgestart van CD. Op een schijfje van 60GB een pool aangemaakt OS (1 disk). Daarna reboot en het geheel start niet op van de harde schijf.

Wat zie ik over het hoofd? Ik ben niet helemaal mee... het is een HP Pro PC met EFI. Secure Boot uitgeschakeld en Legacy mode ingeschakeld. Enige bootdevice dat actief staat is momenteel SATA0, waar de 60GB op aangesloten is.

Ik voel me echt stom maar kan toch geen oplossing vinden...

[Verwijderd]

Je moet ook nog installeren op je pool voordat hij bootable wordt. Enkel een pool aanmaken is hetzelfde als een disk als NTFS-formatteren; dan staat er nog geen Windows op.

Installeren kan met System->Install. Bovendien dienen je disks juist geformatteerd te zijn op de Disks pagina. Als je op een disk klikt hoort deze te beginnen met een roodkleurige freebsd-boot partitie. Als je via ZFSguru hebt gepartitioneerd zou je dat moeten kunnen zien.

[Gralgrathor]

HyperBart schreef op woensdag 08 januari 2014 @ 16:52:Nog eens geprobeerd via standaard SATA kabeltje?

Ik heb wat eSATA multiplexers liggen en voor het gemak ook maar zo'n insteekdoosje gekocht dat ik met eSATA of USB op mijn flaptop kan aansluiten. De vorige schijf deed "tik, tik" en zwijgt dan stil. De laatste die bromt er een beetje bij, alsof hij op snelheid probeert te komen maar eigenlijk liever wil uitslapen, voordat ook die besluit er maar mee te kappen. Jammer, want dat was een van mijn laatste WD RE series schijven (ik draai nu een raidz array van 4xWD RE + 1xWD Green...), en verder heb ik alleen nog maar Green meuk liggen.

BCC schreef op woensdag 08 januari 2014 @ 19:03:
[...]Ik weet niet of het al genoemd is, maar is je voeding ook een beetje een fatsoenlijk ding?

Schijven hangen op dit moment in een externe behuizing (Sharkoon 5-bay RAID station in JBOD mode), dus zou wel moeten. Zoniet, dan heb ik volgens mij binnen nu en een jaartje wel voldoende centen bij elkaar om de geplande opvolger aan te schaffen.

[PuijkeN]

Verwijderd schreef op donderdag 09 januari 2014 @ 15:14:
Je moet ook nog installeren op je pool voordat hij bootable wordt. Enkel een pool aanmaken is hetzelfde als een disk als NTFS-formatteren; dan staat er nog geen Windows op.

Installeren kan met System->Install. Bovendien dienen je disks juist geformatteerd te zijn op de Disks pagina. Als je op een disk klikt hoort deze te beginnen met een roodkleurige freebsd-boot partitie. Als je via ZFSguru hebt gepartitioneerd zou je dat moeten kunnen zien.

Slecht uitgelegd, de installatie is ook gedaan... op de pool die ik aangemaakt heb. ZFSGuru vraagt dan om te rebooten wat ik doe...

Na de reboot krijg ik de melding dat er geen OS kan opgestart worden. Ik ben nu even opnieuw aan het booten van de livecd en ga even nakijken of de paritie een roodkleurige boot partitie bevat.

EDIT: net even gecheckt en de schijf bevat idd een rode boot partitie (256 KiB).
@ hieronder: de schijf staat inderdaad actief in de BIOS, zelfs via het opstartmenu rechtstreeks de disk selecteren lukt niet, er wordt geen OS geboot.

Ik denk dat ik maar even een andere harde schijf er aan hang!

[ Voor 14% gewijzigd door PuijkeN op 09-01-2014 15:36 ]

[Tsurany]

Even een stomme vraag maar staat die schijf wel als bootable aangevinkt in je bios? Ik kan ook hardeschijven gewoon uitsluiten van de bootlijst waardoor niet gezocht wordt of er wel een OS op staat.

[Verwijderd]

@Puijken: controleer of in je BIOS is ingesteld dat hij alleen van UEFI/GPT mag booten; ZFSguru gebruikt normale MBR-bootcode dus die instelling moet uit staan. Verder probeer met F11 ofzoiets de 'boot menu' tevoorschijn te toveren en probeer wat disks uit. Kun je verder ook de exacte foutmelding geven die je ziet? Dan weet ik of de foutcode van je BIOS komt of van de bootcode. Ik vermoed dat je bootcode helemaal niet gestart wordt.

Je hebt de disks via ZFSguru geformatteerd?

[ Voor 3% gewijzigd door Verwijderd op 09-01-2014 15:39 ]

[PuijkeN]

Disks zijn inderdaad geformatteerd via ZFSGuru. Ik ben nu even aan het testen op een andere disk. Installatie van ZFSGuru is nu bezig. Ik installeer momenteel versie 9.2

In de BIOS staat Secure Boot disabled. Legacy boot en Fast boot enabled. Ik heb nu alle devices behalve netwerkkaart op bootable staan. Ook EUFI boot is enabled.

Ik zal na de installatie even de foutmelding hier zetten (indien het probleem zich nog voordoet met de nieuwe disk).

EDIT: melding is nog steeds dezelfde. "ERROR: No boot disk has been detected or the disk has failed."

[ Voor 10% gewijzigd door PuijkeN op 09-01-2014 15:51 ]

[HyperBart]

Gralgrathor schreef op donderdag 09 januari 2014 @ 15:26:
[...]
Schijven hangen op dit moment in een externe behuizing (Sharkoon 5-bay RAID station in JBOD mode), dus zou wel moeten. Zoniet, dan heb ik volgens mij binnen nu en een jaartje wel voldoende centen bij elkaar om de geplande opvolger aan te schaffen.

Als er nog eens een disk faalt zou ik ze echt eens allemaal verplaatsen naar je server zelf, gevoed door de ATX voeding, klinkt echt een beetje als een brakke voeding in mijn ogen (of gewoon lomp toeval).

[Gralgrathor]

HyperBart schreef op donderdag 09 januari 2014 @ 16:18:
zou ik ze echt eens allemaal verplaatsen naar je server zelf, gevoed door de ATX voeding

Die ATX-voeding zit in de geplande opvolger, want die paste niet meer in het mini-ITX doosje dat de hardware voor mijn huidige machine huisvest...

[Gralgrathor]

PuijkeN schreef op donderdag 09 januari 2014 @ 15:08:
kan toch geen oplossing vinden

... Je OS niet op een ZFS volume zetten, is dat niet het gemakkelijkst?

[CurlyMo]

Vraagje aan degene die er ervaring mee hebben.

Ik draai nu een ZFS FreeBSD NAS op 2 USB sticks met een RAIDZ2 pool. Alle download, ftp en webservices draai ik in een virtualized Ubuntu-server. Mijn moederbord ondersteund geen VT-d of VT-x. Het liefste zou ik iets draaien als ESXI en dan een aparte FreeBSD voor ZFS RAID willen draaien + Samba en een Ubuntu server.

Om deze vraag open te houden. Gaat veel nut hebben? Zo ja, kan ik dan simpelweg op mijn hardware ESXI gebruiken en dan mijn bestaande pool importeren in een virtualized ESXI omgeving?

code:

  PID USERNAME      THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
74497 root           21  20    0  1366M  1246M uwait   0  25:48  4.15% VBoxHeadless
72306 root           20  20    0   751M   630M uwait   0  34:46  3.27% VBoxHeadless
 1537 root           11  20    0 95944K 16664K uwait   1   3:46  0.00% VBoxSVC
 1419 root            1  20    0 12184K   352K select  1   3:17  0.00% powerd
 1761 mysql          16  27    0   292M   114M sigwai  1   3:00  0.00% mysqld
74574 root           20  20    0   703M   585M uwait   0   2:25  0.00% VBoxHeadless

Op dit moment is dit mijn CPU verbruik. De virtualizaties zijn:
1. VBoxHeadless --> Ubuntu Server download, web en ftp services.
2. VBoxHeadless --> Ubuntu Server Cross-compile development
3. VBoxHeadless --> Windows 7 + Teamviewer.

[Verwijderd]

PuijkeN schreef op donderdag 09 januari 2014 @ 15:49:
EDIT: melding is nog steeds dezelfde. "ERROR: No boot disk has been detected or the disk has failed."

Die melding is afkomstig van je BIOS. Kun je UEFI eens uitschakelen en kijken of dat wat oplevert? Heb je meerdere disks geprobeerd te selecteren? Vaak kun je met een toetscombinatie (f10/f11/f12) bij de boot opgeven welke disk je van wilt booten, voor die ene keer. Daarmee kun je goed controleren of je wel van de juiste disk boot en of meerdere disks niet willen booten.

Verder het verzoek: schakel je DM (privéberichten) in, dat werkt prettiger met dit soort dingen. Ook omdat ik wat informatie van je nodig heb en dan is het fijn als alles bij elkaar staat, ipv veel andere berichten tussendoor.

[]Byte[]

Grrr....
M'n FC HBA in mijn ZFS-bak is overleden.
Kan geen link meer krijgen op 4 Gb
De link led in ESX blijft solid branden (zoals het hoort) op 4 Gb, maar die in ZFS staat alleen te knipperen op de 4 Gb link.

code:

Jan 10 08:52:49 zfsguru kernel: isp0: Chan 0 LINK FAILED
Jan 10 08:53:31 zfsguru last message repeated 2 times
Jan 10 08:53:34 zfsguru kernel: isp0: isp_handle_platform_atio7: [RX_ID 0xffffffff] D_ID ef not found on any channel- dropping
Jan 10 09:09:04 zfsguru kernel: isp0: Chan 0 LINK FAILED

Wat wel opvalt is dat wanneer ik een andere kabel pak en de oude er uit trek, hij alsnog wel met een LINK FAILED kom. (de melding van 08:52:49)
Weet iemand toevallig of ik het via een instelling op ZFS kan forceren naar 2 Gb om te kijken of dat wel wil werken?
Anders ga ik vandaag maar een paar IB-kaartjes (Mellanox) van ebay afplukken...
Ik zie daar een (HP) 452372-001 staan (=Mellanox MHGH28-XTC) voor net geen 40 euro staan.

Hmm...
Kabels lijkt wat lastiger.
Zie ze op ebay staan voor 25 euro. Zijn alleen wel 5 of 10 meter

Nog even een vraagje: de aansluitingen voor Infiniband op de HCA's zijn toch de SFF-8470 CX4 connectoren?

[ Voor 10% gewijzigd door ]Byte[ op 10-01-2014 09:58 ]

[FireDrunk]

Ik heb hier nog wel wat kabeltjes liggen, je kan wel even komen testen ofzo? (heb er 10 van 1 meter)
Je mag ook de kaart opsturen

[]Byte[]

FireDrunk schreef op vrijdag 10 januari 2014 @ 10:14:
Ik heb hier nog wel wat kabeltjes liggen, je kan wel even komen testen ofzo? (heb er 10 van 1 meter)
Je mag ook de kaart opsturen

Dat laat ik mij geen twee keer zeggen.
Regio Arnhem was het toch? Ik laat het wel even weten als ik ze binnen heb.
Dan spreken we wel ff wat af om langs te komen.

[FireDrunk]

Prima, DM maar

[PuijkeN]

Verwijderd schreef op donderdag 09 januari 2014 @ 20:19:
[...]

Die melding is afkomstig van je BIOS. Kun je UEFI eens uitschakelen en kijken of dat wat oplevert? Heb je meerdere disks geprobeerd te selecteren? Vaak kun je met een toetscombinatie (f10/f11/f12) bij de boot opgeven welke disk je van wilt booten, voor die ene keer. Daarmee kun je goed controleren of je wel van de juiste disk boot en of meerdere disks niet willen booten.

Verder het verzoek: schakel je DM (privéberichten) in, dat werkt prettiger met dit soort dingen. Ook omdat ik wat informatie van je nodig heb en dan is het fijn als alles bij elkaar staat, ipv veel andere berichten tussendoor.

Heb ondertussen DM aangezet in mijn profiel. Ik vermoed echter dat het een probleem of beperking is van de HP EUFI. Ik heb even een Ubuntu installatie proberen doen (niet UEFI) en die bootte ook niet van de harde schijf. Daarna een UEFI installatie gedaan van Ubuntu en deze draait nu zonder problemen.

Uiteindelijk viel de configuratie en installatie van ZFS reuze mee en kreeg ik ook makkelijk mijn andere services draaiend. Ik ben dus wel geneigd om zo'n installatie te doen ipv ZFSGuru te gebruiken.

De performance met 3 schijven is ook uitstekend, bij schrijven via SMB trek ik bijna een gigabit verbinding vol. Alleen lezen is heel wat minder, "slechts" 20 MB/s, maar gelukkig zal in die richting wel een stuk minder data versluist worden. Misschien dat hier nog wat tuning mogelijk is?

Als ik nog ergens tijd vind dit weekend, ga ik even kijken of ik nog ergens een PC'tje kan bovenhalen (geen OEM à la HP) om wat te prutsen met ZFSGuru. In ieder geval leek de performance wel iets minder bij schrijven via SMB (50-60 MB/s). Is dit mogelijk? (opgestart via LiveCD, zonder installatie).

Zijn er verder eigenlijk nadelen aan het draaien van ZFSonLinux? Ik heb ondertussen een hele hoop bijgeleerd en vermoed dat er weinig mis kan gaan. In geval van problemen kan de pool waarschijnlijk wel geimporteerd worden op een nieuwe linux of ZFSGuru installatie?

[FireDrunk]

Staat secure boot niet toevallig aan?

[Panzy]

Verwijderd schreef op donderdag 19 december 2013 @ 23:26:
[...]

Uitgebreid verhaal over HW RAID + ZFS, door CiPHER LINK

Succes

Was de laatste tijd even druk dus had geen tijd meer om hier op terug te komen. Nu weer tijd en zou toch nog even willen reageren.

Bedankt voor alle in-depth informatie, heel interressant om te lezen wat er allemaal achter de schermen gebeurt. Ik bekijk het echter op een simpeler manier:

Wat is betrouwbaarder, een enkele HDD of een RAID array?

Ik zou zeggen, een RAID array want deze heeft redundancy. In het ergste geval kunnen bijde volledig uitvallen en alle data kwijt raken, maar de kans dat dit gebeurt is groter bij de HDD omdat deze geen redundancy heeft. Echter heeft de RAID array weer andere zaken die mis kunnen gaan en kunnen leiden tot data corruptie, maar dit is niet zo ernstig als total-loss van de device. Daarom denk ik dat een RAID array betrouwbaarder is dan een enkele HDD.

Wat is betrouwbaarder, ZFS of een normaal filesystem, zoals EXT4?

Ik zou zeggen, ZFS omdat deze checksumming heeft ingebakken en daarom de data integriteit kan vaststellen. Als er dus een file kapot is gegaan om wat voor reden dan ook dan weet je dat tenminste. Bovendien kunnen kapotte files gerepareerd worden wanneer er redundancy is binnen ZFS (copies, RAIDZ).

Om deze reden zou ik zeggen, 1+1=2, oftwel ZFS + RAID array is MEER betrouwbaar dan ZFS + single disk, EN meer betrouwbaar dan EXT4 + RAID array.

Wat jij echter eigenlijk aangeeft, is dat er een soort achilleshiel zit in ZFS, waardoor het NIET betrouwbaar werkt op een RAID array: 'Gebruik je ZFS in combinatie met hardware RAID, dan bestaat het risico dat je hele pool corrupt raakt. Als dat gebeurt, kun je ook geen recovery meer plegen'.

Dit is dus een tekortkoming van ZFS, en NIET van hardware RAID, want een 'normaal' filesystem zoals EXT4 heeft hier blijkbaar geen last van. Ik heb hier zelfs bewijs van omdat ik een behoorlijk slecht funtionerende hw RAID array heb gehad, deze gaf uiteindelijk zware file corruptie, dikke artifacts door films heen enzo, maar helemaal niks 0,0 aan de hand met de integriteit van het filesystem zelf. Ik kon alle (sommige dan wel corrupted) files gewoon doodleuk vrolijk naar een backup kopieren zonder een enkele error om er later achter te komen dat sommige files corrupted waren.

Dit is dus de reden dat ik dacht, he, als ik nu ZFS had gedraaid, dan WIST ik tenminste welke files er corrupt waren. Maar volgens jouw redenering zou dan dus waarschijnlijk het hele filesystem corrupt geraakt zijn en zou ik de files uberhaupt niet meer kunnen kopieren?

Er zijn dus situaties te creëren waar ZFS MINDER betrouwbaar is dan EXT4. Dit is dus precies exact wat ik bedoel met mijn bezwaar tegen de complexiteit van ZFS. Als een HW RAID controller zo'n situatie kan creëren dan zijn er waarschijnlijk nog vele andere manieren om dat te doen.

Dit is puur een conclusie die ik als relatieve 'leek' trek. Ik vind het interressant om mij in te verdiepen en een discussie over te voeren, zeker als ik zie dat anderen soms wel heel makkelijk conclusies trekken in het voordeel van ZFS. Wat ik er in de praktijk mee doe, ik probeer een zo simpel en betrouwbaar mogelijke server te bouwen voor thuis, en raak er maar niet van overtuigd wat de betere weg is. Ik heb al een HW RAID controller van LSI en die wil ik gebruiken. Is er niet gewoon een filetransfer programma zoals DC++ die automatisch alle files checksummed wanneer deze aangemaakt worden en opnieuw checked wanneer deze verstuurd worden? Alleen dan voor Linux en makkelijker toe te passen?

[ Voor 46% gewijzigd door Panzy op 10-01-2014 15:36 ]

[Verwijderd]

Panzy schreef op vrijdag 10 januari 2014 @ 15:06:
Ik bekijk het echter op een simpeler manier:

Wat is betrouwbaarder, een enkele HDD of een RAID array?

Voor wat betreft disk failure is RAID natuurlijk superieur, dat werkt aardig goed. Wat een enkele disk echter beter kan dan de meeste RAID arrays is omgaan met bad sectors. Je filesystem heeft dan gewoon een onleesbare block. Als je geluk hebt in data, als je pech hebt in metadata. Maar je disk raakt niet gelijk onzichtbaar of andere zaken, hooguit kun je hangende applicaties krijgen en na een tijd een blauw scherm eventueel. Maar als je reboot is je schijf er weer.

Met RAID kan het zo zijn dat je met een bad sector gelijk een degraded volume hebt, tijdens rebuliden vallen er nog twee uit en zie daar maar eens van te recoveren. En al is recovery mogelijk, de gebruiker sloopt meestal deze mogelijkheid door te panieken en b.v. de RAID opnieuw aan te maken, wat zeker bij RAID5 heel gevaarlijk kan zijn ivm rebuild. Als de instellingen niet exact gelijk zijn, dan vernietig je hiermee in feite al je data omdat tijdens het initialiseren/rebuilden er goede informatie wordt overschreven, ipv parity.

Wel kun je stellen dat RAID nog iets meer weerstand heeft tegen bad sectors omdat een redundant volume nog zonder filesystem schade verder kan met slechts één bad sector. Maar het punt is dat de meeste RAID engines nogal lijp reageren op timeouts. Eigenlijk kun je stellen dat RAID ontworpen is voor disk failures de baas te bieden; het heeft eigenlijk geen echt antwoord op bad sectors. Juist nu wordt dat veel belangrijker.

Wat is betrouwbaarder, ZFS of een normaal filesystem, zoals EXT4?

No-brainer; ZFS natuurlijk. Ext4 is in principe onveiliger dan ext2/ext3 maar wel sneller doordat veel async kan gebeuren. Maar in principe valt het onder dezelfde categorie als NTFS, UFS en HFS; allemaal 2e generatie filesystems. ZFS is een 3e generatie filesystem en biedt enorm veel meer bescherming dan alle 2e generatie filesystems.

Zo is zelfs op een enkele disk het filesystem beschermd tegen bad sectors, omdat alle filesystem data ditto block-kopiën heeft verspreid over de schijf. Een single disk ZFS filesystem is dus vele malen veiliger dan een single disk Ext4 filesystem.

Om deze reden zou ik zeggen, 1+1=2, oftwel ZFS + RAID array is MEER betrouwbaar dan ZFS + single disk, EN meer betrouwbaar dan EXT4 + RAID array.

Wat bedoel je met ZFS + RAID array. Dan ga je een modern filesystem op een onveilig ouderwetse RAID-laag stoppen? Erg onveilig en je killt daarmee een heleboel features van ZFS die gewoon veel intelligenter kan multiplexen dan ouderwets RAID.

Wat jij echter eigenlijk aangeeft, is dat er een soort achilleshiel zit in ZFS, waardoor het NIET betrouwbaar werkt op een RAID array: 'Gebruik je ZFS in combinatie met hardware RAID, dan bestaat het risico dat je hele pool corrupt raakt. Als dat gebeurt, kun je ook geen recovery meer plegen'.

Dit is dus een tekortkoming van ZFS, en NIET van hardware RAID, want een 'normaal' filesystem zoals EXT4 heeft hier blijkbaar geen last van.

Dat is volstrekt onjuist. Het is geen tekortkoming van ZFS als het onderliggende storageapparaat FLUSH CACHE-commando's negeert; dat is een paardenmiddel om RAID controllers snel RAID5 te laten schrijven (write aggregation), en ook tijdelijk een hogere schrijfsnelheid te behalen (write-back buffer).

Daarnaast geldt dat RAID het gepresenteerde volume niet altijd corruptievrij kan opleveren. In geval de parity niet overeenkomt met de data wordt automatisch de parity opnieuw berekend, maar het had evengoed gekund dat de parity goed was en de data juist corrupt. Een RAID controller kan eigenlijk geen onderscheid maken tussen corrupte en valide data. Het gokt eigenlijk maar. Gevolg is dat je soms inderdaad wel corruptie hebt aan filesystem zijde. Niet altijd merk je dat op; een blipje in een film bijvoorbeeld. En vaak zie je wat filesystem check dingen voorbij komen. Meestal is de schade beperkt, maar in een enkel geval kan de metadata ernstig gecorrumpeerd raken, dan is het gewoon over en uit.

Bovenstaand verhaal is dus met b.v. ext4 of NTFS. Met ZFS is het eigenlijk niet heel veel anders, behalve dan dat als ZFS root metadata corrupt raakt, je hele volume ontoegankelijk wordt. Dat hoort nooit te gebeuren door alle beveiligingen van ZFS. Maar als ZFS opeens niets meer te zeggen heeft op wat er op de disks komt, maar de RAID controller dat gaat doen en die doet dat niet perfect, dan kun je problemen verwachten.

Als de RAID controller 100% corruptievrij data kan aanleveren aan ZFS zoals ZFS dit heeft opgeslagen, is er geen enkel probleem. In het begin zal ZFS op Hardware RAID ook prima werken. Maar ZFS kan veel intelligenter met je disks omgaan dan ouderwets RAID, dus dit zou echt enorm zonde zijn.

Ik heb hier zelfs bewijs van omdat ik een behoorlijk slecht funtionerende hw RAID array heb gehad, deze gaf uiteindelijk zware file corruptie, dikke artifacts door films heen enzo, maar helemaal niks 0,0 aan de hand met de integriteit van het filesystem zelf. Ik kon alle (sommige dan wel corrupted) files gewoon doodleuk vrolijk naar een backup kopieren zonder een enkele error om er later achter te komen dat sommige files corrupted waren.

Dan is de corruptie in data ipv metadata; dan heb je nog enigszins geluk gehad. Maar jouw verhaal is eerder een bevestiging van mijn stelling dan een contradictie.

Dit is dus de reden dat ik dacht, he, als ik nu ZFS had gedraaid, dan WIST ik tenminste welke files er corrupt waren. Maar volgens jouw redenering zou dan dus waarschijnlijk het hele filesystem corrupt geraakt zijn en zou ik de files uberhaupt niet meer kunnen kopieren?

Als je ZFS op Hardware RAID had gedraaid en op RAID-niveau er ernstige corruptie wordt gepresenteerd aan ZFS, dan kan het zijn dat de hele ZFS pool ontoegankelijk wordt met 'corrupted metadata' als vermelding.

Als je ZFS direct aan disks koppelt (SCSI/SAS/AHCI/ATA/USB/FIREWIRE/THUNDERBOLT/geom_gate) zoals iedereen doet, dan heb je dat probleem niet. ZFS bepaalt zelf wat er op de disks komt. Dus ook geen RAID engine die fouten kan maken. ZFS weet altijd wat corrupt is en wat niet. Het enige wat daar roet in het eten kan gooien zijn RAM bitflips.

Bij ZFS op een single disk array zullen bad sectors op metadata gewoon gecorrigeerd worden; niets aan de hand. Dan heb je juist geluk. Valt de bad sector op data in gebruik door een bestand, dan wordt dat hele bestand onleesbaar (permission denied). Zo kan corruptie ook niet meer naar appliaties vloeien, zoals naar je backup toe. Dan weet je héé hier is iets aan de hand. En jahoor in zpool status -v zie je dat die ene file corrupt is geraakt.

Er zijn dus situaties te creëren waar ZFS MINDER betrouwbaar is dan EXT4.

Dit is puur een conclusie die ik als relatieve 'leek' trek. Ik vind het interressant om mij in te verdiepen en een discussie over te voeren, zeker als ik zie dat anderen soms wel heel makkelijk conclusies trekken in het voordeel van ZFS.

Ik kan je verzekeren dat de veiligheid van ZFS zeker niet overdreven is. Vriend en vijand is het erover eens dat checksumming het begin is van veilige dataopslag. Zelf ga ik nog een stapje verder en stel dat al het andere simpelweg onveilig is; van een ander tijdperk. Hoewel ZFS het eerste veilige filesystems is dat volwassen en breed beschikbaar is, zullen ook anderen volgen: Btrfs/ReFS/HammerFS.

Straks is het 'not-done' om belangrijker dingen op een oud filesystem op te slaan. Je weet eigenlijk nooit of er iets corrupt is of niet, en dat is eigenlijk al de dooddoener voor ieder filesystem. Daarnaast is er eigenlijk geen enkele bescherming voor de metadata of de data. De enige bescherming in 2e generatie filesystems is dat van verloren recente writes (journalling). Dat maakt het mogelijk dat hardeschijven op 150MB/s kunnen schrijven ipv 4MB/s met write buffering uitgeschakeld; wat nodig is voor 1e generatie filesystems. That's it. Stelt niets voor.

[Panzy]

Verwijderd schreef op vrijdag 10 januari 2014 @ 16:22:
[...]

[Er zijn dus situaties te creëren waar ZFS MINDER betrouwbaar is dan EXT4.]

Nou, zoals mijn voorbeeld. Als ik in mijn situatie dus ZFS had gedraaid op mijn corrupte hardware RAID array was de kans aanwezig geweest dat de gehele ZFS pool corrupted was geraakt en dus niks meer toegankelijk was geweest. Dit kan dus niet gebeuren bij EXT4, omdat het een veel simpeler systeem is en daardoor niet op die manier uit het veld is te slaan. Gooi er een scan overheen en hij doet het weer.

Volgens mij was RAID er eerder dan ZFS. Een RAID volume is gewoon een legitiem opslagmedium net als een HDD. Als ZFS hierop door wat corruptie volledig ontoegankelijk kan worden dan is dat in mijn ogen de schuld van ZFS zelf, niet van RAID.

[ Voor 17% gewijzigd door Panzy op 10-01-2014 17:23 ]

[Verwijderd]

Ook een filesystem kan sterk corrumperen. Zo heb ik zelf met software RAID5 en UFS ongeveer 65% van alle data kwijtgeraakt, door corrupte metadata.

En ik snap het punt niet zo; als je ZFS gebruikt dan gebruik je ZFS ook als multiplexer en dus geen RAID. Dus het probleem wat je schetst is extreem hypothetisch. De schuld toeschuiven naar ZFS omtrent corruptie op RAID-niveau is natuurlijk gekkenwerk. Maar ik respecteer je mening.

[Panzy]

Verwijderd schreef op vrijdag 10 januari 2014 @ 17:48:
Ook een filesystem kan sterk corrumperen. Zo heb ik zelf met software RAID5 en UFS ongeveer 65% van alle data kwijtgeraakt, door corrupte metadata.

En ik snap het punt niet zo; als je ZFS gebruikt dan gebruik je ZFS ook als multiplexer en dus geen RAID. Dus het probleem wat je schetst is extreem hypothetisch. De schuld toeschuiven naar ZFS omtrent corruptie op RAID-niveau is natuurlijk gekkenwerk. Maar ik respecteer je mening.

Je begrijpt niet wat ik bedoel volgens mij, probeer het nog een keer uit te leggen:

Ik geef ZFS niet de schuld van corruptie op RAID niveau, ik zeg alleen dat ik het vreemd en slecht vind dat DOOR deze corruptie de hele zpool ontoegankelijk kan worden (jouw woorden). Bij een 2e generatie filesystem kan dit dus blijkbaar niet, zoals je zelf meegemaakt heb was bij een extreem geval nog steeds 35% van de data beschikbaar.

Oftwel als je met ZFS net op de verkeerde plek corruptie heb dan valt het hele systeem uit, dat zeg jij.

[ Voor 5% gewijzigd door Panzy op 10-01-2014 18:08 ]

[mkroes]

Panzy schreef op vrijdag 10 januari 2014 @ 18:06:
[...]


Je begrijpt niet wat ik bedoel volgens mij, probeer het nog een keer uit te leggen:

Ik geef ZFS niet de schuld van corruptie op RAID niveau, ik zeg alleen dat ik het vreemd en slecht vind dat DOOR deze corruptie de hele zpool ontoegankelijk kan worden (jouw woorden). Bij een 2e generatie filesystem kan dit dus blijkbaar niet, zoals je zelf meegemaakt heb was bij een extreem geval nog steeds 35% van de data beschikbaar.

Oftwel als je met ZFS net op de verkeerde plek corruptie heb dan valt het hele systeem uit, dat zeg jij.

ZFS hoor je ook niet bovenop hardware RAID te draaien..
Het is of ZFS (met z'n eigen RAIDZ vdevs) of hardware RAID met hier bovenop een 2de generatie filesystem zoals NTFS/UFS/ext2/ext3...

Met hardware RAID ben je beschermt tegen disk-uitval en kun je wat extra performance genereren.
Met ZFS ben je beschermt tegen diskuitval, kun je wat extra performance genereren en heb je als extra checksumming tegen bitrot (extra bescherming van je filesystem dus).

[ Voor 13% gewijzigd door mkroes op 10-01-2014 19:10 . Reden: extra info ]

[]Byte[]

Ik heb vandaag eens een upgrade naar 10.0-001 gewaagd.
Kan het kloppen dat de write performance nu toch wel een dramatisch stuk lager is?

Op mijn hdd-pool kom ik nu uit op 303 MB/s write t.o.v. 699 MB/s onder 9.2
Op mijn ssd-pool kom ik nu uit op 679 MB/s write t.o.v. 749 MB/s onder 9.2

De leessnelheden zijn op de ssd-pool gelijk gebleven (2 GB/s), maar op de hdd-pool is ie juist omhoog gegaan naar zo'n 1 GB/s.

Heeft iemand een idee?

[FireDrunk]

Andere default instellingen? Even sysctl -a | groep zfs vergelijken?

[]Byte[]

FireDrunk schreef op vrijdag 10 januari 2014 @ 21:06:
Andere default instellingen? Even sysctl -a | groep zfs vergelijken?

Al gedaan. Kon zo niet echt iets bijzonders vinden.
Maar zo'n dramatische achteruitgang ga je volgens mij niet met een paar settings recht trekken.
Ik ben eigenlijk benieuwd of er meer mensen hier dergelijke ervaringen mee hebben.

[FireDrunk]

Vaag, kan mij niet voorstellen dat het iets anders is. Bij veel 10.0 images staat debugging aan (kernel debugging) maar dat zou niet *zo* veel impact op de performance moeten hebben gok ik...

[]Byte[]

Is er een 'makkelijke manier' waarop ik snel terug kan naar de 9.2 versie zoals ie was?
Had ergens gelezen dat dit makkelijk (?) kon, maar ik kan het betrokken artikel zo ff niet meer vinden.

[EnerQi]

]Byte\[ schreef op vrijdag 10 januari 2014 @ 21:52:
Is er een 'makkelijke manier' waarop ik snel terug kan naar de 9.2 versie zoals ie was?
Had ergens gelezen dat dit makkelijk (?) kon, maar ik kan het betrokken artikel zo ff niet meer vinden.

ZFSguru? System --> booting --> kies je bootoptie dmv "activate bootfs"

[Verwijderd]

FireDrunk schreef op vrijdag 10 januari 2014 @ 21:43:
Vaag, kan mij niet voorstellen dat het iets anders is. Bij veel 10.0 images staat debugging aan (kernel debugging) maar dat zou niet *zo* veel impact op de performance moeten hebben gok ik...

Bij ZFSguru wordt tijdens het build proces de GENERIC-kernel gestript van debugging opties.

Maar bij een RC worden de debugging opties ook uitgeschakeld, mogelijk al eerder. Dus ook vanilla FreeBSD 10.0-RCx moet vrij van debugging opties zijn. Wel is het zo dat 10.0 nu met Clang wordt gebuild, inclusief veel services. Ik weet niet of dat het verschil mag zijn.

@]byte[ Ik zou zeggen verifieer je resultaten eens. Doe een write test op de command line met dd, vraag als je hulp nodig hebt.

[]Byte[]

Verwijderd schreef op vrijdag 10 januari 2014 @ 22:11:
[...]
@]byte[ Ik zou zeggen verifieer je resultaten eens. Doe een write test op de command line met dd, vraag als je hulp nodig hebt.

Ga ik zeker doen. Hij is nu ff aan het booten met 9.2-001.
Ik zal dan weer eens de benchmark vanuit de webinterface doen maar ook de dd, en ze eens opnieuw naast elkaar te leggen.

[Verwijderd]

HyperBart schreef op maandag 06 januari 2014 @ 22:17:
Cipher CiPHER , je hebt ooit eens verteld over een manier om metadata in te laten schrijven op l2arc als die geconfigged is voor metadata only. Wat was dat weer?

Wat bedoel je precies?

Je kunt per filesystem het volgende instellen:
- primarycache=all|metadata|none
- secondarycache=all|metadata|none

Primary = RAM, Secondary = SSD (L2ARC)
Door inheritance kun je je pool filesystem ('tank') instellen op metadata voor de secondarycache property. Dan geldt dezelfde setting by default voor alle bovenliggende filesystems, tenzij je zelf expliciet iets anders instelt. Precies wat je wilt dus. Secondarycache op metadata zetten is dus een goed startpunt. Dan kun je op 'all' instellen voor de filesystems waar je echt op wilt cachen, zoals je Game-directory of VM-filesystem of een ZVOL.

Maar als je bedoeld dat in ZFSguru een feature zat waarmee je je L2ARC kunt 'opmwarmen' vlak na een boot, dan kun je /etc/rc.conf eens bekijken daar kun je dat simpelweg instellen:

zfsguru_arc_warmup_enable="YES"

Gevolg hiervan is een 'find' commando op je filesystems. Bestanden worden niet gelezen, maar metadata wel. Hierdoor heb je gelijk alle metadata in de ARC gedrukt. Merk op dat er standaard een cap zit op hoe snel L2ARC gevuld kan worden, dit kan het effect hiervan deels teniet doen. Maar je hebt ook nog L1 ARC (RAM) natuurlijk.

Metadata cachen ben ik zelf erg voorstander van. Het zorgt dat je lekker snel door bestanden en folders heen kunt jassen en HDDs krijgen minder random read seeks te verwerken, zodat ze meer op sequential I/O kunnen richten.

[]Byte[]

Schop mij maar om!

Opeens haal ik dezelfde read en write-speeds onder 9.2 als onder 10.0 voor de hdd_pool, maar de ssd_pool is er weer wel op vooruit gegaan naar zo'n 726 MB/s.

ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool            : hdd_pool1 (36.2T, 5% full)
Test size       : 128 GiB
normal read	: 1 GB/s
normal write	: 304 MB/s
I/O bandwidth	: 37 GB/s

ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool            : ssd_pool1 (928G, 5% full)
Test size       : 128 GiB
normal read	: 2 GB/s
normal write	: 726 MB/s
I/O bandwidth	: 37 GB/s

Maar wat helemaal wierd is:
Na de reboot zie ik opeens mijn disk via FC weer op ESX!
Voor de upgrade naar 10.0 heb ik 'm wel 4 keer gereboot om te kijken of ik de HBA toch weer in leven kon krijgen. (ook nadat ik de kabel had vervangen - just to be sure...)

I'm a bit confused right now...

[FireDrunk]

Upgrade levert je een nieuwe kernel op he?

[CurlyMo]

Was er nog iemand die antwoord had op mijn vraag? Dan kan ik morgen namelijk een beetje gaan klooien.

[]Byte[]

FireDrunk schreef op zaterdag 11 januari 2014 @ 00:39:
Upgrade levert je een nieuwe kernel op he?

Euhh... Ja. Klopt.
Maar als ik van 10.0 terug naar 9.2 ga, mag ik er toch vanuit gaan dat ik ook weer op mijn oude 9.2 kernel zit.
In de 10.0 had ik nog niet eens de FC gecompileerd met de modules en devices.hints aangepast en wat er allemaal verder niet nodig was om het werken te krijgen. Toen ik geboot was in 10.0 heb ik het ook nog gecontroleerd, en NO isp-drivers en NO target support...
Nu ga ik terug naar 9.2, en alles doet het opeens.
Dat er het nodige gecompileerd is mag duidelijk zijn.
Maar dan moet het wel iets common geweest zijn wat in 9.2 maar ook in 10.0 gebruikt wordt en wat op de e.o.a. manier een directe link heeft met FC lijkt mij.

Maar om daar een uitspraak over te doen weet ik te weinig over de processen in FreeBSD.

[FireDrunk]

@CurlyMo, wat bedoel je nou?, wil je esxi virtualiseren onder esxi? Want je hebt het over hardware esxi VS virtualized esxi?

Zfs is simpel, als het dezelfde schijven ziet is je pool importeerbaar, zelfs al komen de schijven over iscsi binnen vanuit de andere kant van de wereld.

[CurlyMo]

Ik heb een MB + CPU die geen vt-d en vt-x aankunnen. Daarnaast draai ik nu freebsd met een zfs raidz2 pool. Kan ik op een usb stick esxi installeren, daarna freebsd virtualized installeren als guest en dan mijn pool weer importeren of heb ik daar vt-d voor nodig?

[Xudonax]

Het lijkt te kunnen, maar je zit wel met de passthrough van je schijven wat ESXi dan moet doen. Plus dat je, vanwege het ontbreken van VT-x, enkel 32 bit CPU's kunt virtualiseren. En hoewel VMWare altijd wel een fatsoenlijke performance heeft kunnen leveren met paravirtualisatie, is de performance daarvan nog steeds ruk vergeleken met VT-x performance. Mijn advies is dan ook om het niet te doen als het niet strikt noodzakelijk is.

Ter vergelijking, ik heb recentelijk VT-x/VT-d ingeschakeld op de server op werk, en ineens draaide de verschillende VM's in ESXi (versie 4.0.0, dat dan weer wel...) merkbaar een héél stuk soepeler. Ik heb helaas geen benchmarks want tsja, werk

[CurlyMo]

Ik draai nu voor veiligheid al mijn download services in een virtualized ubuntu (zoals je kon zien in mijn top output in mijn vorige post).

[Eagleman7]

Gisteren eindelijk mijn eerste UPS binnen gekregen, zodat mijn ESXi machine inclusief FreeNAS "normaal" afgesloten worden. Ik wilde dit in combinatie met ESXi en een centOS VM draaien die de UPS "beheert" met apcupsd.

Dit is dus de groostste fout die ik gemaakt heb.

Ik heb deze methode gevolgd: http://thehelpfulhacker.n...-esxi-server-with-centos/

maar ik krijg het gewoon niet voorelkaar om apcupsd werkend te krijgen, ik heb nu een extra CentOS machine er naast gezet die niet virtueel draait, shutdown gaat perfect, de UPS draait op batterijen en na 60 seconden wordt de CentOS machine uitgezet inclusief de UPS, zodat deze weer opstart als het stroom terug is.

Alleen het wil me maar niet lukken om ESXi uit te zetten, hij weigert gewoon een custom script te draaien.

Ik heb doshutdown aangemaakt in /etc/apcupsd

[root@debian apcupsd]# cat doshutdown

code:

#!/bin/sh
#
# This shell script if placed in /etc/apcupsd
# will be called by /etc/apcupsd/apccontrol when apcupsd
# detects that the battery should be replaced.
# We send an email message to root to notify him.
#
SYSADMIN=root
APCUPSD_MAIL="/bin/mail"

HOSTNAME=`hostname`
MSG="$HOSTNAME UPS shutting down ESXi"
#
(
   /usr/bin/ssh root@192.168.1.10 '/scripts/shutdown-all-vms.sh'
) | $APCUPSD_MAIL -s "$MSG" $SYSADMIN

exit 0     #keep apccontrol from doing it's own shutdown

Ik heb /etc/apcupsd/apccontrol aangepast met het volgende:

SSH=/usr/bin/ssh

${SSH} -l root 192.168.1.10 "/scripts/shutdown-all-vms.sh"
ssh -l root 192.168.1.10 "/scripts/shutdown-all-vms.sh"
ssh root@192.168.1.10 "/scripts/shutdown-all-vms.sh"

Hij wilt gewoon HELEMAAL niks pakken en hij weigert ook ieder ding dat ik aanpas te draaien.

Ik heb geen idee waar ik nog naar kan kijken, ik ben nu al een uur of 5 bezig om dit verschrikkelijke apparaat werkende te krijgen, alleen het wil me maar niet lukken.

[ Voor 17% gewijzigd door Eagleman7 op 11-01-2014 13:19 ]

[Q]

Werkt dit script als je het zelf handmatig uitvoerd?
SSH keys?

[ Voor 27% gewijzigd door Q op 11-01-2014 14:06 ]

[Eagleman7]

Q schreef op zaterdag 11 januari 2014 @ 14:05:
Werkt dit script als je het zelf handmatig uitvoerd?
SSH keys?

./doshutdown

Sluit alles netjes af op de ESXi machine, zonder een wachtwoord te vragen.

De SSH keys werken ook, omdat als ik ssh root@192.168.1.10 uitvoer er niet gevraagd wordt om credentials en hij maakt connectie.

Het probleem is dat hij weigert om dit custom scriptje te draaien.

[ Voor 15% gewijzigd door Eagleman7 op 11-01-2014 14:14 ]