Ervaringen met unRAID?

[skank1]

De cache drive bij unRAID dient enkel om de schrijfsnelheid naar de server te verhogen.  Het lezen van data gaat rechtstreeks vanaf de harde schijven in de server. Daar komt de cache voor niets tussen.

De cache is dus een write-buffer.  Volle speed kopieeren naar de cache schijf omdat er nog geen parity wordt berekend.  Achteraf gaat de server deze data van de cache schijf naar de protected array verplaatsen wat veel trager gaat, maar daar hebben de client PC's dan geen last meer van.

Ik vraag me echt af of ik snelheidswinst zal hebben, tov vroeger, zou toch echt moeten, kon ik dit pc nu maar eens bekabeld krijgen..

[jowi]

Zojuist de parity disk offline gehaald, echter de snelheidsverschillen blijven. Het heeft dus niet met de parity te maken. Sterker nog, die werdt niet berekend voor cached shares, anders had eea al iets sneller moeten gaan Nu weer 12 uur wachten tot de sync klaar is

[skank1]

Zojuist de parity disk offline gehaald, echter de snelheidsverschillen blijven. Het heeft dus niet met de parity te maken. Sterker nog, die werdt niet berekend voor cached shares, anders had eea al iets sneller moeten gaan Nu weer 12 uur wachten tot de sync klaar is

Over welke snelheidsverschillen heb je het dan als je parity niet meer meetelt?

[jowi]

Geen. Het maakt niet uit. Met andere woorden, de parity wordt met een cached user share NIET berekend, zoals ik al zei. Want als ik het uitzet, zie ik geen verschil.

Als ik de user share NIET meer via de cache laat lopen, dan zie je wel een verschil, copieren naar een (parity protected, non cached) user share gaat dan met 32MB/s. Zet ik de cache AAN dan klimt ie tot 50MB/s. Dat is wel een verbetering maar het moet beter kunnen.

Op het unraid forum heeft er gelukkig iemand gereageerd en die zegt dat zodra je met user shares werkt, er altijd een snelheidsverschil zal zijn (trager) dan direct, omdat je door een bepaald subsysteem heen moet. Echter het zou niet zoveel uit moeten maken als ik ervaar.

[Point7]

OK....hier zijn enkele screenshots zoals het bij mij ingesteld staat.

FOTO 1:
Overzicht van mijn array.



FOTO2:
Overzicht van mijn shares.



FOTO3:
De share settings van de share "BLURAY".


FOTO4:
Op mijn computer heb ik een drive letter "T" van Tower toegewezen aan de share op mijn server.
Op die share staan de mappen (letters van alfabet) met elk hun films.

[skank1]

Ok ik ben mee...
Dus je hebt met cache wel snelheidswinst maar niet zoveel als direct naar de cache, en jij dacht dat dit +_ hetzelfde zou moeten zijn.

Geen idee , maar ik zou toch ook hetzelfde verwachten...

Dat je door dat subsysteem moet en dat je hierdoor snelheid verliest met usershares tov direct, Kan goed zijn.. Zover gaat mn kennis niet..

Ik zou het 9/10 zelfs nooit zelf gemerkt hebben denk ik, want ik zou het zo waarschijnlijk nooit doen, maar nu ik het weet zal ik het toch ook es testen zodra ik kan..

[jowi]

@skank: finally

@point7: settings zijn hetzelde als ik ze ook heb, kun je weinig fout aan doen...

[Point7]

nog een screenshot.

Daar zie je onder andere mijn 3 shares maar ook alle schijven individueel.

Als ik naar die 3 shares schrijf wordt de cache SSD gebruikt en haal ik dus meer dan 100MB/s. 
Ik kan ook rechtstreeks naar de disk'en (disk1, disk2, enz)  schrijven maar dan gaat de parity moeten berekend worden en dan haal ik maar 25 a 40MB/s afhankelijk naar welke schijf.

[Point7]

@point7: settings zijn hetzelde als ik ze ook heb, kun je weinig fout aan doen...

Staat ACHI enabled in de bios voor de SATA poorten waarop de SSD aanhangt ?

Ik herinner me ook iets vaag toen ik de server bouwde dat de SSD best op een bepaalde poort van het moederbord moest hangen om de optimale prestaties te krijgen.

Ik weet echter niet meer waarom en welke poort.

Mijn SSD hangt iig rechtstreeks op het moederbord.

Edit: oeps toen had ik die SSD nog niet wanneer ik de server bouwde. iig heeft de cash disk hier altijd rechtstreeks op het moederbord gehangen.

[jowi]

Ik zie niets bijzonders... zouden zo mijn plaatjes kunnen zijn.
De ssd hangt nu aan een sata3 SAS controller, hdparm -t geeft 275MB/s... heb hem ook aan een sata2 poort gehad op het mainboard, gaf ie met hdparm -t maar 130MB/s... echter in beide gevallen bleef de snelheid over het netwerk hetzelfde, dus 80 direct en 50 cached. ahci etc is enabled.

[Point7]

Ik zie niets bijzonders... zouden zo mijn plaatjes kunnen zijn.
De ssd hangt nu aan een sata3 SAS controller, hdparm -t geeft 275MB/s... heb hem ook aan een sata2 poort gehad op het mainboard, gaf ie met hdparm -t maar 130MB/s... echter in beide gevallen bleef de snelheid over het netwerk hetzelfde, dus 80 direct en 50 cached. ahci etc is enabled.

Dus rechtstreeks naar de cache SSD --> 80MB/s  (is normaal)
Naar een cached share --> 50MB/s (is idd niet normaal. Dit moet hetzelfde zijn als rechtstreeks dus ook 80MB/s) Om 1 of andere reden doet de cache zijn werk niet en wordt er precies al direkt een parity berekend ?

Kun je dit checken ?  Je schrijft naar de uw share dan mag er normaal geen write cycles zijn bijgekomen op de parity schijf. Die moet nog niets doen. Enkel als de mover in werking treed moet de parity schijf actief worden.

[jowi]

Ik heb vanmiddag de parity disabled (unassigned) en getest, dat maakte in snelheid niets uit. Ik kan jou methode nu niet testen aangezien ik nu dus de parity aan het her-opbouwen ben

[Jeroen de Waal]

Vwb downloaden heb je een beetje gelijk. Maar niet helemaal. Want stel je hebt die 40GB bluray gedownload, en hij staat in je completed download folder op je cache drive. Dan moet je hem nog steeds naar je user share copieren... Dus sleep je hem naar je user share, en dan gaat ie met een slakkegang het ding daarheen copieren TERWIJL DIE SHARE DUS AL OP DE CACHE DRIVE ZELF ZIT!!!!! snap je het probleem?

Nu weet ik niet of ik helemaal op 1 lijn met je zit Jowi...

Maar wat je bedoelt is dat je via explorer naar je cache drive gaat en vervolgens een map/bestand kopierd met control-c en vervolgens naar je user share gaat via explorer en control-v doet?

Zo ja dan gaat dat zeker traag gezien Windows niet snapt dat het in 1 dezelfde machine zit en dus feitelijk eerst de map/bestand naar je pc haalt en vervolgens doorstuurt naar je user share.


Jeroen.

[jowi]

Nu weet ik niet of ik helemaal op 1 lijn met je zit Jowi...

Maar wat je bedoelt is dat je via explorer naar je cache drive gaat en vervolgens een map/bestand kopierd met control-c en vervolgens naar je user share gaat via explorer en control-v doet?

Zo ja dan gaat dat zeker traag gezien Windows niet snapt dat het in 1 dezelfde machine zit en dus feitelijk eerst de map/bestand naar je pc haalt en vervolgens doorstuurt naar je user share.

Nee, de CACHED user share. Die is dan aangemaakt op de ssd. SMB is dan slim genoeg om dan niet heen- en weer te copieren maar te moven. Echter ik gebruik het woord moven niet omdat dat in unraid teveel op 'mover' lijkt; het script wat 's nachts de cache verplaatst naar de array. Daarom zeg ik ctrlx/ctrlv (dus NIET ctrlc/ctrlv...)

Eea is erg unraid specifiek, ik kan me voorstellen dat het voor niet-unraiders moeilijk te volgen is.

[jowi]

Zou ik met initconfig of in simple features 'new config' een reset kunnen geven? Om zeg maar van scratch af aan te beginnen, ZONDER data te verliezen?

Ik weet precies welke disk in welk slot zit/hoort... iemand dit wel eens gedaan?

[skank1]

Dus rechtstreeks naar de cache SSD --> 80MB/s  (is normaal)
Naar een cached share --> 50MB/s (is idd niet normaal. Dit moet hetzelfde zijn als rechtstreeks dus ook 80MB/s) Om 1 of andere reden doet de cache zijn werk niet en wordt er precies al direkt een parity berekend ?

Kun je dit checken ?  Je schrijft naar de uw share dan mag er normaal geen write cycles zijn bijgekomen op de parity schijf. Die moet nog niets doen. Enkel als de mover in werking treed moet de parity schijf actief worden.

Daar ben ik ook wel benieuwd naar!

[Raphie]

Normaal gesproken heb je in Linux de raidset en configuratie los. Een reset van de Configuratie zou dus niet tot dataverlies moeten leiden

[jaco]

Nu even een copy met windows 7 standard copy naar de cache: 40.5 MB/sec
Maar nu draaien er ook weer 2 hdd's te pre=clearen, maar dat zijn wat langzamere en die doen nu 80 Mbyte/sec per stuk.

[EJ]

Dan loop je vast tegen beperkingen van de bus aan. Hoe is je exacte configuratie?
Vergeet niet dat pre-clearen in principe op max snelheid zal gebeuren.

[jowi]

Ik heb alles weggemieterd en ga een compleet nieuwe config maken... nu maar hopen dat de data niet weg is zelfs de usb opnieuw geformatteerd...

[jaco]

Ik heb de een moederbord van super micro, zelfde als jowi. 4 GB ram.
Zal morgen een cross kabel aansluiten op de 2e lan port van de unraid server, en de 2e interface op de pc, en dan de firewall daarvanaf halen.
Wellicht vertraagd die het. En ergens morgen zullen deze hdds wel klaar zijn met de pre clear.
Dan zal ik maar eens weer testen.

En.. De unraid server is weer een keer gecrashed op de sata driver (mvsas)
Morgen maar de rc6 erop zetten, kijken of die stabieler is..


Om even de server te beschrijven:
Mainbord Supermicro X7SPA-HF-D525
4GB geheugen
Areca ARC-1300ix-16 (marvel chip)
Cache drive Hitachi 1 TB aan mainbord
Parity drive Hitachi 4 TB aan mainbord
4x hitachi 4 TB data drive aan areca


De bron is een assus workstation moederbord met een i7-920, 12 GB ram en windows 7 Ultimate
Data staat op een raid-5 volume aan een Areca arc1130 PCI-X raid controller.
Dit zij 5 * 1 TB hdd's van WD, Raid edition hdd's

Ik kan een copy van dezelfde raid volume naar een 80 GB raptor opstarten en dan krijg ik er 50 Mbyte/sec BIJ, dus de 37 Mbps blijft ook copieren richting unraid. Ik denk dat het vanuit mijn source wel sneller zou moeten kunnen dus..

[jowi]

En ik ben ook weer in de lucht. 100% reset.

En het helpt niks. Copieren naar een cached user share gaat nog steeds de helft langzamer dan direct naar de cache, maar wel sneller dan naar een niet-cached user share.

Ik geef het op. Ik ga wel een script of plugin bouwen die mijn workaround tot standaard verheft

Moet zeggen dat je er wel handig in wordt op deze manier

[eduard]

Jowi,
Als je nog een disk over hebt zou je voor de LOL er even win7 op je server kunnen zetten. Je zou op die manier kunnen kijken of je onder win7 wel met hoge snelheid data heen en weer kan zetten. Op die manier heb je tenminste de hardware van je server uit gesloten.

Heb je de cpu van je server wel eens bekeken als je data naar je cache en wanneer je naar je share op de cache schrijft?

Eduard

[jowi]

Windows gaat niet helpen, dit is een interne unRAID aangelegenheid.
Ik zal morgen, als de parity up te date is, verder testen.

[jowi]

Trouwens, nu ik de boel opnieuw heb opgezet heb ik geen problemen meer met de logitech plugin, installeert gewoon in 1x zonder gedoe... ook gaat de parity sync als een speer; hakt er met 120MB/s doorheen... er gaan dus ook wel dingen goed