Ervaringen met unRAID?

[jowi]

wel erg kort door de bocht voor iemand die zijn probleem nog niet snapt?

Pardon?

Ik heb zowel de SSD als de 500GB harddisk op de externe SATA3 als op de SATA2 van het mobo gehad, beiden geven dezelfde copieer snelheden, waarbij 80MB/s over het netwerk voor hier max is, en een goede waarde.

De SSD op de externe SATA3 controller geeft overigens met hdparm -t average 275MB/s aan, op de SATA2 (intern) 130MB/s. Ik denk dat dit genoeg is om vast te stellen dat de zaak technisch in orde is.

Snelheden zijn in BEIDE gevallen, dus zowel de SSD als de harddisk, zowel sata2 als sata3, direct naar de cache 80MB/s, en via een cached share (dat is een specifieke, unraid oplossing), wat dus OOK direct naar de cache zou moeten zijn, slechts 50MB/s.

Waarbij 'cache' dus de ene keer een SSD is en de andere keer een harddisk.

Ik weet niet hoe ik het nog duidelijker uit kan leggen.

[jowi]

Zijn alle netwerk protocollen e.d. al uitgesloten? Probeer bijv eens direct op de commandline eens time cp <locatie van een redelijk grote file> <cache disk> en daarna hetzelfde naar een normale disk. Dan zou je de waarden moeten zien die het systeem intern haalt zonder overhead van SMB/NFS e.d.

Copieren naar een fysieke disk of naar de cache is gelijk.
Een cache is gewoon een fysieke disk, hetzij een ssd hetzij een harddisk.
'cache' wederom, is een unraid begrip voor een unprotected disk die als write buffer dient.

Maar wel een goede tip; ik ga op die manier eens kijken hoe snel ik van een interne harddisk naar de interne ssd kan copieren (de cache disk) en vanaf die harddisk naar een cached user share (wat dus feitelijk OOK naar die interne ssd is, zij het via een 'omweg').

[Point7]

De SSD op de externe SATA3 controller geeft overigens met hdparm -t average 275MB/s aan, op de SATA2 (intern) 130MB/s. Ik denk dat dit genoeg is om vast te stellen dat de zaak technisch in orde is.

Ik vind die 130MB/s niet normaal voor een SSD op SATA2. Ik zou daar ook 275MB/s (is normaal nog net haalbaar op SATA2) verwachten. 

[jowi]

Ik vind die 130MB/s niet normaal voor een SSD op SATA2. Ik zou daar ook 275MB/s (is normaal nog net haalbaar op SATA2) verwachten.

Daar heb je wel een goed punt...

Andere kant, als de SSD niet goed zou zijn zou ik met de 500GB harddisk als cache geen probleem moeten hebben, en die doet hetzelfde. 80 naar de disk, 50 naar de share. En dat is gewoon niet goed.

[jowi]

Zijn alle netwerk protocollen e.d. al uitgesloten? Probeer bijv eens direct op de commandline eens time cp <locatie van een redelijk grote file> <cache disk> en daarna hetzelfde naar een normale disk. Dan zou je de waarden moeten zien die het systeem intern haalt zonder overhead van SMB/NFS e.d.

Kopieren in de shell:
bestand van 1,5GB van disk1 naar de ssd disk: 19 seconden
bestand van 1,5GB van disk1 naar een cached user share (dus OOK naar de ssd uiteindelijk) 55 seconden...

Schiet mij maar lek.

[dennism]

Kopieren in de shell:
bestand van 1,5GB van disk1 naar de ssd disk: 19 seconden
bestand van 1,5GB van disk1 naar een cached user share (dus OOK naar de ssd uiteindelijk) 55 seconden...

Schiet mij maar lek.

Wat waren je 2 exacte kopieer commando's ?

[bart_nl]

Pardon?...Ik weet niet hoe ik het nog duidelijker uit kan leggen.

de uitleg is duidelijk en ik bedoelde alleen dat je de oplossing van je probleem nog niet weet. Naar mijn idee weet je in het algemeen een oplossing wanneer je het probleem weet. In jouw geval ervaar je de gevolgen van "een probleem" maar weet je nog niet zeker waar het aan ligt. Dat noem ik dan "... niet snapt".
Ik zou niet durven suggereren dat jij niet een duidelijk probleem hebt 

[jowi]

Wat waren je 2 exacte kopieer commando's ?

vanaf /mnt/disk1/backup, waar ik een 1,5GB bestand 'bestand1' in had gezet:

cp bestand1 /mnt/cache
cp bestand1 /mnt/user/movies

waarbij de laatste dus een (cached) user share is.

[jaco]

Wellicht is die Atom processor wel de boosdoender en hadden we beter een bord met een i3 of een i5 moeten kopen.
Ik ga er maar vanuit dat als de meeste data erop staat het allemaal gaat met een paar keer in de week een paar blu ray rips erop copieren.

[dennism]

Wat haal je als je naar een disk kopieerd die geen cache is, en ook geen cached share?

[jowi]

Wellicht is die Atom processor wel de boosdoender en hadden we beter een bord met een i3 of een i5 moeten kopen.
Ik ga er maar vanuit dat als de meeste data erop staat het allemaal gaat met een paar keer in de week een paar blu ray rips erop copieren.

Nou, de cpu komt tijdens deze acties niet boven de 25% uit... pas als je gaat parren en unzippen begint ie het warm te krijgen... en ja ik zorg dat ik dat soort dingen dus niet doe als ik de tests met de cache doe

[Raphie]

Wellicht is die Atom processor wel de boosdoender en hadden we beter een bord met een i3 of een i5 moeten kopen.
Ik ga er maar vanuit dat als de meeste data erop staat het allemaal gaat met een paar keer in de week een paar blu ray rips erop copieren.

de synology met atom haalt trunked makkelijk 140Mb dus processor zal het niet zijn

[Jeroen de Waal]

Jowi,

Hier schrijven ze nog wat over het verschil in snelheid tussen amd en intel bordjes.
Wellicht iets met het "probleem" van maximum doorvoer te maken?

* probeer alleen maar mee te denken *

http://forum.corsair.com/FORUMS/showthread.php?t=104241


Jeroen.

[jowi]

Wat haal je als je naar een disk kopieerd die geen cache is, en ook geen cached share?

Dus bijv een bestand van /mnt/disk1 naar /mnt/disk2?
1,5GB in 50 seconden... dat gaat zeg maar net zo snel... let wel, dit is een protected copy, er wordt dus realtime parity over berekend...

Feit blijft dat dit dus nét zo snel (langzaam) gaat als het copieren naar een cached user share. Met andere woorden, 'cached' geeft geen voordelen in mijn geval... sterker nog, het gaat net zo langzaam als op de protected array, en dan is het nog niet eens protected omdat de cache daar niet in valt

[jaco]

Bij parity controle nu 25%
eerder bij data naar de cache copieren en dus die parity slag was het 50%.

Ik ga over een oaar uur wel teste, dat is dan eindelijk alleen copy naar cache.
Moet ik er eerst wel wat vanaf halen, staat Bijna vol, 10 GB vrij..

[dennism]

Dus bijv een bestand van /mnt/disk1 naar /mnt/disk2?
1,5GB in 50 seconden... dat gaat zeg maar net zo snel... let wel, dit is een protected copy, er wordt dus realtime parity over berekend...

Feit blijft dat dit dus nét zo snel (langzaam) gaat als het copieren naar een cached user share. Met andere woorden, 'cached' geeft geen voordelen in mijn geval... sterker nog, het gaat net zo langzaam als op de protected array, en dan is het nog niet eens protected omdat de cache daar niet in valt

Imho lijkt het erop dat de cached user share helemaal niet cached is, en hij dus wel gelijk de parity berekening meeneemt daar het even snel/langzaam is wanneer je protected wegschrijft, of naar de cached disk terwijl direct naar de cache wegschrijven wel goed gaat. Mogelijk dat daar "onderwater" wat misgaat....

[jowi]

Als ik de parity uitschakel treedt er geen verbetering op...
Ook verschijnen er geen write acties op de parity disk bij het copieren naar een cache user share, en dat gebeurt wel als ik naar een non-cached user share copieer.

Maw, parity wordt niet berekend bij de cached disk... dus dat is in principe ook in orde

[dennism]

Wat je nog zou kunnen proberen is het kopieren opnieuw te doen naar cache en naar de cached user folder. Start dan voor je dit doet een 2de console sessie op waarin je het commando top draait. deze laat de processen zien en welke resources ze op dat moment gebruiken. Misschien dat je hier iets in kan ontdekken wat verschil maakt

[jowi]

Wat je nog zou kunnen proberen is het kopieren opnieuw te doen naar cache en naar de cached user folder. Start dan voor je dit doet een 2de console sessie op waarin je het commando top draait. deze laat de processen zien en welke resources ze op dat moment gebruiken. Misschien dat je hier iets in kan ontdekken wat verschil maakt

Zal ik vanavond eens gaan proberen.

[jowi]

Copieren naar de cache (ssd) direct laat zien in top dat smbd process (samba share neem ik aan) dan 95-100% cpu krijgt. Copieren naar een cached user share, zie je dat smbd 55% cpu krijgt en gezelschap krijgt van een ander proces 'shfs' 45% dus die 2 samen 100%...

Zegt dat iets? Ik las op unraid forum dat 'shfs' het onderliggende file system is wat verantwoordelijk is voor de user shares.

Als je verder zoekt op het unraid forum kom je 'mijn' klacht vaker tegen, alleen die topics worden of niet verder beantwoord, of er wordt na een aantal posts niets meer in gedaan...

[jaco]

Mover loopt nu, cpu ongeveer 40%

[dennism]

Is het mogelijk dat je de machine eens reboot en kijkt of deze cpu iets van speedstep of C1/C2/C3 Halt states heeft in de bios? kan goed zijn dat hier iets verkeerd gaat, daar 100% SMB cpu usage niet ok is. Mijn Syno gebruikt bij puur SMB traffic het volgende bij 90MB/Sec, dan lijkt het mij niet ok als jouw unraid doos bij dezelfde belasting op 100% loopt te stampen.

Code [Selecteer] Expand


CPU:  4.0% usr 31.5% sys  0.0% nic 56.7% idle  1.3% io  0.0% irq  6.3% sirq
Load average: 0.64 0.39 0.30 6/197 11091
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
11028 14746 root     D    25092  2.4 22.1 /usr/syno/sbin/smbd -D
4058     2 root     SW       0  0.0 10.4 [md2_raid5]


[dennism]

of paste even de uitvoer van "cat /proc/cpuinfo"  hier.

[jowi]

Is het mogelijk dat je de machine eens reboot en kijkt of deze cpu iets van speedstep of C1/C2/C3 Halt states heeft in de bios? kan goed zijn dat hier iets verkeerd gaat, daar 100% SMB cpu usage niet ok is. Mijn Syno gebruikt bij puur SMB traffic het volgende bij 90MB/Sec, dan lijkt het mij niet ok als jouw unraid doos bij dezelfde belasting op 100% loopt te stampen.

ik heb het over de kolom cpu in TOP, als ik in unraid naar de cpu stats kijk, doet ie maar 30%. Dus ik weet niet welke info ik je precies moet geven. ik zal screenshots maken, momentje.

1e plaatje: idle (referentie)
2e plaatje: copieren naar de ssd (cache) zelf
3e plaatje: copieren naar een cached share

[dennism]

je screenshots zijn uiteraard een moment opname, maar je belasting lijkt dus niet teveel te verschillen als die van mij.

Voor zover bij mij bekend is, is onderstaand dik gedrukt de CPU belasting totaal, dik gedrukt snapt ie niet in 'code' blijkt, het stukje tussen ['b'] en ['/b'] dus ;-)
en geeft de colom %CPU de onderverdeling weer per proces. Dus bij een totaal CPU gebruik van 44.3% is SMBD verantwoordelijk voor 22.1% van deze totale belasting.

Code [Selecteer] Expand

[b]CPU:  4.0% usr 31.5% sys  0.0% nic 56.7% idle  1.3% io  0.0% irq  6.3% sirq[/b]
Load average: 0.64 0.39 0.30 6/197 11091
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
11028 14746 root     D    25092  2.4 22.1 /usr/syno/sbin/smbd -D
4058     2 root     SW       0  0.0 10.4 [md2_raid5]