Het grote ZFS topic

[Bigs]

Thanks CiPHER, ik ga er eens mee testen zodra de machine vrij is. Zal nog wel even laten weten wat de uitslag is.

Ik zie in de mailinglist archieven echter dat dit wel een hardnekkig 'probleem' is.

[FireDrunk]

Er is een commando om de device ID's van je disks in de pool te regenereren, (zpool reguid)
die zou de problemen die CiPHER noemt moeten fixen.

Beste is inderdaad om even zpool import -d te doen.

[TMon]

Is er ook een manier om te checken of de disks ook echt spindown doen?
Momenteel is m'n kast open en probeer ik te voelen of ze ook echt down gaan. 1 pool lijkt te gaan, maar m'n andere pool wil niet? ook m'n energiemeter geeft aan dat er wel iets uit gaat, maar 15Watt op 10 WD green schijven lijkt me nog wat te weinig??

Is er een manier om te checken of er iets gaande is op de pool die niet down lijkt te gaan?

Onder disks-advanced gekeken in de ui van zfsguru en daar staat netjes dat de 3 disks aan de m1015 slapen, maar de 7 rechtstreeks aan t mobo willen niet down, tenzij ik t handmatig doe.

In rc.conf staat t volgende aan onder de kop spindown:
1e regel ="YES"
2e ="600"
3e ="ada0 ada1 ada3 ada4 ada5 ada6 ada7"

Ada2 is m'n ssd

In tzelfde bestand staat de m1015 van firedrunk en deze werkt prima.

[ Voor 33% gewijzigd door TMon op 06-08-2014 21:14 ]

[FireDrunk]

Je kan met SMART de huidige status uitlezen.

[Verwijderd]

Check man smartctl parameter -n:

      -n POWERMODE, --nocheck=POWERMODE
              [ATA only] Specifies if smartctl should exit  before  performing
              any  checks  when  the  device is in a low-power mode. It may be
              used to prevent a disk from being spun-up by smartctl. The power
              mode  is  ignored by default.  A nonzero exit status is returned
              if the device is in one of the specified  low-power  modes  (see
              RETURN VALUES below).

              Note: If this option is used it may also be necessary to specify
              the device type with the '-d' option.  Otherwise the device  may
              spin up due to commands issued during device type autodetection.

              The valid arguments to this option are:

              never - check the device always, but print  the  power  mode  if
              '-i' is specified.

              sleep - check the device unless it is in SLEEP mode.

              standby  -  check  the  device  unless it is in SLEEP or STANDBY
              mode.  In these modes most disks are not  spinning,  so  if  you
              want  to  prevent a disk from spinning up, this is probably what
              you want.

              idle - check the device unless it is in SLEEP, STANDBY  or  IDLE
              mode.  In the IDLE state, most disks are still spinning, so this
              is probably not what you want.

[Bigs]

FireDrunk schreef op woensdag 06 augustus 2014 @ 17:40:
Er is een commando om de device ID's van je disks in de pool te regenereren, (zpool reguid)
die zou de problemen die CiPHER noemt moeten fixen.

Beste is inderdaad om even zpool import -d te doen.

Volgens mij geeft reguid alleen de pool een nieuw ID en doet het niets met de onderliggende schijven. Een export gevolgd door import -d /dev/gpt was genoeg om de schijven netjes met hun GPT label aan te spreken.

Toch fijn dat ik in deze setup van een losse (UFS) SSD boot, ipv mijn ZFS pool. Dat maakt onderhoud net iets makkelijker.

[ Voor 10% gewijzigd door Bigs op 08-08-2014 14:04 ]

[FireDrunk]

Daar kan ik me zeker iets bij voorstellen. De grote reden waarom ik gewoon Ext4 op mijn Root SSD heb

[GioStyle]

Bigs schreef op vrijdag 08 augustus 2014 @ 14:03:


Volgens mij geeft reguid alleen de pool een nieuw ID en doet het niets met de onderliggende schijven. Een export gevolgd door import -d /dev/gpt was genoeg om de schijven netjes met hun GPT label aan te spreken.

Zou dit ook werken met FreeNAS? Stel dat ik dit zou doen:

code:

zpool export -f tank

Wat wordt dan de import command?

_{Ik ben als de dood dat ik iets verkeerds doe en *poef* /data weg}

[FireDrunk]

zpool import -d /dev/gpt ?

[GioStyle]

code:

[root@Hades ~]# zpool status                                                                                                        
  pool: Media                                                                                                                       
 state: ONLINE                                                                                                                      
  scan: scrub repaired 0 in 3h24m with 0 errors on Thu Aug  7 22:42:42 2014                                                         
config:                                                                                                                             
                                                                                                                                    
        NAME                                            STATE     READ WRITE CKSUM                                                  
        Media                                           ONLINE       0     0     0                                                  
          raidz2-0                                      ONLINE       0     0     0                                                  
            gptid/52f745f5-2c31-11e3-8044-d43d7eda344e  ONLINE       0     0     0                                                  
            gptid/53d5d547-2c31-11e3-8044-d43d7eda344e  ONLINE       0     0     0                                                  
            gptid/54b5bf56-2c31-11e3-8044-d43d7eda344e  ONLINE       0     0     0                                                  
            gptid/55a7cf5b-2c31-11e3-8044-d43d7eda344e  ONLINE       0     0     0                                                  
            gptid/548f441b-2c31-11e3-8044-d43d7eda344e  ONLINE       0     0     0                                                  
            gptid/5749v112-2c31-11e3-8044-d43d7eda344e  ONLINE       0     0     0                                                  
                                                                                                                                    
errors: No known data errors                                                                                                        
[root@Hades ~]# zpool export -f Media                                                                                               
[root@Hades ~]# zpool import -d /dev/gpt                                                                                            
cannot open '/dev/gpt': must be an absolute path                                                                                    
[root@Hades ~]#

Dat dacht ik ook..

[FireDrunk]

FreeBSD of Linux?

[GioStyle]

FreeNas 9.2.1.7, laatste versie.

[FireDrunk]

Heeft BSD niet een /dev/gpt pad?

[Verwijderd]

Begin eens met de wijzigingen in /boot/loader.conf die ik hierboven heb geplaatst. Dan hoor je geen gptid meer te zien. Verder check met gpart show adaX of je wel een GPT label naam hebt op de disk. Bij ZFSguru is dit verplicht; FreeNAS volgens mij niet. En dat vind ik een groot nadeel. Dan werk je met kunstmatige namen die weinig betekenen voor de gebruiker, en user error niet voldoende is afgedekt.

[GioStyle]

code:

# disable id labels
kern.geom.label.gptid.enable="0"
kern.geom.label.ufsid.enable="0"
# disable legacy device mappings (ada->ad)
kern.cam.ada.legacy_aliases="0"

Bovenstaande regels toegevoegd aan /boot/loader.conf en levert mij dit op:

code:

[root@Hades ~]# zpool status                                                    
  pool: Media                                                                   
 state: ONLINE                                                                  
  scan: scrub repaired 0 in 3h24m with 0 errors on Thu Aug  7 22:42:42 2014     
config:                                                                         
                                                                                
        NAME        STATE     READ WRITE CKSUM                                  
        Media       ONLINE       0     0     0                                  
          raidz2-0  ONLINE       0     0     0                                  
            ada4p2  ONLINE       0     0     0                                  
            ada3p2  ONLINE       0     0     0                                  
            ada2p2  ONLINE       0     0     0                                  
            ada1p2  ONLINE       0     0     0                                  
            ada0p2  ONLINE       0     0     0                                  
            ada5p2  ONLINE       0     0     0                                  
                                                                                
errors: No known data errors                                                    
[root@Hades ~]#

Bedankt iig!

Enig idee waarom alles door elkaar staat in plaats van ada0p2 / ada1p2 etc?

[FireDrunk]

Ze worden gesorteerd op intern ZFS id volgens mij.

[Bigs]

GioStyle schreef op vrijdag 08 augustus 2014 @ 16:00:
[...]


Zou dit ook werken met FreeNAS? Stel dat ik dit zou doen:

code:

zpool export -f tank

Wat wordt dan de import command?

_{Ik ben als de dood dat ik iets verkeerds doe en *poef* /data weg}

In principe kun je na een export altijd weer een import doen, dus dat is nooit een risico. Export laat je systeem als het ware je pool vergeten. Import gaat gewoon in alle schijven op zoek naar ZFS schijven/partities en kijkt welke pools hij daar ontdekt (dit werkt dus ook als je de schijven van je zpool in een ander systeem plaatst). Door dat met -d te beperken tot een bepaald pad kun je in FreeBSD afdwingen dat hij ze via de door jouw gewenste naam ontdekt.

Maar ik zie dat je het inmiddels al op een andere manier hebt opgelost. Mooi

[ikkeenjij36]

Hallo na een herstart krijg ik deze error melding te zien ook met opstarten via de live cd:

code:

ata status 51 (drdy serv err)

Waar moet ik dit in gaan zoeken?

[Kortfragje]

Het valt mij op dat scrubs onder ZoL 0.6.3 sneller lopen dan onder 0.6.2 (+/- 350 MB / s vs 240 MB / S voor een 6 disk RaidZ2). Op Ubuntu 12.04 LTS, Athlon X3 met 16 GB ECC-DDR3.


Heeft iemand anders een zelfde ervaring?

[ Voor 14% gewijzigd door Kortfragje op 10-08-2014 14:49 ]

[TMon]

Verwijderd schreef op woensdag 06 augustus 2014 @ 21:12:
Check man smartctl parameter -n:

[pre] -n POWERMODE, --nocheck=POWERMODE

Ik snap wat hier staat, maar welke functie gebruikt ZFSguru standaard? Ik ben nog niet zo bekend met Freebsd dat ik dit zelf op kan zoeken en nagaan, laat staan veranderen.

momenteel zijn m'n instellingen in rc.conf :
zfsguru_apm_enable="NO" de 2 daaropvolgende regels zijn standaard.
Dan bij spindown:
zfsguru_spindown_enable="YES"
zfsguru_spindown_timer="600"
zfsguru_spindown_disks="ada0 ada1 ada3 ada4 ada5 ada6 ada7"

Staat hier iets verkeerd of moet ik de zfs smart tool aanpassen zodat deze m'n schijven niet meer opstart als deze idle zijn?
in geval van 't laatste: waar/hoe kan ik die setting aanpassen?

Ik moet nog veel leren, dus bedankt voor jullie geduld.

[Verwijderd]

Heb je ook dit aanstaan:

## ZFSguru autostart
zfsguru_enable="YES"

Anders werken de rest van de ZFSguru tunables ook niet.

En je kunt het beste met de hand checken of je disks inderdaad slapen of niet. Als alternatief kun je een leesactie doen om dit te verifiëren:
dd if=/dev/ada3 of=/dev/null bs=1m count=10
(WAARSCHUWING: maak geen fouten met 'dd' commando's! Vooral de if= en of= mag je niet omwisselen; check je commando voordat je op enter drukt!)

Dit commando leest 10MiB van disk ada3. Als je disk slaapt, duurt dit 4 tot 7 seconden; het opspinnen van de disk. Als je disk niet slaapt, krijg je direct reactie van dit commando. Het smartctl commando hierboven is om te controleren of de disk slaapt zonder hem op te laten spinnen. Maar als je gewoon wilt weten of spindown überhaupt werkt, is een dd-commando de beste test.

Je kunt in het commando 'ada3' voor andere disks vervangen. Ook voor 'da' disks - dat werkt hetzelfde. Het is gewoon een leescommando op de ruwe disk, niets meer.

[Berkeley]

waarom wordt er in de openingspost eig wel heel uitgebreid gesproken over raidz maar niks over bijv: raid10 onder ZFS?

[Verwijderd]

Omdat er over RAID-Z familie veel meer te vertellen valt; zoals optimale configuraties enzo. Dat geldt allemaal niet voor RAID1/mirror.

Bovendien heeft ZFS geen 'RAID10' - nouja opzich wel maar dat zijn dan meerdere RAID1 vdevs. Alle vdevs worden geinterleaved; maar door load balancing en niet door statische interleaving (striping) zoals bij RAID10 gebeurt. Het voordeel is dat een vdev die sneller is, meer data te verwerken krijgt.

Bij traditioneel RAID en twee mirrors in RAID10, waarbij de ene 100MB/s doet en de ander 200MB/s, dan wordt het (min 100,200) x 2 = 200MB/s. Bij ZFS wordt het 100 + 200 = 300MB/s.

[Berkeley]

Zie, er valt dus toch wat over te vertellen?

[Verwijderd]

Wat ik vertel geldt evengoed voor meerdere RAID-Z vdevs in één pool. Bij traditioneel RAID zou je dan over RAID50 spreken. Bij ZFS gewoon meerdere RAID-Z vdevs.

Ik heb vandaag nog de startpost iets aangepast; kan opzich wel deze informatie nog toevoegen. Maar het is niet de bedoeling dat de startpost enorm uitgebreid wordt; het dient vooral als kennismaking met ZFS. Ik wil mensen namelijk niet afschrikken dat het enorm ingewikkeld is met enorme lappen tekst. Het moet ook lekker hapklaar naar binnen te werken zijn.

[Kortfragje]

Nog even terugkomende op scrubben, het lijkt ong 15% sneller te gaan onder 0.6.3 (verder niets veranderd).

0.6.2

code:

NAME      SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zfspool  10.9T  6.87T  4.03T    63%  1.00x  ONLINE  -

gertdus_write@gertdus-server:~/Desktop$ zpool status
  pool: zfspool
 state: ONLINE
  scan: scrub repaired 0 in 10h5m with 0 errors on Sat Jul 12 09:15:19 2014
config:

    NAME        STATE     READ WRITE CKSUM
    zfspool     ONLINE       0     0     0
      raidz2-0  ONLINE       0     0     0
        2tb1    ONLINE       0     0     0
        2tb2    ONLINE       0     0     0
        2tb3    ONLINE       0     0     0
        2tb4    ONLINE       0     0     0
        2tb5    ONLINE       0     0     0
        2tb6a   ONLINE       0     0     0

errors: No known data errors

en 0.6.3 , nu:

code:

NAME      SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zfspool  10.9T  7.65T  3.22T    70%  1.00x  ONLINE  -

gertdus_write@gertdus-server:~$ zpool status
  pool: zfspool
 state: ONLINE
  scan: scrub repaired 0 in 8h34m with 0 errors on Sun Aug 10 18:08:34 2014
config:

    NAME        STATE     READ WRITE CKSUM
    zfspool     ONLINE       0     0     0
      raidz2-0  ONLINE       0     0     0
        2tb1    ONLINE       0     0     0
        2tb2    ONLINE       0     0     0
        2tb3    ONLINE       0     0     0
        2tb4    ONLINE       0     0     0
        2tb5    ONLINE       0     0     0
        2tb6a   ONLINE       0     0     0

errors: No known data errors

[Berkeley]

* Berkeley heeft nu dat heerlijke gevoel dat je krijgt als je 350euro aan een nieuwe ZFS server hebt uitgegeven.

[Verwijderd]

[FireDrunk]

Verwijderd schreef op zondag 10 augustus 2014 @ 19:40:
Omdat er over RAID-Z familie veel meer te vertellen valt; zoals optimale configuraties enzo. Dat geldt allemaal niet voor RAID1/mirror.

Bovendien heeft ZFS geen 'RAID10' - nouja opzich wel maar dat zijn dan meerdere RAID1 vdevs. Alle vdevs worden geinterleaved; maar door load balancing en niet door statische interleaving (striping) zoals bij RAID10 gebeurt. Het voordeel is dat een vdev die sneller is, meer data te verwerken krijgt.

Bij traditioneel RAID en twee mirrors in RAID10, waarbij de ene 100MB/s doet en de ander 200MB/s, dan wordt het (min 100,200) x 2 = 200MB/s. Bij ZFS wordt het 100 + 200 = 300MB/s.

Volgens mij is het nog steeds zo dat de VDEV die het laatst vol raakt de meeste data te verwerken krijgt. ZFS stuurt er op dat alle VDEV's op hetzelfde moment vol raken (zou onhandig zijn als je 1 10TB VDEV hebt, en 1 50TB VDEV toevoegt, dat na 10TB je array er mee stopt...

Die change waar jij het over hebt, is volgens mij een voorstel (io capability based load balancing), maar volgens mij zit dat er momenteel nog niet in...

[Verwijderd]

In de meeste gevallen is de snellere vdev ook de vdev met meer capaciteit. In mijn situatie was dit in elk geval zo. Maar je hebt gelijk dat het ook enkel een gevolg kan zijn van dat de snellere vdev meer vrije ruimte heeft. Ook weer een idee om te testen? Zou kunnen met een pool met twee vdevs:
vdev1: één SSD van 100GB
vdev2: drie+ SSDs gepartitioneerd op 10GB

Als jouw verhaal klopt, dan zou vdev2 - die 3x sneller is - niet meer data verwerkt moeten krijgen. Als mijn aanname klopt, zou vdev2 wel degelijk sneller schrijven dan vdev1, ondanks dat het minder vrije ruimte heeft.

[Berkeley]

Ik heb geen geld meer dus ik ga het niet testen

[Verwijderd]

Ik heb hier nog wel vier gloednieuwe SSDs liggen voor nieuwe servers, maar geen zin om te testen.

Alles kost tijd, maar als iemand anders het wilt testen, ben ik uiteraard benieuwd naar de uitslag.

[Berkeley]

Verwijderd schreef op zondag 10 augustus 2014 @ 22:58:
Ik heb hier nog wel vier gloednieuwe SSDs liggen voor nieuwe servers, maar geen zin om te testen.

Alles kost tijd, maar als iemand anders het wilt testen, ben ik uiteraard benieuwd naar de uitslag.

Stuur die ssd's maar op, dan wil ik het wel testen.
of je de ssd's terug krijgt is een tweede.

[FireDrunk]

Als ik vandaag tijd over heb kan ik het wel in een vm testen.

[TMon]

Verwijderd schreef op zondag 10 augustus 2014 @ 18:09:
Heb je ook dit aanstaan:

## ZFSguru autostart
zfsguru_enable="YES"

Anders werken de rest van de ZFSguru tunables ook niet.

En je kunt het beste met de hand checken of je disks inderdaad slapen of niet. Als alternatief kun je een leesactie doen om dit te verifiëren:
dd if=/dev/ada3 of=/dev/null bs=1m count=10
(WAARSCHUWING: maak geen fouten met 'dd' commando's! Vooral de if= en of= mag je niet omwisselen; check je commando voordat je op enter drukt!)

Dit commando leest 10MiB van disk ada3. Als je disk slaapt, duurt dit 4 tot 7 seconden; het opspinnen van de disk. Als je disk niet slaapt, krijg je direct reactie van dit commando. Het smartctl commando hierboven is om te controleren of de disk slaapt zonder hem op te laten spinnen. Maar als je gewoon wilt weten of spindown überhaupt werkt, is een dd-commando de beste test.

Je kunt in het commando 'ada3' voor andere disks vervangen. Ook voor 'da' disks - dat werkt hetzelfde. Het is gewoon een leescommando op de ruwe disk, niets meer.

Even getest: ada3:0.8sec, da0:6.96sec. Duidelijk dat de 3 die aan de M1015 hangen wel downspinnen en de 7 ada aan het mobo niet.

ZFSGuru autostart
zfsguru_enable="YES"
Staat ook gewoon goed.

Ik neem aan dat APM gewoon uit mag staan en dat spindown dan nog werkt?
Ik heb headparking ook compleet uitgezet met de wdidle.

Ik bensteeds clueless. Kan ik jullie van nog meer info voorzien? Bedankt voor jullie tijd in ieder geval. Ben erg content met ZFSGuru en de setup. Wil alleen 't idle vermogen nog omlaag krijgen voordat ie in de meterkast verdwijnt.

[Keiichi]

Zit het in FreeBSD(10) ergens gebouwd dat rpc.rquotad user en groupquotas van ZFS terug kunnen geven?

Bij het overschrijden van de quota krijg je in de terminal wel keurige te horen dat de quota overschreden is.

[ Voor 35% gewijzigd door Keiichi op 12-08-2014 23:31 ]

[FREAKJAM]

Ik draait een ESXi 5.5 host en ben inmiddels vanaf scratch bezig met het installeren van Ubuntu 14.04.1 met ZFS on Linux. Ik ga 6x3TB gebruiken in een RAIDZ2 setup.

Ik gebruik een enkele SSD (M500 240GB) als datastore (ik boot ESXi vanaf USB). Hoe kan ik /dev/sda (dus de virtuele disk in VMWare) het beste indelen qua grootte en swapsize? Ik dacht zelf aan 36 GB (18GB voor root en 18GB voor swap). Ik ga de desbetreffende VM enkel gebruiken voor ZoL, dus er zal niet veel ruimte nodig zijn.

Ik ben van plan 18GB RAM te gaan gebruiken. (de regel is 1GB RAM per 1TB en ZFS reserveert automatisch 1GB RAM voor het OS).

[ Voor 102% gewijzigd door FREAKJAM op 13-08-2014 00:36 ]

[WeaselADHD]

Ik krijg foutmeldingen bij het installeren van bepaalde services bij ZFSguru zoals Owncloud & PureFTPd. Enig idee wat ik hier aan kan doen?

code:

Aug 14 14:48:47 zfsguru root: /usr/local/etc/rc.d/openvpn: WARNING: /usr/local/etc/openvpn/openvpn.conf is not readable.
Aug 14 14:48:47 zfsguru root: /usr/local/etc/rc.d/openvpn: WARNING: failed precmd routine for openvpn
Aug 14 14:49:00 zfsguru root: /usr/local/etc/rc.d/openvpn: WARNING: /usr/local/etc/openvpn/openvpn.conf is not readable.
Aug 14 14:49:00 zfsguru root: /usr/local/etc/rc.d/openvpn: WARNING: failed precmd routine for openvpn
Aug 14 14:51:39 zfsguru root: /usr/local/etc/rc.d/openvpn: WARNING: /usr/local/etc/openvpn/openvpn.conf is not readable.
Aug 14 14:51:39 zfsguru root: /usr/local/etc/rc.d/openvpn: WARNING: failed precmd routine for openvpn
Aug 14 14:51:53 zfsguru root: /usr/local/etc/rc.d/openvpn: WARNING: /usr/local/etc/openvpn/openvpn.conf is not readable.
Aug 14 14:51:53 zfsguru root: /usr/local/etc/rc.d/openvpn: WARNING: failed precmd routine for openvpn
Aug 14 14:57:51 zfsguru kernel: pid 27361 (Plex DLNA Server), uid 972: exited on signal 11
Aug 14 14:57:59 zfsguru kernel: pid 47801 (Plex DLNA Server), uid 972: exited on signal 11
Aug 14 16:26:26 zfsguru su: ssh to root on /dev/pts/0
Aug 14 16:33:07 zfsguru root: /usr/local/etc/rc.d/pure-ftpd: WARNING: /usr/local/etc/pure-ftpd.conf is not readable.
Aug 14 16:33:07 zfsguru root: /usr/local/etc/rc.d/pure-ftpd: WARNING: failed precmd routine for pureftpd
Aug 14 16:33:21 zfsguru root: /usr/local/etc/rc.d/pure-ftpd: WARNING: /usr/local/etc/pure-ftpd.conf is not readable.
Aug 14 16:33:21 zfsguru root: /usr/local/etc/rc.d/pure-ftpd: WARNING: failed precmd routine for pureftpd

[Verwijderd]

PureFTPd is een stub; het installeert packages maar heeft geen werkende default configuratie file. Die moet je zelf maken. Dat staat ook in de omschrijving van de service; op de pagina waar je PureFTPd installeert.

Voordat je de service kunt gebruiken, dien je zelf de configuratie /usr/local/etc/pure-ftpd.conf aan te maken; vaak is er een sample file zoals /usr/local/etc/pure-ftpd.conf.sample en kun je die kopiëren naar pure-ftpd.conf (zonder .sample). Dit alles dien je te doen na het inloggen met SSH op de server, wat je op de Access->SSH pagina kunt doen.

Je praat verder over Owncloud; die service is wel afgebouwd; maar je bedoelde denk ik OpenVPN. Ook daarvoor geldt hetzelfde. Je kunt op de paginaomschrijving zien dat deze service WIP (Work In Progress) is. Dat betekent dus dat je er zelf nog werk aan hebt voordat de service werkt. Uiteindelijk is de bedoeling dat voor veel/alle services een eigen web-interface wordt gebouwd. Maar dat kan nog wel even duren. Tot die tijd dien je het handmatig te configureren. Het installeren van packages wordt al wel voor je gedaan; dus dat is al het halve werk. Handmatig compileren hoeft dus niet.

[Bigs]

FREAKJAM schreef op woensdag 13 augustus 2014 @ 00:15:
Ik draait een ESXi 5.5 host en ben inmiddels vanaf scratch bezig met het installeren van Ubuntu 14.04.1 met ZFS on Linux. Ik ga 6x3TB gebruiken in een RAIDZ2 setup.

Ik gebruik een enkele SSD (M500 240GB) als datastore (ik boot ESXi vanaf USB). Hoe kan ik /dev/sda (dus de virtuele disk in VMWare) het beste indelen qua grootte en swapsize? Ik dacht zelf aan 36 GB (18GB voor root en 18GB voor swap). Ik ga de desbetreffende VM enkel gebruiken voor ZoL, dus er zal niet veel ruimte nodig zijn.

Ik ben van plan 18GB RAM te gaan gebruiken. (de regel is 1GB RAM per 1TB en ZFS reserveert automatisch 1GB RAM voor het OS).

[afbeelding]

Een root van 18GB is zat.. met de helft kun je het waarschijnlijk ook wel af. Ik weet niet hoe het met ZFS on Linux zit, maar de regel van 1GB ram per TB data is voor FreeBSD achterhaald. De ARC past zich automatisch aan aan de beschikbare hoeveelheid geheugen. De totale omvang van je pool is daardoor niet van belang, in plaats daarvan kun je beter naar de grootte van je working set kijken (ivm read cache). Ik zou beginnen met 8GB RAM en 4GB swap en dan kijken hoe het loopt als je het gaat gebruiken. Je VM is immers eenvoudig uit te breiden.

Ik daai nu een pool van 30TB (waarvan 10TB in gebruik) met 8GB RAM en dat werkt prima. Die server draait ook nog eens elke dag een berg rsync taken, dan zakt de ARC in naar 4GB. Het plan is overigens wel om daar nog 8GB bij te prikken, maar de levering was wat vertraagd

[Verwijderd]

de regel van 1GB ram per TB data is voor FreeBSD achterhaald

Die regel is nooit geldig geweest. ZFS schaalt performance met RAM-geheugen. Dat betekent dat je 1GB per 100MB/s nodig zou hebben; of iets in die geest. Je hebt niet meer RAM nodig aan de hand van de capaciteit van het opslagvolume. Dat grotere hardeschijven ook automatisch sneller zijn, is een neveneffect. De regel is op niets gebaseerd.

Je zou wel kunnen stellen dat je RAM geheugen zou kunnen schalen met je dataset. Als je een 40GB database hebt, is het fijn als je het actieve deel (zeg 50%) in RAM kunt cachen. Dus dan zou je genoeg RAM voor het systeem (zeg 2GB) + die 50% van de 40GB moeten hebben; dus 22GB. Maar dat heeft an sich niets met ZFS te maken; en geldt ook voor andere filesystems zoals Ext4.

ZFS heeft baat bij meer geheugen, doordat het meer ARC kan cachen en de transaction groups groter kunnen worden. Beide hebben geen directe relatie met de capacitiet van een opslagvolume. Een heel snel volume van 20TB heeft meer RAM-geheugen nodig voor goede performance-scaling dan een traag 100TB-volume. Dus deze 'vuistregel' stelt mijns inziens niets voor.

Bij BSD heb je vanaf 6GiB out-of-the-box redelijke ZFS performance doordat pre-fetching is ingeschakeld en je een klein beetje ARC hebt. Daarboven is het luxe voor meer caching. Met name metadata cachen ben ik erg op gesteld; je kunt dan snel zoeken en snel door directories bladeren.

[Berkeley]

Wat zouden jullie doen met 4x1Tb? Raidz1 of 2? Of voor de raid10 variant van zfs? Er komen o.a backups op en algemene storage van films, series e.d

[Verwijderd]

RAID-Z2 is voor die disk size superieur qua bescherming; maar twee mirror vdevs is beter qua random I/O performance (2x beter dan een enkele RAID-Z1/2/3 vdev). Dus kies je prioriteit.

[Berkeley]

mja, aangezien het allemaal over Gbit gaat, is snelheid niet zo'n prio, dus wordt het Z2 denk ik. Tot de nieuwe hardware er is, kan ik in elk geval genoeg tesen.

[WeaselADHD]

Verwijderd schreef op donderdag 14 augustus 2014 @ 17:00:
PureFTPd is een stub; het installeert packages maar heeft geen werkende default configuratie file. Die moet je zelf maken. Dat staat ook in de omschrijving van de service; op de pagina waar je PureFTPd installeert.

Voordat je de service kunt gebruiken, dien je zelf de configuratie /usr/local/etc/pure-ftpd.conf aan te maken; vaak is er een sample file zoals /usr/local/etc/pure-ftpd.conf.sample en kun je die kopiëren naar pure-ftpd.conf (zonder .sample). Dit alles dien je te doen na het inloggen met SSH op de server, wat je op de Access->SSH pagina kunt doen.

Je praat verder over Owncloud; die service is wel afgebouwd; maar je bedoelde denk ik OpenVPN. Ook daarvoor geldt hetzelfde. Je kunt op de paginaomschrijving zien dat deze service WIP (Work In Progress) is. Dat betekent dus dat je er zelf nog werk aan hebt voordat de service werkt. Uiteindelijk is de bedoeling dat voor veel/alle services een eigen web-interface wordt gebouwd. Maar dat kan nog wel even duren. Tot die tijd dien je het handmatig te configureren. Het installeren van packages wordt al wel voor je gedaan; dus dat is al het halve werk. Handmatig compileren hoeft dus niet.

bedankt! ik ga erachteraan. Ik bedoelde inderdaad OpenVPN. Het probleem bij owncloud was dat dat ik telkens de volgende melding kreeg: installation script failed for service owncloud.

code:

2014-08-15 08:47:55: (mod_fastcgi.c.2695) FastCGI-stderr: PHP Notice:  Undefined variable: class_notrunning in /zfsguru_boot/zfsguru/services/10.1-001/owncloud/panel/owncloud.php on line 18
2014-08-15 08:56:49: (mod_fastcgi.c.2695) FastCGI-stderr: PHP Notice:  Undefined variable: output in /usr/local/www/zfsguru/pages/services/install.php on line 135
2014-08-15 08:56:49: (mod_fastcgi.c.2695) FastCGI-stderr: PHP Warning:  Invalid argument supplied for foreach() in /usr/local/www/zfsguru/pages/services/install.php on line 298
2014-08-15 09:00:11: (mod_fastcgi.c.2695) FastCGI-stderr: PHP Notice:  Undefined variable: output in /usr/local/www/zfsguru/pages/services/install.php on line 135
2014-08-15 09:00:11: (mod_fastcgi.c.2695) FastCGI-stderr: PHP Warning:  Invalid argument supplied for foreach() in /usr/local/www/zfsguru/pages/services/install.php on line 298

[CurlyMo]

En weer een periodieke tutorial van CurlyMo Een van mijn vorige tutorials ging over het migreren van data via zfs send/receive. De vraag betrof toen een migratie binnen dezelfde pool. Daarvoor blijkt nog een veel snellere oplossing voor handen te zijn. De promoted clone:

Stel we hebben de volgende situatie:

code:

data
|--user1
|----foto
|--user2
|----foto

Deze gebruiker heeft 1 foto genaamd aap.jpg

code:

[root@server /]# dd if=/dev/random of=/data/user1/foto/aap.jpg bs=1024 count=1024
[root@server /]# md5 /data/user1/foto/aap.jpg
MD5 (/data/user1/foto/aap.jpg) = af07235e4e0f4e24adb77b354594286c

Deze indeling is leuk zolang er maar één gebruiker is en je verder niks anders in je data pool hebt staan. Maar stel je krijgt meerdere gebruikers. Dan is deze opstellingen veel handiger:

code:

data
|--users
|----user1
|------foto
|----user2
|------foto

Het migreren van deze mappen kan echter niet zomaar tussen ZFS bestandssystemen (op dezelfde pool). Normaal gesproken zou je dit dus moeten doen via ofwel zfs send/receive ofwel via bijv. rsync. Afhankelijk van het aantal bestanden kan dit vele uren duren.

Er is echter wel een snelle manier (evensnel als het maken van snapshots), maar die werkt alleen binnen dezelfde pool. Hierbij maken we gebruik van clones. Voor het gemak roep ik bewust foutmeldingen op om te laten zien wat het doel van verschillende stappen zijn.

code:

[root@server /]# zfs snapshot -r data/user1@clone
[root@server /]# zfs list -t snapshot -r data/user1
NAME                    USED  AVAIL  REFER  MOUNTPOINT
[...]
data/user1@clone           0      -   221K  -
data/user1/foto@clone      0      -  1.21M  -
[root@server /]# zfs create data/users
[root@server /]# zfs clone data/user1@clone data/users/user1
[root@server /]# zfs clone data/user1/foto@clone data/users/user1/foto
[root@server /]# zfs list -r data
NAME                                    USED  AVAIL  REFER  MOUNTPOINT
[...]
data/user1                             1.43M  2.61T   221K  /data/user1
data/user1/foto                        1.21M  2.61T  1.21M  /data/user1/foto
data/users/user1                       23.2K  2.61T   221K  /data/users/user1
data/users/user1/foto                  11.6K  2.61T  1.21M  /data/users/user1/foto
[root@server /]# md5 /data/users/user1/foto/aap.jpg
MD5 (/data/users/user1/foto/aap.jpg) = af07235e4e0f4e24adb77b354594286c
[root@server /]# zfs destroy data/user1/foto@clone
cannot destroy 'data/user1/foto@clone': snapshot has dependent clones
use '-R' to destroy the following datasets:
data/users/user1/foto
[root@server /]# zfs promote data/users/user1/foto
[root@server /]# zfs destroy data/user1/foto@clone
could not find any snapshots to destroy; check snapshot names.
[root@server /]# zfs destroy data/user1/foto
[root@server /]# zfs destroy data/user1@clone
cannot destroy 'data/user1@clone': snapshot has dependent clones
use '-R' to destroy the following datasets:
data/users/user1/foto@clone
data/users/user1/foto
data/users/user1
[root@server /]# zfs promote data/users/user1
[root@server /]# zfs destroy data/user1
[root@server /]# zfs list -r data
NAME                                    USED  AVAIL  REFER  MOUNTPOINT
data/users/user1                       1.45M  2.61T   221K  /data/users/user1
data/users/user1/foto                  1.23M  2.61T  1.21M  /data/users/user1/foto
[root@server /]# md5 /data/users/user1/foto/aap.jpg
MD5 (/data/users/user1/foto/aap.jpg) = af07235e4e0f4e24adb77b354594286c

In dit voorbeeld is er maar één snapshot. Zouden we echter een grote geschiedenis aan snapshots hebben, dan worden die netjes allemaal mee gecloned t/m de geclonede snapshot. Het betreft dus een volledige migratie van het bestandssysteem.

Denk er overigens aan dat het verwijderen van je originele filesystem alleen mogelijk is wanneer de betreffende filesystem een child is van de pool. Stel je hebt een pool genaamd tank, dan kun je achteraf dus wel netjes tank/foo verwijderen, maar natuurlijk niet tank zelf. Dan zou je namelijk je pool verwijderen. In dat laatste geval moet je zeer voorzichtig aan de slag met een goede oude rm -rf. Het beste kan je voor die tijd van de eerste childs van tank even het mountpoint veranderen zodat je niet je vers geclonede data weer verwijderd via je rm -rf.

@CiPHER, is het een idee om in de openingspost linkjes te zetten naar nuttige tutorials. Ik weet dat er meerdere gebruikers zijn die van zulke posts plaatsen. Dat maakt het handiger om ze te vinden als zijnde FAQ.

[ Voor 7% gewijzigd door CurlyMo op 15-08-2014 16:47 ]

[FireDrunk]

Zet zelf maar in de TS

[Berkeley]

CurlyMo schreef op vrijdag 15 augustus 2014 @ 16:21:
[...]

Nice! Thanks!

[CurlyMo]

FireDrunk schreef op vrijdag 15 augustus 2014 @ 16:25:
Zet zelf maar in de TS

Gedaan Graag suggesties voor andere handige posts.

[Berkeley]

* Berkeley vindt http://www.bsdnow.tv/tutorials/zfs erg handig.

[Mystic Spirit]

Ik ben weer eens aan een experimentje begonnen, waar ik misschien beter niet aan had kunnen beginnen, want ik kom er niet echt uit. Ik hoop dat jullie mij kunnen helpen.

De situatie:
Ik ben een nieuwe server aan het bouwen met ESXi en er moet natuurlijk weer een VM komen met ZFS storage. Daarvoor heb ik alle hardware in huis gehaald, maar het belangrijkste is de HDD / SSD configuratie die ik heb uitgezocht.

Een plextor PCI-E SSD (bedoeld voor datastore)
6 HDD's (op onboard poorten om via VT-D door te geven aan de ZFS VM)
Alle hardware is uiteraard VT-D capable

Nu lukt het mij echter niet om de Plextor PCI-E SSD als storage aan te krijgen in ESXi als VT-D aan staat. Als VT-D uit staat lukt het wel, maar dan kan ik uiteraard de HDD's niet doorgeven aan de ZFS VM die ik wil maken.

Wat ik geprobeerd heb:
ESXi 5.5 standaard --> Plextor PCI-E SSD werkt per definitie niet
ESXi 5.5 met custom AHCI drivers --> Geen Plextor PCI-E SSD met VT-D aan / Wel met VT-D uit
ESXi 5.1 met custom AHCI drivers --> Geen Plextor PCI-E SSD met VT-D aan / Wel met VT-D uit
Op zowel ESXi 5.5 als 5.1 geprobeerd de datastore aan te maken met VT-D uit om vervolgens VT-D aan te zetten en te hopen dat de storage beschikbaar bleef. Helaas was dat niet het geval.

Ik ben dus een beetje door mijn opties heen aan het raken en vraag me af wat de andere mogelijkheden zijn.

Opties die ik nog heb:
1) ESXi 5.0 proberen met en zonder custom AHCI drivers
2) Zonder VT-D werken met ESXi 5.5 en hopen dat het goed gaat werken met ZFS.

Optie 1, heb ik weinig vertrouwen in. De kans van slagen lijkt mij nihil.
Optie 2, heb ik geen ervaring mee maar zou kunnen werken.

Iemand die uit ervaring kan melden of een van beide opties de juiste weg is, of wellicht een andere optie heeft voor me om te proberen?

Misschien past het beter in het ESXi topic.. als dat zo is verhuis ik
De optie PCI-E SSD retour en een gewone SSD en een IBM HBA kopen kan ook, maar is niet gewenst
TLDR; Lees toch maar Help

[Bigs]

Wat voor SSD is het? Een M6e?

[FireDrunk]

Hmm, raar dat als je VT-d gebruikt, de PCIe SSD niet meer werkt... Klinkt een beetje als CompizFox' verhaal... Wat voor foutmeldingen krijg je dan? ESXi ziet gewoon de datastore niet meer?
Is hij dan toevallig ook doorgeven aan de VM?

[Bigs]

@Mystic Spirit: Er schijnt een probleem te zijn met bepaalde Marvell controllers, in ieder geval met type 88SE91xx icm vt-d: discussie op v-front.de. De Plextor M6e heeft zo'n controller, maar ik weet niet wat voor type jij hebt. Waarschijnlijk tijd om hem om te ruilen voor iets anders dus

[Mystic Spirit]

Het is inderdaad een M6e, maar het vreemde is dat hij prima werkt met VT-D uit.

Er is geen sprake van foutmeldingen. Als VT-D aan staat zie je de controler wel, maar doet hij net alsof er geen SSD aan zit. Dus dat is vervelend.

Zien jullie geen weg in het werken zonder VT-D?

[FireDrunk]

Mja, met de nieuwe AHCI controller (VM Hardware Level 10) werkt RDM wel op zich, maar ik ben er nog niet 100% over uit of dit goed is... Ik heb het uitgebreid getest, en geen bezwaren gevonden...

Maar mijn onderbuik zegt toch nog, liever niet...

[Mystic Spirit]

Misschien moest ik me daar dan toch maar eens aan gaan wagen... Een andere vriendelijk geprijsde PCI-E SSD waarbij er zekerheid is dat hij werkt zie ik ook zo 1,2,3 niet.

Nog speciale zaken waar ik reken mee moet houden als ik voor de RDM oplossing ga?

[Berkeley]

Waarom een PCI-E SSD? Waarom niet gewoon SATA?

[FireDrunk]

Omdat hij zijn onboard controller door wil geven aan een VM

[Mystic Spirit]

Het idee achter de server was om geen HBA en een losse SSD nodig te hebben. Door het geld wat normaal gesproken in een HBA en kabels gaat ztten (toch al snel 200 euro voor 8 poorts) heb je ook een PCI-E SSD. De uitsparing van een losse SSD is dus volledige winst.
Ik zou de onboard sata poorten beschikbaar hebben voor mijn ZFS config met 6 schijven (raid Z2) en nog ruim poorten over hebben voor uitbreiding.

Kortom vooral financieel gedreven, maar ook gericht op flexibiliteit.

[FireDrunk]

Je kan ook gewoon een 2 poorts controllertje kopen welke werkt onder ESXi...
Of in het tweedehands circuit een cheap controllertje vinden.

[Mystic Spirit]

Had gekund inderdaad... maar wilde ook het aantal onderdelen beperken. Ieder onderdeel extra (zeker een el cheap controlertje) is ook weer een onderdeel dat stuk kan.

Ondertussen toch voor de zekerheid maar ESXi 5.0 geprobeerd, maar geeft hetzelfde resultaat als de andere versies.

Zou het nog andere resultaten geven met KVM / Proxmox ipv ESXi?

[Bigs]

Als het probleem zit in de combinatie van Marvell controller met VT-d niet, zoals je in die link van eerder kunt lezen. Het probleem is ook gerapporteerd in de Linux kernel: bugzilla.

[FireDrunk]

Gewoon poep controller dus.. Jammer. Mocht je er vanaf willen, stuur maar een DM

[justice strike]

Ik wilde van de week zfs-guru gaan updaten. Nu kom ik erachter dat ik net op een te oude versie zit om te updaten. (dwz 0.2.0-beta7 ipv 0.2.0-beta9). Nu wordt er aangeraden om hem van een nieuwe image te installeren en de bootcode te updaten... Maar ik had deze zfs installatie bovenop een schone freebsd 9.1 gebouwd. Updaten met een livecd (9.2 of 10) is dan niet echt makkelijk.

Is er een mogelijkheid om hem manueel te installeren? Ik weet dat je voorheen in de root een zfs dist file kon neerzetten oid?

Ook ben ik benieuwd wat voor impact het heeft om de mbr bootcode te updaten met zfsguru (beta 9 dan). Hij is dan namelijk niet meer gelijk aan de bootcode van het systeem

[FireDrunk]

Voor zover ik weet kan het niet zomaar. ZFSguru gebruikt een hoop lokale scripts en heeft aanpassingen in een aantal files in /etc.

Maar voor garanties moet je bij CiPHER wezen

[justice strike]

dat het niet zomaar kan is mij wel duidelijk geworden van de error melding. Maar voorheen was het altijd wel mogelijk om het een en ander handmatig te doen.

[FireDrunk]

Is er een specifieke reden dat je handmatig ZFSguru installeert? Niet om je te veroordelen hoor, ben gewoon benieuwd naar je beweegredenen.

[CurlyMo]

Ik begrijp hem wel

[Verwijderd]

justice strike schreef op maandag 18 augustus 2014 @ 09:00:
Ik wilde van de week zfs-guru gaan updaten. Nu kom ik erachter dat ik net op een te oude versie zit om te updaten. (dwz 0.2.0-beta7 ipv 0.2.0-beta9).

Dat is de web-interface. Die kun je met een muisklik updaten naar beta10 op de System->Update pagina. Maar ik neem aan dat je het systeem + packages wilt updaten, ipv alleen de web-interface? Wat wil je precies?

Nu wordt er aangeraden om hem van een nieuwe image te installeren en de bootcode te updaten... Maar ik had deze zfs installatie bovenop een schone freebsd 9.1 gebouwd. Updaten met een livecd (9.2 of 10) is dan niet echt makkelijk.

Ah je hebt een handmatige installatie. Wat wil je dan, wil je nu weer een officiële ZFSguru systeemversie, of wil je enkel FreeBSD updaten? Dat laatste kan gewoon op dezelfde manier hoe je FreeBSD update, daar is niets specifieks aan voor ZFSguru. Dus zelf compileren of binary update (freebsd-update) gebruiken.

Als je een officiële ZFSguru systeemversie wilt, kun je gewoon een herinstallatie uitvoeren terwijl je systeem draait. Dus je hebt als het goed is geen LiveCD nodig. Gewoon eerst de web-interface updaten en daarna bij System->Install een nieuwere versie downloaden (10.1-001) en die installeren. Daarna rebooten en je boot in de nieuwe versie ipv de oude. Tadaa!

Ook ben ik benieuwd wat voor impact het heeft om de mbr bootcode te updaten met zfsguru (beta 9 dan). Hij is dan namelijk niet meer gelijk aan de bootcode van het systeem

Je kunt het beste altijd de nieuwste bootcode hebben; dat je systeem een oudere versie heeft, doet er niet toe. Je BIOS moet ermee gaan werken; niet BSD zelf. Je kunt dus ongeacht welke systeemversie je draait, altijd de nieuwste bootcode versie draaien. Daarom geeft ZFSguru ook de mogelijkheid om de web-interface te updaten en daarmee de nieuwste bootcode te installeren, omdat de bootcode ook met de web-interface wordt meegegeven. Je kunt kiezen tussen updaten naar de bootcode van het systeem of updaten naar de bootcode die de web-interface aanlevert (ZFSguru shipped bootcode). Dat laatste is wat je normaliter wilt.

FireDrunk schreef op maandag 18 augustus 2014 @ 09:11:
Voor zover ik weet kan het niet zomaar. ZFSguru gebruikt een hoop lokale scripts en heeft aanpassingen in een aantal files in /etc.

Maar voor garanties moet je bij CiPHER wezen

Root-on-ZFS is een normale BSD installatie, dus alles wat je met BSD kunt, kun je ook met een dergelijke installatie. Alleen kun je niet zomaar de ZFSguru services gebruiken omdat die voor een bepaalde systeemversie zijn gecompileerd. Maar als je toch de onofficiële handmatige route volgt, zal dat ook geen probleem zijn lijkt me. Dan gebruik je enkel de web-interface en doe je het systeem updaten en packages enzo allemaal handmatig; buiten ZFSguru om. Dat kan prima. Uiteraard heeft ZFSguru web-interface wat dingen nodig om te werken, zoals sudo om root access te krijgen, en PHP met php5-session en php5-gd (voor de advanced benchmark). Maar je kunt opzich prima handmatig installeren. Kost wel veel werk.

De scripts waar jij het over hebt, is enkel de run control script voor de LiveCD. Daarbij wordt een tijdelijke root device gemaakt (init ramdisk zoals Linux dat kent) waarbij de systeemversie naar tmpfs (RAMdisk) wordt uitgepakt. Dat is dus scripted. Maar een ZFSguru installatie is gewoon een BSD installatie met wat config files.

[Micr0mega]

Voor mensen die (wat) data willen recoveren van een ZFS disk met I/O errors, volgen hier wat ervaringstips

Maar eerst een korte situatieschets: voor mijn thuisserver heb ik de root pool op mirrored usb sticks staan en deze begonnen stuk te gaan (mijn data staat op een 5-disk raidz1 met ssd cache). Ik draaide OpenIndiana en besloot dat het nu toch wel tijd was om op Linux over te gaan. Dus zo gezegd zo gedaan; toen de server niet meer wilde reageren heb ik de boel plat gegooid en Debian Jessie op andere usb sticks gezet (ook een mirrored root pool).

Nu had ik geen echt belangrijke data op de OI pool staan, maar het zou wel handig zijn om wat configuratie en/of database bestanden terug te kunnen halen. Dus na een "zpool import":

code:

  pool: potion_old
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: resilvered 116M in 0h51m with 109 errors on Tue Aug 19 13:51:21 2014
config:

        NAME                                                STATE     READ WRITE CKSUM
        potion_old                                          DEGRADED   109     0     0
          mirror-0                                          DEGRADED   222     0     0
            usb-JetFlash_Transcend_16GB_69V4Y48A-0:0-part5  ONLINE       0     0   222
            10483926689522572295                            UNAVAIL      0     0     0  was /dev/dsk/c6t0d0s0

errors: 109 data errors, use '-v' for a list

(Overigens snap ik niet helemaal waarom hij ging resilveren na de import, er is maar één disk beschikbaar en de "copies" property staat gewoon op 1)

Zoals ik al zei, stickje is dus eigenlijk stuk. Er zijn dus een aantal bestanden corrupt, maar ZFS geeft je hiervan een mooi lijstje met "zpool status -v potion_old". Maar ik wil gewoon recoveren wat er te recoveren valt naar m'n raidz1 pool (menhir). Dus:

code:

# zfs snapshot potion_old@backupsnap
# zfs send -v -R potion_old@backupsnap | zfs receive -v -u menhir/potion_old
send from @ to potion_old@fresh estimated size is 29.5K
[...]
total estimated size is 18.2G
TIME        SENT   SNAPSHOT
receiving full stream of potion_old@fresh into menhir/potion_old@fresh
received 60.9KB stream in 1 seconds (60.9KB/sec)
[...]

Heel mooi, maar na een minuut of wat stopt hij met verzenden Ik een volgende melding in m'n syslog:

code:

SPLError: 1984:0:(spl-err.c:67:vcmn_err()) WARNING: Pool has encountered an uncorrectable I/O failure and has been suspended.

En deze status op de pool. En de laatste regel van de 'action' klopt, het "zfs send" commando doet helemaal niks meer. Ik kan het process niet killen en zelfs op het reboot commando reageert de server pas na een half uur. Het schijnt een bekend probleem te zijn.

De oplossing? Redelijk simpel, maar kom het niet makkelijk vinden (er stond wel een hint in de ZFS-8000-HC melding):

code:

# zpool set failmode=continue potion_old

Daarnaast schijnt normaal gesproken "zfs send" te stoppen bij read errors, dus heb ik gebruik gemaakt van genoemde tunable:
(niet getest zonder)

code:

# echo "1" > /sys/module/zfs/parameters/zfs_send_corrupt_data

Hierna opnieuw "zfs send | zfs receive" uitgevoerd.

En alles werd netjes verzonden en ontvangen op m'n raidz1 pool, yay gelukt

Bonustip1: om Solaris zone datasets te kunnen mounten:
("dataset is used in a non-global zone")

code:

# zfs set zoned=off menhir/potion_old/zones/<zone>/ROOT

Bonustip2: mountpoints "resetten":

code:

# zfs inherit -r mountpoint menhir/potion_old

Dan krijg je netjes mountpoints onder /menhir/potion_old/<dataset> ipv bijvoorbeeld /

Hopelijk heeft iemand in de toekomst iets aan deze post als referentie

[azerty]

Ik zit met een kleine vraag mbt tot de vdev's:

De bedoeling was om een 10-disk vdev aan te maken met RAID-Z2. Echter is er 1 schijf DOA, en zit ik op dit moment met 9 stuks. Omdat ik hoogstwaarschijnlijk niet zal kunnen wachten met het maken (en vervolgens vullen) van de pool, vraag ik mij af wat het beste is qua bescherming met dit scenario (ter info, de te migreren bestanden zijn +- 8TB in totaal):

- Een pool aanmaken met 9 disks in RAID-Z1 en de laatste schijf als (hot-)spare gebruiken.
- Een pool aanmaken met 5 disks in RAID-Z1 en als de laatste schijf binnenkomt wederom een vdev toevoegen met 5 schijven in RAID-Z1
- Toch wachten en onmiddellijk een 10-disk RAID-Z2 aanmaken (zou alleen lukken mits de webshop tijdig een nieuwe kan sturen).

ZFSGuru is reeds geïnstalleerd op 2 SSD's in RAID 1 (zoals in de startpost beschreven )

[zzattack]

Het is niet optimaal, maar je kunt een bestand aanmaken op je oude pool ter grootte van 1 disk. Vervolgens die file als 10e disk gebruiken om je RAIDZ-2 te maken, data migreren, file vervangen voor fysieke schijf en laten resilveren.

[Verwijderd]

Een 10 disk RAID-Z2 aanmaken met 9 schijven, door één memory disk te gebruiken en direct na het aanmaken van de pool te rebooten. Dan draai je single degraded. Qua snelheid lever je niet veel in; qua veiligheid een RAID-Z. Maar na het toevoegen van de extra disk dus een volwaardige 10-disk RAID-Z2.

Je kunt dit in ZFSguru via de web-interface doen. Maak eerst een memorydisk van 4TB+ aan (kies swap-backend) en formatteer deze op de disks pagina. Dan gewoon een 10-disk RAID-Z2 pool maken en na het aanmaken rebooten. Geen data op de pool zetten, want dan wordt je memory disk ook gevuld; en je hebt natuurlijk geen 4TB+ RAM. De memory disk gebruikt pas RAM zodra je hem vult.

[azerty]

Verwijderd schreef op dinsdag 19 augustus 2014 @ 22:17:
Een 10 disk RAID-Z2 aanmaken met 9 schijven, door één memory disk te gebruiken en direct na het aanmaken van de pool te rebooten. Dan draai je single degraded. Qua snelheid lever je niet veel in; qua veiligheid een RAID-Z. Maar na het toevoegen van de extra disk dus een volwaardige 10-disk RAID-Z2.

Je kunt dit in ZFSguru via de web-interface doen. Maak eerst een memorydisk van 4TB+ aan (kies swap-backend) en formatteer deze op de disks pagina. Dan gewoon een 10-disk RAID-Z2 pool maken en na het aanmaken rebooten. Geen data op de pool zetten, want dan wordt je memory disk ook gevuld; en je hebt natuurlijk geen 4TB+ RAM. De memory disk gebruikt pas RAM zodra je hem vult.

Daar zou ik dus nooit opgekomen zijn

Dank voor de duidelijke uitleg! Zal het morgenochtend uitvoeren

@zzattack: dank voor het meedenken. De oplossing van Cipher lijkt mij echter een stuk beter (de huidige data staat trouwens op een Synology NAS'je, dus ik heb geen "oude" pool om het zo te zeggen)

[ Voor 9% gewijzigd door azerty op 19-08-2014 22:23 ]

[zzattack]

Mee eens, sowieso doen wat CiPHeR zegt

[Mezz0]

Hebben jullie ook de ervaring dat je writes in elkaar stort met een slechte hd?

Ik heb namelijk een raid z2 pool met 6 disks (niet het zelfde merk maar wel dezelfde stats) en ik had een write speed van ~350 MB/s en opeens daalde het naar ~40 of maximal ~80.

Mijn zfsguru server is een vm met een ibm1015 in passthrough en ik test de speeds met crystal benchmark op een windows vm. Ook heb ik een ssd voor cache en log aangezet.

Op google ben ik iemand tegen gekomen die ongeveer het zelfde had en erachter kwam dat 1 van zn disks erg warm werd en dat daardoor zn write performance dropte. Nu ben ik zelf aan het testen geweest in zfsguru bij advanced disk benchmarking en kwam erachter dat smart geen error's gaf maar wanneer ik een benchmark draaide met telkens een schijf erbij dat opeens de write performance dropte. Toen ik de bewuste schijf eruit haalde en het weer ging testen met mn windows vm was de performance weer terug..... tot aan afgelopen weekend.. mn write performance is weer ~80 max.

Nu kan ik weer gaan testen per disk maar zoals eerder gezegd geeft smart geen fout code. Zijn er andere manieren? of moet ik denken aan dat ik alleen hetzelfde merk ga gebruiken.

mochten jullie ideeën hebben of vragen over mn config dan hoor ik dat graag.

[Kortfragje]

Ik ben zo zoetjes aan aan het denken over een storage upgrade. Op dit moment draai ik 2 * RAIDZ2 (6 disks van 2TB) in twee verschillende servers (zfspool1 en zfspool2). Dit geeft me 7.2 TB in beide

Nu heb ik een paar opties om mn storage uit te breiden en ik wilde vragen of mensen feedback willen geven op de opties (ik heb nog 1 extra 2TB drive)

(aanname 2 TB drive = 1862 GB = 1.82 TB / 4TB drive = 3724 GB = 3.64 TB)


Optie 1:
Vervang disks zfspool1 door 4 TB disks en alle andere disks naar backup:
-1*RaidZ2 van effectief 14.5TB in server
-2*RaidZ2 in backup ook netto ~ 14.5TB (2 * 7.2)

Optie 2:
Maak een nieuwe pool van 7*4TB disks in server, maak 1 vdev van 13 2TB disks (Raidz2) in backup
-1*Raidz2 van netto 17 TB (klopt dit?)
-1*Raidz2 van 19.5 TB

Uiteraard is 13 disks in 1 raidz2 vdev wellicht wat aan de grote kant, dus optie 3 zou zijn:

Optie 3:
Maak een nieuwe pool van 7*4TB disks in server, maak 2 vdevs van 6 en 8 2TB disks (Raidz2) in backup (wel extra disk nodig).
-1*Raidz2 van netto 17 TB
-2*RaidZ2 van netto 17.1 TB (7.2 + 9.9)

Optie 4:
Maak een nieuwe pool van 8*4TB disks in server, maak 1 vdev van 13 2TB disks (Raidz2) in backup
-1*Raidz2 van netto 19.9 TB
-1*Raidz2 van 19.5 TB


De netto ruimte heb ik als volgt berekend :
-6 disk raidz2 (2TB disks), 4 data disks.
geen padding dus optimaal,
Disk overhead 1.5 (6/4)
==> netto 10.9 / 1.5 ~ 7.2 TB (dubbel dat voor 4TB)

-7 disk raidz2 (4TB disks), 5 data disks.
bij 128k stripe size dus 25.6k per disk --> is 6.4 sectoren van 4k
dus 28k per disk na padding (= 7 sectoren) -> 140k effectief.
Disk overhead is 1.4 (7/5) en padding nog eens 0.10
==> netto 25.4 / 1.5 ~ 17 TB

8 disk raidz2 (4TB disks), 6 data disks.
bij 128 stripe size dus 21.33 per disk --> 5.3 sectoren van 4k
dus 24k per disk na padding (= 6 sectoren) -> 144k effectief.
Disk overhead is 1.3 (8/6) en padding nog eens 0.12
==> netto 29.09 / 1.46 ~ 19 TB (helft bij 2TB disks)


Wat ik me vooral af vraag is of ik zo de netto ruimte goed heb ingeschat. De performance is minder belangrijk want alles moet over een gigabit lijntje en dat wordt volgens mij zo wel dicht getrokken in alle gevallen...

[FireDrunk]

Mezz0 schreef op donderdag 21 augustus 2014 @ 11:14:
Hebben jullie ook de ervaring dat je writes in elkaar stort met een slechte hd?

Ik heb namelijk een raid z2 pool met 6 disks (niet het zelfde merk maar wel dezelfde stats) en ik had een write speed van ~350 MB/s en opeens daalde het naar ~40 of maximal ~80.

Mijn zfsguru server is een vm met een ibm1015 in passthrough en ik test de speeds met crystal benchmark op een windows vm. Ook heb ik een ssd voor cache en log aangezet.

Op google ben ik iemand tegen gekomen die ongeveer het zelfde had en erachter kwam dat 1 van zn disks erg warm werd en dat daardoor zn write performance dropte. Nu ben ik zelf aan het testen geweest in zfsguru bij advanced disk benchmarking en kwam erachter dat smart geen error's gaf maar wanneer ik een benchmark draaide met telkens een schijf erbij dat opeens de write performance dropte. Toen ik de bewuste schijf eruit haalde en het weer ging testen met mn windows vm was de performance weer terug..... tot aan afgelopen weekend.. mn write performance is weer ~80 max.

Nu kan ik weer gaan testen per disk maar zoals eerder gezegd geeft smart geen fout code. Zijn er andere manieren? of moet ik denken aan dat ik alleen hetzelfde merk ga gebruiken.

mochten jullie ideeën hebben of vragen over mn config dan hoor ik dat graag.

Ligt ook een beetje aan de manier van storage teruggeven aan je Host (ESXi). NFS is niet zo snel, iSCSI is in veel gevallen sneller. Bovendien is een L2ARC toevoegen in sommige gevallen funest voor de write performance (ZFS gaat de data cachen op de L2ARC SSD en als dat erg lang duurt, bottlenecked dat in zeldzame gevallen de algehele write speed van de pool).

Bovendien moet je gebruik maken van PVSCSI in de VM, daar word alles een stuk sneller van

[Mezz0]

Ik geef de storage via iSCSI terug aan de ESXi. Daarnaast zal ik de L2ARC eraf halen en daarna testen.

Wat me nu wel te binnen schiet is dat ik het ook getest heb met de advanced disk benchmark tool heb en dat daar ook de writes slecht zijn. die maakt dat geen gebruik van L2ARC. maar ik ga het toch even testen.. You never know

[FireDrunk]

Een applicatie bepaald niet of er gebruik gemaakt word van L2ARC? L2ARC hangt aan de pool, alle IO naar die pool zal (volgens een speciaal algoritme) gecached worden.

[Verwijderd]

Wat je kunt doen is via SSH een dd-read op alle disks starten:

dd if=/dev/ada0 of=/dev/null bs=1m count=10000 &

Herhaal dit voor alle disks (vervang ada0 door de disk naam) en vergeet ook niet de & op het einde zodat het op de achtergrond wordt uitgevoerd. Start daarna 'gstat' en kijk welke disk afwijkt van de massa.

[Q]

Kortfragje schreef op donderdag 21 augustus 2014 @ 12:39:
Ik ben zo zoetjes aan aan het denken over een storage upgrade. Op dit moment draai ik 2 * RAIDZ2 (6 disks van 2TB) in twee verschillende servers (zfspool1 en zfspool2). Dit geeft me 7.2 TB in beide

Nu heb ik een paar opties om mn storage uit te breiden en ik wilde vragen of mensen feedback willen geven op de opties (ik heb nog 1 extra 2TB drive)

(aanname 2 TB drive = 1862 GB = 1.82 TB / 4TB drive = 3724 GB = 3.64 TB)

Wat ik me vooral af vraag is of ik zo de netto ruimte goed heb ingeschat. De performance is minder belangrijk want alles moet over een gigabit lijntje en dat wordt volgens mij zo wel dicht getrokken in alle gevallen...

Als de performance niet zo uitmaakt kun je zelf kiezen hoeveel disks je in een VDEV duwt en met ashift=9 werken. Je zult evengoed nog wel wat verlies hebben als je je niet aan 2^n data disks houdt, maar lang niet zoveel als bij 4K sectoren.

[zzattack]

Vraag aan CiPHeR: moet ik me voor een 10-disk raidz2 van WD40EZRX schijven druk maken over ashift en alignment?

[CurlyMo]

Ja en Ja

[zzattack]

Oei. Kun je toelichten?
Ik wil graag glabel gebruiken op de disks en dan de /dev/label/blah{1,2,3,...,10} toevoegen aan de vdev. Dit zijn volgens mij nog de volledige disks (als zfs de geom label dan niet om zeep helpt). In ieder geval mag ZFS vooraan de schijf beginnen.
De reported sector size is 512b volgens mij. Simpelweg creëren van een pool gooit ashift toch op 12. Naar ik weet zijn de meeste (alle?) recentelijke WD schijven fysiek 4k.
Betekent dit dat alles in orde is?

[Verwijderd]

Alignment is vooral de partitie offset die belangrijk is. Als je ZFSguru gebruikt zit dat altijd goed. Bij FreeNAS bij recente versies volgens mij ook. Bij oudere Solaris/OI versies is dit wel een probleem omdat die vieze partities maakt zoals Windows XP die ook maakt: met 63-sector offset (31.5K) een oude gewoonte uit het Cylinder/Sector/Heads (CSH) tijdperk. Die moeten hard billekoek krijgen.

Ashift is 4K optimalisatie voor ZFS pools. Bij 10-disk RAID-Z2 is het vooral zo dat een 4K optimalisatie je geen ruimte kost; terwijl niet-optimale configuraties met ashift=12 (4K) je wél ruimte kost en het dus 'duur' is om te optimaliseren voor 4K. Bij een optimale configuratie zoals 10-disks in RAID-Z2 kun je dus 'straffeloos' ashift=12 (4K) optimaliatie activeren. Maar ook zonder draait het opzich prima; beter dan andere niet-optimale configuraties. Het hele ashift-verhaal is een afweging tussen bruikbare opslagrruimte en performance. Bij optimale configuraties kun je beide optimaal krijgen, dat is het punt.

[zzattack]

Mooi dat ZFSGuru het meteen goed doet. Het create new pool menu biedt deze 2 opties:

• No sector size override (normal harddrives)
• Optimize for Advanced Format 4k drives

Als ik het goed begrijp kan ik dus voor de onderste optie gaan omdat ik een 10-disk raidz2 kies wat een optimale configuratie is?

[Verwijderd]

Inderdaad.

Hier nog een overzicht van de verloren ruimte bij 4K optimalisatie (ashift=12):



Bij de optimale configuraties zie je dus dat er geen ruimteverlies is. Dit overzicht is zonder parity disks; dus 8 disks = een 10-disk RAID-Z2 configuratie of een 9-disk RAID-Z. Het is dus een power of 2 aantal data disks wat optimaal is.

[ Voor 93% gewijzigd door Verwijderd op 22-08-2014 00:07 ]

[zzattack]

Erg duidelijk, dank voor de toelichting. Bizar wat gebeurt er vanaf 18 disks met de 4k configuratie!

Compleet wat anders. Ik heb nog een 64GB Crucial SSD over. Deze was ooit ongeschikt om in te zetten als zil omdat bij stroomuitval geriskeerd zou worden dat de pool niet langer te mounten was. Ik geloof dat dit ooit aangepakt zou worden in een latere ZFS versie, waarna dit wel mogelijk zou zijn. Andere optie is de SSD inzetten als l2arc, mits er genoeg RAM beschikbaar is. Is het überhaupt interessant om een relatief kleine SSD (64GB) in te zetten op een relatief grote pool (40TB), wanneer het systeem in totaal 32GB aan RAM heeft, ofwel als zil, ofwel als RAM?

[Verwijderd]

Edit: de volgende quote heb ik denk ik verkeerd geïnterpreteerd. Ik dacht dat je bedoelde dat het gebrek van power-caps bij een sLOG device/dedicated ZIL ooit 'opgelost' zou worden in ZFS. Maar je bedoelde denk ik dat het ontoegankelijk worden van je pool opgelost zou worden. Dat laatste is inderdaad het geval; vanaf ZFS versie 19 kun je een forced import doen van je pool waarbij de sLOG device er niet meer is. Daarbij kun je wel ver in het verleden gaan en vereist dus handmatige interventie. Maar dat je pool stuk zou zijn als je sLOG het begeeft, is dus al lange tijd niet meer het geval.

Ik geloof dat dit ooit aangepakt zou worden in een latere ZFS versie, waarna dit wel mogelijk zou zijn.

Daar weet ik niets van; en dat lijkt mij hoogst onwaarschijnlijk. Bij een ZIL gaat het juist om de recente writes; als een opslagapparaat die juist niet heeft bij bijvoorbeeld een stroomfailure of OS crash, dan lijkt mij dat hetzelfde als de ZIL helemaal uitgeschakeld hebben. Dat wil je niet in de meeste gevallen, al kan ZFS nog naar een veel oudere transaction group terugvallen. Als je een sLOG (losse ZIL) neemt, dan wil je ook dat dat nut heeft. Dus dan heb je een SSD nodig die recente writes kan vasthouden; dat betekent dus power-caps. Samsung SSDs bijvoorbeeld zijn ongeschikt omdat die een rollback doen. Voor een desktop SSD is dat prima maar voor een sLOG device is dat funest. Crucial M4 kan corrupt raken en verliest sowieso zijn write buffer.

Wel kun je elke SSD als L2ARC device gebruiken - no matter hoe slecht je SSD is. Corruptie zal namelijk gewoon worden gedetecteerd en ZFS zal in dat geval van de pool lezen. Dus ook OCZ SSDs kun je gewoon gebruiken als L2ARC zonder zorgen te hebben over corruptie.

Bij L2ARC is het zo dat in de toekomst je persistent caching kunt verwachten, waarbij de data op de SSD behouden blijft na reboots. Nu is dat nog niet zo; na een reboot moet de L2ARC weer vanaf het begin worden opgebouwd. Dit betekent dat L2ARC alleen zin heeft als je het systeem lang aan laat staan.

Bij 32GiB RAM voor een thuissituatie heb je geen L2ARC nodig - wel zou ik de metadata limiet eraf gooien. Bij ZFSguru kun je de /boot/loader.conf editen en daar zie je:

# ARC metadata limits
# increase to cache more metadata (recommended if you have enough RAM)
#vfs.zfs.arc_meta_limit="128m"

Die laatste regel wil je uncommenten en maak er lekker 8G van ofzo. Dan kun je vrijwel al je metadata in RAM cachen. Dat betekent lekker door directories heenzoeven alsof het een SSD is en ook lekker snel zoeken op je NAS. Ik ben een groot voorstander van metadata cachen, vooral voor een typische thuis NAS met veel grote bestanden heeft dit nut; terwijl het cachen van bestanden dan weer minder nut heeft. Doordat je veel metadata cached, betekent dit ook dat de hardeschijven ontzien worden en enkel daadwerkelijke data hoeven te lezen, ipv ook metadata tussendoor. Scheelt weer seeks en dus betere responstijd.

[ Voor 11% gewijzigd door Verwijderd op 22-08-2014 01:15 ]

[Q]

Dat is interessant. Ik merk dat bijvoorbeeld een find over alle data wat langer duurt de 1e keer na boot als bij mijn oude legacy file server die geen ZFS draait.

root@nano:/storage# cat /sys/module/zfs/parameters/zfs_arc_meta_limit
0

Kan ik hier uit afleiden dat ZFS op Linux geen limiet hanteert en de setting voor thuis gebruik 'goed' staat?

[Verwijderd]

Define 'goed'

Standaard is het 128MiB op *BSD en dat is dus erg weinig. Ik heb hem op 8GiB staan met 32GiB RAM op mijn main fileserver. Je kunt met kstats ook zien of het capped is of niet; meestal tot 6GiB bij mij. Ik doe ook aan ARC warmup bij booten door een 'find' commando te draaien wat alle directories doorloopt. Simpel doch doeltreffend. Bij ZFSguru is dit ook geïntegreerd door een /etc/rc.conf variabele te enablen.

Dat het bij ZFS langer duurt dan legacy filesystems lijkt me ook redelijk logisch, aangezien er ook checksums en dergelijke aan te pas komen. Verder kan het zijn dat er meer seeks nodig zijn om de metadata in te lezen; dat hangt af van de distributie van de metadata en ik ken ZFS niet goed genoeg om daar wat over te zeggen.

[FireDrunk]

Voor zover ik weet doet ZoL ARC Meta limit gewoon vullen zolang je ARC nog niet vol is, en word metadata meegenomen in het algoritme van MRU/MFU...

Maar ik kan het mis hebben.

[zzattack]

Erg coole optie om de maximale grootte van je metadata op te schroeven, maar ik heb m'n bedenkingen over het nut ervan. Aangezien deze setting in /boot/loader.conf zit lijkt me dit globaal voor alle pools op je OS te worden toegepast. Als je OS op een aparte zpool staat is, denk ik, de verdeling van ruimte voor metadata niet zoals gewenst, nl. een groot deel voor je OS met heel erg veel kleine bestanden t.o.v. vrijwel uitsluitend grote bestanden op de storage pool. Als je daarbij optelt dat het OS al op een SSD draait krijg ik het idee dat dit een verspilling van RAM is. Klopt dit enigszins of lul ik totale onzin?

[FireDrunk]

De hoevelheid metadata die nodig is, blijft gelijk per file. Dus of het nou een grote file is of niet, maakt weinig uit.

Je OS pool zal inderdaad dan wat meer metadata pakken, maar metadata is nou niet zo groot dat het je gigabytes aan geheugen kost... Als je het zou kunnen tunen per pool zal je dat hooguit een paar honderd MB geheugen schelen (en dat is zelfs al extreem hoog geschat denk ik)...

[Bigs]

Is het wel nodig om die metadata limiet aan te passen? Op mijn stock FreeBSD 10 systeem met 8GB RAM zie ik het volgende:

root@nelson:~ # sysctl -a | grep arc_meta_limit
vfs.zfs.arc_meta_limit: 1806053376

Volgens mij gebruikt hij dus uit zichtzelf al 1,8GB voor metadata.

In top zie ik het volgende:

ARC: 4307M Total, 3249K MFU, 1599M MRU, 3218K Anon, 233M Header, 2468M Other

Het sluit wel aan bij de berichten dat je ZFS in recente FreeBSD versies eigenlijk niet hoeft te tunen.

[ Voor 12% gewijzigd door Bigs op 22-08-2014 12:56 ]

[Q]

Verwijderd schreef op vrijdag 22 augustus 2014 @ 03:43:
Define 'goed'

Standaard is het 128MiB op *BSD en dat is dus erg weinig. Ik heb hem op 8GiB staan met 32GiB RAM op mijn main fileserver. Je kunt met kstats ook zien of het capped is of niet; meestal tot 6GiB bij mij. Ik doe ook aan ARC warmup bij booten door een 'find' commando te draaien wat alle directories doorloopt. Simpel doch doeltreffend. Bij ZFSguru is dit ook geïntegreerd door een /etc/rc.conf variabele te enablen.

Dat het bij ZFS langer duurt dan legacy filesystems lijkt me ook redelijk logisch, aangezien er ook checksums en dergelijke aan te pas komen. Verder kan het zijn dat er meer seeks nodig zijn om de metadata in te lezen; dat hangt af van de distributie van de metadata en ik ken ZFS niet goed genoeg om daar wat over te zeggen.

Ik zie dit:

code:

root@nano:~# cat /proc/spl/kstat/zfs/arcstats | grep -i meta
demand_metadata_hits            4    2539210
demand_metadata_misses          4    119574
prefetch_metadata_hits          4    104830
prefetch_metadata_misses        4    8509
meta_size                       4    2583653888
anon_evict_metadata             4    0
mru_evict_metadata              4    2214428672
mru_ghost_evict_metadata        4    1067335680
mfu_evict_metadata              4    85417472
mfu_ghost_evict_metadata        4    458293248
arc_meta_used                   4    3473477712
arc_meta_limit                  4    6276490752
arc_meta_max                    4    5272136464

Dus ik heb blijkbaar een 6 GB limiet die nu voor 3 GB in gebruik is.

Dat is interessant, want ik heb nog maar 16 TB aan data op het ding staan. Als ik extrapoleer zou mijn RAM geheugen wel eens een bottle neck kunnen worden .

Grappig dat jij inderdaad een find doet bij het booten, in de background neem ik aan? Eigenlijk wel een idee.

[ Voor 7% gewijzigd door Q op 22-08-2014 13:11 ]

[zzattack]

Bigs schreef op vrijdag 22 augustus 2014 @ 12:55:
Is het wel nodig om die metadata limiet aan te passen?

Uit het handbook:

vfs.zfs.arc_meta_limit - Limits the portion of the ARC that can be used to store metadata. The default is 1/4 of vfs.zfs.arc_max. Increasing this value will improve performance if the workload involves operations on a large number of files and directories, or frequent metadata operations, at the cost of less file data fitting in the ARC. This value can only be adjusted at boot time, and is set in /boot/loader.conf.

Lijkt dus inderdaad niet nodig.

[Bigs]

zzattack schreef op vrijdag 22 augustus 2014 @ 13:06:
[...]

Uit het handbook:

[...]

Lijkt dus inderdaad niet nodig.

Je moet dus inderdaad wel een hele goede (en goed doordachte) reden hebben om hier aan te gaan zitten sleutelen.