Ervaringen met unRAID?

[Raphie]

nou zo laag is die unraid performance nou ook weer niet, btw ik draai ondertussen al weer 2 weken

[jowi]

Met m'n nieuwe trunked gbit zit ik nu op 136mb sustained en het netwerk ligt niet stil voor andere pc's kan volgensmij nog wel sneller als ik vlans aanmaak

Echt waar joh? Jeetje, kerel toch. Das wel leuk voor je zeg.

[sj0er-D]

vandaar mijn plaatje

[Raphie]

Echt waar joh? Jeetje, kerel toch. Das wel leuk voor je zeg.

ik proef lichte frustratie met unraid Jowi

[Robert T]

Het mooie van een switch is dat het verkeer alleen van source naar destination mac address loopt dus tenzij de backplane van je switch bizar klein is zou je niks moeten merken van het aanmaken van VLAN's en scheiden van hosts. Het zal hooguit een bottlebeck introduceren wanneer je van het ene naar het andere VLAN's wilt communiceren, alles moet dan opeens gerouteerd worden wat theoretisch trager is dan switching. (MLS daarbij even niet in discussie meegenomen)

Met m'n nieuwe trunked gbit zit ik nu op 136mb sustained en het netwerk ligt niet stil voor andere pc's kan volgensmij nog wel sneller als ik vlans aanmaak

[Point7]

Hoe groot is die SSD ?
Een 128 GB is vol met 2 blu ray rips. Dan moet je de move actie handmatig starten ?
Of  kun je met een script kijken of er data is en dat dan moven ?
Om er nu voor heel veel geld een 512 GB SSD in te zetten ?

Ik heb gekozen voor een 128GB.  Is voorlopig genoeg.  Mijn "mover" start elk uur automatisch. Soms start ik die ook handmatig als ik niet kan wachten tot het volgende uur.
In't begin moest ik nog veel overzetten naar de UNRAID server en toen was die 1,5TB cache handig. 
Nu moet er af en toe een BLURAY/backup IMAGE naar de server en dan is 128GB voor mij ruim genoeg. 

[Point7]

Ik begreep dat het wegwerken van de cache automatisch ging, in idle time, of instelbaar, bijv. om 3 uur 's nachts ofzo. Ik zou het instellen als continue achtergrond taak, lijkt me het mooiste.

Klopt het wel dat het transparant is? Dus als ik een bluray naar de array schrijf in de folder bluray, dat unraid het zelf in de cache plaatst, maar dat ik het ervaar alsof het al op de correcte plek staat?

Je merkt helemaal niets van de cache drive. Behalve de hogere write snelheid.  Je schrijft gewoon naar een SHARE op de server en de cache weet zelf wel naar welke SHARE die achteraf verplaatst moet worden.

[Point7]

Nog maar iets wat me dan weer verbaasd over unRAID. Als je de unRAID boot software download voor op de usb stick, denk je dat je alles hebt toch? Maar nu blijk je weer ergens anders een pre-clear script en weer ergens anders iets als 'unmenu' vandaan te moeten halen en dat dan weer zelf bij dat stickie zetten. Is er een reden waarom ze dat apart houden? Ik bedoel iemand die er mee aan de slag gaat heeft die dingen toch nodig, het zijn geen optionele tools ofzo? Waarom doe ze dit?

Het zijn wel optionele tools/plugins.  Je hebt die niet nodig om met UNRAID te werken.  Het zijn gewoon tools die het nog iets gemakkelijker kunnen maken.

Die Preclear script zouden ze eigenlijk wel standaard mogen inbouwen, maar echt noodzakelijk is het niet om met UNRAID te werken.

[jaco]

Ik heb gekozen voor een 128GB.  Is voorlopig genoeg.  Mijn "mover" start elk uur automatisch. Soms start ik die ook handmatig als ik niet kan wachten tot het volgende uur.
In't begin moest ik nog veel overzetten naar de UNRAID server en toen was die 1,5TB cache handig. 
Nu moet er af en toe een BLURAY/backup IMAGE naar de server en dan is 128GB voor mij ruim genoeg.

Dat klinkt als een scenario voor mij..

Ik heb een paar TB te gaan van losse hdd's naar de unraid server. Ik denk maar een 1 TB hitachi HDT721010SLA360 te nemen die ik nog heb liggen.
Als ik dan alles over gezet heb kan ik wel zien welke SSD dan betaalbaar is en zelf die trim zaken doet, daar lijken er nu een paar van te zijn.

[Point7]

Als ik alle data van losse hdds naar de unraid doos wil copieren zal ik wel een grote cache driive moeten hebben. Ik neem aan dat het processen van de info van cache naar unraid toe langzamer gaat dan de copy slag van pc naar cache (anders zou de cache geen zin hebben)

Wat zijn hiermee de ervaringen ?

Toen ik begon met overzetten van grote hoeveelheden data naar de UNRAID server heb ik mijn PARITY disk uitgeschakeld totdat het meeste was gekopieerd om zo hoge write snelheden te halen zonder de cache drive nodig te hebben en daarna heb ik de parity ingeschakeld en laten checken.

[skank1]

Toen ik begon met overzetten van grote hoeveelheden data naar de UNRAID server heb ik mijn PARITY disk uitgeschakeld totdat het meeste was gekopieerd om zo hoge write snelheden te halen zonder de cache drive nodig te hebben en daarna heb ik de parity ingeschakeld en laten checken.

Slim, hoe dat ik daar vroeger zelf niet aan gedacht heb!

[jowi]

Toen ik begon met overzetten van grote hoeveelheden data naar de UNRAID server heb ik mijn PARITY disk uitgeschakeld totdat het meeste was gekopieerd om zo hoge write snelheden te halen zonder de cache drive nodig te hebben en daarna heb ik de parity ingeschakeld en laten checken.

Dat vind ik wel een slimme optie ga ik ook maar doen denk ik... Want ik moet nu erg veel copieren.

Weet iemand trouwens wat ik precies met de settings in de APCUPS plugin moet doen? Hij herkent keurig mijn APC UPS, maar ik moet blijkbaar 3 dingen instellen die natuurlijk weer eens NERGENS op het forum te vinden zijn:

- battery level ?
- minutes
- timout

Zie screenshot. Mijn UPS zou de boel overigens 85 minuten aan de praat kunnen houden
Wat ik dus eigenlijk in wil kunnen stellen is dat de UPS de boel zo lang mogelijk aan de gang houd, en bijv. 5 minuten voor dat ie zelf op is, de unRAID server gecontroleerd afsluit.

[Point7]

OK, nog een vraag. Ja ik vind het echt een waardeloos forum van Lime, ik kan er echt niks vinden, loop me altijd helemaal rot te zoeken tussen 300 topics die elk 90 pagina's bevatten en dan uit 2007 blijken te zijn ofzo. Wiki is ook een warboel, en stickie topics hebben ze ook amper van gehoord, dus ik vraag het maar hier.

Ik zie nu dat men het steeds heeft over de parity berekenen of checken en dat het zo lang duurt. Maar!!!! ik heb toch altijd begrepen dat de parity realtime wordt bepaald zodra je er iets schrijft? Het is toch niet zo dat je elke nacht ofzo de parity moet laten berekenen?

En waarom is er dan een optie om bijv. elke week of 2 weken de parity te checken? Is de parity dan soms niet goed? Maar dat zou betekenen dat je GEEN goede bescherming hebt?

Ik doe een parity check ongeveer om de maand. Dit is zowat een frequentie die vele op het forum toepassen. Ik start het gewoon handmatig. Ik heb al 1 keer meegemaakt dat tijdens deze check errors gevonden werden die echter wel allemaal gecorrigeerd werden.   De parity checks achteraf waren allemaal perfect.

De check gaat weer ALLE schijven VOLLEDIG checken. Er kan ondertussen een schijf tussen zitten met enkele "rotte" sectoren. Het is een kwestie van dit niet te lang laten aanslepen. De sectoren worden als bad aangeduid en je kan gewoon verder.

[jowi]

Ok, duidelijk, al vind ik het raar dat dit nodig is; ik krijg dan het idee dat het principe blijkbaar niet goed werkt... anders zou je achteraf geen checks hoeven doen immers...

Anyway, om de parity te stoppen, wat doe je dan, de array offline halen? Of 'unassign' je de parity disk?

[Point7]

Ok, duidelijk, al vind ik het raar dat dit nodig is; ik krijg dan het idee dat het principe blijkbaar niet goed werkt... anders zou je achteraf geen checks hoeven doen immers...

Anyway, om de parity te stoppen, wat doe je dan, de array offline halen? Of 'unassign' je de parity disk?

De array stoppen en dan inderdaad de parity disk unassign zetten en de array terug starten. Je hebt dan tijdelijk een unprotected array. In't begin is dat toch niet erg want je hebt de originele versies op de schijven die je naar de server moet kopieeren.

Normaal gezien zou je zo de maximale snelheid moeten halen bij het overzetten. De bottleneck op de server zal de gigabit NIC zijn.  De schijven in uw server zullen allemaal wel meer dan 100MB/sec kunnen halen.

Als de bronschijven ook meer dan 100MB/sec kunnen halen zal het overzetten vlot gaan.

[jaco]

Maar via de cache drive haal je toch ook redelijke snelheden ?
Ik move nu wat data van losse hdd's naar mijn PC toe om de hdd's vrij te maken (verkoop er een aantal)
Dan kan ik vanaf mijn raid-5 volumes wel een Gigabit Ethernet vol drukken lijkt me. Dan wordt de cache disk op de langzame delen van de disk wel een bottleneck vrees ik. Maar eens over nadenken..

[jowi]

Zonder parity disk haal ik niet meer dan 50MB/s... dat schiet ook niet echt heel erg veel meer op... dit vind ik dus wel langzaam.

[Raphie]

50mb kan wel kloppen dat is wat een single disk er zo maximaal door kan drukken, dat is dus wel een nadeel van "nep raid" 

[jowi]

50mb kan wel kloppen dat is wat een single disk er zo maximaal door kan drukken, dat is dus wel een nadeel van "nep raid" 

Je begon goed, sterk middenstuk, maar het eindigde weer een beetje sneu.
Toch bedankt voor je bijdrage.

[Raphie]

nep raid is natuurlijk een geintje, maar je begrijpt wel wat ik bedoel, de downside van data op enkele disk is natuurlijk de throughput, de voordelen zijn natuurlijk dat disks die niet nodig zijn, blijven slapen en dat je bij een crash bij de data op je individuele schrijven kan. tis maar wat je belangrijker vindt. voor mij is dat performance, het kan dus makkelijk 3x zo snel
goede nieuws is, dat als unraid je niet bevalt, je ook gewoon een echte raid 5 of 6 op je nas kan gooien

[jowi]

Het UPS verhaal.

- battery : is de minimale waarde in procenten die de batterij mag hebben. Komt ie hier op, volgt een powerdown
- minutes: als de batterij nog dit aantal minuten over heeft, krijgt de server een powerdown
- timeout : de maximale tijd in seconden die de unraid machine nog door mag draaien als ie op batterijen draait

De powerdown wordt getriggerd door de eerste van bovenstaande events. Stel dat zoals in mijn geval, de ups 65 minuten door kan draaien, en je hebt de timout op 300 seconden staan (5 minuten) dan zal dus na 5 minuten de server een powerdown krijgen. Heb je hem echter op 2700 seconden staan (45 minuten) en na 40 minuten heeft de battery nog maar 10% capaciteit over, dan zal de server toch een powerdown krijgen.

Allemaal wel logisch maar ja waarom zeggen ze dat dan niet meteen...

[Point7]

Zonder parity disk haal ik niet meer dan 50MB/s... dat schiet ook niet echt heel erg veel meer op... dit vind ik dus wel langzaam.

Dat is niet normaal. Wat is je bron ?

Wat haal je als je niet via een SHARE kopieerd maar rechtstreeks naar 1 van de schijven van de array ?   Als dit zonder parity is zou je echt meer dan 100MB/sec moeten halen bij moderne schijven groter dan 1TB.
Dan gebeurd namelijk hetzelfde als naar de cache schijf. Mijn vorige cache schijf was een 5400rpm 1,5TB schijf en die kon al write speeds halen >100MB/sec.

[jowi]

Split levels.

Ik heb nu gekeken wat er gebeurde bij een disk die bijna voor 50% vol zat (de grens waarop de toplevel gaat werken). Op een 4TB disk had ik 1TB aan series staan (/tvserie/naam/season/episode) met splitlevel 1, en bijna 1TB aan blurays (/movies/naam/bd_structuur/../../..) met ook splitlevel 1.

Ik ben net onder de grens van 2TB begonnen met het copieren van een bluray naar de USERSHARE. Die begon nog op disk1, omdat die nog net geen 50% vol was, en is daar in zijn geheel heen gecopieerd De volgende bluray die ik naar de usershare copieerde, werdt automatisch op disk2 gezet, waarbij netjes eerste de hele folderstructuur aangemaakt werd... precies zoals ik wil.

Ging ik daarna terug naar de usershare tvseries, en copieerde ik een NIEUWE serie, kwam deze ook op disk2 terecht! Terwijl als ik een al bestaande serie, die fysiek op disk1 stond, uitbreidde met een extra season of episode, BLEEF die ook gewoon op disk2, dus de hele serie, inclusief seasons en episodes, blijft bij elkaar.

Splitlevel 1 dus in mijn geval. de '1' geeft aan welk folderlevel gesplitst mag worden, en alles wat er aan vooraf gaat. Alles wat er NA komt, blijft bij elkaar.

In geval van

/tvserie/naam/season/episode

Is dus 'tvserie' level 1, en de folder 'tvserie'' mag dus gedupliceerd worden over de diverse disks. Het level er na, level 2, NIET. Die moet, met alles wat daarachter komt, bij elkaar blijven.

Had ik voor level 2 'serienaam' gekozen, dan had ik dus mogelijk de volgende fysieke situatie gehad kunnen hebben:

disk1
      - dexter
            - season 1
            - season 2

disk 2
     - dexter
            - season 3
            - season 4

Terwijl ik als USERSHARE gewoon nog steeds dit zou zien:
TV Series
      - dexter
            - season 1
            - season 2
            - season 3
            - season 4

met splitlevel 1 zorg ik nu dus dat alle seizoenen van een serie niet alleen in de usershare, maar ook fysiek bij elkaar blijven.

[Point7]

50mb kan wel kloppen dat is wat een single disk er zo maximaal door kan drukken, dat is dus wel een nadeel van "nep raid" 

Neen 50MB is echt niet normaal.  Dat is iets voor oude schijven van 160 a 320Gb ofzo. Een moderne grote schijf kan makkelijk meer dan 100MB halen.

[jowi]

Dat is niet normaal. Wat is je bron ?

Wat haal je als je niet via een SHARE kopieerd maar rechtstreeks naar 1 van de schijven van de array ?   Als dit zonder parity is zou je echt meer dan 100MB/sec moeten halen bij moderne schijven groter dan 1TB.
Dan gebeurd namelijk hetzelfde als naar de cache schijf. Mijn vorige cache schijf was een 5400rpm 1,5TB schijf en die kon al write speeds halen >100MB/sec.

Bron is een windows 7 64 bits Home Premium, gigabit netwerk.