Het grote ZFS topic

[FireDrunk]

Ik denk niet dat dat helpt hoor... Je kan het even proberen met een FreeBSD11-CURRENT iso. Als die ook niet werkt heb je simpelweg pech

[CurlyMo]

FireDrunk schreef op maandag 18 mei 2015 @ 13:21:
[...]

Ik ben toch echt van mening dat dat niet zou moeten kunnen hoor? Een proces krijgt zijn eigen memory ruimte, en daar moet ie binnen blijven... De root user heeft misschien wat speciale rechten om hier wat gekke dingen mee te doen, maar het zou bizar zijn als applicaties zomaar andermans geheugen uit zouden kunnen lezen...

Voorbeeld: NIET DAADWERKELIJK UITVOEREN.

C:

#include <stdlib.h> 
#include <stdio.h> 
#include <fcntl.h> 
#include <sys/mman.h> 
#include <sys/stat.h> 
#include <unistd.h>
#include <string.h>

int main (int argc, char* const argv[]) {
    int fd = 0;
    void *mem = NULL;

    fd = open("/dev/mem", O_RDWR | O_SYNC | O_CLOEXEC);
    mem = mmap(0, 1024*1024, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x123456); 
    close(fd); 

    memset(mem, 0, 1024*1024);

    munmap(mem, 1024*1024); 

    return 0;
} 

Afhankelijk van je OS schrijf je hiermee 1024*1024 aan nullen in het geheugen vanaf geheugengebied 0x123456.

[Compizfox]

FireDrunk schreef op maandag 18 mei 2015 @ 13:21:
[...]

Ik ben toch echt van mening dat dat niet zou moeten kunnen hoor? Een proces krijgt zijn eigen memory ruimte, en daar moet ie binnen blijven... De root user heeft misschien wat speciale rechten om hier wat gekke dingen mee te doen, maar het zou bizar zijn als applicaties zomaar andermans geheugen uit zouden kunnen lezen...

Inderdaad, ik snap ook niet hoe dat dan zou kunnen. Volgens mij heeft het zelfs nog vrij weinig te maken met users, maar meer met applicaties.

Als ik onderstaande links zo lees lijkt dat toch wel in tegenspraak met wat CurlyMo beweert, toch?

http://en.wikipedia.org/wiki/Segmentation_fault

[FireDrunk]

CurlyMo schreef op maandag 18 mei 2015 @ 13:52:
[...]


Voorbeeld: NIET DAADWERKELIJK UITVOEREN.

C:

#include <stdlib.h> 
#include <stdio.h> 
#include <fcntl.h> 
#include <sys/mman.h> 
#include <sys/stat.h> 
#include <unistd.h>
#include <string.h>

int main (int argc, char* const argv[]) {
    int fd = 0;
    void *mem = NULL;
    int integer; 

    fd = open("/dev/mem", O_RDWR | O_SYNC | O_CLOEXEC);
    mem = mmap(0, 1024*1024, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x123456); 
    close(fd); 

    memset(mem, 0, 1024*1024);

    munmap(mem, 1024*1024); 

    return 0;
} 

Afhankelijk van je OS schrijf je hiermee 1024*1024 aan nullen in het geheugen vanaf geheugengebied 0x123456.

En wat is de chmod van /dev/mem?

NAS:

[root@NAS ~]# ls -lah /dev/mem
crw-r----- 1 root kmem 1, 1 May 16 11:59 /dev/mem

Laptop:

[thijs@carbon ~]$ ls -la /dev/mem
crw-r----- 1 root kmem 1, 1 May 18 12:27 /dev/mem

Dus zonder root (of kmem groep toegang), geen schrijfrechten..

[ Voor 15% gewijzigd door FireDrunk op 18-05-2015 13:55 ]

[CurlyMo]

code:

crw-r-----  1 root  kmem  0xe Apr 22 00:10 /dev/mem

[FireDrunk]

Ik vraag me af of er devices zijn die dat device gebruiken. Het lijkt mij eerlijk gezegd een beetje overbodig

[CurlyMo]

Het is juist zeer nuttig. Ik gebruik het zelf bijvoorbeeld voor snelle toegang tot de GPIO, maar het kan ook gebruikt worden voor interrupts.

[FireDrunk]

Vanuit userland ja, want de kernel hoeft helemaal geen character devices te openen, daar zijn gewoon kernel structs voor voor zover ik weet...

Het is een 'vieze' toegang tot het geheugen naar mijn mening? (leuk voor low-level, maar gevaarlijk voor al het andere)

[CurlyMo]

En dat gevaarlijke is precies waar ik het over heb.

[tvwes]

Dit blijft toch een lastig onderwerp, ook voor mij. Waar ik telkens volkomen van in de war raak zijn de tegenstrijdige signalen/wensen van de tweakers/eindgebruikers (hier). Aan de ene kant willen mensen betrouwbare opslag en aan de andere kant mag het niets kosten. Die twee kunnen niet samen.
Ja Cipher heeft grotendeels gelijk en brengt goede nuances aan. Vooral het voorbeeld van wel ECC tegelijk met een brakke SSD was erg treffend. De failuremodes moeten in balans zijn.
De meeste ZFS ontwikkelaars hebben allemaal een macbook, zonder ECC. Is dat een probleem? Voor deze profesionals absoluut niet ze snappen de risico's en gaat er wat mis dan hebben ze hun timemachine en git. Ik heb deze mensen hier nooit over horen klagen. Niet dat ze het niet willen maar ze hebben weinig last van niet-ECC problemen. Deze zelfde mensen zullen nooit hun servers zonder ECC laten draaien.
Waarom? Die servers hebben vaak veel langere uptime en worden veel zwaarder belast. (meer geheugen gebruik = grotere kans op fout) De kans op ellende blijkbaar zo reeel dat iedereen wel ECC in zn servers gebruikt. De bekende paper van Google laat dat oa zien.
Nu terug naar de SOHO situatie van velen hier. Werkt ZFS zonder ECC? Natuurlijk. Raakt je zpool corrupt of valt je haar uit als je NAS geen ECC heeft? Niet erg waarschijnlijk.
Het is een kosten baten afweging. Als jij die onverklaarbare vastloper niet erg vind en een keer op de reset knop wil drukken dan prima, pak je cheap ass systeem en veel plezier. De kans is klein maar niet nul.
Als je NAS altijd aan staat en echt iets doet en weinig tijd hebt, geen gezeur wilt, risico avers bent of die 100-200 euro extra over een paar jaar verdisconteerd wel kan betalen zou ik ECC adviseren.

Cipher heeft volkomen gelijk ZFS werkt prima zonder ECC en alle maatregelen moeten in verhouding staan. Iedereen zal zelf deze afweging moeten maken.

Verwijderd schreef op maandag 18 mei 2015 @ 13:12:
Goede paper maar onduidelijk voor veel mensen is dat de corruptie die plaatsvindt door geheugenfouten in veel gevallen tijdelijke corruptie is; die evengoed weer gecorrigeerd wordt bij een volgende toegang.

Ik neem aan dat je hier ZFS toegang bedoeld en dan specifiek een ondisk read?

Voor bedrijven is dit niet zo relevant: zij hebben end-to-end data protection nodig omdat hun applicaties geen corrupte data mogen ontvangen. Stel dat de bank bij het overboeken van geld door een RAM bitflip opeens een paar miljoen ipv een paar euro overmaakt, of naar een andere rekening. Afijn..

Maar voor thuisgebruikers is het helemaal niet zo erg dat er tijdelijke corruptie plaatsvindt. Stel dat in een RAID-Z2 pool er diverse blokjes corrupt zijn door RAM bitflips, wordt dat evengoed weer gecorrigeerd bij een scrub of volgende I/O actie. Nu kunnen RAM bitflips er in theorie ook voor zorgen dat de hele pool corrupt raakt; al heb ik daar nog nooit één concreet voorbeeld van gezien. De normale RAM bitflips komen enorm vaak voor. Ik heb al minimaal 8 mensen met zelfbouw NAS gehad die dit opmerken. En de grap is dat zij dit opmerkten doordat ZFS op een later tijdstip de corruptie weer herstelde; dan zie je dus checksum errors op je disks willekeurig. Vooral als deze willekeurig verspreid zijn over de disks, is geheugen corruptie een zeer aannemelijke oorzaak. Maar tot permanente corruptie heeft het in de praktijk nog nooit geleid, althans ik heb daar nog nooit een concreet voorbeeld van gezien.

Risicoafweging is belangrijk; alleen door alle verhalen over corruptie denk ik dat het voor de gebruiker niet duidelijk hoe deze risico's in te schatten. Ook zijn de belangen van zakelijke gebruikers en thuisgebruikers op bepaalde punten heel anders. Ik vind het dus heel gevaarlijk om algemeen advies bedoeld voor enterprise-gebruikers zomaar op thuisgebruikers toe te passen. Ook vraag ik mij af of gebruikers inderdaad begrepen hadden dat het in die paper om tijdelijke corruptie gaat; die aan de applicatie wordt geleverd. Er wordt niet gesteld dat deze corruptie een volgende keer gewoon weer gecorrigeerd wordt, mits de checksum zelf niet gecorrumpeerd is.

Leuk voorbeeld is de gebruiker ikkeenjij36. Deze is door alle spookverhalen ook geïnteresseerd in ECC geheugen. Maar hij gebruikt nog wel zijn OCZ Vertex als systeemschijf. Dan heb je dus een extreem klein risico met veel geld afgedekt, terwijl een supergroot risico wagenwijd open blijft staan; want een OCZ SSD is in feite onbruikbaar door continu corruptie. Het is voor gebruikers niet altijd duidelijk welke risico's nu echt belangrijk zijn, en welke risico's een margekwestie zijn. Een UPS is ook logischer, voordat je een koepel tegen meteorietinslag zou bouwen. Kortom, begin eerst met het uitschakelen van de grote risico's wat met weinig geld kan, en eindig bij het uitschakelen van kleine risico's met grof geld. Dat is het toetje dat je als thuisgebruiker altijd kunt overwegen om enterprise-achtige veiligheid te bereiken. Maar daar heb je weinig aan als je de veel grotere risico's niet uitsluit. Daarom dat ik de hele discussie hieromtrent zeer nadelig vindt voor thuisgebruikers. Ook zie ik dat mensen ZFS links laten liggen ("want dat werkt alleen goed met ECC") en maar terug gaan naar hun legacy oplossing. Compleet idioot en de oorzaak van deze verkeerde afweging zoek ik in de cowboy-verhalen over ZFS en veiligheid. Want als iemand ZFS kiest, dan moet gelijk voor duizenden euro's alle mogelijke risico's worden uitgesloten. Terwijl dat onzinnig is; een legacy oplossing heeft meer baat bij ECC dan ZFS zou ik durven te stellen; omdat ZFS tenminste detectie heeft voor alle corruptie - ook al is die detectie vertraagd - en tevens enige vorm van correctie heeft voor RAM bitflips. Bij legacy oplossingen zijn beide afwezig, en legacy oplossingen gebruiken meer RAM geheugen dan ZFS.

Op zich waar maar het legacy filesystem heeft en de nodige repair tools alsmede data recovery tools. Als je zpool corrupt is de thuisgebruiker echt alles wat daarop stond kwijt.

Als de thuisgebruiker netjes backups, die hij ook kan terug zetten, heeft dan is ZFS altijd beter dan wat dan ook.

[FireDrunk]

Volgens deze guide:
https://dev.gentoo.org/~s...lconfig-restrictmemaccess

Moet je /dev/mem sowieso slecht leesbaar maken door bepaalde kernel properties te gebruiken.

Mijn Laptop kernel:

[thijs@carbon ~]$ cat /proc/config.gz | gunzip | grep DEVMEM
CONFIG_DEVMEM=y
CONFIG_STRICT_DEVMEM=y

Heeft dit dus. En hier zie je het effect:

[thijs@carbon ~]$ dd if=/dev/mem of=/dev/null
dd: failed to open ‘/dev/mem’: Permission denied
[thijs@carbon ~]$ sudo !!
sudo dd if=/dev/mem of=/dev/null
[sudo] password for thijs: 
dd: error reading ‘/dev/mem’: Operation not permitted
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.0568227 s, 18.5 MB/s

Ik heb nog geen bronnen gevonden waarin staat dat je het uit kan zetten.

[ Voor 4% gewijzigd door FireDrunk op 18-05-2015 14:08 ]

[CurlyMo]

Afhankelijk van je kernel kan dit scriptje prima werken.

C:

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>

int main (int argc, char* const argv[]) {
    int fd = 0;
    void *mem = NULL;

    fd = open("/dev/mem", O_RDWR | O_SYNC | O_CLOEXEC);
    printf("%d %d\n", fd, errno);
    mem = mmap(0, 1024*1024, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x3F000000);
    printf("%d %d\n", mem, errno);
    close(fd);

    munmap(mem, 1024*1024);

    return 0;
}

Op eigen risico natuurlijk!

Edit: iets genuanceerd

[ Voor 16% gewijzigd door CurlyMo op 18-05-2015 14:21 ]

[FireDrunk]

Ah, BSD... Hier zie je dus een groot verschil tussen Linux en BSD. Linux heeft daar aan gedacht.

[CurlyMo]

Mijn conclusie klopte niet. Afhankelijk van het geheugengebied dat je probeert te openen krijg je een foutmelding. Maar dat is wel afhankelijk van je kernel.

[FireDrunk]

Ah, goede nuance! Best belangrijk.

[Verwijderd]

FireDrunk schreef op maandag 18 mei 2015 @ 13:51:
Ik denk niet dat dat helpt hoor... Je kan het even proberen met een FreeBSD11-CURRENT iso. Als die ook niet werkt heb je simpelweg pech

Zodra 0.3 er is, kun je ook je eigen USB stick schrijven met dd of rawrite onder Windows. Dat kan nu eigenlijk al want USB heb ik al twee maanden geleden werkend gekregen. Niet alleen met GPT MBR boot maar ook GPT UEFI. Want sommige moederborden zoals Asus willen niet met MBR booten als de disk GPT partities heeft; dan moet er persé UEFI gebruikt worden. En BSD is dus de uitzondering dat het prima met GPT overweg kan maar geen UEFI nodig heeft; BSD heeft moderne bootcode geschreven.

Kortom, binnenkort heb je veel meer mogelijkheden om te starten met ZFSguru, zonder dat je met de .iso hoeft te werken. Want niet iedereen gebruikt virtualisatie of heeft een Zalman VE-300 .iso emulator.

---

Over jullie discussie over kernel geheugentoegang; in hoeverre hebben HardenedBSD projecten hiermee te maken? ASLR is alleen randomization dacht ik. Maar kan ieder programma zomaar geheugenadressen uitlezen? Dat is toch een ultra-grote security bug? Dan kan een simpel programmatje ook encryptiesleutels uitlezen? Ik kan me dit niet voorstellen dan zou het hele OS lek zijn.

---

@tvwes: mooi stukje! Zal er later op reageren.

[CurlyMo]

Of je geheugen kan uitlezen is afhankelijk van de implementatie van de software en kernel. Ik kan simpel een Raspberry Pi laten crashes via mmap. Zou het moeten kunnen, nee, maar het kan.

[tvwes]

@CurlyMo
Een gewone gebruiker had uberhaubt geen toegang tot /dev/mem op jouw systeem. Dus hoe kunnen applicaties elkaars process ruimte bereiken? Voorzover mij bekend heeft ieder proces een virtuele adres ruimte en kan je van daaruit niet zonder meer of de kernel space of andere processen benaderen.

Weer een goede reden om je applicaties in jails/zones/containers te draaien. Daarin zijn niet dit soort devices, voorzover mij bekend.

Wat Firedrunk al schreef: /dev/mem = gevaarlijk

[CurlyMo]

Maar, hoe weet je of een bepaalde applicatie daadwerkelijk veilig met zijn root vereisten omgaat?

[tvwes]

CurlyMo schreef op maandag 18 mei 2015 @ 14:42:
Maar, hoe weet je of een bepaalde applicatie daadwerkelijk veilig met zijn root vereisten omgaat?

Was die vraag aan mij?

Ik weet dat niet. Als je het wil lezen weten moet je een audit doen, Daarvoor heb je veel kennis en tijd (misschien wel man jaren) voor nodig. Ik vertrouw sommige projecten meer dan andere. Maar bijna alles draait bij mij in zones. Daarbinnen mogen ze zoveel root zijn als ze willen. Niet dat ik alles als root laat draaien maar de risico's zijn veel beperkter.

[CurlyMo]

En dan komen we dus terug op de oorspronkelijke problemen zoals ECC vs non-ECC. Ik ben meer paranoïde over de algemene kwaliteit van de OSS software dan over de kwaliteit van mijn geheugen

Dan heb ik het niet over Apache, Samba, e.d.

[FireDrunk]

Echt een sterk punt! Zo had ik er eerlijk nog niet over nagedacht!

[CurlyMo]

Een bekend voorbeeld - al weet ik niet of het nog actueel is - was/is dat de ZFSGuru webGUI volledige root toegang heeft/had. De meningen over de kwaliteit van de ZFSGuru webGUI zijn wisselend (zie andere topic), maar laat ik het houden bij het feit dat het een probleem kán vormen.

[FireDrunk]

Lastige is dat je voor zfs vrij snel root toegang nodig hebt. Om dat te splitsen moet je best wat aparte dingen doen.

Onder linux minder dan onder BSD.
(Onder linux kan je udev rules maken)

[CurlyMo]

Daar hebben we in het andere topic al uitgebreid over gebrainstormed.

[tvwes]

CurlyMo schreef op maandag 18 mei 2015 @ 14:49:
En dan komen we dus terug op de oorspronkelijke problemen zoals ECC vs non-ECC. Ik ben meer paranoïde over de algemene kwaliteit van de OSS software dan over de kwaliteit van mijn geheugen

De vergelijking tussen de ECC discussie en de kwaliteit van OSS kan ik niet goed volgen. Maar misschien dat je daar nog iets over kan zeggen.

Dan heb ik het niet over Apache, Samba, e.d.

Bedoel je hiermee dat omdat dit veel gebruikte / actief ontwikkelde / grote belangstelling applicaties zijn deze meer te vertrouwen zijn dan andere?
Ik denk niet dat die relatie aanwezig is. Kijk naar BIND en Sendmail beide zeer cruciale paketten maar met een niet al te beste trackrecord op het gebied van kwaliteit noch security. Het is niet zonder reden dat enkele DNS root servers overgezet zijn van BIND naar NSD. Daar heb je bijna de hand van God voor nodig om dat voor elkaar te krijgen. Ondanks alle belangen en aandacht voor BIND is het niet een kwaliteits product.
Kijk naar OpenBSD, wat een beperkte feature set heeft ivg met andere OS's. De tijd en focus ligt daar op kwaliteit. Wat zich vertaalt in een zeer gewaardeerd stuk OSS.

We hebben allemaal beperkte middelen ( tijd en geld) dus kunnen niet een audit doen van al onze gebruikte software en vergeet niet je BIOS te bekijken. Dat is niet realistisch, je moet op een gegeven moment vertrouwen hebben in bepaalde zaken. Door aan spreiding en isolatie en common sense kan je heel veel ellende voorkomen.

Ter afsluiting: wie weet wat al die apps op zn telefoon allemaal uitspoken? En daar zit ook nog betaalde ondeugd tussen.

[CurlyMo]

En daarom noem ik voor de thuisgebruiker de ECC/non-ECC discussie een onzinnige discussie. De grootste risico's loop op andere gebieden: diefstal, brand, brakke software, gebruikersfouten enz.

[yamahabest]

Verwijderd schreef op maandag 18 mei 2015 @ 14:37:
[...]Dat kan nu eigenlijk al want USB heb ik al twee maanden geleden werkend gekregen. Niet alleen met GPT MBR boot maar ook GPT UEFI. Want sommige moederborden zoals Asus willen niet met MBR booten als de disk GPT partities heeft; dan moet er persé UEFI gebruikt worden. En BSD is dus de uitzondering dat het prima met GPT overweg kan maar geen UEFI nodig heeft; BSD heeft moderne bootcode geschreven.

Ehm... doe ik nu wat fout? Ik heb de ZFSGuru iso geboot in VirtualBox, een pool "install" aangemaakt op de usb stick, en daarna 10.1-001 er op geinstalleerd, waarbij ik "Copy system image to pool" aan heb gezet. Redelijk simpel, dacht ik.

Bij booten op de echte machine krijg ik echter:
"Trying to mount root from zfs:install/zfsguru/10.1-001"
"Solaris: NOTICE: Cannot find the pool label for 'install'"
"Mounting from zfs:install/zfsguru/10.1-001 failed with error 5."

[Verwijderd]

Heb je in Virtualbox de VM type wel op FreeBSD (64-bit) ingesteld? Gebruik je AHCI disks? Kan zijn dat de SCSI-disk code in Virtualbox een hogere wachtperiode nodig heeft bij het booten. Dit kun je ook instellen bij de laatste stap van de installatie.

Stuur me anders een DM met wat informatie over wat je in virtualbox hebt gedaan en welke versie pool, etc.

[tvwes]

FireDrunk schreef op maandag 18 mei 2015 @ 15:07:
Lastige is dat je voor zfs vrij snel root toegang nodig hebt. Om dat te splitsen moet je best wat aparte dingen doen.

Onder linux minder dan onder BSD.
(Onder linux kan je udev rules maken)

Nee hoor, ik kan jouw alle ZFS taken laten uitvoeren zonder dat jij root of sudo of welke andere manier root rechten kan verkrijgen.
Hoe?

Simpel twee mechanismen. ZFS allow en Role Based Access Control (RBAC).

code:

$ usermod -P "ZFS File System Management","ZFS Storage Management","File System Management" firedrunk

Hierna kan user firedrunk zonder root te zijn gewoon nieuwe zpools aanmaken en wat dan ook. Met zfs allow kan je administratieve taken als snapshot's maken toestaan.

Oeps ondersteunt je favoriete OS dat niet? Dan kan ik je wat alternatieven noemen...

[tvwes]

CurlyMo schreef op maandag 18 mei 2015 @ 15:12:
En daarom noem ik voor de thuisgebruiker de ECC/non-ECC discussie een onzinnige discussie. De grootste risico's loop op andere gebieden: diefstal, brand, brakke software, gebruikersfouten enz.

Die vergelijking kon ik er niet uithalen. Maar je genoemde risico's zijn helemaal waar en veel groter dan de bitflip.

[CurlyMo]

Wat mij betreft moet het gangbare advies dan ook anders zijn: Als je geld over hebt en betrouwbare opslag wil, neem dan niet eerst ECC geheugen, maar een externe readonly schijf als backup, als je dan nog geld hebt, regel dan een offsite backup, en als laatste kies je voor ECC geheugen.

[FireDrunk]

Lastig backuppen naar een read only schijf

[CurlyMo]

Nee hoor, zfs send/receive werkt prima op een readonly FS.

[FireDrunk]

Slim! Had ik nog niet aan gedacht!

tvwes schreef op maandag 18 mei 2015 @ 15:29:
[...]


Nee hoor, ik kan jouw alle ZFS taken laten uitvoeren zonder dat jij root of sudo of welke andere manier root rechten kan verkrijgen.
Hoe?

Simpel twee mechanismen. ZFS allow en Role Based Access Control (RBAC).

code:

$ usermod -P "ZFS File System Management","ZFS Storage Management","File System Management" firedrunk

Hierna kan user firedrunk zonder root te zijn gewoon nieuwe zpools aanmaken en wat dan ook. Met zfs allow kan je administratieve taken als snapshot's maken toestaan.

Oeps ondersteunt je favoriete OS dat niet? Dan kan ik je wat alternatieven noemen...

Ja, ja, ja, solaris, bla bla. Als Solaris net zo weinig verbruikt, net zo makkelijk installeert, en net zo makkelijk beheert, zou ik het overwegen

[ Voor 92% gewijzigd door FireDrunk op 18-05-2015 16:12 ]

[CurlyMo]

Lijkt me toch een cruciale eigenschap van een backup

[tvwes]

CurlyMo schreef op maandag 18 mei 2015 @ 15:49:
Nee hoor, zfs send/receive werkt prima op een readonly FS.

Bedoel zfs send van readonly dataset? Want ik kan echt niet schrijven naar een readonly zpool (dat is dus wat anders dan een dataset)

code:

bash-4.3# ls -l
total 262205
-rw------T 1 root root 134217728 Sep  6  2013 slog1
-rw------T 1 root root 134217728 Apr 24 10:31 vdev1
bash-4.3# zpool create -f curlymo $PWD/vdev1
bash-4.3# zpool export curlymo
bash-4.3# zpool import -o readonly=on -d $PWD curlymo
cannot import 'curlymo': a pool with that name is already created/imported,
and no additional pools with that name were found
bash-4.3# zpool status curlymo
  pool: curlymo
 state: ONLINE
  scan: none requested
config:

        NAME                 STATE     READ WRITE CKSUM
        curlymo              ONLINE       0     0     0
          /mpool/vdev/vdev1  ONLINE       0     0     0

errors: No known data errors
bash-4.3# echo hoi > /mpool/nocomp/curlymo
bash-4.3# zfs snapshot mpool/nocomp@curlymo
bash-4.3# zfs send mpool/nocomp@curlymo | zfs receive -vd curlymo
receiving full stream of mpool/nocomp@curlymo into curlymo/nocomp@curlymo
cannot receive new filesystem stream: pool is read-only
bash-4.3# zpool export curlymo
bash-4.3# zpool import -d $PWD curlymo
bash-4.3# zfs send mpool/nocomp@curlymo | zfs receive -vd curlymo
receiving full stream of mpool/nocomp@curlymo into curlymo/nocomp@curlymo
received 302KB stream in 1 seconds (302KB/sec)

Misschien kan jij even een voorbeeld posten wat je bedoeld?

[tvwes]

FireDrunk schreef op maandag 18 mei 2015 @ 16:11:
Slim! Had ik nog niet aan gedacht!

Dank u dank u

Ja, ja, ja, solaris, bla bla. Als Solaris net zo weinig verbruikt, net zo makkelijk installeert, en net zo makkelijk beheert, zou ik het overwegen

Ik heb twee van die supermicro's X10SLH's besteld met oa een pentium en celeron. Ik ben erg benieuwd naar hoeveel werk dit soort budget cpu's kunnen verzetten. Ik zal tzt een vergelijking van het stroomverbruik tussen OmniOS, FreeBSD en een courante Linux posten. Op het vlak van installatie wil ik die Pepsi test wel aangaan. Een paar vragen van de installer en klaar. Ook daarna is het aan de gang krijgen van de nas een paar commando's en klaar.
Misschien niet zo snel als klikker-de-klik wel veel flexibeler en leerzamer.

[CurlyMo]

Ik bedoel zfs send naar een readonly zfs niet naar een readonly zpool

[tvwes]

@Curlymo Dat klopt, maar dat stond er niet.. Daarnaast moet je expliciet op de backup zfs set readonly=on doen. Kan je uitleggen wat het voordeel hiervan is? En nog liever hoe die backup workflow eruit ziet. Dank u.

Dan ga ik nu snel zpool destroy curlymo doen.

[Compizfox]

tvwes schreef op maandag 18 mei 2015 @ 15:11:
Bedoel je hiermee dat omdat dit veel gebruikte / actief ontwikkelde / grote belangstelling applicaties zijn deze meer te vertrouwen zijn dan andere?
Ik denk niet dat die relatie aanwezig is. Kijk naar BIND en Sendmail beide zeer cruciale paketten maar met een niet al te beste trackrecord op het gebied van kwaliteit noch security.

*ahem* OpenSSL *ahem*

[CurlyMo]

De expliciete readonly heb ik eenmalig gedaan. Voordeel is natuurlijk dat je niet per ongeluk bestanden op je backup schijf kan aanpassen. Helemaal belangrijk voor zfs send/receive aangezien dat faalt zodra de data (tussen snapshots) op de doelschijf anders is dan op de bron schijf.

Backup workflow kan je zien a.d.v. het script dat ik laatst geplaatst heb. Die draait elke nacht naar een onsite en offsite backup schijf.

[wopie]

tvwes schreef op maandag 18 mei 2015 @ 17:12:
Ik heb twee van die supermicro's X10SLH's besteld met oa een pentium en celeron. Ik ben erg benieuwd naar hoeveel werk dit soort budget cpu's kunnen verzetten. Ik zal tzt een vergelijking van het stroomverbruik tussen OmniOS, FreeBSD en een courante Linux posten.

Daar ^^ ben ik ook in geïnteresseerd (wil ooit nog eens van esxi af en SmartOS/OmniOS zijn in mijn ogen goede kandidaten hiervoor).

[tvwes]

Compizfox schreef op maandag 18 mei 2015 @ 17:29:
[...]

*ahem* OpenSSL *ahem*

Ja zeker, de rij is vrij lang. Des te ouder en bekender des te meer issues er vaak zijn.
Maar er zijn natuurlijk de nodige uitzonderingen, qmail bijvoorbeeld. Nu is de auteur hiervan niet de meest makkelijke persoon maar het is wel, net als veel software van zijn hand, een zeer robuust stuk software. Het is jammer dat daar niet meer mee is gedaan. Veel ISP's waaronder yahoo gebruiken het nog altijd.
Het ontwikkelen van robuste en laat staan veilige software is heel lastig. Kijk ook maar eens naar het cryptech project en vooral wie dit financieren Als je de wiki goed leest zie wat een uitdaging dat is, zelfs voor zoiets niet echt al te ingewikkeld als een hsm. Los van de hardware is het valideren van de compiler en alle andere software ook een hele klus.
Nee het vinden van echt betrouwbare (kwaliteit en veilig) software is een hele uitdaging. Maar op het einde van de dag moet je iets en type ik lekker verder vanuit mn Windows....

[FireDrunk]

Daarom ben ik voorstander van goede frameworks. Je kan vrij veilig zeggen dat in de meest gangbare frameworks er redelijk goed nagedacht wordt over veiligheid. Dat is uiteraard geen garantie, maar als iedereen zijn eigen code gaat schrijven vanaf de grond af, weet je zeker dat er iig meer lekken zijn.

Ja, WordPress is vaak in het nieuws als het gaat om veiligheidslekken, maar intussen is het relatief veilig, en dat kan je van veel zelfgeschreven PHP code niet zeggen

En buiten dat, het getuigt van goed ontwikkelwerk als applicaties het niet nodig hebben om onder root te draaien.

(ik zei de gek , maar dat komt nog wel )

[ Voor 34% gewijzigd door FireDrunk op 18-05-2015 17:56 ]

[tvwes]

wopie schreef op maandag 18 mei 2015 @ 17:38:
[...]


Daar ^^ ben ik ook in geïnteresseerd (wil ooit nog eens van esxi af en SmartOS/OmniOS zijn in mijn ogen goede kandidaten hiervoor).

Als je vragen hebt dan hoor ik het graag. Ik kan je beter helpen met OmniOS dan SmartOS. SmartOS is meer ESXi en OmniOS is algemener en breder inzetbaar.
Ik heb de favoriete applicaties, SB SAB en CP, van @HyperBart (zijn vrouw) bij wijze van demo geinstalleerd in zones op OmniOS. Al deze apps draaien compleet los van elkaar maar delen storage. Los van het maken van de SMF manifests was het eigenlijk allemaal supersimpel en zo geregeld.

[FireDrunk]

Blech, de eerste dingen die ZFSmond al als root moet doen:

SMART uitlezen -> Set UID van smartctl zorgt er voor dat smartctl nog steeds klaagt
blockdev gebruiken -> op te lossen met sudo... gpasswd -a zfs disk
LibZFS-Python -> opgelost door udev regel

En zo hebben we geen root meer nodig

[ Voor 4% gewijzigd door FireDrunk op 18-05-2015 18:16 ]

[tvwes]

FireDrunk schreef op maandag 18 mei 2015 @ 17:55:
Daarom ben ik voorstander van goede frameworks. Je kan vrij veilig zeggen dat in de meest gangbare frameworks er redelijk goed nagedacht wordt over veiligheid. Dat is uiteraard geen garantie, maar als iedereen zijn eigen code gaat schrijven vanaf de grond af, weet je zeker dat er iig meer lekken zijn.

Ja, WordPress is vaak in het nieuws als het gaat om veiligheidslekken, maar intussen is het relatief veilig, en dat kan je van veel zelfgeschreven PHP code niet zeggen

En buiten dat, het getuigt van goed ontwikkelwerk als applicaties het niet nodig hebben om onder root te draaien.

(ik zei de gek , maar dat komt nog wel )

Maar om een socket <1024 te openen heb over het algemeen toch root rechten nodig. Die je, als je de applicatie juist hebt ontwikkeld, netjes na het opstarten laat vallen.

Genoeg grappen, gebruik maken van gevalideerde libraries en frameworks is heel slim. Het scheelt enorm veel tijd en kan een hoop ellende voorkomen. Alleen zijn veel van deze hulpmiddelen vaak van belabberde kwaliteit. Vooral interpreted talen hebben hier last van, hordes die in php of wat dan ook lekker aan het beunen zijn. Makkelijk is het niet om het goed te doen.

Psst.. Firedrunk wist je dat ook hier netjes omheen kan werken in Illumos? Met Privileges. Is iets anders dan eerder genoemde RBAC. Maar weer hoeft je applicatie geen root te zijn. .

[ Voor 3% gewijzigd door tvwes op 18-05-2015 18:24 ]

[FireDrunk]

Leuk, maar dat draaien we niet
Van mij mag je een port van zfsmond maken voor Illumos hoor

[tvwes]

Nou dat zal ik dan maar eens snel doen. Welke versie van smartmon heb je nodig? Staat niet in de prerequisites.

[FireDrunk]

Geen idee, mijn NAS heeft deze versie:

Installed Packages
Name        : smartmontools
Arch        : x86_64
Epoch       : 1
Version     : 6.2
Release     : 8.fc21
Size        : 1.5 M

[tvwes]

@Firedrunk, het zal even moeten wachten, iets teveel dependencies voor een global zone. Ik zou denk ik de disken wel zichtbaar kunnen maken in een zone maar dan zit ik nog met libzfs. Ik zal van de week wel een vm maken om het te testen.

[FutureCow]

Nadat ik vorige week een HDD retour heb gestuurd naar seagate, ook even de SMART waardes van mij SSD uitgelezen.

Wear Level Count staat op 3160
Wear Level Percentage staat op 106%!

is een SSD van crucial van bijna 3 jaar oud, is wel een beetje snel gegaan?
Zou dit kunnen komen doordat ik 1GB ZIL/SLOG op deze SSD gebruik?

Heb de pool 3 jaar gelezen aangemaakt en er toen wel wat over gelezen etc. maar ik vroeg mij eigenlijk af of ik een SLOG echt wel nodig heb. Gebruik de pool voornamelijk als streaming server voor het hele huis. En SB/Sabnzb etc die de boel download en uitpakt. Verder nog webdav voor bestanden die ik thuis en op het werk gebruik. En een backup van de andere PC's. Is een SLOG dan wel nodig?

Verder heb ik ook ZFSMond even getest. Kreeg het eerst niet aan de praat, omdat pip standaard python3 gebruikt en python standaard 2.7 is(lekker zo'n overgang van 2 naar 3)... dus met pip2 de boel wel aan de gang gekregen.

- Wat is precies filesystem, deze pagina blijft bij mij leeg
- Wellicht dat je SMART en ZFS gegeven kunt "loskoppelen" zodat je de zpool status info al wel laad, maar SMART alleen als je op de knop drukt.
- Met iets meer paniek(rood en ! ofzo) laten merken als een pool degraded is.
- Laatste scrub status laten zien.

Wellicht dat ik met een aantal dingen helemaal verkeerd zit te denken, laat maar horen!

[Verwijderd]

Zonder de SMART van je SSD te zien kan ik er niets over zeggen. Overweeg om een screenshot van de SMART in het SMART-topic te posten.

Als je L2ARC gebruikt is het wel noodzakelijk dat je veel aan overprovisioning doet. Als je dat niet doet, gaat je write amplification flink omhoog en brandt je dus sneller door de write cycles heen dan nodig. Dat komt bij mij neer op 'verbrassen'.

[Compizfox]

Verwijderd schreef op dinsdag 19 mei 2015 @ 12:14:
Als je L2ARC gebruikt is het wel noodzakelijk dat je veel aan overprovisioning doet. Als je dat niet doet, gaat je write amplification flink omhoog en brandt je dus sneller door de write cycles heen dan nodig. Dat komt bij mij neer op 'verbrassen'.

En TRIM dan?

[Verwijderd]

TRIM wordt niet gebruikt op L2ARC. FreeBSD is wel het enige platform dat TRIM op ZFS pools/filesystems ondersteunt, evenals via CAM/CTL op ZFS volumes, zoals wanneer je via iSCSI gebruik maakt. Door het GEOM-framework wordt TRIM in UNMAP omgezet, of meer technisch: het is een BIO_DELETE commando totdat het de device node bereikt en dan wordt bekeken of TRIM of UNMAP of CF-ERASE gebruikt wordt (ATA/SCSI/CompactFlash).

Bij gebruik van L2ARC zou ik 25% tot 50% OP aanraden. Eerder dus 40% dan iets als 25%. Bij de nieuwe MX200 zou het voordeel zijn dat je de SSD als SLC-SSD kunt gebruiken als je minder dan de helft van de SSD in gebruik hebt. Dat betekent wel dat je nooit mag schrijven naar de gereserveerde ruimte, en dat kun je met partities afdwingen.

[tvwes]

@Cipher,

misschien een klein beetje offtopic maar toch relevant omdat het de inzet van SSD's in een zpool aangaat.
Ik heb nooit kunnen achterhalen of het beperken van de te schrijven lba's dmv partities hetzelfde doet voor levensduur als dat je het max aantal lba's beperkt bijv door het instellen van een HPA of DCO?
In het eerste geval weet de firmware niet of jij toch niet bij de volgende write wel die ruimte wil aanspreken. In het andere geval maak je een instelling op de SSD die de firmware kan uitlezen en daar wat mee doen.

Los van het gemak dat je geen partities hoeft aan te maken door het max aantal lba's te beperken heb ik er hele goede ervaring mee. Het uiteindelijk aantal TBW's oversteeg de verwachtingen ruimschoots. Maar ik heb nooit daar vanuit de fabrikanten iets van bevestiging over kunnen krijgen. Op congressen is als het om SSD techniek gaat altijd doodse stilte als je zo'n specifieke vraagt stelt.

Een algemene regel zal het nooit zijn want het is aan de fabrikant om iets te doen met deze hint.

[Verwijderd]

De SSD 'weet' dat omdat de mapping tables dat vertellen. Een hardeschijf zou dit niet weten omdat het geen index bijhoudt van de opslag. De LBA is gewoon 1:1 gemapped met fysieke sectors. Alleen reserve sectoren die zijn gebruikt om bad sectors te remappen, vormen hierop een kleine uitzondering. Dat betekent dus een kleine check voor elke LBA of dit remapped sectoren betreffen. Maar bij SSDs is het andersom: alles wordt geindexeerd.

Dat betekent ook dat een SSD die gloednieuw is, 100% OP heeft. Alle oppervlak is voor de SSD intern beschikbaar, zoals voor redirected writes; writes die niet naar de plek worden geschreven waar de host wilt, maar naar een andere plek omdat daar een vrije erase block is en dus niet eerst een blok gewist hoeft te worden. Dit is write remapping/redirection en dat is sinds de Intel X25-M de standaard; de SSD die ook NCQ en dus hoge multiqueue random I/O mogelijk heeft gemaakt en nog veel meer innovaties. Nog steeds wordt deze controller gebruikt, zoals op het ZFSguru forum nu iemand die met vier keer Intel 710 gaat werken voor een high-end build. Nog steeds supergoed bruikbaar voor ZFS.

Maargoed, het werkt dus zo dat alle plekken van de logische LBA (zoals de host hem ziet) die niet beschreven zijn, als overprovisioning tellen; oftewel spare space. Als je enkel statische data (grote bestanden die één keer van a-z geschreven worden en daarna alleen maar gelezen) opslaat, dan heb je vrijwel geen spare space nodig. Maar bij veel random writes, zoals bij L2ARC het geval is, heb je wel meer spare space nodig. In deze grafiek zou L2ARC de roze lijn zijn:



Enterprise SSDs hebben standaard al overprovisioning. Intel 710 is 100GB zichtbaar maar 128GiB fysiek NAND. Idem met de X25-E 32GB->40GiB en vrijwel alle moderne enterprise SSDs. FusionIO kun je de OP instellen met iets van een jumper ofzo. Elke SSD heeft trouwens OP, maar dat zit in het verschil tussen GB en GiB verstopt; dus 6,7% en daarbinnen wordt ook nog de RAID5 bitcorrection (1:128) verstopt. Dus consumenten SSDs hebben héél weinig OP en vertrouwen op normale use cases met TRIM. Bij gebruik van ZFS L2ARC ga je gauw door je write cycles heen als je geen OP toepast.

Software utilities van SSD fabrikanten kunnen ook OP toepassen via hun utilities. Jij noemt het via de HPA beperken van de LBA - cappen dus - maar dat is ook enkel effectief als die ruimte eerst geTRIMed was, of nog nooit beschreven. Voor zover ik weet althans; in theorie kan de SSD eerst zelf de ruimte vrijmaken. Maar theorie en praktijk zijn niet altijd gelijk, zelden helaas.

[tvwes]

@Cipher,

bedank voor je uitgebreide reactie. Ik had erbij moeten zeggen het beperken van de capaciteit inderdaad alleen op een nieuwe of gewiste SSD moet plaatsvinden. Het tweede wat ik erbij had moeten zetten is ik vooral kijk naar een situatie zonder TRIM of UNMAP.
Heb ik het goed begrepen dat jij niet verwacht noch hebt waargenomen dat het cappen via een ATA of SCSI commando ipv een partitie het aantal TBW verhoogt omdat de firmware iets slimmers kan doen omdat het weet dat jij die ruimte niet gaat gebruiken. (Wat overigens bij een HPA helemaal niet het geval hoeft te zijn)
Toch zet het te denken dat, wat jij schreef, als fabrikanten utilities maken om de OP hard in te stellen het waarschijnlijk is dat de firmware meer rendement kan behalen dan met aanmaken van een partitie.

Ik heb zelf heel weinig ervaring met sata ssd's wel met sas varianten maar dat is een totaal ander segment. Ook die sas ssd's werden regelmatig gecapped om zo meer OP te realiseren en zo een langere levensduur. En nee, de zeusram was altijd te klein:)
Ik heb prive een aatal intel 320 allemaal 25% gecapped in een zpool als gewone vdev's als ik die machine een keer reboot dan zal ik eens kijken wat daar nog van over is.
Zijn die mx200's wat als vdev? Of moet ik gewoon bij intel blijven?

[FireDrunk]

Toch zet het te denken dat, wat jij schreef, als fabrikanten utilities maken om de OP hard in te stellen het waarschijnlijk is dat de firmware meer rendement kan behalen dan met aanmaken van een partitie.

Ik denk dat het vooral bedoeld is als permanente' oplossing. Een overprovision blijft na een format / power cycle of wat dan ook gewoon bestaan. Dus ook als je windows opnieuw installeert

Het is denk ik persoonlijk gewoon handig... Niet verplicht.

Voor jouw beeldvorming, ik heb ook Intel 320's gehad, en X25-M's. Nooit overprovisioned, en echt, *veel* benchmarks tegenaan gehad. Ook flinke tijd als L2ARC en ZIL gebruikt.

Die dingen hebben volgens mij wel 10TBW gehad voordat ze hier de deur uit gingen, en ik denk dat die dingen het nu nog steeds doen.

Onverwoestbaar

---
Ik heb overigens een nieuwe versie van ZFSmond gepushed

Nieuwe features:

- Scrub info (inc kleurtjes!)
- Statistieken van je pool (inc auto-refresh elke seconde)

[ Voor 9% gewijzigd door FireDrunk op 19-05-2015 22:47 ]

[A1AD]

Bah ik vind het even niet: ik krijg mijn (test) pool niet imported at boot...ZoL op Debian Wheezy met ZoR. De root pool is wel ok maar een bijkomende, net aangemaakte RaidZ1 pool is weer verdwenen na de reboot. "zpool import pool" werkt wel gewoon.

Ik heb al een tijdje zitten googlen zonder al te veel succes (veel over automount). Heeft er iemand een hint voor mij?

[FireDrunk]

Wat zegt je zpool.cache ?

[tvwes]

FireDrunk schreef op dinsdag 19 mei 2015 @ 22:46:
[...]

Ik denk dat het vooral bedoeld is als permanente' oplossing. Een overprovision blijft na een format / power cycle of wat dan ook gewoon bestaan. Dus ook als je windows opnieuw installeert

Dat blijven settings als HPA, DCO en MaxAddress ook.

Het is denk ik persoonlijk gewoon handig... Niet verplicht.

De tool van de fabrikant is bijna altijd gemakkelijker dan de obscure dos tooltjes.

En verplicht is het zeker niet(, dat heb ik ook nooit geschreven)

Blijft de vraag of de OP setting via de utility van de fabrikant meer doet dan het beperken via de ATA cmd's

Voor jouw beeldvorming, ik heb ook Intel 320's gehad, en X25-M's. Nooit overprovisioned, en echt, *veel* benchmarks tegenaan gehad. Ook flinke tijd als L2ARC en ZIL gebruikt.

Die dingen hebben volgens mij wel 10TBW gehad voordat ze hier de deur uit gingen, en ik denk dat die dingen het nu nog steeds doen.

Onverwoestbaar

Zelfs als ZIL, dat kan hard gaan. Ik moet eens in mijn statistieken duiken om te achterhalen hoeveel die 320's van mij per dag te verduren krijgen. Toch best wat, alle vm's enkele grote builds. Wat ik wel weet is dat mijn gbit nic gem. het afgelopen jaar 132mbit ingress had. Daar komt het nodig van de zones bij.
Wat je schreef die 320's zijn zo goed als onverwoestbaar, echt waar voor je geld.

---
Ik heb overigens een nieuwe versie van ZFSmond gepushed

Nieuwe features:

- Scrub info (inc kleurtjes!)
- Statistieken van je pool (inc auto-refresh elke seconde)

Ik kan er pas in een vm naar kijken...

[Compizfox]

Verwijderd schreef op dinsdag 19 mei 2015 @ 17:25:
TRIM wordt niet gebruikt op L2ARC. FreeBSD is wel het enige platform dat TRIM op ZFS pools/filesystems ondersteunt, evenals via CAM/CTL op ZFS volumes, zoals wanneer je via iSCSI gebruik maakt. Door het GEOM-framework wordt TRIM in UNMAP omgezet, of meer technisch: het is een BIO_DELETE commando totdat het de device node bereikt en dan wordt bekeken of TRIM of UNMAP of CF-ERASE gebruikt wordt (ATA/SCSI/CompactFlash).

Bij gebruik van L2ARC zou ik 25% tot 50% OP aanraden. Eerder dus 40% dan iets als 25%. Bij de nieuwe MX200 zou het voordeel zijn dat je de SSD als SLC-SSD kunt gebruiken als je minder dan de helft van de SSD in gebruik hebt. Dat betekent wel dat je nooit mag schrijven naar de gereserveerde ruimte, en dat kun je met partities afdwingen.

Hmm, dat wist ik niet. Ik ging er eigenlijk gewoon vanuit dat TRIM z'n werk wel zou doen... Had ik het even mooi mis dan.

[FireDrunk]

De meeste moderne SSD's hebben al vrij goede offline garbage collection die ingrijpt op het moment dat TRIM niet (goed) werkt.

Er zijn wel websites die dat testen, ik dacht dat AnandTech dat deed, en daar kon je zien dat SSD's toch nog steeds redelijk presteren tegenwoordig, zelfs zonder TRIM.

[Compizfox]

Maar kan je daar wel wat mee als je geen overprovisioning (en ook geen TRIM) hebt dan?

Je zou denken dat op een gegeven moment 'vanuit de SSD gezien' alle pages volzitten. In andere woorden: de hele SSD is een keer beschreven geweest, ook al is er op dat moment misschien maar 15% van de ruimte 'echt' in gebruik.

Zonder TRIM kan de SSD in dat geval toch niet weten dat 85% van de pages vrij is? De SSD denk gewoon dat hij 100% vol zit, daar gaat geen garbage collection wat aan doen lijkt me.

[ Voor 18% gewijzigd door Compizfox op 20-05-2015 00:20 ]

[FireDrunk]

Een ssd kan gewoon scannen naar lege blokken. Als je echt je ssd een keer vol schrijft met random data, werkt dat niet nee, maar lege ruimte in een partitie werkt wel.

[Verwijderd]

FireDrunk schreef op woensdag 20 mei 2015 @ 00:06:
De meeste moderne SSD's hebben al vrij goede offline garbage collection die ingrijpt op het moment dat TRIM niet (goed) werkt.

Ja, maar dat wil je niet. GC betekent trage writes omdat voordat de write kan plaatsvinden er eerst een erase blok vrijgemaakt moet worden. Als je dat offline doet (in de achtergrond) betekent dit evengoed prestatieverlies vooral bij zakelijke gebruikers die hun SSDs daadwerkelijk benutten/belasten in tegenstelling tot consumenten. Bovendien, als je met weinig OP continu blokken gaat zitten vrijmaken, dan krijg je dus een heel hoge write amplification en dat wil je dus juist absoluut niet.

Daarom is het noodzakelijk om OP toe te passen als je L2ARC gaat gebruiken. De hele SSD gebruiken voor L2ARC is onzinnig, omdat je daarmee in rap tempo door de write cycles brandt door de veel hogere write amplification. Dat is dus het 'verbrassen' van je SSD.

Het is natuurlijk niet voor niets dat zakelijke SSDs bijna zonder uitzondering standaard al een berg OP hebben. Het zijn alleen consumenten die door hun matige gebruik weg kunnen komen met 3% OP.

Serieuze zakelijke gebruikers schakelen TRIM ook veelal uit. Het werkt performance vertragend omdat de mapping tables continu moeten worden bijgewerkt, en als je een SSD voor minder dan 50% gebruikt heb je TRIM ook helemaal niet nodig. Gewoon via lazy allocation zorgen dat je passief (dus zonder background GC) altijd een poel van vrije erase blocks hebt.

Compizfox schreef op woensdag 20 mei 2015 @ 00:19:
Maar kan je daar wel wat mee als je geen overprovisioning (en ook geen TRIM) hebt dan?

Elke SSD heeft spare space / OP. Een SSD met write remapping kan niet functioneren als er niet tenminste iets van OP is. Het is een fundamentele noodzaak. Alleen SSDs van vóór de Intel X25-M generatie doen niet aan write remapping; Mtron en Memoright uit mijn hoofd. Die waren dan ook ruk met random writes en daarom in sommige gevallen trager dan een hardeschijf.

Je zou denken dat op een gegeven moment 'vanuit de SSD gezien' alle pages volzitten. In andere woorden: de hele SSD is een keer beschreven geweest, ook al is er op dat moment misschien maar 15% van de ruimte 'echt' in gebruik.

Nee, want wanneer de SSD write remapping toepast, komen de oude blokken weer vrij. Zolang je iets van 20-30% OP hebt, kun je dus altijd vrije erase blokken vinden en heb je dat hele TRIM niet nodig.

Overigens gaat het niet om vrije pages; het gaat om vrije erase blocks. Dus allemaal snippertjes van 8K heb je niets aan; het gaat om 640K - 16MiB blokken die geheel leeg moeten zijn. Pas dan kan de SSD hier naartoe schrijven (write redirection) zonder eerst het hele blok te moeten wissen; want dat is heel traag. Als je genoeg OP hebt, dan zullen er door de write redirection ook continu lege plekken ontstaan en er altijd wel een aantal erase blocks vrij zijn.

[FireDrunk]

Wat jij 'write redirection' noemt, noem ik ook garbage collection. We zitten zeker op 1 lijn hoor.

Wat ik alleen onder 1 noemer schaal is het efficient omgaan met writes, en zorgen dat er genoeg vrije ruimte is.
En dat noem ik "Garbage collection". Die terminologie klopt misschien niet honder procent, maar dekt wel grotendeels de lading

Wat je nog vergeet te melden misschien is dat write redirection ook service time kost. TRIM kan je OS zelf uitstellen, Write Redirection door de SSD kan dat toch niet?

[tvwes]

@Cipher,

we hebben vaak een verschillende mening maar hier ben ik volledig met je eens.
Wat je schreef over het uitschakelen van trim is ook een van de redenen dat het ontbreekt in (Illumos)ZFS. Het is een non issue bij (zakelijke) SSD's met veel OP. Grappig genoeg is bijvoorbeeld wel UNMAP geimplementeerd in de iSCSI target wat helpt bij het sparse houden van sparse volumes.
Ook aangaande de performance sla je de spijker op zn kop. Het gaat niet om de allerhoogste transfer snelheid die alleen in fabrieks toestand wordt gehaald. Nee het gaat om een consistente performance gedurende de levensduur van de SSD. Waarbij de standarddeviatie zo klein mogelijk moet, dit voor latency en transfersnelheid. Je wilt niet dat door GC plots de prestaties instorten. Mijn ervaring is dat royale OP helpt bij het behalen van een consistente performance.


PS had je nog nog gedacht over mijn vraag of een MX200 een redelijke vervanging is voor een 320 als vdev's?

[Verwijderd]

Write redirection wil zeggen dat de SSD naar een andere plek schrijft, omdat dat sneller is. Dit is wat alle moderne SSDs doen. Write redirection betekent dat je mapping tables nodig hebt; dus deze feature verandert de hele fundamentele opzet/design van een SSD - het is de write redirection feature die zorgt dat een SSD zoveel anders werkt dan een HDD. Want logische LBA is niet meer direct gekoppeld aan fysieke NAND adressen; dat loopt nu allemaal via een tabel.

Garbage collection is het mechanisme dat de SSD gebruikt om vrije erase blocks te maken. Je hebt daarbij:

• Foreground GC (passive GC) - deze doet niets op de achtegrond maar alles op de voorgrond. Pas als er een write is en geen vrije erase block, pas dan wordt GC toegepast om die erase block vrij te krijgen ergens. En dat betekent dus dat die ene I/O wordt vertraagd omdat er eerst een boel werk verzet moet worden. Maar het voordeel is dat je geen I/O op de achtergrond hebt wat ook voor performancedegradatie kan zorgen. Ook is het het 'zuinigst' met het verbruiken van write cycles. Dit type GC werkt het beste als je flink wat OP toepast. Dan zit je aan 1.02 write amplification factor; grofweg het beste mogelijk zonder trucjes van Sandforce (dedup&compressie).
• Background GC (active GC) - deze gaat als een background job continu erase blocks proberen vrij te maken. In feite een continu 'defragmentatie' die de SSD intern uitvoert. Het betekent flink meer writes en dus lagere levensduur, maar wel beter behoud van prestaties ook op een volle SSD of eentje die op een slechte manier gebruikt wordt. Vooral gebruikt in consumenten SSDs die hoge cijfertjes willen laten zien en maar flink inleveren op write cycles. Vooral Samsung is hier een goed voorbeeld van. Agressieve GC noem ik het ook wel.

Kortom, GC heb je altijd wel. Maar er bestaan verschillen. Intel doet GC van het eerste type en dat is wat je wilt onder ZFS. Want met weinig OP zou background GC je hele SSD opvreten omdat het continu je writes zit te schrijven naar andere locaties. Dat is gewoon heel erg inefficiënt en kost je ook performance omdat je SSD continu bezig is 'met zichzelf'.

[ Voor 5% gewijzigd door Verwijderd op 20-05-2015 09:38 ]

[FireDrunk]

Daar ben ik het dan weer niet helemaal mee eens. Als je NAND *echt* goed is, neem ik die write amplification voor lief. Als dat er voor zorgt dat mijn SSD altijd in top conditie is, en ik zal in zijn levensduur (lees 5-10 jaar) niet door de write cycles heen komen, is dat toch prima?

Zelfs voor ZFS (mits voor thuisgebruik dan). Uiteraard heb je gelijk als je 100% van de dag op zo'n SSD staat te hameren dat je geen write amplification wil, maar dat gebeurt zelden hier bij thuisgebruikers.

Voor bijvoorbeeld een VMware omgeving is het leuk om een snelle ssd als ZIL of L2ARC te gebruiken. Die paar keer dat je er mee bezig bent is alles lekker snel, en op het moment dat de omgeving stil staat, kost het je ook geen write cycles.

[Verwijderd]

Bij consumentengebruik kun je 80 jaar doen met een SSD. Maar bij verkeerd gebruik van L2ARC kan je SSD binnen enkele maanden op zijn. Dat kan hard gaan als de write amplification flink oploopt. Sowieso zijn zakelijke gebruikers min of meer de enige die hun SSDs daadwerkelijk opgebruiken - dus alle write cycles benutten. L2ARC valt grotendeels onder het type gebruik wat je bij zakelijke gebruikers ziet.

Als jij een kleine SSD als L2ARC gaat gebruiken en die L2ARC ook daadwerkelijk het niveau bereikt dat de SSD geen spare space meer heeft, dan kan het ook in een thuissituatie hard gaan. Maar L2ARC is niet zo heel populair voor thuisgebruik - want thuisgebruikers hebben vooral grote bestanden die sequentiëel worden gelezen, en daar doet de L2ARC cache niets mee. Maar zoals recent op ZFSguru forum iemand: die gaat vier keer Intel SSDs inzetten voor een L2ARC voor VM storage dus dan geldt dat het niet toepassen van OP enorm zonde is en de levensduur van de mooie Intel SSDs ernstig zal beperken. Gelukkig hebben zijn Intel 710's SSDs standaard al 30% OP. Dat mag je verwachten van zakelijke SSDs. Daarbovenop kun je dan nog eens 20% extra gooien.

Bovendien, als je je L2ARC tot 40GiB zou beperken; dat is al enorm veel 40 gigabyte aan snippertjes van random writes. Dat komt neer op 10 miljoen blokjes van 4K. Behoorlijk wat caches zijn dat. Dus beperken van je SSD wanneer je L2ARC gebruikt is gewoon enorm logisch.

[tvwes]

@Cipher
Je hamert wel heel erg op L2ARC's. Je verhaal is heel algemeen van toepassing. En nog meer van toepassing op bijv een SLOG, ook al kan je daar beter in de eerste plaats geen SSD voor gebruiken. De SLOG kent bijna alleen maar een write load. Ook gewone vdevs kunnen een veel hogere write load dan l2arc's kennen. Het zou kunnen dat er alleen naar de l2arc geschreven wordt en nauwelijks naar de zpool, maar dat is heel uitzonderlijk. Zelfs thuis. 'wat je al schreef de meeste sequentiele reads komen nooit in de L2ARC terecht. Daarnaast komt niet iedere read in de l2arc terecht.

Nogmaals ik ben het helemaal met je eens, alleen is het algemeen toepasbaar en hoeft een L2ARC helemaal niet zo'n extreme write load te kennen als jij schetst.

[tvwes]

Dan nog even dit in het algemeen mbt tot de L2ARC

Je moet wel voldoende ram hebben voor je L2ARC. Een L2ARC van 400GB op een systeem met 8GB ram zal maar voor een stukje gebruikt worden. De L2ARC is een subset van de (L1)ARC en die bevind zich in ram. De L2ARC maakt het mogelijk om ARC data uit ram te pagen naar de L2ARC maar uit eindelijk moet de lijst van arc_buf_hdr's wel in ram passen ook al is het een pointer naar de L2ARC. Reken met 200 bytes per zfs record in de lijst. Nu kan je denken dat je met de default 128k record size toch wel een heel eind kan komen. Dat is waar. Maar de vraag is of je ook echt de volle 128K nodig had. Mijn ervaring is van niet. Al die die data je eigenlijk niet nodig had is nu voor niets naar je SSD geschreven en dat is ook "verbrassen"

Een L2ARC haalt zo goed als niets uit voor het streamen van films. Ook is het beter om de recordsize voor deze toepassing op 128K te laten staan.
Heb je wel echte random io, een miljoen files, vmware datastores etc dan kan een L2ARC zin hebben. Voor die datasets heeft het ook vaak zin de recordsize te verlagen naar bijv 8K.

En diegene van ZFSguru die met 4 SSD's als L2ARC aan de slag gaat kan voor een nare verrassing komen te staan als er eentje faalt. Want op dat moment werkt de zpool wel maar de L2ARC is weg. Er is geen redundancy. Failure van de L2ARC kan voor een enorme performance clif zorgen.

[Verwijderd]

L2ARC is vrijwel enkel random writes en random reads - toch?! sLOG daarentegen is vrijwel helemaal sequential write. Bovendien is een sLOG partitie veel kleiner: 1 tot 4 gigabyte is al ruim voldoende in 99,9% van de gevallen. Dit betekent dat de SSD continu dezelfde ruimte overschrijft. Dat is heel gunstig voor de SSD, want met het overschrijven van de oude gegevens komen deze blokken weer vrij. De SSD overschrijft niet letterlijk de bestaande gegevens; deze worden remapped naar vrije ruimte op de SSD. Maar doordat de oude blokken weer vrijkomen is er een cyclus van erase blocks die beschikbaar komen en dit is dus een heel gunstige situatie voor de SSD: ruim voldoende erase blocks, dus ook maximale performance én maximale write endurance (levensduur).

L2ARC is inderdaad iets minder erg dan ik schets; maar enkel omdat de L2ARC een limiet kent:

code:

vfs.zfs.l2arc_write_max: 8388608

Onder BSD is dus 8MiB /sec de maximum om L2ARC te populeren. Maar het is veelal nuttig deze limiet flink op te schroeven, zoals in het begin waar de L2ARC lekker vol dient te stromen. Dan kun je rustig 200MiB aan random writes doen en ik hoef je niet te vertellen dat enige uren van dit kaliber I/O zeker wel een uitdaging is voor de SSD.

Voor thuisgebruikers is L2ARC een ander verhaal; het wordt nauwelijks gebruikt. Bovendien is ZFS L2ARC niet bijzonder nuttig voor thuisgebruikers omdat de cache verdwenen is bij een reboot of power cycle - in tegenstelling tot sommige andere caches. Voor thuisgebruik is L2ARC dus in de praktijk minder zwaar, omdat er minder belasting is en de belasting die er is vooral sequential I/O betreft. Dus de L2ARC wordt maar heel spaarzaam gebruikt. Om 10GiB L2ARC vol te krijgen in een thuissituatie is niet persé triviaal.

De persoon die 4 Intel SSDs gaat gebruiken als L2ARC heeft standaard al 128GiB DDR4 RAM in de machine zitten. De L2ARC is er min of meer voor om dit te amplifyen naar iets van 300GB 'RAM'. De stelregel is volgens mij ongeveer 1:10 afhankelijk hoe klein je snippertjes zijn gemiddeld, dus voor 10GB L2ARC heb je 1GB RAM nodig. 200GiB L2ARC zou in dat geval 20GiB RAM kosten; dus je gaat van 128->108GiB RAM maar je krijgt daar wel 200GiB L2ARC voor terug.

PS had je nog nog gedacht over mijn vraag of een MX200 een redelijke vervanging is voor een 320 als vdev's?

M500/M550/M600/MX100/MX200 zijn allemaal geschikt als sLOG naar mijn mening/inschatting. Dit omdat ze de FLUSH commando's eerbiedigen, iets wat Samsung niet doet. Samsung SSDs zijn ongeschikt voor sLOG, Intel 320 is het beste (Volledige capacitors voor 192K SRAM buffercache) en Crucial MX100/MX200 is een goedkope keuze.

De MX200 is extra leuk als je de 128GB versie neemt, die heeft dynamic write acceleration. Dit betekent dat een deel van de NAND als SLC gebruikt kan worden om performance te boosten. Als je minder dan de helft van de SSD in gebruik zou hebben, zou dit betekenen dat je de SSD in feite als SLC SSD gebruikt. Dat betekent dus maximale write endurance en maximale performance.

[tvwes]

Weer zien we hoe lastig het is om algemene adviezen te geven. Cipher heeft volkomen gelijk aangaande de SSD techniek maar voor ZFS vdevs als L2ARC, SLOG of data is het heel moeilijk uitspraken te doen iedere workload is anders. Het enige wat zeker is dat als een SSD wordt voorzien van grote OP dmv een partitie, ATA cmd of fabrikant utility het de prestaties en de levensduur van de SSD aanzienlijk zal verlengen.

Die vuistregel klopt redelijk maar is afhankelijk van de recordsize. Als deze gebruiker voor de rest niets anders met de 128GB hoeft te doen zal het wel loslopen en zal de L2ARC zeker een goede bijdrage kunnen leveren. Al ben ik benieuwd wat zijn L2 hit ratio zal zijn. Zeker met 128GB ram heb je al zo'n grote ARC dat de L2ARC vaak minder bijdraagt dan je zou verwachten. Maar dat hangt erg af van de data en toegang.

Ik wil de SSD's inzetten als boot schijf en gebruiken voor zones en vm's. Ik heb een ram based slog dus daar hoef ik me geen zorgen over te maken. En een intel DC versie is ook over de top. Ik denk dat ik dan 2 mx200 van 500gb zal bestellen.

[FireDrunk]

Dat de server 128GB RAM heeft, zegt natuurlijk niets of hij daadwerkelijk die hele 128GB aan ARC gaat geven...

Ik gok dat er ook wel wat VM's op komen te staan, dus het kan best zijn dat hij gewoon 'maar' 16GB aan ARC geeft, en de rest aan VM's geeft. Dan is een groot L2ARC misschien wel weer leuk ivm caches voor de VM's.

Maar het is exact wat je zegt: We weten de workload niet

[Verwijderd]

Hij heeft 15 dedicated VM hosts en 2 NAS/SAN boxen. Hij wilt de oudere NAS/SAN naar ZFS (ZFSguru) migreren en daarbij upgrade hij de hardware, met name het geheugen naar 128GiB. De SSDs en HDDs hergebruikt hij; de rest wordt nieuw gekocht.

Dus de NAS is 100% storage en niks anders; de 15 VM hosts hebben elk 10Gbps ethernet en ik vermoed dat dit genoeg I/O belasting zal opleveren om het een ZFS NAS flink moeilijk te maken. Virtualisatie kenmerkt zich namelijk door veel random I/O en veel fragmentatie. Dus je gaat de ARC wel nodig hebben anders valt hij terug op 7200rpm disks en dat zuigt natuurlijk voor random reads.

Concrete user-case: http://zfsguru.com/forum/buildingyourownzfsserver/953

[ Voor 5% gewijzigd door Verwijderd op 20-05-2015 15:09 ]

[FireDrunk]

Aha, als hij veel dezelfde VM's draait zou ik zelfs deduplication aanraden, maar goed, dat is een andere discussie.

Leuk speelgoed iig

Wel een beetje jammer dat hij voor ZFSguru kiest voor een productieomgeving

[Verwijderd]

Ach wijsheid komt met de jaren.

[FireDrunk]

Of niet

[tvwes]

Verwijderd schreef op woensdag 20 mei 2015 @ 15:09:
Hij heeft 15 dedicated VM hosts en 2 NAS/SAN boxen. Hij wilt de oudere NAS/SAN naar ZFS (ZFSguru) migreren en daarbij upgrade hij de hardware, met name het geheugen naar 128GiB. De SSDs en HDDs hergebruikt hij; de rest wordt nieuw gekocht.

Dus de NAS is 100% storage en niks anders; de 15 VM hosts hebben elk 10Gbps ethernet en ik vermoed dat dit genoeg I/O belasting zal opleveren om het een ZFS NAS flink moeilijk te maken. Virtualisatie kenmerkt zich namelijk door veel random I/O en veel fragmentatie. Dus je gaat de ARC wel nodig hebben anders valt hij terug op 7200rpm disks en dat zuigt natuurlijk voor random reads.

Concrete user-case: http://zfsguru.com/forum/buildingyourownzfsserver/953

Ik heb de thread even gelezen maar het blijft allemaal een beetje vaag. "Ik draai vm's in kvm en vmware" "ik gebruik iscsi en nfs" "ik ga twee slogs gebruiken" "ik gebruik sata en sas drives" "19 sas drives met 8 poorten" Zonder meer info is er weinig zinnigs over te zeggen en geeft ie een hoop geld uit een suboptimale nas.
Heeft hij de SLOG uberhaubt wel nodig?
Via welk protocol wil hij zijn vm's ontsluiten?
Hoe wil hij 19 drives aansluiten op 8 poorten?

Misschien levert het een veel betere performance op als hij die 4 SSD's als datastore gebruikt voor zn VM's om maar eens iets te noemen.

In ieder geval weten we nu dat het volle geheugen (128GB) als ARC gebruikt kan worden. Mijn inschatting is dat de L2ARC weinig effect zal hebben behalve voor de vm's. Maar dan zou ik altijd daarvoor een losse zpool aanmaken met de SSD's, mits het past.

[FireDrunk]

15 hosts met ik gok minimaal 32GB RAM, met een gemiddelde van 4GB ram per vm, maakt 100+ VM's

Als je gemiddeld 50GB per VM aan storage nodig hebt (wat niet absurd hoog is), zit je dus op 5TB aan VM storage.

Ik zou daar geen SSD's voor willen kopen...

[Verwijderd]

@tvwes: VMs is het enige dat er is?! En ik gok dat het gewoon om VPS gaat dus een blok data ter beschikking wordt gesteld. Dat allemaal op SSDs opslaan lijkt me geen haalbare oplossing. Hij heeft ook nu maar 4x100GB SSDs; geen goedkopere 1TB consumentenmodelletjes die hiervoor goed in aanmerking zouden komen. Hij gaat dus denk ik wel de L2ARC nodig hebben.

Maar ik was ook van plan hem aan te raden eerst te beginnen met een kale configuratie en kijken hoe de ARC gebruikt wordt en pas later L2ARC en sLOG inzetten. Dat kan terwijl het systeem draait, als hij niet makkelijk een testcase kan vinden.

@FireDrunk: zelf zegt hij:

So, for the virtualization hosts (a mix of VMware and Linux KVM) I didn't specify which hardware they are running (because I thought it wouldn't matter much), but basically they are all 2x E5-26xx, 96+ GB of memory and most have 10Gbit network. On the vmware boxes I use iSCSI with VMFS on top and on the Linux boxes I use NFS to get to the VM disk images.

Dus 96GiB+ RAM per VM host, en daar 15 van met de meeste 10Gbps ethernet. Dat is een aardige hoeveelheid VPSen en dus ook storage die daaraan hangt en tegelijk I/O uitvoert. Ik denk dat hij alle RAM en L2ARC goed kan gebruiken!

[ Voor 4% gewijzigd door Verwijderd op 20-05-2015 16:04 ]

[FireDrunk]

Inderdaad, zeker waar. Wel een leuk project hoor
Doe mij die maar

[tvwes]

@Firedrunk Maar nu doen we weer aannames. Misschien zijn het wel hoofdzakelijk linked clones? Stel dat het wel 5Tb aan storage is. Dan krijg je de vraag of sommige vm's misschien niet de io's van de ssd's toch heel goed kunnen gebruiken, zoals de genoemde exchange en sql server. Misschien dat die de performance boost heel goed kunnen gebruiken. Een dedicated SSD zpool is altijd veel sneller dan een L2ARC en disken. Met 10GBit kan je ook echt de SSD naar hun max benutten. Je andere vm's serveer je dan vanaf de harddisks.
Wat me ook niet zou verbazen is als deze daemon ook nog eens zn 19 disken in brede RAIDZ stripe stopt. Over performance gesproken...
@Cipher, dat eventueel naderhand toevoegen van een SLOG of L2ARC is inderdaad heel slim. (Alleen dat stond nergens volgens mij..) In die thread die jij opgaf was jij die enige die het woord VPS gebruikte en dan ook nog in vragende vorm. Daemon heeft het constant over VM's en "maximum performance" in de eerste zin. Dan is mijn all SSD pool op zich niet onredelijk. Nogmaals we en ik zeker niet weet niet wat de bedoeling is en dat maakt de discussie een beetje lastig. Neem het in gebruik, draai arc_summary en bepaal of hij er baat bij heeft zoja dan voeg je er "hot" eentje toe en kijk je opnieuw, veel L2 hits? Dan nog eentje erbij.
Als hij de maximum performance wil met de grootste capaciteit dan zijn 8 mirrors met een of meer L2ARC's het grootste in capaciteit en levert de beste performance op. Hij zal ook wel moeten voor kiezen voor die 8 mirrors wil hij iets aan zn 10GBe hebben je krijgt dat anders nooit benut en met random io's al helemaal niet.

Klaarblijkelijk is dit geen thuis gebruiker dus mag ik ook een zakelijk mening geven. En mijn mening is dat dit aan alle kanten een niet doordacht plan is. Je moet je doelstellingen helder formuleren en je workload kennen dan rolt de oplossing ervan zelf uit. Een belangrijk gedeelte van mijn werk is dit soort trajecten begeleiden. Vandaar dat ik hier zo alert op ben. Beroepsdeformatie zullen we maar zeggen

[A1AD]

FireDrunk schreef op dinsdag 19 mei 2015 @ 23:05:
Wat zegt je zpool.cache ?

Hoe laat ik zpool.cache praten? Via cat krijg ik maar vreemde tekens.

[FireDrunk]

Hmm daar zeg je wat... Dacht dat het leesbaar zou zijn.

Wat je kan proberen:
Zpool export pool
Rm zpool.cache
Zpool import -d [dir] poolnaam
Reboot

[A1AD]

FireDrunk schreef op woensdag 20 mei 2015 @ 20:50:
Hmm daar zeg je wat... Dacht dat het leesbaar zou zijn.

Wat je kan proberen:
Zpool export pool
Rm zpool.cache
Zpool import -d [dir] poolnaam
Reboot

Geen verschil Kan ik niet gewoon een import doen in cron @reboot? Of wordt dit niet gedaan? _{Ik zou de pool wel op de juiste manier willen importeren natuurlijk}

[tvwes]

A1AD schreef op woensdag 20 mei 2015 @ 21:12:
[...]


Geen verschil Kan ik niet gewoon een import doen in cron @reboot? Of wordt dit niet gedaan? _{Ik zou de pool wel op de juiste manier willen importeren natuurlijk}

Wat is precies het probleem?

[A1AD]

tvwes schreef op woensdag 20 mei 2015 @ 21:14:
[...]
Wat is precies het probleem?

Ik ben ZoL aan het testen op Proxmox (debian 7). Er is alreeds een zfs pool (rpool) voor root aanwezig door de installer. Nu wil ik van de 3 overige schijven een RaidZ1 pool maken (NAS). Maar na een reboot moet ik de NAS pool weer zelf importeren. Ik weet ook niet goed hoe ik dit moet opzoeken, "auto import zpool debian ..." geeft niet de gewenste resultaten.

Ik vraag mij ook af hoe zfs weet wat hij moet importeren at boot.

edit: al gedaan in /etc/default/zfs de ZFS_MOUNT op yes gezet. Maar heeft volgens mijn logica niets te maken met al dan niet importeren?

[ Voor 10% gewijzigd door A1AD op 20-05-2015 21:23 ]

[tvwes]

Verwijderd schreef op dinsdag 19 mei 2015 @ 18:13:
[afbeelding]

@Cipher, ik heb een vraag over die grafiek. Hoe kan je een A_f krijgen kleiner dan 1? Als ik 1GB schrijf naar de SSD dan moet de SSD toch ook 1GB naar NAND schrijven? (Compressie en dedup buitengelaten) Ik snap dat bij weinig vrije blokken er geshuffeld moet worden en dat je daardoor een hogere A_f krijgt. Maar minder dan 1??

Tweede vraag zijn de volgende twee smart attributen standaard bij alle merken SSD?
247 F7 Host program page count
248 F8 Background program page count

[Gonadan]

Zucht. Kernelupdates, reboots en weet ik niet wat gehad. En de pool is weer niet automatisch gemount. Blijft toch behelpen met dat Ubuntu.

[tvwes]

A1AD schreef op woensdag 20 mei 2015 @ 21:21:
[...]


Ik ben ZoL aan het testen op Proxmox (debian 7). Er is alreeds een zfs pool (rpool) voor root aanwezig door de installer. Nu wil ik van de 3 overige schijven een RaidZ1 pool maken (NAS). Maar na een reboot moet ik de NAS pool weer zelf importeren. Ik weet ook niet goed hoe ik dit moet opzoeken, "auto import zpool debian ..." geeft niet de gewenste resultaten.

Ik vraag mij ook af hoe zfs weet wat hij moet importeren at boot.

edit: al gedaan in /etc/default/zfs de ZFS_MOUNT op yes gezet. Maar heeft volgens mijn logica niets te maken met al dan niet importeren?

Even voor alle duidelijkheid:
-je hebt geen zfs set speciale optie ergens gedaan
-de enige tweak is wat je hierboven schreef
-na een reboot laat zpool status alleen de rpool zien? en zfs import (met niets erachter) geeft de optie om je andere zpool te importeren?

Ik vraag dit omdat het ook wel bij zol voorkomt dat de zpool wel is geimporteerd maar niet gemount.

[tvwes]

Gonadan schreef op woensdag 20 mei 2015 @ 21:26:
Zucht. Kernelupdates, reboots en weet ik niet wat gehad. En de pool is weer niet automatisch gemount. Blijft toch behelpen met dat Ubuntu.

Stoppen met Linux en een ander OS kiezen

[A1AD]

tvwes schreef op woensdag 20 mei 2015 @ 21:31:
[...]

Even voor alle duidelijkheid:
-je hebt geen zfs set speciale optie ergens gedaan
-de enige tweak is wat je hierboven schreef
-na een reboot laat zpool status alleen de rpool zien? en zfs import (met niets erachter) geeft de optie om je andere zpool te importeren?

Ik vraag dit omdat het ook wel bij zol voorkomt dat de zpool wel is geimporteerd maar niet gemount.

- nee
- ja, maar terug origineel staan
- ja

Ja klopt, het is echt importen dat niet automatisch gaat. Met een zpool import pool lukt het uiteraard wel (zonder -d of iets dergelijks).

[tvwes]

A1AD schreef op woensdag 20 mei 2015 @ 21:21:
[...]

Ik weet heel weinig van Linux distro's. Wel weet ik dat het mounten tijdens boot niet recht toe recht aan is. Je distro moet daar geschikte init scripts voor hebben. Zie faq
Niet dat dit je probleem direct oplost maar geeft wel een zoek richting van het probleem.

[tvwes]

Dan is mijn vorige post over de mount scripts misschien te voorbarig.
Het verwijderen van zpool.cache gevolgd door een zpool import loste ook niets op toch? Verscheen zpool.cache wel direct na de import en voor de reboot?
Heb je de cache file ook al eens expliciet gezet?
# zpool set cachefile=/etc/zfs/zpool.cache <pool>
Doe eerst even:
# zpool get cachefile

[Gonadan]

tvwes schreef op woensdag 20 mei 2015 @ 21:32:
Stoppen met Linux en een ander OS kiezen

FreeBSD?

Als ik nu opnieuw zou beginnen met mijn server zou ik het overwegen, maar om nu met een server vol draaiende software en geconfigureerde tools opnieuw te beginnen staat me toch wat tegen.