De CSL/OT-kroeg

[Q]

Wat kost op de tafel dansen eigenlijk?

[-Venom-]

Ligt aan je gewicht en de constructie van de tafel ik durf met mijn gewicht niet op de meeste tafels te gaan dansen

[Q]

Stel je voor dat dit op de tafel danst.



Het is niet zozeer de kosten van de tafel denk ik, als wel de mensen die na afloop door
slachtoffer hulp en vele sessies met psychiaters weer op de been geholpen moeten worden.

[Voor 6% gewijzigd door Q op 22-04-2014 21:26]

[mux]

Pf, gewoon wat rustiger dansen. Een beetje springend persoon genereert makkelijk 2.5-3x zijn gewicht in krachten op de tafel en dat gaat ook prima.

Which leads to the obvious question: Heeft iemand Zeef wel eens gevraagd om op een tafel te dansen? Wat was het resultaat?

[FireDrunk]

Waarom Zeef? Kom je iets tekort?

[Phyt_]

Hoi, vind het beetje vroeg om bier te drinken.
Houd het nog even bij koffie.
@FD, bedankt voor het checken van de Wifidongle i.c.m. Pfsense, dit gaat hem dus niet worden :<.
Dat wilde ik ook namelijk ook in het nieuwe huis wat er misschien gaat komen gaan invoeren.
Heb nu de Pfsense nog met een linksys AP draaien.

[Pantagruel]

FireDrunk schreef op dinsdag 22 april 2014 @ 20:41:
do-release-upgrade -d geeft je de dev versie, niet de LTS. Is nogal een verschil...

Thnx, weer wat wijzer geworden, ook dat een upgrade niet alles in leven laat en herinstalls vereist van dingen.

FireDrunk schreef op dinsdag 22 april 2014 @ 22:14:
Waarom Zeef? Kom je iets tekort?

Every man his fetish

[Voor 22% gewijzigd door Pantagruel op 23-04-2014 13:09]

[-Venom-]

2,5 tot 3 keer zijn gewicht 265 tot 315 kilo... Als ik de tafel zelf gemaakt heb durf ik dat wel aan maar een ikea tafel doe ik dat niet aan (moet wel zeggen dat ik er niet zo uitzie als Q zijn afbeelding zodra het zo erg is ga ik met tatjana sporten )

[Q]

Ik heb een paar weken terug 4 x 4 TB gekocht bij "www.update.nl" en nu ik er een paar bij wil kopen blijkt die website nu al een dag uit de lucht. Heb ze maar ergens anders gekocht. Hoop dat ze niet faiiliet zijn. Ze waren wel de goedkoopste...

[GENETX]

Q schreef op donderdag 24 april 2014 @ 10:17:
Ik heb een paar weken terug 4 x 4 TB gekocht bij "www.update.nl" en nu ik er een paar bij wil kopen blijkt die website nu al een dag uit de lucht. Heb ze maar ergens anders gekocht. Hoop dat ze niet faiiliet zijn. Ze waren wel de goedkoopste...

Oef, vroegâh was dat dé lokale computerwinkel bij ons in de stad (althans, stad voor Friese begrippen ). Vond het al jammer dat die winkel toen dicht ging. Weet niet of het domein nou overgenomen was door een van de oud medewerkers, of dat iemand anders er op in ging.

* GENETX werkt nog steeds met een echte heuze Update PC

[FireDrunk]

Update.nl is toch zo'n franchiseonderneming die lokale zaakjes samen koppelt?

[Q]

Website doet het weer, mogelijk een grote storing maar ik zie niets op de site staan. Ik bestel er even niet voorlopig. Heb mijn 4 x 4 TB inmiddels binnen, daar ga ik deze dagen ook even mee spelen. Ik ben zo benieuwd wat 10 x 4 TB in RAID 0 doet qua sequentiele performance. Gewoon voor de kick. Zou op ~1500 MB/s moeten uitkomen.

[FireDrunk]

Ik verwacht eerlijk gezegd niet dat het zo goed schaalt. Je gaat denk ik de max van je controller raken (M1015 / Onboard AHCI).

[Q]

Ik heb er 3 x M1015 in zitten dus ik zou een eind moeten komen.

[FireDrunk]

Moet lukken

Keep us posted

[Q]

Spot on!

code:

root@nano:/storage# dd if=/dev/zero of=test.bin bs=1M count=100000
100000+0 records in
100000+0 records out
104857600000 bytes (105 GB) copied, 71.109 s, 1.5 GB/s
root@nano:/storage# dd if=test.bin of=/dev/null bs=1M 
100000+0 records in
100000+0 records out
104857600000 bytes (105 GB) copied, 65.1503 s, 1.6 GB/s

[Voor 8% gewijzigd door Q op 24-04-2014 18:12]

[FireDrunk]

RAID0 met ZFS of MDADM?

[Q]

FireDrunk schreef op donderdag 24 april 2014 @ 18:17:
RAID0 met ZFS of MDADM?

MDADM puur even als performance test.

[DXaroth]

weer wat lopen spelen met mn libzfs wrapper:

code:

xaroth@test> python -m libzfs.cmd zpool status
   pool: test
  state: ONLINE
   scan: scrub repaired 0 in 0h0m with 0 errors on 2014-04-25 01:51:40

had geen zin om de gehele zpool status na te bouwen; er gebeurt nog best veel onder water bij het checken van de zpool status om 'even' na te maken.

de code, voor de liefhebbers: https://gist.github.com/Xaroth/11273909

[WhiteX]

Ik heb een domme vraag mbt backups waar ik niet direct een antwoord op vind.
Ik ben eigenlijk een leek in het backup gebeuren en niet zo vertrouwd met de daily/weekly/monthly

Op mijn stage steken ze elke maandag nieuwe tapes in. (weekly)
elke laatste maandag van de maand worden monthly tapes verwisseld.

Is het dan zo dat, elke maandag wordt een wekelijkse back-up genomen. Dit is een full back-up van de gehele machine op die moment. Gedurende de week wordt op basis van deze full back-up een incremental back-up genomen (daily).

Hoe zit dat dan met die maandelijkse tapes? Nemen die dan een back-up van de wekelijkse back-ups die gedurende die maand gelopen hebben? (wat er dus 4 zijn in totaal)

[Q]

WhiteX schreef op vrijdag 25 april 2014 @ 09:03:
Ik heb een domme vraag mbt backups waar ik niet direct een antwoord op vind.
Ik ben eigenlijk een leek in het backup gebeuren en niet zo vertrouwd met de daily/weekly/monthly

Op mijn stage steken ze elke maandag nieuwe tapes in. (weekly)
elke laatste maandag van de maand worden monthly tapes verwisseld.

Is het dan zo dat, elke maandag wordt een wekelijkse back-up genomen. Dit is een full back-up van de gehele machine op die moment. Gedurende de week wordt op basis van deze full back-up een incremental back-up genomen (daily).

Hoe zit dat dan met die maandelijkse tapes? Nemen die dan een back-up van de wekelijkse back-ups die gedurende die maand gelopen hebben? (wat er dus 4 zijn in totaal)

In dit topic dansen we op tafel met in iedere hand een biertje, of wiskey, wat je lekker vindt

Als je vragen hebt over backup enzo: maak een mooie separate topic start. Het antwoord op je vraag is trouwens 'nee'. Proost!

[FireDrunk]

Een monthly tape betekend vooral dat de tape een maand bewaard wordt. Die maandag tape word de eerstvolgende maandag weer overschreven.

Ze bevatten zeer waarschijnlijk dezelfde data, alleen heeft de tape dus een langere retentie.

[jacovn]

Is dit wel een rookvrije kroeg ?
Anders ga ik er direct weer uit

[Q]

Blegh, roken is zo 1968. No way.

[mux]

Het is jammer dat het zo stinkt en ongezond is, anders zou het best cool zijn af en toe.

[Pantagruel]

mux schreef op vrijdag 25 april 2014 @ 13:03:
Het is jammer dat het zo stinkt en ongezond is, anders zou het best cool zijn af en toe.

Wel choco fantasie natuurlijk

[Voor 3% gewijzigd door Pantagruel op 25-04-2014 15:28]

[FireDrunk]

Roken is alleen maar cool als het om electronica gaat

[Pantagruel]

FireDrunk schreef op vrijdag 25 april 2014 @ 16:16:
Roken is alleen maar cool als het om electronica gaat

I love the smell of a burned capacitor in the morning

[Q]

Tja, als je gaat roken, doe het dan goed

(Wagner er zelf bij denken)

[jacovn]

Die moet ik ook weer eens kijken, alleen heb ik zo weinig tijd. In de dvd tijd gekeken, nu heb ik de blu ray rips staan.

[Q]

Doe dan wel de redux versie, de extra fragmenten zijn het echt waard.

The white leave, the yellow stay.

[FireDrunk]

* FireDrunk heeft geen idee over welke film het gaat...

[Q]

cultuurbarbaar* Dan ga jij mogelijk nog de geneugten ondervinden (als je'm echt niet gezien hebt) van Appocalypse Now Redux. Doe dat als je een beetje relaxed bent, je moet jezelf echt op die film laten meedrijven. Kijk de film s'avonds laat als het goed donker is. En de speakers goed luid zetten.

• De laaste cultureel verantwoorde film die ik heb gezien is te lang geleden. Laatst 'Thor' gekeken for crying out loud.

[Voor 20% gewijzigd door Q op 26-04-2014 12:32]

[Pantagruel]

Q schreef op zaterdag 26 april 2014 @ 12:13:
cultuurbarbaar* Dan ga jij mogelijk nog de geneugten ondervinden (als je'm echt niet gezien hebt) van Appocalypse Now Redux. Doe dat als je een beetje relaxed bent, je moet jezelf echt op die film laten meedrijven. Kijk de film s'avonds laat als het goed donker is. En de speakers goed luid zetten.

• De laaste cultureel verantwoorde film die ik heb gezien is te lang geleden. Laatst 'Thor' gekeken for crying out loud.

Cultureel verantwoord, erhhmmm, Texas Buyers club, denk ik. De rest is toch vooral genietbaar met bier en chips/popcorn erbij

[FireDrunk]

1979???

[Q]

FireDrunk schreef op zaterdag 26 april 2014 @ 15:29:
1979???

Shut up and watch the goddamn movie, you will not be disappointed.

[Damic]

@firedrunk: met zo'n naam en dan niet weten waarover het gaat
Spoiler: YouTube: Apocalypse Now - smell of napalm

I love the smell of burning rubber in the morning/evening/night HELL whole day long

[FireDrunk]

Die quote ken ik wel, maar film nog nooit gezien


"Deze video is niet beschikbaar in je land.

Het spijt ons."

[Voor 40% gewijzigd door FireDrunk op 26-04-2014 18:53]

[jacovn]

Het gaat over de waanzin van de oorlog

Je kunt de imdb preview bekijken: IMDB: Apocalypse Now (1979)

Er moeten vast wel meer film liefhebbers in deze kroeg komen, met al die multi TB servers zal er haast wel iemand bij zijn die er films op heeft staan..

[Voor 94% gewijzigd door jacovn op 27-04-2014 07:47]

[Patatjemet]

Over cultureel verantwoorde films gesproken; ik heb laatst dances with wolves weer eens gezien en heb er echt van genoten. Het heeft wel als nadeel dat de flinterdunne verhalen lijnen van veel huidige films mij nou meer irriteren dan daarvoor...

[Pantagruel]

Patatjemet schreef op zondag 27 april 2014 @ 09:15:
Over cultureel verantwoorde films gesproken; ik heb laatst dances with wolves weer eens gezien en heb er echt van genoten. Het heeft wel als nadeel dat de flinterdunne verhalen lijnen van veel huidige films mij nou meer irriteren dan daarvoor...

LOL, de chips en HJ smaakte beter dan "the mechanic" en " The Expendables" van gisteravond bij elkaar

Voordeel je mist weing als je naar de koelkast slentert voor een nieuwe vulling

[jacovn]

Apocalypse now heeft ook vrij lange dialogen en overpeinzingen of hoe ze ook mogen heten, het is een lange zit met de redux versie..

[FireDrunk]

Ach, voor een goede verhaallijn kijk ik tegenwoordig een serie... Dan is de verhaallijn veel langer (en vaak iets beter uigewerkt).

Ben nu bezig met Arrow, en daar vind ik het verhaal wel grappig. (los van het feit dat er in de serie wel wat slechte acteurs zitten, en het verhaal beetje... vreemd... is )

Maar goed.... iemand nog wat leuks gedaan op ZFS gebied? Ik begin het de laatste tijd een beetje beu te worden dat het allemaal zo half werk is. DXaroth is bezig met een fatsoenlijk python library voor ZFS, maar waarom zijn die dingen er nu pas zou je zeggen... ZFSonLinux is er ook al weer een aantal jaar

[Patatjemet]

Bar fight!!

[Q]

Patatjemet schreef op zondag 27 april 2014 @ 10:11:
Bar fight!!

Ja met jou, over Dances with Wolves. Bah wat een saaie film.

[DXaroth]

FireDrunk schreef op zondag 27 april 2014 @ 09:59:
Ach, voor een goede verhaallijn kijk ik tegenwoordig een serie... Dan is de verhaallijn veel langer (en vaak iets beter uigewerkt).

Ben nu bezig met Arrow, en daar vind ik het verhaal wel grappig. (los van het feit dat er in de serie wel wat slechte acteurs zitten, en het verhaal beetje... vreemd... is )

Maar goed.... iemand nog wat leuks gedaan op ZFS gebied? Ik begin het de laatste tijd een beetje beu te worden dat het allemaal zo half werk is. DXaroth is bezig met een fatsoenlijk python library voor ZFS, maar waarom zijn die dingen er nu pas zou je zeggen... ZFSonLinux is er ook al weer een aantal jaar

libzfs is onderdeel van zfs; en de meeste gaan er van uit dat als je iets serieus met zfs wilt doen, dat je dat dan in C/C++ doet (en dan dus libzfs zelf kan gebruiken).

Dat gezegd hebbende, hopenlijk kan ik met libzfs-python dingen wat makkelijker maken voor interfaces; kan me zo maar bedenken dat een zfsguru/nas4free dit kan gebruiken om niet command-line-output te hoeven parsen (bedoel, maak een simpel script en output het als json data en -elke- taal kan het lezen.. om dan nog het concept xmlrpc te negeren)

[Q]

De enige reden waarom ik ZFS zou gebruiken is dat ZFS mij op zijn minst kan vertellen dat er file corruptie optreedt en welk bestand het is. Het hoeft niet eens gerepareerd te worden, als ik maar weet wat stuk is.

Dus heb ik een RAID0 (om met mijn vorige bench te kunnen vergelijken) gemaakt en daar bovenop ZFS als FS geflikkerd.

code:

root@nano:/storage# dd if=/dev/zero of=test.bin bs=1M count=100000
100000+0 records in
100000+0 records out
104857600000 bytes (105 GB) copied, 84.1368 s, 1.2 GB/s
root@nano:/storage# dd if=test.bin of=/dev/null bs=1M
100000+0 records in
100000+0 records out
104857600000 bytes (105 GB) copied, 79.5248 s, 1.3 GB/s

Performance verlies van ZFS vs XFS is acceptabel. Performance is nog steeds zeer goed.

Maar ZFS blijft me dwars zitten, bijvoorbeeld het feit dat je gewoon 1/64 van de capaciteit inlevert.

[DXaroth]

Q schreef op zondag 27 april 2014 @ 11:36:
De enige reden waarom ik ZFS zou gebruiken is dat ZFS mij op zijn minst kan vertellen dat er file corruptie optreedt en welk bestand het is. Het hoeft niet eens gerepareerd te worden, als ik maar weet wat stuk is.

[...]

Maar ZFS blijft me dwars zitten, bijvoorbeeld het feit dat je gewoon 1/64 van de capaciteit inlevert.

1/64e is verwaarloosbaar voor waar het tegenover staat.. die ruimte die je inlevert is juist om dat te realiseren

[Extera]

/me Extera komt ook de kroeg in

Nieuw speelgoed, altijd leuk!



Als de boel in elkaar zit zal ik hem eens posten in het show-off topic met meer info

[FireDrunk]

Oeeeeh...

[heavy breathing]

On another note:

Is er hier iemand met een B85 bord? Geen Biostar B85N, maar bijvoorkeur een iets beter merk als Intel of ASUS?

Ik ben op zoek naar iemand die de ACPI informatie even kan dumpen.

[Voor 76% gewijzigd door FireDrunk op 30-04-2014 15:50]

[CiPHER]

ASRock B85M-ITX bord heb ik. Mini-ITX. Heb je iets nodig?

[Q]

Extera schreef op woensdag 30 april 2014 @ 15:35:
/me Extera komt ook de kroeg in

Nieuw speelgoed, altijd leuk!

[afbeelding]

Als de boel in elkaar zit zal ik hem eens posten in het show-off topic met meer info

Dat is een ri-vier kastje toch? Wat ga je er in stoppen?

[FireDrunk]

CiPHER schreef op woensdag 30 april 2014 @ 16:17:
ASRock B85M-ITX bord heb ik. Mini-ITX. Heb je iets nodig?

Het valt te proberen, ik zal binnenkort wel ff een handleiding posten.

[Q]

Misschien is dit totaal oninteressant, maar ik heb een obsessie met die Unrecoverable Read Error rate (URE) discussie van 10^14 (komt hij weer).

Ik ga nu zelfs zo ver dat ik 6 disks heb gevuld met data in blokken van 10G en over die files nu in een loop een md5sum over laat draaien.

De disks hebben verschillende leeftijden, condities en capaciteit. Als ze naar de knoppen gaan dan maakt mij dat niet uit, maar ik ben bereid ze een paar weken te laten stampen.

De discussie is natuurlijk: is dit een legitieme test. Ik sta open voor kritiek en ik wil de test daar ook zeker op aan passen.

Nu ben ik niet zo goed met statistiek maar bij een URE van 10^14 zou ik een URE in 12 TB aan data kunnen verwachten. Als ik dan over 6 disks verspreid en na 100 TB nog geen URE heb gezien, heb ik dan mazzel, of is er dan meer aan de hand?

Hoe lang moet ik de test laten lopen om dit ook statistisch relevant te maken? Ik stop er nog 2 disks bij met een totaal van 8 disks dus.

[Voor 7% gewijzigd door Q op 30-04-2014 20:26]

[FireDrunk]

Drop je wel alle fs caches? Anders is het geen goede test denk ik...

[mux]

Er zitten nog veel meer haken en ogen hieraan... je hebt ofwel te maken met zeer significante overhead (constant een integrity test over je data draaien), ofwel met een moeilijk te bewijzen URE gezien de firmware niet verplicht is om wetenschappelijk correcte data aan te voeren en dit ook zelden doet (bit error rates worden vaak pas op SMART geregistreerd als ze op een active block van toepassing zijn, niet als het block op tijd 'gered' is en vervangen door een reallocated sector).

Daarnaast ga je ook uit van een gelijk verdeelde error density, terwijl ik zo zou gokken dat bit errors juist heel erg patroongebonden zijn. Van wat ik me herinner van de eerste jaren van PMR zijn er zelfs 'verboden' datapatronen die een veel hogere error rate veroorzaken dan gemiddeld (dit wordt waarschijnlijk in firmware wel opgelost, maar toch). Je zult dus ook ofwel representatieve data moeten kiezen om te schrijven/lezen, ofwel eh... ik heb geen idee. Random data?

Stel dat dit allemaal niet het geval is en de mean data between errors perfect normaal verdeeld is, dan kun je je test draaien en eens beginnen met net zolang doorgaan tot je op iedere schijf minimaal twee errors bent tegengekomen. Daarmee kun je dan je mean data between errors uitrekenen en een eerste grove schatting van de standaarddeviatie doen. Ook belangrijk is dat je dan een eerste grove uitspraak kunt doen over de consistentie van je errors van schijf tot schijf. Indien alle schijven ongeveer even goed blijken te presteren kun je al je data op één hoop gooien, en dat is uiteraard heel erg fijn voor de hoeveelheid tijd die je test duurt.

Vervolgens begin je een écht grote test waarin je statistische significantie probeert te bereiken door bijvoorbeeld een of twee dozijn errors te triggeren op iedere schijf. Je hebt bij een Poisson/normale distributie een confidence level van 0,1 bij 30 observaties of 0,05 bij 100ish observaties. Indien alle schijven gelijk presteren betekent dit dus dat je maar een paar extra observaties nodig hebt voor p=0,1.

[Voor 3% gewijzigd door mux op 30-04-2014 21:16]

[Q]

Dus dit is wat ik nu doe:

1. Ik formatteer een disk met XFS en mount deze
2. Ik vul 'm met files van 10 GB per stuk die gevuld zijn met nullen.
3. Ik draai een MD5SUM van alle files en gooi deze naar een file
4. Ik draai in een eindeloze loop een md5sum -c van deze files op de disk.
5. wachten op read errors -> kernel errors in syslog.

Ik schrijf een aaneengesloten reeks nullen, maar de inhoud van de data lijkt mij juist niet relevant.
Zover ik weet slaan harde schijven de echte bitjes in een bepaalde encoding op zodat er dus geen lange
stukken aaneengesloten nul of een zijn.

Wat caches betreft, ik ben daar minder goed thuis in, maar beschrijf de gehele harde schijf en ik lees 'm ook in zijn geheel weer uit. Ik zie nu ~590 MB/s aan data over de interfaces gaan. Het is niet zo dat ik 1 x 10GB over en over test.

mux schreef op woensdag 30 april 2014 @ 21:15:
muur van tekst

Ik snap geen Toyota^TM van wat je schrijft en nu voel ik me heel dom.

Ik bekijk het misschien te simpel. Ik zit een beetje op het niveau van ELI5.

Als puber werkte ik ooit met MS-DOS en in die tijd hadden we te maken met zogenaamde 'bad sectors'. Een URE is in feite niets anders dan dat je een 'bad sector' treft en dat is nog al 'onfortuinlijk' als dat gebeurt op een degraded RAID array waarbij er geen parity meer beschikbaar is.

Een URE is wat mij betreft gewoon een dikke read error die in je syslog terecht komt. Data is ofwel uitleesbaar, of niet meer. Wat er onderwater gebeurd maakt mij niet uit, het gaat er om wat je op applicatie niveau kan verwachten.

Als een remapping tot gevolg heeft dat een disk te lang doet over het teruggeven van data en dat daardoor alsnog de degraded array klapt, dan is mijn test niet zo goed. Want als de disk zichzelf wel hersteld dan ga ik dat niet zien als een read error, behalve dan in de smartwaarden.

Ik denk dat ik mijn wiskunde boek maar eens uit het stof moet halen en moet kijken hoeveel data ik moet overpompen om het recht te kunnen claimen dat iets mogelijk wel/niet klopt.

Ik ben ook wel benieuwd hoe fabrikanten zelf hun UREs echt testen + berekenen.

Ik besef alleen dat mijn huidige test misschien niet zo heel spannend is. Een aantal van de schijven heeft een 10^15 specificatie... Ik zou me eigenlijk tot de 10^14 schijven moeten beperken.

[Voor 5% gewijzigd door Q op 30-04-2014 23:45]

[FireDrunk]

@Q en Mux, een URE != een Bad Sector.

Een Bad Sector is een PERMANENT kapotte sector...

Een URE kan ook gewoon een mislukte read zijn, waar er ook nog eens niet genoeg ECC data gelezen is om de fout te herstellen.

Veel voorkomende reden: Een zonnevlam ofzo? Electromagnetische straling? Who cares... iig, een schijf maakt gewoon wel eens fouten, zonder dat er fysiek iets kapot is.

Een URE rate van 10 tot de 14e wil niet zeggen dat er elke 2TB gelezen een sector stuk gaat... Dat zou wel hard gaan

@Q
Wat Mux bedoeld is: eens in 10 tot de 14e wil niet zeggen, na 10 tot de 14e bytes... Het is ERGENS tussen die waardes 1 keer.

Maar het kan ook zomaar 2 keer zijn in 10 tot de 14e bytes... Het gaat om het gemiddelde...
Je kan geen gemiddelde trekken met maar 1 fout. Je moet minimaal een aantal meetpunten hebben om een goed en betrouwbaar gemiddelde uit te rekenen.

Wat mux zegt klopt exact, zorg er voor dat je op al je schijven 2 fouten hebt gezien, dan kan je een (redelijk) betrouwbaar gemiddelde uitrekenen.

[Voor 33% gewijzigd door FireDrunk op 01-05-2014 09:26]

[mux]

ELY5:

Je wil testen hoe vaak UREs voorkomen. Impliciet neem je aan dat een dichtheid van 1 op 10^14-10^15 die opgegeven wordt door fabrikanten betekent dat je een gemiddelde waarde verwacht van 1 op 12.5TB (~1 op 12TiB). Ook impliciet neem je aan dat deze failure density gelijkmatig verdeeld, ongecorreleerd en random voorkomend is, en dat je dus sneller errors zult zien als je meer schijven tegelijk test.

Ik zeg dan: test al deze impliciete aannames! Test:
- Of fouten echt gelijkmatig verdeeld zijn
- Of fouten ongecorreleerd zijn
- Of fouten random voorkomen of juist op iedere schijf na een bepaalde hoeveelheid tijd/data

Deze aannames resulteren in een normaal verdeeld plotje van data geschreven tussen errors. Als al jouw aannames kloppen, dan kun je na een bepaalde hoeveelheid tijd (die je waarschijnlijk niet anders dan experimenteel kunt vaststellen) een mooi klokvormig plotje maken. Als je aannames niet kloppen, krijg je iets anders te zien. Een normaal verdeelde error density zou erg mooi zijn, want dan kun je heel nauwkeurig afschatten hoeveel UREs je nodig hebt voor statistische significantie (namelijk ~30 UREs voor p=0,1 en ~100 voor p=0,05). Zoniet, dan heb je er waarschijnlijk meer nodig.

Echter, ik merk ook aan dat het niet mals is om een test te ontwerpen die de 'echte' URE meet zonder de meting te beïnvloeden. Je bent sowieso een bepaalde hoeveelheid overhead aan het toevoegen (eerst een stukje writen, dan een stukje readen, continu bijhouden en wegschrijven wat je statistieken tot zover zijn) wat voor extra stress op de schijven zorgt tov een nominale belasting. Ook maak je een hele grote aanname, en dat is dat data overal op de schijf een gelijke kans heeft op errors, terwijl zowel de vorm als de locatie van de data een impact kan hebben waar je eigenlijk ook voor moet corrigeren.

UBEs (unrecoverable bit errors) zoals opgegeven door de fabrikant zijn inherent een low-level fenomeen wat je niet kunt testen door het syslog/eventlog te checken. Het is iets dat de schijf zelf (soms) rapporteert, en als hij het niet rapporteert dan moet je er zelf achter zien te komen door een integriteitscheck te draaien en alarm te slaan als ofwel de check faalt, ofwel de check er wel heel erg lang over doet om klaar te zijn. De definitie van een unrecoverable READ error behelst ook reallocated sectors (write errors niet).

[FireDrunk]

Je zou haast een standaard test script willen maken, wat onafhankelijk van het aantal disks / filesystem test en dat hier posten.

Als we allemaal gaan testen, gaat het een stuk sneller, en haal je weer wat onzekere factoren uit de test (hardware gerelateerde fouten)

[Q]

Bedankt voor de toelichting.

Ik wil wel een test script in elkaar zetten om dit goed te testen. De vraag is dan hoe dit script moet werken.

- 1x schrijven en oneindig lezen? (volgens mij geeft dit de meeste kans op fouten)
- r/w/r/w/r/w etc? (schrijven lijkt mij het magnetische veld van een bit te versterken)
- 1x schrijven 100 x lezen en dan weer schrijven?

Zou een dd if=/dev/zero of=/dev/device bs=1M en dan md5sum /dev/device > log.md5 + md5sum -c log.md5 een zinnige test zijn? md5sum zelf is eigenlijk niet boeiend: het gaat om de kernel error's die in
syslog verschijnen. We testen hier geen bitrot. Dus lezen met DD zou ook OK kunnen zijn.

Log bevat:

0. start tijdstip test
1. Tijdstip start read file x
2. tijdstip end read file x
3. status ok/not ok (bonus)
4. cummulative total time test is running

Script zou eigenlijk ook syslog moeten greppen op de 'gewenste' kernel errors.

Zoiets? Suggesties?

[Voor 6% gewijzigd door Q op 01-05-2014 15:30]

[FireDrunk]

Uh, je doet nu een hele grove aanname, en dat is dat de schijf de URE zelf detecteert...

Dat is niet altijd het geval...?

[mux]

At the end of the day... je moet toch érgens beginnen. Zorg ervoor dat je een nuttige hypothese formuleert en ga dat testen. Als je puur voor UREs (en niet voor bit errors in het algemeen) wilt gaan is 1x schrijven en daarna alleen lezen een prima optie. En dan maar net zo lang blijven doorgaan tot je een redelijke hoeveelheid UREs hebt gevonden zodat je kunt kijken hoe ze verdeeld zijn. Om randgevallen uit te sluiten kun je je data wel wat entropie meegeven (enkele tientallen MB van random.org trekken ofzo).

Het is sterk de vraag of alle UREs correct worden gerapporteerd en gecatched door het OS. Ik zou toch echt beginnen met het zelf checken van de data. Je kunt daar wel de syslog naast houden en als je ziet dat het ook na tientallen observaties nog perfect overeenkomt kun je het puur bij het syslog houden.

Hé, als je toch bezig bent: smijt je logfile realtime online zodat we mee kunnen kijken

[Q]

Script:

https://github.com/louwrentius/uretest

Ik draai nu een test om te zien of dit werkt.

Toelichting:

Het script is 'veilig' als in: het schrijft niet naar een disk.

Het script werkt als volgt:

1. maak MD5SUM van hele disk device (file system onafhankelijk) en schrijf naar file
2. start een eindeloze loop waarin je een md5sum -c check doet en log de resultaten in een log file

Mocht iemand het leuk vinden om met een of meerdere schijven te willen testen, dan zou leuk zijn.
Het is dan wel handig om aan te geven om welke schijf het gaat.

Persoonlijk denk ik dat de meeste 10^14 URE harde schijven zo gespect zijn omdat je dan wat makkelijker je dure enterprise schijfjes kunt verkopen die 10^15 zijn gespecced.

Alle schijven die ik test zijn trouwens 7200 RPM schijven, ik heb geen 5400 RPM spul.

code:

--------------------------------------
| Dev | Model                 | GB   |   
--------------------------------------
| sda | SAMSUNG HD103UJ       | 1000 |   
| sde | SAMSUNG HD501LJ       | 500  |   
| sdf | SAMSUNG HD103UJ       | 1000 |   
| sdg | SAMSUNG HD501LJ       | 500  |   
| sdh | WDC WD3200JS-00PDB0   | 320  |   
| sdm | WDC WD740GD-75FLA1    | 74   |   
| sdn | SAMSUNG HD501LJ       | 500  |   
| sdo | WDC WD5000AAKS-00V1A0 | 500  |   
| sdq | WDC WD5000AAKS-00V1A0 | 500  |   
| sdr | SAMSUNG HD501LJ       | 500  |   
--------------------------------------

- De 500 GB samsung heeft een 10^14 spec volgens deze site.
- De 1 TB doet echter 10^15.
- De 320 WD doet 10^15
- De 74 GB 10K rpm doet 10^15
- De 500 GB WD's doen 10^14

Met ~500+ MB/s over de disks kost het nog 23 dagen voordat ik 1 petabyte aan verkeer heb gegenereerd... Wat stiekem mijn doel is.

[Voor 125% gewijzigd door Q op 03-05-2014 20:08]

[FireDrunk]

Zijn er nog meer mensen die (alweer) ZFS Mountall problemen hebben met ZFSonLinux icm Ubuntu?

Ik word er (weer) knettergek van....

[Q]

Hoe zou je het probleem kunnen reproduceren?
Ik weet van niets.

[FireDrunk]

Heb het uiteindelijk op kunnen lossen.. Geen idee wat nou precies het probleem is, maar de Mountall van Ubuntu laad soms eerder (of te snel) voordat ZFS helemaal klaar is.

Dit zorgt er dus voor dat je pools ongemount blijven na boot... Lekker handig.

https://github.com/zfsonl...l-FAQ-and-troubleshooting

Het is nogal een bekend probleem.


Heb het wel werkend gekregen, met het devicewait scriptje, en een keer de zpool.cache file weggooien, en de pool opnieuw importeren.

Rare is, ik had dit probleem voorheen met mijn M1015, en daar kon ik het begrijpen, maar sinds gister heb ik gewoon de schijven onboard, en daar zou je dit probleem niet verwachten...

[BartNL]

Q schreef op donderdag 01 mei 2014 @ 22:22:
Mocht iemand het leuk vinden om met een of meerdere schijven te willen testen, dan zou leuk zijn.
Het is dan wel handig om aan te geven om welke schijf het gaat.
.....
Met ~500+ MB/s over de disks kost het nog 23 dagen voordat ik 1 petabyte aan verkeer heb gegenereerd... Wat stiekem mijn doel is.

sort of test doe ik wanneer ik de raid volumes op mijn fileserver check. Gisteren een viertal volumes gechecked. Resultaat,

Time	Device	Event Type	Elapse Time	Errors
2014-05-05 05:16:59	R5-6x4TB#11	Complete Check	017:55:38	0
2014-05-05 05:10:49	R5-6x4TB#12	Complete Check	017:49:28	0
2014-05-04 21:24:49	R5-6x4TB#22	Complete Check	009:16:38	0
2014-05-04 20:26:54	R5-6x4TB#21	Complete Check	009:05:34	0

Gebruikte schijven zijn allemaal 4TB Seagate ST4000DM000 en bovenstaande checks zijn bij elkaar 96TB aan bruto schijfruimte. Verschil in de tijden zit waarschinlijk in de gebruikte stripe size van 128kB (trager) vs 1024kB (sneller).
Deze volume checks doe ik ongeveer eens per 2 maanden en ik kom dan weinig errors tegen. Als er al errors zijn, misschien 20(?) op 600TB(?) aan checked data, dan merk ik daar niets van in de data. Wel is er maandje terug een array degraded geraakt doordat een schijf uit de array werd gegooid. Die array werd na vervangen van schijf probleemloos hersteld.
Zo lang de resultaten zo blijven volstaat hardware raid met 10^-14 gespecificeerde schijven voor mij

[Q]

Die 20 RAID errors zijn juist erg interessant. Wat voor soort fouten waren dat? Parity mismatch met de data?
Is dan de data stuk of de parity? Dat is precies de 'rot' waar ZFS tegen zou moeten beschermen en jouw stat zou misschien wel eens mijn 'hypothese' onderuit kunnen halen.

Linux MDADM is heel goor wat dit betreft: als de parity niet klopt berekent MDADM de parity gewoon opnieuw. Met RAID6 wordt daar slimmer mee omgegaan (weet niet of dat al in de kernel zit) omdat je dan kunt bepalen of de parity of data rot is. En dan kun je ofwel de parity of data herberekenen.

[Voor 34% gewijzigd door Q op 05-05-2014 13:19]

[BartNL]

Ja, ik stel de controller in op scrub bad.blocks en herberekening van parity. Die láátste keuze is arbitrair omdat ik niet weet of data of parity goed is. Omdat ik check terwijl ik geen probleem met data ervaar gebruik ik deze instelling. Dit is een zwak punt bij hardware raid.

[Dadona]

Misschien is dit interessant om in een apart topic te bespreken om het eens goed uit te werken?

[FireDrunk]

Nee!, plannen op bierviltjes!!!

[Dadona]

Daar staan de beste ideeën op, is dit er zo één dan? Het hangt er een beetje vanaf of je het idee echt wil doorzetten. Voor als je het iets serieuzer wil hebben dan is het misschien handig om het buiten de kroeg uiteen te zetten.

[BartNL]

Dadona schreef op maandag 05 mei 2014 @ 19:01:
...als je het iets serieuzer wil hebben ...

tot dusver kloppen theorie en praktijk m.b.t. de URE discussie niet dus is het wat mij betreft is het hier wel op zijn plek

[Voor 6% gewijzigd door BartNL op 05-05-2014 19:19]

[Dadona]

Het ging mij er eigenlijk om of Q het nu eens echt een keer goed uit wil zoeken. En dat lijkt mij dan echt iets om in een apart topic te bespreken.

[Q]

Ik vind dit juist mooie kroegenpraat. Zit nu op ~168 TB verkeer en geen verandering in SMART waardes van de disks + ook geen error messages in syslog. Op naar de petabyte.

Zag een mooie duc op het werk. Was zo jaloers. Mis motorijden enorm, maar heb niet echt plek voor een motor meer.

[Voor 3% gewijzigd door Q op 05-05-2014 21:34]

[FireDrunk]

Zijn er al mensen hier die al met BTRFS gespeeld hebben? Ik lees dat bcache icm BTRFS een leuk alternatief zou moeten zijn voor ZFS icm ZIL/L2ARC.

bcache is misschien niet zo goed als ZIL en L2ARC als het gaat om checksumming, maar het mist toch wel een flink aantal nadelen die ZFS wel heeft.

Zo kan je 1 device makkelijk gebruiken voor zowel Read als voor Write caching.
Zo kan je 1 device gebruiken voor een oneindig aantal fysieke drives (meerdere pools dus ook).
Het cache blijft werken na een reboot

Ga binnenkort maar eens kijken met 2*2.5" 320GB Schijfjes icm BTRFS mirror en 4*80GB Intel SSD's als cache.

[Q]

FireDrunk schreef op dinsdag 06 mei 2014 @ 16:24:
Zo kan je 1 device makkelijk gebruiken voor zowel Read als voor Write caching.
Zo kan je 1 device gebruiken voor een oneindig aantal fysieke drives (meerdere pools dus ook).
Het cache blijft werken na een reboot

Ik hou mijn vak niet bij, dat is onwijs gaaf.

Het is zo jammer dat die RAID6 zooi nog niet af is (of bewijs ik wederom dat ik niet up-to-date ben?)
want zo'n cache kan dan heel mooi de nadelen van RAID6 maskeren.

[FireDrunk]

De engine is wel af, alleen de checksum -> parity validatie niet. Dus bij het tegenkomen van bad blocks gebeurd er nog niet hetzelfde als bij ZFS voor zover ik begrepen heb.

[Extera]

Q schreef op woensdag 30 april 2014 @ 19:52:
[...]
Dat is een ri-vier kastje toch? Wat ga je er in stoppen?

Klopt!
Er komt een asrock B75-Pro3-M in met om te beginnen 8GB geheugen. Een upgrade naar 24GB staat op de planning. Er zit een G2020 in.

Er komen 2 pools in, 1 voor VMware (4x 2x1TB mirror) en 1 voor media (5x4TB zRaid1).
In de toekomst plaats ik er nog 2 SSD's bij als SLOG en L2ARC.


De media pool spreek ik aan via een 2Gbit channel, de VMware pool hangt via 10Gbit CX4 aan mijn ESX Host en wordt via iSCSI aangeboden.

[FireDrunk]

Btrfs is not currently stable with bcache (Feb 2014) - this is a known bug and being worked on, but for the moment I'd strongly advise against this use.

[Q]

Extera schreef op woensdag 07 mei 2014 @ 08:39:
[...]
Klopt!
Er komt een asrock B75-Pro3-M in met om te beginnen 8GB geheugen. Een upgrade naar 24GB staat op de planning. Er zit een G2020 in.

Er komen 2 pools in, 1 voor VMware (4x 2x1TB mirror) en 1 voor media (5x4TB zRaid1).
In de toekomst plaats ik er nog 2 SSD's bij als SLOG en L2ARC.


De media pool spreek ik aan via een 2Gbit channel, de VMware pool hangt via 10Gbit CX4 aan mijn ESX Host en wordt via iSCSI aangeboden.

Ok helder. Die voor media wordt RAIDz1 neem ik aan. Waarom een consumenten bordje, geen ecc?

FireDrunk schreef op woensdag 07 mei 2014 @ 10:57:
[...]

Iets anders, volgens mij is MPTCP eigenlijk wel interessant voor als je meerdere gigabits aan elkaar wilt knopen like bonding. Ook maar eens een keertje naar kijken.

[Voor 19% gewijzigd door Q op 07-05-2014 23:17]

[Extera]

Q schreef op woensdag 07 mei 2014 @ 23:15:
[...]
Ok helder. Die voor media wordt RAIDz1 neem ik aan. Waarom een consumenten bordje, geen ecc?

Het moederbord met CPU en mem had ik nog liggen.
Op dit moment draait mijn NAS (alleen de media pool) virtueel in VMware met de IBM 1015 doorgegeven via passthrough, daar zit wel ECC in.

Ik heb besloten om de NAS toch weer los te trekken, zodat ik 8GB vrij maak in VMware, en ik kan meer geheugen in de fysieke NAS steken zodat ik dedup kan aanzetten voor de VMware pool.

Helaas is de CX4 kaart DOA, dus ik moet even wachten op een nieuwe.
Best interessant, met 2 van die kaartjes schijn je gewoon P2P moeten kunnen koppelen, dan heb je relatief goedkoop 10Gbit. Ik ben bij CX4 uitgekomen omdat ik toevallig een switch heb met 4 CX4 poorten...

Mijn media pool heb ik encrypt, dus ik moet nog even kijken hoe dat gaat draaien nu ik verhuis naar een systeem zonder hardware encryptie. (AES).

[Voor 9% gewijzigd door Extera op 08-05-2014 08:36]

[Q]

Jammer van de CX4 kaart. Doet ZFS geen native encryptie?

[FireDrunk]

@Extera, welke switch heb je?

[Extera]

@ Q: Encryptie wordt toch ge offload naar hardware indien je hardware dit support? De G2020 doet dit niet.
@ Firedunk. Een HP 2900

[Voor 33% gewijzigd door Extera op 08-05-2014 10:04]

[FireDrunk]

Power Consumption: 200W

[Extera]

Ik zal het eens meten... 40W ligt denk ik meer in de richting op dit moment
Nog veel, maargoed, deze switch is ook niet echt voor thuisgebruik

[Voor 4% gewijzigd door Extera op 08-05-2014 10:32]

[The Executer]

Grrr, zoontje heeft vandaag even een schijf op de grond gegooid. Onbewust aangezien hij net een jaar oud is, maar toch... Schijf spint nog netjes op, Windows herkent de grootte maar is wel de partitietabel kwijt. Nu maar even een ouderwetse Chkdsk er overheen. Eerste resultaat:
- bestandsrecordsegment XXXXX is onleesbaar
- bestandsrecordsegment XXXXX is onleesbaar
- bestandsrecordsegment XXXXX is onleesbaar
- bestandsrecordsegment XXXXX is onleesbaar

[Lednov]

omdat het ook een CSL kroeg is, ik zie wel aankondigen staan voor de nieuwe B95 moederborden van de haswell refresh, alleen daar houdt het mee op. laatst zijn de Z/H97 geintroduceerd. alleen dus niet de B95. iemand die daar toevallig meer over weet?

oh ja *proost*

[Voor 3% gewijzigd door Lednov op 09-05-2014 17:31]

[Q]

Extera schreef op donderdag 08 mei 2014 @ 10:01:
@ Q: Encryptie wordt toch ge offload naar hardware indien je hardware dit support? De G2020 doet dit niet.
@ Firedunk. Een HP 2900

AES encryptie is niet zo zwaar voor een processor anno 2014, je gaat dan geen gigabytes per seconden meer halen, maar de performance zou nog steeds bruikbaar moeten zijn.

[Extera]

Proost Firedunk, op jou verjaardag

[FireDrunk]

Danku!
* FireDrunk trekt een pilsje open!

[enthernal]

Proficiat Firedrunk

Even terloops een simpele vraag, maar op het internet spreken verschillende partijen elkaar tegen. Als je op een RAID5 (of gelijkaardige) array een grote stripe size hebt, dan is het toch zo dat data sneller weg geschreven wordt, maar je minder IOPS haalt, en omgekeerd bij een kleinere stripe size? Maar meer dan de helft van wat ik vind beweert het omgekeerde, dat grote bestanden sneller verwerkt worden met kleine stripe size, hun theorie zijnde dat er dan 'meer schijven' worden aangesproken . Iemand die de twijfels kan weghalen voor ik mijn theorie in mijn eindwerk steek?

[FireDrunk]

Dat ligt er aan, het is een samenspel.

4K stripesize over 32 disks is niet handig. (voor sequentiële transfers)
16MB stripesize of 2 disks is ook niet handig (voor IOPS).

Je wil dat er per disk nog een substantiële hoeveelheid weggeschreven word dat het ongeveer als een sequentiële write gezien kan worden.

Dan praat je dus over > 256K ofzo.
Dus bij 8 schijven is een stripe size van 2 of 4MB prima.

Heb je een array van 32 schijven is 16MB waarschijnlijk beter, maar ga je echt puur op IOPS, zou ik proberen te zorgen dat de schijven 'maar' 4K weg hoeven te schrijven. Dat is vaak het hoogste punt qua IOPS.

Dus bij 8 Schijven een stripesize van 32K. Maar daar zullen inderdaad je sequentiële transfers onder lijden.

_{Waarom denk je dat ZFS met variabele stripesizes werkt}

[Voor 29% gewijzigd door FireDrunk op 12-05-2014 13:29]

[Q]

Ik zit met mijn URE test nu op 0.5 PB en opeens falen alle checksums van alle disks. Wat hier is gebeurd weet ik niet. Geen error's in syslog. Geen disk errors. Hoe dit alle disks kan treffen weet ik niet. Misschien een RAM (ECC!) issue of iets anders.

[enthernal]

FireDrunk schreef op maandag 12 mei 2014 @ 13:27:
_{Waarom denk je dat ZFS met variabele stripesizes werkt}

Daarom gaat mijn eindwerk ook ZFS Je moet natuurlijk wel goed kunnen uitleggen waarom het oude systeem brak is

[rikadoo]

Is er iemand die ervaring heeft met deze server?
pricewatch: HP Proliant ML310e Gen8 v2 (724160-425)

Ik ben aan het kijken voor een ZFS / NAS server, Nu ben ik ook aan het kijken voor ESXi zodat ik daar ook mee zou kunnen experimenteren. Iemand enig idee of dit goed werkt met deze server? En hoeveel schijven kunnen er in? volgens de site 4 maar volgens andere sites is deze ook weer uit te breiden met 2 slots.

[FireDrunk]

Vaak moet dat met speciale beugels van HP en heb je nog speciale kabel kits nodig ook... Voor veel schijven zijn het vaak niet de meest gebruikersvriendelijke producten...

[rikadoo]

FireDrunk schreef op woensdag 14 mei 2014 @ 15:05:
Vaak moet dat met speciale beugels van HP en heb je nog speciale kabel kits nodig ook... Voor veel schijven zijn het vaak niet de meest gebruikersvriendelijke producten...

Oke, ik zou wel graag wel wat meerdere HDD willen bij plaatsen in de toekomst. Verder zijn de specs best goed voor de prijs als je het mij vraagt. Maar eens verder kijken dan.

Heb momenteel 2 Synology DS209 en DS211 met ieder 2 schijven, maar die beginnen vol te raken. Was dus van plan iets te kopen (zelfbouw) om zo meer ruimte te creeëren voor extra disks. en dan in 1 systeem.

[Voor 18% gewijzigd door rikadoo op 14-05-2014 15:10]