Het grote ZFS topic

[FireDrunk]

dan zou je dat 12.5 * 10^12 keer kunnen doen voordat je een UBE tegenkomt.

Dat zei je Maar maakt niet uit, ik snap wat je bedoelt nu

Over je reactie:

Je hebt helemaal gelijk, we moeten een harddisk gewoon zien als een Blackbox, en ons niet druk maken over wat er binnenin gebeurt. Als het ding zijn specs haalt, mooi, zo niet, kan het lastig zijn. Maar meer dan dat ook niet.

Wat ik wel semi- eng vind, is conclusies verbinden als: Ik heb een lege(re) pool, dus ik zit iets veiliger in de specs. Maar dat weerleg je zelf ook al.

Dat was het enige punt wat ik wilde maken

[tvwes]

FireDrunk schreef op dinsdag 21 april 2015 @ 13:13:
[...]


Dat zei je Maar maakt niet uit, ik snap wat je bedoelt nu

Over je reactie:

Je hebt helemaal gelijk, we moeten een harddisk gewoon zien als een Blackbox, en ons niet druk maken over wat er binnenin gebeurt. Als het ding zijn specs haalt, mooi, zo niet, kan het lastig zijn. Maar meer dan dat ook niet.

Wat ik wel semi- eng vind, is conclusies verbinden als: Ik heb een lege(re) pool, dus ik zit iets veiliger in de specs. Maar dat weerleg je zelf ook al.

Inderdaad, dat is hoe je het moet bekijken een blackbox. Waarvan je bepaalde zaken weet en bepaalde niet. De blackbox heeft als oa eigenschap dat er een bepaalde kans op een leesfout per zoveel gelezen data. Als jij constant je niet volle schijf aan het lezen bent dan is de kans groter dan als je zoaf en een toe een filmpje streamt van je volle 8TB schijf.

Het is inmiddels duidelijk dat een opfrissingscursus statistiek en kansberekening niet verkeerd zou voor de lezer hier. (niet persoonlijk bedoeld)

Dat was het enige punt wat ik wilde maken

Nieuwe post met antwoorden op je vragen bijna klaar...

[riwi]

tvwes schreef op maandag 20 april 2015 @ 21:51:
Lees even dit artikel van een nog grotere professional.
Die (oude) adviezen over optimale vdev samenstellingen hebben alleen betrekking op zeer specifieke use cases. (zie artikel)
De vertaling van de samenvatting van het artikel uit de link:
Gebruik raidz. Stop niet te veel schijven in een vdev. Zet compressie aan.

Ook in de usecase van Matt gaat hij ervan uit dat de pool wel compressible data bevat. Op zich geen slechte aanname, maar voor de 'video server toepassing' misschien niet geheel waar.
Ik heb wel de lz4 compressie optie aangezet op mijn test bak maar nog niet op de 'grote' nas.

Ik las dat er ook gewerkt wordt aan 'large block' support. Dan zouden er dus behalve de standaard 128kB blocksize tot 1MB ZFS block'en gekozen kunnen worden voor een pool of vdev of filesysteem. Dat zou voor grote files meer efficientie geven. En dan kan je de 2^n+r aanbeveling voor RAIDZr echt gedag zeggen.
https://github.com/zfsonlinux/zfs/pull/2865
Voor ZoL nog wel toekomstmuziek, maar wie weet komt het voor iIlumos en FreeBSD wel eerder.

[FireDrunk]

ZoL is juist meestal vrij snel met implementaties volgens mij...

[riwi]

FireDrunk schreef op dinsdag 21 april 2015 @ 18:06:
ZoL is juist meestal vrij snel met implementaties volgens mij...

Ik lees net de commentaren in de pull request en het lijkt er inderdaad op dat Behlendorf dit al snel wil implementeren. Ik draai met de laatste git patches meestal op m'n test server. Ik wil het wel proberen als ze het mergen met de master.
Soms kunnen ze niet zo snel volgen omdat oa geheugen beheer en allocatie in Linux echt anders werkt dan in FreeBSD en Illumos.

[FireDrunk]

Ik hoop (en verwachte eigenlijk ook wel) dat de sequentiele performance hierdoor wel voor een aantal mensen zal stijgen

Alsook de scrub snelheden misschien wel. Als alle IO met 1MB per keer ingeladen wordt, heb je een stuk minder IO's nodig om te scrubben

[riwi]

scrub, resilver wordt sneller en minder slack space bij grote files zeggen ze. Dus zeker interessant.

[tvwes]

riwi schreef op dinsdag 21 april 2015 @ 17:24:
[...]
Ook in de usecase van Matt gaat hij ervan uit dat de pool wel compressible data bevat. Op zich geen slechte aanname, maar voor de 'video server toepassing' misschien niet geheel waar.
Ik heb wel de lz4 compressie optie aangezet op mijn test bak maar nog niet op de 'grote' nas.

@riwi, zou jij mij willen aanwijzen waar dat staat in het artikel. Het enige wat ik lees dat compressie bij comprimeerbare data altijd meer oplevert dan wat voor getweak aan RAIDZ configuraties.

This compression is more beneficial than any RAID-Z sizing

Voor video server toepassing met grote files is en was er nooit iets aan de hand. De standaard record size van 128K minimaliseert de inefficientie al dermate dat het altijd al een non issue was voor grote bestanden.
Nogmaals: alleen bij hele specifieke use-case als database met 4K of 8K page sizes of VM disk images op 512bytes/sector blockdevices zonder compressie helpt het om een minimaal aantal blockdevices per RAIDZ vdev op te nemen.

Je media archief met grote slecht comprimeerbare files kan je opslaan op een RAIDZ vdev van willekeurige grootte in een apart filesystem zonder compressie

code:

 zfs create -o compression=off mpool/shared/mypr0n

Maar als je genoeg cpu cycles over hebt hebt dan zou ik de lz4 compressie voor alles aan laten staan. De enige keer dat je moet oppassen is als je kleine stukje data in een groot bestand als een database of een vmdk gaat wijzigen. Pas dan moet je gaan tunen.

Ik las dat er ook gewerkt wordt aan 'large block' support. Dan zouden er dus behalve de standaard 128kB blocksize tot 1MB of zelfs 4MB ZFS block'en gekozen kunnen worden voor een pool of vdev. Dat zou voor grote files meer efficientie geven. En dan kan je de 2n+2 aanbeveling voor RAIDZ2 echt gedag zeggen.
https://github.com/zfsonlinux/zfs/pull/2865
Voor ZoL nog wel toekomstmuziek, maar wie weet komt het voor iIluminos en FreeBSD wel eerder.

Deze feature was vorig jaar al gecommit. Ook dit is weer een feature die je niet klakkeloos moet gaan gebruiken. Ik heb het getest voor een dvr systeem. En dat leverde na wat aanpassing aan de operator software zeker betere prestaties. Maar bij gewoon gebruik leverde het een (soms enorme) performance penalty op naast een enorme verspilling van de ruimte. De evt performance winst voor een scrub weegt denk ik niet op tegen de nadelen. Als je scrub je traag is is je vdev te breed.
"Use RAID-Z. Not too wide. Enable compression." Een smallere vdev en meer vdevs en probleem opgelost.

Als jij nu met 128K record size tegen problemen aan loopt ben ik heel benieuwd wat je use case is en wat die problemen dan zijn.

edit1) Een typo, een moeilijk woord vervangen door makkelijk en een stukje tekst was plots weg.

[tvwes]

FireDrunk schreef op dinsdag 21 april 2015 @ 08:42:
Allereerst: Mooi stukje! Ik ben het echt op heeeeel veel vlakken met je eens, en met een paar kleine aanpassingen mag dit van mij in de topic start, maar toch wil ik je graag uitnodigen om een paar dingen uit te leggen, want ik kan vooral de conclusie die je uit bepaalde onderdelen trekt niet volgen. Zie het alsjeblieft niet als een aanval, maar meer om een nederige vraag om verduidelijking.

Dank je wel, vooral voor de kritische vragen. Ik zal een en ander proberen te beantwoorden. Maar houd er rekening mee dat het een vereenvoudiging van de werkelijkheid blijft en dat een heleboel zaken nog steeds achterwege blijven.
Mocht je het artikel willen aanpassen en/of verplaatsen dan hoor ik dat graag.

[...]

Dit vraag ik mij af. Dit zou betekenen dat een error te maken heeft met tijd en kans, en 0,0 met de disk zelf. Dat is volgens mij niet zo. Een UBER heeft ook te maken met sectoren die bijvoorbeeld lang niet gelezen zijn, en waarvan de elektrische lading lager is.

De conclusie die jij trekt, dat je 12.5* meer kan lezen bij een (vrijwel) lege schijf, kan ik dus moeilijk geloven. Als je maar 1 sector beschreven hebt, maar daarna die sector 10 jaar niet aanraakt, en daarna pas weer leest, denk ik dat het risico op een UBER toch redelijk significant is.

Harde cijfers hierover zijn er uiteraard niet, dus het is en blijft speculeren.

Jij haalt nu andere factoren aan die ik had weggelaten. Daarnaast pas je de UBER verkeerd toe. UBER is de uncorrectable bit-error rate. Het is een eenheid (die ook voor oa. ram en flash wordt gebruikt) die het aantal data errors per gelezen bit na interne ECC. De UBER spec is alleen van toepassing op lezen. Wat jij er nu bij haalt is "magnetic decay" "bitrot" het fenomeen dat gemagnetiseerde eilandjes op de platter langzaam hun magnetisme verliezen. Dat is volkomen waar. Het is alleen niet een eigenschap waar, voor zover mij bekend, harddisk fabrikanten ooit een uitspraak over doen. Dit in tegenstelling tot tape fabrikanten, die voor courant tape als LTO5 en LTO6 een shelf life van 30 spec'en. Voor harddisken gaat men vaak uit 10 jaar. Maar net als bij tape hangt er veel af van de bewaar condities. Vooral (lucht)vocht is erg slecht. Harddisk fabrikanten speccen wel "niet in bedrijf" condities, maar die zijn voor transport en opslag bedoeld niet voor lange termijn archivering.
Ja een harddisk die 10 jaar op de plank heeft gelegen zal zeker problemen geven. En ik vind het ook een heel leuk voorbeeld. Deze harddisk zal zeker last hebben van magnetisch verval. Maar zal dat ook leiden tot een UBE? (Een harde lees fout) Ja er zullen er heus wel zijn. Maar ik denk dat de harddisk ook op de nodige plaatsen lachend een sector terug geeft terwijl 10 jaar geleden er iets anders stond. En daar heb je nu ZFS voor. Dankzij de veel sterkere checksums zal ZFS deze fouten wel eruit halen en de drive firmware met zn zwakkere checksums niet. Het is een hypothese maar ik zal later in het jaar op een conferentie dit eens navragen bij wat mensen die van de hoed en de rand weten.
Waardoor die UBE nu wordt veroorzaakt maakt voor jouw als eindgebruiker niet zoveel uit. Heeft de schijf zo heel af en toe een tracking probleem? Kan de schijf zo heel af en toe de vibratie niet compenseren? Het is leuk om er over na te denken maar je komt er niet achter want de fabrikant deelt die kennis niet met je. Het enige wat je weet is de fabrikant een bepaalde kans in de vorm van de UBER specificeert bij gebruik binnen de gespecificeerde bedrijfscondities.
Jouw voorbeeld haalde er een ander probleem bij wat los staat van de UBER en hier ook niet echt relevant is. Het ging om het lezen van disken (vol of minder vol) vandaag niet om disken die 10 jaar op de plank hadden gelegen. Natuurlijk is de UBER gecorreleerd met de fysieke schijf. Maar eenheid UBER drukt alleen een kans uit per zoveel gelezen bits. De fysieke schijf en eventuele oorzaken blijven buiten beschouwing. Mijn stelling dat of een schijf nu vol of leeg is maakt voor de kans op een UBE niet uit, blijft daarmee overreind.

[...]

Ook hier heb ik mijn vragen bij. Een schijf met een goed geparkeerde kop kan volgens mij 150-250 g hebben. Nou is mijn wiskunde erg gedateerd (lees: 10 jaar oud), maar dat is niet niks. Het is ook niet dat je het ding met 160KM/h tegen de grond aan kan gooien, maar van een beetje hobbelen in karton zou het ding niet stuk moeten gaan.

Nogmaals: het is geen aanval, meer een geval van: Ik denk dat het subjectief is, en dat jouw ervaringen voor je spreken. Persoonlijk heb ik namelijk nog nooit een kapotte disk gezien vanwege transport. En als dat wel zo is, moet je even met je postbode praten denk ik, want dan gaat hij er slechter mee om dan een blok beton

Ik hoop overigens dat de echte werktuigbouwkundige, fysicus zich graag meld voor deze berekening.
Ik zat ooit ook zo te rederenen. Het probleen is niet acceleratie of de snelheid maar afremming. De harddisk vliegt lekker door de lucht en komt spontaan een betonnen vloer tegen. De vertraging is dan veel groter dan 250G. Als de harddisk nu in een dun kartonnen doosje zou zitten is het al veel minder. Hoe dun dat karton ook is het helpt zeker. HP had jaren geleden laptops met een eigen ingebouwd accelerometer ipv in de harddisk. De speciale software van HP parkeerde dan de kop. Je kan die sensor uitlezen en dan de G kracht van de impact bepalen. Als je de laptop van iets 4 of 5 inch liet vallen op een stenen vloer kwam je al boven de 150G. Terwijl het hele chasis al zo veel absorbeerde.

Als de fabrikant harddisken in dozen van dik twee laags karton met een custom schok absorberende piepschuim binnenkant en deksel verschepen doen ze dat niet zonder reden. Als ik harddisken ontvang op de bodem van een super dun kartonnen doosje met wel een laag wokkels of kussens ER BOVENOP plus dat ik weet wat een enorm tempo die bezorgers hebben (waar zij niks aan kunnen doen overigens) dan is dat niet goed voor de harddisk en een risico wat ik niet wil nemen. Ik haal graag dan een keer onderweg even die bestelling op. Die paar euro duurder kan mij helemaal niets schelen als ik het gezeur er tegen over zet. Nu zal de ene winkel het beter verzenden dan de ander maar als het even kan zou ik het afhalen.

[...]

Hier heb je in veel gevalen gelijk in, maar er is 1 maar, en dat is: marketing.
Bedrijven verkopen features in naam vanwege geld, niet omdat ze zogenaamd echt nodig zijn.
Ja, de echte top schijven zoals de Hitachi Ultrastars zijn echt wel beter dan de Western Digital Blue's (Enterprise SAS / Fibre Channel even buiten beschouwing gelaten).

Maar het verschil tussen de Western Digital RED en GREEN's is alleen TLER Firmware en Garantie.

Dat wil niet zeggen dat je ongelijk hebt, maar het is van mij uit meer een kanttekening om goed te kijken waar je voor kiest, en niet blind kijkt naar het label Enterprise.

Natuurlijk is het marketing. Maar als de dokter zegt neem dit pilletje. Ga jij daar dan altijd tegenin? Weet je ook echt dat een ander pilletje net zo goed is. Nee dat weet je niet. De dokter kan dit zelf maar tenauwernood beoordelen. Alleen een onderzoeker die dagelijks bezig is met dat een geneesmidel kan daar een uitspraak over doen.
Wij, jij en ik net zo min hebben die kennis over harddisken niet. En iedereen die niet werkzaam is op dit moment bij een harddisk fabrikant in een ontwikkelfunctie heeft die kennis evenmin en overschat zichzelf.
Vermoedelijk heb je gelijk met het verschil tussen RED en Green, maar misschien zij er nog meer verschillen... ik dacht de RED's bijv ook vibratie compensatie hadden. Wij weten het niet. Vermoedelijk zijn alle platters hetzelfde maar dmv binning gaan de betere naar de duurdere modellen. Maar dat staat nergens, je weet het domweg niet. Het enige waar je dan vanuit kan gaan is de opgave van de fabrikant.
Ik heb nergens SAS, FC en/of Enterprise produkten of oplossingen genoemd of voorgesteld. Ik heb juist toegespitst op de gemiddelde SOHO gebruiker, en geadviseerd om in beginsel een model te kiezen waarvan de fabrikant zegt dat het geschikt is voor de toepassing. Telkens benadruk ik dat een ieder geheel vrij is om zelf te kiezen. Wil je meer betrouwbaarheid dan betaal je daar voor. Iedereen mag dat zelf bepalen. Ik denk dat mijn advies heel neutraal is, en gebaseerd op dingen die we weten niet op dingen die we vermoeden. Daarnaast claim ik het niet beter te weten dan de fabrikant en heb ik niemand richting enterprise of welke richting dan ook gestuurd.

[...]

Heb je een bron waarin staat dat een schijf die het druk heeft sneller slijt dan een schijf die niets doet? Ik moet daar namelijk nog harde cijfers van zien. Niet dat het theoretisch gezien raar is, maar ik heb er gewoon nog geen harde cijfers over gezien...

Publieke data heb ik niet, wel weet ik dat de uitval van echt druk belaste bedrijfsarrays heel hoog is. Nu ligt dat gedeeltelijk aan het feit dat het 10K of 15K rpm harddisken zijn. Die worden gloeiend heet en dan 24x7 io's er naar toe sturen zorgt voor slijtage. Soms heb je de hele array 1 of 2 keer vervangen in een jaar. De actuator en motor blijven uiteindelijk mechanische onderdelen die slijten en kunnen falen. Hoe robuust ze ook zijn in mijn ogen als je bekijkt hoe complex het is een hoeveel bewegingen er per seconde worden gemaakt. Soms staan dit soort arrays jaren als standby te idlen, daar faalt geen enkele disk. (niet vragen waarom er niet naar gerepliceerd word want de wegen van het management zijn duister en ondoorgrondelijk)
Het enige andere stuk ervaring wat ik je kan bieden is dat hotspares na toevoeging aan de array ongeveer net zolang meegaan als de schijven die alleen in de array zaten. De hotspares hadden geen draaiende motor wel actieve elektronica.
En boeren verstand voorspelt ook dat iets wat veel gebruikt wordt sneller slijt dan iets wat niet gebruikt wordt. Er bestaan geen componenten die niet slijten en mechanische al helemaal niet. Gebruik je het meer slijt het sneller.

[...]

Op zich is de quote in beginsel waar, maar meerdere VDEV's gebruiken is een *nog* hoger risico... Ik zou liever zien dat je dan 2 pools maakt. Dat is administratief minder handig (maar zeker niet onmogelijk om hetzelfde te bereiken), maar veiliger omdat je ipv een RAID0+RAIDZ array maakt, maar 2 losse RAIDZ array's. Daarvan is de kans lager dat je al je data verliest.

(misschien begrijp ik je opmerking verkeerd) Maar zoals ik je stelling "dat meerdere vdevs binnen een zpool een hogere mttdl hebben" interpreteer, ben ik dat niet met je eens en andere ook niet.
Als eerste is het belangrijk om vast te stellen dat de kans op een device fault een onafhankelijke kans. Iedere harddisk is een losse geldstuk. Het gooien van kop bij een volgend geldstuk is onafhanklijk van de uitkomst van het gooien van een ander geldstuk. Daarnaast gaat het om de kans op data verlies niet de kans op device faults.
Laten we uitgaan van een zpool met een enkel RAIDZ2 met 12 schijven. De kans P_3df is de kans op drie device faults. P_3df is gelijk aan de kans op dataverlies van de zpool bij dit enkele RAIDZ2 vdev met 12 drives . Echter als je twee RAIDZ2 vdevs maakt met 6 schijven binnen de zpool is de kans op dataverlies van je zpool kleiner dan P_3df. De kans op P_3df geld voor de twaalf schijven en is groter dan die voor zes schijven.
Anders gezegd de kans dat er drie schijven uit vallen binnen een vdev met zes drives is kleiner dan dat drie drives uitvallen in een vdev van twaalf drives.
Als je naar de grafiek kijkt in de link zie het terug voor de mirror devices dat meer vdevs maar een kleine verhoging van het risico met zich meebrengt. Terwijl het risico toeneemt met het aantal schijven in een vdev.
Je stelt voor om twee zpools te maken "Ik zou liever zien dat je dan 2 pools maakt" Als we het voorbeeld van boven blijven gebruiken en de 12 schijven nu verdelen over twee zpool met ieder een RAIDZ2 vdev met zes schijven. Dan levert geen betere MTTDL op dan deze zelfde twee vdevs in een zpool stoppen. Zie de kans berekening hierboven. Het enige wat ik kan bedenken is dat de kans op dataverlies, door oorzaken anders dan een device fault, kleiner wordt . Misschien raakt maar een enkele zpool corrupt en heb je dan ander nog. Maar die kansen kan ik niet inschatten en is voor mij nooit een overweging BINNEN een enkel systeem. Dat je data spreid over meerdere systemen is wel iets wat heel gewoon is.

[...]

Voor de gemiddelde gebruiker hier, is dat een hele dure optie... Een Coldspare kost je al snel ~100-140 euro (voor een 4-6TB schijf). Daarvoor heb je ook onbeperkte online backup per jaar.
Dus mits je internetverbinding het niet toestaat, zou ik liever zien dat mensen een fatsoenlijke backup regelen. Dan maakt het een stuk minder uit dat je disk er een dag of twee langer over doet.

Dit is niet helemaal een zuivere afweging. De spare is een eenmalig uitgave met weinig afschrijving de disk slijt niet De online opslag moet je elk jaar weer betalen. De (hot/cold)spare maakt snelle recovery mogelijk. Als je een adaquate internet verbinding hebt dan nog kan het dagen of weken duren voordat je alles terug hebt. Ik moet er niet aan denken om een paar TB te downloaden. Of je moet weer (behoorlijk) betalen om je data op een externe usb schijf te laten zetten en op sturen. Daarnaast kunnen de meeste van deze diensten alleen files backup'en, meestal is er geen unix client en support voor ZFS is er al helemaal niet. Ik kan dus niet zomaar een zvol backup'en naar zo'n dienst. Dan zijn er nog wat beperkingen en addertjes onder het gras. Al deze diensten zijn prachtig, en ik moedig het gebruik ervan ook aan. Maar je kan deze diensten niet zomaar als offsite backup voor je zpool gebruiken. Als een van deze diensten nu een blockdevice van onbeperkte grootte zou aanbieden voor een tientje per maand zou dat een complete game changer zijn.

Wat ik ter afsluiting onderaan mijn artikel schreef "niks moet (behalve de backup)" sta ik volkomen achter. Al het mooi's van ZFS ten spijt zonder echte backup ben je nergens. Online / cloud diensten kunnen een onderdeel vormen van je backup strategie. Maar (voor zover mij bekend) kan geen van deze diensten een backup van mijn zpool verzorgen. (backup betekent dat alles wat ik had inc metadata na de restore ook weer aanwezig is) De spare is financieel niet zo onredelijk, het maakt snelle recovery mogelijk en is niet te vergelijken met een online backup dienst.

[...]

Ik vind persoonlijk dat je hier wel heel makkelijk over doet. Het mixen van ongebalanceerde VDEV's is haast een wetenschap op zich. ZFS gaat namelijk zorgen dat de VDEV's tegelijkertijd vol raken. Je nieuwe VDEV gaat dus veel meer IO te verduren krijgen. Je plaatst dus een ongetest VDEV naast een goed VDEV om vervolgens al je data op het nieuwe VDEV geschreven te zien worden. Faalt dat VDEV ben je *al* je data kwijt...

[...]

Wat schreef ik er heel nadrukkelijk bij? Dit is een procedure voor de liefhebber
Er is altijd een moment dat je vdev ongetest is. Of dat nu is bij inbedrijfstelling of toevoeging naderhand maakt niet uit. De procedure is erop gericht om juist geteste schijven te gebruiken dmv ingebruik zijnde en daarmee geteste schijven in een vdev te vervangen door nieuwe exemplaren. In principe moet je niet meer vervangen dan je aan pariteit hebt. Ook moet je zelf bepalen wanneer het moment is dat je op het vlakke stuk van de badkuip curve zit. Is dat na een maand? Drie maanden? De onbalans maakt voor sommige workloads helemaal niet uit. Zeker hier op tweakers is het voor een bepaalde groep helemaal geen bezwaar om telkens een vdev toe te voegen. Als iemand met een enkel vdev voldoende performance heeft zn film te streamen dan is het toevoegen (met of zonder wisselen) van vdevs een manier om langzaam in de tijd meer storage toe te voegen zonder in een keer een paar duizend euro af te moeten rekenen.

@FireDrunk, nogmaals dank voor de vragen en ik hoop dat ik het voldoende goed heb uitgelegd. Als de antwoorden afdoende zijn moet ik nog wel nadenken hoe ik dat in het artikel kan verwerken.

[FireDrunk]

tvwes schreef op dinsdag 21 april 2015 @ 21:18:
[...]

Dank je wel, vooral voor de kritische vragen. Ik zal een en ander proberen te beantwoorden. Maar houd er rekening mee dat het een vereenvoudiging van de werkelijkheid blijft en dat een heleboel zaken nog steeds achterwege blijven.
Mocht je het artikel willen aanpassen en/of verplaatsen dan hoor ik dat graag.

[...]

Jij haalt nu andere factoren aan die ik had weggelaten. Daarnaast pas je de UBER verkeerd toe. UBER is de uncorrectable bit-error rate. Het is een eenheid (die ook voor oa. ram en flash wordt gebruikt) die het aantal data errors per gelezen bit na interne ECC. De UBER spec is alleen van toepassing op lezen. Wat jij er nu bij haalt is "magnetic decay" "bitrot" het fenomeen dat gemagnetiseerde eilandjes op de platter langzaam hun magnetisme verliezen. Dat is volkomen waar. Het is alleen niet een eigenschap waar, voor zover mij bekend, harddisk fabrikanten ooit een uitspraak over doen. Dit in tegenstelling tot tape fabrikanten, die voor courant tape als LTO5 en LTO6 een shelf life van 30 spec'en. Voor harddisken gaat men vaak uit 10 jaar. Maar net als bij tape hangt er veel af van de bewaar condities. Vooral (lucht)vocht is erg slecht. Harddisk fabrikanten speccen wel "niet in bedrijf" condities, maar die zijn voor transport en opslag bedoeld niet voor lange termijn archivering.
Ja een harddisk die 10 jaar op de plank heeft gelegen zal zeker problemen geven. En ik vind het ook een heel leuk voorbeeld. Deze harddisk zal zeker last hebben van magnetisch verval. Maar zal dat ook leiden tot een UBE? (Een harde lees fout) Ja er zullen er heus wel zijn. Maar ik denk dat de harddisk ook op de nodige plaatsen lachend een sector terug geeft terwijl 10 jaar geleden er iets anders stond. En daar heb je nu ZFS voor. Dankzij de veel sterkere checksums zal ZFS deze fouten wel eruit halen en de drive firmware met zn zwakkere checksums niet. Het is een hypothese maar ik zal later in het jaar op een conferentie dit eens navragen bij wat mensen die van de hoed en de rand weten.
Waardoor die UBE nu wordt veroorzaakt maakt voor jouw als eindgebruiker niet zoveel uit. Heeft de schijf zo heel af en toe een tracking probleem? Kan de schijf zo heel af en toe de vibratie niet compenseren? Het is leuk om er over na te denken maar je komt er niet achter want de fabrikant deelt die kennis niet met je. Het enige wat je weet is de fabrikant een bepaalde kans in de vorm van de UBER specificeert bij gebruik binnen de gespecificeerde bedrijfscondities.
Jouw voorbeeld haalde er een ander probleem bij wat los staat van de UBER en hier ook niet echt relevant is. Het ging om het lezen van disken (vol of minder vol) vandaag niet om disken die 10 jaar op de plank hadden gelegen. Natuurlijk is de UBER gecorreleerd met de fysieke schijf. Maar eenheid UBER drukt alleen een kans uit per zoveel gelezen bits. De fysieke schijf en eventuele oorzaken blijven buiten beschouwing. Mijn stelling dat of een schijf nu vol of leeg is maakt voor de kans op een UBE niet uit, blijft daarmee overreind.

Heb je een bron die dit onderbouwt? Ik ging/ga er namelijk gewon heel simpel vanuit dat in de UBER spec ook magnetic decay meegenomen is als een gemiddeld voorkomend probleem.

[...]

Ik hoop overigens dat de echte werktuigbouwkundige, fysicus zich graag meld voor deze berekening.
Ik zat ooit ook zo te rederenen. Het probleen is niet acceleratie of de snelheid maar afremming. De harddisk vliegt lekker door de lucht en komt spontaan een betonnen vloer tegen. De vertraging is dan veel groter dan 250G. Als de harddisk nu in een dun kartonnen doosje zou zitten is het al veel minder. Hoe dun dat karton ook is het helpt zeker. HP had jaren geleden laptops met een eigen ingebouwd accelerometer ipv in de harddisk. De speciale software van HP parkeerde dan de kop. Je kan die sensor uitlezen en dan de G kracht van de impact bepalen. Als je de laptop van iets 4 of 5 inch liet vallen op een stenen vloer kwam je al boven de 150G. Terwijl het hele chasis al zo veel absorbeerde.

Als de fabrikant harddisken in dozen van dik twee laags karton met een custom schok absorberende piepschuim binnenkant en deksel verschepen doen ze dat niet zonder reden. Als ik harddisken ontvang op de bodem van een super dun kartonnen doosje met wel een laag wokkels of kussens ER BOVENOP plus dat ik weet wat een enorm tempo die bezorgers hebben (waar zij niks aan kunnen doen overigens) dan is dat niet goed voor de harddisk en een risico wat ik niet wil nemen. Ik haal graag dan een keer onderweg even die bestelling op. Die paar euro duurder kan mij helemaal niets schelen als ik het gezeur er tegen over zet. Nu zal de ene winkel het beter verzenden dan de ander maar als het even kan zou ik het afhalen.

Hoewel ik het helemaal met je eens ben, projecteer je hier je eigen (niet wetenschappelijke) ervaring op een advies. Jij hebt meegemaakt dat je disks zo verstuurd werden, ik niet.

Ik bestel (lalala reclame ) regelmatig bij Afuture of Azerty, en die sturen disks keurig op in die speciale plastic doosjes met daaromheen nog weer karton.

Je verhaal klopt echt hoor, maar ik ben niet zo van het bang maken van mensen met horror verhalen... Dat is in mijn ogen erg subjectief.

(Lees sowieso: no flame intended )

[...]

Natuurlijk is het marketing. Maar als de dokter zegt neem dit pilletje. Ga jij daar dan altijd tegenin?

JA! Ik laat mij niet zomaar troep voeren... Dan zou je ook alle homepatische en spirituele meuk moeten geloven... Zo werkt het niet... Er moet een duidelijk onderbouwde wetenschappelijke verklaring zijn voor het gebruik van een specifiek medicijn, en als jij als patient vraagt om een medische onderbouwing van je arts, zou in mijn ogen een goed arts deze ook zeker geven!

Weet je ook echt dat een ander pilletje net zo goed is. Nee dat weet je niet.

Dat hoeft ook niet, het enige wat ik moet weten zijn kaders/randvoorwaarden waarin ik iets acceptabel vindt.
(Risico, prijs, manier van inname, mate van inname, comfort, bijwerkingen, etc etc etc.)
Het is daarna aan de arts om een passend middel te vinden (of niet ).

De dokter kan dit zelf maar tenauwernood beoordelen. Alleen een onderzoeker die dagelijks bezig is met dat een geneesmidel kan daar een uitspraak over doen.

Ben ik het niet helemaal mee eens, hoewel ik wel (denk ik) begrijp wat je bedoelt.
In principe ga ik ervan uit dat alle informatie die de dokter/onderzoeker gebruikt om zijn keuzes te maken publiekelijk beschikbaar is, waardoor wij daar direct of indirect bij kunnen.

Wij, jij en ik net zo min hebben die kennis over harddisken niet. En iedereen die niet werkzaam is op dit moment bij een harddisk fabrikant in een ontwikkelfunctie heeft die kennis evenmin en overschat zichzelf.

Eens, maar dat is 100% de andere kant op. Dat ik er niets begrijp van de inhoud van een harddisk betekend niet automatisch dat ik mij maar 'dom' moet houden.

Vermoedelijk heb je gelijk met het verschil tussen RED en Green, maar misschien zij er nog meer verschillen... ik dacht de RED's bijv ook vibratie compensatie hadden. Wij weten het niet. Vermoedelijk zijn alle platters hetzelfde maar dmv binning gaan de betere naar de duurdere modellen. Maar dat staat nergens, je weet het domweg niet.

Er zwerven gewoon een aantal blogs posts van mensen die twee kapotte schijven open geschroeft hebben en laten zien dat die dingen gelijk zijn van binnen.

Ook zijn er volgens mij geluidsmetingen gedaan waaraan je kan zien dat het resonantiegeluid hetzelfde was volgens mij...

(kan het mis hebben, misschien haal ik artikelen door elkaar).

Het enige waar je dan vanuit kan gaan is de opgave van de fabrikant.

Niet helemaal waar, er zijn mensen die onderzoek doen buiten het boekje van de fabrikant

Ik heb nergens SAS, FC en/of Enterprise produkten of oplossingen genoemd of voorgesteld. Ik heb juist toegespitst op de gemiddelde SOHO gebruiker, en geadviseerd om in beginsel een model te kiezen waarvan de fabrikant zegt dat het geschikt is voor de toepassing.

Mee eens, nadeel is alleen weer dat ook de fabrikant geen rekening houdt met ZFS.
Zo zegt WD dat je REDS moet nemen voor NAS systemen vanwege TLER, en in principe heb je dat niet verplicht nodig voor ZFS.

In zo'n geval krijg je een mismatch tussen wat de fabrikant denkt dat jouw toepassing van de schijf is, en de daadwerkelijke features die je nodig hebt.

Telkens benadruk ik dat een ieder geheel vrij is om zelf te kiezen. Wil je meer betrouwbaarheid dan betaal je daar voor.

Dat is te kort door de bocht, daarmee ga je er al vanuit dat meer geld meer betrouwbaarheid koopt. Dan geloof je in mijn ogen al teveel in marketing

Tuurlijk zal er een kern van waarheid in zitten, maar in mijn ogen moet je als (tweaker) consument altijd kritisch kijken naar wat jouw maatstaven van betrouwbaarheid zijn en niet alleen maar luisteren naar wat de fabrikant jouw op de mouw speld als 'betrouwbaar'.

Iedereen mag dat zelf bepalen. Ik denk dat mijn advies heel neutraal is, en gebaseerd op dingen die we weten niet op dingen die we vermoeden. Daarnaast claim ik het niet beter te weten dan de fabrikant en heb ik niemand richting enterprise of welke richting dan ook gestuurd.

Eensch

[...]

Publieke data heb ik niet, wel weet ik dat de uitval van echt druk belaste bedrijfsarrays heel hoog is. Nu ligt dat gedeeltelijk aan het feit dat het 10K of 15K rpm harddisken zijn. Die worden gloeiend heet en dan 24x7 io's er naar toe sturen zorgt voor slijtage. Soms heb je de hele array 1 of 2 keer vervangen in een jaar. De actuator en motor blijven uiteindelijk mechanische onderdelen die slijten en kunnen falen. Hoe robuust ze ook zijn in mijn ogen als je bekijkt hoe complex het is een hoeveel bewegingen er per seconde worden gemaakt. Soms staan dit soort arrays jaren als standby te idlen, daar faalt geen enkele disk. (niet vragen waarom er niet naar gerepliceerd word want de wegen van het management zijn duister en ondoorgrondelijk)
Het enige andere stuk ervaring wat ik je kan bieden is dat hotspares na toevoeging aan de array ongeveer net zolang meegaan als de schijven die alleen in de array zaten. De hotspares hadden geen draaiende motor wel actieve elektronica.
En boeren verstand voorspelt ook dat iets wat veel gebruikt wordt sneller slijt dan iets wat niet gebruikt wordt. Er bestaan geen componenten die niet slijten en mechanische al helemaal niet. Gebruik je het meer slijt het sneller.

Niet om je aan te vallen, maar hier gebruik je je boerenverstand, waar je 2 alinea's terug nog zegt: Ik doe geen aannames over data die ik niet weet

[...]

(misschien begrijp ik je opmerking verkeerd) Maar zoals ik je stelling "dat meerdere vdevs binnen een zpool een hogere mttdl hebben" interpreteer, ben ik dat niet met je eens en andere ook niet.
Als eerste is het belangrijk om vast te stellen dat de kans op een device fault een onafhankelijke kans. Iedere harddisk is een losse geldstuk. Het gooien van kop bij een volgend geldstuk is onafhanklijk van de uitkomst van het gooien van een ander geldstuk. Daarnaast gaat het om de kans op data verlies niet de kans op device faults.
Laten we uitgaan van een zpool met een enkel RAIDZ2 met 12 schijven. De kans P_3df is de kans op drie device faults. P_3df is gelijk aan de kans op dataverlies van de zpool bij dit enkele RAIDZ2 vdev met 12 drives . Echter als je twee RAIDZ2 vdevs maakt met 6 schijven binnen de zpool is de kans op dataverlies van je zpool kleiner dan P_3df. De kans op P_3df geld voor de twaalf schijven en is groter dan die voor zes schijven.
Anders gezegd de kans dat er drie schijven uit vallen binnen een vdev met zes drives is kleiner dan dat drie drives uitvallen in een vdev van twaalf drives.
Als je naar de grafiek kijkt in de link zie het terug voor de mirror devices dat meer vdevs maar een kleine verhoging van het risico met zich meebrengt. Terwijl het risico toeneemt met het aantal schijven in een vdev.
Je stelt voor om twee zpools te maken "Ik zou liever zien dat je dan 2 pools maakt" Als we het voorbeeld van boven blijven gebruiken en de 12 schijven nu verdelen over twee zpool met ieder een RAIDZ2 vdev met zes schijven. Dan levert geen betere MTTDL op dan deze zelfde twee vdevs in een zpool stoppen. Zie de kans berekening hierboven. Het enige wat ik kan bedenken is dat de kans op dataverlies, door oorzaken anders dan een device fault, kleiner wordt . Misschien raakt maar een enkele zpool corrupt en heb je dan ander nog. Maar die kansen kan ik niet inschatten en is voor mij nooit een overweging BINNEN een enkel systeem. Dat je data spreid over meerdere systemen is wel iets wat heel gewoon is.

In mijn ogen:
Je berekening klopt bijna helemaal, maar mist 1 cruciaal punt.

Als je twee VDEV's hebt, moet je de kans dat VDEV A faalt optellen bij de MTTDL van VDEV B.
Dit omdat de VDEV's onlosmakelijk met elkaar verbonden zijn.

De berekening zoals jij hem nu uitwerkt, geld voor JBOD. Als de VDEV's onafhankelijk van elkaar zouden kunnen functioneren.

Als er genoeg disks in VDEV B falen doet VDEV A het ook niet meer, ondanks dat alle ZFS structuren intact zijn.

Hoe je die kansen exact wiskundig bij elkaar optelt, weet ik ook niet, maar 2 VDEV's met kans X naast elkaar is onveiliger dan 2 losse VDEV's met kans x.

Volgens mij is het zo simpel uit te leggen.

[...]

Dit is niet helemaal een zuivere afweging. De spare is een eenmalig uitgave met weinig afschrijving de disk slijt niet De online opslag moet je elk jaar weer betalen. De (hot/cold)spare maakt snelle recovery mogelijk. Als je een adaquate internet verbinding hebt dan nog kan het dagen of weken duren voordat je alles terug hebt. Ik moet er niet aan denken om een paar TB te downloaden. Of je moet weer (behoorlijk) betalen om je data op een externe usb schijf te laten zetten en op sturen. Daarnaast kunnen de meeste van deze diensten alleen files backup'en, meestal is er geen unix client en support voor ZFS is er al helemaal niet. Ik kan dus niet zomaar een zvol backup'en naar zo'n dienst. Dan zijn er nog wat beperkingen en addertjes onder het gras. Al deze diensten zijn prachtig, en ik moedig het gebruik ervan ook aan. Maar je kan deze diensten niet zomaar als offsite backup voor je zpool gebruiken. Als een van deze diensten nu een blockdevice van onbeperkte grootte zou aanbieden voor een tientje per maand zou dat een complete game changer zijn.

ZFS werkt ook op files, dus als jij een zfs send | file.gz doet, en die file in de cloud zet, heb je ZFS in de cloud...

Wat ik ter afsluiting onderaan mijn artikel schreef "niks moet (behalve de backup)" sta ik volkomen achter. Al het mooi's van ZFS ten spijt zonder echte backup ben je nergens. Online / cloud diensten kunnen een onderdeel vormen van je backup strategie. Maar (voor zover mij bekend) kan geen van deze diensten een backup van mijn zpool verzorgen. (backup betekent dat alles wat ik had inc metadata na de restore ook weer aanwezig is) De spare is financieel niet zo onredelijk, het maakt snelle recovery mogelijk en is niet te vergelijken met een online backup dienst.

Klopt, maar we hadden het over SOHO... De gemiddelde SOHO gebruiker heeft echt niet meer dan 1TB aan *echt* cruciale data.

We zijn allemaal tweakers, en vinden het allemaal fijn om veel, snelle, en betrouwbare storage te hebben, maar als we heel scherp naar ons eigen gedrag kijken, komen we er vaak achter dat we maar een paar honder GB aan echt belangrijke data hebben.

En dan heb ik niet over je muziekcollectie waar je jaren op gespaard hebt. Die kan je ook missen...
Als ik het over cruciale data heb, heb ik het over: Documenten die je nodig hebt voor je werk, huis, eigendomsaktes, trouwfoto's, kinderfoto's, rechtzaakdocumenten, financiele meuk etc etc.

Ik zal een keer flink vloeken als mijn server uitfikt, maar ik ga er niet persoonlijk failliet aan.

[...]
Wat schreef ik er heel nadrukkelijk bij? Dit is een procedure voor de liefhebber
Er is altijd een moment dat je vdev ongetest is. Of dat nu is bij inbedrijfstelling of toevoeging naderhand maakt niet uit. De procedure is erop gericht om juist geteste schijven te gebruiken dmv ingebruik zijnde en daarmee geteste schijven in een vdev te vervangen door nieuwe exemplaren. In principe moet je niet meer vervangen dan je aan pariteit hebt. Ook moet je zelf bepalen wanneer het moment is dat je op het vlakke stuk van de badkuip curve zit. Is dat na een maand? Drie maanden? De onbalans maakt voor sommige workloads helemaal niet uit. Zeker hier op tweakers is het voor een bepaalde groep helemaal geen bezwaar om telkens een vdev toe te voegen. Als iemand met een enkel vdev voldoende performance heeft zn film te streamen dan is het toevoegen (met of zonder wisselen) van vdevs een manier om langzaam in de tijd meer storage toe te voegen zonder in een keer een paar duizend euro af te moeten rekenen.

Duidelijk, misschien nam ik het woord liefhebber wel te scherp op. Ik zou het afraden, en niet eens iets noemen voor een liefhebber. Maar dat ben ik

@FireDrunk, nogmaals dank voor de vragen en ik hoop dat ik het voldoende goed heb uitgelegd. Als de antwoorden afdoende zijn moet ik nog wel nadenken hoe ik dat in het artikel kan verwerken.

Komt vast goed

[riwi]

tvwes schreef op dinsdag 21 april 2015 @ 20:20:

@riwi, zou jij mij willen aanwijzen waar dat staat in het artikel. Het enige wat ik lees dat compressie bij comprimeerbare data altijd meer oplevert dan wat voor getweak aan RAIDZ configuraties.

Due to compression, the physical (allocated) block sizes are not powers of two, they are odd sizes like 3.5KB or 6KB. This means that we can not rely on any exact fit of (compressed) block size to the RAID-Z group width.

Dus hij zegt hier dat het kiezen van een raidz2 layout aan de hand van mooie deelbaarheid van de 128kB blocks over de beschikbare disks niet een voordeel is als je compressie gebruikt.

tvwes schreef op dinsdag 21 april 2015 @ 20:20:
Deze feature was vorig jaar al gecommit. Ook dit is weer een feature die je niet klakkeloos moet gaan gebruiken. Ik heb het getest voor een dvr systeem. En dat leverde na wat aanpassing aan de operator software zeker betere prestaties. Maar bij gewoon gebruik leverde het een (soms enorme) performance penalty op naast een enorme verspilling van de ruimte. De evt performance winst voor een scrub weegt denk ik niet op tegen de nadelen. Als je scrub je traag is is je vdev te breed.
"Use RAID-Z. Not too wide. Enable compression." Een smallere vdev en meer vdevs en probleem opgelost.

Als jij nu met 128K record size tegen problemen aan loopt ben ik heel benieuwd wat je use case is en wat die problemen dan zijn.

Ja Illuminos loopt wel voor meestal. Ik vind het al super dat opgeloste bugs in Illumos gemapped worden naar ZoL en FreeBSD.

Ik heb geen problemen met 128kB recordsize. Ik had gelezen dat door implementatie van 1MB records de verhouding metadata/contentdata zou verbeteren. En dat dat in de 'procenten' kan lopen. Nou 3% van een pool van 10x4TB is toch leuk om te winnen aan netto opslagruimte.
En ZFS send en receive zou ook sneller kunnen werken, al zal dat meestal gelimiteerd zijn door het netwerk bij thuisgebruikers die geen 10Gbit installeren.

Ik gebruik maar 1 vdev per pool en 3 pools van 10 disks in de NAS PC. meerdere vdevs zijn niet nodig (geen hoge IOPS nodig) en de multiple pool oplossing past beter bij mijn backup en upgrade strategie.

Mijn usecase is voornamelijk opslag van films en series in HD, liefst volledige blurays zonder recode.

[tvwes]

riwi schreef op dinsdag 21 april 2015 @ 23:59:
[...]


Due to compression, the physical (allocated) block sizes are not powers of two, they are odd sizes like 3.5KB or 6KB. This means that we can not rely on any exact fit of (compressed) block size to the RAID-Z group width.

Dus hij zegt hier dat het kiezen van een raidz2 layout aan de hand van mooie deelbaarheid van de 128kB blocks over de beschikbare disks niet een voordeel is als je compressie gebruikt.

De zin die je aanhaalt en de conclusie die je trekt hebben niets met elkaar te maken. En de conclusie lees ik ook niet in het artikel.
Laatste poging om het uit te leggen en dan zal ik er over op houden
In de zin die je aanhaalt staat dat door compressie je er niet vanuit kan gaan dat de gecomprimeerde data precies in je RAIDZ vdev stripe past.
Dat is nog geen groot ruimte efficiency probleem, want RAIDZ ondersteunt variable breedte van de stripe. Je RAIDZp vdev bepaalt de hoeveelheid pariteit p. Iedere vdev stripe bevat minimaal p aan pariteit. Daarnaast vereist RAIDZ dat iedere allocatie een veelvoud is van (p+1).
Zie ook het layout plaatje in het artikel.

Er zijn drie effecten om rekening mee te houden als het om ruimte efficiency gaat:
1) data die eerst misschien precies een veelvoud van de vdev stripe grootte was is dat na compressie niet meer.
2) er kunnen niet volledige volle blokken ( data en pariteit) ontstaan.
3) je kan eindigen met zoveel blokken dat er padding nodig, om te voldoen aan eis (p+1) blokken (zie licht blauwe blokken in plaatje

Het eerst effect wordt opgelost door de variabele stripe breedt in RAIDZ en kost geen ruimte.
Het tweede effect, zorgt voor inefficiente opslag. Echter in het artikel wordt er direct bij gezegd de deze inefficientie in het niet valt door de voordelen van compressie.
Het derde effect is weinig aan te doen.

Maar niks staat een willekeurige RAIDZ vdev grootte in de weg.

"Dus hij zegt hier dat het kiezen van een raidz2 layout aan de hand van mooie deelbaarheid van de 128kB blocks over de beschikbare disks niet een voordeel is als je compressie gebruikt."
Bedoel je dat het een nadeel is? Het enige, oa "These people would claim that for example, a 9-wide (2^3+1) RAIDZ1 is better than 8-wide or 10-wide. This is not generally true.", wat in het artikel staat is dat het aantal disks in de RAIDZ vdev over het algemeen niet uitmaakt. En zeker voor het gebruik hier op tweakers. In de conclusie van het artikel staat wel de aanbeveling het aantal schijven in een vdev niet te groot te maken

Misschien bedoelen we hetzelfde, maar ik las het niet in je bericht. 2 zinnen is niet echt duidelijk als het over zoiets best lastigs gaat.

[...]

Ja Illuminos loopt wel voor meestal. Ik vind het al super dat opgeloste bugs in Illuminos gemapped worden naar ZoL en FreeBSD.

Het is Illumos.
Dat is de doelstellling van OpenZFS om vanuit een gemeenschappelijke codebase (die van Illumos) ports te maken naar andere platforms. Dit is efficient en voorkomt veel fouten. Het is alleen jammer dat er zo weinig resources (betalende mensen om ontwikkelaars te betalen) zijn om allerlei leuke features die al lang af zijn te porten naar OpenZFS.

Ik heb geen problemen met 128kB recordsize. Ik had gelezen dat door implementatie van 1MB records de verhouding metadata/contentdata zou verbeteren. En dat dat in de 'procenten' kan lopen. Nou 3% van een pool van 10x4TB is toch leuk om te winnen aan netto opslagruimte.

Het is kwestie van testen. Het kan wat ruimte opleveren het kan ook ruimte kosten door niet volle blokken.

Kan jij een goede beschrijving (soort bestanden en filesizes) geven van de inhoud van je zpool. Alsmede de output posten van
zpool get all [zpool name]
zfs get all [zpool/zfs/met films of bulk van je data]
zdb | grep ashift

Dan ik kijken hoe de ruimte nu benut wordt, qua efficiency.

En ZFS send en receive zou ook sneller kunnen werken, al zal dat meestal gelimiteerd zijn door het netwerk bij thuisgebruikers die geen 10Gbit installeren.

Ik heb een tijdje tweaker @jacovn geholpen met wat zfs send en receive performance vraagstukken in tvwes schreef op maandag 13 april 2015 @ 22:27
Zonder large blocks of wat voor tuning dan ook haalde hij 829MiB/sec via send/recv met een enkel RAIDZ2 vdev met 10 schijven dit via 10GBit ethernet.
Zoals je zelf al schreef, gigabit is bijna altijd de beperkende factor niet je zpool. De large block feature gaat dus lang niet altijd helpen.

Ik gebruik maar 1 vdev per pool en 3 pools van 10 disks in de NAS PC. meerdere vdevs zijn niet nodig (geen hoge IOPS nodig) en de multiple pool oplossing past beter bij mijn backup en upgrade strategie.

Mijn usecase is voornamelijk opslag van films en series in HD, liefst volledige blurays zonder recode.

Lijkt we een prima en weloverwogen keuze voor jouw gebruik. Ik adviseer ook vaak om meerdere zpool's aan te maken ipv 1 gigantische pool. Een zpool met veel vdevs of schijven erin heb je nodig voor veel iops, bandbreedte,een namespace met veel opslag of grote zvol's
Als de client of applicatie overweg kan met meerdere namespaces (smb of nfs shares bijv) dan zou ik ook meerdere zpool's aanmaken.
Maar bij een grote vmware datastore bijvoorbeeld wil je vaak wel al die ruimte in een zpool stoppen.
Je opmerking over het makelijker upgraden en backup'en is volkomen waar en heel slim voor de SOHO gebruiker.

[riwi]

tvwes schreef op woensdag 22 april 2015 @ 12:24:
De zin die je aanhaalt en de conclusie die je trekt hebben niets met elkaar te maken. En de conclusie lees ik ook niet in het artikel.
Laatste poging om het uit te leggen en dan zal ik er over op houden
In de zin die je aanhaalt staat dat door compressie je er niet vanuit kan gaan dat de gecomprimeerde data precies in je RAIDZ vdev stripe past.

Ik heb geen conclusie getrokken. Alleen vertaald wat in de post van Matt staat.
Met vaste 128kB records size zou een 2^n+p disk aanbeveling zin kunnen hebben. Met compressie actief niet. En ik schreef "geen voordeel" omdat ik dat bedoelde en niet 'nadeel' impliceerde

tvwes schreef op woensdag 22 april 2015 @ 12:24:
Het is Illumos.

Inderdaad Vage benaming. Na de overname van Sun door Oracle doe ik weinig meer met Solaris of de afgeleiden.

tvwes schreef op woensdag 22 april 2015 @ 12:24:
Dat is de doelstellling van OpenZFS om vanuit een gemeenschappelijke codebase (die van Illumos) ports te maken naar andere platforms. Dit is efficient en voorkomt veel fouten. Het is alleen jammer dat er zo weinig resources (betalende mensen om ontwikkelaars te betalen) zijn om allerlei leuke features die al lang af zijn te porten naar OpenZFS.

LLNL voor ZoL is wel behoorlijk groot (5000 man en US defense budget). Maar niet veel ontwikkelaars voor ZFS.

tvwes schreef op woensdag 22 april 2015 @ 12:24:
Het is kwestie van testen. Het kan wat ruimte opleveren het kan ook ruimte kosten door niet volle blokken.

Kan jij een goede beschrijving (soort bestanden en filesizes) geven van de inhoud van je zpool. Alsmede de output posten van
zpool get all [zpool name]
zfs get all [zpool/zfs/met films of bulk van je data]
zdb | grep ashift

Dan ik kijken hoe de ruimte nu benut wordt, qua efficiency.

Ik wil er gewoon mee spelen. Dan zie ik wel of het wat voor me is.
ashift staat op 12. Dat kan ook niet anders met 4k sector disks.
Serie files zijn vrijwel altijd groter dan 1.5GB tot 15GB per aflevering en films meestal tussen 25 en 45 GB. Nu bestaan bluray folders uit een (fors) aantal kleinere bestanden, maar die remux ik vaak tot een groot 30GB bestand. Nu staan er tussen de bestanden ook jpg en bmp bestanden alsmede 1 txt per entry als artwork en sturing daarvan.

<snip lange printouts>

tvwes schreef op woensdag 22 april 2015 @ 12:24:
Lijkt we een prima en weloverwogen keuze voor jouw gebruik. Ik adviseer ook vaak om meerdere zpool's aan te maken ipv 1 gigantische pool. Een zpool met veel vdevs of schijven erin heb je nodig voor veel iops, bandbreedte,een namespace met veel opslag of grote zvol's

Groot voordeel is ook dat ik zo 10 disks uit de PC kan trekken en in een andere PC kan zetten. Ik bedoel 40TB moven van de ene naar de andere PC kan via netwerk nooit zo snel als fysiek de disks verplaatsen.
( leuke anecdote : IP over Avian : https://tools.ietf.org/html/rfc2549 )

Dus het is voornamelijk manageability die deze keuze heeft bepaald.

[ Voor 246% gewijzigd door riwi op 27-04-2015 11:45 ]

[Paul]

Thuis heb ik een FreeNAS-machine draaien met meer dan genoeg geheugen. Echter, ik wil graag (een deel van) mijn data off-site repliceren in geval van brand of diefstal van mijn NAS. Mijn zwager heeft ESX draaien op een servertje bij hem thuis en ik heb nog een harddisk over. Match made in heaven zou je zeggen alleen heeft die ESX-host niet zo heel veel RAM.

Iedereen gaat er bij alle berekeningen vanuit dat het NAS gebruikt gaat worden voor file access en heftige random reads, ik kan echter niet vinden wat ZFS (of FreeNAS) nodig heeft als het alleen maar aan het ZFS Receive'n is. Momenteel is de server idle (zelfs nog geen pool gedefinieerd) en wordt er 780 MB gebruikt waarvan 150 MB voor de ARC. Ter vergelijk, de server thuis gebruikt 61 GB waarvan 44 GB ARC.

Ik kom wel topics uit 2011 tegen waar mensen aangeven dat 4 of zelfs 2 GB voor een thuis-server met lage load voldoende is, maar veruit de meeste mensen zeggen 'don't be a special snow flake en neem minimaal 8 GB als je data je lief is'

Hoeveel RAM heeft een FreeBSD-machine die enkel aan ZFS Receive doet nodig?

[CurlyMo]

Ik denk dat dit voldoende antwoord voor je is:
CurlyMo in "Het grote ZFS topic"
CurlyMo in "Het grote ZFS topic"

Het betreft dus een DualCore ARM bordje met 1GB aan RAM. De backup pool heeft dedup en lz4 compressie aanstaan.

[ Voor 10% gewijzigd door CurlyMo op 26-04-2015 10:54 ]

[tvwes]

Paul schreef op zondag 26 april 2015 @ 10:37:
Thuis heb ik een FreeNAS-machine draaien met meer dan genoeg geheugen. Echter, ik wil graag (een deel van) mijn data off-site repliceren in geval van brand of diefstal van mijn NAS. Mijn zwager heeft ESX draaien op een servertje bij hem thuis en ik heb nog een harddisk over. Match made in heaven zou je zeggen alleen heeft die ESX-host niet zo heel veel RAM.

Iedereen gaat er bij alle berekeningen vanuit dat het NAS gebruikt gaat worden voor file access en heftige random reads, ik kan echter niet vinden wat ZFS (of FreeNAS) nodig heeft als het alleen maar aan het ZFS Receive'n is. Momenteel is de server idle (zelfs nog geen pool gedefinieerd) en wordt er 780 MB gebruikt waarvan 150 MB voor de ARC. Ter vergelijk, de server thuis gebruikt 61 GB waarvan 44 GB ARC.

Ik kom wel topics uit 2011 tegen waar mensen aangeven dat 4 of zelfs 2 GB voor een thuis-server met lage load voldoende is, maar veruit de meeste mensen zeggen 'don't be a special snow flake en neem minimaal 8 GB als je data je lief is'

Hoeveel RAM heeft een FreeBSD-machine die enkel aan ZFS Receive doet nodig?

Mijn inschatting is dat het prima zal werken voor dit specifieke geval. Maar ik heb ook een aantal oude ZFS servers met 2x2GB ram als NAS voor oa ESXi. Dat waren allround ZFS servers en zelfs dat werkte prima. De ram is alleen verplicht bij dedup en bij snelle netwerken. Voor de rest is het een cache. Waar jij in deze write only use case nauwelijks gebruik van maakt. Hou je FreeBSD lean and mean. Ook wil ik je wijzen op een post die ik een aantal weken terug hier plaatste aan @jacovn. Die liet het nut van mbuffer zien bij zfs send/recv. Nu was dat een 10gbit netwerk maar ook voor wan heb ik er goede ervaring mee. Hou de unix filosofie in het achterhoofd, veel kleine programmaatjes die samenwerken. Bijv deze oneliner: zfs send | [compressor] | mbuffer | ssh (zonder compressie) [e-mail] 'mbuffer | [decompressor] | zfs recv'
De (de)compressor is optioneel en er is tal van keuze. Voor ssh zou je de encrypty kunnen verlagen naar arcfour bijv.

Even testen en je hebt zo wat settings die voor jouw werking. Je ram kan je zo verhogen indien nodig.

[Paul]

tvwes schreef op zondag 26 april 2015 @ 10:55:

CurlyMo schreef op zondag 26 april 2015 @ 10:52:

Tnx voor de bevestiging

Ik ga gewoon de mechanismen gebruiken die FreeNAS in de GUI aanbiedt, sowieso is de upload aan de bron maar 6 mbit/s of zo, en zo hoef ik niet bang te zijn dat ik alles opnieuw in mag gaan stellen bij een update

[Houston3]

Ik heb een nas draaien op Freenas met daarin 3 pools. Een voor movies, een voor TV en een voor overige.

Met CIFS heb ik alle geshared zodat ik uit windows alles kan managen. De share Movies en TV werken dan ook prima, maar de overige share heeft onder CIFS dezelfde instellingen maar als ik vanuit windows die share benader dan mag ik niet schrijven, ondanks dat ik in Freenas wel die rechten heb.

Iemand enig idee hoe ik dit kan oplossen, de share mag zonder wachtwoord te benaderen zijn.

[FireDrunk]

Post je smb.conf eens.

[Houston3]

Hoe kan ik dat doen? Ik ben niet echt bekend met Unix.

[FireDrunk]

Inloggen via ssh

cat /usr/local/samba/smb.conf

Of

cat /etc/samba/smb.conf

Weet even niet meer waar hij staat.

[blobber]

Als het goed is, staat hij hier: /usr/local/etc/smb.conf

[FireDrunk]

Die dus, thanks voor de opheldering

[Houston3]

Ik krijg bij alle 3 de opties no such file or directory.

[blobber]

Probeer /usr/local/etc/smb4.conf

[CurlyMo]

Of gelijk de duurbare oplossing:

code:

find /usr -name smb*.conf

[tvwes]

$ man find

lezen ....

en dan ...

$ find / -type f -name 'smb.conf'
of als je denkt dat je onvoldoende rechten hebt
$ sudo find / -type f -name 'smb.conf'

en als je een index hebt zou je daarin eerst kunnen zoeken. Gebruik maar find dat levert het betrouwbaarste antwoord op.

[Houston3]

Met die van Blobber lukte het wel.

code:

[global]
    server max protocol = SMB2
    encrypt passwords = yes
    dns proxy = no
    strict locking = no
    oplocks = yes
    deadtime = 15
    max log size = 51200
    max open files = 232094
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    getwd cache = yes
    guest account = nobody
    map to guest = Bad User
    obey pam restrictions = yes
    directory name cache size = 0
    kernel change notify = no
    dfree command = /usr/local/libexec/samba/dfree
    panic action = /usr/local/libexec/samba/samba-backtrace
    nsupdate command = /usr/local/bin/samba-nsupdate -g
    server string = FreeNAS Server
    ea support = yes
    store dos attributes = yes
    hostname lookups = yes
    time server = yes
    acl allow execute always = true
    acl check permissions = true
    dos filemode = yes
    multicast dns register = yes
    domain logons = no
    local master = yes
    idmap config *: backend = tdb
    idmap config *: range = 90000001-100000000
    server role = standalone
    netbios name = FREENAS
    workgroup = WORKGROUP
    security = user
    pid directory = /var/run/samba
    smb passwd file = /var/etc/private/smbpasswd
    private dir = /var/etc/private
    create mask = 0666
    directory mask = 0777
    client ntlmv2 auth = yes
    dos charset = CP437
    unix charset = UTF-8
    log level = 1


[Movies]
    path = /mnt/Movies.1
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    recycle:repository = .recycle/%U
    recycle:keeptree = yes
    recycle:versions = yes
    recycle:touch = yes
    recycle:directory_mode = 0777
    recycle:subdir_mode = 0700
    vfs objects = zfsacl
    hide dot files = yes
    guest ok = yes
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare


[TV]
    path = /mnt/Tv.1
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    recycle:repository = .recycle/%U
    recycle:keeptree = yes
    recycle:versions = yes
    recycle:touch = yes
    recycle:directory_mode = 0777
    recycle:subdir_mode = 0700
    vfs objects = zfsacl
    hide dot files = yes
    guest ok = yes
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare


[Videos]
    path = /mnt/Videos.1
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    recycle:repository = .recycle/%U
    recycle:keeptree = yes
    recycle:versions = yes
    recycle:touch = yes
    recycle:directory_mode = 0777
    recycle:subdir_mode = 0700
    vfs objects = zfsacl
    hide dot files = yes
    guest ok = yes
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare

[FireDrunk]

Met de 'overige' share die niet werkte, bedoel je dus [Videos] ?

Wat zijn de rechten van die directory?

ls -lah /mnt/Videos.1

[riwi]

Aangezien de setting "map to guest = Bad User" er staat zal er als een 'onbekende user' toegang wil, samba altijd de guest user gebruiken. Dus dan inderdaad een ls -al op de 3 directories met media en dat met chmod en chown recht zetten.

[Houston3]

De overige share is idd Videos.

@Riwi, correct me if im wrong, maar ik heb het idee dat dat deel betrekking heeft op alle shares, waarvan er 2 probleemloos werken. Overigens heb ik die ls -lah ook geprobeerd op movies.1 en daar valt op dat die andere rechten heeft: drwxrwxrwx

code:

[root@freenas] ~# ls -lah /mnt/Videos.1
total 14
drwxrwxr-x+ 3 root  wheel     4B Apr 29 19:10 ./
drwxr-xr-x  5 root  wheel   160B Apr  1 21:28 ../
-rw-r--r--  1 root  wheel     0B Apr 29 19:10 .windows
drwxrwxr-x  2 root  wheel     2B Feb 19 11:55 Concerts/

[riwi]

Dat is ook zo. En dat is ook een goede setting die minder snel user / rights problemen zal veroorzaken.
Gebruik ik zelf ook.
misschien ter vergelijking ook /mnt/Tv.1 printen ?
Dan vergelijken waar de rwx'en staan. En om te zien of onder /mnt/Tv.1 ook alles van root:wheel is

[ Voor 12% gewijzigd door riwi op 30-04-2015 13:34 ]

[FireDrunk]

./ is de lokale directory en die staat dus zoals je ziet op drwxrwxr-x (775)
movies.1 heeft drwxrwxrwx (777 ).

Het laatste getal is de rechten voor de anonoymous user (zoals samba).

7 = alles
5 is alleen lezen.

Het klopt dus dat je er niet bij kan

[CurlyMo]

Afhankelijk natuurlijk wat er allemaal aan ACL's zijn geconfigureerd. Er staat een plus achter. Wat zegt dus:

code:

getfacl /mnt/Videos.1

[FireDrunk]

Goed punt, daar keek ik even over heen!

[Houston3]

@Riwi, Tv.1 heeft ook drwxrwxrwx.

@CurlyMo en Firedrunk.

code:

[root@freenas] ~# getfacl /mnt/Videos.1
# file: /mnt/Videos.1
# owner: root
# group: wheel
            owner@:rwxpDdaARWcCos:fd----:allow
            group@:rwxpDdaARWcCos:fd----:allow
         everyone@:r-x---a-R-c---:fd----:allow

en voor vergelijk ook Tv.1

[root@freenas] ~# getfacl /mnt/Tv.1
# file: /mnt/Tv.1
# owner: root
# group: wheel
            owner@:rwxp--aARWcCos:------:allow
            group@:r-x---a-R-c--s:------:allow
         everyone@:r-x---a-R-c--s:------:allow

[riwi]

Ik zou dat missende w'tje gewoon toevoegen :
chmod -R 777 /mnt/Videos.1

De -R doet het dus ook op alle onderliggende folders

[FireDrunk]

Die ACL's die je ziet zijn dus NFSv4 ACL's.
Wel duidelijk verschillend.

Heb je in FreeNAS zelf ACL's aangezet, of was dat default? Want dat maakt je leven niet per definitie makkelijker

[ Voor 63% gewijzigd door FireDrunk op 30-04-2015 14:08 ]

[CurlyMo]

Ik vind het opvallender dat Videos.1 als folder wordt aangemerkt en Tv.1 niet. Even een:

code:

ls -Al /mnt

[Houston3]

@riwi, die chmod lost het probleem niet op.

code:

[root@freenas] ~# ls -Al /mnt
total 22
drwxr-xr-x   5 root  wheel  160 Apr  1 21:28 ./
drwxr-xr-x  19 root  wheel   28 Apr  1 21:12 ../
drwxr-xr-x   4 root  wheel    4 Apr  2 15:33 Movies.1/
drwxr-xr-x   3 root  wheel    3 Feb 12 18:25 Tv.1/
dr-xrwxrwx   3 root  wheel    4 Apr 29 19:10 Videos.1/
-rw-r--r--   1 root  wheel    5 Apr  1 21:03 md_size

[CurlyMo]

Als welke gebruiker / groep probeer je in te loggen via samba?

[ Voor 6% gewijzigd door CurlyMo op 30-04-2015 14:28 ]

[Houston3]

Dat kunnen verschillende gebruikers zijn, Administrator, Ramon en mn raspberry pi logt ook in, ik denk als ''Pi''.

[CurlyMo]

Tot welke groep(en) horen die gebruikers?

[Houston3]

binnen windows tot de administrator groep, in freenas bestaan ze niet omdat ik daar anonymous toegang toe wil staan.

[riwi]

precies . En daar is die mapping setting voor die "bad User" naar guest mapped

[Houston3]

Met nog wat gegoogle op de bad user kwam ik op het volgende

code:

chomd -R a+rX /mnt/Videos.1

nu heb ik wel schrijfrechten op Videos.1 Vanavond even proberen of openelec dit ook accepteert allemaal.
Of iemand moet zeggen dat ik dit absoluut niet moest doen, dan hoor ik het ook graag

[CurlyMo]

Precies het chmod command van riwi dus

[Houston3]

Ter lering ende vermaek. Chmod -R 777 is een representatie van chmod -R a+rX ? Want 777 pakte hij niet.

[riwi]

da's vreemd. Of heb je echt Chmod getyped met grote C ?

[CurlyMo]

Niet letterlijk exact hetzelfde.
-R: Recursief
a+: Alle gebruikers
r: lees rechten
X: uitvoer rechten (ook nodig om de inhoud van folder te zien) voor specifiek folders (en niet bestanden).

Dus om precies te zijn hetzelfde als:

code:

find /mnt/Videos.1 -type d -exec chmod 777 \;

Als je een x had gebruikt, dan was het wel exact hetzelfde geweest als chmod -R 777

[Houston3]

Ok helder. Ben iig blij dat het nu opgelost is, kan ik mn duikvideos en concerten tenminste kwijt

@Riwi, ik had wat jij poste 1:1 gekopieerd naar ssh, maar geen idee waarom het niets deed.

[riwi]

dat snap ik dan ook niet
Het zal een van de fijnere verschilletjes zijn tussen FreeBSD en de Linux waar ik bekend mee ben.
Mooi dat het werkt.

[wopie]

Ik heb op het moment op m'n esxi -server een zfsguru installatie draaien waar ik middels VT-D de onboard sas-controller heb ge-pass-trough-ed (supermicro x10sl7-f). Nu heb ik hier files etc op staan die door ZFS in leven gehouden worden.
Ik wil nu graag offsite-backup gaan doen, maar vraag me af hoe ik dit low-power/low-budget kan doen.

Destijds heb ik voor een all-in-one oplossing gekozen omdat ik toch een dikke vm-server wou gebruiken voor spielerij etc. en ZFS voor het healthy houden van m'n dierbare data (foto's/video's met name). Ik vond het na wat leeswerk verstandig om als ik dan toch middels VT-D ging passtrough'en een fatsoenlijk server-board te kopen die dan ook gelijk ECC ondersteund.

Nu dus nog de offsite backup. ZFS-send/receive lijkt me een ideale oplossing (1-op-1 kopie van mn data) om de data intact over te krijgen. Wat is nu de overweging om offsite een mirror vs single-disk (dan mis je toch je ZFS-bescherming) te gebruiken (Curlymo gebruikt er voor zover ik weet 1tje)? En waarom zou je hier zonder ECC af kunnen/willen?

[FireDrunk]

ECC is altijd beter, maar je hebt liever 1 kapotte file vanwege geheugen fouten, dan helemaal geen backup...

Low-Budget offsite backup klinkt idd als een rPi met een diskje er aan...

Je hoeft overigens niet perse ZFS actief te draaien, je kan zfs send ook pipen naar een file.
Dan kan je die file offsite opslaan, en mocht je hem nodig hebben, herinstalleer je je machine en pipe je de file naar zfs receive.

(niet de mooiste oplossing, maar het kan).

[CurlyMo]

wopie schreef op donderdag 30 april 2015 @ 15:41:
Nu dus nog de offsite backup. ZFS-send/receive lijkt me een ideale oplossing (1-op-1 kopie van mn data) om de data intact over te krijgen. Wat is nu de overweging om offsite een mirror vs single-disk (dan mis je toch je ZFS-bescherming) te gebruiken (Curlymo gebruikt er voor zover ik weet 1tje)? En waarom zou je hier zonder ECC af kunnen/willen?

Kosten / prestatie. ZFS weet wanneer er een bestand corrupt is geraakt maar kan het niet zelf oplossen met een enkele disk. Als dat zo is, dan stuur ik dat betreffende bestand opnieuw naar de backup óf ik wissel de offsite backup om met mijn lokale backup. Van de offsite en lokale backup is de layout precies hetzelfde dus dan kan de offsite backup weer verder terwijl ik de corruptie lokaal oplos.

FireDrunk schreef op donderdag 30 april 2015 @ 15:55:
Je hoeft overigens niet perse ZFS actief te draaien, je kan zfs send ook pipen naar een file.
Dan kan je die file offsite opslaan, en mocht je hem nodig hebben, herinstalleer je je machine en pipe je de file naar zfs receive.

Alleen mis je dan de voordelen van een incremental send.

[FireDrunk]

@CurlyMo, klopt, maar je kan toch zelf delta's maken tussen twee snapshots?

[wopie]

Zou je ook in je offsite backup (single-disk) middels extra ditto-blocks toch hetzelfde kunnen doen als een mirror en zo beschermd zijn tegen bit-rot maar niet tegen disk-uitval uiteraard?

Zou natuurlijk mooi zijn als dit kan, mirror voor levende data, offsite backup zekeren middels extra parity. Kan ZFS -send/receive dit on the fly doen (blocks toevoegen zeg maar) of is het iets wat ik dan al op mijn mirror zou moeten instellen.

[CurlyMo]

wopie schreef op donderdag 30 april 2015 @ 16:11:
Zou je ook in je offsite backup (single-disk) middels extra ditto-blocks toch hetzelfde kunnen doen als een mirror en zo beschermd zijn tegen bit-rot maar niet tegen disk-uitval uiteraard?

Zou natuurlijk mooi zijn als dit kan, mirror voor levende data, offsite backup zekeren middels extra parity. Kan ZFS -send/receive dit on the fly doen (blocks toevoegen zeg maar) of is het iets wat ik dan al op mijn mirror zou moeten instellen.

Simpelweg de kans uitrekenen dat toevallig je huis afbrandt of alles gestolen wordt én dat er opeens bitrot optreedt op de schijf terwijl je de backup terug zet.

---

FireDrunk schreef op donderdag 30 april 2015 @ 16:07:
@CurlyMo, klopt, maar je kan toch zelf delta's maken tussen twee snapshots?

Wist je dat ik daar nog nooit over nagedacht had

[ Voor 15% gewijzigd door CurlyMo op 30-04-2015 16:21 ]

[wopie]

CurlyMo schreef op donderdag 30 april 2015 @ 16:13:
[...]

Simpelweg de kans uitrekenen dat toevallig je huis afbrandt of alles gestolen wordt én dat er opeens bitrot optreedt op de schijf terwijl je de backup terug zet.

Ik denk dan, ik heb lokaal backup van +/-50GB, remote een pool van 160GB, waarom zou ik die space niet gebruiken voor ditto-blocks? De pool houd zich zo toch in stand?

Ik snap dat de kans klein is, maar de penalty mijn inziens ook (aangezien ik remote de ruimte niet nodig heb).

Kan het technisch wel (ik weet nog te weinig van ZFS -send/receive, moet me hier nog verder over inlezen)?

[tvwes]

Je kan de incrementals ook prima naar een file schrijven. Je moet alleen een hele goede administratie voeren. En je moet al je incrementals bewaren en die stuk voor stuk restoren, als een journal replay. Bij een echte ZFS send/receive kan je wel zaken tussen tijds opruimen en heb je de zekerheid dat het echt aanwezig is op het andere systeem, je kan echt de files zien.

Je kan zfs send inderdaad naar een file pipen. Houd er rekening mee dat als er ook maar iets corrupt raakt aan de file je geen restore kan uit voeren! Je gaat de stream tussen zfs send en receive afvangen en naar een file sturen. Alleen heeft deze stream geen enkele bescherming of redundantie. Als je dit doet maak dan wat par blokken aan en splits de file in stukken van 50-250mb. Dat maakt uploaden naar een cloud dienst bijvoorbeeld makkelijker.

Als je offsite (bij familie of vrienden) een apparaat wil/mag neerzetten. Dan kan je echt zfs send en receive doen en is er meer mogelijk. Zelf heb ik oplossingen gemaakt op basis van de bijv een tijdschakelklok en de bios instelling resume after power loss. En sommige bios hebben zo'n timer om het systeem mee wakker te maken. Niet zo low power je rPi maar wel meer sata poorten en veel meer mogelijkheden.

[tvwes]

wopie schreef op donderdag 30 april 2015 @ 16:32:
[...]


Ik denk dan, ik heb lokaal backup van +/-50GB, remote een pool van 160GB, waarom zou ik die space niet gebruiken voor ditto-blocks? De pool houd zich zo toch in stand?

Wat bedoel je? Ik denk dat je eerst even moet doen wat je zelf al schreef in je laatste zin.

Ik snap dat de kans klein is, maar de penalty mijn inziens ook (aangezien ik remote de ruimte niet nodig heb).

Die kans is heel GROOT veel groter dan dat je harddisk kapot gaat.

Hier komen de getallen:
cbs statline Woningvoorraad naar eigendom; regio, 2006-2012
totale woningvoorraad 2012: 7266295 woningen

cbs, brandweerstatistiek 2012
aantal branden 2012: 14400 binnenbranden

De berekening laat ik aan de lezer over. Maar de kans op een woningbrand was in 2012 helemaal niet klein. Even zoeken je hebt de feiten erbij.

Kan het technisch wel (ik weet nog te weinig van ZFS -send/receive, moet me hier nog verder over inlezen)?

[wopie]

[quote]tvwes schreef op donderdag 30 april 2015 @ 16:52:
[...]

Wat bedoel je? Ik denk dat je eerst even moet doen wat je zelf al schreef in je laatste zin.

[...]

Ik bedoel:

Ik heb thuis een esxi-all-in-one waarbinnen ik ZFS draai op een mirror van 2 disken (2TB) middels zfsguru, hierop staan op verschillende filesystems data, de een belangrijker als de andere.
Mijn kritieke data (foto's/video's fam etc) wil ik graag offsite backuppen om te beschermen tegen random-ramp. Nu is mijn kritieke data (filesystem(s)) +/-50GB groot.

Remote (andere familielid) heb ik een freebsd-machine met 160GB pool ter beschikking op slechts 1 disk.

Nu is mijn gedachte dmv extra ditto-blocks ervoor te zorgen dat mijn remote pool zichzelf in stand kan houden bij een scrub en wat omgevallen bitjes. De penalty is dat de data dubbel wordt opgeslagen, maar aangezien mijn backup niet zo groot is zal ik hier voorlopig niet tegen grenzen aanlopen (uiteraard afhankelijk van groei).

Nou weet ik alleen niet of je van een "non" ditto-block filesystem (op mijn thuis NAS) middels ZFS send/receive op de remote NAS naar een ditto-block == 2 kunt gaan, of dat zfs send/receive letterlijk een kopie is en de data "as-is" overgezet wordt zonder evt bewerkingen erop.

[CurlyMo]

De zfs data wordt aangepast aan wat de ontvangende kant wil hebben. Niet gecomprimeerde data wordt gecomprimeerd, niet gededupliceerde (wat een woord) data wordt gededupliceerd enz.

[tvwes]

wopie schreef op donderdag 30 april 2015 @ 17:18:
Nou weet ik alleen niet of je van een "non" ditto-block filesystem (op mijn thuis NAS) middels ZFS send/receive op de remote NAS naar een ditto-block == 2 kunt gaan, of dat zfs send/receive letterlijk een kopie is en de data "as-is" overgezet wordt zonder evt bewerkingen erop.

Mmm dat is een leuke, wat je denk ik bedoeld is de optie copies=N. Deze kan je tijdens het aanmaken of naderhand instellen. In dat laatste geval geld dit alleen voor nieuwe data.
De feature die jij zoekt is wel aanwezig in Oracle ZFS maar niet in OpenZFS.
Je kan niet bij het ontvangen de Copies=N property veranderen in 2.
Er zijn wel voorstellen gedaan maar het is nooit tot een RTI gekomen.

aanvulling:
Als je aan de ontvangende kant de parent van de destination wel copies=2 instelt zou het via inheritance goed moeten gaan. Bijvoorbeeld:
zfs create -o copies=2 destpool/backup
zfs send sourcepool/myPron@snappie | zfs receive destpool/backup/myPron@snappie
dit kan je checken met zfs get copies destpool/backup/myPron

Ik heb een en ander met zdb nagekeken en inderdaad bovenstaande oplossing werkt. Ik zie inderdaad keurig van alles twee blokken verschijnen. Mocht er belangstelling zijn voor heel veel cryptische output van zdb dan hoor ik het wel.

@wopie, Heb je de kans op een binnenbrand even uitgerekend?

[ Voor 25% gewijzigd door tvwes op 30-04-2015 20:44 ]

[wopie]

tvwes schreef op donderdag 30 april 2015 @ 17:33:
[...]

Mmm dat is een leuke, wat je denk ik bedoeld is de optie copies=N. Deze kan je tijdens het aanmaken of naderhand instellen. In dat laatste geval geld dit alleen voor nieuwe data.
De feature die jij zoekt is wel aanwezig in Oracle ZFS maar niet in OpenZFS.
Je kan niet bij het ontvangen de Copies=N property veranderen in 2.
Er zijn wel voorstellen gedaan maar het is nooit tot een RTI gekomen.

aanvulling:
Als je aan de ontvangende kant de parent van de destination wel copies=2 instelt zou het via inheritance goed moeten gaan. Bijvoorbeeld:
zfs create -o copies=2 destpool/backup
zfs send sourcepool/myPron@snappie | zfs receive destpool/backup/myPron@snappie
dit kan je checken met zfs get copies destpool/backup/myPron

Heb je de kans op een binnenbrand even uitgerekend?

Je hebt iets met vuur of niet? (ik betaal "achter de dijk" -belasting ), als ik goed google 1 op 65.
De opmerking dat ik snap dat de kans klein is slaat niet op de woningbrand, maar aan de combinatie woningbrand waarbij mn zfs-bak afbrand en daarnaast op dat moment bitrot onstaat op een single-disk offsite backup.

Mijn ZFSGuru pool-versie betreft versie 5000 (FreeBSD 10.0 stable als basis), ik kan in de webinterface aangeven dat ik 2 of 3 ditto-blocks wil gebruiken voor een filesystem.

Dankjewel voor je aanvulling (een voorbeeldje van je eigen script gebruikt? ), ik zal eens testen binnenkort.

[tvwes]

wopie schreef op donderdag 30 april 2015 @ 20:59:
[...]
Je hebt iets met vuur of niet?

Nee, ik heb iets met kansberekening en statistiek. Een onderwerp waar weinig mensen hier echt kaas van hebben gegeten.

(ik betaal "achter de dijk" -belasting ), als ik goed google 1 op 65.

Als ik (7266295 / 14400) intoets op een rekenmachine dan lees ik 1 op 505 af. Maar misschien kan jij nog even uitleggen hoe je bij een kans van 1 op 65 komt.

De opmerking dat ik snap dat de kans klein is slaat niet op de woningbrand, maar aan de combinatie woningbrand waarbij mn zfs-bak afbrand en daarnaast op dat moment bitrot onstaat op een single-disk offsite backup.

Sorry, dat had ik verkeerd begrepen. (Ik zie het nog steeds niet helemaal staan) Maar die kans is inderdaad heel klein. Maar bij een kans van 1 op 65 op een woningbrand is de kans dat je de backup ook verliest door brand niet verwaarloosbaar

Mijn ZFSGuru pool-versie betreft versie 5000 (FreeBSD 10.0 stable als basis), ik kan in de webinterface aangeven dat ik 2 of 3 ditto-blocks wil gebruiken voor een filesystem.

Grappig ik vroeg me al af hoe je aan die term ditto blocks was gekomen. Dat ze dat in de UI ditto blocks noemen terwijl zelfs de man page het heeft over copies=N. Nu wordt in een klikklik applicatie jargon gebruikt terwijl de het onderwater gewoon copies heet.
Ik verwacht weinig problemen mbt de zpool versie. Ik heb het zojuist in een oude v28 getest. Als sender en receiver enigzins overkomen zou dit zonder problemen moeten werken.

Dankjewel voor je aanvulling (een voorbeeldje van je eigen script gebruikt? ), ik zal eens testen binnenkort.

Ik dacht laat ik maar een voorbeeld gebruiken wat de meeste hier snappen.

[tvwes]

Nog even voor de liefhebber en kan mn terminal dicht. Hieronder de output voor copies=2 van een simple text file op een nieuw fs.

code:

tvwes@oistor1:/$ zdb -dddddd single | tail -n 30

Indirect blocks:
               0 L0 EMBEDDED et=0 200L/1dP B=4

                segment [0000000000000000, 0000000000000200) size   512

    Object  lvl   iblk   dblk  dsize  lsize   %full  type
         8    1    16K    512     1K    512  100.00  ZFS plain file (K=inherit) (Z=inherit)
                                        168   bonus  System attributes
        dnode flags: USED_BYTES USERUSED_ACCOUNTED
        dnode maxblkid: 0
        path    /copies.txt
        uid     0
        gid     0
        atime   Thu Apr 30 21:23:52 2015
        mtime   Thu Apr 30 21:37:03 2015
        ctime   Thu Apr 30 21:37:03 2015
        crtime  Thu Apr 30 21:23:52 2015
        gen     226
        mode    100644
        size    14
        parent  4
        links   1
        pflags  40800000004
Indirect blocks:
               0 L0 0:4b600:200 0:4b800:200 200L/200P F=1 B=384/384

                segment [0000000000000000, 0000000000000200) size   512

Verified large_blocks feature refcount is correct (0)
tvwes@oistor1:/$ zdb -R single 0:4b600:200
Found vdev: /mpool/nocomp/disk0

0:4b600:200
          0 1 2 3 4 5 6 7   8 9 a b c d e f  0123456789abcdef
000000:  7372656b61657774  00000a776f63200a  tweakers. cow...
000010:  0000000000000000  0000000000000000  ................
<snip>
tvwes@oistor1:/$ zdb -R single 0:4b800:200
Found vdev: /mpool/nocomp/disk0

0:4b800:200
          0 1 2 3 4 5 6 7   8 9 a b c d e f  0123456789abcdef
000000:  7372656b61657774  00000a776f63200a  tweakers. cow...
000010:  0000000000000000  0000000000000000  ................
<snip>

Het eerste commando haalt wat info op over de file copies.txt.
In de laatste regel van de output kan je de twee dva adressen vinden.
Daarna lees ik de twee dva adressen uit. En zie dat beide adressen hetzelfde bevatten.

[HyperBart]

Zo, net weer wat liggen stoeien met de disks, mijn spiegeltje bestaande uit 2 x 2TB (met die rotte Seagates, failure rate skyhigh) is ondertussen een enkeltje geworden, en voorzien van de laatste ZFS snapshotjes.

Op de juggernaut pool is ondertussen weer een verzamelingetje snapshotjes bijgekomen, ook weer fijn voor versies te houden, en die staan ook weer op spiegeltje en COLDBACKUP, een diskje wat in de volgende dagen naar de woning van mijn ouders gaat 2 dorpen verderop.

Ik mis nog wel een fijne tool voor ZFS regelmatig te laten backuppen.

Iets à la: indien de destionation-backup-pool gemount is, doe dan telkens een incremental send receive tussen 2 snapshots van juggernaut, zend het verschil naar de backup-pool, en doe het "voorlaatste" snapshot weg.

Ik ben eens gaan stoeien met scriptjes, maar ergens along the road wel opgegeven. Ik wil eigenlijk mijn productie-pool relatief clean houden, en alleen een bepaalde set van FS'en veiligstellen...

[tvwes]

@HyperBart
er zijn veel scripts te vinden. Shell based en in diverse talen als python. Als je niks kan vinden, moet je even aangeven wat het script precies moet doen en in welke taal het moet zijn geschreven.

[CurlyMo]

Ik heb zelf hier nog een backup script geplaatst dat ik zelf gebruik.

[HyperBart]

Script mag bij voorkeur in bash, zonder dependencies van andere talen oid. Als python een paar pareltjes kan bieden, geen probleem.

Wat ik eigenlijk wil is gewoon bv maandelijks of wekelijks een backup laten trekken via een (incremental) zfs send receive naar een pool die niet altijd online is of beschikbaar, als dat een te moeilijke eis is wil ik eventueel wel een hostje opzetten bij mijn vader om daar permanent iets te hebben... Maar ik wil mijn "mai" storage pool zo "clean mogelijk" houden. Een paar snapshotjes, maar niet de hele waslijst van vroeger van alle backups...

[CurlyMo]

Heb je dus al gekeken naar mijn scripts in dit topic?

[XhaiKhaL]

Is het ook mogelijk om ZFS in een soort JBOD setup te draaien (met 2 of 3 HDD's) als performance niet belangrijk is (ben bang van niet aangezien uitbreiden van de pool ook niet mogelijk is las ik)? Ik zoek namelijk naar een manier om alle opslagcapaciteit maximaal te benutten maar toch niet ál je data kwijt te raken bij het uitvallen van één schijf (zoals bij RAID0 wel het geval is door striping).

Momenteel heb ik een 2x 3TB spanned volume in Windows 7 en volgens mij is het wel mogelijk data terug te halen in geval van één defecte schijf (hoewel het internet ook niet heel duidelijk is hoe dat dan zou moeten en welke software dat zou kunnen). Bovendien ben je erg flexibel als je uit wilt breiden, je stopt er gewoon een schijf bij en stopt hem in het spanned volume. Naar deze flexibiliteit (makkelijk uitbreiden) en het niet verliezen van alle data bij een defecte schijf zoek ik.

Dan zou je zeggen blijf lekker bij het spanned volume, echter ik heb het idee dat aan deze setup een zeer groot nadeel kleeft: als de HDD's idle zijn en in slaap stand staan en er dan data van de tweede HDD opgevraagd wordt, wordt eerst de eerste HDD opgespind en zodra die draait wordt de tweede schijf pas opgespind. Erg inefficiënt en bovendien erg slecht voor de eerste schijf (die heel vaak voor niks ontwaakt wordt).

[FireDrunk]

Ik zou zelf JBOD maken door middel van goede mountpoints.

[tvwes]

XhaiKhaL schreef op vrijdag 01 mei 2015 @ 03:46:
Is het ook mogelijk om ZFS in een soort JBOD setup te draaien (met 2 of 3 HDD's) als performance niet belangrijk is (ben bang van niet aangezien uitbreiden van de pool ook niet mogelijk is las ik)? Ik zoek namelijk naar een manier om alle opslagcapaciteit maximaal te benutten maar toch niet ál je data kwijt te raken bij het uitvallen van één schijf (zoals bij RAID0 wel het geval is door striping).

Nee, zoiets is er niet. Een zpool kan bestaan uit een RAID0 / stripe van disks. Die samenwerken en als je er een verliest dan heb je een probleem. Het enige wat kan is wat Firedrunk ook al voorstelde is van iedere disk een eigen zpool te maken. En iedere zpool een logisch stuk van data te geven. Bijvoorbeeld de fpool met films en de mpool met mp3 en de vpool met vakantie foto's. Standaard OS'es als FreeBSD en Linux hebben geen magische software die je data transparant over de devices verdeelt maar wel op zo'n manier dat een losse device's altijd uit te lezen zijn.

Misschien is bij Windows blijven zo gek nog niet.

Dan zou je zeggen blijf lekker bij het spanned volume, echter ik heb het idee dat aan deze setup een zeer groot nadeel kleeft: als de HDD's idle zijn en in slaap stand staan en er dan data van de tweede HDD opgevraagd wordt, wordt eerst de eerste HDD opgespind en zodra die draait wordt de tweede schijf pas opgespind. Erg inefficiënt en bovendien erg slecht voor de eerste schijf (die heel vaak voor niks ontwaakt wordt).

[jvhaarst]

Ik heb iets raars, of ik snap het niet.
Op een NAS die ik over NFS share wil ik user quotas aanslingeren.
Waarschijnlijk kan de user niet checken wat zijn/haar quota is, maar dat is van later zorg.

De users bestaan dus lokaal niet, maar de id's worden wel netjes doorgegeven :

code:

sysop@scratch:~$ ls -l /scratch/data/haars001/
total 32
-rwx------  1 16825946 16777729 1134 Jan 19 23:11 arraytime.py
<SNIP>
sysop@scratch:~$ sudo zfs set userquota@16825946=100T scratch/data
sysop@scratch:~$ sudo zfs userspace scratch/data
TYPE        NAME       USED  QUOTA
POSIX User  1123      5.49K   100T
POSIX User  root      55.7K   none
POSIX User  sysop     4.44T   none
POSIX User  www-data  42.6G   none
sysop@scratch:~$ sudo zfs set userquota@16825946=200T scratch/data
sysop@scratch:~$ sudo zfs userspace scratch/data
TYPE        NAME       USED  QUOTA
POSIX User  1123      5.49K   200T
POSIX User  root      55.7K   none
POSIX User  sysop     4.44T   none
POSIX User  www-data  42.6G   none

Het lijkt er dus op dat in plaats van de uid die ik meegeef, er een redelijk random uid voor in de plaats gebruikt word, in plaats van de uid die ik meegeef.

Als ik een ander uid gebruik, gebeurt er zelfs helemaal niets:

code:

sysop@scratch:~$ sudo zfs set userquota@16912323=200T scratch/data
sysop@scratch:~$ sudo zfs userspace scratch/data
TYPE        NAME       USED  QUOTA
POSIX User  1123      5.49K   200T
POSIX User  root      55.7K   none
POSIX User  sysop     4.43T   none
POSIX User  www-data  42.6G   none
sysop@scratch:~$ sudo zfs set userquota@16912323=100T scratch/data
sysop@scratch:~$ sudo zfs userspace scratch/data
TYPE        NAME       USED  QUOTA
POSIX User  1123      5.49K   200T
POSIX User  root      55.7K   none
POSIX User  sysop     4.43T   none
POSIX User  www-data  42.6G   none

Iemand een idee hoe ik dit kan fixen ?

Het zou me namelijk nogal wat hoofdpijn schelen als ik mensen met quota's kan limiteren, in plaats van voor iedere gebruiker een aparte volume aan moet maken, en dat op alle plekken moet gaan mounten.

[tvwes]

jvhaarst schreef op vrijdag 01 mei 2015 @ 09:37:
Ik heb iets raars, of ik snap het niet.
Iemand een idee hoe ik dit kan fixen ?

Het zou me namelijk nogal wat hoofdpijn schelen als ik mensen met quota's kan limiteren, in plaats van voor iedere gebruiker een aparte volume aan moet maken, en dat op alle plekken moet gaan mounten.

Misschien eerst even vertellen welk OS en versie de NAS heeft alsmede de client.
En nfs configuratie en de exports.

[HollowGamer]

Hopelijk kan iemand mij hier verder helpen met het volgende 'dilemma'.

Ik zou graag ZFS willen runnen op mijn desktop, in combinatie met een paar 1.5/1TB HDD's.

Op dit moment heb ik op mijn beide NAS'en btrfs draaien in combinatie met Arch Linux; maar ik lees zoveel positieve(r) verhalen over ZFS dat ik het graag eens zou willen uitproberen hoe het in de praktijk werkt tegenover btrfs. Daarom wil ik het graag eerst op de desktop uit proberen.

Mijn wensen:
- Arch Linux x64
- Encryptie (dm-crypt met LUKS) voor /root
- UEFI (dual boot met Windows met Grub2

Mijn indeling:
Samsung 840 SSD

code:

EFI
/boot (schijnt nodig te zijn)
/ (encrypted)
Windows

2 á 3 HDD's 1/1.5TB's in een (dezelfde) pool/RAID: 2x RAID-1, en eentje voor de performance (/mnt/data).

Nu heb ik alle informatie al een beetje bij elkaar opgezocht, tevens is de Arch Wiki gelukkig uitgebreid.
Alleen snap ik nu niet hoe ik de schijven dien te encrypten:
Van wat ik lees moet ik Solaris-partities aanmaken i.p.v. een Linux-partitie. Deze partitie dm-crypt'en en vervolgens een ZFS pool daarop aanmaken.
Met btrfs ging dit vrij eenvoudig: mkfs.btrfs /dev/mapper/hdd1 /dev/mapper/hdd2 dev/mapper/hdd3, zoiets dus ook in ZFS?

Klopt dit? Wat is nu de beste methode?
Ik probeer mijn SSD zo weinig mogelijk de formatteren, vandaar deze vragen.

Heel erg bedankt!

[ Voor 7% gewijzigd door HollowGamer op 01-05-2015 14:09 ]

[CurlyMo]

Waarom niet FreeBSD encryptie d.m.v. Geli?

[HollowGamer]

CurlyMo schreef op vrijdag 01 mei 2015 @ 12:02:
Waarom niet FreeBSD encryptie d.m.v. Geli?

Ben nu eenmaal Linux software/omgeving gewend. Vind Arch ook het beste & fijnste werken.

[CurlyMo]

Dan zul je verrast zijn in hoeverre FreeBSD en Arch op elkaar lijken qua structuur

[FireDrunk]

Vindt je? Het blijft BSD vs Linux. Ja er is AUR vs ports, er is Pacman vs Pkg.

Maar ik denk niet dat BSD en Arch dichter bij elkaar liggen dan andere Linux distro's?

Of heb jij een andere redernatie?

[tvwes]

Waarom willen mensen toch nooit wat nieuws proberen hier? Er worden goede adviezen gegeven om toch een keer even dat andere OS te proberen. Maar nee, aparte tweaker mentaliteit. Het is toch niet dat iemand je verplicht om een bepaald OS te gebruiken of dat je een legacy app hebt die het alleen doet op RHEL4?

Het installeren van een ander OS is zo gedaan en voor alle taken, als installatie en filesharing, zijn vele howto's beschikbaar. Dus niet zo angstig en/of lui maar probeer eens iets uit, zeker als het niet een onredelijk voorstel is.

[FireDrunk]

Tegen wie is die rant gericht?

[CurlyMo]

Ik vind FreeBSD veel meer in lijn met CentOS, Red Hat, Slackware, Arch dan met Debian achtige linuxes.

Qau package manager is nauwelijks een verschil tussen pkgNG, yum, apt, pacman voor de eindgebruiker.
Met kernel doe je als eindgebruiker al helemaal niks.

Het enige echte probleem is de verschillende ELF's. Dus als je je die hard linux software wil draaien op FreeBSD. Daarnaast is het even wennen aan het stricte gebruik van /usr en /usr/local.

[HollowGamer]

tvwes schreef op vrijdag 01 mei 2015 @ 14:35:
Waarom willen mensen toch nooit wat nieuws proberen hier? Er worden goede adviezen gegeven om toch een keer even dat andere OS te proberen. Maar nee, aparte tweaker mentaliteit. Het is toch niet dat iemand je verplicht om een bepaald OS te gebruiken of dat je een legacy app hebt die het alleen doet op RHEL4?

Het installeren van een ander OS is zo gedaan en voor alle taken, als installatie en filesharing, zijn vele howto's beschikbaar. Dus niet zo angstig en/of lui maar probeer eens iets uit, zeker als het niet een onredelijk voorstel is.

Hoewel ik het 100% met je eens ben, ben ik bang dat mijn hardware (simpelweg) niet draait onder BSD. Heb bijvoorbeeld een TV-kaart die enkel werkt onder Linux. Probeer zoveel mogelijk taken/dingen te combineren, en daardoor kan ik de NAS'en bijvoorbeeld niet omgooien naar een ander OS.

Tevens doe wel degelijk iets nieuws, namelijk ZFS draaien (je zou kunnen zeggen 3% BSD).

[tvwes]

FireDrunk schreef op vrijdag 01 mei 2015 @ 14:38:
Tegen wie is die rant gericht?

Tegen veel lezers hier, maar zeker niet jij. Lees maar een paar posts terug en je ziet vanzelf wat ik bedoel.

En ja het is een oprechte aanklacht tegen bekrompenheid en luiheid. Zeker de ICT, die zich met een schrikbarend tempo ontwikkeld, is niet gebaad bij mensen met een houding van "mwha het is mij best" Je moet konstant op zoek zijn naar verbetering, van jezelf en je afgeleverde werk. Door dingen te proberen kan je de verschillen pas echt benoemen. Misschien is dat andere stuk software veel handiger. Als je niks nieuws probeert zaten we nog steeds in DOS met 640K ram.
Ik verwacht dat ook van mijn medewerkers, als die niet blijven onderzoeken zit ik straks met een club vastgeroeste maar wel aardige mensen.

[tvwes]

HollowGamer schreef op vrijdag 01 mei 2015 @ 14:55:
[...]

Hoewel ik het 100% met je eens ben, ben ik bang dat mijn hardware (simpelweg) niet draait onder BSD. Heb bijvoorbeeld een TV-kaart die enkel werkt onder Linux. Probeer zoveel mogelijk taken/dingen te combineren, en daardoor kan ik de NAS'en bijvoorbeeld niet omgooien naar een ander OS.

Tevens doe wel degelijk iets nieuws, namelijk ZFS draaien (je zou kunnen zeggen 3% BSD).

Misschien was ik te vlug en heb jij een goede reden waarom je aan een bepaald platform vast zit, maar jij had ook niet alle relevant informatie gemeld. Excuses, en vermeld voortaan dit soort dingen. Dat voorkomt de rant.

Mits je mobo het ondersteund zou je de tv kaart ook aan een vm kunnen doorgeven. Je gaat dan je storage en tv taken netjes scheiden. Nu ben ik er geen voorstander om je storage zo te virtualiseren maar het kan. Je hebt plots ook betere resource control. Als je tv kaart app op hol slaat is niet alles bijvoorbaat verloren.

[jvhaarst]

tvwes schreef op vrijdag 01 mei 2015 @ 09:51:
[...]

Misschien eerst even vertellen welk OS en versie de NAS heeft alsmede de client.
En nfs configuratie en de exports.

De check gaat niet over NFS, dit is allemaal op de NAS zelf.
Ik gebruik NAS, maar eigenlijk is gewoon een Ubuntu bak met wat schijven:

code:

sysop@scratch:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 13.10
Release:        13.10
Codename:       saucy

en

code:

sysop@scratch:~$ aptitude show libzfs2 zfsutils | grep Version
Version: 0.6.3-1~wheezy
Version: 0.6.3-1~wheezy

[tvwes]

jvhaarst schreef op vrijdag 01 mei 2015 @ 15:26:
[...]


De check gaat niet over NFS, dit is allemaal op de NAS zelf.

Dank je wel. Kan je nog even $cat /etc/exports posten? Alsmede $ sudo zfs get all scratch/data

Afhankelijk hoe de client zich identificeert maakt NFS wel degelijk uit.

[FireDrunk]

Ubuntu 13.10 ja?

Dat is het nieuwe XP onder de Linux versies?

[ Voor 8% gewijzigd door FireDrunk op 01-05-2015 16:02 ]

[HyperBart]

Stel dat je tijdens een scrub een fout tegenkomt, krijg je daar dan ergens een melding van in een log?

Wat gebeurt er eigenlijk als je een fout krijgt (die zichtbaar is via de counters van zpool status) en er wordt een scrub gestart?

Blijft ALLES wat er fout gelopen is, permanent staan tot je zpool clear doet?

Eigenlijk best wel een belangrijke vraag in mijn geval aangezien ik 2 x per week een scrub doe, als er al een aantal keer iets gefixed is, dan heb ik het eigenlijk nooit geweten. Ik monitor uiteraard wel met SMART, maar dat laat me niet weten of ik een corruptie ben tegengekomen...

[FireDrunk]

Je ziet hoeveel bytes er gerepareerd zijn in de scrub line.

[HyperBart]

Permanten tot je cleart? Dus ook als je 4 scrubs achter elkaar doet en de eerste scrub heeft dingen gefixed?

[CurlyMo]

Het is sowieso vrij overdreven om twee keer per week een scrub te doen.

[HyperBart]

Is dat? Een scrub duurt bij mij een 10 à 11h. Prima in een nachtje te doen.

Disks zijn commodity, disks zijn vervangbare onderdelen die falen, ik wil het zo snel mogelijk weten. Ik heb geen enterprise grade disks, gewone 4TB Seagates, dus ik scrub liever eens te veel dan te weinig...

Zeker omdat het een redelijk "fill her up" NAS is, waarbij oude data bijna NOOIT wordt gelezen, vind ik 2 x per week absoluut geen probleem.

Sowieso is het aan te raden om een scrub bij SATA disks minstens één keer per week te doen. 2 x gaat het heus niet erger maken en geeft volgens mij (oooooh tvwes? ) statistisch gezien een betere kans om problemen te detecteren...

[ Voor 43% gewijzigd door HyperBart op 01-05-2015 18:56 ]

[tvwes]

HyperBart schreef op vrijdag 01 mei 2015 @ 18:50:
Is dat? Een scrub duurt bij mij een 10 à 11h. Prima in een nachtje te doen.

Sowieso is het aan te raden om een scrub bij SATA disks minstens één keer per week te doen. 2 x gaat het heus niet erger maken en geeft volgens mij (oooooh tvwes? ) statistisch gezien een betere kans om problemen te detecteren...

Om te beginnen moet ik

Disks zijn commodity, disks zijn vervangbare onderdelen die falen, ik wil het zo snel mogelijk weten. Ik heb geen enterprise grade disks, gewone 4TB Seagates, dus ik scrub liever eens te veel dan te weinig...

Ja het generieke advies is om bij SATA disks 1x per week een scrub te doen. En een keer extra kan geen kwaad. Maar de vraag is wat ga je doen als scrub fouten vind? Je kan redeneren: omdat er fouten waren je de disk moet vervangen aan de andere kant dat scrub de fouten heeft hersteld en dat het daarmee klaar is.
Natuurlijk is het niet leuk dat er fouten waren, maar wanneer is het gerechtvaardigd om de disk te vervangen? Je kan wachten totdat zfs de disk als faulted markeert. Of zelf een criterium bedenken, bij zoveel fouten en die ouderdom en dat smartattribuut en of Venus in lijn staat met Mars staat. Oftewel zelf iets zinnigs bedenken is best lastig.
Ik wacht bijna altijd totdat ZFS de disk als faulty markeert. Bij thuis installaties heb ik wel eens een disk preventief vervangen. Maar stel je maar eens voor wat een karwei het is als je duizenden disken moet gaan karakteriseren en dan te bepalen welke vervangen moet worden.

Het swappen van disken wat ik wel eens heb uitgelegd is iets anders.

[jvhaarst]

tvwes schreef op vrijdag 01 mei 2015 @ 15:56:
[...]

Dank je wel. Kan je nog even $cat /etc/exports posten? Alsmede $ sudo zfs get all scratch/data

Afhankelijk hoe de client zich identificeert maakt NFS wel degelijk uit.

/etc/exports:

code:

/scratch/data 192.168.1.1/24(rw,no_root_squash,sync,subtree_check)  10.73.177.215(rw,no_root_squash,sync,subtree_check) 10.1.1.1/16(rw,no_root_squash,sync,subtree_check) 10.73.216.102(rw,no_root_squash,sync,subtree_check) pevzner(rw,no_root_squash,sync,subtree_check)
/scratch/clc 192.168.1.1/24(rw,no_root_squash,sync,subtree_check)
/scratch/data/haars001/projects/VLPB/test_data 137.224.96.215(rw,no_root_squash,sync,subtree_check)
/scratch/data/nijve002/ftp 137.224.96.215(rw,no_root_squash,sync,subtree_check)

zfs get all:

code:

sysop@scratch:~$ sudo zfs get all scratch/data
NAME          PROPERTY              VALUE                  SOURCE
scratch/data  type                  filesystem             -
scratch/data  creation              Mon Mar 24 10:30 2014  -
scratch/data  used                  54.1T                  -
scratch/data  available             4.37T                  -
scratch/data  referenced            54.1T                  -
scratch/data  compressratio         1.29x                  -
scratch/data  mounted               yes                    -
scratch/data  quota                 none                   default
scratch/data  reservation           none                   local
scratch/data  recordsize            128K                   default
scratch/data  mountpoint            /scratch/data          default
scratch/data  sharenfs              on                     local
scratch/data  checksum              on                     default
scratch/data  compression           lzjb                   inherited from scratch
scratch/data  atime                 off                    inherited from scratch
scratch/data  devices               on                     default
scratch/data  exec                  on                     default
scratch/data  setuid                on                     default
scratch/data  readonly              off                    default
scratch/data  zoned                 off                    default
scratch/data  snapdir               hidden                 default
scratch/data  aclinherit            restricted             default
scratch/data  canmount              on                     default
scratch/data  xattr                 on                     default
scratch/data  copies                1                      default
scratch/data  version               5                      -
scratch/data  utf8only              off                    -
scratch/data  normalization         none                   -
scratch/data  casesensitivity       sensitive              -
scratch/data  vscan                 off                    default
scratch/data  nbmand                off                    default
scratch/data  sharesmb              off                    default
scratch/data  refquota              none                   default
scratch/data  refreservation        none                   default
scratch/data  primarycache          all                    default
scratch/data  secondarycache        all                    default
scratch/data  usedbysnapshots       0                      -
scratch/data  usedbydataset         54.1T                  -
scratch/data  usedbychildren        0                      -
scratch/data  usedbyrefreservation  0                      -
scratch/data  logbias               latency                default
scratch/data  dedup                 off                    default
scratch/data  mlslabel              none                   default
scratch/data  sync                  disabled               inherited from scratch
scratch/data  refcompressratio      1.29x                  -
scratch/data  written               54.1T                  -
scratch/data  logicalused           69.7T                  -
scratch/data  logicalreferenced     69.7T                  -
scratch/data  snapdev               hidden                 default
scratch/data  acltype               off                    default
scratch/data  context               none                   default
scratch/data  fscontext             none                   default
scratch/data  defcontext            none                   default
scratch/data  rootcontext           none                   default
scratch/data  relatime              off                    default

Oh, en het is een productie bak, mensen worden een beetje boos als ik ze de storage afpak voor een OS update, terwijl dat eigenlijk niet nodig is.
Als het moet om deze "bug" op te lossen, dan moet het maar, maar liever niet.
En op de creation date, was dit dus de nieuwste Ubuntu..

[tvwes]

jvhaarst schreef op vrijdag 01 mei 2015 @ 20:17:
[...]

Ik was net bezig je ubuntu te installeren om het even na te bouwen

install Saucy

1GB ram
16GB vmdk
LSI parallel
all english
us keyboard
guided - use entire disk and setup lvm
boot disk sda met ext4
apt via proxy

code:

Last login: Fri May  1 20:43:25 2015
tmp@jvhaarst:~$ uname -a
Linux jvhaarst 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
tmp@jvhaarst:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 13.10
Release:        13.10
Codename:       saucy

nu even ZoL 0.6.3 erop ...

dat bleek te hoog gegrepen ik kan deze versie niet zo snel vinden en daarnaast is de support door ZoL voor saucy non-existent.

Ik heb nu trusty geinstalleerd

code:

tmp@trusty:/etc$ uname -a
Linux trusty 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
tmp@trusty:/etc$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:        14.04
Codename:       trusty
tmp@trusty:/etc$ aptitude show libzfs2 zfsutils | grep Version
Version: 0.6.4.1-1~trusty
Version: 0.6.4.1-1~trusty

Nu aan de slag

code:

sudo -E add-apt-repository ppa:zfs-native/stable
sudo apt-get update
sudo apt-get install ubuntu-zfs

cat /proc/partitions
sudo sh -c 'echo "- - -" > /sys/class/scsi_host/host2/scan'
cat /proc/partitions

sudo zpool create -f scratch /dev/sdb
sudo zfs set atime=off scratch
sudo zfs create scratch/data

sudo sh -c 'dpkg -l | grep nfs-kernel-server'
sudo apt-get install nfs-kernel-server

sudo vi /etc/exports
cat /etc/exports
/scratch/data 192.168.10.0/24(rw,no_root_squash,sync,subtree_check)

sudo exportfs -ra
sudo service nfs-kernel-server restart

Nu heb ik precies dezelfde dataset via nfs met dezelfde opties geexporteerd op de ubuntu host

Nu ga ik naar een client, OmniOS in dit geval.
En mount als gebruiker de zojuist geexporteerde nfs share

code:

cd ~
mkdir trusty
pfexec mount -F nfs 192.168.10.35:/scratch/data trusty
cd trusty
uname -a > remote-uname
ls -l
total 1
-rw-r--r-- 1 tvwes tvwes 51 May  1 23:03 remote-uname

Toen heb ik op de client de file "remote-uname' aangemaakt.
Let op dat mijn username hier leesbaar is.

Nu ga ik naar de server en doe daar een listing
Nu is mijn username alleen numeriek bekend

code:

ls -l
total 1
-rw-r--r-- 1 1306 1306 51 May  1 23:03 remote-uname
cat /scratch/data/remote-uname
SunOS oistor1 5.11 omnios-170cea2 i86pc i386 i86pc

sudo zfs set userquota@1306=2K scratch/data
sudo zfs userspace scratch/data
TYPE        NAME  USED  QUOTA
POSIX User  1306    1K     2K
POSIX User  root   512   none

Vervolgens een userquotum ingesteld voor mijn uid van 2K
Toen het huidige verbruik opgevraagd, voor mijn uid had ik 1K van de 2K gebruikt.

Nu even op letten, een quota bereiken is niet hetzelfde als een volle disk.
Ik schrijf 2K naar een file en dat lukt.
Maar ik ben wel over mijn quotum heen, laatste output

code:

tvwes@oistor1:/export/home/tvwes/trusty$ dd if=/dev/random bs=1K count=2 of=./tegroot
2+0 records in
2+0 records out
2048 bytes (2.0 kB) copied, 0.0109567 s, 187 kB/s

tmp@trusty:~/showtools$ sudo zfs userspace scratch/data
TYPE        NAME   USED  QUOTA
POSIX User  1306  3.50K     2K
POSIX User  root    512   none
tmp@trusty:~/showtools$ ls -l /scratch/data/
total 4
-rw-r--r-- 1 1306 1306   51 May  1 23:03 remote-uname
-rw-r--r-- 1 1306 1306 2048 May  1 23:14 tegroot

Laten we een derde file proberen te schrijven..

code:

tvwes@oistor1:/export/home/tvwes/trusty$ dd if=/dev/random bs=1K count=2 of=./tegroot2
dd: failed to open './tegroot2': Disc quota exceeded

En nu krijg je de quota melding

Tot slot nog als root een testje..

code:

tvwes@oistor1:/export/home/tvwes/trusty$ pfexec dd if=/dev/random bs=1K count=2 of=./tegroot_root
2+0 records in
2+0 records out
2048 bytes (2.0 kB) copied, 0.00269709 s, 759 kB/s

tmp@trusty:~/showtools$ ls -l /scratch/data/
total 6
-rw-r--r-- 1 1306 1306   51 May  1 23:03 remote-uname
-rw-r--r-- 1 1306 1306 2048 May  1 23:14 tegroot
-rw-r--r-- 1 root root 2048 May  1 23:18 tegroot_root

Samenvattend het lijkt prima te werken geen funky gedrag alles prima. Dus @jvhaarst, alles lijkt het gewoon te doen. Ik heb net als jij een numeriek uid aan userquota meegegeven. Ik had je gevraagd waar die hoge uid vandaan kwamen maar kreeg geen reply. Mijn uid was een classic 16bit en jij gebruikte een 32bit uid. Ik kan probleemloos op ZoL ook een quotum instellen voor jouw hoge uid. Ik kan dit ook opvragen. En daar gaat het volgens mij mis. Na het zetten wil je volgens mij een listing opvragen van quota door dmv

code:

sudo zfs userspace scratch/data

Dat commando geeft een lijst met gebruikte ruimte en ingestelde quota per gebruiker maar alleen voor gebruikte ruimte. Dus als jouw uid van 16825946 geen ruimte gebruikt dan zal hij nooit in de lijst komen.
Ik had er overheen gelezen in eerste instantie omdat jij zo stellig beweerde dat er een probleem is.

Ik Je zal met een betere beschrijving van je probleem moet komen mocht ik niet de oplossing in mijn stappen hebben verklapt. Ik heb alles zoveel mogelijk gelijk proberen te houden tot en met datasetnamen en zfs create opties.

En ziet een ieder hier de mate van detail, niks anderhalve regel voor een probleem. Stap voor stap een scenario uitwerken.

Tot slot nog wat relevante output

code:

sudo zpool status
[sudo] password for tmp:
  pool: scratch
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        scratch     ONLINE       0     0     0
          sdb       ONLINE       0     0     0

errors: No known data errors

sudo zpool history scratch
History for 'scratch':
2015-05-01.22:36:29 zpool create -f scratch /dev/sdb
2015-05-01.22:44:14 zfs create scratch/data
2015-05-01.23:10:32 zfs set userquota@1306=2K scratch/data

sudo zfs get all scratch/data
NAME          PROPERTY              VALUE                  SOURCE
scratch/data  type                  filesystem             -
scratch/data  creation              Fri May  1 22:44 2015  -
scratch/data  used                  28.5K                  -
scratch/data  available             9.78G                  -
scratch/data  referenced            28.5K                  -
scratch/data  compressratio         1.00x                  -
scratch/data  mounted               yes                    -
scratch/data  quota                 none                   default
scratch/data  reservation           none                   default
scratch/data  recordsize            128K                   default
scratch/data  mountpoint            /scratch/data          default
scratch/data  sharenfs              off                    default
scratch/data  checksum              on                     default
scratch/data  compression           off                    default
scratch/data  atime                 off                    inherited from scratch
scratch/data  devices               on                     default
scratch/data  exec                  on                     default
scratch/data  setuid                on                     default
scratch/data  readonly              off                    default
scratch/data  zoned                 off                    default
scratch/data  snapdir               hidden                 default
scratch/data  aclinherit            restricted             default
scratch/data  canmount              on                     default
scratch/data  xattr                 on                     default
scratch/data  copies                1                      default
scratch/data  version               5                      -
scratch/data  utf8only              off                    -
scratch/data  normalization         none                   -
scratch/data  casesensitivity       sensitive              -
scratch/data  vscan                 off                    default
scratch/data  nbmand                off                    default
scratch/data  sharesmb              off                    default
scratch/data  refquota              none                   default
scratch/data  refreservation        none                   default
scratch/data  primarycache          all                    default
scratch/data  secondarycache        all                    default
scratch/data  usedbysnapshots       0                      -
scratch/data  usedbydataset         28.5K                  -
scratch/data  usedbychildren        0                      -
scratch/data  usedbyrefreservation  0                      -
scratch/data  logbias               latency                default
scratch/data  dedup                 off                    default
scratch/data  mlslabel              none                   default
scratch/data  sync                  standard               default
scratch/data  refcompressratio      1.00x                  -
scratch/data  written               28.5K                  -
scratch/data  logicalused           18.5K                  -
scratch/data  logicalreferenced     18.5K                  -
scratch/data  snapdev               hidden                 default
scratch/data  acltype               off                    default
scratch/data  context               none                   default
scratch/data  fscontext             none                   default
scratch/data  defcontext            none                   default
scratch/data  rootcontext           none                   default
scratch/data  relatime              off                    default
scratch/data  redundant_metadata    all                    default
scratch/data  overlay               off                    default

sudo zfs list
NAME           USED  AVAIL  REFER  MOUNTPOINT
scratch        100K  9.78G    19K  /scratch
scratch/data  28.5K  9.78G  28.5K  /scratch/data

ls -l /scratch/
total 1
drwxrwxrwx 2 root root 6 May  1 23:29 data

ls -l /scratch/data
total 11
-rw-r--r-- 1 1306 1306   51 May  1 23:03 remote-uname
-rw-r--r-- 1 1306 1306 2048 May  1 23:14 tegroot
-rw-r--r-- 1 root root 2048 May  1 23:18 tegroot_root
-rw-r--r-- 1 root root 4096 May  1 23:29 tegroter_root

[ Voor 146% gewijzigd door tvwes op 02-05-2015 01:04 ]

[HyperBart]

Zonet eens aan de slag gegaan met het script van CurlyMo. Snel een test VM opgezet, twee pools aangemaakt en filesystems eronder met dezelfde namen als op de NAS.


CurlyMo in "Het grote ZFS topic"

Dat werkt echt prima zeg...

Je geeft een lijstje van datasets op, je maakt snapshots aan, dit script send/rcv'd. Je houdt op de twee pools telkens het "laatste" snapshotje bij (uiteraard, want het is incremental). Je kan alle tussenliggende snapshots verwijderen, of het nu aan source of destination is...

Combineer dat dan met periodiek een automatische snapshot of manueel, en periodiek dit script laten lopen, en klaar .

code:

root@UbuntuTesting:~# crontab -l
* * * * * /bin/bash /root/backup.sh 2>&1 | /root/timeStamping.sh >> /root/logs/backup.log

+

Bash:

root@UbuntuTesting:~# cat timeStamping.sh
#!/bin/bash
while read x; do
    echo -n `date +%d/%m/%Y\ %H:%M:%S`;
    echo -n " ";
    echo $x;
done

+

Bash:

#!/usr/bin/env bash

export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

ERROR=0
DESTINATION="backuppool";

round()
{
echo $(printf %.$2f $(echo "scale=$2;(((10^$2)*$1)+0.5)/(10^$2)" | bc))
};

DISKSPACE=($(zfs list -o used,avail -Hp $DESTINATION));
SPACETOTAL=$((${DISKSPACE[0]}+${DISKSPACE[1]}));
SPACEUSED=${DISKSPACE[0]};
SPACEAVAIL=${DISKSPACE[1]};
SPACECAP=$(($(($SPACEAVAIL*100))/$SPACETOTAL));

MINSPACE=$(($SPACETOTAL-$(round $SPACETOTAL*0.1 0)));
MINSNAP=5;

FOLDERS=(
"juggernaut/BeeldmateriaalGezin"
"juggernaut/Bart"
"juggernaut/Documenten"
);

SNAPSHOTS=($(zfs list -t snapshot -o name -H -s creation -r $DESTINATION));
DISKSPACE=($(zfs list -o used,avail -Hp $DESTINATION));
SPACETOTAL=$((${DISKSPACE[0]}+${DISKSPACE[1]}));
SPACEUSED=${DISKSPACE[0]};
SPACEAVAIL=${DISKSPACE[1]};
SPACECAP=$(($(($SPACEAVAIL*100))/$SPACETOTAL));
TMP=$(echo ${SNAPSHOTS[@]} | sed -e 's/\ /\\n/g');
FS=$(echo -e "$TMP" | cut -f1 -d"@" | sort | uniq);
NRSNAP=$(echo -e "$TMP" | cut -f2 -d"@" | sort | uniq | wc -l);
REMOVED=1;

while [ $SPACEUSED -gt $MINSPACE ] && [ $REMOVED -eq 1 ]; do
    REMOVED=0
    TMP=$(echo ${SNAPSHOTS[@]} | sed -e 's/\ /\\n/g');
    for F in ${FS[@]}; do
        NRSNAP=$(echo -e "$TMP" | grep $F | cut -f2 -d"@" | sort | uniq | wc -l);
        S=$(echo -e "$TMP" | grep $F | sort | uniq | head -n 1);
        if [ $NRSNAP -ge $MINSNAP ]; then
            echo "zfs destroy $S"
            zfs destroy $S
            REMOVED=1
            SNAPSHOTS=(${SNAPSHOTS[@]/$S})
            FS=(${FS[@]/$F})
            if [ ${#FS[@]} -eq 0 ]; then
                FS=$(echo -e "$TMP" | cut -f1 -d"@" | sort | uniq);
            fi
            break;
        fi
    done

    sleep 1;

    DISKSPACE=($(zfs list -o used,avail -Hp $DESTINATION));
    SPACETOTAL=$((${DISKSPACE[0]}+${DISKSPACE[1]}));
    SPACEUSED=${DISKSPACE[0]};
    SPACEAVAIL=${DISKSPACE[1]};
    SPACECAP=$(($(($SPACEAVAIL*100))/$SPACETOTAL));
done

if [ $SPACEUSED -gt $MINSPACE ]; then
    echo "Not enough diskspace on $DESTINATION pool" 1>&2
fi

zfs list $DESTINATION 1>/dev/null 2>/dev/null || ERROR=1;

if [ $ERROR -eq 1 ]; then
    echo "Destination doesn't exists";
    exit;
fi

BACKUP=$(zfs list -o name -r -t snapshot $DESTINATION)
ERROR=0;
NEWLINE=$'\n';

DESTROOT=$(dirname $DESTINATION);

if [ $DESTROOT == "." ]; then
    DESTROOT=$DESTINATION;
fi

for F in ${FOLDERS[@]}; do

    ORIROOT=${F%%/*};
    ORIFS=${F#*/};
    DATA=$(zfs list -o name -r -t snapshot $ORIROOT 2>/dev/null)
    if [ $? -eq 1 ]; then
        echo "Origin $F doesn't exists";
        continue;
    fi

    LASTORISNAP="";
    LASTDESTSNAP="";
    FIRSTORISNAP="";
    FIRSTDESTSNAP="";
    ORISNAPEXISTS=0;

    for D in ${BACKUP[@]}; do
        ROOT=${D%%@*}
        SNAP=${D##*@}
        if [ "$ROOT" == "$DESTINATION/$ORIFS" ]; then
            if [ -z $FIRSTDESTSNAP ]; then
                FIRSTDESTSNAP=$SNAP;
            fi
            LASTDESTSNAP=$SNAP;
        fi
    done
    for D in ${DATA[@]}; do
        ROOT=${D%%@*}
        SNAP=${D##*@}
        if [ "$ROOT" == "$F" ]; then
            if [[ "$LASTDESTSNAP" =~ "$SNAP" ]]; then
                ORISNAPEXISTS=1
            fi
            if [ -z $FIRSTORISNAP ]; then
                FIRSTORISNAP=$SNAP;
            fi
            LASTORISNAP=$SNAP;
        fi
    done

    if [ $ORISNAPEXISTS -eq 1 ]; then
        if [ $LASTORISNAP = $LASTDESTSNAP ]; then
            echo "$F already up-to-date on $DESTINATION";
        else
            echo "zfs send -RI $F@$LASTDESTSNAP $F@$LASTORISNAP | zfs receive -dvu $DESTROOT"
            zfs send -RI $F@$LASTDESTSNAP $F@$LASTORISNAP | zfs receive -dvu $DESTROOT
        fi
    else
         if [ ! -z $LASTDESTSNAP ]; then
             echo "$F already has snapshots on $DESTINATION, but none of them matches to an existing snapshot on $ORIGIN";
         else
            echo "zfs send -R $F@$FIRSTORISNAP | zfs receive -Fdvu $DESTROOT"
            zfs send -R $F@$FIRSTORISNAP | zfs receive -Fdvu $DESTROOT
            if [ $FIRSTORISNAP != $LASTORISNAP ]; then
                echo "zfs send -RI $F@$FIRSTORISNAP $F@$LASTORISNAP | zfs receive -dvu $DESTROOT"
                zfs send -RI $F@$FIRSTORISNAP $F@$LASTORISNAP | zfs receive -dvu $DESTROOT
            fi
        fi
    fi
done

=

code:

root@UbuntuTesting:~# tail -f /root/logs/backup.log
01/05/2015 23:49:58 juggernaut/Documenten already up-to-date on backuppool
01/05/2015 23:50:02 juggernaut/BeeldmateriaalGezin already up-to-date on backuppool
01/05/2015 23:50:02 juggernaut/Bart already up-to-date on backuppool
01/05/2015 23:50:02 juggernaut/Documenten already up-to-date on backuppool
01/05/2015 23:51:01 juggernaut/BeeldmateriaalGezin already up-to-date on backuppool
01/05/2015 23:51:01 juggernaut/Bart already up-to-date on backuppool
01/05/2015 23:51:01 juggernaut/Documenten already up-to-date on backuppool
01/05/2015 23:52:01 juggernaut/BeeldmateriaalGezin already up-to-date on backuppool
01/05/2015 23:52:01 juggernaut/Bart already up-to-date on backuppool
01/05/2015 23:52:01 juggernaut/Documenten already up-to-date on backuppool

[ Voor 115% gewijzigd door HyperBart op 01-05-2015 23:56 ]