Ervaringen met unRAID?

[skank1]

Blijkbaar niet. Want je hebt het niet getest of ervaren.

Man ik heb een ongeluk gehad , zit met 24 pinnen in mn been en dit al 5 maanden aan een stuk
Nu maandag terug operatie en dan terug 5 maanden ermee
Ik heb de cache wel degelijk gekocht voor snelheidswinst maar ik kan het absoluut niet testen nu...

[jowi]

Zo doe ik het ook...
Maar het klopt idd ergens niet....

Dat is dus de verkeerde werkwijze. Je zou gewoon naar de user share moeten kunnen copieren op full speed, beter nog, moven ctrlx/ctrlv in een split second.

Maar waarom kan je het niet testen dan? Je hebt geen pc tot je beschikking ofzo?

[riwi]

Maar waarom kan je het niet testen dan? Je hebt geen pc tot je beschikking ofzo?

Dat lag aan de wifi begreep ik.
Toen ik 3 maanden met mijn hernia lag had ik gewoon wired gbit bij mijn bed En met remote desktop kon ik op de kamer PC en ging het net zo snel als anders 

@skank : klinkt beroerd zeg, 24 pennen en operaties en zo. Dat valt niet mee. Hoop dat het je snel beter gaat! 

[jowi]

Zelf vermoed ik dat unRAID bij een cached user share, nog steeds de parity gaat berekenen zodra je er rommel naar toe copieert... en dat zou ie dus niet moeten doen. Pas als de mover er ('s nachts) fysiek mee aan de haal gaat, moet pas de parity berekend worden...

Ik zou het kunnen testen door de parity disk te unassignen, echter... dan volgt weer 12 uur lang parity check... zit ik ook niet op te wachten... ik hoop eerst dat ze op het lime forum eens wakker worden en mijn noodkreten beantwoorden.

[skank1]

Dat is dus de verkeerde werkwijze. Je zou gewoon naar de user share moeten kunnen copieren op full speed, beter nog, moven ctrlx/ctrlv in een split second.

Maar waarom kan je het niet testen dan? Je hebt geen pc tot je beschikking ofzo?

Zover ik het begrepen heb, heb je snelheidswinst tss:
1. kopieren van bv win7 pc naar een usershare zonder cache use
2. kopieren van win7 pc naar usershare met cache use

dit omdat hij geen parity protection heeft
Dit kan ik momenteel niet testen wegens het feit dat mn niet wired is.... (wel draadloos, maar dit is merkbaar trager)

Wat jij en ik nu blijkbaar doen/verkeerd doen is downloaden met sabnzb naar de cache disk
en dit moet dan op de usershare komen
hierdoor maak ik (en jij) eigenlijk dezelfde structuur aan op de cache, knip en plak het , en zet het mover script hem dan naar de juiste plaats...
Dit tov het kopieren van win7 pc naar usershare zonder cache, zal volgens mij geen snelheidswinst opgeven want de usershare blijft parity protected...

[skank1]

@skank : klinkt beroerd zeg, 24 pennen en operaties en zo. Dat valt niet mee. Hoop dat het je snel beter gaat! 

Ja, zwijg me ervan, al 5 operaties achter de rug; nog 2 te gaan
en dit allemaal omdat ik voorrang gaf aan een auto, en deze veel te kort ingedraaid heeft.....
Dan geef je hem es voorrang, rijdt hij je overhoop....

[jowi]

Wat jij en ik nu blijkbaar doen/verkeerd doen is downloaden met sabnzb naar de cache disk

NEE NEE NEE NEE NEE NEE NEE NEEEEEEE!!!!! Het heeft geen mallemoer met sabnzb te maken...

Ik copieer nu NOODGEDWONGEN naar een eigen gemaakte structuur omdat copieren naar de ECHTE user share dus te traag gaat.

[skank1]

NEE NEE NEE NEE NEE NEE NEE NEEEEEEE!!!!! Het heeft geen mallemoer met sabnzb te maken...

Ik copieer nu NOODGEDWONGEN naar een eigen gemaakte structuur omdat copieren naar de ECHTE user share dus te traag gaat.

Ik zeg toch niet dat het sabnzb zn schuld is?
Die user share waarnaar jij kopieert is parity protected, dus normaal dat het traag gaat
je gaat normaal enkel snelheid winst zien vanaf een andere pc naar de cache zelf......

Als jij kopieert van de cache (je eigen  gemaakte structuur) naar de ECHTE user share (die de cache gebruikt , maar hij staat al op de cache !!!!!!!!!!!!!!!!!!!!!!!) dan ga jij geen snelheidswinst zien !

ik zal het anders zeggen
kopieer eens vanaf bv je win pc naar de User share, dan moet je snelheid toch hoger liggen dan zonder de cache

[jowi]

IDie user share waarnaar jij kopieert is parity protected, dus normaal dat het traag gaat

Nogmaals, NEE NEE NEE NEE NEE....
Die user share is CACHED. Die is dus NIET fysiek onder de parity protection. Dat zou namelijk onzin zijn, want dan heb je geen snelheidswinst, EN DAAR GAAT HET OM met de cache disk. Daar is ie voor. Plus, lees de docs maar, de cache schijf is NIET protected. pas als de mover de boel naar de array verplaatst, is het protected.

Skank, ik hou er mee op. Je hebt geen idee wat je doet, hoe het werkt, of het werkt, je praat alleen maar het lime forum na, en doet alsof je een perfect werkend systeem hebt en wij (ik) een stel debielen zijn, terwijl je zelf eigenlijk geen benul hebt of alles werkt zoals het moet, je neemt het alleen maar aan dat het werkt.

En nogmaals, dat eigen gemaakt structuur is een WORKAROUND. Dat is NIET zoals het zou moeten werken. Vergeet dat nou maar, heb al spijt dat ik het uit probeer te leggen.

[skank1]

Nogmaals, NEE NEE NEE NEE NEE....
Die user share is CACHED. Die is dus NIET fysiek onder de parity protection. Dat zou namelijk onzin zijn, want dan heb je geen snelheidswinst, EN DAAR GAAT HET OM met de cache disk. Daar is ie voor. Plus, lees de docs maar, de cache schijf is NIET protected. pas als de mover de boel naar de array verplaatst, is het protected.

Skank, ik hou er mee op. Je hebt geen idee wat je doet, hoe het werkt, of het werkt, je praat alleen maar het lime forum na, en doet alsof je een perfect werkend systeem hebt en wij (ik) een stel debielen zijn, terwijl je zelf eigenlijk geen benul hebt of alles werkt zoals het moet, je neemt het alleen maar aan dat het werkt.

En nogmaals, dat eigen gemaakt structuur is een WORKAROUND. Dat is NIET zoals het zou moeten werken. Vergeet dat nou maar, heb al spijt dat ik het uit probeer te leggen.

Ik zeg toch zelf dat de cache, niet protected is, ik moet niks lezen
Je user share is niet cached, hij gebruikt hem...
Maw als je kopieert naar je user share, plaats hij hem eerst naar de cache, niet naar de user share zelf, je mover script plaats die dan van de cache naar je user share..
Ik begrijp het perfect
Kopieer maar eens rechtstreeks naar je user share vanaf een windows pc, hij zal perfect op de cache disk komen onder dezelfde mappenstructuur

Oh dus nu is het ganse lime forum een stel debielen?
lol ja ok, misschien daarom dat je geen antwoord krijgt...
En nogmaals, ik heb nergens problemen, zal wel aan mij liggen dan
Die eigen gemaakt structuur is een workaround omdat je bv sabnzb niet kan zeggen van, zet films onder die user share, zet series onder die user share enz
Mocht je wel verschillende mappen kunnen invullen, moet je die workaround niet eens gebruiken
En nee, mocht je het nu weer denken, sabnzb is inderdaad het probleem niet


Nogmaals je snelheidswinst haal je enkel als je naar je cache kopieert
dit kan ofwel naar een user share zijn of de cache zelf..

Indien je tracht te proberen van de cache zelf te kopieren (bv \films) naar een user share  \films, die ook de cache gebruikt, zal hij hem wel fysiek op de disk zetten vermits hij al op de cache staat, en dan heb je dus geen parity protection meer........

ik geef het nu ook op

[skank1]

Een user share is ALTIJD parity protected, of hij nu de cache disk gebruikt of niet.....
Een user share is niet parity protected als er staat "use cache only"

Nogmaals een user share IS niet cached, hij gebruikt hem !!!!!!!!!

man, zucht

[jowi]

Skank, je begrijpt er echt geen hol van. Ik ga het ook niet proberen uit te leggen, het gaat er toch niet in. Diepe zucht inderdaad.

[jowi]

Nogmaals je snelheidswinst haal je enkel als je naar je cache kopieert
dit kan ofwel naar een user share zijn of de cache zelf..

Ok, nog 1x dan.

als ik direct naar de cache copieer: 80MB/s
als ik naar de cached user share (dat IS de cache!!!) copieer : 50MB/s

WELKE snelheidswinst?

[Raphie]

  .....

[angel1978]

hahaha dit is bijna als een dagelijkse soap 

Jowi, Skank1 is idd. gewoon een fanboy die het ontdekte systeem prachtig vindt en absoluut geen kritiek wil horen op het door hem geadoreerde systeem.. Hij wil volgens mij ook helemaal niet weten hoe het werkt; weet je dat namelijk, dan ken je ook de nadelen en de minpunten en die horen sommigen liever niet

Ik volg dit topic vanaf het begin al met veel interesse omdat ik het systeem an sich wel interessant vind. Volgens Skank1 was dit HET systeem en bestaat er eigenlijk niets beters, met fantastische support en kost het eigenlijk bijna niets.. Ik snap de frustratie als je er dan achter komt dat dit allemaal een beetje tegenvalt, hoewel de puzzel an sich ook wel leuk is volgens mij ( ondanks alle frustratie )...

Maar zo moet je het volgens mij inmiddels ook zien:

Als ik een serieuze, goed werkende NAS wil hebben in RAID die gewoon doet wat ie moet doen en waar ik weinig omkijken naar heb, dan moet ik daar gewoon een X bedrag voor reserveren en voor een Synology gaan... Het kost wat, maar dan heb je ook wat..

Unraid is leuk voor de knutselaar en uiteindelijk krijg je wellicht ook wel wat je zou willen hebben, maar het is en blijft een knutselproject en daar moet je dus de tijd en zin voor hebben ( en de bereidheid niet je eigen tijd mee te rekenen, anders overstijgt deze in no time de kosten die je voor een synology zou hebben neergeleggd ).

Enige echte voordeel van de unraid die ik tot nu toe heb gezien is het leesbaar zijn van een enkele losse disk bij een calamiteit... Maar of de ingestoken uren daar tegenop wegen...

[skank1]

hahaha dit is bijna als een dagelijkse soap 

Jowi, Skank1 is idd. gewoon een fanboy die het ontdekte systeem prachtig vindt en absoluut geen kritiek wil horen op het door hem geadoreerde systeem.. Hij wil volgens mij ook helemaal niet weten hoe het werkt; weet je dat namelijk, dan ken je ook de nadelen en de minpunten en die horen sommigen liever niet

Ik volg dit topic vanaf het begin al met veel interesse omdat ik het systeem an sich wel interessant vind. Volgens Skank1 was dit HET systeem en bestaat er eigenlijk niets beters, met fantastische support en kost het eigenlijk bijna niets.. Ik snap de frustratie als je er dan achter komt dat dit allemaal een beetje tegenvalt, hoewel de puzzel an sich ook wel leuk is volgens mij ( ondanks alle frustratie )...

Maar zo moet je het volgens mij inmiddels ook zien:

Als ik een serieuze, goed werkende NAS wil hebben in RAID die gewoon doet wat ie moet doen en waar ik weinig omkijken naar heb, dan moet ik daar gewoon een X bedrag voor reserveren en voor een Synology gaan... Het kost wat, maar dan heb je ook wat..

Unraid is leuk voor de knutselaar en uiteindelijk krijg je wellicht ook wel wat je zou willen hebben, maar het is en blijft een knutselproject en daar moet je dus de tijd en zin voor hebben ( en de bereidheid niet je eigen tijd mee te rekenen, anders overstijgt deze in no time de kosten die je voor een synology zou hebben neergeleggd ).

Enige echte voordeel van de unraid die ik tot nu toe heb gezien is het leesbaar zijn van een enkele losse disk bij een calamiteit... Maar of de ingestoken uren daar tegenop wegen...

haha fanboy
ok je hebt volkomen gelijk
unraid is het beste dat er is... niks beters
there, you have it

Misschien moet je eens Solaris ZFS proberen, zal je pas weten wat snelheid is

[skank1]

Ok, nog 1x dan.

als ik direct naar de cache copieer: 80MB/s
als ik naar de cached user share (dat IS de cache!!!) copieer : 50MB/s

WELKE snelheidswinst?

Geen, en dan klopt ook niet, misschien een bug?
Zou toch even snel moeten zijn?
Stel het eens in het RC topic?
Of een direct post naar limetech toe?

Ik dacht dat jij snelheden aan het vergelijken was tss niet naar de cache kopieren en wel naar de cache...

[skank1]

Een user share is ALTIJD parity protected, of hij nu de cache disk gebruikt of niet.....
Een user share is niet parity protected als er staat "use cache only"

Nogmaals een user share IS niet cached, hij gebruikt hem !!!!!!!!!

man, zucht

mm klopt idd niet, als hij hem gebruikt is hij cached...

[Point7]

Compleet opnieuw assignen etc maakt ook niets uit.

Mijn conclusie: toevoegen van een cache disk, zelfs een supersnelle SSD, om het (perceptive) schrijven naar een user share te versnellen, werkt niet en is zonde van je geld.

Correctie: "werkte bij U niet"   Hier gaf dat wel een performance boost. Waarom het bij u niet wil werken is nog een raadsel. Ik vermoed dat het iets stoms is (zoals op het Limetech forum ook iemand schreef) en dat je daarom weinig reactie krijgt.
bv. doe je verkeerde handelingen zonder het eigenlijk te weten.   

[Raphie]

Jongens het gaat ook nooit sneller worden, troughput is namelijk van individuele disk, aka JBOD met de overhead van parity. Maar goed........ Ti's nog steeds geen volwaardige raid

[jowi]

Ik weet het skank het is ook gewoon moeilijk om uit te leggen wat ik doe, en wat ik (denk) wat de bedoeling is, en daar tussendoor wat ik denk dat er aan de hand is... 

[jowi]

Jongens het gaat ook nooit sneller worden, troughput is namelijk van individuele disk, aka JBOD met de overhead van parity. Maar goed........

Daar heb je hem ook weer.
Waar jij op doelt daar gaat dit niet over Raphie.

[Raphie]

Is van en naar, dus lees en schrijf troughput trouwens gelijk?

[Point7]

ik kan me voorstellen dat de cache ssd ook voordeel biedt bij het ontwaken van het systeem uit slaap/sluimer stand. met een SSD zal dat sneller zijn dan met fysieke schijven.

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.

[jowi]

De cache is dus een write-buffer.  Volle speed kopieeren naar de cache schijf omdat er nog geen parity wordt berekend. 

Zo heb ik het ook begrepen... en bij jou is de snelheid van copieren naar bijv. de root van de cache disk zelf net zo groot als naar een cached usershare. Bij mij dus niet... en daar klopt iets niet.