Het grote DIY RAID NAS topic deel 3

[DXaroth]

Verwijderd schreef op zondag 23 februari 2014 @ 23:19:
Gigabit is een product met een hoge 'bandbreedtevertragingsproduct'. Dat betekent dat de interface relatief een veels te hoge latency heeft om de bandbreedte makkelijk vol te krijgen. Je zult aan queueing moeten doen om de gigabit interface 'bezig' te houden anders komt deze stil te vallen. Alle momentjes samen dat de link stil ligt, zorgt ervoor dat je niet de 112MB/s maximale throughput behaalt, maar slechts een gedeelte hiervan. Daar komen nog protocol issues bij, verschillen in OS en verschillen in netwerkapparatuur. Dat samen kan voor slechtere resultaten zorgen, maar soms is het voor mij ook totaal onduidelijk waarom het ene systeem beter doet dan het andere.

Maar ik zoek het dus wel heel duidelijk in de softwarehoek, en niet in de richting van de hardware. Dat laatste kun je enigszins ook meten; de CPU-belasting kan tijdens gigabit bij mij oplopen tot 3,4% bij 80MB/s write met een Intel Ivy Bridge quadcore (3570) en 32GiB RAM. CPU is denk ik het probleem niet; maar bij interruptproblemen kan dat soms wel zo lijken omdat je een heel hoog CPU verbruik ziet.

Ik weet niet of ik hier om moet lachen, of huilen.. dit is zo verkeerd op zo veel plekken en op zo veel manieren

[Phuncz]

Als je serieus wilt worden genomen, zal je toch met argumenten moeten komen.

[Paul]

Je zou kunnen beginnen met het onderbouwen waarom je dat denkt?

[jacovn]

Hier zie ik copy snelheden van 103-105 Mbyte/sec/
PC: intel i7-920 met 12 GB ram en windows 7, met een intel PCI-E NIC kaart.
NAS: Xeon E3-1220 met 24 GB ram en ZfsGuru op FreeBSD met onboard intel NICs op supermicro MB.

Belasting van de ZFSguru machine geeft 65% aan, PC 5-8%

Copieer ik via 10 GE kaarten (intel x520-DA2) dan zie ik 51% op de NAS en 5-8% op mijn PC.
Dan heb ik copy snelheden van 160-200 Mbyte/sec (PC kant IO system limiteerd)

Over de 1 GE interface wordt de interface zo zwaar belast dat ik geen webpagina meer kan laden met fatsoen.

[ Voor 10% gewijzigd door jacovn op 24-02-2014 10:19 ]

[DXaroth]

Paul schreef op maandag 24 februari 2014 @ 09:55:
Je zou kunnen beginnen met het onderbouwen waarom je dat denkt?

Eerst moet je dingen opdelen in de verschillende niveaus waar het op werkt; jawel, het beroemde OSI level.

Layer 7 : Application (Samba)
Layer 5 : Session (Cifs)
Layer 4 : Transport (TCP)
Layer 3 : Network (IP)
Layer 1 : Physical ( cat6 )

In zowel laag 4, als laag 5, als laag 7, zit queueing ingebouwd; dit is hoe die systemen zijn gemaakt, en het vol krijgen van de gbit verbinding is precies -waarom- het gemaakt is.

Samba is verantwoordelijk voor rechten, voor het lezen en schrijven naar bestanden; zijn queue is meerendeel FS-level gericht (buffered reads om de winst te pakken van sequential reads voor zo veel dat kan)

Cifs zet dat om naar de netwerk stack, deze houdt een send/read queue bij, de send queue wordt automatisch geflushed naar het netwerk, en de read queue wordt afgehandeld door samba

TCP heeft zijn eigen kernel queue (/proc/sys/net/ipv4/tcp_rmem / tcp_wmem, iemand?) die gemaakt is om het versturen van packets, en het afhandelen van collisions te doen zonder dat dat op applicatie/sessie level gedaan hoeft te worden.

Bedenk je dan dus, dat een goed werkend stuk software (wat samba over het algemeen is), zal zorgen dat deze 3 buffers goed samen werken, en altijd zo vol mogelijk zitten.. de enige reden dat deze queues niet vol zitten zal door externe factoren komen (krijgt samba de CPU tijd om zijn lees buffer te vullen, en kan deze goed doorgezet worden naar cifs?), denk aan hoge CPU load door andere processen (of wellicht iets waardoor samba zelf veel CPU in gebruik zal nemen (I/O locks) ), of geen beschikbare RAM om als buffer te fungeren.

Ook kunnen de problemen elders liggen, kan je NIC's chipset het aan (roepen dat je gigabit bent, en gigabit zijn, zijn twee compleet verschillende dingen), heb je een brakke cat5/6 kabel, de switching throughput van je switch(es) (en in hoeverre die al belast is ... een 24-poort switch die 20gbit aan kan, kan wellicht niet meer 1gbit-per-link aankunnen zodra er >10gbit over de backplane gaat)

Overigens; als je toch rekening gaat houden met protocol issues, begin dan bij de eerste; TCP. het is vaak de norm dat als je van bit naar byte gaat in term van netwerk, dat je een ratio 1:10 aanhoudt... het is ook een van de redenen waarom jumbo frames nut hebben; die verlagen de overhead van elke TCP packet, door te zorgen dat packets groter zijn (en daarom minder packets voor dezelfde hoeveelheid data, en dus minder overhead per data)... heb je een gigabit verbinding, dan is 100mbyte/s haalbaar.. alles meer is bonus, maar bij de 112 ga je enkel in de buurt komen met jumbo frames.

[FireDrunk]

Om daar nog even aan toe te voegen. Windows doet by-default receive side scaling. Dit vergroot dynamisch tijdens transfers de buffers (die 8k / 16k waar CiPHER het dus over heeft, veranderen continu).

Dit zorgt voor een prima verloop omdat je voor elke soort file transfer misschien wel een ander soort buffer wil.

Er zijn hele studies over receive side scaling gedaan, en ik geloof dat microsoft het zo slecht nog niet doet...

C:\Users\Thijs>netsh interface tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : disabled
Direct Cache Access (DCA)           : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : none
ECN Capability                      : disabled
RFC 1323 Timestamps                 : disabled
Initial RTO                         : 3000
Receive Segment Coalescing State    : disabled

[ Voor 42% gewijzigd door FireDrunk op 24-02-2014 12:13 ]

[oddy]

InflatableMouse schreef op donderdag 20 februari 2014 @ 21:11:
Kan iemand mij vertellen of de LSI SAS 9211-8i ook te flashen is voor JBOD net als de IBM variant voor ZFS?

En de IBM M5015? Da's volgens mij dezelfde als de M1015 maar dan met cache en BBU? Is die ook om te zetten voor JBOD?

Dank!

Ben ik juist ook mee bezig! Heb juist voor de M1015 deze handleiding om te flashen gevonden: http://www.servethehome.com/ibm-serveraid-m1015-part-4/
Hier kan je de M1015 flashen met LSI firmware, en zo als JBOD gebruiken.

Van de 5015 heb ik geen idee...

[Verwijderd]

DXaroth schreef op maandag 24 februari 2014 @ 09:52:
Ik weet niet of ik hier om moet lachen, of huilen.. dit is zo verkeerd op zo veel plekken en op zo veel manieren

Lachen of huilen is niet nodig. Het is juist een mooi iets als jij kennis kan overdragen aan een ander, zeker wanneer die ander open staat voor die kennis.

Verder wil ik verzoeken om mijn posts niet als absolute waarheid te beschouwen; ik ben ook maar een mens. En de kennis die ik bezit uit eigen onderzoek danwel kennis opgedaan van diverse bronnen zal zeker niet perfect zijn, al helemaal niet op netwerkgebied.

Dat gezegd; als je reageert, reageer dan op een positieve manier. Een die inderdaad op de materie ingaat. Ik vraag me namelijk af of je op dezelfde manier had gereageerd als mijn naampje zwart was geweest ipv rood. Als dat klopt, vind ik dat jammer omdat dat betekent dat je mij niet als gelijkwaardig behandelt; als user. Ik mag dan gevraagd zijn dit forum te modereren, ik beschouw mijzelf nog in eerste plaats als gebruiker of forumlid. Mijn mening in zie zin is niets meer of minder waard dan die van de ander; en zal op de inhoud gewaardeerd moeten worden.

---

DXaroth schreef op maandag 24 februari 2014 @ 10:23:
Eerst moet je dingen opdelen in de verschillende niveaus waar het op werkt; jawel, het beroemde OSI level.

ISO-OSI is een leuk model; alleen bestaat het volgens mij alleen in theorie. De presentatielaag is volgens mij geen onderdeel van de reguliere TCP-stacks. De daadwerkelijke TCP stacks die in gebruik zijn, zijn volgens mij wel geïnspireerd op ISO-OSI, maar geen directe implementatie daarvan. Je noemt CIFS als zijnde onderdeel van laag 5, maar ik dacht juist dat CIFS net als HTTP en andere protocollen, gewoon op laag 7 (applicatielaag) bevinden.

Daarnaast rijst bij mij de vraag: wat is de relevantie van dit argument ten opzichte van mijn post waar je op ageerde?

In zowel laag 4, als laag 5, als laag 7, zit queueing ingebouwd; dit is hoe die systemen zijn gemaakt, en het vol krijgen van de gbit verbinding is precies -waarom- het gemaakt is.

Waarom lukt het dan niet in de praktijk om gigabit verzadigd te krijgen? De hardware zou prima in staat moeten zijn om dit te realiseren. En in low-level tests kun je af en toe ook maximale bandbreedte behalen; zoals met iPerf bijvoorbeeld. Maar dan nog kan het zijn dat je met CIFS en andere high-level protocols geen gigabit volkrijgt.

Is dat de schuld van de hardware, of de software? Mijn betoog kwam neer dat ik hier de schuldige zoek in de softwarehoek; niet die van de hardware. Bestrijd je dat argument nu juist, of omarm je deze? Dat is mij niet geheel duidelijk.

Samba is verantwoordelijk voor rechten, voor het lezen en schrijven naar bestanden; zijn queue is meerendeel FS-level gericht (buffered reads om de winst te pakken van sequential reads voor zo veel dat kan)

Als de lagere lagen hun werk doen, hoeft een applicatie helemaal niet aan read-ahead of buffering te doen. Denk ik dan...

en het afhandelen van collisions te doen zonder dat dat op applicatie/sessie level gedaan hoeft te worden.

Met collisions doel je op de fysieke laag? CSMA/CD? Nogal logisch dat dit niet op appliatieniveau gedaan wordt? Ook hier geldt: wat is precies de relatie met het bericht waarop je reageert? Dat is mij namelijk niet duidelijk. Ik wil graag begrijpen waarom je mijn quote zo verkeerd vond; dat is mij nu nog niet duidelijk.

Bedenk je dan dus, dat een goed werkend stuk software (wat samba over het algemeen is), zal zorgen dat deze 3 buffers goed samen werken, en altijd zo vol mogelijk zitten.. de enige reden dat deze queues niet vol zitten zal door externe factoren komen (krijgt samba de CPU tijd om zijn lees buffer te vullen, en kan deze goed doorgezet worden naar cifs?), denk aan hoge CPU load door andere processen (of wellicht iets waardoor samba zelf veel CPU in gebruik zal nemen (I/O locks) ), of geen beschikbare RAM om als buffer te fungeren.

Geen RAM voor buffers is natuurlijk onzin met 1GiB+ RAM; in de meeste gevallen zal BSD ook crashen als het geen TCP buffers kan alloceren. Onvoldoende CPU-kracht is ook niet de primaire reden dat gigabit bij thuissituaties (zoals een zelfbouw NAS) niet verzadigd raakt. In veel gevallen staat de CPU uit zijn neus te vreten. De oorzaak moet elders liggen.

Ook kunnen de problemen elders liggen, kan je NIC's chipset het aan (roepen dat je gigabit bent, en gigabit zijn, zijn twee compleet verschillende dingen), heb je een brakke cat5/6 kabel, de switching throughput van je switch(es) (en in hoeverre die al belast is ... een 24-poort switch die 20gbit aan kan, kan wellicht niet meer 1gbit-per-link aankunnen zodra er >10gbit over de backplane gaat)

Het feit dat een realtek NIC vervangen door een Intel NIC in sommige gevallen tot sterk verbeterde doorvoer leidt, doet vermoeden dat er ook hardwareissues kunnen zijn, waar jij denk ik op doelt in deze quote. Onduidelijk is of het echt de hardware is, of juist dat drivers kunnen zorgen dat bepaalde Realtek modellen onder bepaalde OS geen goede performance geven.

Maar ik vind het interessanter om van een simpele situatie uit te gaan: zelfbouw NAS met voldoende CPU/RAM, gigabit met goede kabel zonder switch naar een desktop client. Wat kan daar de reden van zijn als je slechte Samba performance krijgt? Moet je dat zoeken in de hardwarekant, of juist meer de software? Mijn vorige bericht ging over dat ik juist de softwarekant verdenk van de oorzaak van veel van dit soort problemen.

Overigens; als je toch rekening gaat houden met protocol issues, begin dan bij de eerste; TCP. het is vaak de norm dat als je van bit naar byte gaat in term van netwerk, dat je een ratio 1:10 aanhoudt... het is ook een van de redenen waarom jumbo frames nut hebben; die verlagen de overhead van elke TCP packet, door te zorgen dat packets groter zijn (en daarom minder packets voor dezelfde hoeveelheid data, en dus minder overhead per data)... heb je een gigabit verbinding, dan is 100mbyte/s haalbaar.. alles meer is bonus, maar bij de 112 ga je enkel in de buurt komen met jumbo frames.

110MB/s haal ik anders met normale 1500 byte MTU; maar alleen write; de reads zijn met 80MB/s wel een stuk lager.

Verder interessant in dit verband is dat FreeBSD sinds enige tijd ook ondersteuning voor Netmap heeft; wat het zonder jumbo frames mogelijk zou maken om met heel weinig CPU-kracht enorm hoge packet rates kan bereiken. Vooral voor 10 gigabit ethernet zou dit interessant zijn.



Kortom, is het niet een redelijk argument om juist de softwareconfiguratie (kernel, drivers, appliatie) te verdenken van veel gigabit performance issues?

FireDrunk schreef op maandag 24 februari 2014 @ 12:10:
Om daar nog even aan toe te voegen. Windows doet by-default receive side scaling. Dit vergroot dynamisch tijdens transfers de buffers (die 8k / 16k waar CiPHER het dus over heeft, veranderen continu).

Dit zorgt voor een prima verloop omdat je voor elke soort file transfer misschien wel een ander soort buffer wil.

Is dit hetzelfde als de auto-tuning TCP buffers in FreeBSD 7 of 8? Dat is nog niet hetzelfde als de TCP receive window als ik het goed begrijp.

Daarnaast, als wat jij zegt klopt en die 8/16k bij Windows misschien initieel zo is maar door dynamische tuning vanzelf verandert tijdens de workload; dan hoe verklaar je het dat met het instellen van een hogere TCP receive window - zoals 128k - er wel hogere scores bereikt worden? Als de auto tuning zijn werk zou doen, zou dat na misschien de eerste seconde wel goed moeten gaan. Maar in plaats daarvan kun je op veel plaatsen verschil zien tussen iperf verricht met default waarden en met een opgegeven 128k+ receive window.

Nogmaals: ik ben helemaal geen expert op dit gebied. Maar het kan wel degelijk relevant zijn voor bouwers van een zelfbouw NAS. Een voorstel zou kunnen zijn een speciaal topic over gigabit tuning met concrete benchmarks en wat veranderde instellingen of juist veranderde hardware betekent voor het resultaat.

[DXaroth]

Verwijderd schreef op maandag 24 februari 2014 @ 20:56:
[...]
Verder wil ik verzoeken om mijn posts niet als absolute waarheid te beschouwen; ik ben ook maar een mens. En de kennis die ik bezit uit eigen onderzoek danwel kennis opgedaan van diverse bronnen zal zeker niet perfect zijn, al helemaal niet op netwerkgebied.

In dat geval is het handig als je je posts formuleert alsof ze meer mening-gebaseerd zijn, dan probeert te verkondigen dat het zo is.. je positie buiten mod hier gelaten, je staat ook bekend als devvert van ZFSguru, daarmee krijg je een bepaald aanzien waarin mensen denken 'hé, hij heeft zfsguru gemaakt, hij weet waar hij over praat'.. het klinkt onaannemelijk, maar het komt voor, en dat is dan jammer als het om on/halve waarheden gaat... gooi er wat 'ik denk', en 'ik vind' in, en het komt minder over dat je een waarheid probeert te verkondigen, en meer dat je je mening er over geeft die niet per se waar hoeft te zijn.


Daarbuiten, mijn 'manier' van discussiëren is wellicht wat kort door de bocht (en kan door sommige als agressief opgevat worden); dat is een bekend probleem, maar die bug heeft men nog steeds niet kunnen patchen .. dit is vaak niet mijn bedoeling.

---

OSI, in de groote lijnen, bestaat zoals het beschreven is; dat gezegd hebbende, dat betekend niet dat alle lagen 100% vertaalbaar zijn naar elke opstelling.. in het geval van Samba is er immers geen presentatie (dat zit compleet elders), maar de andere lagen bestaan wel (sommige buiten Samba, sommige in samba, sommige in de libraries van samba)... het is ook de reden dat een Layer 3 switch, een Layer 3 switch is

Dit is ook de hoofdreden dat ik ze per stuk verwoord, en presentatie daarbij weglatend.

Daarnaast rijst bij mij de vraag: wat is de relevantie van dit argument ten opzichte van mijn post waar je op ageerde?

Om een argument duidelijk te maken dat een ander het ook begrijpt, is het (soms) handig om wat context te genereren; in dit geval ga ik er van uit dat niet iedereen 100% bekend is met OSI, en de distincties tussen de doelen van de verschillende lagen, dus geef ik keywords zodat google de rest kan invullen...

Waarom lukt het dan niet in de praktijk om gigabit verzadigd te krijgen? De hardware zou prima in staat moeten zijn om dit te realiseren.

Dit is een van de grootste ergernissen met producten, marketing vs realiteit. Als een verkoper je verteld dat je auto 200km/h rijdt, wordt er niet bij verteld dat, bij die snelheid, je elke 100 meter mag tanken.. of dat de 200km/h pas na 3 uur accelereren gehaald wordt.

In het geval van meer IT gerichte zaken, wordt vaak gekeken of het product het in theorie aan kan, niet of het in een dagelijkse opstelling ook haalbaar is.. zoals ik aangaf, er zijn switches die 20gbit backplanes hebben die, mocht je 48 poorten hebben, pas de 20gbit haalt (wat dan dus betekend dat je 48x500mbit hebt, en NIET de 48x gbit snelheid die verkocht wordt).. zelfs de 24 poorts versies zullen merken dat, zodra je boven de 10gbit/s over de backplane gaat, er niet 1gbit-per-poort beschikbaar is, ook al suggereert de specifcaties dit wel.

In het geval van complete tests wordt het nog complexer, aangezien je dan gebonden bent aan elke genoemde laag dat deze optimaal presteren.. zodra er een stukje stof op een connector zit is het al niet meer optimaal, en kan er een onderdeel zijn dat opeens niet meer de verkochte performance kan waarmaken.. maar dan met 500 onderdelen en een enorme mogelijke hoeveelheid stof.

Hetzelfde geld overigens ook voor de benchmarks die ik geregeld langs zie lopen.. het is leuk om te zien dat je systeem 1.8gb/s haalt met een sequential read van nulletjes naar een loze ruimte, maar zodra je er iets anders mee doet (ooit geprobeerd random data weg te schrijven tijdens je test?), ga je dit niet meer halen.

Is dat de schuld van de hardware, of de software? Mijn betoog kwam neer dat ik hier de schuldige zoek in de softwarehoek; niet die van de hardware. Bestrijd je dat argument nu juist, of omarm je deze? Dat is mij niet geheel duidelijk.

Zonder een testopstelling is het lastig om een oorzaak aan te wijzen, maar je argumenten dat queues 'nodig zijn' ben ik het niet mee eens, en probeer ik te beargumenteren, je argument dat samba/cifs/kernel de oorzaak kan zijn ben ik het compleet mee eens.

Als de lagere lagen hun werk doen, hoeft een applicatie helemaal niet aan read-ahead of buffering te doen. Denk ik dan...

In de theorie, zou je aanname compleet correct zijn, en in een ideale wereld, zou dit enorm geweldig zijn.. maar dit is ook waar het vaak fout gaat.
Je os doet onder water enorm veel zooi, deel daarvan is zorgen dat elk proces kan draaien, en zijn werk kan doen.. tegelijk.
Nu kan een processor kern maar 1 echte taak tegelijk aan (hyperthreading en de andere truukjes daar buiten gelaten), dus zorgt je OS er voor dat alle processen hun CPU-tijd delen.. dit doet de scheduler, zonder dat een proces daar al te veel in te zeggen heeft.

Dus terwijl in een ideale wereld samba genoeg tijd zal krijgen om alles in te lezen en te versturen zonder dat er lege ruimtes op het net gaan komen, weet samba in dit geval niet of het genoeg ruimte gaat krijgen; I/O operaties zijn langzaam vergeleken met memory operaties, dus is de zinnige oplossing om, zolang er tijd is, die te gebruiken om een buffer aan te leggen, dit betekend dat zodra er weer tijd is om wat te doen, dat dit dan gelijk uit geheugen geladen kan worden (wat sneller is), zodat er veel minder kans is op lege ruimtes op het net. (daarnaast zal je kernel dit ook nog eens doen, wat in theorie dus zou moeten zorgen voor 100% verzadiging).

Geen RAM voor buffers is natuurlijk onzin met 1GiB+ RAM; in de meeste gevallen zal BSD ook crashen als het geen TCP buffers kan alloceren. Onvoldoende CPU-kracht is ook niet de primaire reden dat gigabit bij thuissituaties (zoals een zelfbouw NAS) niet verzadigd raakt. In veel gevallen staat de CPU uit zijn neus te vreten. De oorzaak moet elders liggen.

Geen ram voor de kernel taken is natuurlijk een enorm kleine kans (maar ZFS heeft wel eens bewezen dat dit kan gebeuren), maar niet alleen de kernel gebruikt buffers.
Als een applicatie dynamisch probeert te bufferen, dan zal deze dit doen zolang er ruimte is; dit lijkt in grote delen op hoe ZFS zijn ARC vult.. is er ruimte beschikbaar, dan wordt dit gebruikt.. is dit er niet, dan moet er wat anders gedaan worden.

Niet genoeg CPU is onder normale omstandigheden iets wat niet zo vaak zal voorkomen, totdat er iets mis gaat; denk aan processen die in een deadlock gaan, deze kunnen makkelijk voor enige tijd zorgen dat de CPU geen tijd heeft om andere dingen te doen (de kernel scheduler is goed, maar niet -zo- goed dat die situaties ontweken kunnen worden)...

Dit zijn beide voorbeelden van wat nog meer de oorzaak kan zijn van niet-100%-capaciteit op je netwerk... (kunnen, niet zijn)

Het feit dat een realtek NIC vervangen door een Intel NIC in sommige gevallen tot sterk verbeterde doorvoer leidt, doet vermoeden dat er ook hardwareissues kunnen zijn, waar jij denk ik op doelt in deze quote. Onduidelijk is of het echt de hardware is, of juist dat drivers kunnen zorgen dat bepaalde Realtek modellen onder bepaalde OS geen goede performance geven.

Correct; er zijn brakke chipsets en er zijn goede chipsets... ervaringen zullen verschillen, maar Intels worden vaak aangeprezen als de betere.

Maar ik vind het interessanter om van een simpele situatie uit te gaan: zelfbouw NAS met voldoende CPU/RAM, gigabit met goede kabel zonder switch naar een desktop client. Wat kan daar de reden van zijn als je slechte Samba performance krijgt? Moet je dat zoeken in de hardwarekant, of juist meer de software? Mijn vorige bericht ging over dat ik juist de softwarekant verdenk van de oorzaak van veel van dit soort problemen.

De oorzaak van een probleem zoeken is veelal een geval van exclusion.. pak een werkende opstelling, en een waarbij dit niet zo is, en dan zal de oorzaak (iig deels) liggen in de verschillen er tussen.

Met deels doel ik dat de oorzaak wel in een overeenkomstig onderdeel kan zitten, maar dan zal dit in bijna alle gevallen te maken hebben met een van de verschillen.. denk hierbij aan drivers die bij sommige versies van bepaalde hardware minder goed werken dan bij anderen.

Dit betekend dat samba niet in noch uitgesloten is als oorzaak.. het kan een samenhang zijn tussen samba+driver, of driver+hardware (of sata driver + cifs kernel module).. dit maakt het enorm lastig om een oorzaak te leggen totdat je in een testlab verschillende onderdelen tegen elkaar uit kan spelen.

Kortom, is het niet een redelijk argument om juist de softwareconfiguratie (kernel, drivers, appliatie) te verdenken van veel gigabit performance issues?

Net zo redelijk als het verdenken van chipsets

[FireDrunk]

Even kort: CiPHER, wat je te snel afzwaait is de CPU.

Ook al is een CPU niet druk met daadwerkelijk rekenen, hij kan wel degelijk druk zijn met interrupts afvangen of met context switches (terwijl je dat niet direct terugziet in de CPU load).
Dat laatste bijvoorbeeld is wel interessant, want bijvoorbeeld Wikipedia zegt zei ooit ergens eens (kan even niet vinden waar) dat een systeem onafhankelijk van de CPU snelheid, maar (ongeveer) maximaal 10.000 context switches per seconden aan kan.
(maar of dit recent is weet ik ook niet)

Samba (Linux en BSD) is voor zover ik weet een 50/50 kernel/userland applicatie, waar het onder windows een full kernel protocol is (maar Windows is weer een hybride kernel, bla bla, gaat de discussie niet over ).

Dat zou ook zeker kunnen verklaren waarom Windows relatief makkelijker SMB verkeer verzet dan Linux/BSD.

[Verwijderd]

Phuncz schreef op maandag 24 februari 2014 @ 08:43:
* Phuncz valt flauw.
Hoe "geen switch" ? Het acroniem van een NAS staat voor Network Attached Storage ! Heiligschennis ! Verklaar je nader AUB

Om de switch ook te kunnen uitsluiten als potentiële oorzaak van performanceproblemen, kun je een opstelling maken zonder switch. Je sluit de kabel dan direct aan op beide computers. Vanaf gigabit (en sommige 100Mbps) heb je geen zogenaamde 'crosslink' (MDI-X) kabels meer nodig hiervoor. Als je maar één netwerkpoort hebt, betekent dit wel dat je geen internet of reguliere netwerktoegang hebt. Voor een testopstelling is dat natuurlijk niet zo'n probleem.

In realistische opstellingen kun je denken aan een 10-Gigabit kaart met 2 poorten die je in server en desktop stopt, en dan zonder switch direct aansluit op elkaar. De onboard gigabit aansluiting gebruik je dan voor regulier netwerk/internet-toegang. Dit is een opstelling die ik overwoog, hopende dat 10-gigabit ethernet goedkoper zou worden. Dat valt tot nu toe tegen; de X540-T2 doet nog steeds rond de 460 euro:
pricewatch: Intel Ethernet Converged Network Adapter X540-T2.

[Verwijderd]

Noot: ter bevordering van de leesbaarheid, post ik liever meerdere malen achter elkaar met kleinere berichten dan één megabericht. Klachten per DM.

DXaroth schreef op maandag 24 februari 2014 @ 21:59:
In dat geval is het handig als je je posts formuleert alsof ze meer mening-gebaseerd zijn, dan probeert te verkondigen dat het zo is..

Daar ben ik helemaal voor. Maar welke zaken bestrijd je nu precies? Het is mooi dat je achtergrondinformatie geeft en laat zien dat je kennis van zaken hebt. Maar waar ik vooral benieuwd naar ben is waarom je zo reageerde op mijn initiële post. Nu zei je al dat je misschien ietwat overdreven hebt gereageerd, maar wat er precies inhoudelijk mis aan is heb ik nog niet duidelijk van je vernomen.

Als je mijn post leest, kun je aan het taalgebruik zien dat er onderscheid gemaakt kan worden tussen de 1e en 2e paragraaf. De 1e paragraaf is geschreven alsof het zo is; dat is waar jij op doelt. De 2e paragraaf echter niet. Je kunt hieruit afleiden dat ik in de 1e paragraaf schrijf, ik acht als zijnde de waarheid met redelijke zekerheid; terwijl de 2e paragraaf ingaat op de zaken die ik nog niet weet of waar mijn gedachten naartoe gaan. De 1e paragraaf:

Gigabit is een product met een hoge 'bandbreedtevertragingsproduct'. Dat betekent dat de interface relatief een veels te hoge latency heeft om de bandbreedte makkelijk vol te krijgen. Je zult aan queueing moeten doen om de gigabit interface 'bezig' te houden anders komt deze stil te vallen. Alle momentjes samen dat de link stil ligt, zorgt ervoor dat je niet de 112MB/s maximale throughput behaalt, maar slechts een gedeelte hiervan. Daar komen nog protocol issues bij, verschillen in OS en verschillen in netwerkapparatuur. Dat samen kan voor slechtere resultaten zorgen, maar soms is het voor mij ook totaal onduidelijk waarom het ene systeem beter doet dan het andere.

Je ziet hier dat ik zaken als waarheid stel, terwijl het gekleurde gedeelte ingaat dat ik sommige dingen nog niet kan verklaren. De 2e paragraaf speculeert verder over de mogelijke oorzaken hiervan, duidelijk anders verwoord dan het begin van de 1e paragraaf:

Maar ik zoek het dus wel heel duidelijk in de softwarehoek, en niet in de richting van de hardware. Dat laatste kun je enigszins ook meten; de CPU-belasting kan tijdens gigabit bij mij oplopen tot 3,4% bij 80MB/s write met een Intel Ivy Bridge quadcore (3570) en 32GiB RAM. CPU is denk ik het probleem niet; maar bij interruptproblemen kan dat soms wel zo lijken omdat je een heel hoog CPU verbruik ziet.

gooi er wat 'ik denk', en 'ik vind' in, en het komt minder over dat je een waarheid probeert te verkondigen, en meer dat je je mening er over geeft die niet per se waar hoeft te zijn.

Dat probeer ik dus juist te doen. Daar waar ik dat niet doe, kun je veronderstellen dat ik het als waarheid zie.

Ik ben helemaal voor het genuanceerde verhaal. Als jij het beter weet, is het fijn als je mij hierin corrigeert. Maar tot nu toe kan ik wat je hebt geschreven niet helemaal relateren aan mijn post. Als je daar zin in hebt, kun je daar nog eens een poging toe wagen.

Daarbuiten, mijn 'manier' van discussiëren is wellicht wat kort door de bocht (en kan door sommige als agressief opgevat worden); dat is een bekend probleem, maar die bug heeft men nog steeds niet kunnen patchen .. dit is vaak niet mijn bedoeling.

Excuses aanvaard.

Nee hoor grapje. Maar.. begrijp wel dat als je mij zo tegenspreekt ik wel benieuwd ben wat er precies mis is aan hetgeen ik vertel. Als er iets is wat ik van je kan leren, sta ik daar helemaal voor open. Voor mij is het forum vooral een plek om scherp te blijven en bij te leren; met mensen die een hele andere achtergrond hebben met veel overlappende kennis, maar ook kennis die zich aan één zijde bevindt. Het is dan fijn als je dat kunt uitwisselen zonder gelijk een ander af te kraken, of iets in die richting. Probeer gewoon constructieve kritiek te geven voorzien van inhoudelijke argumenten. Dat is echt veel leuker dan het wellus-nietus. In elk geval voor mij.

[Verwijderd]

DXaroth schreef op maandag 24 februari 2014 @ 21:59:
OSI, in de groote lijnen, bestaat zoals het beschreven is; dat gezegd hebbende, dat betekend niet dat alle lagen 100% vertaalbaar zijn naar elke opstelling..

Voor zover ik heb begrepen is OSI juist een conceptueel model wat nooit helemaal realiteit is geworden. Het praktische model laat lagen 5 6 en 7 allemaal in de applicatielaag. Die zijn nooit als integraal onderdeel van de networkstack opgenomen. Als ik zoek op Wikipedia lijkt dat min of meer ook verwoord, zij het ietwat cryptisch: Wikipedia: Application layer. In dit verband wordt SMB (Server Message Block) ook genoemd. Dat betekent dat concreet Samba met SMB/CIFS op laag 7 van het OSI-model opereert, en simpelweg de applicatielaag in het praktische model dat wordt gebruikt; boven de TCP/IP-netwerkstack.

Wat jij volgens mij doet is zeggen: "ja CIFS dat heeft ook een kernelfunctie dus dat zie ik als laag-x". Maar dat is slechts een abstracte gedachte; in realiteit is het volgens mij zo dat applicaties gewoon de TCP/IP netwerkstack aanspreken. Nu gebeurt dat niet altijd op dezelfde manier. Als Samba 'sendfile' gebruikt, wordt die file naar een geheugenlocatie gelezen waarbij hetzelfde adres gebruikt wordt voor de netwerkdoorvoer; dit in een poging om de latency laag te houden zodat er niet meerdere keren de data in het geheugen rondslingert voordat het via het netwerk wordt verzonden.

er zijn switches die 20gbit backplanes hebben die, mocht je 48 poorten hebben, pas de 20gbit haalt

Voor full-duplex moet je een backplane hebben van het dubbele van het aantal poorts. Dus een 8 poorts gigabit switch hoort een 16Gbps backplane te hebben. Anders kan bij maximale utilisation geen maximale bandbreedte worden behaald. Correct?

Allemaal prima, maar dit zijn geen redenen waarom gigabit niet verzadigd raakt in een thuissituatie. Net als het CPU-argument: het zijn opstellingen waarbij de hardware zo goed als idle is, of in elk geval de load niet hoog. Kortom, CPU-resources zijn voorhanden, netwerkhardware kan de bandbreedte leveren; maar waar de crux zit is de softwareconfiguratie. Daar zit denk ik de reden dat in veel gevallen - zeker bij home NAS - geen optimale performance wordt behaald. Is dat iets wat jij bestrijdt?

Je betoog lijkt dat op sommige momenten te ontkennen, maar ook weer te bevestigen, zoals:

Correct; er zijn brakke chipsets en er zijn goede chipsets... ervaringen zullen verschillen, maar Intels worden vaak aangeprezen als de betere.
[..]
Net zo redelijk als het verdenken van chipsets

En het gaat hier niet om het verhelpen van een concrete situatie. Het gaat mij erom dat in bijna alle gevallen er geen optimale performance wordt behaald in een simpele gigabit NAS opstelling. De vraag is altijd: waar komt dat door? Is het de hardware die gewoon echt niet sneller kan, ook al is dat met een ander OS of andere drivers of wat dan ook. Of is dat de softwareconfiguratie (OS, drivers, applicaties) die in de meeste gevallen de oorzaak is van dergelijke performanceissues?

Ik denk zelf dat de hardware in veel gevallen prima in staat is om harder te kunnen, maar dat allerlei invloeden kunnen zorgen voor netto brakke performance. Zo stond Samba in het begin bekend als erg Linux-geoptimaliseerd en werd in FreeBSD-kring vooral NFS gebruikt. Ook heeft FreeBSD auto-tuning TCP buffers ingebouwd; ik geloof in FreeBSD 7. Kortom, het lijkt mij juist heel aannemelijk dat softwareconfiguratie veel vaker de oorzaak is van performance issues bij home NAS, dan hardwareproblemen.

[Verwijderd]

FireDrunk schreef op maandag 24 februari 2014 @ 22:09:
Even kort: CiPHER, wat je te snel afzwaait is de CPU.

Ik begrijp je argument dat simpelweg % geen recht doet aan de situatie in de praktijk. Maar ik dacht ook juist dat 'load' daar op inspeelde, door precies de gemiddelde wait state te geven voor alles wat draait. Als de applicatie elke keer 1 wait states moet wachten voordat het weer aan de beurt mag (RUNNABLE->RUNNING) dan is de load 1.00. Althans zo heb ik begrepen, zeg ik er in alle voorzichtigheid maar bij.

Maar mijn punt is dus: je kunt met 'top' denk ik vrij simpel zien dat als de load 0.09 is tijdens gigabit transfers en de performance is kut; ligt dat dan aan CPU resources? Dat lijkt mij toch bijzonder sterk...

Ik snap best dat als je allerlei VMs draait op dezelfde server, dit mogelijk een issue kan zijn; dat er nog wel CPU resources over zijn, maar dat de load soms flink uithandig kan uitpakken in het nadeel van Samba/CIFS. Maar in thuis NAS situaties lijkt me dit gewoon sterk. Bij de E350 Brazos is dat wel het geval; dat de CPU op zijn tenen loopt. Maar zelfs daar kun je nog vrij deftig 70MB/s halen. En 110MB/s op tmpfs. De gemiddelde CPU in zelfbouw NAS is vele malen krachtiger, dus hoe verklaar je dat de CPU een significante oorzaak kan zijn voor performance issues?

Samba (Linux en BSD) is voor zover ik weet een 50/50 kernel/userland applicatie, waar het onder windows een full kernel protocol is (maar Windows is weer een hybride kernel, bla bla, gaat de discussie niet over ).

Voor zover ik weet is Samba 100% userland. Het kan wel sendfile gebruiken, maar dat is toch gewoon een API-call?

Verder is er nog de Asynchronous I/O kernel module, die Samba optioneel kan gebruiken voor async I/O. Dat zijn volgens mij ook gewoon API-calls.

Kortom, is Samba niet gewoon een applicatie op applicatie-niveau? Het gebruikt wel API-calls maar heeft niet zelf onderdelen op kernelniveau draaien. Bij Solaris is dat volgens mij wel het geval; maar ook daar weet ik nog users die klaagden over slechte performance; terwijl anderen prima performance behaalde. Dat zie je ongeveer ook zo met Samba. En in sommige gevallen behaalt veel krachtigere hardware juist lagere netwerk-throughput performance. Dat zoek ik duidelijk in de softwarehoek.

[TrsvK]

EnerQi schreef op zondag 23 februari 2014 @ 21:11:
[...]


Hmm deze quote ben ik dus aan het zoeken. Waarom krijgen sommige mensen dan zo'n slechte resultaten met de Intel Avoton C2550? pricewatch: ASRock C2550D4I
Midas.e bijvoorbeeld krijgt maar 53 MB/s eruit ipv +-100. Dit zorgt ervoor dat ik enorm aan het twijfelen ben of dit moederbord + CPU geschikt is voor mijn NAS 2.0 .

Het hardforum meldt geen problemen, op dit forum wisselend en benchmarks zijn niet voldoende toegespitst op samba snelheden. Of ze testen met Linux ipv freebsd etc etc etc.

Een dure aanschaf als blijkt dat ie problemen heeft om één Gb snelheid te halen.

Ik heb laatst ook een ZFS nasje gebouwd met de C2550D4l, vooralsnog heb ik er een aantal 3/4jaar oude 1,5 TB schijven in hangen omdat ik nog even verder moet sparen voor een kistje greens maar zelfs met deze schijven en red ik een stabiele 80MB/s in windows via SMB/CIFS met een CPU belasting van rond de 40%.

[DXaroth]

Om de welles-nietes discussie over OSI voor wat het is te laten, inhoudelijk:

Allemaal prima, maar dit zijn geen redenen waarom gigabit niet verzadigd raakt in een thuissituatie. Net als het CPU-argument: het zijn opstellingen waarbij de hardware zo goed als idle is, of in elk geval de load niet hoog. Kortom, CPU-resources zijn voorhanden, netwerkhardware kan de bandbreedte leveren; maar waar de crux zit is de softwareconfiguratie. Daar zit denk ik de reden dat in veel gevallen - zeker bij home NAS - geen optimale performance wordt behaald. Is dat iets wat jij bestrijdt?

Mijn betoog is dat, in veel gevallen, je niet weet welke variabelen er spelen, als het gaat om de oorzaak zoeken van de slechte performance; dit betekend niet dat ik wil zeggen dat het -niet- software kan zijn, enkel dat er hardware factoren zijn die makkelijk niet meegerekend worden, die wel van toepassing zijn.

Juist doordat er zo ontiegelijk veel factoren zijn, is het lastig iets de schuld te kunnen geven; het zal waarschijnlijk een combinatie van meerdere zijn (wat het nog complexer maakt)..

Mijn eigen mening is ook iets in die richting; ik verwacht dat het een combinatie is van hardware dat kosten-besparend gemaakt wordt, en daardoor niet de 100% kan geven waarvoor het ontworpen was (ooit).. hierdoor heeft het als effect dat bepaalde software (het zij drivers, het zij iets hoger) niet zo goed performed als het zou moeten... dit levert een situatie op waar het lijkt alsof alles optimaal zou moeten werken, maar dit het toch niet zo doet.

De enige manier om dat echt te testen; is om meerdere systemen te bouwen; elk met dezelfde software stack, en dan gaan testen.. chipsets met elkaar vergelijken, net zolang tot er een patroon voor doet

[Phuncz]

Verwijderd schreef op dinsdag 25 februari 2014 @ 00:34:

Maar mijn punt is dus: je kunt met 'top' denk ik vrij simpel zien dat als de load 0.09 is tijdens gigabit transfers en de performance is kut; ligt dat dan aan CPU resources? Dat lijkt mij toch bijzonder sterk...

Dit valt mij op met mijn Ubuntu Server install op een Atom N330 met Intel 945GC chipset: maximale performance is echt niet hoog maar mijn CPU zit dan ook meestal ook niet aan zijn limiet. Toen ik er Windows op draaide met een SSD had ik de indruk dat de performance tegengehouden werd door de chipset want de CPU verveelde zich vaak en het RAM geheugen werd ook minimaal gebruikt. Mogelijk ook een verschijnsel van de E350 CPU met bijhorende chipset ?

[brederodekater]

Verwijderd schreef op dinsdag 25 februari 2014 @ 00:34:
Gigabit is een product met een hoge 'bandbreedtevertragingsproduct'. Dat betekent dat de interface relatief een veels te hoge latency heeft om de bandbreedte makkelijk vol te krijgen. Je zult aan queueing moeten doen om de gigabit interface 'bezig' te houden anders komt deze stil te vallen. Alle momentjes samen dat de link stil ligt, zorgt ervoor dat je niet de 112MB/s maximale throughput behaalt, maar slechts een gedeelte hiervan. Daar komen nog protocol issues bij, verschillen in OS en verschillen in netwerkapparatuur. [color=#4444ff]Dat samen kan voor slechtere resultaten zorgen, maar soms is het voor mij ook totaal onduidelijk waarom het ene systeem beter doet dan het andere.[/color]

Je ziet hier dat ik zaken als waarheid stel, terwijl het gekleurde gedeelte ingaat dat ik sommige dingen nog niet kan verklaren. De 2e paragraaf speculeert verder over de mogelijke oorzaken hiervan, duidelijk anders verwoord dan het begin van de 1e paragraaf:

Maar ik zoek het dus wel heel duidelijk in de softwarehoek, en niet in de richting van de hardware. Dat laatste kun je enigszins ook meten; de CPU-belasting kan tijdens gigabit bij mij oplopen tot 3,4% bij 80MB/s write met een Intel Ivy Bridge quadcore (3570) en 32GiB RAM. CPU is denk ik het probleem niet; maar bij interruptproblemen kan dat soms wel zo lijken omdat je een heel hoog CPU verbruik ziet.

Dit heeft volgens mij niet alleen betrekking op gigabit snelheden, of op Ethernet media in het algemeen. Als je volledig gebruik wilt maken van media op optimale snelheden dan moet je er voor zorgen alle onderdelen binnen je systeem hierop aansluiten (netwerk, interne bussen, CPU, geheugen, kernel, etc).

Als er zich een bottleneck (in de strikte zin van het woord) bevind binnen een systeem dan zal je met queuing te maken krijgen. Diepe & ongecontrolleerde (niet getuned) queus moeten over het algemeen vermeden worden, omdat je dan inderdaad een soort schommel effect zult gaan zien – stilte wanneer de queue gevult wordt & een relatief hoge burst wanneer deze wordt geleegd.

Maar goed, In bepaalde gevallen weet je dat je niet anders kunt dan queuen. Denk in het geval van crappy Realtek chipsets, of wanneer zelfs 10Gbit Ethernet de output van je systeem niet kan bijbenen Zorg er dan voor dat je kernel/network stack queue in ieder geval groot genoeg is, ander krijg je ook nog eens te maken met verloren TCP fragmenten, wat retransmissions tot gevolg heeft & wat automatisch het congestion avoidance algoritme van TCP in werking stelt. Iets waardoor je zeker je lijntje niet meer gaat voltrekken & ook nog eens een relatief hoog CPU verbruik tot gevolg kan hebben.

[FireDrunk]

Verwijderd schreef op dinsdag 25 februari 2014 @ 00:34:
[...]

Voor zover ik weet is Samba 100% userland. Het kan wel sendfile gebruiken, maar dat is toch gewoon een API-call?

Verder is er nog de Asynchronous I/O kernel module, die Samba optioneel kan gebruiken voor async I/O. Dat zijn volgens mij ook gewoon API-calls.

Kortom, is Samba niet gewoon een applicatie op applicatie-niveau? Het gebruikt wel API-calls maar heeft niet zelf onderdelen op kernelniveau draaien. Bij Solaris is dat volgens mij wel het geval; maar ook daar weet ik nog users die klaagden over slechte performance; terwijl anderen prima performance behaalde. Dat zie je ongeveer ook zo met Samba. En in sommige gevallen behaalt veel krachtigere hardware juist lagere netwerk-throughput performance. Dat zoek ik duidelijk in de softwarehoek.

Dat vraag mij af, Samba imporsonate users (veranderd het proces id van een worker thread), dat vereist flink wat kernel permissies en levert een context switch op. Dat is niet hetzelfde als een kernel module gebruiken, maar het vergt wel wat meer dan alleen maar een gewone applicatie zijn.

Daarnaast is er CIFS ondersteuning in de kernel, nou weet ik niet precies of Samba de CIFS modules uit de kernel gebruikt, maar volgens mij wel. Dat betekend dus dat Samba voor het opbouwen van een daadwerkelijke CIFS verbinding, een kernel API aanspreekt. Zodra dit gaat lopen, is het in kernel space.

Wat jij zegt over het inlezen van files dat dit 'gewoon' een API is, dan klopt dat wel, maar dat wil niet zeggen dat dit niet door de kernel uitgevoerd word. Vooral in het kader van AIO denk ik dat juist de kernel het werk doet, en (het userland proces) Samba gewoon wacht tot de call uitgevoerd is, en OK gemeld is.

Dit maakt het dat Samba voor de helft in kernel draait, en voor de andere helft in user land. Vandaar mijn 50/50 (klopt natuurlijk niet exact, maar je snapt mijn punt).

Ik heb ooit eens begrepen dat in Windows dat dus juist niet is. Daar word alle SMB verkeer in kernel afgehandeld (zelfs de user logins etc...) Dat maakt dat je veel minder context switches hebt, en je veel directer met geheugen om kan gaan. (Er hoeven namelijk geen context switches te gebeuren bij het kopieren van geheugen van disk drivers naar applicaties).

Verder over het afhandelen van interrupts, je ziet dat misschien wel als load, maar ik vraag mij af, of die load berekening nog van deze tijd is. Een interrupt afhandelen is vooral het kopieren van geheugen (van devices naar drivers) voor zover ik het begrijp. Maar misschien kan een hyperthread wel interrupts afhandelen terwijl de gewone core werk verzet.

Misschien kan dat ook wel niet, en word hyperthreading niet meer mogelijk ten tijde van het afhandelen van interrupts. I don't know...

Punt is. Dat soort specifieke platform truukjes worden vast niet meegenomen in de load calculatie onder Linux en BSD.

Daarom kijk ik altijd met een scheef oog naar die load...

[jacovn]

Verwijderd schreef op maandag 24 februari 2014 @ 23:29:
[...]

In realistische opstellingen kun je denken aan een 10-Gigabit kaart met 2 poorten die je in server en desktop stopt, en dan zonder switch direct aansluit op elkaar. De onboard gigabit aansluiting gebruik je dan voor regulier netwerk/internet-toegang. Dit is een opstelling die ik overwoog, hopende dat 10-gigabit ethernet goedkoper zou worden. Dat valt tot nu toe tegen; de X540-T2 doet nog steeds rond de 460 euro:
pricewatch: Intel Ethernet Converged Network Adapter X540-T2.

Dit doe ik ook, maar met een X520-DA2
Die gaan soms voor onder de 300 euro op ebay, en je hebt dan een SFP+ kabel nodig, die zijn tot 2 meter rond de 70 euro te krijgen
2x nas en 1 PC in een driekhoek bekabeld, eigen ip subnet op elke link, en je kunt vanaf de pc naar elke nas data moven, en ook tussen de nas units onderling.

Bij meer devices zit je wel aan een dure switch vast, de goedkoopste met 4 spf+ poorten is een cisco SG500X-24 die bijna 1000 euro kost, en dan heb je 4 poorten 10GE via sfp+ en 24 1GE poorten

Als je meer dan 4 10GE goedkoper aan wilt sluiten kun je wel beter naar X540 kaarten gaan, dan kun je een netgear XS708E gebruiken (8 poorts voor 720 euro of 12 poorten voor 1260, maar unmanaged)
En je hebt geen koppeling naar een 1GE netwerk dan omdat er alleen maar 10Ge poorten op zitten

[FireDrunk]

SFP+ is toch backwards compatible? Dus je zou er gewoon een 1Gb SFP module in moeten kunnen prikken...

[DennusB]

Wat een gek iets heb ik weer zeg. Ik wilde ZFSGuru installeren op mijn Esxi 5.5 doos. Lijkt goed te gaan, maar op de een of andere manier krijgt ie geen IP (andere VM's krijgen dat wel prima) en gaat ie luisteren op 0.0.0.0 i.p.v. het IP. En kan niet vinden wat t is...

[FireDrunk]

Shell -> ifconfig.

Die detectie gaat vaak mis.

[DennusB]

FireDrunk schreef op dinsdag 25 februari 2014 @ 10:43:
Shell -> ifconfig.

Die detectie gaat vaak mis.

Ja bij ifconfig staat ook echt het IP niet staat een plip0 iface met 0.0.0.0 en een lo0.

[FireDrunk]

Heb je als adapter VMXNET3 gekozen?

[DennusB]

FireDrunk schreef op dinsdag 25 februari 2014 @ 10:48:
Heb je als adapter VMXNET3 gekozen?

Jep! Heb ik gedaan!

[FireDrunk]

Dat kan pas nadat je FreeBSD 10 draait. 9.2 heeft geen ondersteuning voor VMXNET3.
(De bootcd van ZFSguru is nog 9.2)
Dus eerst even E1000 kiezen. Daarna ZFSguru installeren, en daarna veranderen naar VMXNET3.

[ Voor 9% gewijzigd door FireDrunk op 25-02-2014 10:50 ]

[DennusB]

FireDrunk schreef op dinsdag 25 februari 2014 @ 10:49:
Dat kan pas nadat je FreeBSD 10 draait. 9.2 heeft geen ondersteuning voor VMXNET3.
(De bootcd van ZFSguru is nog 9.2)
Dus eerst even E1000 kiezen. Daarna ZFSguru installeren, en daarna veranderen naar VMXNET3.

Duidelijk. Ga ik even proberen!

[ppl]

FireDrunk schreef op maandag 24 februari 2014 @ 22:09:
Samba (Linux en BSD) is voor zover ik weet een 50/50 kernel/userland applicatie, waar het onder windows een full kernel protocol is (maar Windows is weer een hybride kernel, bla bla, gaat de discussie niet over ).

Dat zou ook zeker kunnen verklaren waarom Windows relatief makkelijker SMB verkeer verzet dan Linux/BSD.

Je zoekt het eigenlijk al veel te ver. Het is een stuk simpeler: het hele SMB verhaal zoals we dat kennen komt bij Microsoft vandaan en zit standaard in Windows. Erg veel andere filesharing mogelijkheden had je destijds in Windows niet en dat maakt het gigantisch lastig als je ook niet-Windows machines hebt. Samba is destijds begonnen met het reverse engineren van dat protocol omdat er (vrijwel) geen documentatie over beschikbaar was. Dat is inmiddels wel anders, echter, Samba loopt nog steeds achter op Windows. Hun AD implementatie is (nog) niet op het niveau van wat er nu met Windows mogelijk is en ook zit er (nog) geen SMB 3.0 ondersteuning in waar Windows 8 en 2012 gebruik van kunnen maken. Het is dan ook niet zo heel erg raar dat Windows op dit vlak tot dusver altijd beter heeft gescoord (qua performance maar ook qua stabiliteit en load).

Het heeft dus meer met de implementatie zelf te maken dan dat het voor 50% kernel en voor 50% userland is. Het is overigens niet het enige wat speelt. Hardware maar ook de settings in Samba spelen een rol (denk aan grootte van pakketten e.d.).

Verwijderd schreef op dinsdag 25 februari 2014 @ 00:34:
Ik begrijp je argument dat simpelweg % geen recht doet aan de situatie in de praktijk. Maar ik dacht ook juist dat 'load' daar op inspeelde, door precies de gemiddelde wait state te geven voor alles wat draait.

Het geeft aan hoe druk het systeem is met alles wat het moet doen. Niks meer, niks minder. Je kunt er dus moeilijk aan afleiden waarom dat zo is maar daar is het ook niet voor bedoeld. Het is vooral bedoeld als trigger om verder te gaan onderzoeken waar het probleem zou kunnen zitten. Als je bijv. een hoge load ziet maar in je activity monitor/task manager dat cpu gebruik niet hoger komt dan 20% betekent dat je dus verder moet gaan zoeken en wellicht meer richting hardware moet gaan kijken (is de hardware nog wel toereikend, is er iets gammel?).

Maar mijn punt is dus: je kunt met 'top' denk ik vrij simpel zien dat als de load 0.09 is tijdens gigabit transfers en de performance is kut; ligt dat dan aan CPU resources? Dat lijkt mij toch bijzonder sterk...

Pin je niet vast op de cpu want dat is niet het enige wat netwerkkaarten gebruiken. Er zijn heel veel zaken die standaard naar de NIC worden geoffload en daar zijn soms nog wel eens problemen mee. Door bepaalde offloading uit te schakelen werkt het ineens wel stabiel en/of snel. Het gebruik van fatsoenlijke NICs wil ook nog wel eens een groot verschil maken hierin (Intel ipv Realtek om maar eens de 2 bekendsten te gebruiken). Verder ook goed om naar het OS zelf te kijken want ook daar kunnen bugs in de driver zitten die dit soort problemen kunnen veroorzaken.

FireDrunk schreef op dinsdag 25 februari 2014 @ 10:49:
Dat kan pas nadat je FreeBSD 10 draait. 9.2 heeft geen ondersteuning voor VMXNET3.

Of nadat je VMware Tools (via de vSphere Client) of open-vm-tools (in de ports: emulators/open-vm-tools of emulators/open-vm-tools-nox11 als je geen GUI hebt/wil) hebt geïnstalleerd. Je hebt dan wel de sources nodig (dus een /usr/src met inhoud).

(De bootcd van ZFSguru is nog 9.2)
Dus eerst even E1000 kiezen. Daarna ZFSguru installeren, en daarna veranderen naar VMXNET3.

En zo te lezen doet ie dat daarna vanzelf, klopt dat?

Als je toch niks intern wil gebruiken en verder alles extern over gigabit hebt lopen is het gebruik van VMXNET3 tov E1000 niet interessant. Als je het wel intern wil gaan gebruiken wil je juist iets als VMXNET3 omdat deze een interne 10Gbit kan bieden.

Mocht je naar FreeBSD 10 gaan pas dan wel even op. Er blijken wat problemen te zijn met netwerkverkeer wat icm met een firewall erg irritant is doordat pakketten dusdanig binnenkomen dat ze niet aan een pass rule te matchen zijn en dus standaard worden gedropt. Op het forum van FreeBSD vindt je hier meer info over.

[ Voor 16% gewijzigd door ppl op 25-02-2014 14:58 ]

[FireDrunk]

E1000 doet ook gewoon 10Gbit hoor. Het gebruik van E1000 limiteert je helemaal niet tot 1Gb dat is een broodje aap verhaal.

VMXNET3 levert je vooral lagere CPU load op bij flinke transfers.

[Verwijderd]

DennusB schreef op dinsdag 25 februari 2014 @ 10:44:
Ja bij ifconfig staat ook echt het IP niet staat een plip0 iface met 0.0.0.0 en een lo0.

Schakel die parallelle poort ajb uit; dat is zo ouderwets. plip is een soort netwerkinterface over de parallelle poort, wat natuurlijk niemand gebruikt. Net als 'fwe' de FireWirte-over-Ethernet module is. Lekker uitschakelen dat soort spul!

Verder zoals FireDrunk zegt: vanaf ZFSguru 10.x kun je standaard VMXNET3 in de kernel verwachten. Daar hoef je verder niets voor te doen om het te gebruiken. Bij 9.2 en ouder kun je denk ik de vm-vmware-drivers service gebruiken.

[jacovn]

Ik ga ook maar eens seagate ST4000DM000 proberen voor de volgende pool van de 2e server. Het zijn toch de goedkoopste 4TB op het moment, en voor film opslag zijn ze wel geschikt naar wat ik gelezen heb.
Niet erg veel warmte ontwikkeling (ten opzchte van de 7K4000) dus ik ben benieuwd.

[ppl]

FireDrunk schreef op dinsdag 25 februari 2014 @ 15:00:
E1000 doet ook gewoon 10Gbit hoor. Het gebruik van E1000 limiteert je helemaal niet tot 1Gb dat is een broodje aap verhaal.

Nee hoor dat doet die E1000 helemaal niet, dat is nou juist hetgeen wat het broodje aap verhaal is en dat had je kunnen weten als je een bron had gebruikt die wel juiste informatie verstrekt. Zo'n bron is bijv. VMware zelf: Choosing a network adapter for your virtual machine (1001805).

Ik citeer: "E1000: An emulated version of the Intel 82545EM Gigabit Ethernet NIC."

Het is dus niets meer en niets minder dan een 1Gbit nic. Als je in de gemiddelde UNIX OS kijkt dan zul je ook zien dat dit vaak als drivertype voorbij komt. De output van ifconfig zal in bijv. FreeBSD keurig netjes melden dat ie op 1000BaseT draait. Bij de VMXNET3 staat er bij mij geen snelheid vermeldt maar de metingen laten tot dusver zien dat het 10Gbit is. Zo rondzoekend op internet kwam ik erachter dat ik niet de enige ben. VMware heeft het in een document bevestigd (document is te vinden via eerder genoemde link).

Er is een nieuwere versie van die driver voor wat nieuwere nics zoals de Intel 82574 en dat is de E1000e. Echter, de E1000 heeft nog altijd een voorkeur omdat deze ontzettend goed wordt ondersteund in het gemiddelde OS.

VMXNET3 levert je vooral lagere CPU load op bij flinke transfers.

Het is een wat efficiëntere nic die je daardoor een lagere cpu load oplevert maar ook een hogere bandbreedte. De support van diverse operating systemen is echter niet zo heel goed.

[jadjong]

Het praktische verschil tussen e1000 & vmxnet3 is bij mij doorvoer bij gelijke processorbelasting. De E1000 doet maximaal 2600mbit, terwijl vmxnet3 op dezelfde host, in dezelfde vm's ruim 7000mbit biedt.

[FireDrunk]

De E1000 is inderdaad driver technisch een 1Gbit verbinding. Maar dat het ding zegt dat ie 'maar' 1Gbit aan kan, wil dat niet zeggen dat je OS stopt met data voeren als het ding meer dan 1Gb aan het versturen is. Er is nergens een hard limiet dat stopt bij 1Gb in het geval van E1000.

Zoals jadjong al zegt, de effectieve doorvoersnelheid ligt boven de 1Gb, alleen omdat er veel meer van de driver geïmplementeerd moet worden dan bij VMXNET3 is het een inefficiëntere adapter.

[Verwijderd]

Een exacte emulatie van een netwerk interface zou het inderdaad op 1Gbps gelimiteerd moeten zijn. Maar bij paravirtualisatie of 'geëmuleerde hardware' is dat niet strict nodig. Je kunt zeggen 100Mbps link terwijl in werkelijkheid er geen limiet is; alleen die van CPU resources. Hetzelfde zie je volgens mij ook bij de Virtio 'vtnet' netwerk-interface bij *BSD en bepaalde virtualiatieengines, zoals VirtualBox. De link wordt op 100 of 1000Mbps weergegeven, maar de performance is dan niet link-gebonden maar CPU-gebonden.

[FireDrunk]

De recentere VirtIO NICs geven zelfs 10Gbit aan, maar halen nog meer (heb al eens 18Gb geklokt )

[ppl]

Het ligt uiteraard ook heel erg aan het OS zelf, wat die aan drivers gaat gebruiken en wat die drivers wel/niet kunnen. Hoe dan ook, het is een 1Gbit kaart die 1Gbit doet. Net als met een echte nic kun je in de praktijk net even wat meer halen maar dat is geen enkele garantie en dus moet je die ook zeker niet meenemen in een berekening. Een iperf laat ook zien dat het gewoon een 1Gbit kaart is (en daarmee test ik binnen ESXi) want ik haal snelheden rond de 1Gbit. Ik zie geen andere snelheden dan bij een fysieke 1Gbit nic. Als ik test tussen vm's met de VMXNET3 dan zit ik tussen 10~14Gbit/s.

[ Voor 6% gewijzigd door ppl op 26-02-2014 23:51 ]

[FireDrunk]

Het ligt vooral aan de driver implementatie volgens mij. Windows VM's met E1000 halen minder snel > 1Gb dan dat Linux VM's dat bijvoorbeeld doen.

Ik heb zeker wel > 1Gb gezien bij E1000.

[Midas.e]

Sata power, het blijft een feest
scan: resilver in progress since Thu Feb 27 02:19:11 2014
5.96T scanned out of 6.22T at 175M/s, 0h25m to go
580G resilvered, 95.87% done

Inmiddels zitten alle drives in hotswap bays zoals vanouds, hardware is naar mn oude lian li chassis gegaan maar nu met veel meer ruimte over.

[FireDrunk]

Het is zo leeg dat ik zo'n mooie tumbleweed door de kast zie gaan icm een mooi western muziekje

[Midas.e]

Helemaal als je de oude ernaast zet:

[GioStyle]

Ik zit nog steeds te wachten tot een fabrikant met een mooie itx case komt waar dit bordje mooi bij past met 10 of 12 keer hotswap bays...

[Steephh]

Ik ben aan het kijken naar een 19" behuizing om mijn FreeNAS config in te draaien.. Alleen het is echt bizar lastig om aan 2U voedingen te komen (en nog lastiger om ze voor een leuke prijs te vinden).. En afaik passen andere type voedingen zoals FlexATX etc allemaal niet.

Iemand die daar ook tegenaan gelopen is?

[Verwijderd]

PicoPSU? Of ga je over de 80W heen? 2U behoort toch niet zo'n probleem te zijn. 1U PSUs zijn er ook zat.

[Steephh]

Ik wil uiteindelijk maximaal 12 SATA disks in totaal gaan gebruiken straks en dat op een AMD A4-3400 met 32GB of 64GB aan geheugen. Volgens eXtreme Powersupply Calculator Lite zou ik dan op 180 Watt minimaal, maar liever 230 Watt uitkomen.. De 2U voedingen die ik al had gevonden die zijn rond de 460 / 520 Watt, oftewel best wel overkill en niet zo zuinig dus omdat ze niet zo zwaar belast gaan worden.

Een 1U PSU zou natuurlijk ook kunnen, daar had ik nog niet naar gekeken. En er zijn ook nog allerlei maten voedingen die volgens mij ook zouden moeten passen, Ik ben al CFX, TFX, ATX, Flex-ATX al tegengekomen, maar eens kijken wat er daarvan dan in zou kunnen passen.. Een beetje modden vind ik opzich geen probleem, zolang ik maar niet hoef te gaan slijpen en lassen..

Eigenlijk is dit dan wel een interessante optie: http://www.logicsupply.co...pplies/flex-atx/ss250-su/

Beetje tie-wrappen en hoppakee..

[ Voor 12% gewijzigd door Steephh op 27-02-2014 19:06 ]

[DXaroth]

Steephh schreef op donderdag 27 februari 2014 @ 18:08:
Ik ben aan het kijken naar een 19" behuizing om mijn FreeNAS config in te draaien.. Alleen het is echt bizar lastig om aan 2U voedingen te komen (en nog lastiger om ze voor een leuke prijs te vinden).. En afaik passen andere type voedingen zoals FlexATX etc allemaal niet.

Iemand die daar ook tegenaan gelopen is?

1 woord: SuperMicro .. 90% van de chassis hebben er al een PSU bij, helemaal de 1u systemen.. zo niet, dan kan je daar altijd nog een bijpassende PSU vandaan halen

[Steephh]

Mja, punt is dat die niet de kasten voor de prijs hebben die ik wil..

[Midas.e]

@Q leuk dat script van je, zojuist op de 1.5TB disks van mn oude set los gelaten:
root@semafoor:~/showtools# ./show disk -H
----------------
| DEV | Hours |
----------------
| dm-0 | 35071 |
| dm-1 | 35071 |
| sda | 35071 |
| sdb | 35181 |
| sdc | 35154 |
| sdd | 35183 |
| sde | 35182 |
| sdf | 35071 |
----------------

[Q]

Bedankt, die disks hebben exact 4 jaar gedraaid als ik dat goed bereken. Hoe zijn de smart waarden?

[Phuncz]

Steephh schreef op donderdag 27 februari 2014 @ 21:06:
Mja, punt is dat die niet de kasten voor de prijs hebben die ik wil..

Waarschijnlijk omdat er een voeding bijzit die wel past

[Midas.e]

Q schreef op donderdag 27 februari 2014 @ 22:09:
Bedankt, die disks hebben exact 4 jaar gedraaid als ik dat goed bereken. Hoe zijn de smart waarden?

[Dadona]

Temperaturen van 56-59 graden celcius? Is dat altijd zo of wisselt dat ook nog? (Doe je aan spindown?)

[Midas.e]

ding staat nu te packagen, dus redelijk zwaar belast. zodra dat klaar is zijn ze idle 35 graden.

[Pixeltje]

Vraagje; Ik zie dat de meeste ATX voedingen niet verder komen dan 6, 8 of 9 SATA stroomstekkers, hoe sluiten jullie de 10+ disks aan die regelmatig de revue passeren in dit topic?

@ hieronder,
Thanks, dat was snel

[ Voor 10% gewijzigd door Pixeltje op 28-02-2014 12:26 ]

[Dadona]

Met iets als dit: pricewatch: Silverstone SST-CP06 4x SATA

@Midas.e, als je dat met regelmaat hebt, zou je dan niet iets van een ventilator ervoor gooien. Hoge(re) temperaturen zijn nog niet het punt, wel als er extremere wisselingen zijn.

[InflatableMouse]

Ik heb eindelijk m'n IBM M1015 binnen en moet hem zo dus gaan flashen naar IT mode maar ik wil natuurlijk wel meteen de laatste versie doen.

De bestanden en versies in dit artikel:
http://www.servethehome.com/ibm-serveraid-m1015-part-4/

Zijn denk ik niet de meest recente (is van feb 2011)?

http://forums.laptopvideo...211-firmware-files/page-5

Die post doet vermoeden dat er nieuwere zijn (P17) maar ik kan dat niet vinden op de LSI site.

Iemand een linkje naar de nieuwste mischien voor me?

Dank!

[Dadona]

Waarom wil je de meest recente versie? Juist van de wat oudere versies weet je dat die inmiddels wel flink getest zijn. Ik zou gewoon zo'n oude versie pakken waar iedereen mee werkt.

[Midas.e]

Dadona schreef op vrijdag 28 februari 2014 @ 12:22:
@Midas.e, als je dat met regelmaat hebt, zou je dan niet iets van een ventilator ervoor gooien. Hoge(re) temperaturen zijn nog niet het punt, wel als er extremere wisselingen zijn.

Valt dus best mee

[FireDrunk]

60c is best wel heel erg heet hoor...

[Patatjemet]

GioStyle schreef op donderdag 27 februari 2014 @ 13:54:
Ik zit nog steeds te wachten tot een fabrikant met een mooie itx case komt waar dit bordje mooi bij past met 10 of 12 keer hotswap bays...

Bordje vandaag geïnstalleerd (de quad core). IPMI doet het maar krijg geen beeld (blijft zwart). Stomme is dat ik geen vga monitor in huis heb en dus niet kan controleren of het aan IPMI ligt of dat er meer aan de hand is. Maar even snel ergens een monitor regelen en verder troubleshooten. Via IPMI sensors kan ik zien dat de cpu ~ 41 C blijft.

Ondertussen is mijn huidige server via lokale rsync mijn backup server aan het volstampen

[Paul]

Dadona schreef op vrijdag 28 februari 2014 @ 13:16:
Waarom wil je de meest recente versie? Juist van de wat oudere versies weet je dat die inmiddels wel flink getest zijn.

...en daar komen issues uit voort en daar maakt men een fix voor -> nieuwere versie

Het sentiment is goed, maar dan moet je wel de release notes van de nieuwere versies bekijken omdat je anders misschien alles kwijt raakt op een bug die er al lang en breed uit is gehaald

[jantje112]

Patatjemet schreef op vrijdag 28 februari 2014 @ 14:27:
[...]




[afbeelding]

[afbeelding]

[afbeelding]

[afbeelding]

[afbeelding]

Bordje vandaag geïnstalleerd (de quad core). IPMI doet het maar krijg geen beeld (blijft zwart). Stomme is dat ik geen vga monitor in huis heb en dus niet kan controleren of het aan IPMI ligt of dat er meer aan de hand is. Maar even snel ergens een monitor regelen en verder troubleshooten. Via IPMI sensors kan ik zien dat de cpu ~ 41 C blijft.

Ondertussen is mijn huidige server via lokale rsync mijn backup server aan het volstampen

Niet toevallig nog een vga op je tv zitten?

PS Mooie setup

[FireDrunk]

Idd, patatje, prachtig systeempje

[Midas.e]

Patatjemet schreef op vrijdag 28 februari 2014 @ 14:27:
[...]





Bordje vandaag geïnstalleerd (de quad core). IPMI doet het maar krijg geen beeld (blijft zwart). Stomme is dat ik geen vga monitor in huis heb en dus niet kan controleren of het aan IPMI ligt of dat er meer aan de hand is. Maar even snel ergens een monitor regelen en verder troubleshooten. Via IPMI sensors kan ik zien dat de cpu ~ 41 C blijft.

Ondertussen is mijn huidige server via lokale rsync mijn backup server aan het volstampen

Ik zou mn geheugen maar even checken, bord is redelijk specifiek qua ram, geeft geen piep of iets maar je ipmi blijft zwart bij verkeerd ram. Tevens kan je het op je toetsenbord zien of ie juist boot door de leds van je keyboard te volgen. (eerst 2x scroll-lock en daarna 1x numlock aan is boot)

[DXaroth]

Patatjemet schreef op vrijdag 28 februari 2014 @ 14:27:
[...]




[afbeelding]

[afbeelding]

[afbeelding]

[afbeelding]

[afbeelding]

Bordje vandaag geïnstalleerd (de quad core). IPMI doet het maar krijg geen beeld (blijft zwart). Stomme is dat ik geen vga monitor in huis heb en dus niet kan controleren of het aan IPMI ligt of dat er meer aan de hand is. Maar even snel ergens een monitor regelen en verder troubleshooten. Via IPMI sensors kan ik zien dat de cpu ~ 41 C blijft.

Ondertussen is mijn huidige server via lokale rsync mijn backup server aan het volstampen

zijn dat 3.5"of 2.5"disk bays die daar in zitten (of een link naar chassis, werkt ook )

[edit] nm, model nummer van de disk geeft aan dat het een 2.5" is.. was leuk geweest voor mijn setup als het een 3.5" was

[ Voor 4% gewijzigd door DXaroth op 28-02-2014 15:55 ]

[InflatableMouse]

Ik probeer de M1015 te flashen, ik heb de Linux variant sas2flash geprobeerd, kan de kaart niet vinden. VIa USB DOS geboot, zegt tie ERROR, cannot initialize PAL. Ik lees nu dat ik het via EFI shell moet doen.

Ik wordt er een beetje simpel van allemaal hoor. Waarom kan die crap niet gewoon normaal werken? Als ik vanuit de BIOS EFI Shell kies, zegt tie dat tie shellx64.efi niet kan vinden. Ik zoek me wezeloos geen idee waar ik dat vandaan moet halen of wat ik daar mee moet doen.

In m'n Linux heb ik /boot/efi/EFI/debian, daar staat een grubx64.efi in. Moet ik hier ergens zo'n shellx64.efi bij zetten of moet dat ergens anders?

Als iemand hier ervaring heeft met dit geneuzel hoor ik het graag!

Bedankt alvast.

[FireDrunk]

Cannot initialize PAL betekend gewoon, je hebt een moederbord waarin je de M1015 niet kan flashen.
Pak een ander bord, en goede kans dat het werkt.

[InflatableMouse]

http://brycv.com/blog/201...rmware-to-lsi-sas9211-8i/

Hij geeft aan dat die melding optreedt op EUFI borden en dat tie de EFI versie moet hebben. De EFI executable heb ik, ik heb een Shellx64.efi maar waar ik het ook weg zet vanuit de BIOS weigert het te starten. Ik snap neit waarom dit allemaal zo lastig moet zijn.

Ik heb 1 andere pc, zit ook een EUFI bord in maar ik zal het daar eens in proberen dan. Moet ik weer met m'n monitor naar zolder shouwen maar goed ... zucht.

[FireDrunk]

Ach, als het eenmaal gelukt is ben je weer blij Het is een nodig-kwaad om even doorheen te komen

[InflatableMouse]

Helaas. Andere pc doet hetzelfde.

Net even buiten heel diep staan zuchten anders was er wat gesneuveld.

M'n md raids starten trouwens niet meer op nadat ik die m1015 in m'n andere pc heb gehad.
mdadm --examine /dev/sdh1 etc laat zien dat ze allemaal clean zijn maar waarom tie em niet assembled is mij even een raadsel. Gelukkig werkt ssh wel (start verder gewoon op) hoef ik niet op die koude zolder te zitten.

Shellx64.efi ... iemand ideen?

[ Voor 52% gewijzigd door InflatableMouse op 28-02-2014 17:31 ]

[FireDrunk]

Je bent vrij snel boos of niet?
Je mag wel even langskomen hoor, dan flash ik hem wel voor je

[Xudonax]

Patatjemet schreef op vrijdag 28 februari 2014 @ 14:27:
[...]




[afbeelding]

[afbeelding]

[afbeelding]

[afbeelding]

[afbeelding]

Bordje vandaag geïnstalleerd (de quad core). IPMI doet het maar krijg geen beeld (blijft zwart). Stomme is dat ik geen vga monitor in huis heb en dus niet kan controleren of het aan IPMI ligt of dat er meer aan de hand is. Maar even snel ergens een monitor regelen en verder troubleshooten. Via IPMI sensors kan ik zien dat de cpu ~ 41 C blijft.

Ondertussen is mijn huidige server via lokale rsync mijn backup server aan het volstampen

Wat voor kastje is dat? Ziet eruit als een waardige opvolger van mijn Bitfenix

[ Voor 3% gewijzigd door Xudonax op 28-02-2014 17:42 ]

[InflatableMouse]

Ik ben redelijk snel door m'n geduld heen inderdaad . Schijnbaar zijn de UUID's verandert sinds de reboot waardoor mdadm ze niet meer wil assemblen:

code:

mdadm: /dev/sdj2 has wrong uuid.
mdadm: /dev/sdj1 has wrong uuid.
mdadm: no RAID superblock on /dev/sdj
mdadm: /dev/sdi2 has wrong uuid.
mdadm: /dev/sdi1 has wrong uuid.
mdadm: no RAID superblock on /dev/sdi
mdadm: /dev/sdh2 has wrong uuid.
mdadm: /dev/sdh1 has wrong uuid.

Bedankt voor het aanbod maar om nu even van Delft naar Arnhem te rijden is iets te ver. Eerst md0 en md1 fixen, dan is m'n humeur ook weer goed!

Gelukkig vandaag nog nieuwe backups gemaakt

Edit: gelukkig die arrays doen het weer .

[ Voor 3% gewijzigd door InflatableMouse op 28-02-2014 17:47 ]

[FireDrunk]

Gebruikte je RDM's? VT-d of VMDK's?

[InflatableMouse]

Wie ik? Voor wat precies?

[FireDrunk]

Oh wacht, ik dacht dat je ESXi draaide

[InflatableMouse]

Nope. Geen ESXi. Wel KVM maar dat staat hier verder los van de arrays hangen gewoon aan de server zelf.

[Sleepkever]

Iemand trouwens enig idee of die nieuwe ri-vier kasten ( RVS4-06A bijvoorbeld) nog activity leds per drive hebben zitten? Neem aan dat SGPIO daar niet voor nodig is toch? Geen dealbreaker natuurlijk maar voor de cool factor wel leuk offcourse.

[TiZu]

Ik heb de 2u versie die heeft per schijf activiteit leds. Dus kga daar wel van uit.

[InflatableMouse]

Nou ik krijg het niet voor elkaar met die EFI shell starten vanuit de BIOS. Ik begrijp totaal niet wat Asus en Asrock bezielen dat ze zoiets inbouwen zonder enige vorm van documentatie. Alles wat ik lees op internet is beladen met frustratie maar wat voor hun wel werkt krijg ik niet aan de praat.

Als er iemand een beetje in de buurt van Delft woont en me uit de brand kan helpen met dit kaartje te flashen naar IT mode zou ik het op prijs stellen! PM me maar.

[GioStyle]

Patatjemet schreef op vrijdag 28 februari 2014 @ 14:27:
-setup-

Leuke setup! Zo zou ik het ook inderdaad hebben gedaan als ik genoeg had aan alleen 2.5" schijfjes. Ik heb ook nog zo'n 6 hotswapbays in 1 5.25" bay in gebruik hier.
Maar helaas heb ik 3.5" schijven nodig ivm de opslaggrootte.

Ik ben wel benieuwd waar je dit kastje vandaan heb getoverd!

En wat voor verbruik heb je met deze setup? Zou je dat kunnen meten?

@Habana: Ja, thanks voor de tip. Als ik ga uitbreiden, dan wil ik naar een 10 disks setup of zelfs 12. Ik zit nu op 6x 3TB, maar ik wil op termijn naar 40/50TB.

Ik ben eigenlijk op zoek naar dit:



En dan voor 10 of 12 schijven.

[ Voor 37% gewijzigd door GioStyle op 01-03-2014 00:10 ]

[Habana]

@ GioStyle, Phunch kwam een tijdje terug met de Silverstone DS380 als tip, als 8xSata genoeg is..

http://silverstonetek.com/product.php?pid=452&area

[Q]

Midas.e schreef op vrijdag 28 februari 2014 @ 11:24:
[...]

[afbeelding]

Disk sdf heeft flink wat reallocated sectors maar de rest ziet er ok uit.

[guid0o]

InflatableMouse schreef op vrijdag 28 februari 2014 @ 19:11:
Nou ik krijg het niet voor elkaar met die EFI shell starten vanuit de BIOS. Ik begrijp totaal niet wat Asus en Asrock bezielen dat ze zoiets inbouwen zonder enige vorm van documentatie. Alles wat ik lees op internet is beladen met frustratie maar wat voor hun wel werkt krijg ik niet aan de praat.

Als er iemand een beetje in de buurt van Delft woont en me uit de brand kan helpen met dit kaartje te flashen naar IT mode zou ik het op prijs stellen! PM me maar.

Ik heb er zelf een tijdje terug ook heel veel ruzie mee gehad. Eerst deze guide gevolgd: http://www.servethehome.com/ibm-serveraid-m1015-part-4/ maar toen liep ik ook tegen het UEFI gedoe aan en vervolgens is het me met deze guide uiteindelijk wel gelukt: http://www.0x00.to/post/2...11-8i-with-UEFI-mainboard

Dit was trouwens wel met een Asrock bordje.

[InflatableMouse]

Ah, die link gaat m'n bookmarks in! Bedankt!

Gisterenavond heeft Goshimaplonker298 me geholpen, erg tof! Aardige kerel en woonde niet te ver weg, kon meteen terecht.

Vanochtend er in gezet, werkt echt perfect! BIOS hebben we leeg gelaten, start tie wat sneller op en verkloot tie m'n device order niet (alhoewel ik begreep dat daar ook een ander trucje voor is). SSD is nu weer netjes sda in ieder geval. Alle disks zijn nu ook netjes ata devices, met merk/type/serienummer genaamd ipv generieke scsi-randomgetalletjes. Smartmontools laat alle info zien, ziet er goed uit!

Kabeltjes paste trouwens nog maar net zeg, bij de oude kaart zaten ze aan het uiteinde, deze kaart heeft ze naast het bracket zitten. Moest nog disks verplaatsen omdat het anders niet paste, maar het zit .

Net alles geinventariseerd, welke disk welk merk/model is. Zo de UUID's er bij zetten en de pool opnieuw aanmaken. Inventarisatie print ik uit en leg ik bij de server zodat ik makkelijk weet welke disk ik moet vervangen als er eentje uitknalt.

M'n md-raids zijn trouwens weer weg, mdadm.conf had ik weggemikt gisteren, maar niet opnieuw aangemaakt . Zo nog maar even naar kijken .

[jacovn]

De seagates lopen inmiddels in Movietank4. (10 hdd's in RaidZ2)

Even de benchmark gedraaid:
64 GiB:
ZFSguru 0.2.0-beta8 (9.1-005) pool benchmark
Pool : Movietank3 (27.2T, 44% full)
Test size : 64 GiB
normal read : 1 GB/s
normal write : 766 MB/s
I/O bandwidth : 28 GB/s

ZFSguru 0.2.0-beta8 (9.1-005) pool benchmark
Pool : Movietank4 (36.2T, 0% full)
Test size : 64 GiB
normal read : 578 MB/s
normal write : 901 MB/s
I/O bandwidth : 28 GB/s


128 GiB:
ZFSguru 0.2.0-beta8 (9.1-005) pool benchmark
Pool : Movietank4 (36.2T, 0% full)
Test size : 128 GiB
normal read : 554 MB/s
normal write : 744 MB/s
I/O bandwidth : 29 GB/s

De read snelheden zijn wel fors lager dan die van de 7200 RPM Toshiba's (movietank3)
De write snelheden zijn wel net zo goed, beetje vreemd dat read zo veel langzamer dan write is.

update: geen L2arc in deze pool, wellicht het verschil ?

update: ja dus..

ZFSguru 0.2.0-beta8 (9.1-005) pool benchmark
Pool : Movietank4 (36.2T, 0% full)
Test size : 64 GiB
normal read : 1 GB/s
normal write : 805 MB/s
I/O bandwidth : 29 GB/s

[ Voor 14% gewijzigd door jacovn op 01-03-2014 15:47 ]

[Jormungandr]

Steephh schreef op donderdag 27 februari 2014 @ 18:26:
Eigenlijk is dit dan wel een interessante optie: http://www.logicsupply.co...pplies/flex-atx/ss250-su/

Beetje tie-wrappen en hoppakee..

Ik heb de 2U versie en hou je dB-meter maar al goed vast. Goede PSU's maar zeer luid. Ik denk eraan om in mijn 2U een noctua fan te plaatsen.

[DXaroth]

Habana schreef op vrijdag 28 februari 2014 @ 23:09:
@ GioStyle, Phunch kwam een tijdje terug met de Silverstone DS380 als tip, als 8xSata genoeg is..

http://silverstonetek.com/product.php?pid=452&area

Die is wel interessant ja.

[BartNL]

jacovn schreef op zaterdag 01 maart 2014 @ 13:35:
De seagates lopen inmiddels in Movietank4. (10 hdd's in RaidZ2)

heb er van dit type sinds juli 2013 24 via een sas expander aan een Areca 1882 raidkaart hangen en 12 daarvan al paar maanden langer. Zijn tot nu de meest betrouwbare schijven die ik in mijn fileserver heb gehad, geen doa, geen uitval en nul problemen. Zouden met ZFS RaidZ2 dus al helemaal geen problemen mogen geven

[Patatjemet]

Gister het bordje aan de praat gekregen. Het lijkt erop alsof DIMM slot B1 kapot is, met het geheugen in A1 start het bordje gewoon op. Ik heb het geheugen meerdere keren opnieuw geplaatst, met het moederbord zowel in als buiten de kast. Ik twijfel of ik nog een DIMM bestel om te testen of hij met A1 en B1 gevuld wel werkt of het bordje voor RMA wegstuur (met het risico dat ik een aantal weken zonder bordje zit). Kan het zijn dat het moederbord verplicht bij 1 DIMM gebruik te maken van A1?

Met freenas 9.2 worden alle sata poorten direct herkend. Een 10 disk raidz-2 met mijn 640 GB laptop disks geeft ~4.3 TB ruimte, voor mij nu voldoende. Kan ik rustig aan sparen voor 10 nieuwe > 1.5 TB 2.5" disks. En ik heb nog 2 slots vrij, al weet ik nog niet wat ik daarmee ga doen (L2ARC - datastore - download disk ?).

Het hele systeem wordt nauwelijks warm en maakt zo goed als geen geluid, heerlijk! Tijdens rsync vanaf mijn backup server wordt het moederbord en de processor ~49 C met de fan op 900 RPM. Die ene 9 cm fan koelt dus mijn hele systeem(pje)! Opvallend is dat de G620 in mijn vorige server ~ 75 % belast werd tijdens een rsync (pull), de avaton zit zo rond de 15% (is dit dan 1 core of de totale cpu belasting?).

Avaton (pull):





G620 (push):





Zoals in mijn vorige setup heb ik de disks op "always on" staan. Dit zou slijtage moeten voorkomen en zorgt daarnaast voor een altijd vlot reagerend systeem. Ik meet mijn energie verbruik met een (onbetrouwbare) energy check 3000 (het geeft in ieder geval een indicatie...). Zonder disks doet het systeem 23 w. Met 10 disks idle doet het 32 w. en tijdens een rsync actie over mijn netwerk verbruikt het systeem 39 w. Startup piek is 50 w. Dit alles met een mini box pico psu 150 xt met 150 w. adapter (ofterwijl ik kan gaan testen met een lichtere picopsu ).

Economisch gezien is de aanschaf van dit moederbordje niet te verantwoorden, ook niet met de lage verbruikscijfers (mijn vorige setup verbruikte idle ~ 50 w.). De reden om toch een nieuwe server te bouwen is deels hobby (kleiner, netter, zuiniger, sneller) en deels ontevredenheid met mijn oude setup, de hele server moest uit elkaar om een disk te wisselen. Daarnaast vind ik het fijne gedachte dat ik een setup heb die jaren mee kan (geheugencapaciteit, uitbreidingsslot, etc). Het enige wat niet werkt zoals ik zou willen is de disk activiteit leds op de icy docks, die doen helemaal niks. Iemand een idee?

De case is een Emko EM-113. Niet in nederland te verkrijgen (de EM-111 wel), dus direct via de fabrikant besteld.

[ Voor 9% gewijzigd door Patatjemet op 03-03-2014 19:45 ]

[analog_]

Je bedoelt 12.5%, 1/8ste core volledig. Rsync is helaas singlethreaded en gaat voor geen meter vooruit om die reden. Ik gok dat het dus trager nu is.

[ Voor 12% gewijzigd door analog_ op 03-03-2014 19:01 ]

[TrsvK]

je kopieert inderdaad ook maar met 150mbit/s. Ik heb hetzelfde moederbord en met oude spinpoint 3,5'' schijven haal ik 750mbit/s als ik met smb in windows naar mn nas kopieer met een cpu belasting van rond de 40-50%. Heb wel 16gb ram ipv 8, weet niet of dat iets uitmaakt met zo weinig schijven. Over een paar maanden ga ik waarschijnlijk 10x4tb greens en een ssdtje halen, zal laten weten hoeveel dat helpt.

[Patatjemet]

analog_ schreef op maandag 03 maart 2014 @ 18:43:
Je bedoelt 12.5%, 1/8ste core volledig. Rsync is helaas singlethreaded en gaat voor geen meter vooruit om die reden. Ik gok dat het dus trager nu is.

Hoe bedoel je 1/8 core volledig? Ik heb de quadcore variant. Bedoel je dat die grafiek de gehele processor belasting aangeeft, dus 100% belasting zou alle 4 de cores volledig zijn?

TrsvK schreef op maandag 03 maart 2014 @ 19:24:
je kopieert inderdaad ook maar met 150mbit/s. Ik heb hetzelfde moederbord en met oude spinpoint 3,5'' schijven haal ik 750mbit/s als ik met smb in windows naar mn nas kopieer met een cpu belasting van rond de 40-50%. Heb wel 16gb ram ipv 8, weet niet of dat iets uitmaakt met zo weinig schijven. Over een paar maanden ga ik waarschijnlijk 10x4tb greens en een ssdtje halen, zal laten weten hoeveel dat helpt.

Zal vanavond even testen met smb.

[ Voor 40% gewijzigd door Patatjemet op 05-03-2014 13:02 ]

[damouzer]

InflatableMouse schreef op vrijdag 28 februari 2014 @ 17:29:
Helaas. Andere pc doet hetzelfde.

Net even buiten heel diep staan zuchten anders was er wat gesneuveld.

M'n md raids starten trouwens niet meer op nadat ik die m1015 in m'n andere pc heb gehad.
mdadm --examine /dev/sdh1 etc laat zien dat ze allemaal clean zijn maar waarom tie em niet assembled is mij even een raadsel. Gelukkig werkt ssh wel (start verder gewoon op) hoef ik niet op die koude zolder te zitten.

Shellx64.efi ... iemand ideen?

https://wiki.archlinux.or...nsible_Firmware_Interface

Deze even downloaden en hernoemen (Shellx64.efi) en op de usbstick zetten:
https://svn.code.sf.net/p...g/UefiShell/X64/Shell.efi

Stappen die ik gevolgd heb:

Bootable usbstick maken met http://rufus.akeo.ie/
V15 firmware gedownload uit forum van http://www.servethehome.com/ibm-serveraid-m1015-part-4/

usbstick dos boot:
megarec -writesbr 0 sbrempty.bin
megarec -cleanflash 0
reboot naar bios om EFI mode te starten
fs0:
sas2flash.efi -o -f 2118it.bin
sas2flash.efi -o -sasadd 500605004EXCEXX
sas2flsh -listall

reboot

Optie voor bootable kaart:
sas2flash.efi -o -f 2118it.bin -b mptsas2.rom

[ Voor 22% gewijzigd door damouzer op 05-03-2014 13:32 ]

[FREAKJAM]

Ik heb inmiddels Ubuntu server 13.10 met ZFS On Linux draaien. (6x3TB RAIDZ2). Het lijkt erop dat mijn schijven automatisch worden gedownspind, maar ik kan nergens vinden wat dit veroorzaakt/regelt. (ik kan gewoon ssh'en, dus ik ga er vanuit dat het niet de hele server is die in standby/hibernate mode staat). Ubuntu server 13.10 draait onder ESXi in een VM.

code:

hdparm -C /dev/sdb
/dev/sdb:
drive state is: standby

Ik heb trouwens niets ingesteld in /etc/hdparm.conf, smartd of wat dan ook. Betreft een versie installatie.

edit:
Kan natuurlijk ook mijn LSI2308 controller zijn die dit doet. In FreeNAS/ZFSGuru/NAS4Free etc gingen mijn drives niet automatisch in standby, maar misschien gaat Ubuntu hier iets handiger/beter mee om.

[ Voor 16% gewijzigd door FREAKJAM op 05-03-2014 15:30 ]

[tsjoender]

FREAKJAM schreef op woensdag 05 maart 2014 @ 13:42:
Ik heb inmiddels Ubuntu server 13.10 met ZFS On Linux draaien. (6x3TB RAIDZ2). Het lijkt erop dat mijn schijven automatisch worden gedownspind, maar ik kan nergens vinden wat dit veroorzaakt/regelt. (ik kan gewoon ssh'en, dus ik ga er vanuit dat het niet de hele server is die in standby/hibernate mode staat). Ubuntu server 13.10 draait onder ESXi in een VM.

code:

hdparm -C /dev/sdb
/dev/sdb:
drive state is: standby

Ik heb trouwens niets ingesteld in /etc/hdparm.conf, smartd of wat dan ook. Betreft een versie installatie.

edit:
Kan natuurlijk ook mijn LSI2308 controller zijn die dit doet. In FreeNAS/ZFSGuru/NAS4Free etc gingen mijn drives niet automatisch in standby, maar misschien gaat Ubuntu hier iets handiger/beter mee om.

Zou best eens een eigenschap kunnen zijn bij recente Ubuntu releases. Onder 12.04 deed ie het niet, maar ik probeerde laatst een 14.04 pre-release en die zette de schijf ook uit. Je zou eens kunnen kijken onder /etc/default/hdparm of daar iets verklaard waarom die dat doet of met hdparm -S0 /dev/sdb spindown weer uitzetten.

[Patatjemet]

Vandaag de tweede dimm binnen gekregen en wat blijkt, slot b1 doet het gewoon (als slot a1 ook bezet is). Kunnen andere gebruikers van het c2550d4i bordje bevestigen / testen of het bord met alleen slot b1 bezet niet boot? Of zou er toch wat aan de hand zijn met mijn bordje?

Gister en vandaag ook smb kunnen testen. Gister met 8 GB en vandaag met 16 GB. Beide keren een na een herstart van de server. Het ontvangende systeem is mijn htpc (i3, 8 gb, 64 gb msata m4). In de server draait een raidz-2 van 10 640 GB 2.5" disks. Zowel met 8 als met 16 GB haal ik met een 20 GB mkv bij zowel lezen als schrijven vrij stabiel de 750 Mbps. De cpu van de server zit hierbij rond de 40-50%. Het is dus exact hetzelfde als TrsvK (!).

[ Voor 6% gewijzigd door Patatjemet op 06-03-2014 14:43 ]

[TrsvK]

Goed om te horen dat het is goed gekomen. Weet je toevallig wat de maximale lees/schrijfsnelheden zijn van de schijfjes die je gebruikt?

[Patatjemet]

Van wat ik zo kan opmaken uit deze review en deze review is dat de maximale sequentiële doorvoersnelheid 95.1 MB/s is. Maar ik ben geen held in het interpreteren van dit soort grafieken, dus misschien zit ik er wel naast

Het zou in ieder geval aardig overeen komen met de resultaten die ik haal (raidz-2 = snelheid 1 disk toch?).