Het grote ZFS topic

[Verwijderd]

Stel je download filesystem is:
tank/zfsguru/download

Dan kun je tmpfs mounten met het commando:
mount -t tmpfs tmpfs /tank/zfsguru/download

Voor overige lezers: tank dus vervangen door de naam van je pool.

[Tsurany]

Ik heb nu al mijn schijven vervangen voor een enkele pool van 4x3TB en wil nu gelijk standby van de schijven werkend krijgen.
Momenteel heb ik de HDD Standby tijd op 30 minuten gezet en APM op 127. Echter waar ik mee zit is dat de schijven ook gemount zijn op mijn Ubuntu systeem. Kunnen de hardeschijven in standby gaan ondanks dat ze als CIFS share gemount zijn op een ander systeem?
En kan ik ergens terug vinden of ze in standby gegaan zijn? Hoe kan ik controleren of het werkt?

[Gralgrathor]

Tsurany schreef op woensdag 22 januari 2014 @ 08:19:
Ik heb nu al mijn schijven vervangen voor een enkele pool van 4x3TB en wil nu gelijk standby van de schijven werkend krijgen.
Momenteel heb ik de HDD Standby tijd op 30 minuten gezet en APM op 127. Echter waar ik mee zit is dat de schijven ook gemount zijn op mijn Ubuntu systeem. Kunnen de hardeschijven in standby gaan ondanks dat ze als CIFS share gemount zijn op een ander systeem?
En kan ik ergens terug vinden of ze in standby gegaan zijn? Hoe kan ik controleren of het werkt?

Ik lees het een en ander over de wenselijkheid van het down-spinnen van schijven in een array. Je RAID-controller/ZFS-ware kan verkeerde conclusies trekken als het net even te lang duurt om een schijf weer te laten draaien. Daarbij is het mij nog niet gelukt om schijven met hdparms te laten down-spinnen als ze middels een smbd zijn geshared, of er nu andere machines die shares hadden gemount of niet.

Een veiliger/zekerder optie is misschien het standby zetten van de hele machine, in combinatie met WoL.

Maar ik ben benieuwd wat de experts erover te melden hebben; ik zou ook graag een spindown zien als het veilig kan...

[Goderic]

Iemand een idee wat er hier aan de hand kan zijn?

code:

1 root@Frank /home/goderic # zfs list                                                                                                                                                        :(
NAME                   USED  AVAIL  REFER  MOUNTPOINT
zroot                 57.1G   140G  40.6M  /
zroot/data            19.7G   140G  19.6G  /home/goderic/data
zroot/data/documents  67.8M   140G  67.7M  /mnt
zroot/home            15.5G   140G  5.22G  legacy
zroot/tmp             31.1M  4.97G  1.61M  /tmp
zroot/usr             4.43G   140G  3.09G  legacy
zroot/var             17.0G   140G  1.79G  legacy
zroot/var/log          279M   221M  28.2M  legacy
root@Frank /home/goderic # zfs umount zroot/data
umount: /home/goderic/data: not mounted
cannot unmount '/home/goderic/data': umount failed
1 root@Frank /home/goderic # zfs mount zroot/data                                                                                                                                            :(
cannot mount 'zroot/data': filesystem already mounted
1 root@Frank /home/goderic # zfs set mountpoint=/mnt2 zroot/data                                                                                                                             :(
umount: /home/goderic/data: not mounted
cannot unmount '/home/goderic/data': umount failed
1 root@Frank /home/goderic #

umounten gaat niet want het is niet gemount, mounten gaat ook niet want hij is al gemount? Mountpoint veranderen gaat ook niet.

De rest van de datasets doen wel normaal. Ik gebruik ZFS on Linux.

[]Byte[]

umount: /home/goderic/data: not mounted
cannot unmount '/home/goderic/data': [b]umount failed[/b]

Staat er niets in je /var/log/messages ?
(anders reboot eens proberen....)

Euhh... ben je niet een '/' vergeten?

zfs umount [b]/[/b]zroot/data

[ Voor 18% gewijzigd door ]Byte[ op 22-01-2014 14:26 ]

[Tsurany]

Gralgrathor schreef op woensdag 22 januari 2014 @ 14:05:
Ik lees het een en ander over de wenselijkheid van het down-spinnen van schijven in een array. Je RAID-controller/ZFS-ware kan verkeerde conclusies trekken als het net even te lang duurt om een schijf weer te laten draaien. Daarbij is het mij nog niet gelukt om schijven met hdparms te laten down-spinnen als ze middels een smbd zijn geshared, of er nu andere machines die shares hadden gemount of niet.

Een veiliger/zekerder optie is misschien het standby zetten van de hele machine, in combinatie met WoL.

Maar ik ben benieuwd wat de experts erover te melden hebben; ik zou ook graag een spindown zien als het veilig kan...

Ik denk dat het geen issue mag zijn dat de schijf weer moet upspinnen, in ieder geval niet in kleine arrays met moderne schijven. Als het sharen problemen gaat geven is dat wel jammer, dan moet ik daar wellicht iets op verzinnen.

Standby zetten van de hele machine is geen optie voor mij, ik wil continu bij de data kunnen. Alleen door de schijven in standby te zetten kan ik toch een redelijke stroombesparing behalen.

[matty___]

Goderic schreef op woensdag 22 januari 2014 @ 14:17:


De rest van de datasets doen wel normaal. Ik gebruik ZFS on Linux.

Ja, daar ga je al

zou het daaraan liggen dat zroot/data/documents een niveau lager is dan zroot/data?
dus eerst zroot/data/documents unmounten en dan pas zroot/data?

[Goderic]

]Byte\[ schreef op woensdag 22 januari 2014 @ 14:24:

umount: /home/goderic/data: not mounted
cannot unmount '/home/goderic/data': [b]umount failed[/b]

Staat er niets in je /var/log/messages ?
(anders reboot eens proberen....)

Euhh... ben je niet een '/' vergeten?

zfs umount [b]/[/b]zroot/data

Niets te zien in journalctl en reboot helpt niet. '/ ' moet er niet voor (al kost het wel erg veel tijd om dat af te leren ).

matty___ schreef op woensdag 22 januari 2014 @ 14:32:
[...]

Ja, daar ga je al

zou het daaraan liggen dat zroot/data/documents een niveau lager is dan zroot/data?
dus eerst zroot/data/documents unmounten en dan pas zroot/data?

Nee, dat had ik als eerste geprobeerd.

[sphere]

http://forums.freenas.org...on-ecc-ram-and-zfs.15449/

Example 2: Server with ZFS and non-ECC RAM. Now you have more ways to lose your data:

1. If the drive completely dies(obviously).
2. Based on prior users that have had non-ECC RAM fail you'll reboot to find your pool unmountable. This means your data is gone. There is no data recovery tools out there for ZFS. NONE. It's ALL gone for good.
3. What about the fact that you used those non-server grade parts? Guess what, they can also trash your pool and make it unmountable. The outcome is exactly the same as #2. You just lost all of your data because the pool won't mount.

Als dit zo'n probleem is, waarom zou je dan het risico lopen, zelfs met ECC. Double bit fouten komen ook voor.

[Verwijderd]

Die tekst is geschreven door de agressieve en vaak incorrecte cyberjock, als ik zijn naam goed heb onthouden. Veel van wat hij zegt is agressief verwoord en weinig genuanceerd. Zo ook de uitleg over ECC en ZFS.

Wat niet wordt verteld is dat duizenden bitflips in RAM zoals bij een defect geheugenreepje in de praktijk voor checksum errors zorgt, en dat na het draaien van memtest en vervangen van het defecte reepje je pool weer prima in orde is.

Het gevaar is dat als je ZFS blijft gebruiken wanneer je ernstige geheugencorruptie hebt, dat bijvoorbeeld de checksum verkeerd wordt aangemaakt. De data is dan goed, maar ZFS denkt dan dat deze corrupt is omdat het niet overeenkomt met de checksum. Dit bestand ben je dan kwijt.

Het punt is: als je veel checksum fouten krijgt is dat voor velen een reden om aan de bel te trekken. Vooral nieuwe servers waarbij MemTest86+ is overgeslagen, kunnen foute RAM reepjes hebben.

Het is dus zeker niet zo dat ZFS gelijk op zijn bek gaat van RAM fouten. In elk geval heeft ZFS meer bescherming tegen RAM bitflips dan alle andere filesystems. Daar staat tegenover dat ZFS een groter geheugenbereik voor write-back gebruikt.

Dat consumentenhardware ook voor kapotte pools kan zorgen is natuurlijk onzin. Ook een goedkoop systeem wat correct functioneert, werkt in essentie hetzelfde als een peperduur serversysteem.

Wat mij betreft luisteren jullie iets minder naar die rottweiler die niet kan stoppen met blaffen. Er valt in elk geval genoeg aan te nuanceren.

[FireDrunk]

Helemaal mee eens

[Q]

Helemaal mee oneens, maar ik ben conform Cyberjock ook van nature meer een blaffende rotweiler.

Er is geen discussie over mogelijk dat het gebruik van non-ecc geheugen voor een server systeem gewoon een duidelijk risico met zich mee brengt.

Geen enkel server merkt stopt non-ecc geheugen in zijn apparatuur. ZFS is ook ontwikkeld binnen een enterprise omgeving bedoeld voor server-grade hardware. Daar is een reden voor.

Naar mijn weten heeft ZFS nul bescherming tegen bitflips. Er is naar mijn weten helemaal niets wat tegen brak geheugen kan. Niet alleen je data, maar ook je file system zelf gaat naar de kloten.

Heel schattig dat mensen ZFS draaien op consumenten spul, maar ga niet verbaast doen als de boel opeens stuk is. Ik heb zelf destijds ook gegokt met consumenten hardware voor mijn 18TB server en tot nu toe ben ik er mee weg gekomen, maar ik zou dat nooit meer doen.

Als je echt om je data geeft dan gebruik je ZFS met ECC geheugen, anders doe je het maar half goed en ben je lang niet zo veilig af als je zou verwachten/willen.

Wat non-ecc geheugen betreft is ZFS niet veiliger dan andere file systems, behalve dan dat je het mogelijk eerder opmerkt vanwege de checksum errors, maar eigenlijk ben je dan al te laat en is je data niet meer te vertrouwen. Je weet alleen wat eerder dat je de klos bent.

[ Voor 18% gewijzigd door Q op 22-01-2014 15:10 ]

[sphere]

Wat ik ernstiger vind is dat hij claimt dat een ext3/ext4 filesystem minder risico loopt op consumentenhardware dan een zfs filesystem. Maar als je dat doortrekt is ZFS draaien sowieso een onacceptabel risico, want zodra je pool corrupt raakt kan je alles wegpleuren.

Ik hoop dat dat onwaar is.

[Verwijderd]

@sphere: dat is kul. Een ext4 systeem hoor je niet piepen terwijl je continu corruptie krijgt, die ext4 ook niet kan corrigeren. ZFS zit dan wel continu corruptie te corrigeren en dat zou moeten opvallen als je duizenden checksum fouten ziet. Simpelweg weten dat er iets aan de hand is, is sowieso al enorm veel waard. De detectie vind ik eigenlijk nog belangrijker dan de correctie.

@Q: je moet wel weten dat ZFS expliciet is ontwikkeld voor 'dat consumentenspul'. Jeff Bonnwick:

The original promise of RAID (Redundant Arrays of Inexpensive Disks) was that it would provide fast, reliable storage using cheap disks. The key point was cheap; yet somehow we ended up here. Why?

Naar mijn weten heeft ZFS nul bescherming tegen bitflips.

Zolang ZFS redundantie heeft, en dat heeft het al op een enkele schijf zonder RAID dankzij ditto blocks, heb je ook (beperkte) bescherming tegen RAM bitflips. Dat heb ik uiteraard zelf getest met een brak geheugenreepje die duizenden RAM errors genereerde en ook heel veel checksum fouten bij ZFS. Daarna reboot met een goed geheugenreepje en scrub gedraaid. Er wordt dan corruptie gedetecteerd en gecorrigeerd, ik had daarbij met enkelvoudige redundantie genoeg aan om alle fouten te corrigeren.

Wat non-ecc geheugen betreft is ZFS niet veiliger dan andere file systems

Dat is dus uitdrukkelijk wel zo; ZFS biedt zowel detectie als correctie van door RAM veroorzaakte bitflips. Geen volledige bescherming; er kan na uren scrubben best wat stuk gaan dat geloof ik prima. Maar zo nu en dan een bitflip mag geen probleem zijn behalve in een heel uitzonderlijk geval dat de checksum verkeerd wordt aangemaakt, dan heb je een corrupt bestand. Ook is het niet ondenkbaar dat essentiële metadata corrupt kan raken. In mijn tests was dat niet gebeurd, terwijl ik toch een geheugenreepje had wat in memtest tienduizenden fouten kreeg binnen enkele seconden; een heel erg brak reepje dus.

Het is juist andersom: als je ECC wilt, dien je eerst alle systemen behalve de ZFS server uit te rusten hiermee, en pas als laatste de ZFS server. De reden hierachter is dat je ZFS server tenminste enige bescherming en detectie heeft van RAM bitflips, terwijl je andere systemen dat niet hebben. Bedenk dat corrupt aangeleverde gegevens ZFS ook niets meer aan kan doen, dus het is eigenlijk veel belangrijker dat je Windows/Linux workstation over ECC beschikt dan je ZFS server.

Ik ben het natuurlijk wel met je eens dat ECC RAM de basis is voor een betrouwbare computer; alle computers zouden ECC moeten hebben dat wordt immers al zo breed toegepast binnen computertechniek, dus why the fuck niet voor RAM? Antwoord is simpel: men wil centjes grof verdienen aan de zakelijke klanten en ECC reserveren voor de zakelijke markt. Ten koste van ons consumenten, die de 2 euro extra kostprijs prima zouden willen in ruil voor ECC bescherming. Maargoed, dit is inherent aan kapitalisme en heeft niets met de techniek zelf te maken.

[ Voor 61% gewijzigd door Verwijderd op 22-01-2014 15:30 ]

[FireDrunk]

@Q, je blaft weer heel hard, maar hebt blijkbaar geen idee wat ZFS allemaal wel en niet kan. ZFS is juist wel beschermt tegen bitflips, zolang deze in de data voorkomen. Nee het is geen ultieme bescherming, dat bestaat niet nee... Of de bitflip namelijk door een kapotte schijf komt (URE), of door geheugen (Bitflip) of zelfs door Netwerk (ja ja, dat kan ook). Zolang de checksum intact is, zal ZFS de data corrigeren.

ECC Helpt... Niet meer en niet minder... Als je ECC zo ongelofelijk belangrijk vind, moet je ook de nieuwste Intel netwerkkaarten (i350 T4) gebruiken, dat zijn de enige netwerkkaarten die ECC onboard hebben voor zover ik weet.

Keihard roepen dat mensen niet moeten piepen als ze zonder ECC een kapotte pool hebben is ook weer onzinnig hard blaffen om niks. Een server is niets anders dan een apparaat wat data levert aan gebruikers. Of dat ding nou een uptime heeft van een uur per jaar of 24/7/365 maakt niet uit.

Als je een consumenten server hebt, welke maar een paar uur per dag aan staat is het echt belachelijk zonde om ECC te gebruiken.

Heb je een bak die 24/7 bestookt wordt met NFS / iSCSI vanwege een ESXi cluster (zoals ondergetekende) dan is ECC zeker aan te raden.

TL;DR: ECC is niet verplicht, het is een optie die een bepaald probleem oplost... Niet meer, niet minder.

[Q]

Verwijderd schreef op woensdag 22 januari 2014 @ 15:23:
@Q: je moet wel weten dat ZFS expliciet is ontwikkeld voor 'dat consumentenspul'. Jeff Bonnwick:

Daar staat 'cheap disks' maar dat is wat anders als consumenten-hardware als in: mobo/cpu/ram. Ik bedoel: ZFS komt bij SUN vandaan. En waarom kunnen we anno 2014 nog steeds geen VDEVS expanden zoals met MDADM? Omdat die feature alleen voor consumenten boeit, niet voor enterprise storage waar een paar disken meer of minder echt niet uitmaken qua budget.

[ Voor 29% gewijzigd door Q op 22-01-2014 15:33 ]

[Q]

FireDrunk schreef op woensdag 22 januari 2014 @ 15:28:
@Q, je blaft weer heel hard, maar hebt blijkbaar geen idee wat ZFS allemaal wel en niet kan. ZFS is juist wel beschermt tegen bitflips, zolang deze in de data voorkomen.

ZFS beschermt niet tegen bitflips in RAM memory. Daar is niets tegen bestand.

Zolang deze in de data voorkomen, dus met RAM errors heb je daar geen controle over, het is een spelletje Russische roulette, wordt het een bitflip in data of in het file system zelf?

Als je een consumenten server hebt, welke maar een paar uur per dag aan staat is het echt belachelijk zonde om ECC te gebruiken.

Voor die mensen maakt het gebruik van ZFS eigenlijk ook niet zoveel uit. dus Tja. Ik denk dat veel NAS bouwers die machines weldegelijk 24/7 aan laten staan, dus voor hen is het net zo relevant. Of ze zijn zo verstandig dat ze trukjes met WOL uithalen....

TL;DR: ECC is niet verplicht, het is een optie die een bepaald probleem oplost... Niet meer, niet minder.

Als we maar niet gaan doen alsof ZFS magischerwjize beschermt tegen rot geheugen. Je zult het eerder door hebben en dat is positief. En je kunt zien wat er rot is. Als je dat thuis acceptabel vindt, soit.

Maar voorkomen is beter dan genezen.

Edit: Stel je schrijft data met een geflipte bit + checksum naar disk, dan zal ZFS nooit weten dat er corrupte data op disk is weggeschreven en heb je alsnog last van silent data corruptie.

Edit2: zie ook dat je voor 370 dollar al een mooi ECC platformpje hebt, conform mijn blog post en hij kiest zelf nog een iets goedkopere processor die ook ECC doet. Dus waar hebben we het over?

Ik vind dat er niet eens geldige financiele redenen zijn om GEEN ECC platformpje neer te zetten.

[ Voor 37% gewijzigd door Q op 22-01-2014 15:55 ]

[Ultimation]

En de zoveelste discussie over het gebruik van ECC-geheugen! Zijn jullie er nu nog niet uit?

[FireDrunk]

@Q, je zal mij ook nooit horen zeggen dat omdat je ZFS gebruikt je geen ECC nodig hebt. Dat klopt als een bus.

@Ultimation, en daar is de discussie wel klaar mee

[Q]

Tja sorry dat ik even loop te blaffen maar als ik eerlijk ben vind ik de post van Cyberjock heel goed geschreven, heel helder en ik zie geen fouten.

En ik trigger dan erg op dit soort niet-specifieke adhominem quotes van CiPHER die niets bijdragen aan de discussie en mensen weg houdt van inhoudelijk goede artikelen.

Die tekst is geschreven door de agressieve en vaak incorrecte cyberjock, als ik zijn naam goed heb onthouden. Veel van wat hij zegt is agressief verwoord en weinig genuanceerd.

Wat mij betreft luisteren jullie iets minder naar die rottweiler die niet kan stoppen met blaffen. Er valt in elk geval genoeg aan te nuanceren.

Ik zou dit soort opmerkingen altijd buiten een discussie willen houden en alleen in willen gaan op de inhoud.

Het is juist andersom: als je ECC wilt, dien je eerst alle systemen behalve de ZFS server uit te rusten hiermee, en pas als laatste de ZFS server. De reden hierachter is dat je ZFS server tenminste enige bescherming en detectie heeft van RAM bitflips, terwijl je andere systemen dat niet hebben. Bedenk dat corrupt aangeleverde gegevens ZFS ook niets meer aan kan doen, dus het is eigenlijk veel belangrijker dat je Windows/Linux workstation over ECC beschikt dan je ZFS server.

Dit vind ik dus het slechtste advies wat je kunt geven aan mensen en het geeft een vals gevoel van veiligheid. Het biedt geen 'enige' bescherming. Dit is echt niet waar. Als data in ram corrupt raakt ziet ZFS dat niet. Dan wordt corrupte data weg geschreven als zijnde 'goede' data.

Dat je checksum errors krijgt als goede data (of het checksum) op een rot stukje RAM beland dat is mooi, maar dan ben je al te laat. Je kunt al silent corruptie hebben. Het is goed om te weten dat het mis gaat...

Maar er zijn betere methoden om achter brak RAM te komen. Dat heet ECC RAM.

Extra edit: Als ik dat gelinkte artikel lees (uit 2007) van Cyberjock:

https://www.usenix.org/le...ech/full_papers/zhang.pdf

Dan is de boodschap zoals ik die lees duidelijk: ZFS kan NIET tegen RAM errors.

[ Voor 19% gewijzigd door Q op 22-01-2014 16:45 ]

[FireDrunk]

Helemaal mee eens, het verhaal dat andere clients eerst ECC nodig hebben, ben ik het ook niet mee eens. De kans is groter dat je lokaal problemen hebt.

[Eagleman7]

Voor thuis gebruik is dat risico toch prima op te vangen door incremental backups?

[Verwijderd]

Dit vind ik dus het slechtste advies wat je kunt geven aan mensen en het geeft een vals gevoel van veiligheid. Het biedt geen 'enige' bescherming. Dit is echt niet waar. Als data in ram corrupt raakt ziet ZFS dat niet. Dan wordt corrupte data weg geschreven als zijnde 'goede' data.

Op een niet-redundante pool zou dat inderdaad het geval zijn, maar bij een redundante RAID-Z pool is dat anders. Dan is één block corrupt en dat valt prima te corrigeren. Dit heb ik zelf getest en ieder van jullie kan hetzelfde testen mits jullie een brak geheugenreepje hebben. Je zult checksum errors zien, na het omwisselen met goed geheugen zie je weer checksum errors, maar alle of bijna alle files worden correct hersteld.

Wel is het zo dat je End-to-end data integrity gaat missen; er kan corrupte data aan applicaties worden gelezen. Dat kan ZFS niet verhinderen; de end to end data integrity protection geldt niet voor RAM corruptie.

Maar ZFS heeft dus wel degelijk extra bescherming terwijl normale filesystems geen enkele bescherming en zelfs geen detectie hebben. Ook is het zo dat het maken van backups via het netwerk ook risicovol is zonder dat de doelcomputer ook over ECC beschikt; corruptie kan zo ongezien in handen komen van ZFS en daartegen kan ZFS nooit beschermen. Vandaar de gedachte dat je beter eerst ECC op je workstations kan hebben dan op je ZFS server zelf.

[Q]

Als je corrupte data in-memory hebt dan wordt dat corrupt-en-al weg geschreven naar disk. Dat gaat ZFS nooit zien en dat wordt niet opgelost door de checksums en parity. Een checksum over poep resulteert nog steeds in poep. Best kut als dat net je meta data / file system zelf is.

Als 'goede' data wordt ingelezen en op rot geheugen terecht komt, dan grijpt ZFS in omdat het checksum niet meer klopt en dat is positief, dat wordt niet opgepakt door oudere file systems.

Je laptop of desktop heeft vrijwel nooit ECC geheugen. Dat is jammer, maar dat is een andere discussie.

Het enige gevolg is dat data corrupt kan raken. Maar geheugen corruptie op je laptop of pc is nooit een dreiging voor de file system integriteit van je ZFS file server. Dat is wel een behoorlijk verschil.

Ik zie gebruikers ook niet snel workstations met ECC geheugen kopen (alhoewel er veel voor te zeggen valt). Er zijn geen 'betaalbare' laptops / desktops met ecc geheugen. Wat realistischer is, is om gewoon even 100 euro meer uit te geven en degelijke hardware te kopen voor je NAS. Want daar gaat het om. We gaan niet doen alsof je verstandig bezig bent om non-ECC geheugen toe te passen in je NAS.

Tuurlijk, als je het risico wilt nemen 'jouw' funeral, maar laten we niet doen alsof dit geen issue is.

Weetje, ik krijg een soort gevoel met dit soort discussies dat ZFS eens soort van snakeoil is die al je problemen die je ooit kunt krijgen in je leven oplost, niets dan goeds over ZFS en alle tekortkomingen (ik zie het niet kunnen afhankdelen van brak RAM niet als een tekortkoming van ZFS maar dat terzijde) een soort van met de mantel der liefte wordt bedekt en gebagataliseerd en verdoezeld.

Ik vraag me af wat de Synology en Qnaps eigenlijk doen qua ram. Ik vrees het ergste.

[ Voor 22% gewijzigd door Q op 22-01-2014 17:04 ]

[FireDrunk]

De zakelijke modellen hebben vaak ECC.

[sphere]

Q schreef op woensdag 22 januari 2014 @ 16:59:
Als je corrupte data in-memory hebt dan wordt dat corrupt-en-al weg geschreven naar disk. Dat gaat ZFS nooit zien en dat wordt niet opgelost door de checksums en parity. Een checksum over poep resulteert nog steeds in poep. Best kut als dat net je meta data / file system zelf is.

Allemaal heel leuk, maar als je toevallig een dubbele bitfault hebt en je pool gaat stuk helpt ECC je ook niet.

Ik bedoel gewoon een gevoel te krijgen of ZFS gevoeliger is voor bitflips dan ext4. Is ZFS een upgrade ceteris paribus tov ext4, of is het zo dat zonder ECC je een groter risico loopt met ZFS dan met ext4. Want dat is wat hij schrijft.

[Rolfie]

sphere schreef op woensdag 22 januari 2014 @ 17:45:
Allemaal heel leuk, maar als je toevallig een dubbele bitfault hebt en je pool gaat stuk helpt ECC je ook niet.

Memmory mirroring, of Memory RAID.... Zit al in highend servers....

Of de toekomst ZFS Memory banken ......

[Verwijderd]

Q schreef op woensdag 22 januari 2014 @ 16:59:
Als je corrupte data in-memory hebt dan wordt dat corrupt-en-al weg geschreven naar disk. Dat gaat ZFS nooit zien en dat wordt niet opgelost door de checksums en parity.

Aantoonbaar onjuist. Heb je zelf al getest met defect RAM geheugen? Nee? Waarom dan die uitspraken?

Als er RAM corruptie plaatsvindt, is dit het meest aannemelijke scenario. Gegevens worden geschreven naar 5 disk RAID-Z en daarbij vindt corruptie plaats; nu is één van de 5 blocks corrupt:
RAID-Z
disk1: OK
disk2: OK
disk3: OK (parity)
disk4: CORRUPT
disk5: OK

Bij de volgende access zal de corruptie gezien worden; de checksum komt niet meer overeen met de data van disk4. Aangezien je redundantie hebt kun je dit soort corruptie prima opvangen.

Eigenlijk kan ZFS dus heel veel RAM corruptie corrigeren. Maar cruciaal is daarbij dat het pas de 2e keer wordt gecorrigeerd; de 1e keer maakt ZFS het juist corrupt. Die 1e keer is niet te detecteren; ZFS denkt dat alles corruptievrij is en schrijft de data weg. Bij corruptie tijdens leesacties kan het inderdaad voorkomen dat er corrupte data wordt geleverd aan applicaties, dus daar gaat je End-to-End data integrity...

Maar blijf toch onverminderd over dat ZFS prima tegen beperkte RAM corruptie kan beschermen?! Als ZFS tegen duizenden RAM errors kan beschermen, dan is een enkele bitflip ook niet zo ultra spannend. Wel denk ik dat het inderdaad zo kan zijn dat je pech kunt hebben en corruptie bepaalde metadata kan corrumperen. Denk bijvoorbeeld aan corruptie bij het berekenen van de checksum. In dat geval is de hele file stuk terwijl eigenlijk alleen de checksum fout is maar de data goed. Dan ben je dus een bestand kwijt.

Ik zie gebruikers ook niet snel workstations met ECC geheugen kopen (alhoewel er veel voor te zeggen valt). Er zijn geen 'betaalbare' laptops / desktops met ecc geheugen. Wat realistischer is, is om gewoon even 100 euro meer uit te geven en degelijke hardware te kopen voor je NAS.

En dan? Dan heb je een miniem risico afgedekt, wat nog steeds backups niet overbodig maakt. Bovendien heb je het grootste probleem niet afgedekt: RAM corruptie bij het schrijven of lezen van/naar de ZFS NAS. Leuk dat je backups maakt, maar als corruptie naar je backup kan lopen zonder gedetecteerd te worden is dat best kut. En als data al corrupt is voordat het in ZFS zijn handen is, dan kan ZFS ook weinig meer beschermen. Dus ik denk dat je realistisch gezien meer baat hebt bij ECC in je workstation (die alle ZFS data gaat lezen en schrijven) dan in de ZFS NAS zelf.

Het argument daarbij is dat ZFS zowel detectie heeft voor RAM corruptie (je ziet vanzelf checksum errors op de disk) alsmede mogelijkheid heeft om heel veel corruptie te corrigeren na een 2e scrub met corruptievrij geheugen. Je workstation heeft geen enkele bescherming en ook geen detectie. Dit terwijl als op dit moment de data corrupt raakt er helemaal geen enkel mechanisme is: geen detectie, geen correctie. Dus zo vreemd is het toch niet om te stellen dat ECC geheugen eerst op je workstations toegepast zou moeten worden en pas als laatste op je ZFS NAS. Dat is toch gewoon een kwestie van de juiste prioriteiten stellen?!

Weetje, ik krijg een soort gevoel met dit soort discussies dat ZFS eens soort van snakeoil is die al je problemen die je ooit kunt krijgen in je leven oplost, niets dan goeds over ZFS en alle tekortkomingen [..] een soort van met de mantel der liefte wordt bedekt en gebagataliseerd en verdoezeld.

Ik wil graag discussiëren maar dan wel graag op de inhoud.

[FireDrunk]

Nee, een ZFS pool is niet gevoeliger dan Ext4, ook ZFS' eigen operaties zijn copy-on-write, dus mocht er corruptie optreden, kan je in theorie zelfs dat terugdraaien (via ingewikkelde zdb commando's enzo...)

@CiPHER, je praat al over het wegschrijven... Zo ver moet je nog helemaal niet denken. Data gaat nog wel 4 keer door je geheugen heen voor het weggeschreven wordt.

Fysieke nic chip -> NIC driver memory
Driver memory -> Kernel memory (TCP stack)
TCP stack -> Samba / NFS memory
Samba / NFS memory -> VFS laag (POSIX compatible laag van ZFS)
VFS -> ZIO
ZIO -> Disk

(ik zal het heus niet helemaal correct hebben, maar je snapt het punt)

Pas bij de op een na laatste stap wordt de checksum berekend. In al die stappen daarvoor kan er al een bitflip optreden.

Potentieel klopt je verhaal heus wel, alleen moeten we niet zeggen dat een bitflip ALTIJD in data voorkomt of ALTIJD in ZFS data of waar dan ook.

De kans is namelijk ook heel groot, dat er een bitflipl in programmacode voorkomt. Dat is potentieel VEEL erger.

Stel de bitflip gebeurt op een address waarop ZFS het virtuele on disk block (dus voor RAID) adres heeft staan, en dat adres word gecorrumpeert, gaat ZFS vrolijk de data consistent en met checksum naar het verkeerde adres schrijven.

Ik ben echt niet bang voor een kapotte ZFS pool, omdat de programmacode misschien maar een paar honderd MB is (inclusief hele BSD / Linux kernel). En je L2ARC / ZFS Write Cache veel groter is.
Maar de checksums staan zelf niet in memory, alleen op disk, dus ZFS controleert volgens mij alleen de checksum als data van disk komt, en niet als deze uit L1 ARC komt.

Daar zit ook nog een risico...

Dus: CiPHER en Q, jullie hebben beide gelijk, en de waarheid ligt ergens in het midden.

[ Voor 79% gewijzigd door FireDrunk op 22-01-2014 18:27 ]

[Verwijderd]

Gelukkig is het wel zo dat ZFS data ongeveer 90% van het RAM-verbruik kan bevatten, terwijl actieve programmacode hooguit een paar procent is. Bovendien kan het programma ook nog crashen, ipv op hol slaan. Dat laatste is natuurlijk wel een worst case scenario; er kan dan vanalles gebeuren met je on-disk data.

En data die ZFS krijgt aangeleverd kan op heel veel plaatsen corrupt raken ja. Maar ik ben zelf het meest bang voor geheugencorruptie die metadata van ZFS zou kunnen beschadigen bij normale leesacties.

Wat ik namelijk ook gemerkt heb is dat een scrub bij defect RAM vele checksum errors oplevert. De 'foutieve' data wordt daarbij gecorrigeerd. Maar in feite wordt goede data juist corrupt gemaakt tijdens die scrub, door de geheugen errors. Rebooten met een goed geheugenreepje kon bij mij alle duizenden corrupte blocks weer herstellen.

Meer testen zou wenselijk zijn, om proberen te reproduceren dat in een zeldzaam geval de hele pool corrupt kan raken, bijvoorbeeld. Dat zou ik in elk geval niet willen tegenspreken en het lijkt me vrij aannemelijk dat dit kan gebeuren. Maar we praten dan wel over een vrij kleine kans. Als ik met defect RAM wat tienduizend errors per seconde genereer mijn pool corruptievrij had gekregen, kun je stellen dat ZFS toch enige mate van resiliency heeft versus RAM bitflips. Iets wat andere filesystems en RAID engines helemaal niet hebben. Dus het kernpunt van mijn betoog klopt denk ik wel.

De vraag zit hem meer in de details. Hoe groot is de kans nu werkelijk op corruptie, etc. Misschien is de kans dat je pool stuk gaat door een bitflips eens per x maanden uiteindelijk veel kleiner dan blikseminslag. Als dat zo is vind ik dat we een beetje panieken om niets en in dat opzicht reageer ik dan ook op die Cyberjock. Want als je naar hem luistert dan ben je eigenlijk een sukkel als je een ZFS NAS zonder ECC bouwt. Dat soort uitspraken kan ik mij wel aan irriteren. Je bent pas een goed mens als je 10 keer per dag bid, zoiets.

[FireDrunk]

Ik ben het ook niet met hem eens, zeuren dat elke zelfrespecterende ZFS gebruiker ECC moet gebruiken is onzin. Als ik een paar bitflips heb en er zijn wat files kapot, soit. Kakka, maar verder geen ramp.

Ik ben dan ook geen enterprise waarbij zo'n file de financiele uitslagen van de afgelopen maanden had kunnen zijn

[EnerQi]

Dit vind ik dus het slechtste advies wat je kunt geven aan mensen en het geeft een vals gevoel van veiligheid. Het biedt geen 'enige' bescherming. Dit is echt niet waar. Als data in ram corrupt raakt ziet ZFS dat niet. Dan wordt corrupte data weg geschreven als zijnde 'goede' data.

Dit risico is toch net zo groot als op andere filesystemen? (niet-ZFS). Hooguit iets groter omdat ZFS meer RAM gebruikt. Als het bijvoorbeeld van 0,01% naar 0,02% gaat, heeft ZFS dus 100% meer kans dat iets fout gaat .

[duiveltje666]

Volgens mij is ZFS van het padje af hier..

tank Used 3.01G Available 1.33T Terwijl mn pool 2.03 TB is ?

[Verwijderd]

@duiveltje666: zpool status commando geeft ruwe ruimte weer, dus inclusief RAID-Z redundancy; bij mirror weer niet, dus ook niet erg consistent. Kijk je naar 'zfs list' output dan zie je bruikbare ruimte zonder redundancy.

[duiveltje666]

ah . dan klopt het wel ja

[Q]

sphere schreef op woensdag 22 januari 2014 @ 17:45:
[...]

Allemaal heel leuk, maar als je toevallig een dubbele bitfault hebt en je pool gaat stuk helpt ECC je ook niet.

Dan halt je systeem direct voordat er schade kan ontstaan, zover ik weet. Dus die foute data komt nooit op disk.

FireDrunk schreef op woensdag 22 januari 2014 @ 19:11:
Ik ben het ook niet met hem eens, zeuren dat elke zelfrespecterende ZFS gebruiker ECC moet gebruiken is onzin. Als ik een paar bitflips heb en er zijn wat files kapot, soit. Kakka, maar verder geen ramp.

Ik ben dan ook geen enterprise waarbij zo'n file de financiele uitslagen van de afgelopen maanden had kunnen zijn

Ik blaf en zeur. Maar ik geef geen false informatie of probeer mensen in slaap te sussen dat hun el-cheapo consumenten spul prima veilig is met ZFS.

Er is een duidelijke teneur dat wordt gedaan alsof ZFS tegen RAM errors beschermd en dat is niet waar. De genoemde bronnen geven dat ook allemaal aan: ECC is echt nodig anders doe je afbreuk aan de bescherming die ZFS je kan bieden.

Ieder zijn eigen keuze - ik zie dat je consumenten hardware hebt ingezet - als jij dat risico persoonlijk acceptabel vind prima, maar bitflips kan al je geheugen en dus ook metadata treffen en dan ben je verder van huis. Laat mensen hier bewust van zijn zodat ze zelf kunnen kiezen. Het beperkt je wat meer in de hardware keuze, maar voor de prijs hoef je het eigenlijk niet te laten.

Ik heb spijt dat mijn 18 TB NAS met non-ECC geheugen is uitgerust. Dat zou ik nu ook nooit meer doen. Mogelijk dat dit systeem ook een upgrade gaat krijgen als mijn nieuwe server klaar is, zodat ik de data eerst veilig kan stellen.

FireDrunk schreef op woensdag 22 januari 2014 @ 18:20:
@CiPHER, je praat al over het wegschrijven... Zo ver moet je nog helemaal niet denken. Data gaat nog wel 4 keer door je geheugen heen voor het weggeschreven wordt.

Inderdaad: de data komt in het geheugen nog voordat het wordt weg geschreven en de code van ZFS raakt.

Nu kunnen we alles allemaal bagataliseren en hardop gaan af vragen 'maar hoe groot is die kans echt?'.

Waarom gebruiken we dan uberhaupt ZFS? Want URE: hoe groot is die kans nu werkelijk? Als we zo gaan redeneren, dan is ZFS toch ook bangmakerij? Maar we weten wel beter.

Over memory fouten: daar zijn stats over en het getal was 150 x per jaar een recoverable memory error voor servers die belast worden en 24/7 draaien.

http://cache-www.intel.com/cd/00/00/46/78/467819_467819.pdf

Van Microsoft: http://research.microsoft...e_Debugging_RFS_71310.pdf
http://www.cs.rochester.edu/~kshen/papers/usenix2007-li.pdf

ZFS is gaaf want met de huidige data sets en schijf-grootes neemt ze een serieus risico weg: dat disks brakke data wegschrijven of aan je apps ophoesten. Maar ZFS kan dat niet 100% zelfstandig, ze vertrouwt op het goed functioneren van een aantal componenten. En goede componenten hoeven niet duur te zijn. Maar je moet wel weten dat je hier beter over na kunt denken.

[ Voor 111% gewijzigd door Q op 22-01-2014 22:21 ]

[duiveltje666]

Net ook weer een leuke issue gevonden ... de webinterface van phpmyadmin ( via services installed) wil niet werken met php 5.5 (typo) , krijg dan een 404 in mn reet geschoven

[ Voor 4% gewijzigd door duiveltje666 op 22-01-2014 21:49 ]

[]Byte[]

Hmmm.... Even voorover buigen aub voor een intern onderzoekje...!
Is de directory er wel? (/usr/local/www/zfsguru/interface/mysql wat vervolgens weer een sym.link is naar de dir. /usr/local/www/phpMyAdmin)
Vooral de sym.link. Als de dir er wel is, kan je de sym.link zelf aanmaken.
Als de dir er niet is, zou ik eens proberen het package nogmaals te installeren.

[ Voor 17% gewijzigd door ]Byte[ op 22-01-2014 23:56 ]

[EnerQi]

@Q

Op dit moment heb ik ook geen ECC geheugen in mijn server/NAS zitten. Het nut is te beperkt (denk ik dan ). Wat bij mij meer fout kan gaat, is dat mijn (1:1) backup op NTFS formaat (2e generatie filesystem) schijven staan, puur om ze nog te kunnen uitlezen op andere OS'en. De backup opslaan in ZFS formaat zou betekenen dat ik mijn backup zeer moeilijk kan teruglezen met het risico dat het dus niet meer lukt en de backup waardeloos is. Wel een backup, geen recovery mogelijkheden ;-).

Hoe ga je dit adresseren? Toch ZFS format backup schijven gebruiken? (Raid0, enkele disks?)

[FireDrunk]

@Q
Je overdrijft volgens mij een tikkie:

About a third of machines and over 8% of DIMMs in
our fleet saw at least one correctable error per year. Our
per-DIMM rates of correctable errors translate to an aver-
age of 25,000–75,000 FIT (failures in time per billion hours
of operation) per Mbit and a median FIT range of 778 –
25,000 per Mbit (median for DIMMs with errors), while pre-
vious studies report 200-5,000 FIT per Mbit. The number of
correctable errors per DIMM is highly variable, with some
DIMMs experiencing a huge number of errors, compared to
others. The annual incidence of uncorrectable errors was
1.3% per machine and 0.22% per DIMM.

Das geen 150x per jaar per ELKE dimm...

@EnerQi, Je kan toch gewoon een LiveCD booten?

[Q]

FireDrunk schreef op donderdag 23 januari 2014 @ 08:07:
@Q
Je overdrijft volgens mij een tikkie:


[...]


Das geen 150x per jaar per ELKE dimm...

@EnerQi, Je kan toch gewoon een LiveCD booten?

Dan overdrijft Intel. Het staat 2x in de presentatie. Ik zal die papers nog eens beter nalezen.

[FireDrunk]

Raar, ik zie ook veel wisselende getallen. Ik waardeer het ten zeerste dat je goede papers noemt hoor!
Als het risico om geheugen fouten te krijgen bijvoorbeeld hoger is dan het getal dat je disk fouten maakt. Zeg ik: Eerder ECC dan ZFS.

[EnerQi]

@EnerQi, Je kan toch gewoon een LiveCD booten?

Klopt, maar een backup moet in mijn ogen altijd leesbaar zijn ipv via een moeilijke weg (live cd, reboot, hopen dat de live cd werkt EN de backup schijf). Eenvoud over complexiteit. Het is nog iets wat ik moet testen en betrouwbaar moet achten .

[FireDrunk]

Ik snap nog steeds je punt niet... Waarom zou een LiveCD niet werken? En je ZFS pool kan je gewoon importeren (mits je niet een 25TB volume hebt met Dedup aan....)?

[EnerQi]

De voordelen van een LiveCD weet ik inmiddels maar in de tijd dat ik de backup maakte, had ik onvoldoende vertrouwen in een LiveCD. Ik ben namelijk erachter gekomen dat bepaalde LiveCD's niet meer werkte op nieuwere hardware of andere problemen veroorzaakten (of gewoon user error, most likely). Omdat een backup moet werken, heb ik besloten om NTFS te gebruiken dat windows dus zo uitleest (en linux denk ik).

Ik wil voorkomen dat ik perongeluk een pool delete ipv importeer in het heetst van de strijd

[ Voor 10% gewijzigd door EnerQi op 23-01-2014 09:36 ]

[Gralgrathor]

EnerQi schreef op donderdag 23 januari 2014 @ 07:51:
Het nut is te beperkt

Iemand zou voor de gein eens twee machines naast elkaar moeten zetten. Zelfde specs, een ECC, de ander non-ECC. Voorts gaan beide machines doorlopend dezelfde 10GB video heen en weer verplaatsen tussen ZFS volumes. Na een paar maanden tijd houden we een video-avondje. Met bier.

[]Byte[]

Gralgrathor schreef op donderdag 23 januari 2014 @ 09:38:
[...]
Na een paar maanden tijd houden we een video-avondje. Met bier.

Whahahaha... Ik lust geen bier.
Maar ik denk niet dat we moeten verzeilen in een welles-nietes-discussie.
Welke oplossing je ook neerzet, er zal altijd wel een bepaald risico blijven. De vraag is alleen tegen welke kosten kunnen we het risico nog verder verkleinen.
Of het een oplossing van 2000 euro of 400.000 euro.
Kijk eens naar de post van tweakone.
Die heeft eens een ZFS-head tussen een Lefthand storage en servers ingezet.
Ook daar komen errors voor!

[Tsurany]

De vraag is welke kans groter is. Een ZFS pool die niet meer functioneert door dat een issue in het RAM optreed of een ZFS pool die niet meer functioneert omdat er teveel schijven uitgevallen zijn. Een RAIDZ1 opstelling met non-ECC geheugen heeft volgens mij een hogere kans van omvallen omdat twee schijven defect raken dan omdat er een bitflip in het geheugen optreed.

[FireDrunk]

Nou, het verschil is (volgens mij) dat je kapotte schijven aan ziet komen (2 schijven die tegelijkertijd falen is nog altijd een geringe kans). Kapot geheugen zie je niet aankomen.

[Tsurany]

Maar wat is de kans dat twee schijven beiden in zeer korte tijd dienst weigeren versus de kans dat je pool onbereikbaar wordt door een bitflip? Puur naar percentages kijkend.

[FireDrunk]

Dat ligt dus 100% aan je schijven. Als ik de papers van Q mag geloven staat er dat 8% van de DIMM's in 1 jaar tijd 1 error geeft. Hoe groot de kans is dat dat programmacode raakt (want denk ik nodig is om je pool te slopen). hangt natuurlijk af van de hoeveelheid geheugen.

Als je 256GB geheugen hebt, is de kans veel kleiner dat je ZFS programmacode raakt dan als je 1GB geheugen hebt.

Het antwoord is dus: Dat is niet te meten. Of in ieder geval niet met zekerheid, omdat je alle mogelijke combinaties zou moeten testen (van 1GB geheugen met 2 consumer schijven tot 256GB geheugen in een storage pod)

[ Voor 16% gewijzigd door FireDrunk op 23-01-2014 10:06 ]

[Gralgrathor]

EnerQi schreef op donderdag 23 januari 2014 @ 09:36:
Omdat een backup moet werken

Het hebben van backups is natuurlijk leuk en belangrijk en alles. Maar een van de vragen die je moet stellen is wat je van een backup wil.

Je familiefoto's tot het einde der tijden veilig stellen? Dan zou ik ze branden op CD, afdrukken op bewerkt leer, en CD en leren vellen in kunsthars gieten en opslaan in een bunker.

Je systeemconfiguratie tien jaar bewaren? Waarom zou je dat willen?

Een steeds veranderende database met bedrijfsgegevens kunnen herstellen tot een bepaalde snapshot? Dan heb je een dedicated machine voor je snapshots, die hun integriteit ten tijde van aanmaak verifieert en hun onveranderlijkheid blijft controleren, en hoef je je over leesbaarheid op andere machines geen zorgen te maken.

Kortom, het soort backup dat je maakt, en de middelen die je daarvoor inzet, hangt af van de data die je wil bewaren.

[duiveltje666]

]Byte\[ schreef op woensdag 22 januari 2014 @ 23:51:
Hmmm.... Even voorover buigen aub voor een intern onderzoekje...!
Is de directory er wel? (/usr/local/www/zfsguru/interface/mysql wat vervolgens weer een sym.link is naar de dir. /usr/local/www/phpMyAdmin)
Vooral de sym.link. Als de dir er wel is, kan je de sym.link zelf aanmaken.
Als de dir er niet is, zou ik eens proberen het package nogmaals te installeren.

oorzaak gevonden , die package wil expliciet php5(5.4) hebben
gedowngrade en het werkt. Hierna weer php 5.5 installed en je raadt het al .. de sabnzbd service stikt ook op php5.5 met installen

[FireDrunk]

Whut? SabNZBd gebruikt helemaal geen PHP? (dat draait op Python / Cheetah)

[ Voor 28% gewijzigd door FireDrunk op 23-01-2014 10:58 ]

[duiveltje666]

leuk die services


sh service_install.sh
* installing service sabnzbdplus
* executing pre-installation script
* Creating _sabnzbd user account
pw: group name `_sabnzbd' already exists
pw: login name `_sabnzbd' already exists
user account:
_sabnzbd:*:350:350::0:0:User &:/services/sabnzbdplus/data:/usr/sbin/nologin
group account:
_sabnzbd:*:350:
* done with pre-installation script
* installing packages
* package sabnzbdplus
note: package sabnzbdplus is already installed; skipping...
* package wget
note: package wget is already installed; skipping...
* package py27-musicbrainz2
note: package py27-musicbrainz2 is already installed; skipping...
* package py27-mutagen
note: package py27-mutagen is already installed; skipping...
* package py27-unidecode
note: package py27-unidecode is already installed; skipping...
* package php5-filter
pkg: Missing dependency matching Origin: 'lang/php5' Version: '5.4.21'

EDIT: uit de file INSTALL_PKGLIST de entry voor php eruit gehaald en opnieuw install script vanaf CLI gedraaid ...nu is het geinstalleerd , maar nu gaat sickbeard weer over de zeik

[ Voor 8% gewijzigd door duiveltje666 op 23-01-2014 11:19 ]

[FireDrunk]

Tja, ik snap niet waarom dat iets met PHP te maken heeft? SabNZBd, SickBeard, CouchPotato en Headphones gebruiken allemaal geen PHP.

Alleen Spotnet gebruikt PHP.

[zzattack]

Terugkoppeling van blackblaze over hdd failure rates:
http://blog.backblaze.com...-hard-drive-should-i-buy/

[FireDrunk]

En deze dan gelijk ook:
http://blog.backblaze.com...rprise-drive-reliability/

[ Voor 18% gewijzigd door FireDrunk op 23-01-2014 13:04 ]

[Verwijderd]

duiveltje666 schreef op donderdag 23 januari 2014 @ 10:44:
oorzaak gevonden , die package wil expliciet php5(5.4) hebben

Dan heb je dus PHP geupdate voordat je alle services geïnstalleerd hebt? Dat is de verkeerde manier. Gebruik of services zonder packages handmatig te updaten, of installeer eerst alle services en update daarna je packages, maar niet andersom.

@FireDrunk: de SABnzbd+ service omvat ook Spotnet, daar komen de php modules vandaan denk ik.

[FireDrunk]

Waarom zoveel meuk in 1 service proppen

[Verwijderd]

Omdat mensen die dingen samen gebruiken. En heb je ze ook allemaal op een rij. Bovendien zijn al die extra services niet aanwezig in de portstree.

[FireDrunk]

Dus maak je het jezelf moeilijker door alles in 1 service te stoppen ipv er netjes losse services van te maken.

Ik dacht dat Jason's mentaliteit was: Als je iets niet wil installeer je het toch gewoon niet?

Dus wat nou als ik alleen SabNZBd wil?

[Verwijderd]

Ben nog nooit iemand tegengekomen die dat ook wilde; die services zijn volgens mij ook allemaal aan elkaar gekoppeld; X doet dat, Y pakt data van X en levert weer aan Z. Ik ken al die meuk niet, maar er zijn nog geen klachten binnengekomen van mensen die ze apart wilde gebruiken.

Met dezelfde opstelling kan phpMyAdmin van MySQL worden gescheiden en phpVirtualBox van VirtualBox, maar dat lijkt mij zelf niet zo wenselijk.

Dat gezegd, je kunt de autostart wel per app regelen want er zijn wel rc.d scripts voor.

[ Voor 17% gewijzigd door Verwijderd op 23-01-2014 15:19 ]

[FireDrunk]

[sarcasm]pisses his pants[/sarcasm]

[Tsurany]

Spotnet heeft niks met SABnzbd van doen en past in die zin ook absoluut niet samen in een service. Dat is mijn inziens wel slecht bouwwerk, het introduceert teveel dependancy's die dus dit soort issues kunnen geven.

[HyperBart]

Verwijderd schreef op donderdag 23 januari 2014 @ 14:41:
[...]
@FireDrunk: de SABnzbd+ service omvat ook Spotnet, daar komen de php modules vandaan denk ik.

Ik heb nog nooit Spotnet gebruikt, ik wil het niet. Ergens in een ander topic verkondig je toen ik neutte over "ja, ZFSguru voelt altijd zo wildgroei-aans aan, ik wil het als pure webpanel gebruiken" dat ik dan gewoon geen services moest installeren, dan bleef het clean.

Ik kies nu voor één bepaalde installatie (of 3 ongeveer) en nu besluiten jullie eigenlijk voor mij dat ik ineens ook maar de hele mikmak van links tot rechts boven en onder moet mee installeren? Ik wil een een NAS, geen fucking hele server met bloated rotzooi.

God, nog even en ik gooi al mijn n00b angsten voor kaal FreeBSD overboord en ik ga naar FreeBSD 10 met handje tandje manueel.

[DXaroth]

HyperBart schreef op donderdag 23 januari 2014 @ 16:20:
[...]



Ik heb nog nooit Spotnet gebruikt, ik wil het niet. Ergens in een ander topic verkondig je toen ik neutte over "ja, ZFSguru voelt altijd zo wildgroei-aans aan, ik wil het als pure webpanel gebruiken" dat ik dan gewoon geen services moest installeren, dan bleef het clean.

Ik kies nu voor één bepaalde installatie (of 3 ongeveer) en nu besluiten jullie eigenlijk voor mij dat ik ineens ook maar de hele mikmak van links tot rechts boven en onder moet mee installeren? Ik wil een een NAS, geen fucking hele server met bloated rotzooi.

God, nog even en ik gooi al mijn n00b angsten voor kaal FreeBSD overboord en ik ga naar FreeBSD 10 met handje tandje manueel.

Dat is ook de reden dat ik helemaal niet voor een zfs-pre-installed-systeem ga, maar het zelf ga doen (op linux dan, want dat ligt me beter) .. volledige controle over wat er wel en niet op gaat draaien (en dat ik nu zelf een eigen interface heb geschreven met spotnet en een sab-like interface, laten we maar achterwege )

[Verwijderd]

HyperBart schreef op donderdag 23 januari 2014 @ 16:20:
Ik heb nog nooit Spotnet gebruikt, ik wil het niet. Ergens in een ander topic verkondig je toen ik neutte over "ja, ZFSguru voelt altijd zo wildgroei-aans aan, ik wil het als pure webpanel gebruiken" dat ik dan gewoon geen services moest installeren, dan bleef het clean.

Doe dat dan?

Ik kies nu voor één bepaalde installatie (of 3 ongeveer) en nu besluiten jullie eigenlijk voor mij dat ik ineens ook maar de hele mikmak van links tot rechts boven en onder moet mee installeren?

Eerst was SabNZBD alleen, toen kwamen CouchPotato en SickBeard erbij. En men wilde ook ondertitels en de hele mikmak. Het is op verzoek van de community dat de SABnzbd+ service is uitgebreid.

Als jij het niet wilt draaien; installeer het dan niet. Probleem opgelost.

[duiveltje666]

Verwijderd schreef op donderdag 23 januari 2014 @ 14:41:
[...]

Dan heb je dus PHP geupdate voordat je alle services geïnstalleerd hebt? Dat is de verkeerde manier. Gebruik of services zonder packages handmatig te updaten, of installeer eerst alle services en update daarna je packages, maar niet andersom.

@FireDrunk: de SABnzbd+ service omvat ook Spotnet, daar komen de php modules vandaan denk ik.

Heb het gedowngrade , services reinstalled , portmaster update (ook voor php5.5 again gedraaid en nu komt couchaardappel niet meer op

EDIT : Posts zijn niet om te ranten , heb Freebsd toch maar kunnen upgraden van 10.0-RC1 naar 10.0-RELEASE zonder dat zfsguru op zn gat ging

[ Voor 10% gewijzigd door duiveltje666 op 23-01-2014 16:56 ]

[Verwijderd]

Heb je gereboot na het installeren van SABnzbd+ ? Ik denk niet dat CouchPotato PHP gebruikt, dus daar kan het niet aan liggen. De eerste keer start CouchPotato niet, dat is bekend. Je moet gewoon een keer rebooten.

[duiveltje666]

Dat werkt na reboot , nu nog het probleemgeval sickbeard , deze komt nog steeds niet op

[Verwijderd]

Je kunt proberen hem handmatig te starten met:

service sickbeard onestop
service sickbeard onestart

De errors zie je mogelijk niet omdat die onderdrukt worden, dan moet je handmatig python commando draaien. Pas dan zie je mogelijke errors.

Er zitten best wat bugs in al die utilities. En de rc.d scripts zijn zelfgeschreven; die zijn ook niet bijgeleverd. Alleen sabnzbd zelf is eigenlijk een normaal programma via portstree, de rest is allemaal best lastig om werkend te krijgen, maar als ik SABnzbd+ in een LiveCD start, werken bij mij alle apps/tabs.

[duiveltje666]

Daar ga ik zo mee aan de slag , eerst voedertijd

EDIT :

service sickbeard onestop
Stopping sickbeard
sickbeard is not running; no pid file found!
[root@zfsguru /usr/ports/sysutils/froxlor]# service sickbeard onestart
Starting sickbeard.
service sickbeard stop
Stopping sickbeard sickbeard is not running; no pid file found!

[ Voor 73% gewijzigd door duiveltje666 op 23-01-2014 18:02 ]

[EnerQi]

Verwijderd schreef op donderdag 23 januari 2014 @ 16:37:

[...]

Eerst was SabNZBD alleen, toen kwamen CouchPotato en SickBeard erbij. En men wilde ook ondertitels en de hele mikmak. Het is op verzoek van de community dat de SABnzbd+ service is uitgebreid.

Als jij het niet wilt draaien; installeer het dan niet. Probleem opgelost.

Ik dacht dat de eerste reactie was dat het 1 service was en ook maar 1 mogelijkheid. Nu vermeld je dat het toch apart kan? Overigens gebruik ik alleen Sabnzbd en de rest niet . Het is een lastige discussie maar misschien toch apart mogelijk maken (na 0.2 bijvoorbeeld en of het natuurlijk kan ). Net zoals Firedrunk opmerkt: Ik dacht dat Jason's mentaliteit was: Als je iets niet wil installeer je het toch gewoon niet?

[FireDrunk]

SickBeard en CouchPotato zijn peanuts om aan de praat te krijgen.. Zelfs vanaf source een paar minuutjes werk... Voor sickbeard gebruik ik een alternatief init script van internet. (2e hit op google ofzo). Bij couchpotato zit er gewoon een init script bij (init.freebsd)

[Verwijderd]

@duiveltje666: controleer eerst of autostart is ingeschakeld; zonder dat kan de service niet starten. Dit gebeurt automatisch maar misschien heb je het handmatig uitgeschakeld?

Zo niet, voer dit eens uit als root:
python /services/sabnzbdplus/data/sickbeard/SickBeard.py

@EnerQi:
Alle SAB apps zitten in één service; ze zijn ook afhankelijk van elkaar. Bovendien worden ze vrijwel altijd samen gebruikt. Als je al die dingen niet wilt maar alleen Spotweb of SAB, installeer dan niet de ZFSguru service. Hetzelfde geldt voor andere services zoals MySQL waar de phpMyAdmin frontend bij zit.

@FireDrunk: het stoppen van de services werkt niet altijd. Die python apps kunnen kennelijk alleen via een HTTP-request worden afgesloten. Dus gewoon een normaal kill commando gaat niet (goed). Waarom dat in godsnaam is is mij een raadsel. Er is wel brst veel werk besteed om SAB out of the box werkend te krijgen. Iets wat nu 'bijna' lukt. Nog steeds zijn er allerlei bugs of issues waardoor die apps niet willen starten. Voor mij het hoofdpijn; ik ben blij dat het min of meer werkt. Als jullie wat anders willen laat maar zien.

[duiveltje666]

# python /services/sabnzbdplus/data/sickbeard/SickBeard.py
Starting up Sick Beard master from /services/sabnzbdplus/data/sickbeard/config.ini
Your database version has been incremented
past what this version of Sick Beard supports.

If you have used other forks of SB which have
modified your database it may now be unusable.

[Verwijderd]

Wellicht dat je packages hebt geupdate waardoor SABnzbd+ SickBeard niet meer werkt. Daar kan ik niet mee helpen. Moeten dat soort apps maar niet zoveel dependencies kweken daar krijg je dit soort ellende van...

Edit: misschien kun je zoeken of er een nieuwere/fixed versie van SickBeard is?

[ Voor 19% gewijzigd door Verwijderd op 23-01-2014 18:18 ]

[duiveltje666]

Verwijderd schreef op donderdag 23 januari 2014 @ 18:13:
Wellicht dat je packages hebt geupdate waardoor SABnzbd+ niet meer werkt. Daar kan ik niet mee helpen. Moeten dat soort apps maar niet zoveel dependencies kweken daar krijg je dit soort ellende van...

Edit: misschien kun je zoeken of er een nieuwere/fixed versie van SickBeard is?

Sabnzbd zelf werkt anders prima

[RudolfR]

duiveltje666 schreef op donderdag 23 januari 2014 @ 18:12:
# python /services/sabnzbdplus/data/sickbeard/SickBeard.py
Starting up Sick Beard master from /services/sabnzbdplus/data/sickbeard/config.ini
Your database version has been incremented
past what this version of Sick Beard supports.

If you have used other forks of SB which have
modified your database it may now be unusable.

Naast /services/sabnzbdplus/data/sickbeard/config.ini staat waarschijnlijk een sickbeard.db van een nieuwere versie sickbeard dan wat je nu draait.
Als je die weggooit, kan er een database in het oude formaat worden aangemaakt.

[duiveltje666]

ja precies , daar was ik zelf ook al achter
kan em nu opstarten , echter als ik bijv een willekeurig menuutje aanklik in SB

500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

Traceback (most recent call last):
File "/tank/zfsguru/services/10.0-001/sabnzbdplus/data/sickbeard/cherrypy/_cprequest.py", line 660, in respond
response.body = self.handler()
File "/tank/zfsguru/services/10.0-001/sabnzbdplus/data/sickbeard/cherrypy/lib/encoding.py", line 193, in __call__
self.body = self.oldhandler(*args, **kwargs)
File "/tank/zfsguru/services/10.0-001/sabnzbdplus/data/sickbeard/cherrypy/_cpdispatch.py", line 25, in __call__

[Verwijderd]

Dat bedoel ik met 'Peanuts' om werkend te krijgen.

duiveltje666: voor de duidelijkheid je krijgt dit probleem alleen als je packages update? Als je dat niet doet start sickbeard wel gewoon? Heb je sickbeard schoon/kaal geinstalleerd of heb je de data directory hergebruikt?

[duiveltje666]

ik heb zowel voordat ik php en andere packages heb geupgrade sickbeard schoon en kaal installed

[Verwijderd]

Wat je zou kunnen doen is nog een keer proberen en verifiëren dat SickBeard pas stuk gaat nadat je packages hebt geupdate. Je kunt voordat je packages update een snapshot maken van je boot filesystem. En eventueel een bugreport naar de SickBeard devs.

[duiveltje666]

ik ga het anders doen denk ik
die map deleten en dan ff van git de sickbeard-source trekken

[Verwijderd]

Je kunt nog wat anders proberen. Er zit een download.sh script in de packages directory. Daarmee kun je de nieuwste versies downloaden. Daar was ik nog niet eerder opgekomen.

Zo werkt het: verwijder de huidige service. Download de service (heb je al gedaan).

Dan als root:

mkdir /services/sabnzbdplus
# volgende commando moet je wellicht aanpassen; in elk geval tank naar je poolname en ik denk de versie
tar x -C /services/sabnzbdplus/ -f /tank/zfsguru/download/service-sabnzbdplus-10.0-001-amd64-10.tar
cd /services/sabzbdplus/packages
# voer nu het script uit wat alle extra apps downloadt
./download.sh
# nu moet je git installeren; zie instructies
/services/sabnzbdplus/service_install.sh
/services/sabnzbdplus/service_register.sh REGISTER

Dan rebooten en ben benieuwd?

[ Voor 3% gewijzigd door Verwijderd op 23-01-2014 19:22 ]

[FireDrunk]

Trek gewoon even de git source naar /usr/local/sickbeard
Pas even de config aan zodat hij op 0.0.0.0 luistert ipv 127.0.0.1.
Kopieer init.freebsd naar /usr/local/etc/rc.d/sickbeard
En gaan...

[ Voor 6% gewijzigd door FireDrunk op 23-01-2014 19:24 ]

[Verwijderd]

Dat kan ook maar dan moet je alsnog de directories instellen, als je dat doet naar /services/sabnzbdplus/data/sickbeard dan houd je het ook compatible met de ZFSguru service.

[duiveltje666]

blijft met de methode van Cipher dit gezeik houden

[Verwijderd]

En met de methode van FireDrunk? Volgens mij hetzelfde omdat dat ook via git gaat.

Kan zijn dat SickBeard nog niet geupdate is om met je nieuwe packages om te kunnen gaan. In dat geval heb je pech. Wil je SickBeard gebruiken kun je dan beter niet (alles) updaten met portmaster.

[duiveltje666]

dat gaat ook via git , cherrypy lijkt de boosdoener

[Verwijderd]

In elk geval, het ligt niet aan FreeBSD, niet aan de ZFSguru service maar is gewoon een issue van SickBeard. In dat geval kun je het beter elders bespreken, zoals hier: [Ervaringen] CouchPotato, Sickbeard, Headphones e.a. deel 3.

@syl: ik was je voor. Ook bij zeer specifieke ZFSguru issues los ik meestal via DM op, om dit topic te ontzien.

[ Voor 18% gewijzigd door Verwijderd op 23-01-2014 20:22 ]

[syl765]

Horen bovenstaande installatie perikelen niet in een ander topic.
Het woord zfs komt al een tijdje niet meer voor

[duiveltje666]

syl765 schreef op donderdag 23 januari 2014 @ 20:19:
Horen bovenstaande installatie perikelen niet in een ander topic.
Het woord zfs komt al een tijdje niet meer voor

deels mee eens , aangezien zfsguru het meest gebruikt wordt kan het wel handig zijn om problemen zo op te lossen en zfsguru te verbeteren

[Verwijderd]

Nog even voor de duidelijkheid: de service werkt wel voordat je update met portupgrade, klopt? In dat geval is het geen ZFSguru-specifiek issue maar een upstream bug. Wachten totdat er een nieuwere versie van SickBeard uitkomt of simpelweg geen packages updaten.

[duiveltje666]

ik ga wel ff kijken of ik sickbeard buiten de service om kan installen

[EnerQi]

10.0-002 is gereleased voor ZFSguru. Zijn er bepaalde problemen opgelost of wat kunnen we verwachten in deze release? Er is op Tweakers en ZFSguru.com geen melding te vinden.

[indian]

Ik heb interesse in het opbouwen van een ZFS setup. De vraag is virtualiseren of baremetal.
Zijn er verder nog nadelen in het virtualiseren naast een klein performance verlies?

De hardware ondersteunt ecc, vtx/vtd en kan volgens mij gebruikmaken van alle ESXI 5.5 functionaliteiten.

[duiveltje666]

EnerQi schreef op vrijdag 24 januari 2014 @ 09:32:
10.0-002 is gereleased voor ZFSguru. Zijn er bepaalde problemen opgelost of wat kunnen we verwachten in deze release? Er is op Tweakers en ZFSguru.com geen melding te vinden.

Gniffel , net die 10.0-02 installed , het gaat al fout zodra ik het wachtwoord voor user ssh wil veranderen in services

Warning : this service does not exist

[FireDrunk]

indian schreef op vrijdag 24 januari 2014 @ 10:04:
Ik heb interesse in het opbouwen van een ZFS setup. De vraag is virtualiseren of baremetal.
Zijn er verder nog nadelen in het virtualiseren naast een klein performance verlies?

De hardware ondersteunt ecc, vtx/vtd en kan volgens mij gebruikmaken van alle ESXI 5.5 functionaliteiten.

In mijn ogen niet, je verliest inderdaad wat performance, en je configuratie is iets ingewikkelder soms (je moet vmxnet3 werkend krijgen enzo) maar je krijgt er weer wat extra vrijheid voor terug.