Het grote DIY RAID NAS topic deel 3

[Paul]

En daar verschillen we dus van mening, want ik (en anderen) zijn dus van mening dat

Het verhaal dat je bij ZFS persé ECC geheugen moet gebruiken, is denk ik gewoon onzin. Het is een extra vorm van zekerheid, die je juist als je geen ZFS gebruikt extra hard nodig hebt. Gebruik je ZFS dan is de noodzaak voor ECC geheugen juist veel minder.

eerlijk en goed geïnformeerd is en dat

ZFS zonder ECC draaien is alsof je in een auto stapt met gordels maar zonder remmen.

een bijzonder overdreven stukje FUD is

"de wereld vergaat" is mijn creatieve interpretatie van hetgeen ik hierboven van je quote... Ik zie overigens nu pas dat je die ondertussen lijkt te hebben aangepast naar "met remmen maar zonder gordels", wat de strekking wel wezenlijk anders maakt, als dat er direct had gestaan dan had ik ook wat anders gereageerd

[Berkeley]

Is ECC geheugen niet echt alleen nuttig voor een NAS als je op _al_ je clients die de NAS gebruiken ECC hebt? Want als de data al corrupt op de NAS komt, lijkt mij niet dat ECC daar iets aan kan veranderen?

[Verwijderd]

RobHaz schreef op dinsdag 05 augustus 2014 @ 20:05:
Is ECC geheugen niet echt alleen nuttig voor een NAS als je op _al_ je clients die de NAS gebruiken ECC hebt? Want als de data al corrupt op de NAS komt, lijkt mij niet dat ECC daar iets aan kan veranderen?

Dat zie je verkeerd. De kans dat het op je NAS verkeerd gaat komt bovenop de kans dat het op je PC al mis gaat. Het optreden van fouten is zelfs onafhankelijk. De kans dat je data corrupt wordt opgeslagen is

P(data corrupt) =1 - (1 - P(data PC corrupt)) * (1 - P(data NAS Corrupt))

Alleen vanaf dat moment 'leeft' de data op je NAS en zijn je backups kopieen van wat op je NAS staat. ZFS beschermt je tegen harddisk fouten, als dat misgaat zal er data corruptie optreden, helemaal los van wel of geen ECC in je PC! Gaat het bij het teruglezen van je data op je PC een keer fout wegens geen ECC is dat geen punt, het staat immers nog goed op je NAS en je probeert het opnieuw. Gaat het bij het overschrijven naar je NAS fout op je PC dan red je snapshot je. ECC op de NAS is dus (voor de meeste zaken) vele malen belangrijker dan ECC op je PC.

Overigens of je bij ZFS ECC moet gebruiken hangt er ook vanaf waarom je ZFS gebruikt.

Als je antwoord daarop is vanwege die handige snapshots en de makkelijke management tools, en voor de data bescherming vind ik regelmatige backups voldoende; het is niet interessant als er af een toe een bestand verloren zou kunnen gaan. Dan kan je zonder ECC draaien; zolang je je maar bewust bent welke trade off je maakt.

Als je echter zegt dat je kiest voor ZFS vawege het belang van je data en er mag absoluut niets verloren gaan, dan ben je gewoon verkeerd bezig door geen ECC te nemen. Zoals ik en een ander eerder al aangeven zijn de extra kosten minder dan die van een extra harddisk. En je vind je data blijkbaar belangrijk genoeg om twee hele harddisks aan redundantie te spenderen (RAIDZ2 - RAIDZ1 is schijnveiligheid vandaag de dag).

[FireDrunk]

@Q, jij durft dus te beweren dat NTFS minder met RAM doet dan ZFS, ok, actief gezien kan ik je daarin geloven, per transactie (of in NTFS' geval, per IO) zal er minder geheugen gebruikt worden, maar er is nog zoiets als cache.

Een hele simpele test dan:



Goh... Ik heb momenteel 6GB aan File Cache actief op mijn desktop...

Dat is letterlijk *meer* dan op mijn Ubuntu NAS met ZFS (die heeft een ARC limiet van 4GB, en staat uit zijn neus te eten, dus er zijn geen lopende transacties...)

Er is dus niet zomaar sprake van, dat NTFS minder rust op geheugen... Het kan wel, als je zoveel applicaties hebt draaien, dat er geen ruimte is voor cache... Maar ik acht die kans klein...

[Ultra]

Ik snap die vergelijking met andere file systems niet zo. Als je voor betrouwbaarheid gaat kies je op 't moment voor ZFS icm ECC. ECC kun je, indien goed geinformeerd, weglaten, maar dat blijft een suboptimale keuze. Wat een ander FS daarmee te maken heeft .

[Staatslot]

Ik ben heel voorzichtig aan het rondkijken en aan het sparen voor wat moois.
Plan is om het ding niet 24/7 te laten draaien, dus vooral dagelijks 's avonds een paar uurtjes aan en in het weekend wat meer, zodat er muziek/video/foto's kunnen worden gestreamd naar de devices in huis. Verder is mijn idee ZFSguru en disks in RAIDZ2. In ieder geval dus echt als dedicated NAS.

Natuurlijk wat vragen

• Gaat dit vaker in- en uitschakelen ten koste van de disks waardoor ik het toch beter 24/7 aan kan laten staan?
• Is het om een andere reden onverstandig om enkel paar uurtjes per dag aan te zetten? Ik denk aan bepaalde acties die ZFSGuru bv 's nachts uitvoert, en daar in mijn geval dus nooit aan toe zal komen
• Is spindown mogelijk (en zo ja, eenvoudig of alleen met een hoop trucs te realiseren?) Ik verwacht dat de disks die niet downspinnen namelijk anders de grootste stroomvreter zullen zijn?

Ik heb zoveel mogelijk meegelezen en de tips verzameld.

Daarom denk ik aan:

• Moederbord met veel onboard poortjes, dus geen HBA nodig
• ECC memory (al snap ik de discussie, die wil ik niet opnieuw aanslingeren )
• Geen SSD, geloof niet dat ik dit nodig zal hebben als cache
• 8x WD Green WD40EZRX, RAIDZ2 dus pakweg 24TB netto

Ik heb twee kasten op het oog, maar die vereisen een klein moederbord, en de combinatie klein moederbord met veel sata poortjes is zeldzaam dus daar puzzel ik nog..

#	Product	Prijs	Subtotaal
1	Fractal Design Node 804	€ 85,97	€ 85,97
1	Silverstone DS380	€ 149,-	€ 149,-

Zijn er tips/overwegingen die jullie me mee kunnen geven in mijn zoektocht en kunnen jullie mijn (domme?) vragen beantwoorden? Thanks!

[FireDrunk]

Ultra schreef op dinsdag 05 augustus 2014 @ 21:40:
Ik snap die vergelijking met andere file systems niet zo. Als je voor betrouwbaarheid gaat kies je op 't moment voor ZFS icm ECC. ECC kun je, indien goed geinformeerd, weglaten, maar dat blijft een suboptimale keuze. Wat een ander FS daarmee te maken heeft .

Er wordt gesuggereerd dat het veiliger is om NTFS te gebruiken zonder ECC dan ZFS te gebruiken zonder ECC omdat NTFS (en vergelijkbaar) minder sterk op het geheugen leunen.

Dit probeerde ik dus te ontkrachten... Alle filesystems maken gebruik van het geheugen. Soms wat actiever, soms wat minder actief... Maar het blijft grijs gebied... Om die reden zeg ik: ZFS zonder ECC is beter dan NTFS, omdat je altijd meer kans hebt op detectie dan met NTFS.

Wil je super veilig? Uiteraard ga je voor ECC. Dat spreekt voor zich... Kan je het weglaten in mijn ogen? Ja als je weet wat je doet wel ja...

[Q]

@Firedrunk, dat is read cache.

Mijn scenario waar ik vooral aan refereer is wat er gebeurt als goede data, via verrot RAM op de NAS storage komt. ZFS cached alle writes in txg's in RAM,

Writes worden door legacy file systems niet eens gebufferd naar ik weet, omdat deze file systems uit een tijd komen dat geheugen nog duur was en werd vertrouwd op het cache geheugen van de disk of RAID controller en writes moeten zo snel mogelijk veilig op disk komen was het motto (ZFS gaat hier heel anders mee om). Dus op dit vlak ben je gek genoeg misschien beter af dan ZFS. In dit scenario.

Operating systems hebben wel een soort van dirty page buffer die af en toe wordt weggeschreven en writes worden ook in RAM gecached voordat ze worden weggeschreven. De vraag is hoeveel RAM daarvoor wordt gebruikt, bij ZFS is dat al snel 5 seconden x performance van vdev /s.

Dus omdat legacy file systems het RAM 'relatief' omzeilen bij writes, loop je minder risico op een rotte bit te komen bij het schrijven van je data naar storage.

Dus je kunt stellen dat je bij ZFS een grotere kans hebt dat goede data via rot geheugen rot op disk komt dan bij legacy file systems en dat is juist het punt.

Wat betreft jouw punt met de read cache: als goede data van disk wordt gelezen en op rot RAM terecht komt dan zal ZFS ten onrechte de conclusie trekken dat die data rot is. Mogelijk gaat zij zelfs goede data 'repareren' en daardoor juist corruptie introduceren op data die goed op disk staat. Als ik dit verkeerd heb hoor ik het graag. Voorgaande is wat ik van de artikeltjes heb begrepen die ik eerder heb gelinked.

Legacy file systems zullen gewoon dom rotte data uit ram aan de applicatie voeren, maar als je het geheugen vervangt of de storage in een ander systeem stopt, is de data nog in tact.

Zowel met ZFS als met NTFS zal je applicatie dan qua lezen rotte data voorgeschoteld krijgen, met als extra risico dat ZFS je goede data ondisk om zeep helpt door de self healing features die dan juist tegen je gaan werken.

Dit is waarom ik de stoute bewering doe dat non-ECC RAM juist gevaarlijker is met ZFS dan met legacy file systems. en dat je dus beter ofwel gewoon maar helemaal geen ZFS kunt draaien dan ZFS met non-ECC RAM.

@Paul: Hier een paper dat wederom laat zien dat die mening niet klopt. ZFS is niet minder gevoelig voor memory fouten, maar juist meer omdat het zo afhankelijk is van RAM geheugen.

http://research.cs.wisc.e...zfs-corruption-fast10.pdf

Our analysis reveals the importance of considering both memory and disk in the construction of truly robust file and storage systems.

[ Voor 10% gewijzigd door Q op 05-08-2014 22:25 ]

[FireDrunk]

Mja, in het geval van writes is het inderdaad waar, hoewel NTFS inderdaad een nog steeds een write buffer heeft, en onder linux heb je zelfs een heel groot write buffer (vm.dirty_pages heet het geloof ik...).

Ik vind nog steeds in veel opzichten dat je gelijk hebt hoor.. ECC is *ALTIJD* beter... *ALTIJD*...

Is het wat mij betreft de prijs waard? In mijn geval niet, maar zoals ik al eerder zei, ik heb maar een NASje met wat Films, ISO's, en wat TV Series... Zou ik voor *echt* kritieke data voor non-ECC NAS gaan? Nee... Heb je het dus nodig als je nuclear proof storage wil, ja, natuurlijk... Daar hoef je mij echt geen papers voor te laten zien

Ik denk dat de beste analogie misschien wel is: Jij laat iemand liever fietsen, omdat er minder mensen dood gaan aan fietsen dan aan autorijden... CiPHER, Paul en ik raden iemand een Ford Ka aan, omdat ze een Land Rover 4x4 niet kunnen betalen.

Is er een kans dat iemand dood gaat in een Ford Ka? Ja zeker... Is die groter dan op de fiets? Ja vast...
Is het een risico wat je wil nemen?

Ik wil, want ik wil droog zitten

PS: Ik bedenk me nu, misschien is de gulden middenweg wel heel simpel... Schrijf een scriptje wat als een idioot alarm slaat als je Checksum errors hebt... Mensen zonder ECC geheugen? Maak een goede backup, Controleer of je backup gelopen heeft (zo niet, ben je een sukkel ) en draai even Memtest, is dat OK? dan ligt het aan je schijven.
Mensen met ECC geheugen? Check je kernel logs, zie je een losse single bit error, kan je rustig slapen. Zie je niets, ligt het aan je disks.

[ Voor 18% gewijzigd door FireDrunk op 05-08-2014 22:22 ]

[Q]

Ik deed stoute uitspraken over dat legacy file systems bijna veiliger zijn dan ZFS als je non-ECC geheugen gebruikt omdat ze niet zo op het RAM leunen bij writes, maar dat is fout. Windows en Linux cachen writes inderdaad enorm in RAM en alhoewel beide operating systems niet zoveel geheugen proberen te pakken als ZFS, maakt dat eigenlijk niet zoveel uit. Ik hou het er op dat ZFS en legacy file systems beiden even kwetsbaar zijn voor RAM fouten.

@Firedrunk, ik snap je analogie niet maar ik denk dat ik murw ben van het zeiken over ECC geheugen.

Helaas gaan backups je nooit helpen als je ZFS draait met non-ecc geheugen. Het scenario waarbij er silent data corruptie optreed is allen als data nieuw naar disk wordt geschreven, bijvoorbeeld vanaf het netwerk vanaf een client PC. Dus de corruptie dit dan vanaf dag 1 in je backup .

[ Voor 33% gewijzigd door Q op 05-08-2014 22:34 ]

[MrLurch]

Je checksum van je data blijft inktakt op je schijf. Zodra je data leest wat in je ram corrupt raakt zal zfs zien dat de checksum niet overeen komt en hierdoor een read error geven. ZFS zal je data niet proberen te repareren aangezien je checksum niet veranderd is op je disk. Zodra je weer rotte data vanuit je ram naar je disk gaat schrijven zul je inderdaad een probleem hebben. ZFS berekend van de rotte data een checksum die als goed bestempeld wordt terwijl de data eigenlijk rot is.
Zelf heb ik ooit eens een zfs server gebruikt met non-ecc ram. Ik kreeg heel veel read error's dus ik dacht dat er een disk aan het overlijden was. Na een memtest bleek echter dat er fouten in het geheugen zaten en er niks met de schijven aan de hand was. De data was gelukkig nog intakt.
Voor mij dus alleen ECC geheugen in een zfs server

[FireDrunk]

MrLurch schreef op dinsdag 05 augustus 2014 @ 22:29:
Je checksum van je data blijft inktakt op je schijf. Zodra je data leest wat in je ram corrupt raakt zal zfs zien dat de checksum niet overeen komt en hierdoor een read error geven. ZFS zal je data niet proberen te repareren aangezien je checksum niet veranderd is op je disk. Zodra je weer rotte data vanuit je ram naar je disk gaat schrijven zul je inderdaad een probleem hebben. ZFS berekend van de rotte data een checksum die als goed bestempeld wordt terwijl de data eigenlijk rot is.
Zelf heb ik ooit eens een zfs server gebruikt met non-ecc ram. Ik kreeg heel veel read error's dus ik dacht dat er een disk aan het overlijden was. Na een memtest bleek echter dat er fouten in het geheugen zaten en er niks met de schijven aan de hand was. De data was gelukkig nog intakt.
Voor mij dus alleen ECC geheugen in een zfs server

Dat is niet helemaal waar, ZFS zal de metadata checksummen, en als die correct is, ervan uitgaan dat de checksum op disk kapot is, en deze opnieuw genereren. Als dat gedaan is wordt de checksum opnieuw vergeleken met de in ram metadata, en als dat overeenkomt, word er een nieuwe checksum naar disk geschreven.

ZFS is self healing, zowel voor data, checksums, als metadata (metadata is ook nog redundant opgeslagen).

(voor zover ik weet)

Het punt wat Q maakt, dat ZFS corrupte data zal wegschrijven, is dus zeker valide... Dat zeggen de papers ook duidelijk... Maar dat moet de discussie helemaal niet zijn.

Het enige wat ik probeerde (want het is inmiddels gelukt) is dat het risico bij ZFS niet (noemenswaardig) groter is dan bij andere filesystems.

Dus ja, het is nog steeds aan te raden om ECC te gebruiken met ZFS. Maar dat is het ook bij andere filesystems.

Misschien is het leuker om de discussie een andere kant op te sturen, namelijk: Wat kun je doen om zo snel mogelijk erachter te komen dat er iets mis is met je server?

Ik bedoel, Q is goed in wat simpele scriptjes schrijven (veel beter dan ik zelfs, en ik ben afgestudeerd programmeur ).

Laten we hier dan delen wat we allemaal doen om het systeem wat je thuis hebt staan mooi intact te houden!

[ Voor 23% gewijzigd door FireDrunk op 05-08-2014 22:38 ]

[Paul]

Q schreef op dinsdag 05 augustus 2014 @ 22:01:
@Paul: Hier een paper dat...

Ik moet bekennen dat ik net iets te snel gelezen heb gisteren Ik geef toe dat ZFS mogelijk meer aan ECC kan hebben dan legacy filesystems. Dan nog ben ik van mening dat je ECC bij ZFS eerder moet vergelijken met ABS dan met de gordels

[Verwijderd]

Die paper gaat vooral in op de End-to-End data integrity protection; die verlies je als je RAM niet te vertrouwen is. Dat betekent dat corrupte data kan worden doorgegeven aan applicaties in geval van datacorruptie.

Voor thuisgebruikers is dat helemaal niet zo relevant als voor bedrijven. Het gaat immers niet om permanente corruptie; bij een volgende read/scrub/whatever kan de data weer corruptievrij worden uitgelezen.

Ik heb zelf testjes gedaan met defect RAM. Bij de vele vele vele RAM fouten kwamen ook veel checksum fouten naar voren. Uiteindelijk werd bij omruilen van het geheugen alle fouten ook weer hersteld; met handmatige MD5 checksums waren de bestanden ook allemaal identiek als tevoren.

Kortom, ZFS heeft wel degelijk de mogelijkheid van correctie en heeft daarnaast een prima mogelijkheid van detectie voor RAM bitflips. Dat is de reden dat ik stel dat ZFS beter tegen non-ECC RAM kan, dan NTFS.

Veel eigen ervaring leert ook dat mensen met checksum errors uiteindelijk foute RAM latjes hadden. Dat deed verder niets met hun pool; geen permanente corruptie. Kortom, ZFS kan prima tegen een stootje.

Dat sommige mensen een mening hebben dat je alleen voor ZFS zou mogen kiezen als je het hélemaal goed doet en ook gelijk voor SAS disks gaat en ook gelijk EMI-shielding behuizingen gebruikt en meer van dat soort dingen, is vooral een mening. Maar dat ZFS corruptie veroorzaakt door RAM bitflips kan detecteren en in sommige/meeste gevallen ook kan corrigeren, is een aantoonbaar feit.

Dat zegt nog niets over de vraag of het nu beter is om wat extra geld te geven voor ECC. Ik heb wat gezocht en inderdaad is het qua budget prima mogelijk om voor ECC te gaan. Echter, dat betekent wel minder hardwarekeuze qua moederbord en CPU. Juist de leuke mini-ZFS servers zoals op basis van Kabini/Bay trail bieden geen mogelijkheid tot ECC. Dat is wellicht nog het grootste bezwaar: de keuze voor ECC betekent een beperking van de hardware keuze, vooral als je het betaalbaar wilt houden.

Laten we verder ieder vrij laten om wel of niet voor ECC te kiezen. Roepen dat iemand beter NTFS kan draaien als hij een ZFS server bouwt met non-ECC geheugen vind ik echt enorm trollerig. Het is een extra bescherming voor diegenen die dit wenselijk achten en bereid zijn meer te betalen cq. hun hardwarekeuze hierop af te stemmen. Prima toch?!

[Verwijderd]

Staatslot schreef op dinsdag 05 augustus 2014 @ 21:43:
Gaat dit vaker in- en uitschakelen ten koste van de disks waardoor ik het toch beter 24/7 aan kan laten staan?

Consumentenschijven kunnen prima tegen dagelijks spindown/spinup. Voor serverschijven is dit heel anders en moet je dit niet doen.

Vaak wordt er gesproken of schijven 24/7 kunnen draaien; maar eigenlijk moet je het andersom zien. Consumentenschijven kunnen zowel periodiek als 24/7 draaien, terwijl serverschijven enkel voor 24/7-gebruik geschikt zijn. Dit kun je zien in het aantal spinup-cycles wat voor serverschijven véél lager is dan voor consumentenschijven.

Is het om een andere reden onverstandig om enkel paar uurtjes per dag aan te zetten? Ik denk aan bepaalde acties die ZFSGuru bv 's nachts uitvoert, en daar in mijn geval dus nooit aan toe zal komen

Niets wat belangrijk is tenzij je een UNIX geek bent.

Is spindown mogelijk (en zo ja, eenvoudig of alleen met een hoop trucs te realiseren?) Ik verwacht dat de disks die niet downspinnen namelijk anders de grootste stroomvreter zullen zijn?

Het kan; alleen de schijven zullen bij ZFS-access sequentiëel worden opgespind. Dus dat kan een tijdje duren; 6 seconden voor iedere schijf.

Ik gebruik zelf een scriptje wat mijn pool exporteert en dan alle schijven downspint, en een spinup-script wat eerst alle schijven parallel opspint door één sector te lezen, en dan vervolgens de pool te importeren. Dat gaat dus stukken sneller vooral bij meerdere schijven.

Gewoon normale spindown is vrij makkelijk in te stellen, mits je disks 'ada' heten en dus op een normale AHCI-controller zijn aangesloten. Dan kun je in /etc/rc.conf de zfsguru spindown inschakelen en je disks opgeven. Ook kun je hier APM op 254 laten instellen wat headparking uitschakelt op WD Green en andere schijven.

Moederbord met veel onboard poortjes, dus geen HBA nodig

Het liefste heb je AHCI-poorten; sommige poorten op bordjes komen van een SAS-controller. Dan kun je bijvoorbeeld APM niet meer instellen.

Geen SSD, geloof niet dat ik dit nodig zal hebben als cache

Nadeel is wel dat je spindown niet echt meer kunt gebruiken. Je kunt wel systeemdisk op twee disks plaatsen op de eerste partitie en die dan niet spindownen, de rest van de disks wel. Voordeel van cache zou kunnen zijn lekker veel metadata cachen, maar extra RAM kan ook prima.

8x WD Green WD40EZRX, RAIDZ2 dus pakweg 24TB netto

Qua performance en space efficiency niet echt optimaal. Je kunt ook 10x WD greens in RAID-Z2 overwegen; dat is denk ik de sweet spot qua ZFS vdev configuratie, omdat je slechts 20% overhead hebt, toch tweevoudige paritybescherming en 4K optimaal / space efficient.

Qua bord kun je dit overwegen:

pricewatch: ASRock C2550D4I



Voordelen:

• 12 keer AHCI-poorten (chipset+2x marvell)
• ECC UDIMM geheugen, 32GiB of 64GiB
• Mini-ITX
• Bay trail SoC dus zuinig; je kunt voor de 4-core 2550 kiezen of de 8-core 2750. ZFS kan enorm goed overweg met meerdere cores, maar het prijsverschil is nog best fors.

Idee?

[EnerQi]

Verwijderd schreef op woensdag 06 augustus 2014 @ 08:55:

Het kan; alleen de schijven zullen bij ZFS-access sequentiëel worden opgespind. Dus dat kan een tijdje duren; 6 seconden voor iedere schijf.

Ik gebruik zelf een scriptje wat mijn pool exporteert en dan alle schijven downspint, en een spinup-script wat eerst alle schijven parallel opspint door één sector te lezen, en dan vervolgens de pool te importeren. Dat gaat dus stukken sneller vooral bij meerdere schijven.

Gewoon normale spindown is vrij makkelijk in te stellen, mits je disks 'ada' heten en dus op een normale AHCI-controller zijn aangesloten. Dan kun je in /etc/rc.conf de zfsguru spindown inschakelen en je disks opgeven. Ook kun je hier APM op 254 laten instellen wat headparking uitschakelt op WD Green en andere schijven.

Aha, daarom dat spindown bij mij irritatie opleverd. Ik moet duidelijk 6x 6 seconden wachten of zelfs 10x 6 seconden . Is er een mogelijkheid dat deze functionaliteit (paralel opspinnen) ingebouwd wordt in ZFSguru?

p.s. ik heb het asrock bordje en het werkt perfect met ZFSguru (10 schijven in RaidZ2 en 1 laptopschijfje voor ZFSguru + downloads), spindown gebruik ik overigens niet wegens de wachttijd

[Verwijderd]

Ja, ik wilde op de Pools pagina een knop maken 'put pool to sleep' en omgekeerd ook. Dan kun je handmatig redelijk gemakkelijk je pool op/down spinnen. Leukste zou zijn als er een mobiele app (iphone/android) zou komen waar je dit soort dingen nog makkelijker kunt doen.

[FireDrunk]

Persoonlijk zou ik liever zien dat de ZFS dev's dit 'fixen' door bij een eerste read van zoveel mogelijk disks te lezen. Dan gaat het vanzelf parallel. Probleem is een beetje dat ZFS confirmatie wil volgens mij van elke read. Die krijgt ZFS pas als de disk opgespint is...

Met die reden zou ik ook eerder voor minder disks in 1 pool gaan, dan heb je dat probleem niet zo. 10*6 seconden zorgt voor een Samba/Windows timeout... Dat is echt irritant. Met 4-6 schijven heb je dat probleem niet zo.

[Verwijderd]

Eens; maar spindown gebruikt niet iedereen. Persoonlijk vind ik de WD Greens zo zuinig dat je met 3,5 watt naar 0,5 watt slechts 3W per disk bespaart. 6 euro per jaar bij 24/7 gebruik per disk. Voor die prijs kun je overwegen ze lekker te laten draaien.

Anders is dat bij mijn Seagate 7200.14 disks; die doen mede dankzij de BGMS background scanning al gauw zo'n 7,5 watt idle. 15 euro per disk per jaar; dat tikt toch al snel aan. Bovendien maken ze irritant veel geluid - seekgeluidjes, kleine tikjes.

[FireDrunk]

Dat is exact wat ik doe, ik laat ze gewoon draaien... Scheelt een hoop configuratie geneuzel en aan geld scheelt het amper (ik heb 4*4TB Seagate HDD.15, die doen 4.0-5.0W idle)

[GioStyle]

Als je bijvoorbeeld FreeNAS draait vanaf een USB stick, dan moet er op je pool een 'cache' komen voor onder andere Samba. De schijven gaan dan al helemaal niet zo makkelijk meer spindown. En hier gaat de NAS uit als ie niet wordt gebruikt, want heb ook nog een Hyper-V bak met genoeg 2.5" schijfjes voor recente meuk.

[BartNL]

ik draai met 48 disks en dan is het in voorbeeld CiPHER al € 288,- per jaar. Spindown werkt met Areca probleemloos en zo heb ik in 4 jaar mijn hardware controller er uit

[FireDrunk]

Maar de Areca doet wel parallel spinup toch?

[Staatslot]

Cipher heel hartelijk dank voor je uiterst behulpzame en uitgebreide reactie!
Ik ga me er komend weekend weer in verdiepen, enige vraag voor nu: is de onboard cpu bij zo'n 2550 krachtig genoeg om gigabit vol te kunnen trekken? Er is ook wat last met leveren van de variant met de 2750 zag ik. Iemand met een van die twee ervaring qua snelheid gigabit voltrekken?

[ Voor 5% gewijzigd door Staatslot op 06-08-2014 22:47 ]

[FireDrunk]

Ligt aan het protocol en je opties. Samba met 26 concurrent users is misschien wat veel gevraagd, maar FTP/NFS met 1 of 2 sessies moet prima kunnen.

[Extera]

hmz, heb ik weer.

Gister de 3 120mm FANs van mijn RV406 chassis vervangen. (Heerlijk stil nu).
Nu start het systeem echter niet meer op. (FreeNAS).

code:

getty repeating too quickly on port /dev/ttyv0, sleeping 30 secs

google levert niet zo bijster veel op. Veel oude incidenten / bugs. Ik heb ook geen toetsenbord oid aangesloten. Ik vrees dat er iets corrupt is op de stick?

Ik heb wel een backup gemaakt vanuit Freenas. hoop maar dat ik alles netjes terug krijg, anders ben ik weer een tijdje bezig met opnieuw opbouwen

Jullie nog ideeën?

[EnerQi]

Staatslot schreef op woensdag 06 augustus 2014 @ 22:40:
Cipher heel hartelijk dank voor je uiterst behulpzame en uitgebreide reactie!
Ik ga me er komend weekend weer in verdiepen, enige vraag voor nu: is de onboard cpu bij zo'n 2550 krachtig genoeg om gigabit vol te kunnen trekken? Er is ook wat last met leveren van de variant met de 2750 zag ik. Iemand met een van die twee ervaring qua snelheid gigabit voltrekken?

Dit kan ik vanavond wel even testen maar zover ik kon zien haalde ik 70/80 MB/s (Samba, schrijven vanaf 1 schijf naar RaidZ2 (10 schijven), 1Gb verbinding).

[BartNL]

FireDrunk schreef op woensdag 06 augustus 2014 @ 14:24:Maar de Areca doet wel parallel spinup toch?

is bij opstart staggered met 0.4 seconden maar vanuit spindown weet ik niet zeker...

[FireDrunk]

Extera schreef op donderdag 07 augustus 2014 @ 09:19:
hmz, heb ik weer.

Gister de 3 120mm FANs van mijn RV406 chassis vervangen. (Heerlijk stil nu).
Nu start het systeem echter niet meer op. (FreeNAS).

code:

getty repeating too quickly on port /dev/ttyv0, sleeping 30 secs

google levert niet zo bijster veel op. Veel oude incidenten / bugs. Ik heb ook geen toetsenbord oid aangesloten. Ik vrees dat er iets corrupt is op de stick?

Ik heb wel een backup gemaakt vanuit Freenas. hoop maar dat ik alles netjes terug krijg, anders ben ik weer een tijdje bezig met opnieuw opbouwen

Jullie nog ideeën?

Ttyv0 is volgens mij de remote IPMI console (textiele console). Misschien IPMI firmware updaten?

[Verwijderd]

ttyv0 is de console; wat je op je monitor ziet. Getty voert een commando uit die deze console bestuurt, maar als die crasht wordt er direct een nieuwe instance opgestart. Als het continu crasht, dan gaat getty throttlen en probeert het elke 30 seconde het weer op te starten. Punt is dus dat het tty-commando wat in /etc/ttys staat, niet goed werkt/crasht. Dat kan inderdaad komen door corruptie. Herinstallatie is dan wel aan te bevelen; want er kan om die reden nog meer stuk zijn.

Overigens, gebruikt FreeNAS geen read-only image op USB sticks? Zo ja dan is het wel raar dat je hier last van hebt. Tenzij FreeNAS geen checksum uitvoert op die image, zoals ZFSguru wel doet. Dan weet je zeker dat er geen corruptie heeft plaatsgevonden.

[Extera]

Het gaat om een Asrock B75pro3-M, dus IPMI zit er niet op.
Ook was er geen keyboard / muis aangesloten, alleen vga, power en netwerk.

Ik geloof dat een herinstallatie wel meevalt met een backup. Ik heb al een nieuwe stick gemaakt. Vanavond even erin prikken, backup terug zetten, rebooten en dan duimen dat alle settings terug zijn.

Zit er niet op te wachten om weer nieuwe shares te maken, iSCSI in te stellen, etc.

FreeNAS mount / altijd read-only, als je wijzigingen wilt uitvoeren moet je / eerst rw mounten.
Geen idee of FreeNAS checksums uitvoert....

[franklee]

Ik heb sinds een paar weken Freenas 9 draaien op een AM1 Asrock AM1B-ITX met een 5350 met 5 WD Red schijven. 4 x 2GB als ZFS Raidz2 en 1 x 2TB non raid. De non-raid disk hangt aan een extra 2 ports sata PCI/300 express controller (nog 1 vrij voor toekomstige migratie of uitbreiding). Verder heb ik nog een losse backup van de 4 x 2 disks op een losse WD Red 4TB. Booten gebeurd mbv een usb disk.
Er zit 2 x 4GB geheugen in, er draait als plugin ook nog OwnCloud op (synchronisatie tussen Apple Mac Pro, iMac en Samsung Note 2 werkt perfect, verder worden 24uur per dag alle bewakingsbeelden van een IP cam opgenomen op de non-raid disk, waar ook nog Time Machine op draait. De performance is prima, veel sneller dan mijn 2 oude Netgear NV+ en 1 Duo. een 2de AM1 draait als webserver (Wordpress en Minecraft server, alles op 1 SSD).
Ik kan niet anders zeggen dat beide system zeer stabiel zijn. De webserver draait inmiddels ruim 30 dagen (sinds de laatste upgrade) probleemloos, geen memoryleaks zo te zien. De Freenas server is net klaar, eergisteren net de laatste non-raid disk toegevoegd, maar draaide daarvoor ook al stabiel. Performance van beide machines prima (geen benchmarkdata voorhanden maar al hogere transfersnelheden gezien dan met de Netgear). De processorload is minimaal, eigenlijk overkill, maar voor die paar euro extra wat mij betreft een no-brainer. Plexserver is ook geïnstalleerd maar wordt nog niet gebruikt, de CPU lijkt voldoende power te hebben voor realtime transcoding.
Kortom: geweldig spul, vooral de mogelijkheid om 6 disks op dit platform te kunnen gebruiken terwijl alles volledig stabiel lijkt te zijn, maakt het een aanrader..

[Verwijderd]

FreeNAS mount de USB stick direct en live? Dus geen image die naar RAM wordt uitgepakt? Ik dacht dat FreeNAS inmiddels zo ver was? Of ben ik in de war met wat anders?!

Kun je de USB stick verwijderen terwijl het systeem draait? Dat zou de ultieme test zijn.

[franklee]

Geen idee of de stick eruit kan.. Ik laat 'em lekker zitten... anders kan ik straks weer gaan scrubben :-) Ik ben net klaar met de data migratie, alles uitzoeken, herindelen, tijdelijk gedeeltelijke backups omdat ik de disken nodig had,300GB FLAC muziek converteren naar MP3 (ben geen audiofiel en de extra diskruimte vond ik belangrijker).. Het is mooi geweest. Genoeg spannende momenten gehad toen er iedere keer een disk uit de pool viel.. bleek een sata kabel te zijn die los contact maakte.. Het enige wat ik nu nog moet doen is een image maken van de usbkey. Daarna handjes af en de komende 3 jaar laten draaien :-)
Meer erg leuk.. 5 WD's red probleemloos op het AM1 platform en nog ruimte voor eentje extra..

[Verwijderd]

Je hebt helemaal gelijk natuurlijk; het is heerlijk als dingen gewoon werken en je er geen omkijken meer na hebt.

[Karp]

Ik heb op dit moment een topic lopen voor aankoopadvies van een NAS/Plex media server: NAS/Plex media server

Als er hier mensen zijn die hier feedback op kunnen geven wat betreft opslag/RAID dan zou ik dat erg prettig vinden!

[Paauwe]

Graag advies over mijn Raid setup.

De server zal gebruikt worden om:
* fileserver
* download server via couchpotato en sabnzbd
* internet server (lokaal)
* in de toekomst mss een EsXi server

Op de website van Supermicro lees ik dat mijn moederbord niet zomaar met alles compatibel is.

Wat ik nu al heb:
* Moederbord: Supermicro X10SLH-F
* Processor: Intel Xeon E3-1230 V3 Boxed
* Voeding: Seasonic SS-400L2U Active PFC

1)Nu ben ik op zoek naar een goede controller die compatibel is met Linux (Ubuntu Server) en dit moederbord.
Ik heb gekeken naar IBM ServeRAID M1015 SAS/SATA Controller,
echter kan ik geen uitsluitsel vinden op mijn vraag.

2)Ik zou een systeem willen bouwen dat draait op Ubuntu Server op XFS,
met snapraid. In raid 6 met een 8-tal HDD's.
Is dit een verstandige opstelling of toch beter ZFS?

[FireDrunk]

Je systeem is prima geschikt voor ZFS, dat is wel wat beter dan XFS, maar je moet het natuurlijk zelf weten. ZFS kent ook wat nadelen.

Mooie setup verder!

[EnerQi]

Staatslot schreef op woensdag 06 augustus 2014 @ 22:40:
Cipher heel hartelijk dank voor je uiterst behulpzame en uitgebreide reactie!
Ik ga me er komend weekend weer in verdiepen, enige vraag voor nu: is de onboard cpu bij zo'n 2550 krachtig genoeg om gigabit vol te kunnen trekken? Er is ook wat last met leveren van de variant met de 2750 zag ik. Iemand met een van die twee ervaring qua snelheid gigabit voltrekken?

De test!
C2550 Asrock: Schrijven: 89 MB/s, lezen: 117 MB/s (verbaast mij ook ). Bij het lezen is duidelijk mijn netwerkverbinding de bottleneck. OS: ZFSguru beta 9, standaard installatie.

[FireDrunk]

Enige tuning van samba toegepast?

[EnerQi]

FireDrunk schreef op donderdag 07 augustus 2014 @ 21:44:
Enige tuning van samba toegepast?

Nope. Ik heb gewoon de standaard installatie van ZFSguru doorlopen en alles op default gezet.
Ik heb getest met een stopwatch en windows 7 PC met een file van 7,203 GB.

Ik heb het over de onderstaande setup (NAS2):

#	Product	Prijs	Subtotaal
1	ASRock C2550D4I	€ 250,49	€ 250,49
1	Hitachi Travelstar 5K1000, 1TB	€ 50,51	€ 50,51
10	WD Green WD40EZRX	€ 129,25	€ 1.292,50
1	Fractal Design Define R4 Pearl Black	€ 82,93	€ 82,93
2	Silverstone SST-CP06 4x SATA	€ 8,08	€ 16,16
2	Startech.com 3.5inch Hard Drive to 5.25inch Front Bay Bracket Adapter - zwart	€ 4,71	€ 9,42
1	Kingston KVR1333D3E9SK2/16G	€ 163,35	€ 163,35
1	Seasonic G-Serie 360Watt	€ 56,-	€ 56,-
Bekijk collectie Importeer producten		Totaal	€ 1.921,36

[FireDrunk]

https://wiki.amahi.org/index.php/Make_Samba_Go_Faster

Probeer sowieso eens AIO, en Sendfile, de socket opties als laatste.

[Verwijderd]

AIO en Sendfile staan standaard al aan bij ZFSguru. Maar je moet bij AIO ook een geschikte client hebben; Windows XP bijvoorbeeld gebruikt dat niet; volgens mij Windows 7 wel maar dat weet ik niet zeker. Of ben ik in de war met multipath I/O?

Either way; Samba performance moet je niet direct op CPU bottlenecks gooien; dat is slechts zelden zo. Met een Brazos C60 (ouderwetse dualcore op 1.0GHz) kon je al 60-80MB/s halen icm ZFS op een 6-disk RAID-Z2 pool. Dus een quadcore 2GHz Kabini/Bay trail moet zeker ruim marge hebben voor een normale ZFS NAS; zaken als encryptie uitgezonderd. LZ4-compressie kun je ook rustig inschakelen; zeker omdat deze een detectie heeft voor non-compressible data en bij dergelijke data de compressie uitschakelt. Bovendien multi-core, dus vele gigabytes per seconde mogelijk.

Dus als mensen vragen is een AMD Kabini voldoende voor een normale ZFS server, dan zeg ik volmondig ja. De performance die men met Samba behaald, zal om andere redenen geen 110/110MB/s zijn. Bij mij is juist lezen langzamer, terwijl schrijven op 115MB/s gebeurt. Ik vind het allemaal prima. Zodra ik >1Gbps netwerk kan krijgen voor een redelijke prijs ga ik daar op over. Nieuwe thunderbolt met native host-to-host networking op 20 gigabit heb ik mijn pijlen op gericht. FireDrunk zei dat de CPU daar wel eens zwaar kan worden belast; maar we zullen zien in hoeverre dat een belemmering vormt. Als ik 15Gbps haal dan spring ik in de lucht; nu betaal je zwaaaaar voor 10 gigabit NICs - in elk geval die 10GBaseT-krengen.

[FireDrunk]

Haal je SMB Multichannel en Linux' libaio niet door elkaar? Ik dacht dat aio er alleen maar voor zorgde dat Samba libaio ging gebruiken voor asynchrone disk access?

Voor sendfile heb je inderdaad een nieuwere client nodig.

[ Voor 15% gewijzigd door FireDrunk op 08-08-2014 14:16 ]

[Berkeley]

Weet niet of dit hier mag, of dat ik een ander topic moet openen maar bij deze:

Ik heb een tijd geleden een server gekocht op tweakers( V&A aangeboden: 1U server Intel E2160, 4Gb RAM, 80Gb harddisk ) nu kent iedereen het geluid wel van een 1U server die aangaat, maar meestal wordt dat geluid(althans bij deze specifieke server) wat minder. Sinds kort(aka 1 - 2 uur) is dit niet meer zo, en komt er een raar geluid uit de voeding, net of er zo'n kleine fan heel hard aan het draaien is.. Als ik de server op een monitor aansluit via vga, gaat de monitor in 'sleep mode' de monitor en kabel werken nog, dit heb ik al getest op een andere pc. Bij het indrukken van de reset knop flikkert het oranje 'berichten' lampje(er staat een soort postbrief icoontje boven het lampje afgebeeld) als ik de server uit wil zetten via de aan/uit button werkt dit niet of duurt het heel lang. Heb het getest met schijven aangesloten en zonder iets aangesloten, maakt geen verschil.
Iemand enig idee?

[MTDjassen]

Vraagje... Heb nu mijn set-up binnengekregen, vanwege levertijden uiteindelijk gekozen voor een Antec kast, namelijk deze pricewatch: Antec VSK-3000E. Omdat deze natuurlijk een standaard voeding ondersteund (en mijn mobo een onboard voeding heeft) mijn vraag of er plaatjes zijn om dit (vrij grote) voedingsgat in m'n case netjes af te sluiten? Anders gaat het wel stof happen voor het leven, denk ik. Iemand?

[Berkeley]

Kan dat misschien met van die rubberen strips? zoiets alleen dan in het klein? Of is het echt een gat dat er zit?

[MTDjassen]

Nee echt het gat waar normaliter de voeding zit zeg maar, dus wel een goeie 10x7cm ofzo.

[Berkeley]

Misschien dat je een soort van rubberen lap kan krijgen, die je er overheen plakt en dan de juiste gaten er uit snijdt/knipt voor je voeding/bedrading?

[Nielson]

Ze bestaan wel, maar zelf een plaatje (laten) maken of een oude bestaande voeding aanpassen is ws handiger.

http://ecosmartpc.com/blanks.html

[ Voor 37% gewijzigd door Nielson op 10-08-2014 17:16 ]

[Ample Energy]

Hoe zoeken jullie op moederborden met ondersteuning voor ECC-geheugen?
Als ik op "ECC" zoek, vind ik er maar 16 in de PW.

Ik ben namelijk wel geïnteresseerd in ECC, maar nu wacht ik eigenlijk steeds tot iemand hier een bord post, zodat ik die kan bekijken. Het zou wel makkelijk zijn om een overzicht van leverbare moederborden te hebben, zeker omdat de prijzen en het aantal SATA-poorten nogal uiteenlopen.

[Berkeley]

Siempie schreef op maandag 11 augustus 2014 @ 12:28:
Hoe zoeken jullie op moederborden met ondersteuning voor ECC-geheugen?
Als ik op "ECC" zoek, vind ik er maar 16 in de PW.

Ik ben namelijk wel geïnteresseerd in ECC, maar nu wacht ik eigenlijk steeds tot iemand hier een bord post, zodat ik die kan bekijken. Het zou wel makkelijk zijn om een overzicht van leverbare moederborden te hebben, zeker omdat de prijzen en het aantal SATA-poorten nogal uiteenlopen.

Bij server borden is het vaak alleen even kijken op de website van het merk. Ik heb gister deze besteld: pricewatch: Supermicro X9SCM-F

[Verwijderd]

Pas nog gepost:
pricewatch: ASRock C2550D4I

Zie ook mijn post:
Verwijderd in "Het grote DIY RAID NAS topic deel 3"

Ondersteunt tot 64GiB ECC UDIMM.

Let wel op: ECC heb je in Registered en Unregistered/Unbuffered (=UDIMM). Je wilt vaak ECC UDIMM, dat is normaal geheugen maar wel ECC. Kies ook voor modern 1,35v geheugen als het kan.

[BartNL]

Siempie schreef op maandag 11 augustus 2014 @ 12:28:
Hoe zoeken jullie op moederborden met ondersteuning voor ECC-geheugen?
Als ik op "ECC" zoek, vind ik er maar 16 in de PW.

Kijk welke chipset op de gevonden moederborden zit en zoek daar dan op. Qua Intel zullen het vooral de c2xx (s1150/s1155)en c6xx (s2011) chipset zijn.

[Ample Energy]

RobHaz schreef op maandag 11 augustus 2014 @ 12:41:
[...]

Bij server borden is het vaak alleen even kijken op de website van het merk. Ik heb gister deze besteld: pricewatch: Supermicro X9SCM-F

Is ook een manier
Het kan wel, maar helaas moet je nog handmatig de meeste borden wegfilteren. Maar in principe is alles dat langs een designteam is gegaan geen serverbord en heeft geen ECC, dus het filteren kan wel.

Verwijderd schreef op maandag 11 augustus 2014 @ 12:53:
Pas nog gepost:
pricewatch: ASRock C2550D4I

Zie ook mijn post:
Verwijderd in "Het grote DIY RAID NAS topic deel 3"

Ondersteunt tot 64GiB ECC UDIMM.

Let wel op: ECC heb je in Registered en Unregistered/Unbuffered (=UDIMM). Je wilt vaak ECC UDIMM, dat is normaal geheugen maar wel ECC. Kies ook voor modern 1,35v geheugen als het kan.

Thanks. Zulke posts wachtte ik altijd af, maar zelf zoeken kostte zo veel moeite. Ik vind dat bord wel erg interessant, maar heb nog nooit iets gekocht met een onboard CPU en wil dus nog research doen. Het stroomverbruik spreekt me wel aan, maar dat ECC kost toch net zo veel als een offsite back up en ik heb ECC nooit nodig gehad.

BartNL schreef op maandag 11 augustus 2014 @ 14:16:
[...]

Kijk welke chipset op de gevonden moederborden zit en zoek daar dan op. Qua Intel zullen het vooral de c2xx (s1150/s1155)en c6xx (s2011) chipset zijn.

De manier die ik zocht, bedankt! Niet heel veel aanbod met 8 of meer SATA-aansluitingen, maar op zich vallen de kosten mee, want ik heb dan geen RAID-controller nodig.

[Berkeley]

Voor te weinig sata poorten kan je gewoon een pcie kaartje kopen. Veel goedkoper waarschijnlijk.

[FireDrunk]

Hangt er vanaf hoeveel poortjes je wil... 2 poortjes, ja, 4 poortjes, kiele-kiele, 8 poortjes, no way.

(Ik, en met mij velen, zien nog steeds een gat in de markt, voor een 16 poorts true AHCI controllertje op PCIe x8 ofzo)

[ Voor 37% gewijzigd door FireDrunk op 11-08-2014 18:57 ]

[TrsvK]

Ik heb vandaag een nieuwe z2 pool aangemaakt met 4x4TB wd greens. Tot mijn verbazing resulteerde dit slechts tot een bruikbare ruimte van 6.9TB. Ik wist dat ik niet de volledige 8TB beschikbaar zou hebben maar dit lijkt me wel erg veel overhead. Kan iemand mij vertellen of dit normaal is of heb ik gewoon pech en een "kleine" schijf in de pool gestopt?

[u_nix_we_all]

TrsvK schreef op donderdag 14 augustus 2014 @ 11:31:
Ik heb vandaag een nieuwe z2 pool aangemaakt met 4x4TB wd greens. Tot mijn verbazing resulteerde dit slechts tot een bruikbare ruimte van 6.9TB. Ik wist dat ik niet de volledige 8TB beschikbaar zou hebben maar dit lijkt me wel erg veel overhead. Kan iemand mij vertellen of dit normaal is of heb ik gewoon pech en een "kleine" schijf in de pool gestopt?

6.9 TB of 6.9 TiB ? (het verschil tussen een TB en TiB is al zo'n 10% , de rest zal wat overhead zijn idd)

[FireDrunk]

Ik heb hier 10.4 beschikbaar ofzo bij 4*4 RAIDZ1 dat komt uit op ~3.4TiB per 4TB schijf.

Komt wel aardig overeen lijkt mij.

[Verwijderd]

@TrsvK: lees dit artikel eens door: Wikipedia: Binary prefix

[servela]

TrsvK schreef op donderdag 14 augustus 2014 @ 11:31:
Ik heb vandaag een nieuwe z2 pool aangemaakt met 4x4TB wd greens. Tot mijn verbazing resulteerde dit slechts tot een bruikbare ruimte van 6.9TB. Ik wist dat ik niet de volledige 8TB beschikbaar zou hebben maar dit lijkt me wel erg veel overhead. Kan iemand mij vertellen of dit normaal is of heb ik gewoon pech en een "kleine" schijf in de pool gestopt?

Als ik het bereken via een online calculator zou dat ongeveer het volgende moeten zijn:
*Raw Storage: 16.0 TB / 16000.0 GB
*Usable Storage: 7.3 TB / 7450.6 GB
Met elke extra schijf in uw z2 pool verkleint uw overhead

[Verwijderd]

Dat is niet correct; de ruwe opslag is 16TB en de bruikbare opslag 8TB. Als je de 1024-IEC-standaard gebruikt in plaats van de 1000-SI-standaard, spreek je over TiB, niet over TB.

Ruw: 16TB = 14,55 TiB
Exclusief redundancy: 8TB = 7,27TiB
Netto bruikbaar (excl. filesystem overhead): ~7TiB.

[FireDrunk]

Precies, en daar komt izjn 6,9TiB dus ook vandaan.. De rest zal alvast een reservering zijn van ZFS Metadata.

[ Voor 4% gewijzigd door FireDrunk op 14-08-2014 12:44 ]

[Joenuh]

Hallo mensen,

ik heb een waarschijnlijk knullige vraag. Na een tijd geleden Sabnzbd geinstalleerd te hebben op m'n Freenas 8 systeem wilde ik deze eens gaan instellen. Bij het instellen van mijn downloadfolders kwam ik een probleem tegen. Deze kunnen namelijk volgens mij alleen binnen de Jail directory gekozen worden? Nu las ik dat ik dan gebruik zou moeten maken van mount points, Wat dit zijn is me half duidelijk, misschien kan iemand me dat verduidelijken?

Het echte probleem zit hem in het volgende. Ik wil dus naar de web interface van mijn Freenas 8. Maar als ik daar inlog krijg ik niet het volledige menu te zien en ik kan er niks beginnen. Ik heb mijn Nas al meerdere keren gereboot maar dit mocht niet helpen. Ook verschillende browsers maken geen verschil(Chrome, Mozilla Firefox en Internet Explorer.. tja, je moet wat als je wanhopig bent). Heeft iemand een idee hoe dit probleem verholpen kan worden? Het ziet er als volgt uit:



Bij voorbaat dank,

Joenuh

[Daiov97]

Wat is beter, een static ip toewijzen aan een NAS via de router of via de NAS zelf? Of maakt dit niet uit?

[GioStyle]

Daimen schreef op donderdag 14 augustus 2014 @ 17:00:
Wat is beter, een static ip toewijzen aan een NAS via de router of via de NAS zelf? Of maakt dit niet uit?

Netter: static ip via de nas instellen. Beter? Mwah...

[FireDrunk]

Ik zou alle devices die ook maar iets van een service leveren voor andere systemen een statisch IP geven.
Dus: Printer, Server, NAS, WiFi AP etc.

[u_nix_we_all]

Hoe doe je dat eigenlijk, een statisch IP door de router toe laten wijzen ?
M.a.w. statisch ip adres configureren doe je altijd op het apparaat zelf.

Ja, je kunt een heel lange lease op je DHCP zetten zodat het ip niet veranderd, maar dat blijft DHCP

[GioStyle]

IP adres koppelen aan een MAC adres?

[ Voor 12% gewijzigd door GioStyle op 14-08-2014 17:35 ]

[Verwijderd]

DHCP kan inderdaad gewoon aan de hand van het MAC-adres elke keer hetzelfde DHCP-adres uitdelen. Een goede DHCP-router doet dit ook, en kun je ook zelf instellen welk IP de computer moet hebben.

Zelf gebruik ik een eigen DHCP server op mijn BSD server, en daar heb ik een DHCP-range voor onbekende clients tussen 200 en 250, en daaronder heb ik bekende clients een vast IP gegeven. Maar dat wordt dus wel door de DHCP-server gegeven; dus als ik op de client Linux opnieuw installeer, krijg ik ook automatisch weer hetzelfde IP. Lekker handig.

[u_nix_we_all]

Tja, het is misschien een beetje bitneuken op semantisch vlak, maar in mijn beleving is DHCP de tegenhanger van statisch. (D staat ook voor dynamic). Zodra je het DHCP protocol gebruikt, en het niet met de hand op het device zelf configureert, is het voor mij geen statisch ip-adres meer

[Verwijderd]

DHCP configureer je dus niet op de device zelf; maar op de server. Dynamic dekt tegenwoordig niet meer de lading. Ik zou het eerder 'Automatic Network Configuration' (ANC) noemen. Gelijk een mooie verwijzing naar Mandela.

[FireDrunk]

IPv6 heeft een ingebakken DHCP systeempje (waarbij clients onderling een IP range afspreken).

Het is iets intelligenter dan APIPA (de oude 169.x.x.x manier).

[u_nix_we_all]

Verwijderd schreef op donderdag 14 augustus 2014 @ 17:52:
DHCP configureer je dus niet op de device zelf; maar op de server. Dynamic dekt tegenwoordig niet meer de lading. Ik zou het eerder 'Automatic Network Configuration' (ANC) noemen. Gelijk een mooie verwijzing naar Mandela.

Volgens mij moeten we eigenlijk niet over statische of dynamische adressen praten, maar over een statische of dynamische configuratie. Want de NAS is wel dynamisch geconfigureerd als hij op DHCP staat (als in: verplaats hem naar een ander netwerk met andere DHCP-server en hij krijgt een ander nummer).

[Verwijderd]

Goed punt!

[TrsvK]

Bedankt voor de snelle replies. Ik heb nu toch maar twee extra schijven bijbesteld. Ze worden morgen bezorgd dus zal dan opnieuw een poging wagen.

Ik heb trouwens ook nog een klein goedkoop SSDtje liggen pricewatch: Transcend TS64GSSD340 64GB
Zou het toevoegen van deze SSD als L2ARC aan de pool helpen om deze responsiever te maken voor de meest gebruikte bestanden of is dat een nutteloze onderneming en kan ik hem beter gebruiken als schijf om mijn jails op te draaien?

[soulrider]

u_nix_we_all schreef op donderdag 14 augustus 2014 @ 18:32:
[...]

Volgens mij moeten we eigenlijk niet over statische of dynamische adressen praten, maar over een statische of dynamische configuratie. Want de NAS is wel dynamisch geconfigureerd als hij op DHCP staat (als in: verplaats hem naar een ander netwerk met andere DHCP-server en hij krijgt een ander nummer).

een netwerk met een DHCP-server waarop alles via gereserveerde ip-adressen gaat is als geheel een statische configuratie met een dynamisch iets als kern ;-)

Maar de vraag

Wat is beter, een static ip toewijzen aan een NAS via de router of via de NAS zelf? Of maakt dit niet uit?

moet eigenlijk

Wat is beter, een gereserveerd ip toewijzen aan een NAS via de router of een static ip instellen via de NAS zelf? Of maakt dit niet uit?

en dan is de 1ste vraag: verwacht je dat je je nas vaak/regelmatig gaat verhuizen van netwerk (bv naar vrienden/familie/lan-party) ? neen: dan is het naar eigen voorkeur en kunnen.
anders draagt "DHCP met een gereserveerd ip-adres dat je router/dhcp-server uitgeeft" de voorkeur.

[TrsvK]

Heren,

tijdens het kopieren van mijn data uit de oude pool naar de nieuwe blijft 1 schijf steeds detachen na een paar minuten. Ik hoopte dat het een voedingsprobleem was maar heb de schijn nu op een andere voeding gezet en het probleem blijft aanwezig. Als de schijf is gedetached crashed FreeNas en kan ik ook de andere pool niet meer benaderen. Wel kan ik nog in de webgui en op reboot klikken maar deze wordt dan niet volledig uitgevoerd en een harde reset is nodig op alles weer in orde te krijgen. Nadat de nas weer is opgestart is de schijf weer geattached en kan ik weer een paar minuten kopieren.

Denken jullie dat dit gewoon een kapotte schijf is of is er iets wat ik kan doen?

[FireDrunk]

Wat zijn je specs?

[TrsvK]

Ik heb heb de onderstaande onderdelen gebruikt maar momenteel heb ik ook mijn oude pool (stripe 2*1 TB +1*1.5TB) aangesloten en gebruik ik mijn 650W Corsair TX voeding omdat de seasonic niet genoeg uitgangen biedt om alle schijven aan te kunnen sluiten. De 1.5TB (Seagate) schijf vliegt er steeds uit. Daarom heb ik deze samen met 2 andere schijven los op de Seasonic aangesloten.

verder draai ik momenteel de laatste versie van FreeNas (9.2.1.7) en de nieuwe pool staat in raid Z2 met de ssd als L2ARC

#	Product
1	ASRock C2550D4I
6	WD Green WD40EZRX
1	BitFenix Phenom Mini-ITX Wit
1	Kingston DataTraveler Micro USB 2.0 8GB Zwart
1	BitFenix Spectre All White, 230mm
1	Crucial CT2KIT102472BD1339
1	Seasonic G-Serie 360Watt
1	APC Back-UPS ES 550VA 230V
1	Transcend TS64GSSD340 64GB

[FireDrunk]

Wat je kan doen, is je OS even loskoppelen (USB stickje gok ik), en even een Linux Boot CD erbij pakken, en even rustig van alle schijven Smart waardes opvragen...

[TrsvK]

De smart test op de betreffende schijf geeft:

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA
_of_first_error
# 1 Extended offline Completed without error 00% 10816 -
# 2 Extended offline Completed without error 00% 10073 -
# 3 Extended offline Completed without error 00% 8876 -
# 4 Extended offline Completed without error 00% 8167 -
# 5 Short offline Completed without error 00% 8122 -
# 6 Short offline Completed without error 00% 8116 -
# 7 Short offline Completed without error 00% 8104 -
# 8 Short offline Completed without error 00% 8092 -
# 9 Short offline Completed without error 00% 8080 -
#10 Short offline Completed without error 00% 8068 -
#11 Short offline Completed without error 00% 8056 -
#12 Short offline Completed without error 00% 8044 -
#13 Short offline Completed without error 00% 8032 -

[FireDrunk]

Mja, SMART tests zijn niet echt betrouwbaar, die geven OK's binnen de marges van de fabrikant...
Post liever even de echte stats

[TrsvK]

Welke stats bedoel je?

[ Voor 8% gewijzigd door TrsvK op 16-08-2014 10:18 ]

[FireDrunk]

smartctl -a

[BartNL]

TrsvK schreef op zaterdag 16 augustus 2014 @ 08:04:
Denken jullie dat dit gewoon een kapotte schijf is of is er iets wat ik kan doen?

de sata kabel checken / vervangen of wanneer niets meer werkt en het nodig is (de data anders verkoren is) de schijf klonen en met de kloon werken?

[ Voor 20% gewijzigd door BartNL op 16-08-2014 10:50 ]

[Verwijderd]

SMART-waarden graag in het Check je SMART topic en niet met 'smartctl -a' doen maar met 'smartctl -A' dus hoofdletter A, dan krijg je niet alle onnodige meuk maar alleen de relevante SMART-gegevens.

[FireDrunk]

Goed punt!

[TrsvK]

Wellicht een stomme vraag maar wat klopt hier niet aan?

smartctl -A -d ata ada7 (als ik -d ata weglaat geeft hij namelijk aan dat hij niet weet wat t apparaat type is)

[Verwijderd]

Je bent /dev/ vergeten voor ada7

smartctl -A /dev/ada7

Dan kan hij nog klagen dat SMART niet is ingeschakeld:

smartctl -A -s on /dev/ada7

[TrsvK]

Graag in het Check je SMART-topic, zoals ik hierboven had aangegeven.

[ Voor 97% gewijzigd door Verwijderd op 16-08-2014 11:55 ]

[TrsvK]

TrsvK schreef op zaterdag 16 augustus 2014 @ 11:53:
[mbr]Graag in het Check je SMART-topic, zoals ik hierboven had aangegeven. ;)[/]

Sorry daar had ik overheen gekeken. Ik heb inmiddels een post in het SMART topic gemaakt.

[TrsvK]

Weten jullie of het mogelijk is om bestanden te kopieren via het cp commando en aan te geven dat alleen bestaande bestanden die dezelfde naam hebben als het bronbestand maar kleiner zijn moeten worden vervangen?

[ Voor 12% gewijzigd door TrsvK op 17-08-2014 06:04 ]

[FireDrunk]

Dat kan met rsync

[TrsvK]

Bedankt, maar dus niet via cp in de shell?

Ik heb inmiddels na ruim 40 reboots al mijn niet gebackupte bestanden kunnen overzetten naar de nieuwe pool. (echt verschrikkelijk frustrerend werk)

De nas loopt nu goed en ik merk dat hij met de nieuwe schijven een stuk responsiever is. Erg prettig.

Wel heb ik opgemerkt dat de schijven periodiek blijven schrijven waardoor de niet in standby of spindown gaan. https://www.dropbox.com/s/5nomgukwwprg51z/Knipsel.PNG, Is dit normaal als je maar 1 pool hebt die daarom ook de systeempool is of kan ik hier iets aan doen? (Omdat het om kleine hoeveelheden data gaat is het wellicht een log dat wordt bijgehouden (ik heb de syslog al uitgezet) Aan het netwerkverkeer te zien lijkt het wel of hij met de router communiceerd oid) Gelukkig is het geheel vrij zuinig dus als de spindown niet gaat werken is dat geen grote ramp. (53W idle aan de UPS)

Ook ben ik benieuwd wat de da0 schijf is die onderaan het overzichtje (afbeelding) te zien is. Is dit de usbstick waarop freenas staat?

Nogmaals bedankt voor jullie hulp!

[ Voor 18% gewijzigd door TrsvK op 18-08-2014 07:56 ]

[analog_]

Iemand een opinie over de MegaRAID SAS 84016E, het is een wat oudere kaart maar de enige die in 16 poorts smaak goedkoop te vinden is. Ik heb 16 poorten nodig of ik moet afwijken naar een 1xPCIe 2 of 4 sata poorts oplossing in combo met m1015 en onboard (6x intel, 2 asmedia crap). Er komen archief disks aan te hangen (max 2TB) dus dat zou wel moeten loslopen lijkt me. Er zit wel een Intel xscale nog in, bandbreedte?

Nvm, blijkt geen successaus te zijn.

[ Voor 12% gewijzigd door analog_ op 18-08-2014 00:11 ]

[FireDrunk]

Wat voor OS / Filessytem zou je er op willen draaien? Als je geen (hardware) RAID wil, zou ik voor deze gaan: pricewatch: LSI SAS 9201-16i

[ Voor 59% gewijzigd door FireDrunk op 18-08-2014 08:01 ]

[MvL]

FireDrunk schreef op maandag 18 augustus 2014 @ 07:59:
Wat voor OS / Filessytem zou je er op willen draaien? Als je geen (hardware) RAID wil, zou ik voor deze gaan: pricewatch: LSI SAS 9201-16i

Die heb ik ook een paar dagen geleden gekocht. Ik heb de kaart nog niet binnen. Ik weet alleen nog niet welke distro / filsystem /oplossing ik ga gebruiken. Ik ben op het moment een beetje aan het klungelen met BTRFS in een virtuele machine. Ook heb ik snapRAID uitgeprobeerd.

[analog_]

FireDrunk schreef op maandag 18 augustus 2014 @ 07:59:
Wat voor OS / Filessytem zou je er op willen draaien? Als je geen (hardware) RAID wil, zou ik voor deze gaan: pricewatch: LSI SAS 9201-16i

Dat was ook mijn goto kaart echter is de prijs meer dan lineair, daarom ben ik wat verder gaan zoeken. ZFS uiteraard met OI of een linux. Is er nog een generatie ouder compromis oplossing? Heel eventueel zelfs open voor non 64b lba als het echt goedkoop/degelijk kan.

Er is doorgewerkt aan een OpenSM poort (door een fransman, op v-front.de zoeken) voor ESXi 5.5 waardoor ik binnenkort ZoUbuntu kan ditchen en terugstappen naar OI of NexentaStor en de virtualisatie stack kan updaten van 5.1. Kunnen we weer wat scst benchmarks gaan posten, nu we toch bezig zijn ... ik wil mijn SSD volumes updaten/graden. Ik zit nu nog op een viertal Crucial M4s 128g voor virtualisatie storage. Ik zou graag naar ongeveer het dubbele gaan. Het hangt op een UPS dus caps zijn optioneel. Ik zat zelf te denken aan een kwartet crucial m500s van 240g.

edit: ik weet ongeveer hoe je denkt over expanders, ik wil de discussie niet ophevelen maar dit zag er nog wel aardig uit.

[ Voor 28% gewijzigd door analog_ op 20-08-2014 20:26 ]