Het grote ZFS topic

[Erik1]

Verwijderd schreef op woensdag 03 oktober 2012 @ 22:12:

@B2: je SSD gaat via de ESXi toch? Dus dat is geen veilige opslag. Root-on-ZFS betekent dat je systeem/OS dezelfde bescherming geniet als je data.

Wat daarbij wel roet in het eten gooit, is dat ESXi voor zover ik weet niet kan booten vanaf een met VT-d doorgegeven controller. Maar misschien kunnen andere hypervisors dit wel.

[B2]

Erik1 schreef op woensdag 03 oktober 2012 @ 22:32:
[...]

Wat daarbij wel roet in het eten gooit, is dat ESXi voor zover ik weet niet kan booten vanaf een met VT-d doorgegeven controller. Maar misschien kunnen andere hypervisors dit wel.

Ik gebruik geen ESXi maar KVM.

[sloth]

Verwijderd schreef op woensdag 03 oktober 2012 @ 22:12:
@sloth: wat voor controller. heb je de disk netjes geformatteerd onder NAS4Free?

Het is een usbstick waar de embedded versie van NAS4Free op staat die aangesloten is op een onboard USB poort van pricewatch: Asus C60M1-I

[ Voor 13% gewijzigd door sloth op 03-10-2012 22:42 ]

[FireDrunk]

@B2, Je kan dus prima met de VirtIO controller een Logical Volume doorgeven en daar Root-on-ZFS mee doen.

Volgens mij ondersteund VirtIO zelfs TRIM/UNMAP tegenwoordig in de nieuwste kernels, dus zou de performance ook goed moeten blijven...

[HyperBart]

Wat is zo een beetje het optimale APM-level van een setje van disks in een NAS? Een uurtje eer ze downspinnen lijkt me niet slecht om wear and tear te beperken... Weet alleen niet de verschillen tussen

Count Level
00h Reserved
01h Minimum power consumption with Standby
02h-7Fh Intermediate power management levels with Standby
80h Minimum power consumption without Standby
81h-FDh Intermediate power management levels without Standby

Betreft enkele pricewatch: Hitachi Deskstar 7K3000, 3TB .

[u_nix_we_all]

Even iets heel anders: heeft er iemand al eens gekeken naar [url=/http://www.debian.org/ports/kfreebsd-gnu/]Debian GNU/KFreeBSD[/url]. Debian met een FreeBSD kernel dus.
Ik kende het nog niet (ken wel het Debian GNU/Hurd project waar niet zoveel uit komt) maar het lijkt mij een hoop voordelen te bieden, een mooie distro voor mensen die graag ZFS willen, maar de overstap van Linux naar BSD eng vinden
Hoewel voor die groep native zfs-on-linux er ook steeds beter uitziet, ik ben daar ook mee aan het spelen, om te kijken of ik een Linux/ZFS/DRBD setup kan maken met ZFS en synchroon-replicatie van datapools

[FireDrunk]

Ik heb al jaren spindown op 10 minuten staan en dat ging prima. Nu met zfs moet ik het nog even bekijken.

[EnerQi]

Dadona in "Het grote ZFS topic"

In ZFSguru staat dat mijn processor usage 240% is. Average 2.60,2,20 1,32. Hoe is het bij mij dan mogelijk om hoger dan "2" uit te komen? Ik heb namelijk maar een duelcore in mijn NAS zitten en het is overduidelijk dat de netwerkverbinding het probleem is. (2 pc's die tegelijk de nas aan het vullen zijn).

Edit: als je de 2 reacties erna ook leest vanaf het bericht van Dadona, is dit bericht overbodig....

[ Voor 12% gewijzigd door EnerQi op 07-10-2012 11:35 ]

[Dadona]

Als het goed is heb je het even verkeerd / te laat afgelezen. Misschien is het codetechnisch mogelijk dat je toch net iets van een verschil krijgt, maar in principe is 'processor usage' gelijk aan de het eerste getal (1 minuut) van load average. In jouw geval zou dat dus 260% zijn geweest.

Zoals ik al zei klopt het niet dat ZFSguru het over 'Current CPU usage' heeft. Het moet 'current' usage zijn. (Het is ook niet echt current, omdat het over een minuut loopt, maar goed dat terzijde.) Het is de 1 minute load average, het eerste getal van 'load averages' en is geen enkel opzicht indicatief voor het CPU gebruik.
De load averages kunnen rustig boven het aantal cores uitkomen, omdat hierin ook de wachtrij is meegenomen. Voor het werkelijke CPU gebruik moet je met SSH aan de gang. Inloggen en dan 'top' starten. Dan kun je uitlezen wat het CPU gebruik werkelijk is.

[sphere]

u_nix_we_all schreef op vrijdag 05 oktober 2012 @ 12:28:
Even iets heel anders: heeft er iemand al eens gekeken naar [url=/http://www.debian.org/ports/kfreebsd-gnu/]Debian GNU/KFreeBSD[/url]. Debian met een FreeBSD kernel dus.
Ik kende het nog niet (ken wel het Debian GNU/Hurd project waar niet zoveel uit komt) maar het lijkt mij een hoop voordelen te bieden, een mooie distro voor mensen die graag ZFS willen, maar de overstap van Linux naar BSD eng vinden
Hoewel voor die groep native zfs-on-linux er ook steeds beter uitziet, ik ben daar ook mee aan het spelen, om te kijken of ik een Linux/ZFS/DRBD setup kan maken met ZFS en synchroon-replicatie van datapools

Dit is een van de redenen volgens de wiki:

http://wiki.debian.org/Debian_GNU/kFreeBSD_why

[_RRM_]

_RRM_ schreef op zondag 30 september 2012 @ 22:29:
rsync installeren onder ZFSguru levert de volgende foutcode op bij benadering van lokaalip:873

@RSYNCD: 30.0
@ERROR: protocol startup error

Acties als volledige beginner:
- FreeBSD handleiding hier doorgewerkt.
- Naast de rsync instructies hier gelegd.

Installatie van rsync eindelijk gelukt, maar ik loop volledig vast in het benaderen vanaf een windows machine.
Ik heb al regels toegevoegd om lokale adressen toegang te geven via rsync en ssh, geen wachtwoorden, volledige rechten in de desbetreffende map. Deltacopy en Backup Agent geprobeerd die eveneens vastlopen in de verbindingsfase. cygwin en cwRsync werden iets te complex en zijn daardoor niet gelukt.
Een howto voor rsync van een windows bak naar ZFSGuru server kan ik maar gedeeltelijk vinden.
Twijfel of ik door moet gaan met ZFSguru....

[ Voor 8% gewijzigd door _RRM_ op 08-10-2012 15:05 ]

[Verwijderd]

rsync voor Windows? Hoe doet windows dan permissies en flags? Als je toch van non-POSIX naar ZFS wilt, waarom dan rsync? Gebruik dan gewoon Samba.

En rsync zou heel eenvoudig moeten zijn:
1. Install: pkg_add -r rsync
2. edit config file ee /usr/local/etc/rsyncd.conf

[test]
path=/pad/naar/data

3. start rsync server op ZFSguru: rsync --daemon
4. connect van client naar server:
rsync 10.0.0.100::test /destination

Wat wil je nu precies?

[HyperBart]

Ik kan CiPHER alleen maar bijvallen: rsync installeren en activeren kost echt maar 5 minuutjes, 10 minuutjes als je wat "zwakhartig" ben en regelmatig wat moet opzoeken...

Plus, dat je rsync niet werkend krijgt ligt niet aan ZFS of ZFSguru maar eerder aan het feit dat je de bron-kant niet zo goed configureert...

[VorCha]

Ik ben het met Cypher eens, gebruik Samba als het connectiviteit vanuit Windows betreft. Zelf heb ik een robocopy draaien ipv rsync.

[Dadona]

Ik heb een tijd Timedicer gebruikt. Daarmee kun je Rsync onder Windows op relatief makkelijke manier aan de gang krijgen. Weliswaar gaan inderdaad de permissies niet goed bij een restore, maar dat had ik er wel voor over.
Sowieso zou ik een test uitvoeren of het het probleem bij de initiator of de target zit. Pak een Linux of FreeBSD installatie en probeer daarmee ook contact te zoeken met ZFSguru.

[_RRM_]

Verwijderd schreef op maandag 08 oktober 2012 @ 15:09:
rsync voor Windows? Hoe doet windows dan permissies en flags? Als je toch van non-POSIX naar ZFS wilt, waarom dan rsync? Gebruik dan gewoon Samba.

En rsync zou heel eenvoudig moeten zijn:
1. Install: pkg_add -r rsync
2. edit config file ee /usr/local/etc/rsyncd.conf

[test]
path=/pad/naar/data

3. start rsync server op ZFSguru: rsync --daemon
4. connect van client naar server:
rsync 10.0.0.100::test /destination

Wat wil je nu precies?

Helemaal eens! Installatie van rsync onder ZFSguru met wat inlees werk en beginnersfouten zeker een fluitje van een cent. Dat draait allemaal naar behoren.
Ik heb dus het idee om een client onder windows te draaien die met een vast gestelde regelmaat backups naar de server stuurt.
Het gaat dus niet mis op de server (ZFSguru), maar binnen de client. Het ontbreekt mij dus aan kennis om in te schatten waar de permissies, wachtwoorden, toegestane ip-adressen, etc.. nu verkeerd zijn ingesteld.
Ik kom hier dus niet goed uit met de diverse handboeken, fora of howto's.

Samba is zeker het alternatief onder windows, maar had het idee dat rsync via ssh sneller/veiliger zou zijn bij een backup op afstand in de toekomst.

Deltacopy werkt...
Met het toevoegen van het volgende aan rscynd.conf werkt het met deltacopy:
[BackUp]
path = /ZFSguru/share/test_backup
read only = false

Nu nog uitzoeken hoe dit veilig te krijgen. Per user write/read rechten, maar geen read mogelijkheden voor de andere mappen.

[ Voor 15% gewijzigd door _RRM_ op 08-10-2012 21:45 ]

[FireDrunk]

d1ng schreef op woensdag 03 oktober 2012 @ 17:59:
[...]

Dan zul je versteld staan hoe makkelijk dat in FreeBSD is. Je hebt maar 1 configuratie bestand die maar een paar regels hoeft te bevatten. Gewoon "include GENERIC" erin opnemen en daaronder je eigen opties.

Ik heb me er maar even toe gezet om me er in te verdiepen, en inderdaad, het stelt weinig voor

Nu alleen nog vinden hoe ik geforceerd dingen NIET als module kan compilen... (al die meuk...)

[gitaarwerk]

FireDrunk schreef op dinsdag 02 oktober 2012 @ 18:26:
Klopt allemaal, maar voor de situatie waar Gitaarwerk in zit is het dan eigenlijk nutteloos.

even wat anders, weet jij (CiPHER) iets van de bugs met de IXGBE drivers onder FreeBSD? Ik krijg kernel panics als ik mijn 10Gb kaart in mijn ZFSGuru machine heb zitten.

Weer even het topic ingedoken. Inmiddels de RAID card afbesteld,.. ik ben er nog heel erg aan in aan het duiken. Moet nog veel leren, ben ook ondertussen bezig te kijken hoe het zit met VMware view.. maar dat is niet relevant voor deze discussie.
Ik vind het erg interessant allemaal.

Waar ik een beetje altijd aan het twijfelen over bent: Hoe rigoreus moet je nou omgaan met de server/storage/backup.

Wat ik vooral op tweakers lees, hier wordt verteld kiest men vaak voor de beste oplossing. Helaas zijn die beste oplossingen vrij intensief soms, om die te bewerkstelligen heb je bijvoorbeeld weer een colocated server (ik noem maar wat op), terwijl soms een simpele NAS ook kan volstaan. , het is wel heel erg leuk om er mee bezig te zijn. Brings out the nerd in me Je wilt het graag goed doen, maar zo goed dat het niet teveel geld kost (zeker omdat ik net gestart bent)

Het moeilijke vind ik dus, wat is nou echt belangrijk, en enigzins betaalbaar/uitvoerbaar. Bedrijven werken met veel minder, en wij zijn maar met ons tweeën

Uiteindelijk zou er een simpel antwoord mogelijk zijn; welke vm's heb je nodig, en hoe kan je het stabiel laten draaien, zonder dat je twee/drie servers nodig hebt met failover technieken,.. het lijkt me (ik heb nog niet veel ingelezen) dat je een filesysteem runt (zfs dus), en dat je van die een image maakt, en als de SSD of USB stick uitvalt, dat je deze terug kan zetten.
Maar zo zou het dus vast niet werken . Uiteindelijk moet er gewoon met heel weinig omkijken naar gewerkt mee worden. Daarvoor vind ik persoonlijk, heb je deze dingen dus... zo niet, dan kan ik toch gewoon beter 's avonds de raid schijven mee naar huis nemen en de volgende dag weer inpluggen?

Nu ben ik natuurlijk wel even erg simpel, maar naar zo een oplossing zoek ik dus wel.
Onderhand aan het inlezen over PCoIP en virtualisatie wat erg interessant is, maar zeker zo een bestandssysteem zou gewoon wel direct goed moeten zijn.

Ik dwaal een beetje af nu...

[FireDrunk]

Even heel kort door de bocht: De simpelste oplossing is gewoon 2 externe harde schijven met kopies van je VM's. 's avons zet je gescheduled de VM's uit, en kopieert via SCP de .vmdk en .vmx files naar twee externe harddisks. 1 van die 2 leg je in je ouderlijk huis, en de andere in een kluis bij een andere bekende.

Simpel, veilig en kost vrij weinig (alleen disks, en tijd).

Nadeel hiervan? Downtime, en restore time.

Waarom roepen tweakers altijd van die rare dingen? Omdat ze lui zijn en alles willen automatiseren (net als ik...) en er dus geen omkijken naar willen hebben.

[gitaarwerk]

FireDrunk schreef op dinsdag 09 oktober 2012 @ 14:11:
Even heel kort door de bocht: De simpelste oplossing is gewoon 2 externe harde schijven met kopies van je VM's. 's avons zet je gescheduled de VM's uit, en kopieert via SCP de .vmdk en .vmx files naar twee externe harddisks. 1 van die 2 leg je in je ouderlijk huis, en de andere in een kluis bij een andere bekende.

Simpel, veilig en kost vrij weinig (alleen disks, en tijd).

Nadeel hiervan? Downtime, en restore time.

Waarom roepen tweakers altijd van die rare dingen? Omdat ze lui zijn en alles willen automatiseren (net als ik...) en er dus geen omkijken naar willen hebben.

Thanks , kort door de bocht, is ook fijn soms!

De VM's kun je dus niet zomaar exporteren zonder uit te zetten. Dat heb ik gemerkt. Ik geloof dat je daarvoor ook weer vMotion-achtige oplossingen. Downtime zou evt kunnen, maar handig is het niet inderdaad. Restore time vind ik dan overigens wel weer minder interessant.

Dus so far,.. niet echt een shortcut . En ik heb overigens dezelfde insteek hoor . Nu is IT niet mijn hoofdtaak.. ik heb geewoon mijn bedrijf te runnen en andere dingen te doen.. maar vind het wel lekker als alles goed geregeld is, en er op kan vertrouwen (maar wel dat ik geen enterprise stuff moet gaan aanschaffen )

[ Voor 11% gewijzigd door gitaarwerk op 09-10-2012 14:17 ]

[FireDrunk]

Je kan een snapshot maken van de VM en dan de VMDK kopieren. Op het moment dat er een snapshot actief is, word het write lock van een VMDK file afgehaald omdat dat op de snapshot file zit.

Je kan dus zonder downtime een VMDK kopieren.
Nadat de VMDK gekopieerd is delete je gewoon het snapshot en is alles weer bij het oude.

Simpel scriptje om dat te doen is er al, dat heet GhettoVCB.

[Verwijderd]

Waarom het snapshot kopieren? als je een VM snapshot hebt gemaakt zfs snapshot je de dataset met het snapshot en delete het snapshot; als je wilt repliceren doe je zfs send -i.

[FireDrunk]

Dat staat er toch niet? Je moet juist je VMDK kopieren, anders heb je een inconsistente file.

[Verwijderd]

Ja dat bedoel ik je VMDK kopieren is niet nodig.

[Mafketel]

Ik ben aan het nadenken over mijn volgende setup qua opslag, ik heb nu een opensolaris draaien met 5 1tb disken op zfs raidz natuurlijk.

Alleen dat natuurlijke van die raidz ben ik niet zo zeker van. Er staat een hoop op die schijven wat zonder problemen(is al een backup van) kan verdwijnen als er corrupte schijven zijn. Tevens is de noodzaak van blijven draaien als een schijf uitvalt niet aanwezig.

Er is wel data die ik liever redundant op die zpool heb staan en dat kun je ondervangen door copies=2. Overigens staat deze data ook nog op een laptop schijf en gedeeltelijk ook nog online.

Als ik het goed heb begrepen ben je bij volledig uitval van een schijf al je data kwijt bij zfs raid0, maar hoe vaak komt dat bij schijven met platters voor?
Ik kan mij 2 scenario's bedenken, een raidcontroller die een schijf uit een array gooien als de schijf niet binnen een paar seconden een timout geeft. En vertex ssd's die de pijp aan maarten geven. Daarnaast misschien losse kabels...

Zfs gooit een schijf niet uit de zpool als deze zijn best doet om data te lezen terwijl dat moeilijk is en ik heb eigenlijk nog nooit gehoord van een hardeschijf die buiten zijn corrupte sectoren niet meer reageert.

Dus als je een raid0 zpool aanmaakt waarbij je "belangrijke" data opslaat in een zfs met copies=2 en de rest met copies=1 wat is dan de kans(scenario) dat je die belangrijke data kwijt raakt?
Hoe redundant wordt de metadata opgeslagen? Of anders gezegd kan ik beter een zpool per schijf aanmaken met als gevolg niet een mooie grote zpool.

Bij een corrupte sector, bij de copies=1 bestanden jammer dan, bij de copies=2 bestanden heb je je data nog. kans 1 op 10^{14 of 15 of 16}bits of zo. Zorg wel dat bij je bij smart pending sectors direct de schijf vervangt.
Uitval volledige hardeschijf, betekent alles kwijt. Maar wat is de kans hierop?
Losse kabel, niet met je tengels aan de server zitten als die draait en geen oelewapper schijven hotswap laten verwisselen. kans is dan voor mijn gebruik te verwaarlozen.

Wat zijn jullie gedachten hierover? Zie ik wat over het hoofd?

[FireDrunk]

en ik heb eigenlijk nog nooit gehoord van een hardeschijf die buiten zijn corrupte sectoren niet meer reageert.

Uh, waar heb je die wijsheid vandaan? Eigen ervaring?

Wikipedia: Annualized failure rate

[victorb]

Als ik in zfsguru bij de transmission de torrent download plek veranderd spring die weer terug naar het oude. Ook als ik in /usr/local/etctranmssion/setting het verander reboot is het weer terug bij het oude.

[FireDrunk]

Heeft de user waar Transmission onder draait schrijf rechten op de files?

[victorb]

Heb niks aan de rechten veranderd van de standaard instalatie van trandmission en zfsguru. Heb meerdere pogingen gedaan maar hij reset steeds naar standaard waarden

[FireDrunk]

kun je eens een ls -la doen in de directory van transmission?

[Verwijderd]

Net even gekeken en de panel interface past de settings.json file aan, in het bijzonder dit stukje:

"rpc-whitelist": "127.0.0.1",

Daar wordt je eigen IP aan toegevoegd. Maar dat zou niet verklaren waarom de config weer teruggezet wordt. Kun je zelf eens de config (settings.json) veranderen/aanpassen en aangeven wat je moet doen voordat die weer verandert/reverted wordt zoals jij zegt?

Ik neem aan dat je Transmission stopt terwijl je de config file aanpast; anders zou het kunnen dat bij het afsluiten transmission zijn oude gecachde config gebruikt om de door jou aangepaste config te overschrijven.

[FireDrunk]

Je moet inderdaad transmission gestopt hebben om de file te wijzigen. anders gaat het niet goed.

[Mafketel]

FireDrunk schreef op woensdag 10 oktober 2012 @ 12:58:
[...]


Uh, waar heb je die wijsheid vandaan? Eigen ervaring?

Wikipedia: Annualized failure rate

Nee geen eigen ervaring maar ik heb er nog nooit van gehoord. De link naar het wiki artikel zegt alleen maar gefaalde harde schijven niet op wat voor manier.

Harde schijven gaan stuk, zover als ik weet vooral plaatselijk, dat is niet waar ik op doel.
Ik doel op het feit dat ik nog niet heb gehoord over harde schijven die van het een op het andere moment helemaal niet meer bereikbaar zijn.

Even buiten beschouwing gehouden dat iemand gaat voetballen met een schijf of dat een backplane de boel door laat branden.

[Verwijderd]

Mafketel: jij hebt dus alleen bad sectors gehad en nog nooit een dode schijf. Maar dat betekent natuurlijk niet dat dat nooit gebeurt. In tegeldeel; opslagmedia sterft veel vaker dan bijvoorbeeld een processor, videokaart of geheugenmodule (DoA). Dat is denk ik ook logisch omdat het mechanische techniek betreft.

Hardeschijven kunnen stukgaan door:

• fysiek defect (afgebroken pinnen; connector is niet meer bruikbaar)
• bad sectors (alles werkt maar je hebt bijvoorbeeld veel last van onleesbare sectoren)
• mechanisch defect (leeskop of motor werkt niet meer; vaak einde verhaal)
• electronisch defect (printplaat is stuk of doorgebrand; mechanisch gedeelte kan prima in orde zijn; verwisselen printplaat met identieke schijf is een optie.

[Mafketel]

Verwijderd schreef op woensdag 10 oktober 2012 @ 15:41:
...
Hardeschijven kunnen stukgaan door:
[list]• fysiek defect (afgebroken pinnen; connector is niet meer bruikbaar)

niet door iemand aan laten zitten. mag dan niet voorkomen en als je het zelf molt moet je zelf op de blaren zitten

• bad sectors (alles werkt maar je hebt bijvoorbeeld veel last van onleesbare sectoren)

heb er genoeg gezien maar tot nu toe heb ik redelijk eenvoudig alle leesbare sectoren terug kunnen halen, en vooralsnog als je niet met een bokkende raid kaart zit is de schijf alleen uitermate traag.

• mechanisch defect (leeskop of motor werkt niet meer; vaak einde verhaal)

Dit doet mij met weemoed denken aan de zip, jazz en nog een andere cassette hardeschijf waar dit idd een probleem was.
Ik heb veel oude schijven in mijn handen gehad en als iets degelijk in elkaar is gezet dan zijn het wel schijven. de economische levensduur (max 5 jaar bij een schijf) is vele male lager dan die van de motor en actuator en deze gebreken zijn vaak een gevolg van een mishandeling of of is van te voren te horen door een luidruchtigere schijf. Waarom ik trouwens 5 jaar zeg, ik heb hier nog 2 500gb schijven liggen die ik niet meer inzet en deze zijn ongeveer zo oud.

• electronisch defect (printplaat is stuk of doorgebrand; mechanisch gedeelte kan prima in orde zijn; verwisselen printplaat met identieke schijf is een optie.[/list]

Ook deze laatste heeft vaak met mishandeling te maken. Al geef ik toe dat sommige backplanes er ook wel iets mee te maken hebben.

Vooralsnog probeer ik niet te bewijzen dat hardeschijven niet stuk gaan, want dat gaan ze wel, soms zelfs met bosjes, maar wil ik graag weten hoe resilient een zfs raid0 met copies=2 is.

Als iemand trouwens ideeën heeft om hierop te zoeken ben ik je ook zeer erkentelijk. Termen die ik gebruik zoals bijvoobeeld jbod krijg ik hints hoe ik een raid kaart moet configureren en niet iets over zfs raid0.

Maar om terug te keren naar het zfs topic, Ik begrijp dat jij het ten zeerste afraad om zfs raid0 te gebruiken met alleen de wat "belangrijkere" bestanden op copies=2

[Verwijderd]

Ik gebruik zelf RAID0 en ben een groot voorstander hiervan. Je moet alleen begrijpen dat het geen redundantie beidt dus je zult je data op een andere manier veilig moeten stellen. Een goede backup bijvoorbeeld. Als je geen uptime nodig hebt, maakt RAID0 weinig uit.

ZFS in een RAID0 met copies=2 beschermt je als één van de disks op een specifiek punt een bad sector heeft; dus vrijwel immuun voor bad sectors. Maar als één schijf gefaald is en het simpelweg niet meer doet, dan is je hele pool ontoegankelijk; dus het werkt nog niet zo stoer als dat het in feite een mirror wordt.

Zelfs met copies=1 heeft je metadata ook bescherming (ditto copies) en kan dus bad sectors overleven. Alleen voor je data wil je dus copies=2 of redundantie, maar niet alle data is belangrijk genoeg om bescherming nodig te hebben. Simpelweg het detecteren van corruptie is dan genoeg; oke prima dan kopiëer ik hem even van mijn andere NAS, zoiets.

Ik zelf gebruik een Brazos mini-NAS met 2 notebook HDDs en 2 SSDs als 24/7 NAS, mijn grote servers kunnen zo grotendeels uitstaan ook als ik bezig ben. Daarmee bespaar ik serieus veel energie (zeker 200W dus 400 euro per jaar).

Oh en leuk dat bij jou een schijf nog nooit gefaald is, maar daar hoort iets van een disclaimer bij... 'In het verleden behaalde resultaten zijn geen garantie voor de toekomst' ?
HDDs zijn mechanische hooggevoelige apparaten. Die kunnen makkelijk stuk, maar kunnen in een stabiele omgeving ook heel lang prima werken. Maar de kans op uitval is veel hoger dan zeg een processor die inderdaad vrijwel NOOIT stuk gaat een DoA of user-abuse uitgezonderd.

[ Voor 16% gewijzigd door Verwijderd op 10-10-2012 19:52 ]

[victorb]

CiPHER

Wat ik ook probeer hij springt terug.

Net vinkje uitgezet van autostart - reboot - via ssh en nano config aangepast settings.json - vinkje weer aangezet van autostart reboot en dan staat die weer op oude download locatie

[base_]

Mafketel schreef op woensdag 10 oktober 2012 @ 12:39:
...
en ik heb eigenlijk nog nooit gehoord van een hardeschijf die buiten zijn corrupte sectoren niet meer reageert.

Nou bij deze: dat gebeurt echt wel! Soms als je met de stroom erop en volledig aangesloten je heel hard met de schijf op het beton slaat wil ie nog wel eens opspinnen dan....

Losse kabel, niet met je tengels aan de server zitten als die draait en geen oelewapper schijven hotswap laten verwisselen. kans is dan voor mijn gebruik te verwaarlozen.

Server een goeie aai over zijn bol geven kan geen kwaad en hotswappables zijn bedoeld om hot te kunnen swappen (uiteraard horen die wel in een hotswappable behuizing maar met een goeie controller en in de goede volgorde gaat dat ook zonder prima hoor) dus dat is nou net geen probleem (ook stroomstoringen worden meestal zonder problemen overleefd, instabiele/flucturerende spanning gaat echter wel al je harddisks op den duur slopen).

[FireDrunk]

victorb schreef op woensdag 10 oktober 2012 @ 23:59:
CiPHER

Wat ik ook probeer hij springt terug.

Net vinkje uitgezet van autostart - reboot - via ssh en nano config aangepast settings.json - vinkje weer aangezet van autostart reboot en dan staat die weer op oude download locatie

Word de file echt gewijzigd, of zie je in de web interface nog gewoon de oude locatie?

Als de file gewijzigd word, word dat echt door transmission gedaan... niemand anders komt aan die file.
En dus werkt de start/stop/autostart blijkbaar niet helemaal goed.

Als je net opgestart ben, kun je dan eens

netstat -an | grep 9091 

doen?

[ Voor 14% gewijzigd door FireDrunk op 11-10-2012 09:00 ]

[HyperBart]

Of ik lees/interpreteer verkeerd, of er is iets mis met weergave van snapshots:

Ik heb een filesystem genaamd "hulk" met daaronder verschillende subfilesystems voor iedere share (lekker makkelijk en flexibel, kan ik snapshotten per share voor mij).

Ik heb een soort "baseline" snapshot gemaakt, waarvan ik zeker ben dat daar enkele dingen inzitten die voor mij belangrijk zijn...

Na die baseline snapshot ben ik data gaan bijpompen op mijn pool, maar de snapshot viewer van ZFSguru geeft niet aan dat die snapshot aan het groeien is, terwijl dat toch het geval zou moeten zijn, niet?

Ik heb ook al geprobeerd een tweede snapshot te maken (ik dacht: wie weet berekent hij het alleen tussen twee snapshots in en niet tussen snapshot en het heden) maar hij blijft nog steeds als Used = 0 aangeven... Terwijl bij refer wel staat 16,3GB (wat er al onmiddellijk stond na het aanmaken van de snapshot en dat getal kan ik ook niet plaatsen...)

[Verwijderd]

Na die baseline snapshot ben ik data gaan bijpompen op mijn pool, maar de snapshot viewer van ZFSguru geeft niet aan dat die snapshot aan het groeien is, terwijl dat toch het geval zou moeten zijn, niet?

Nee, een snapshot wordt alleen groter als alleen de snapshot bepaalde data referenced. Voorbeeld:

Snapshot groeit in grootte:
1. Je hebt X data, je snapshot die data
2. je verwijdert een paar bestanden, die nu alleen maar door de snapshot worden gereferenced; de usage van de snapshot gaat omhoog. Je krijgt er pas vrije ruimte bij als je het snapshot verwijdert; waarna die verwijderde bestanden pas echt verwijderd zijn en die ruimte beschikbaar komt voor nieuwe dataopslag.

Snapshot blijft op 0 bytes gebruik:
1. Je hebt X data, je snapshot die data
2. Je kopiëert 100GB aan nieuwe data; deze data is niet door de snapshot gereferenced en verandert/overschrijft ook geen bestaande data. De data komt er dus gewoon BIJ als extra. In dat geval blijft je snapshot 0B zeggen.

Snapshot gebruikt dus alleen iets als alleen die snapshot de data 'vasthoudt'. Dus data die door het filesystem zelf niet meer referenced is zoals door de snapshot vastgelegd.

[HyperBart]

Ooooh zo moet je het interpreteren. OK, dan ben ik mee

[HyperBart]

En de REFER dan? Die sprong al onmiddellijk op 16.3...

[FireDrunk]

Dat klopt toch? Je snapshot bevat 16GB aan data...

[Mafketel]

die refer is de hoeveelheid data die zowel in de snapshot als in de reguliere data, of andere snapshot staat.

dus je hebt een 16,3gb data set.
je maakt een snapshot = snapshot refer 16,3 rest 0 data 16,3

je set 1gb extra op de schijf = snapshot refer 16,3 rest 0 data 17,3

je delete 1gb data die ook in de snapshot staat = snapshot refer 15,3 used 1gb data durf ik niet te zeggen maar waarschijnlijk 16,3

[Mafketel]

victorb schreef op woensdag 10 oktober 2012 @ 23:59:
CiPHER

Wat ik ook probeer hij springt terug.

Net vinkje uitgezet van autostart - reboot - via ssh en nano config aangepast settings.json - vinkje weer aangezet van autostart reboot en dan staat die weer op oude download locatie

Heb je voor het veranderen van settings.json met ps gecontroleerd of transmission daadwerkelijk uit stond?
heb je na het veranderen een cat van de settings.json gedaan voor controle.
heb je zonder de transmission autostart weer aan te zetten al een keer gereboot om te controleren of je veranderingen er nog staan?

En even voor mijn info, omdat ik niet 100% weet of zfsguru wel of niet gebruik maakt van een oplossing zoals unionfs. Worden je veranderingen wel op de persisitant storage weggeschreven?

Als je transimission uitzet kan het overigens wel even duren voordat deze daadwerkelijk uitstaat omdat er best nog wel wat moet gebeuren om het netjes te doen.

[HyperBart]

FireDrunk schreef op donderdag 11 oktober 2012 @ 13:27:
Dat klopt toch? Je snapshot bevat 16GB aan data...

Ik had na het maken van de snapshot meer als 16GB aan data er bij gepompt...

[Mafketel]

Verwijderd schreef op woensdag 10 oktober 2012 @ 19:50:
...
dus het werkt nog niet zo stoer als dat het in feite een mirror wordt.

Dit wetende zat ik mij dus even af te vragen hoe vaak dat daadwerkelijk gebeurt en onder wat voor omstandigheden

...
Simpelweg het detecteren van corruptie is dan genoeg; oke prima dan kopiëer ik hem even van mijn andere NAS, zoiets.

Omdat het niet zoiets is van dan kopieer ik het even .... zit ik dus te twijfelen.
Voor de belangrijke data heb ik een externe disk, het staat op mijn laptop, en dus op de server. De minder belangrijke data staat op dvd's cd's en is weer een hoop werk om terug te zetten. Ik heb helaas niet de middelen om een ultrium5 of 4 drive te kopen. En ik geef liever de extra schijf uit aan een ofsite schijf bij iemand anders.

...
Oh en leuk dat bij jou een schijf nog nooit gefaald is, maar daar hoort iets van een disclaimer bij... 'In het verleden behaalde resultaten zijn geen garantie voor de toekomst' ?

Volgens mij heb ik al meerdere keren gezegd dat ik 1 mij er terdege van bewust zijn dat schijven uitvallen, en 2 ik hier meerdere keren mee te maken heb gehad.

HDDs zijn mechanische hooggevoelige apparaten. Die kunnen makkelijk stuk, maar kunnen in een stabiele omgeving ook heel lang prima werken. ...

Fijnmechanisch en geven daardoor als het fijnmechanisch niet helemaal tof meer is waarschuwingssignalen af. Dat is ook waarom ik naar de zip en jazz drives refereerde omdat voorbeelden zijn waar het mechanisch vaak stuk ging.

base_ schreef op donderdag 11 oktober 2012 @ 02:58:
[...]

Nou bij deze: dat gebeurt echt wel! Soms als je met de stroom erop en volledig aangesloten je heel hard met de schijf op het beton slaat wil ie nog wel eens opspinnen dan....

Deze verhalen ken ik, ook zelf met iets dergelijks te maken gehad met een schijf van iemand anders die het na een tijdje opgaf als die te warm werd.
Dit heb ik uiteindelijk opgelost door deze schijf in een externe usb behuizing te proppen een tijdje in de vriezer en osx was niet zo vervelend om alles volledig te laten hangen als er een foutje ontstond. Het grappige is nadat ik alle data van de schijf had(geen zfs dus kan corrupt zijn geweest) de schijf zich weer normaal is gaan gedragen en deze wordt nu weer gebruikt(niet door mij maar door de originele eigenaar).

[...]

Server een goeie aai over zijn bol geven kan geen kwaad en hotswappables zijn bedoeld om hot te kunnen swappen (uiteraard horen die wel in een hotswappable behuizing maar met een goeie controller en in de goede volgorde gaat dat ook zonder prima hoor) dus dat is nou net geen probleem

Ah maar hier verschil ik van mening, er zijn genoeg oeps momenten geweest dat iemand de verkeerde schijf uit een gedegradeerde raid set haalde. Zelf gelukkig niet gedaan maar een collega wel en op het internet ook genoeg verhalen daarover.

(ook stroomstoringen worden meestal zonder problemen overleefd, instabiele/flucturerende spanning gaat echter wel al je harddisks op den duur slopen).

Deze laatste categorie komt vaak voor bij zeer oude gebakjes. En wat ik dan met zeer oud bedoel is machines die richting de fysieke levensduur hebben gedraaid. Vaak korter dan verwacht door te hoge omgevings temperaturen. En als ik naar google zijn resultaten kijk dan refereer ik dus niet naar de temp van de schijven maar van de condensatoren die her en der in systemen zijn gebouwd en vervelende spanningen kunnen veroorzaken.

[HyperBart]

HyperBart schreef op donderdag 11 oktober 2012 @ 14:17:
[...]

Ik had na het maken van de snapshot meer als 16GB aan data er bij gepompt...

Oh wacht

Ik heb het als volgt:
hulk
hulk/share1
hulk/share2

Ik had een snapshot genomen van hulk (ik ga er van uit dat ik dan ook alle systems/shares die op hulk staan ook mee gesnapshotted zijn?) en ik heb daarna data bijgepompt in hulk/share1... Maar dan zou ik verwachten dat die refer op 0 blijft staan en niet naar 16,3GB springt?

[Mafketel]

alleen met -r ook een snapshot van onderliggende zfs

Je kan altijd even bekijken wat in je snapshot staat dor naar die "dir" te gaan

.zfs/snapshot/

en je gaat niet blij zijn met wat je daar ziet staan kan ik je vertellen.

[ Voor 70% gewijzigd door Mafketel op 11-10-2012 14:27 ]

[HyperBart]

OK, dan nu nog alleen de verklaring van het feit dat hij naar 16,3GB al onmiddellijk springt als ik er nog niks bijzet in dat ZFS FS? Das best veel voor gewoon "ff kwijt te zijn" zonder direct aanwijsbare reden

[Verwijderd]

Referenced = hoeveel data de snapshot bevat
Used = hoeveel schijfruimte de snapshot EXTRA in beslag neemt, buiten de parent dataset (filesystem)

filesystem 'tank' kan helemaal leeg zijn maar een 'tank/data' filesystem hebben waar wel veel op staat. Dan geldt voor 'tank': used: 0, referenced: 200GB

Ga je nu 'tank/data' snapshotten, dan gebruikt de snapshot in het begin nog niets omdat hij niet afwijkt van de dataset. Dus zie je used: 0, referenced: 200GB. Ga je nu alle bestanden verwijderen, dan worden deze alleen nog door de snapshot vastgehouden (referenced). Dan zie je dus: used: 200GB, referenced: 200GB voor de snapshot, terwijl de filesystem zelf vrijwel niets meer gebruikt.

De 'used' is dus waar je moet kijken. Als die op 0 staat, kost de snapshot ook geen ruimte. Als jij een groot 10GB bestand overschrijft nadat je een snapshot hebt gemaakt, moet mogelijk data dubbel opgeslagen worden; de snapshot moet de oude versie opslaan de filesystem slaat de nieuwe versie op. Als de nieuwe versie grotendeels overeenkomt met de oude versie, hoeft er ook maar een klein beetje extra data worden opgeslagen. Als de nieuwe versie totaal verschillend is, dan zal de snapshot 10GB extra diskruimte vergen omdat zowel de oude als nieuwe 10GB file ergens opgeslagen moeten zijn. De nieuwe versie wordt dan onder 'used' van het filesystem weergegeven, terwijl de snapshot de oude versie in 'used' voor zijn kiezen krijgt.

Snap je het zo een beetje? Anders speel wat met snapshots en je begrijpt het vast wel als je wat dingen uitprobeert.

[Mafketel]

Verwijderd schreef op donderdag 11 oktober 2012 @ 14:39:
...
filesystem 'tank' kan helemaal leeg zijn maar een 'tank/data' filesystem hebben waar wel veel op staat. Dan geldt voor 'tank': used: 0, referenced: 200GB
...

hmmm dat komt niet helemaal overeen wat ik hier zie staan.


tank used 3.52T refer 55.9K

vervolgens staat alle data in aparte filesystemen.

snapshot van tank van vorig jaar

tank@vorigjaar used 30.4K refer 54.3k

oftewel ik heb wat directory's veranderd als ik het zo zie.
Als ik in de tank/.zfs/snapshots/vorigjaar kijk staan daar ook alleen de directories waar dan weer de andere filesystemen gemount worden.

voor de rest klopt het wel. Ik heb het idee opgegeven dat ik zfs ooit echt volledig zal snappen, elke keer is er toch weer een verassing met een waarde of gedrag dat toch weer net anders is dan wat je voorspelt

[ Voor 13% gewijzigd door Mafketel op 11-10-2012 15:33 ]

[HyperBart]

Nog een heel rare, disk usage op de QNAP:

[/share/vmware] # ls -lahR
.:
drwxrwxrwx    8 admin    administ     4.0k Jun 26 17:06 ./
drwxrwxrwx   33 admin    administ     4.0k Dec  6  2011 ../
drwxr-xr-x    2 admin    administ     4.0k Sep 28  2011 HV1/
drwxr-xr-x    2 admin    administ     4.0k Sep 28  2011 HV2/
drwxrwxrwx    2 bart     everyone     4.0k Jul 17 17:07 ISO's/
drwxr-xr-x    2 admin    administ     4.0k Jun 26 17:27 Kbot-xp/
drwxr-xr-x    2 admin    administ     4.0k Sep 26  2011 W2K8R2E_TEMPLATE_BASEMENT/
drwxr-xr-x    2 admin    administ     4.0k Sep 28  2011 W2K8R2_STORAGE/

./HV1:
drwxr-xr-x    2 admin    administ     4.0k Sep 28  2011 ./
drwxrwxrwx    8 admin    administ     4.0k Jun 26 17:06 ../
-rw-------    1 admin    administ    20.0G Sep 28  2011 HV1-flat.vmdk
-rw-------    1 admin    administ     8.5k Sep 28  2011 HV1.nvram
-rw-------    1 admin    administ      513 Sep 28  2011 HV1.vmdk
-rw-r--r--    1 admin    administ        0 Sep 28  2011 HV1.vmsd
-rwxr-xr-x    1 admin    administ     4.2k Sep 28  2011 HV1.vmx*
-rw-r--r--    1 admin    administ      258 Sep 28  2011 HV1.vmxf
-rw-------    1 admin    administ   828.0k Sep 28  2011 vmware-1.log
-rw-------    1 admin    administ   171.3k Sep 28  2011 vmware-2.log
-rw-------    1 admin    administ   197.5k Sep 28  2011 vmware-3.log
-rw-------    1 admin    administ   179.8k Sep 28  2011 vmware-4.log
-rw-------    1 admin    administ   128.4k Sep 28  2011 vmware-5.log
-rw-------    1 admin    administ   135.6k Sep 28  2011 vmware-6.log
-rw-------    1 admin    administ   119.1k Sep 28  2011 vmware.log

./HV2:
drwxr-xr-x    2 admin    administ     4.0k Sep 28  2011 ./
drwxrwxrwx    8 admin    administ     4.0k Jun 26 17:06 ../
-rw-------    1 admin    administ    20.0G Sep 28  2011 HV2-flat.vmdk
-rw-------    1 admin    administ     8.5k Sep 28  2011 HV2.nvram
-rw-------    1 admin    administ      513 Sep 28  2011 HV2.vmdk
-rw-r--r--    1 admin    administ        0 Sep 28  2011 HV2.vmsd
-rwxr-xr-x    1 admin    administ     4.2k Sep 28  2011 HV2.vmx*
-rw-r--r--    1 admin    administ      258 Sep 28  2011 HV2.vmxf
-rw-------    1 admin    administ   135.0k Sep 28  2011 vmware-0.log
-rw-------    1 admin    administ  1022.4k Sep 28  2011 vmware-1.log
-rw-------    1 admin    administ   180.1k Sep 28  2011 vmware-2.log
-rw-------    1 admin    administ   126.8k Sep 28  2011 vmware-3.log
-rw-------    1 admin    administ   131.9k Sep 28  2011 vmware-4.log
-rw-------    1 admin    administ   103.8k Sep 28  2011 vmware-5.log
-rw-------    1 admin    administ   104.7k Sep 28  2011 vmware.log

./ISO's:
drwxrwxrwx    2 bart     everyone     4.0k Jul 17 17:07 ./
drwxrwxrwx    8 admin    administ     4.0k Jun 26 17:06 ../
-rw-rw-rw-    1 bart     everyone     2.8G Nov  2  2009 DVD5_Windows_Svr_DC_EE_SE_Web_2008R2_64-bit_English_X15-59754.ISO
-rwxrw-rw-    1 bart     everyone   590.3M Jul 28  2011 NexentaStor-Community-3.1.0.iso*
-rwxrw-rw-    1 bart     everyone   588.7M Apr 21  2011 NexentaStor-Enterprise-3.0.5.iso*
-rw-rw-rw-    1 bart     everyone     2.5G Sep 12  2011 VMware-vsa-en-1.0.0.6-458467.iso
-rw-rw-rw-    1 bart     everyone   276.3M Jul 16 14:32 ZFSguru-0.2.0-beta4-livecd-amd64.iso
-rw-rw-rw-    1 bart     everyone     4.2G Jun 12 20:27 en_sql_server_2012_enterprise_edition_x86_x64_dvd_813294.iso
-rw-rw-rw-    1 bart     everyone     4.2G Jun 12 21:01 en_sql_server_2012_standard_edition_x86_x64_dvd_813403.iso
-rw-rw-rw-    1 bart     everyone     3.0G May  5  2011 en_windows_7_enterprise_with_SP1_x64_dvd.iso
-rw-rw-rw-    1 bart     everyone     2.2G Sep  2  2009 en_windows_7_enterprise_x86_dvd_x15-70745.iso
-rw-rw-rw-    1 bart     everyone     2.3G Sep  1  2009 en_windows_7_professional_x86_dvd_x15-65804.iso
-rwxrw-rw-    1 bart     everyone   458.9M Aug 15  2011 oi-dev-148-text-x86.iso*
-rw-rw-rw-    1 bart     everyone   490.6M Apr  4  2012 oi-dev-151a-text-x86.iso
-rwxrw-rw-    1 bart     everyone   673.6M May 23  2011 ubuntu-11.04-server-amd64.iso*
-rwxrw-rw-    1 bart     everyone   654.7M May 23  2011 ubuntu-11.04-server-i386.iso*
-rw-rw-rw-    1 bart     everyone   684.3M May 24 23:20 ubuntu-12.04-server-amd64.iso
-rw-rw-rw-    1 bart     everyone     2.3G Aug 23  2011 zvcentr5.iso

./Kbot-xp:
drwxr-xr-x    2 admin    administ     4.0k Jun 26 17:27 ./
drwxrwxrwx    8 admin    administ     4.0k Jun 26 17:06 ../
-rw-------    1 admin    administ       13 Jun 26 17:27 Kbot-aux.xml
-rw-------    1 admin    administ    15.0G Jun 26 17:27 Kbot-flat.vmdk
-rw-------    1 admin    administ     8.5k Jun 26 17:27 Kbot.nvram
-rw-------    1 admin    administ      509 Jun 26 17:27 Kbot.vmdk
-rw-r--r--    1 admin    administ        0 Jun 26 17:27 Kbot.vmsd
-rwxr-xr-x    1 admin    administ     3.9k Jun 26 17:27 Kbot.vmx*
-rw-r--r--    1 admin    administ      259 Jun 26 17:27 Kbot.vmxf
-rw-------    1 admin    administ    50.0G Jun 26 17:17 Kbot_1-flat.vmdk
-rw-------    1 admin    administ      543 Jun 26 17:17 Kbot_1.vmdk
-rw-------    1 admin    administ   100.0G Jun 26 17:23 Kbot_2-flat.vmdk
-rw-------    1 admin    administ      518 Jun 26 17:23 Kbot_2.vmdk
-rw-------    1 admin    administ    71.6k Jun 26 17:27 vmware-39.log
-rw-------    1 admin    administ   146.3k Jun 26 17:27 vmware-40.log
-rw-------    1 admin    administ   139.6k Jun 26 17:27 vmware-41.log
-rw-------    1 admin    administ   113.9k Jun 26 17:27 vmware-42.log
-rw-------    1 admin    administ   116.3k Jun 26 17:27 vmware-43.log
-rw-------    1 admin    administ   129.0k Jun 26 17:27 vmware-44.log
-rw-------    1 admin    administ    30.8k Jun 26 17:27 vmware.log

./W2K8R2E_TEMPLATE_BASEMENT:
drwxr-xr-x    2 admin    administ     4.0k Sep 26  2011 ./
drwxrwxrwx    8 admin    administ     4.0k Jun 26 17:06 ../
-rw-------    1 admin    administ    40.0G Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT-flat.vmdk
-rw-------    1 admin    administ     8.5k Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT.nvram
-rw-------    1 admin    administ      561 Sep 26  2011 W2K8R2E_TEMPLATE_BASEMENT.vmdk
-rw-r--r--    1 admin    administ        0 Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT.vmsd
-rwxr-xr-x    1 admin    administ     2.8k Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT.vmtx*
-rw-r--r--    1 admin    administ      280 Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT.vmxf
-rw-r--r--    1 admin    administ   677.4k Sep 20  2011 vmware-1.log
-rw-r--r--    1 admin    administ   266.3k Sep 20  2011 vmware-2.log
-rw-r--r--    1 admin    administ   299.6k Sep 20  2011 vmware-3.log
-rw-r--r--    1 admin    administ     9.8M Sep 20  2011 vmware.log

./W2K8R2_STORAGE:
drwxr-xr-x    2 admin    administ     4.0k Sep 28  2011 ./
drwxrwxrwx    8 admin    administ     4.0k Jun 26 17:06 ../
-rw-------    1 admin    administ    40.0G Sep 28  2011 W2K8R2_STORAGE-flat.vmdk
-rw-------    1 admin    administ     8.5k Sep 28  2011 W2K8R2_STORAGE.nvram
-rw-------    1 admin    administ      550 Sep 28  2011 W2K8R2_STORAGE.vmdk
-rw-r--r--    1 admin    administ        0 Sep 28  2011 W2K8R2_STORAGE.vmsd
-rwxr-xr-x    1 admin    administ     3.2k Sep 28  2011 W2K8R2_STORAGE.vmx*
-rw-r--r--    1 admin    administ      269 Sep 28  2011 W2K8R2_STORAGE.vmxf
-rw-------    1 admin    administ   100.0G Sep 28  2011 W2K8R2_STORAGE_1-flat.vmdk
-rw-------    1 admin    administ      528 Sep 28  2011 W2K8R2_STORAGE_1.vmdk
-rw-------    1 admin    administ   677.4k Sep 28  2011 vmware-1.log
-rw-------    1 admin    administ   266.3k Sep 28  2011 vmware-2.log
-rw-------    1 admin    administ   299.6k Sep 28  2011 vmware-3.log
-rw-------    1 admin    administ     9.8M Sep 28  2011 vmware-4.log
-rw-------    1 admin    administ   845.6k Sep 28  2011 vmware-5.log
-rw-------    1 admin    administ   329.8k Sep 28  2011 vmware.log
[/share/vmware] # du -h
4.6G    ./HV2
28G     ./ISO's
45G     ./Kbot-xp
15G     ./W2K8R2_STORAGE
8.8G    ./W2K8R2E_TEMPLATE_BASEMENT
4.6G    ./HV1
105G    .
[/share/vmware] # cd HV2
[/share/vmware/HV2] # du -h
4.6G    .
[/share/vmware/HV2] # ls -la
drwxr-xr-x    2 admin    administ     4096 Sep 28  2011 ./
drwxrwxrwx    8 admin    administ     4096 Jun 26 17:06 ../
-rw-------    1 admin    administ21474836480 Sep 28  2011 HV2-flat.vmdk
-rw-------    1 admin    administ     8684 Sep 28  2011 HV2.nvram
-rw-------    1 admin    administ      513 Sep 28  2011 HV2.vmdk
-rw-r--r--    1 admin    administ        0 Sep 28  2011 HV2.vmsd
-rwxr-xr-x    1 admin    administ     4345 Sep 28  2011 HV2.vmx*
-rw-r--r--    1 admin    administ      258 Sep 28  2011 HV2.vmxf
-rw-------    1 admin    administ   138228 Sep 28  2011 vmware-0.log
-rw-------    1 admin    administ  1046900 Sep 28  2011 vmware-1.log
-rw-------    1 admin    administ   184418 Sep 28  2011 vmware-2.log
-rw-------    1 admin    administ   129859 Sep 28  2011 vmware-3.log
-rw-------    1 admin    administ   135066 Sep 28  2011 vmware-4.log
-rw-------    1 admin    administ   106297 Sep 28  2011 vmware-5.log
-rw-------    1 admin    administ   107166 Sep 28  2011 vmware.log
[/share/vmware/HV2] # ls -lah
drwxr-xr-x    2 admin    administ     4.0k Sep 28  2011 ./
drwxrwxrwx    8 admin    administ     4.0k Jun 26 17:06 ../
-rw-------    1 admin    administ    20.0G Sep 28  2011 HV2-flat.vmdk
-rw-------    1 admin    administ     8.5k Sep 28  2011 HV2.nvram
-rw-------    1 admin    administ      513 Sep 28  2011 HV2.vmdk
-rw-r--r--    1 admin    administ        0 Sep 28  2011 HV2.vmsd
-rwxr-xr-x    1 admin    administ     4.2k Sep 28  2011 HV2.vmx*
-rw-r--r--    1 admin    administ      258 Sep 28  2011 HV2.vmxf
-rw-------    1 admin    administ   135.0k Sep 28  2011 vmware-0.log
-rw-------    1 admin    administ  1022.4k Sep 28  2011 vmware-1.log
-rw-------    1 admin    administ   180.1k Sep 28  2011 vmware-2.log
-rw-------    1 admin    administ   126.8k Sep 28  2011 vmware-3.log
-rw-------    1 admin    administ   131.9k Sep 28  2011 vmware-4.log
-rw-------    1 admin    administ   103.8k Sep 28  2011 vmware-5.log
-rw-------    1 admin    administ   104.7k Sep 28  2011 vmware.log
[/share/vmware/HV2] # cd ..
[/share/vmware] # du -h
4.6G    ./HV2
28G     ./ISO's
45G     ./Kbot-xp
15G     ./W2K8R2_STORAGE
8.8G    ./W2K8R2E_TEMPLATE_BASEMENT
4.6G    ./HV1
105G    .

Disk usage op ZFSguru:

[ssh@zfsguru /hulk/VMware]$ ls -lahR
total 28
drwxrwxrwx   8 share   share     8B Oct 11 08:57 ./
drwxr-xr-x  11 share   share    11B Oct 11 13:16 ../
drwxr-xr-x   2 nobody  share    15B Sep 28  2011 HV1/
drwxr-xr-x   2 nobody  share    15B Sep 28  2011 HV2/
drwxrwxrwx   2 nobody  share    18B Jul 17 15:07 ISO's/
drwxr-xr-x   2 nobody  share    20B Jun 26 15:27 Kbot-xp/
drwxr-xr-x   2 nobody  share    12B Sep 26  2011 W2K8R2E_TEMPLATE_BASEMENT/
drwxr-xr-x   2 nobody  share    16B Sep 28  2011 W2K8R2_STORAGE/

./HV1:
total 20950082
drwxr-xr-x  2 nobody  share    15B Sep 28  2011 ./
drwxrwxrwx  8 share   share     8B Oct 11 08:57 ../
-rw-------  1 nobody  share    20G Sep 28  2011 HV1-flat.vmdk
-rw-------  1 nobody  share   8.5k Sep 28  2011 HV1.nvram
-rw-------  1 nobody  share   513B Sep 28  2011 HV1.vmdk
-rw-r--r--  1 nobody  share     0B Sep 28  2011 HV1.vmsd
-rwxr-xr-x  1 nobody  share   4.2k Sep 28  2011 HV1.vmx*
-rw-r--r--  1 nobody  share   258B Sep 28  2011 HV1.vmxf
-rw-------  1 nobody  share   828k Sep 28  2011 vmware-1.log
-rw-------  1 nobody  share   171k Sep 28  2011 vmware-2.log
-rw-------  1 nobody  share   197k Sep 28  2011 vmware-3.log
-rw-------  1 nobody  share   179k Sep 28  2011 vmware-4.log
-rw-------  1 nobody  share   128k Sep 28  2011 vmware-5.log
-rw-------  1 nobody  share   135k Sep 28  2011 vmware-6.log
-rw-------  1 nobody  share   119k Sep 28  2011 vmware.log

./HV2:
total 20950007
drwxr-xr-x  2 nobody  share    15B Sep 28  2011 ./
drwxrwxrwx  8 share   share     8B Oct 11 08:57 ../
-rw-------  1 nobody  share    20G Sep 28  2011 HV2-flat.vmdk
-rw-------  1 nobody  share   8.5k Sep 28  2011 HV2.nvram
-rw-------  1 nobody  share   513B Sep 28  2011 HV2.vmdk
-rw-r--r--  1 nobody  share     0B Sep 28  2011 HV2.vmsd
-rwxr-xr-x  1 nobody  share   4.2k Sep 28  2011 HV2.vmx*
-rw-r--r--  1 nobody  share   258B Sep 28  2011 HV2.vmxf
-rw-------  1 nobody  share   135k Sep 28  2011 vmware-0.log
-rw-------  1 nobody  share     1M Sep 28  2011 vmware-1.log
-rw-------  1 nobody  share   180k Sep 28  2011 vmware-2.log
-rw-------  1 nobody  share   126k Sep 28  2011 vmware-3.log
-rw-------  1 nobody  share   131k Sep 28  2011 vmware-4.log
-rw-------  1 nobody  share   103k Sep 28  2011 vmware-5.log
-rw-------  1 nobody  share   104k Sep 28  2011 vmware.log

./ISO's:
total 29202120
drwxrwxrwx  2 nobody  share    18B Jul 17 15:07 ./
drwxrwxrwx  8 share   share     8B Oct 11 08:57 ../
-rw-rw-rw-  1 nobody  share   2.8G Nov  2  2009 DVD5_Windows_Svr_DC_EE_SE_Web_2008R2_64-bit_English_X15-59754.ISO
-rwxrw-rw-  1 nobody  share   590M Jul 28  2011 NexentaStor-Community-3.1.0.iso*
-rwxrw-rw-  1 nobody  share   588M Apr 21  2011 NexentaStor-Enterprise-3.0.5.iso*
-rw-rw-rw-  1 nobody  share   2.6G Sep 12  2011 VMware-vsa-en-1.0.0.6-458467.iso
-rw-rw-rw-  1 nobody  share   276M Jul 16 12:32 ZFSguru-0.2.0-beta4-livecd-amd64.iso
-rw-rw-rw-  1 nobody  share   4.2G Jun 12 18:27 en_sql_server_2012_enterprise_edition_x86_x64_dvd_813294.iso
-rw-rw-rw-  1 nobody  share   4.2G Jun 12 19:01 en_sql_server_2012_standard_edition_x86_x64_dvd_813403.iso
-rw-rw-rw-  1 nobody  share     3G May  5  2011 en_windows_7_enterprise_with_SP1_x64_dvd.iso
-rw-rw-rw-  1 nobody  share   2.2G Sep  2  2009 en_windows_7_enterprise_x86_dvd_x15-70745.iso
-rw-rw-rw-  1 nobody  share   2.3G Sep  1  2009 en_windows_7_professional_x86_dvd_x15-65804.iso
-rwxrw-rw-  1 nobody  share   458M Aug 15  2011 oi-dev-148-text-x86.iso*
-rw-rw-rw-  1 nobody  share   490M Apr  4  2012 oi-dev-151a-text-x86.iso
-rwxrw-rw-  1 nobody  share   673M May 23  2011 ubuntu-11.04-server-amd64.iso*
-rwxrw-rw-  1 nobody  share   654M May 23  2011 ubuntu-11.04-server-i386.iso*
-rw-rw-rw-  1 nobody  share   684M May 24 21:20 ubuntu-12.04-server-amd64.iso
-rw-rw-rw-  1 nobody  share   2.3G Aug 23  2011 zvcentr5.iso

./Kbot-xp:
total 172824936
drwxr-xr-x  2 nobody  share    20B Jun 26 15:27 ./
drwxrwxrwx  8 share   share     8B Oct 11 08:57 ../
-rw-------  1 nobody  share    13B Jun 26 15:27 Kbot-aux.xml
-rw-------  1 nobody  share    15G Jun 26 15:27 Kbot-flat.vmdk
-rw-------  1 nobody  share   8.5k Jun 26 15:27 Kbot.nvram
-rw-------  1 nobody  share   509B Jun 26 15:27 Kbot.vmdk
-rw-r--r--  1 nobody  share     0B Jun 26 15:27 Kbot.vmsd
-rwxr-xr-x  1 nobody  share   3.9k Jun 26 15:27 Kbot.vmx*
-rw-r--r--  1 nobody  share   259B Jun 26 15:27 Kbot.vmxf
-rw-------  1 nobody  share    50G Jun 26 15:17 Kbot_1-flat.vmdk
-rw-------  1 nobody  share   543B Jun 26 15:17 Kbot_1.vmdk
-rw-------  1 nobody  share   100G Jun 26 15:23 Kbot_2-flat.vmdk
-rw-------  1 nobody  share   518B Jun 26 15:23 Kbot_2.vmdk
-rw-------  1 nobody  share    71k Jun 26 15:27 vmware-39.log
-rw-------  1 nobody  share   146k Jun 26 15:27 vmware-40.log
-rw-------  1 nobody  share   139k Jun 26 15:27 vmware-41.log
-rw-------  1 nobody  share   113k Jun 26 15:27 vmware-42.log
-rw-------  1 nobody  share   116k Jun 26 15:27 vmware-43.log
-rw-------  1 nobody  share   129k Jun 26 15:27 vmware-44.log
-rw-------  1 nobody  share    30k Jun 26 15:27 vmware.log

./W2K8R2E_TEMPLATE_BASEMENT:
total 41907050
drwxr-xr-x  2 nobody  share    12B Sep 26  2011 ./
drwxrwxrwx  8 share   share     8B Oct 11 08:57 ../
-rw-------  1 nobody  share    40G Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT-flat.vmdk
-rw-------  1 nobody  share   8.5k Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT.nvram
-rw-------  1 nobody  share   561B Sep 26  2011 W2K8R2E_TEMPLATE_BASEMENT.vmdk
-rw-r--r--  1 nobody  share     0B Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT.vmsd
-rwxr-xr-x  1 nobody  share   2.9k Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT.vmtx*
-rw-r--r--  1 nobody  share   280B Sep 20  2011 W2K8R2E_TEMPLATE_BASEMENT.vmxf
-rw-r--r--  1 nobody  share   677k Sep 20  2011 vmware-1.log
-rw-r--r--  1 nobody  share   266k Sep 20  2011 vmware-2.log
-rw-r--r--  1 nobody  share   299k Sep 20  2011 vmware-3.log
-rw-r--r--  1 nobody  share   9.8M Sep 20  2011 vmware.log

./W2K8R2_STORAGE:
total 146636702
drwxr-xr-x  2 nobody  share    16B Sep 28  2011 ./
drwxrwxrwx  8 share   share     8B Oct 11 08:57 ../
-rw-------  1 nobody  share    40G Sep 28  2011 W2K8R2_STORAGE-flat.vmdk
-rw-------  1 nobody  share   8.5k Sep 28  2011 W2K8R2_STORAGE.nvram
-rw-------  1 nobody  share   550B Sep 28  2011 W2K8R2_STORAGE.vmdk
-rw-r--r--  1 nobody  share     0B Sep 28  2011 W2K8R2_STORAGE.vmsd
-rwxr-xr-x  1 nobody  share   3.2k Sep 28  2011 W2K8R2_STORAGE.vmx*
-rw-r--r--  1 nobody  share   269B Sep 28  2011 W2K8R2_STORAGE.vmxf
-rw-------  1 nobody  share   100G Sep 28  2011 W2K8R2_STORAGE_1-flat.vmdk
-rw-------  1 nobody  share   528B Sep 28  2011 W2K8R2_STORAGE_1.vmdk
-rw-------  1 nobody  share   677k Sep 28  2011 vmware-1.log
-rw-------  1 nobody  share   266k Sep 28  2011 vmware-2.log
-rw-------  1 nobody  share   299k Sep 28  2011 vmware-3.log
-rw-------  1 nobody  share   9.8M Sep 28  2011 vmware-4.log
-rw-------  1 nobody  share   845k Sep 28  2011 vmware-5.log
-rw-------  1 nobody  share   329k Sep 28  2011 vmware.log
[ssh@zfsguru /hulk/VMware]$ du -h
164G    ./Kbot-xp
 20G    ./HV1
 40G    ./W2K8R2E_TEMPLATE_BASEMENT
 20G    ./HV2
139G    ./W2K8R2_STORAGE
 27G    ./ISO's
412G    .
[ssh@zfsguru /hulk/VMware]$ du -h
164G    ./Kbot-xp
 20G    ./HV1
 40G    ./W2K8R2E_TEMPLATE_BASEMENT
 20G    ./HV2
139G    ./W2K8R2_STORAGE
 27G    ./ISO's
412G    .
[ssh@zfsguru /hulk/VMware]$

Is zo maar even maal 4 gegaan qua gebruik... .

[Verwijderd]

File size != Disk usage

'du' geeft disk usage aan. Dat houdt dus verband met veel zaken als 'slack' (verspilling) door LBA->character conversie zodat een bestand van 1 byte al 4KiB inneemt. Maar ook zaken als compressie en deduplicatie, die de grootte juist verkleinen. Dan heb je weer copies=2 (ditto copies). Als je dat inschakelt en je schrijft daarna een bestand van 10GB, dan krijg je met du 20GB te zien, want het kost 20GB disk space om dat 10GB bestand met copies=2 weg te schrijven. Logisch, als je het zo bekijkt.

Bekijk het verschil tussen file size en disk usage met de du -A optie, dus:

du -sh /dir = disk usage, wat kost het qua opslagruimte
du -Ash /dir = total file size, hoe groot zijn alle bestanden exact, ongeacht hoeveel het me kost om ze op te slaan

@Mafketel: jij pakt een filesystem met children; in mijn voorbeeld juist niet omdat dat het nog compelxer maakt en staat los van wat we hadden besproken. Een dataset met children (sub filesystems of volumes) heeft bijvoorbeeld tegen de 0B aan referenced maar wel 20GB used. Dan zit die 20GB hem in de children datasets, het filesystem zelf slaat dan vrijwel niets op en zegt 31.5K ofzoiets.

[ Voor 20% gewijzigd door Verwijderd op 11-10-2012 18:03 ]

[Mafketel]

Ik dacht toch echt dat je tank bedoelde met daar het data filesysteem in en dus nam ik aan dat het een kind was.

Maar wat ik al zei ik heb het opgegeven om deze dingen tot de bodem uit te zoeken.

[HyperBart]

Verwijderd schreef op donderdag 11 oktober 2012 @ 18:02:
File size != Disk usage

'du' geeft disk usage aan. Dat houdt dus verband met veel zaken als 'slack' (verspilling) door LBA->character conversie zodat een bestand van 1 byte al 4KiB inneemt. Maar ook zaken als compressie en deduplicatie, die de grootte juist verkleinen. Dan heb je weer copies=2 (ditto copies). Als je dat inschakelt en je schrijft daarna een bestand van 10GB, dan krijg je met du 20GB te zien, want het kost 20GB disk space om dat 10GB bestand met copies=2 weg te schrijven. Logisch, als je het zo bekijkt.

Bekijk het verschil tussen file size en disk usage met de du -A optie, dus:

du -sh /dir = disk usage, wat kost het qua opslagruimte
du -Ash /dir = total file size, hoe groot zijn alle bestanden exact, ongeacht hoeveel het me kost om ze op te slaan

Ja ok, ik snap dat file size niet noodzakelijk gelijk is aan disk usage, maar je maakt me ook niet wijs dat een file die op een simpele QNAP, zonder speciale dingen zoals dedup of whatever ineens zoveel meer inneemt op een ZFS-systeem waar OOK niets bijzonders op actief is zoals copies=2...

[ssh@zfsguru /hulk/VMware]$ du -sh
412G    .
[ssh@zfsguru /hulk/VMware]$ du -Ash
412G    .

[Verwijderd]

Ik denk dat ik het al weet.. even een gokje: je gebruikt thin provisioning in je grote datafiles. Dus kostte het ook maar beperkt ruimte op je QNAP ook al waren de bestanden zelf heel groot. Want hoe kan je QNAP aangeven 110GB als één dir ik al 100GB + 40GB bestanden zie? Juist.. thin provisioning. Dan denk ik aan VM images.

Nu je die bestanden zomaar gaat kopiëren ga je bij ZFS dus wel de volledige ruimte innemen. In dit geval is het enablen van compressie een goede manier. Maar ik denk dat jij niet zoveel filesystems gebruikt? Je hebt alleen een 'share' filesystem? Als je meer filesystems aanmaakt (dus VMware map ook een filesystem) dan heb je meer controle over settings als compressie en zelfs dedup. Als je allemaal Linux images in één filesystem opslaat en je enabled daar dedup, kun je flink winst boeken zolang die images maar niet zo groot worden dat de deduptables ook groot worden. dus heel specifiek opties enablen voor specifieke data, dat kan heel winstgevend zijn en is vrij makkelijk met ZFS.

[HyperBart]

Ik had een DM klaarstaan voor je om dat te verklaren en het zijn inderdaad VMDK's die thin provisioned zijn...

Oh jawel, ik gebruik voor al mijn shares aparte filesystems, daardoor was er toen we over dat snapshotting verhaal bezig waren ook verwarring, maar dat kwam omdat ik op HULK een snapshot zonder -R had genomen terwijl ik wel data aan het veranderen was in het filesysteem /hulk/BestandenBart/

Ik denk dat ik een bugje heb:

Ik heb ZFSguru een statisch IP adres gegeven via rc.conf, ook een gateway ingevuld en resolv.conf in orde gemaakt. Wat pings getest en de foutmeldingen in de webgui dat ik geen internet had (omdat er geen gateway en resolv was geconfigureerd) waren ook weg, mooi . Tijd om VirtualBox te installeren:

Netjes gedaan via de webGUI en gelet op het feit dat ik maar één keer mocht klikken op die knop "installeren met die handel", maar nu blijft de browser spinnen en geraak ik niet meer op de webinterface...

(ping antwoordt nog wel)

Nevermind: hij deed er gewoon redelijk lang over

Vorige keer ging dat echt als een fluitje van een cent, nu open ik de Virtualbox mgmt pagina:

PHP does not have SOAP extensions enabled

[ Voor 50% gewijzigd door HyperBart op 13-10-2012 13:01 ]

[Verwijderd]

Jullie vergeten altijd op Restart webserver te klikken na de installatie, veel mensen zien het feedback balkje bovenaan over het hoofd waarin staat dat je de webserver moet herstarten inclusief een knop om dat gelijk te doen.

Services installeren werkt een stuk beter/makkelijker met beta8. En ik hoop dat Jason wat doet aan die restart webserver knop, want velen lijken die over het hoofd te zien.

[HyperBart]

Verwijderd schreef op zaterdag 13 oktober 2012 @ 15:10:
Jullie vergeten altijd op Restart webserver te klikken na de installatie, veel mensen zien het feedback balkje bovenaan over het hoofd waarin staat dat je de webserver moet herstarten inclusief een knop om dat gelijk te doen.

Services installeren werkt een stuk beter/makkelijker met beta8. En ik hoop dat Jason wat doet aan die restart webserver knop, want velen lijken die over het hoofd te zien.

Haha, schitterend dat de dingen die mensen tegenkomen dat je altijd direct weet waar dat aan ligt... Bewijst voor mij eigenlijk dat de basis goed is, maar de presentatie misschien soms beter kan voor gebruikers en het feit dat jullie er van op de hoogte zijn... Komt er op neer: wat jullie er in steken, de core werkt, alleen zitten er in het activeren of gebruiken ervan soms wat losse eindjes.

(PS: dit is als compliment bedoeld, serieus)

[Verwijderd]

Beta8 werkt een stuk netter qua service installaties, dan hoef je ook niet lang te wachten totdat je browser een pagina laadt maar krijg je netjes te zien dat service X op de achtergrond geinstalleerd of gedownload wordt en je kunt meerdere services tegelijkertijd downloaden en installeren.

Dit is geen luxe met grote X services die soms wel lang duren voordat ze geïnstalleerd zijn. De gebruiker is niet gewend om lange laadtijden te zien voor een lokale pagina. Dus hoe het in beta8 is geregeld is stukken beter en Jason wil de X services ook pas vanaf beta8 introduceren/ondersteunen.

[analog_]

Ik was pas wat aan het nadenken over zil devices en wat de mogelijkheden zijn voor implementatie ervan.

• sata/sas disks
• sata/sas ssds
• pci-e ssds (ocz, gigabyte ddr ding)
• pci ramdrives (fusion io)
• sata ram drives (adata iodrive x1)

Nut schrapt sata en sas disks. Wat er overblijft is te duur of niet snel genoeg in vergelijking met conventionele ssd's (arrays). De knutselaar in mij bedacht dat ram drives weliswaar niet persistent zijn maar wel sneller dan vrijwel alles vermeld en vooral relatief goedkoop (ram kost geen drol). Om persistentie toe te voegen moet er ofwel op één of andere manier deze 'staat' bewaren. Ik bedacht toen dat een tweede 'persistente' ramdrive in raid 1 zou voldoen, zolang de tweede drive niet faalt. De tweede drive zou je kunnen implementeren met een opslag device (ssd) maar hierdoor zou de performantie instorten (naar het niveau van de traagste paar), wat ik mij bedacht is dat een tweede toestel eenzelfde ramdrive zou moeten hebben gedeeld over iets 'snels' zodat de performance van het geheugen niet teveel instort. Volgens mij zou dus infiniband met rdma moeten volstaan. Samengevat: een cluster een kleine zfs machines met zil's bestaande uit een raidset met één (of meerdere) lokale ram drive(s) en één (of meerdere) via iscsi gedeelde ramdrives op andere machines. Elke machine zou vervolgens met een individuele UPS uitgerust moeten worden.

Blijkt dat ik niet de eerste was en vier jaar geleden het idee al bedacht en gevalideerd is. Ik heb dus besloten om mijn aankoop plannen wat te wijzigen zodat ik twee of meer storage nodes kan aanschaffen en dit uit te proberen.

ps. heb benchmarks van vier crucial m4's met een LSI 9265-8i gepost in DIY RAID thread, >2GB/s read/writes. Heb echter wat moeite met openindiana, LSI 9211-8i en deze SSDs om te benchen met ZFS. Bizar.

[ Voor 5% gewijzigd door analog_ op 14-10-2012 01:07 ]

[sphere]

Hoe groot moet de array worden en hoe groot de ZIL? Wij halen onder windows 7 lang geen 800MB/s met 10G Infiniband maar het is een hele fijne oplossing en redelijk goedkoop op eBay te krijgen.

[sloth]

Ik test op dit moment verschillende NAS OS' met ZFS ondersteuning, waaronder FreeNAS en NAS4Free.

Voor ik alle belangrijke data overpomp wil ik zeker zijn dat alles stabiel werkt, en de hoogste mogelijke performance gehaald wordt.
Daarnet heb ik wat file transfer tests gedaan, met een m.i. rare uitkomst.

Beide zijn via FTP gedaan, tussen dezelfde hosts en met dezelfde instellingen.

1. Read transfer test via FTP naar een client (download)



2. Write transfer test via FTP vanaf een client (upload)



Algemeen is het sneller te lezen van een disk dan ernaar te schrijven. In die zin is het niet logisch dat de downloadsnelheid lager is dan de uploadsnelheid. Hoe valt dit te verklaren?

Daarnaast is de leessnelheid stabiel, terwijl er grote pieken zitten tijdens het schrijven. Is dit te wijten aan ZFS breathing oid?

[FireDrunk]

Je kan eens wat tunen aan ZFS inderdaad. Je bak heeft zo te zien genoeg geheugen om prefetching aan te hebben. Je kan eens vdev.max_pending en vdev.min_pending op 1 zetten. Dat wil nog wel eens helpen bij sequentiele transfers.

Heb je al eens iperf tests gedaan?

[ Voor 7% gewijzigd door FireDrunk op 15-10-2012 17:42 ]

[Contagion]

Sloth: jij draait op een C60 bord van Asus toch? Ik heb gisteren datzelfde bord besteld om mijn ZFS nas naar om te bouwen. De door jouw genoemde snelheden vallen mij ook wat tegen, maar zodra ik mijn bord heb ga ik er ook mee testen. Probleem is alleen dat ik nu 8 harddisks aangesloten heb op huidige moederbord en met de C60 kan ik er 'maar' 6 kwijt dus daar moet ik nog aan rommelen. Klopt het ook dat jij 1 bankje van 8GB gevuld hebt? Volgens de manual kan dat helemaal niet echter in de manual staan ook DIMM configuraties met 3 modules terwijl het bord maar 2 sloten heeft.

[Verwijderd]

2x8GiB werkt gewoon op Brazos. Zelfs 2x16GiB = 32GiB ook al bestaan die modules nog niet/nauwelijks.

@Contagion: je kunt tijdelijk even een Silicon Image of JMicron controllertje voor 10 euro gebruiken met 2 poorten op PCIe x1. Probleem is dat deze prutcontrollertjes soms nog best duur verkocht worden, tussen de 22 euro en 50 euro soms wel, voor iets wat in feite maar een paar euro kost bij het juiste adres. Alternatief is een USB behuizing, die je later voor andere doeleinden kunt gebruiken.

@sloth: Samba ook getest? Ik weet ook niet of proFTPd wel 'sendfile' ondersteunt. Verder vind ik je interrupt (38%) enorm hoog; dat betekent dat bijna een hele core gebruikt wordt voor interrupts alleen. Wellicht kun je met netwerk 'polling' de CPU usage omlaag krijgen en dus ook de prestaties omhoog.

[Verwijderd]

ZFS kent (teveel) tune-ables maar over het algemeen hebben vdev pending alleen invloed op throughput. Het hoger maken deze waarde resulteert in een grotere queue.Je krijgt dus over het algemeen meer MB/s per seconde.

Arcstat's zouden wat meer inzicht moeten kunnen geven over je cache hit ratio, de write "drops" die je ziet komen voor uit tgx_commit's die plaatsvinden, dit kun je ook meer uitsmeren door sync time aan te passen. DTRACe kan je vertellen hoe lang elke commit actie duurt en je een hint geven over waardes die het beste passen; mits je dit enabled hebt.

[Verwijderd]

@Gila: in meerdere benchmarks is naar voren gekomen dat een max_pending setting van 1 wel eens kan helpen met sequential write, met name mensen die last hebben van breathing. Hoe dat precies zit weet ik niet, maar ik kan me voorstellen dat er schijven zijn die minder goed op NCQ parallelle I/O reageren en derhalve betere prestaties geven bij een enkele queue depth.

Ik had in het verleden ook wel last van breathing en moest flink aan de synctime en write_override zitten om de pauzes minder lang te maken. Tegenwoordig met ZFS v28 op FreeBSD heb ik hier geen/minder last van.

[sloth]

8GB, en op dit moment 1 2TB disk om te testen dus idd meer dan zat.

Iperf testjes:

nas als server, 256k window size

code:

Server listening on TCP port 5001
TCP window size:  256 KByte (default)
------------------------------------------------------------
[  4] local 192.168.0.1 port 5001 connected with 192.168.0.2 port 1148
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.2 sec   708 MBytes   582 Mbits/sec
[  5] local 192.168.0.1 port 5001 connected with 192.168.0.2 port 1149
[  5]  0.0-10.3 sec   757 MBytes   615 Mbits/sec
[  4] local 192.168.0.1 port 5001 connected with 192.168.0.2 port 1150
[  4]  0.0-10.0 sec   715 MBytes   597 Mbits/sec

andere host als server, 256k window size

code:

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  256 KByte
------------------------------------------------------------
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.1 port 22968
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   866 MBytes   725 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.1 port 15835
[  4]  0.0-10.0 sec   866 MBytes   725 Mbits/sec
[  4] local 192.168.0.2 port 5001 connected with 192.168.0.1 port 36090
[  4]  0.0-10.0 sec   866 MBytes   726 Mbits/sec

Kan veel beter, maar iirc haalde ik ook geen >900 Mbits/sec waarden toen ik tussen 2 ramdisks aan het testen was, wat wel gewoon > 100 MB/s "echte" throughput gaf.
Heb ook gelijk met andere netwerkkabels getest, daar zit het probleem i.i.g. ook niet.

Bedankt voor je tips om vdev.max_pending en vdev.min_pending aan te passen Ik ga zo rebooten en dezelfde test herhalen.

---

Contagion: klopt. Spannend, deel je ook jouw ervaringen even hier?
Dat klopt inderdaad. Het gaat hierbij om 1 dimm pricewatch: Kingston KVR1333D3N9/8G die probleemloos herkend wordt.
De manual moet je je idd niet op verhalen, dat is een algemene asus manual waar nog veel dingen instaan die niet kloppen.
Zelfde voor de bios btw, je kan de cpu fanspeed instellen op een passief bord

[Contagion]

Ja dat van die CPU fan zag ik ook al . Zodra het bord binnen is ga ik er mee aan de slag. Ik zal in eerste instantie vooral testen met ZFS-Fuse en de ZFS kernel modules onder linux. Ik heb nogal een exotisch config met 4x2TB en 4x1TB waarbij de 1TB drives weer in Linux RAID0 aan elkaar gekoppeld zijn tot 2 TB schijven. Dat hele zooitje is dus totaal 6x2TB en dat hangt weer aan ZFS-Fuse. Ik denk dat ik met de Brazos ga naar 6x3TB.

Ik kan het ook zo doen:
3TB + 3TB + (1TB + 2TB) + (1TB + 2TB) + (1TB + 2TB) + (1TB + 2TB)

Meer info over setup nu: Contagion in "Storage showoff topic - 10+ TB storage systems"

Ik houd jullie op de hoogte. Ben voornamelijk benieuwd naar performance VS stroomverbruik (alleen daarom is de 8 of 10 disk array van hierboven al niet aan te bevelen ).

[Verwijderd]

@sloth: Je kunt altijd nog zelf een CPU fan erop zetten, er zit volgens mij gewoon een CPU fan header op dat bord. Dus dat is geen loze functionaliteit?

Over je scores: probeer het eens van dat AMD C60 bordje naar een andere computer of andere netwerkinterface toe. Het zou kunnen dat bepaalde combinaties van netwerkchips minder goed samenwerken dan anderen. Dat is iets wat ik nog een keer wilde uitzoeken, maar geen tijd voor heb.

Verder, probeer eens meerdere threads, haal je dan wel max gigabit?

[Dadona]

Ik heb zelf testjes gedaan met ZFSguru en liep tegen dezelfde problemen aan als sloth (grofweg dezelfde opstelling, inclusief moederbord). Transfers die toch wat tegenvielen (50-60MB/sec bij single FTP transfers - meerdere kon ik niet makkelijk uitvoeren met HDDs) en interrupts van >30%.
Het probleem voor mij is toch wel het gebrek aan controle (mijn persoonlijke besef wat er achter de schermen gaande is) over wat ZFS voor slimme dingen wil uitvoeren.
Het doel is om caching (l1arc) uit te schakelen, maar wel op dusdanige wijze dat niet opeens SWAP of wat dan ook aangaat. Bij ZFSguru kan dat wel met wat config opties, maar het achterliggende simpele commando zou prettig zijn. Met caching uitgeschakeld kun je simpel Ramdisk-Ramdisk spelen en volstaat 2-4GB al. Dat is prima te benchen, ook als je Windows in de mix wil gooien.

[ Voor 16% gewijzigd door Dadona op 15-10-2012 19:22 ]

[FireDrunk]

Ik haal hier gewoon 110MB/s lezen en schrijven via FTP op mijn ZFS array

[ Voor 13% gewijzigd door FireDrunk op 15-10-2012 19:39 ]

[Dadona]

Maar jij schiet dan ook echt met een kanon op een mug.

(Eerlijkheid gebied mij te bekennen dat ik ook hardware heb die dat vast ook wel kan halen, redelijk 'wagenpark' hier, maar het zijn niet de meest efficiënte opstellingen. Dat was één van de redenen dat ik eens zo'n simpel setje wou opzetten. Voor de langere termijn een speel- en leerplatform om zoveel mogelijk te doen met zo min mogelijk.)

[ Voor 76% gewijzigd door Dadona op 15-10-2012 20:05 ]

[Verwijderd]

@Dadona, heb je al eens polling geprobeerd? ifconfig re0 polling

[Dadona]

Nog niet, maar ik had het al genoteerd om te testen. Maar momenteel is het systeem 'even' bezig...

[sloth]

FireDrunk: ik heb de test herhaald maar helaas, met

[code]
cat /etc/rc.conf | grep vdev
vdev.max_pending="1"
vdev.min_pending="1"
[/code]

blijven de pieken aanhouden. Ook de average speed blijft ongewijzigd.

Zie volgende post

---

CiPHER: met 2 threads is er geen beterschap. De totale write throughput ligt net wat hoger, maar de pieken blijven:



Ik heb nog een Intel 1000pt nic over, zal zo daar nog even mee testen en kijken of ik hogere resultaten haal.

Wat polling betreft kan ik helaas niet testen, omdat voor zover ik het begrijp er geen ondersteuning voor ingebakken zit in NAS4Free.

code:

nas4free:~# ifconfig re0 polling
nas4free:~#

Is dit wel zo bij ZFSGuru?

[FireDrunk]

Heb je al eens zonder sync of ZIL geprobeerd?

[matty___]

sloth schreef op maandag 15 oktober 2012 @ 20:51:

code:

nas4free:~# ifconfig re0 polling
nas4free:~#

Is dit wel zo bij ZFSGuru?

polling werk alleen bij bepaalde nics en je moet het mee compileren in de kernel.
investeer in een pci-e intel nic die heb je al


je zou nog de zfs_write_limit_override parameter aan kunnen passen. Hiermee bepaal je de hoeveelheid data per tx group.

[ Voor 18% gewijzigd door matty___ op 15-10-2012 22:19 ]

[Verwijderd]

Hij heeft al een Intel NIC, en ik vind het onzin om gelijk de onboard NIC af te schrijven. Eerst testen, dan kijken of het extra energieverbruik het wel waard is.

Realtek re driver ondersteunt vrijwel alle nieuwe snufjes inclusief polling. Je moet inderdaad wel een kernel hebben met options DEVICE_POLLING erin. Je kunt een include GENERIC config file maken. Met ZFSguru kun je de sourcecode installeren via de 'FreeBSD sourcecode' service en dan vind je in /usr/src/sys/amd64/conf de config files zoals GENERIC. In /usr/src dan:
make buildkernel KERNCONF=MYCONF
make installkernel KERNCONF=MYCONF

Hopelijk heb je met deze mini-howto voldoende motivatie om polling te proberen, want juist voor de AMD C60 kan dit performance verbeteren omdat je dus veel minder CPU load hebt. Dat lijkt mij waardevol genoeg om te testen voordat je er weer een smak geld tegenaan gooit.

[Verwijderd]

Wil niet de uithangen hier maar van alles wordt voorgesteld om te "tweaken" maar zou je niet beter kunnen kijken wat er allemaal aan de hand is voor je dat doet? Bij write problemen kan het zo zijn dat zfs_write_throttle wordt uitgevoerd waarbij je "sluggish" response kunt krijgen: heb je daar last van? daarnaast wat is je spa sync tijd? DTRACE is your friend.

[FireDrunk]

Is er iets anders dan DTrace? Dat werkt nog niet onder ZFSGuru, ik moet nog even een nieuwe kernel compilen...

[matty___]

post je loader.conf eens.

probeer een lagere waarde voor vfs.zfs.txg.timeout

En welke versie van zfs heb je? ZFS v28 zit pas in de laatste Beta :

FreeNAS 8.3.0-BETA1 has the FreeBSD base system switched to FreeBSD 8.3-RELEASE-p3. The most noticable affect of this change is the inclusion of ZFS version 28, but there are a number of other driver changes as well.


En v28 loopt stukken soepeler dan de oude

[Verwijderd]

FireDrunk schreef op dinsdag 16 oktober 2012 @ 09:53:
Is er iets anders dan DTrace? Dat werkt nog niet onder ZFSGuru, ik moet nog even een nieuwe kernel compilen...

Nee helaas, alleen de traditionele *stat maar die geven niet weer wat je zoekt. DTRACE er in bakken is easy-peasy, BSD heeft zijn build system goed voor elkaar (dat kan illumos niet zeggen namelijk)

[FireDrunk]

Mja, ik moet me er binnenkort even op storten om van mijn NAS de kernel te vervangen...
Maar dan wil ik wel even een backup bootable kernel in het keuze menu erbij zetten.

Dat is even uitzoekwerk.

[Verwijderd]

Daar is juist ZFS voor bedoeld toch? https://github.com/vermaden/beadm

[FireDrunk]

Iets meer uitleg?

[Verwijderd]

Je maakt een snapshot van je boot partitie (en dus kernel) list in grub de snapshots en je kan kiezen welke boot omgeving je wilt gebruiken:

-bash-4.1# beadm list
BE Active Mountpoint Space Policy Created
rootfs-nmu-000 - - 4.33G static 2012-08-10 23:44
rootfs-nmu-001 NR / 946M static 2012-10-10 10:57

001 is mijn active, als ik reboot heb ik in GRUB de keuze tussen 000 en 001

[FireDrunk]

Je kan dus een specifiek ZFS Snapshot van je boot omgeving booten?

[Verwijderd]

Dat is de bedoeling idd.

[matty___]

FireDrunk schreef op dinsdag 16 oktober 2012 @ 13:41:
Je kan dus een specifiek ZFS Snapshot van je boot omgeving booten?

zelfde wat Solaris heeft.

[Verwijderd]

FreeBSD gebruikt geen grub? Van een snapshot booten heb ik nog niet eerder gehoord. Maar @FireDrunk, als je een installkernel doet, komt je oude kernel automatisch op /boot/kernel.old en kun je dus ook handmatig booten via de loader prompt (boot kernel.old dacht ik gewoon). Dus je kunt altijd al terug naar je oude kernel indien nodig.

Wel moet je zorgen dat de sourcecode in /usr/src hetzelfde is als je draaiende systeem. Om die reden kun je in ZFSguru het beste de FreeBSD Sourcecode service downloaden; dan krijg je niet nieuwe sourcecode maar exact dezelfde als waarmee jouw systeemimage gebakken is.

[FireDrunk]

Dat heb ik al

Nadeel is alleen, als je dus 2 keer make installkernel doet, je je nieuwe kernel ook weer naar kernel.old zet.

Als je dus 2 keer compiled, is je originele kernel al weg.

Ik heb in een VM ook al een nieuwe kernel gebouwd, en dat scheelt ook een paar seconde opstarttijd (vooral vanwege het verwijderen van oude IDE en SCSI meuk...)

Nu nog even op mijn 'productie' systeem testen.

[d1ng]

De kernel.old is dan eigenlijk je GENERIC. Deze kan je gewoon hernoemen naar GENERIC. Met nextboot kun je dan evt. kiezen welke kernel je op wilt starten. Bv. 'nextboot -k GENERIC'

[FireDrunk]

Kan je nextboot ook gebruiken vanaf je boot/loader prompt? Want dat is natuurlijk het belangrijkst.
Kunnen recoveren van een kapotte kernel.. (die panict ofzo)

[Verwijderd]

Escape to loader prompt: boot kernel.old zo kun je elke kernel booten vanaf de boot loader prompt. Loader prompt kom je door op ESC te drukken zodra je het FreeBSD menu ziet waar er van 10 naar 0 wordt afgeteld.

[Durandal]

puur ZFS vraagje,
als ik een raidz2 heb, wat heeft het dan voor nut om je filesysteem op copies=3 te zetten?
Als er 3 disks falen is je pool toch weg, en heb je niets aan die extra copies, of kan zfs dan toch nog de data reconstrueren?

[Verwijderd]

@Durandal: ditto blocks ofwel copies=2 of hoger - wat standaard voor alle metadata ingeschakeld is - kan geen disk failures opvangen, maar het kan wel bad sectors en corruptie opvangen. Met copies=2 en RAID-Z2 heb je in totaal 6 data sources (3 van de RAID-Z2 en dan MAAL twee doordat je twee kopiën hebt). Met andere woorden: de kopiën hebben zelf ook de redundantie, dus je kunt zo een heel hoog niveau van bescherming hebben in geval bepaalde blocks corrupt zijn. Copies=2 kan op een RAID0 ook nuttig zijn, niet om een totale failure van één member op te vangen, maar wel om bad sectors / uBER uit te sluiten.

Het belangrijkste is dat metadata altijd minimaal twee kopiën heeft, wat in combinatie met redundantie betekent dat het ZFS filesystem bijna niet stuk kan. Zelfs op een niet redundante configuratie zoals een enkele disk of een RAID0 heb je standaard dus bescherming tegen bad sectors / corruptie voor metadata. Inclusief redundantie wordt die bescherming flink versterkt, omdat je het niet optelt maar vermenigvuldigt.