Het grote ZFS topic

[ZombieExtreme]

Mezelf kennende komt hier weer een lange post, hopelijk voeg ik voldoende info toe en kan iemand me op gang helpen.

Ik gebruik nu zo'n anderhalf jaar ZFSguru als NAS en SABnzbd downloader, naar tevredenheid (bedankt Jason & CiPHER!). Het systeem is een Celeron G550 op Asrock B75 Pro3-M met 16GB en flink wat TB aan HDDs. Ik had een separate Win7 PC bij de TV (Samsung LE40C750) om XBMC te draaien en 1080p films van de NAS te spelen. Ik had de XBMC service geprobeerd maar toen liepen de films erg slecht dus gekozen voor een separate Win7 PC. HDMI verbinding naar de TV en toslink naar de receiver.

Een paar maanden geleden heb ik ZFSguru geupgrade naar 10.0-002 en de nodige services meteen geïnstalleerd. Ik merkte op dat de XBMC service een v13 beta is, en heb het opnieuw geprobeerd. De films lopen goed en schokken alleen als ik tevens files ga kopiëren. Aangezien het voor thuisgebruik is, is dit geen probleem. Zodoende heb ik de ZFSguru hardware in het TV meubel geplaatst, HDMI naar de TV en toslink naar de receiver. Na even uitzoeken hoe ik geen Pulseaudio krijg maar Realtek rear digital, werkte het geluid ook, en de receiver gaf mooi DTS of DD aan.

Volgende stap; receiver vervangen door een exemplaar met HDMI en ondersteuning voor HD audio. Uiteindelijk is het de Pioneer VSX-923 geworden. Toen ik deze aansloot werden de display kleuren binnen gnome (op de TV) verkeerd. Wat er precies fout is weet ik niet, het lijkt op veel teveel groen, maar kan ook een kleurinversie of verwisseling zijn. Tijdens de boot zijn de kleuren goed (bios, FreeBSD en ZFSguru teksten) tijdens de switch naar Gnome gaat het pas fout. Met 100% zekerheid.

De volgende zaken heb ik geprobeerd zonder resultaat:
- Firmware van TV, receiver en mobo geupdate indien mogelijk.
- Verschillende HDMI kabels geprobeerd (waaronder 2.0 compatible).
- Verschillende HDMI inputs van de receiver geprobeerd.
- Video bewerking van de receiver uitgezet (passthrough) en verschillende dingen getest.
- Op de TV verschillende video settings getest.
- In plaats van de TV een HDMI monitor aangesloten, ook hiermee foute kleuren.

Ik kan de receiver niet 100% uitsluiten, maar volgens mij is het probleem ZFSguru of FreeBSD of Gnome gerelateerd, vandaar mijn post in dit topic .

Bij de volgende situaties zijn de kleuren goed:
- Receiver-eigen menu's zijn correct (tijdens instellingen menu, internet radio etc)
- Receiver op een andere (Windows) PC aangesloten met dezelfde kabel: volledig correcte kleuren
- PS3 aangesloten via de receiver: correcte kleuren (bij alle video opties die de PS3 heeft)
- Resolutie binnen Gnome verlagen

Dit laatste punt heeft me doen denken dat het een handshake probleem betreft, maar zowel de Windows PC als de PS3 kunnen probleemloos 1080p weergeven.

Ik heb momenteel de volgende ideeën die het probleem misschien verhelpen;
- De G550 vervangen door een G16x0; De Ivy bridge CPU zou veel verbeteringen hebben tov de Sandy Bridge.
- ZFSGuru 11 proberen
- Nieuwe of andere Intel KMS drivers proberen (en uitzoeken hoe ik deze kan installeren)
- NVidia kaart lenen, insteken en testen (Ik heb alleen AMD kaarten in huis)
- De EDID forceren (en uitzoeken hoe dit onder Gnome moet)
- Een andere receiver lenen om te testen of het merk/type/exemplaar gerelateerd is.

Heeft iemand een idee welke kant de waarschijnlijkste is?

[nero355]

Volgens mij heb jij dit probleem en zit je tevens in het verkeerde topic : http://www.cypheros.de/colspace_e.html

Succes!

[ZombieExtreme]

Fout kleurbereik was mijn eerste vermoeden maar ik dacht dit uitgesloten te hebben omdat ik op de PS3 alle display settings heb uitgeprobeerd, waaronder de full-RGB settings. Deze gaan allemaal goed. Het liefste zou ik het natuurlijk binnen ZFSguru/Gnome uitproberen, maar ik weet nog niet hoe dat kan . Ik ga eens op zoek.

EDIT:
Volgens mij heb ik het al gevonden:
OUTPUT=`xrandr -display :0 -q | sed '/ connected/!d;s/ .*//;q'`
xrandr --output $OUTPUT --set "Broadcast RGB" "Full"
Nu uitzoeken waar ik dit moet toevoegen

EDIT2:
Ik heb via de terminal xterm "Full" en "Limited 16:235" geprobeerd maar dit geeft geen enkel verschil. Ik zie dat het display wel opnieuw geinitialiseerd wordt en heb met --prop geverifieerd dat de setting gelukt was. Helaas is dit de oplossing niet . Wat ik wel heb gedetecteerd is dat het probleem ook aanwezig is op 720p. Dus op 1080p en 720p zijn de kleuren fout maar op alle andere resoluties zijn de kleuren wel in orde.

[ Voor 53% gewijzigd door ZombieExtreme op 06-04-2014 10:33 ]

[]Byte[]

Kan iemand mij vertellen waar ik moet zoeken waar de hardware zo druk mee bezig is op een systeem wat 'niets doet'?

last pid:  7826;  load averages:  1.00,  0.98,  0.93     up 0+15:05:03  11:26:34
51 processes:  1 running, 50 sleeping
CPU:  0.0% user,  0.0% nice,  [b]7.5% system[/b],  0.0% interrupt, 92.5% idle
Mem: 50M Active, 620M Inact, 2867M Wired, 896K Cache, 59G Free
ARC: 1428M Total, 206M MFU, 428M MRU, 51K Anon, 26M Header, 768M Other
Swap: 2048M Total, 2048M Free

Soms na een reboot doet ie echt niets en zit de load regens rond de 0.06-0.08
Maar na de laatste reboot's is ie ergens druk mee bezig, maar weet alleen niet met wat.

[FireDrunk]

Wat staat er bovenaan in top?

[]Byte[]

soms 'top' zelf of clamd of python2.7 (van sabnzbd)
Maar die staan allemaal op 0.00%
Als die load zouden verstoken zou ik dat terug zien in user-load... niet in system-load (lijkt mij)

Maar ook als ik alle services disabled zet maakt het geen verschil.

[ Voor 16% gewijzigd door ]Byte[ op 06-04-2014 15:03 ]

[matty___]

]Byte\[ schreef op zondag 06 april 2014 @ 14:35:
soms 'top' zelf of clamd of python2.7 (van sabnzbd)
Maar die staan allemaal op 0.00%
Als die load zouden verstoken zou ik dat terug zien in user-load... niet in system-load (lijkt mij)

Maar ook als ik alle services disabled zet maakt het geen verschil.

Heb je device polling aanstaan voor een van je nics?

[DXaroth]

]Byte\[ schreef op zondag 06 april 2014 @ 11:34:
Kan iemand mij vertellen waar ik moet zoeken waar de hardware zo druk mee bezig is op een systeem wat 'niets doet'?

last pid:  7826;  load averages:  1.00,  0.98,  0.93     up 0+15:05:03  11:26:34
51 processes:  1 running, 50 sleeping
CPU:  0.0% user,  0.0% nice,  [b]7.5% system[/b],  0.0% interrupt, 92.5% idle
Mem: 50M Active, 620M Inact, 2867M Wired, 896K Cache, 59G Free
ARC: 1428M Total, 206M MFU, 428M MRU, 51K Anon, 26M Header, 768M Other
Swap: 2048M Total, 2048M Free

Soms na een reboot doet ie echt niets en zit de load regens rond de 0.06-0.08
Maar na de laatste reboot's is ie ergens druk mee bezig, maar weet alleen niet met wat.

als er geen processen druk zijn, dan kan het I/O waits zijn waardoor de load omhoog gaat (of swap migraties)

[]Byte[]

matty___ schreef op zondag 06 april 2014 @ 16:50:
[...]

Heb je device polling aanstaan voor een van je nics?

Als je mij kan vertellen waar ik dat kan vinden....
Er zitten 4 NIC's in (2 onboard en 2 op een dual-NIC card) die in een LAGG staan.

[update]
Ik heb nog ff verder gezocht...
Deze kan ik vinden op 'poll'

code:

kern.cam.cd.poll_period: 3
kern.cam.da.poll_period: 3
kern.polling.burst: 5
kern.polling.burst_max: 150
kern.polling.each_burst: 5
kern.polling.idle_poll: 0
kern.polling.user_frac: 50
kern.polling.reg_frac: 20
kern.polling.short_ticks: 0
kern.polling.lost_polls: 0
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 0
kern.polling.phase: 0
kern.polling.suspect: 0
kern.polling.stalled: 0
kern.polling.idlepoll_sleeping: 1
debug.acpi.ec.polled: 0
hw.mfi.polled_cmd_timeout: 60
hw.usb.xhci.use_polling: 0
hw.usb.ukbd.pollrate: 0

[ Voor 51% gewijzigd door ]Byte[ op 06-04-2014 18:55 ]

[]Byte[]

DXaroth schreef op zondag 06 april 2014 @ 17:47:
[...]


als er geen processen druk zijn, dan kan het I/O waits zijn waardoor de load omhoog gaat (of swap migraties)

Dat is nu juist mijn probeem...
Ik had ook al een verdenking in die hoek.

Vandaar mijn vraag:
"Kan iemand mij vertellen waar ik moet zoeken waar de hardware zo druk mee bezig is op een systeem wat 'niets doet'?"

Ik heb er wel een zabbix_agentd op draaien, maar krijg ik op de iowait een NOT_SUPPORTED terug. Op andere systemen (o.a. CentOS, Windows en op 1 van de 2 QNAP's) werkt het wel, maar ZFSguru... Noppes

[Verwijderd]

top -S laat systeemprocessen zien. Je kunt ook gewoon 'top' starten en met Shift+S togglen tussen user processen of user+systeem processen. Aangezien je top-output 'system' aangeeft, zouden dit drivers of kernel activiteit kunnen zijn. Dan denk ik eerder aan hardware.

[]Byte[]

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
   11 root         12 155 ki31     0K   192K RUN    11  49.4H 1170.31% idle
    0 root        612  -8    0     0K  9792K -      11 233:15  88.43% kernel
   12 root         55 -92    -     0K   880K WAIT    0   0:18   0.00% intr
    2 root         17  -8    -     0K   320K zvol:i  8   0:11   0.00% zfskern
 4772 clamav        2  52    0   317M   266M select 11   0:10   0.00% clamd
 4778 clamav        1  52    0 50568K 12116K pause   2   0:09   0.00% freshclam
 5928 _sabnzbd      2  20    0   224M 59224K select 10   0:08   0.00% python2.7
 [...]

De kernel...
Is er nog een mogelijkheid om nog verder 'te spitten'?

Als het hardware is, zou ik verwachten dat ik altijd dezelfde 'idle-load' zou zien.
Maar soms lukt het na een reboot dat ie bijna helemaal geen cpu-load verstookt.
De vraag die dan blijft, waarom zo inconsequent?

[ Voor 13% gewijzigd door ]Byte[ op 06-04-2014 19:39 ]

[matty___]

]Byte\[ schreef op zondag 06 april 2014 @ 18:23:
[...]

Als je mij kan vertellen waar ik dat kan vinden....
Er zitten 4 NIC's in (2 onboard en 2 op een dual-NIC card) die in een LAGG staan.

ifconfig en dan de options regel bekijken. Als daar POLLING bijstaat dan zou het dat wel eens zijn

[FireDrunk]

Kijk eens naar vmstat. Kan je een hoop mee vinden.

[hansdegit]

Heb hier nu ZFSGuru draaien. Ik vermoed wat performance problemen (ik krijg in een Windows VM totaal geen throughput). Dat wil ik even vergelijken met een nfs share. Dus in zfsguru een nfs share gemaakt op tier1 (pool met harddisks).

Een 2e VM gemaakt die Knoppix draait. Alleen: ik krijg die nfs niet gemount. Vanuit Knoppix tik ik:
sudo mount 192.168.0.192:/tier1/testje /mnt
(zoals ook voorgesteld door ZFSGuru).

Maar dan krijg ik de volgende reactie op mijn Knoppix scherm:
[...]failed, reason given by server: Permission denied.

Ik kan op het internet het verlossende antwoord niet vinden...Hier iemand?

Permissies staan zoals ik kan zien zo open mogelijk. Laatste commando om de nfs share te publiceren was:
/sbin/zfs set sharenfs="-alldirs -mapall=1000:1000 -maproot=Gitje -mask=0.0.0.0" tier1/testje

[]Byte[]

matty___ schreef op zondag 06 april 2014 @ 19:51:
[...]
ifconfig en dan de options regel bekijken. Als daar POLLING bijstaat dan zou het dat wel eens zijn

Tnx... Maar er staat geen polling op.

FireDrunk schreef op zondag 06 april 2014 @ 20:37:
Kijk eens naar vmstat. Kan je een hoop mee vinden.

Daar kom ik niet veel verder als alleen de eerder genoemde acpi die redelijk druk bezig is met .... te doen.

code:

[root@zfsguru ~]# vmstat -i
interrupt                          total       rate
irq1: atkbd0                           6          0
irq9: acpi0                    414130057      16842
irq16: ehci0                       43086          1
irq23: ehci1                       74023          3
cpu0:timer                      27792212       1130
irq264: mps0                       46600          1
irq265: mps1                       26227          1
irq266: em0                        19703          0
irq267: em1                        24972          1
irq268: isci0                          1          0
irq270: em2:rx 0                   46663          1
irq271: em2:tx 0                    9854          0
irq272: em2:link                       1          0
irq273: em3:rx 0                  485405         19
irq274: em3:tx 0                   13719          0
irq275: em3:link                       1          0
irq276: ahci0                     583674         23
cpu1:timer                       3395014        138
cpu3:timer                       8215408        334
cpu6:timer                       7820456        318
cpu2:timer                       8439403        343
cpu9:timer                       8580618        348
cpu10:timer                      8755611        356
cpu8:timer                       8447922        343
cpu5:timer                       5742305        233
cpu11:timer                      8437138        343
cpu4:timer                      27704292       1126
cpu7:timer                       7892021        320
irq280: mlx4_core0                 20937          0
irq281: mlx4_core0                 25269          1
Total                          546772598      22237

Maar of de rate van acpi0 nu echt de oorzaak is of niet, ik heb geen flauw idee wat 'normaal' de range is voor acpi.

Met andere opties als de '-w 5' of '-a' ... Ik weet nu niet echt waar ik naar moet kijken / hoe te interpreteren.
Aantal blocked processes blijft steady op 0. Dat lijkt mij ook geen probleem.
En bij faults de interrupts en system calls... tja... Ook hier ontbreekt mij de kennis om hier een juiste interpretatie aan te geven.
hoog/laag/normaal/...?

code:

[root@zfsguru ~]# vmstat -a 5
 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr ad0 ad1   in   sy   cs us sy id
 0 0 0   3640M    61G   145   0   0   0   256  87   0   0 16900  833 68355  0  7 93
 0 0 0   3640M    61G     0   0   0   0   142 119  27  25 16925  531 68397  0  8 92
 0 0 0   3640M    61G     0   0   0   0    50 119  21  19 17959  545 72425  0  7 93
 0 0 0   3640M    61G     0   0   0   0    51 119  23  18 17027  594 68677  0  7 93
 0 0 0   3640M    61G     0   0   0   0    52 119  21  17 17759  546 71593  0  7 93
 0 0 0   3640M    61G    10   0   0   0   114 119  26  22 16922  531 68297  0  7 93
 0 0 0   3640M    61G     0   0   0   0    57 119  18  14 17226  573 69539  0  7 93
 0 0 0   3640M    61G     0   0   0   0    48 119  22  18 17006  541 68586  0  7 93
 0 0 0   3640M    61G     0   0   0   0   106 119  32  31 16951  526 68373  0  7 93
 0 0 0   3640M    61G    61   0   0   0   135 119  21  19 17120  627 69038  0  7 93
 0 0 0   3640M    61G     0   0   0   0    50 119  23  21 17184  507 69279  0  8 92
 0 0 0   3640M    61G     0   0   0   0    51 119  22  21 16903  508 68244  0  7 93
 0 0 0   3640M    61G     0   0   0   0    52 119  21  17 16880  553 68175  0  7 93
 0 0 0   3640M    61G     0   0   0   0    72  95  31  21 16877  520 68182  0  8 92
 0 0 0   3640M    61G     0   0   0   0    48 119  25  23 16969  514 68508  0  7 93
 0 0 0   3640M    61G     0   0   0   0    48 119  23  21 16993  560 68638  0  7 93
 0 0 0   3640M    61G     0   0   0   0    51 119  21  19 16866  523 68092  0  7 93

[update]
gstat geeft ook niet veel meer duidelijkheid en lijkt daarmee de disk ook uit te kunnen sluiten.
Als er zich al een I/O voordoet ligt de ms/w over het algemeen < 0.2

[HyperBart]

Zo, dat is ook iets wat je niet alle dagen ziet

top - 09:57:55 up 21 days, 15:05,  1 user,  load average: 37.29, 36.59, 34.35
Tasks: 455 total,   2 running, 453 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us, 13.8 sy,  0.0 ni, 59.9 id, 26.1 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem:  32921192 total, 30499248 used,  2421944 free,      288 buffers
KiB Swap:  4882428 total,   332992 used,  4549436 free,     1868 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 3599 root      39  19     0    0    0 R 100.2  0.0 217:59.63 spl_kmem_cache/
   77 root      20   0     0    0    0 S   2.9  0.0  58:40.86 kswapd0
10687 root      20   0  351m  10m    0 S   1.9  0.0 127:47.32 ajenti-panel
 3630 root      39  19     0    0    0 D   1.0  0.0   1:12.22 zvol/19
 6026 root      20   0 1623m  64m    0 S   1.0  0.2  19:48.87 python
30981 root      20   0 1567m  31m    0 S   1.0  0.1  20:02.87 python
 6785 root      39  19     0    0    0 D   0.6  0.0   6:59.78 z_wr_iss/5
 6786 root      39  19     0    0    0 D   0.6  0.0   6:57.71 z_wr_iss/6
27264 root      20   0 20128 4708    0 D   0.6  0.0   0:08.15 unrar
27334 root      20   0 20916  936  140 R   0.6  0.0   0:01.53 top
28892 root      20   0 2376m  68m    0 S   0.6  0.2 407:45.67 sabnzbdplus
   17 root      20   0     0    0    0 S   0.3  0.0   7:29.14 rcu_sched
   18 root      20   0     0    0    0 S   0.3  0.0   1:11.29 rcuos/0
 3618 root      39  19     0    0    0 D   0.3  0.0   1:11.94 zvol/7
 3620 root      39  19     0    0    0 D   0.3  0.0   1:25.30 zvol/9
 3621 root      39  19     0    0    0 D   0.3  0.0   1:09.33 zvol/10
 3626 root      39  19     0    0    0 D   0.3  0.0   1:13.85 zvol/15
 3628 root      39  19     0    0    0 D   0.3  0.0   1:06.48 zvol/17
 3634 root      39  19     0    0    0 D   0.3  0.0   1:12.46 zvol/23
 3748 root      39  19     0    0    0 D   0.3  0.0   0:08.72 z_rd_iss/7
 6780 root      39  19     0    0    0 D   0.3  0.0   7:47.20 z_wr_iss/0
 6787 root      39  19     0    0    0 D   0.3  0.0   5:31.06 z_wr_iss/7
 6807 root      39  19     0    0    0 D   0.3  0.0   2:14.33 z_wr_int/14
 6854 root       0 -20     0    0    0 D   0.3  0.0  23:22.20 txg_sync
27065 bart      20   0 96908 1168  216 S   0.3  0.0   0:00.25 sshd
    1 root      20   0 28004 1088    0 S   0.0  0.0   0:01.68 init
    2 root      20   0     0    0    0 S   0.0  0.0   0:00.24 kthreadd
    3 root      20   0     0    0    0 S   0.0  0.0   0:05.44 ksoftirqd/0
    4 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0
    5 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0H
    7 root      rt   0     0    0    0 S   0.0  0.0   0:18.13 migration/0
    8 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcu_bh
    9 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/0
   10 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/1
   11 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/2
   12 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/3
   13 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/4
   14 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/5
   15 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/6
   16 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/7
   19 root      20   0     0    0    0 S   0.0  0.0   0:43.08 rcuos/1
   20 root      20   0     0    0    0 S   0.0  0.0   0:40.71 rcuos/2
   21 root      20   0     0    0    0 S   0.0  0.0   0:37.87 rcuos/3
   22 root      20   0     0    0    0 S   0.0  0.0   0:17.80 rcuos/4
   23 root      20   0     0    0    0 S   0.0  0.0   0:13.54 rcuos/5
   24 root      20   0     0    0    0 S   0.0  0.0   0:14.95 rcuos/6
   25 root      20   0     0    0    0 S   0.0  0.0   1:24.98 rcuos/7
   26 root      rt   0     0    0    0 S   0.0  0.0   0:05.77 watchdog/0
   27 root      rt   0     0    0    0 S   0.0  0.0   0:05.64 watchdog/1
   28 root      rt   0     0    0    0 S   0.0  0.0   0:26.70 migration/1
   29 root      20   0     0    0    0 S   0.0  0.0   0:13.47 ksoftirqd/1
   30 root      20   0     0    0    0 S   0.0  0.0   3:20.41 kworker/1:0
   31 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/1:0H
   32 root      rt   0     0    0    0 S   0.0  0.0   0:05.00 watchdog/2
   33 root      rt   0     0    0    0 S   0.0  0.0   0:27.98 migration/2
   34 root      20   0     0    0    0 S   0.0  0.0   0:02.53 ksoftirqd/2
   35 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kworker/2:0
   36 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/2:0H
   37 root      rt   0     0    0    0 S   0.0  0.0   0:04.96 watchdog/3
   38 root      rt   0     0    0    0 S   0.0  0.0   0:19.01 migration/3
   39 root      20   0     0    0    0 S   0.0  0.0   0:05.37 ksoftirqd/3
   40 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kworker/3:0
   41 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/3:0H
   42 root      rt   0     0    0    0 S   0.0  0.0   0:04.74 watchdog/4
   43 root      rt   0     0    0    0 S   0.0  0.0   0:03.59 migration/4
   44 root      20   0     0    0    0 S   0.0  0.0   0:00.56 ksoftirqd/4

ZFSonLinux, de guide van FireDrunk gevolgd.

Verklaart wel waarom Sab zo traag stond te downloaden en bijna niet kon uitpakken/repairen.

Iemand een ideetje of is dit nog steeds een bug?

[]Byte[]

HyperBart schreef op maandag 07 april 2014 @ 09:59:
Zo, dat is ook iets wat je niet alle dagen ziet

top - 09:57:55 up 21 days, 15:05,  1 user,  load average: 37.29, 36.59, 34.35
Tasks: 455 total,   2 running, 453 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us, 13.8 sy,  0.0 ni, 59.9 id, 26.1 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem:  32921192 total, 30499248 used,  2421944 free,      288 buffers
KiB Swap:  4882428 total,   332992 used,  4549436 free,     1868 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 3599 root      39  19     0    0    0 R 100.2  0.0 217:59.63 spl_kmem_cache/
   77 root      20   0     0    0    0 S   2.9  0.0  58:40.86 kswapd0
10687 root      20   0  351m  10m    0 S   1.9  0.0 127:47.32 ajenti-panel
 3630 root      39  19     0    0    0 D   1.0  0.0   1:12.22 zvol/19
 6026 root      20   0 1623m  64m    0 S   1.0  0.2  19:48.87 python
[...]

26.1% waiting...
Wat zegt je iostat?

Het is mij wel eens gelukt om 'belachelijke loads' te behalen, maar dat was icm de nodige dedup-testen (zie een paar pagina's terug)

[ Voor 6% gewijzigd door ]Byte[ op 07-04-2014 10:09 ]

[HyperBart]

Dat ben ik nu bit per bit aan het proberen te installeren .

[ Voor 3% gewijzigd door HyperBart op 07-04-2014 11:04 ]

[FireDrunk]

Je systeem staat te swappen, denk dat je ARC te vol zit.

[HyperBart]

Ik heb Sabnzbdplus even gestopt en gestart en de load is ineens helemaal naar 0.01 gegaan.

[]Byte[]

HyperBart schreef op maandag 07 april 2014 @ 11:41:
Ik heb Sabnzbdplus even gestopt en gestart en de load is ineens helemaal naar 0.01 gegaan.

(L1 & L2) ARC disabled zetten op je sabnzb-share is misschien een idee...
(heb ik ook gedaan op een paar shares)

[ Voor 8% gewijzigd door ]Byte[ op 07-04-2014 11:48 ]

[FireDrunk]

hmm, dat is best een goed idee, je downloads folder niet in ARC laten opnemen.
Enige probleem hier is dat dat op dezelfde pool staat als mijn data

Juist omdat een mv commando dan <1 sec duurt

[]Byte[]

I know...
Dat is voor mij ook de reden geweest om er toch aparte shares van te maken.
Niet alleen voor sabnzb maar ook voor mijn TimeMachine-backups.
Ook daar heb ik L1 & L2 disabled gezet.

Als je genoeg RAM hebt zou je L1 enabled kunnen laten, maar je ziet hoe je systeem reageert bij ARC icm sabnzb. L2 zou ik per definitie disabled zetten op dergelijk 'backup-folders'. (of je moet snel aan nieuwe SSD's willen )
Wat je verder ook kan overwegen is MP3's en films ook te excluden van ARC.
(dat is toch allemaal streaming meuk... toch?!?)

FireDrunk,
Ik zou gewoon sabnzbd excluden! Dus inclusief de submappen.
(cache, complete, incomplete, logs, nzb en temp)

Ohja...
En dedup aanzetten op je backup-shares!
De winst bij sabnzbd zal waarschijnlijk niet zo groot zijn, maar op de 'reguliere' backup-shares (TimeMachine) weer wel.

[ Voor 71% gewijzigd door ]Byte[ op 07-04-2014 13:01 ]

[HyperBart]

Ik download al naar een SSD zelf, kwestie dat mijn disks dan in spindown gaan en alleen bij de move naar mijn spinning disks de disks moeten opspinnen.

[]Byte[]

Heb je je al gerealiseerd wat sabnzb aan het doen is bij een repair of bij het uitpakken van je files?
Het gaat wel lekker snel, maar is wel killing voor je lifetime van de SSD's.

[MdBruin]

hansdegit schreef op zondag 06 april 2014 @ 21:16:
Heb hier nu ZFSGuru draaien. Ik vermoed wat performance problemen (ik krijg in een Windows VM totaal geen throughput). Dat wil ik even vergelijken met een nfs share. Dus in zfsguru een nfs share gemaakt op tier1 (pool met harddisks).

Een 2e VM gemaakt die Knoppix draait. Alleen: ik krijg die nfs niet gemount. Vanuit Knoppix tik ik:
sudo mount 192.168.0.192:/tier1/testje /mnt
(zoals ook voorgesteld door ZFSGuru).

Maar dan krijg ik de volgende reactie op mijn Knoppix scherm:
[...]failed, reason given by server: Permission denied.

Ik kan op het internet het verlossende antwoord niet vinden...Hier iemand?

Permissies staan zoals ik kan zien zo open mogelijk. Laatste commando om de nfs share te publiceren was:
/sbin/zfs set sharenfs="-alldirs -mapall=1000:1000 -maproot=Gitje -mask=0.0.0.0" tier1/testje

Als je op de console van je ZFSguru machine als su tikt showmount -e
Geeft deze dan bij de share Everyone op of iets anders?

Heb het hier even getest met ZFSGuru en een Mac maar de mount ging bij mij zonder problemen.
Welke versie ZFSGuru draai je met welke webinterface?

[hansdegit]

In /var/log/messages kwam ik foutmeldingen tegen; hij kon blijkbaar de /etc/zfs/exports niet goed interpreteren. Die file is nu redelijk kaal en voilà, nu kan ik NFS shares mounten vanaf een Linux VM.
Ben nog in test/ondekkingsfase, dus als het moet installeer ik zfsguru gewoon opnieuw. Ik heb de nieuwste webinterface, maar misschien heb ik nog niet de meest recente versie van de NAS software.

Ik ervaar alleen iets heel vreemds: Writes over NFS gaan met 70-80 MB/s, met reads kom ik niet boven de 4MB/s. Dat zijn de volgende (ws niet zo heel representatieve) testjes
voor de write performance:

dd if=/dev/zero of=/nfshare/outputfile bs=1048576 count=10000

Reads test ik als volgt

dd if=/nfshare/outputfile of=/dev/null bs=1048576

Ik moet wel zeggen: flinke leervurce voor een niet zo ervaren unix man.

[ Voor 19% gewijzigd door hansdegit op 07-04-2014 14:52 ]

[HyperBart]

]Byte\[ schreef op maandag 07 april 2014 @ 13:25:
Heb je je al gerealiseerd wat sabnzb aan het doen is bij een repair of bij het uitpakken van je files?
Het gaat wel lekker snel, maar is wel killing voor je lifetime van de SSD's.

Is dat effectief zo nefast voor die SSD in kwestie ja?

[]Byte[]

Laat ik het zo zeggen: sinds ik de discussie van o.a. CiPHER heb gevolgd over de impact van de write cycles op SSD's heb ik eens goed nagedacht over wat ik met de data wil bereiken.
SABnzbd staat onder aan de prioriteiten-lijst vwb het verslinden van mijn write-cycles op de SSD's.
Ik 'win' er niets mee, maar het kost mij wel m'n SSD's...
Daarop heb ik voor mijzelf de afweging gemaakt om alle SABnzbd en TimeMachine-meuk niet op L1 & L2-ARC te zetten.
Zolang ik op mijn HDD-pool zonder al te veel problemen zo'n 600 MB/s kan schrijven vindt ik het best.
Dan gebruik ik L1 en L2 liever voor mijn VM's en MySQL waar ik het harder nodig, danwel meer profijt van zal hebben dan voor backup- / sabnzbd faciliteiten.

[FireDrunk]

Een M500 is gespecced op 72TB written. Dat is 40GB per dag voor 5 jaar lang.

Dat halen de meeste mensen niet met SabNZBd.

[]Byte[]

FireDrunk schreef op maandag 07 april 2014 @ 15:28:
Een M500 is gespecced op 72TB written. Dat is 40GB per dag voor 5 jaar lang.

Dat halen de meeste mensen niet met SabNZBd.

Enig idee hoeveel je verstookt met met 1 DVD-tje lurken, uitpakken en als je geluk hebt ook nog repairen?
Ik ben het met je eens... sustained 40 GB/dag is heel veel voor de gemiddelde gebruiker...
Maar wel een puntje om toch even bij stil te staan.
_{* ]Byte[ is ook 'bovengemiddelde gebruiker'}

[ Voor 6% gewijzigd door ]Byte[ op 07-04-2014 17:52 ]

[MikeVM]

kan iemand me helpen met het automatisch downspinnen van mn HDD's op ZFSGuru, ik heb dat al enkele keren onderzocht, maar ik vind nergens een goede tutorial of guide die me daarbij helpt.

er zijn nog mensen hier in het topic die dat aangegeven hebben te willen toepassen, maar niet weten hoe.

[FireDrunk]

Zoek even op posts van mij.

[Dadona]

Ja, want daar zijn er zo weinig van...

Gaat het om een spindown van discs op de onboard, spindown van discs aan een m1015, welke versie van ZFSguru, ...?

[FireDrunk]

FireDrunk in "Het grote ZFS topic"

[MikeVM]

Spindown:

Verwijderd schreef op vrijdag 11 november 2011 @ 20:07:
Als je spindown wilt doen kun je beter geen Root-on-ZFS op je main pool doen nee. USB stick kan, maar dan moet je wel wat rommelen met de /var directory waar Samba veel kleine bestandjes naar schrijft zo heb ik gemerkt.

FireDrunk schreef op woensdag 14 november 2012 @ 16:01:
Voor de mensen met een M1015:

Prerequisite: ZFSguru / FreeBSD portstree (of de gewone ports tree gebruiken uiteraard...)

cd /usr/ports/sysutils/spindown
make && make install

nano /etc/rc.conf

#Enable Spindown
spindown_enable="YES"
spindown_flags="-b -d da0 -d da1 -d da2 -d da3 -d da4 -d da5 -d da6 -d da7 -t 300"

_{-b voor background, -d per device, -t voor timeout in seconden}

Onderaan toevoegen.

offtopic:
@CiPHER, misschien iets om automatisch te enablen als er da* devices gevonden worden?

Verwijderd schreef op maandag 29 juli 2013 @ 12:11:
In de nieuwe systeemversie van ZFSguru wordt spindown op een andere manier geregeld. Je kunt dat redelijk eenvoudig aanpassen met ee /etc/rc.conf

## ZFSguru autostart
zfsguru_enable="YES"
# APM or Advanced Power Management controls power saving features of your hard
# drives. To disable the dreaded 'headparking' feature, it is common to enable
# APM to a setting of 254, to disable headparking altogether.
zfsguru_apm_disks="ada1 ada2 ada3 ada4 ada5 ada6 ada7"
zfsguru_apm_level="254"
# To enable your disks to spindown whenever inactive for a number of seconds,
# configure both the timer (in seconds) and the disks you want to be spun down.
zfsguru_spindown_enable="YES"
zfsguru_spindown_timer="900"
zfsguru_spindown_disks="ada3 ada4 ada5 ada6 ada7"
# If you have a pool with L2ARC cache devices present, you might want to warm
# up the L2ARC right after boot with metadata. We can do that by scanning all
# directory layout which will cause metadata to be written to the L2ARC cache.
zfsguru_l2arc_warmup_enable="NO"

Ik wil de startpost eigenlijk redelijk OS agnostisch houden. Specifieke dingen voor BSD of Solaris horen er eigenlijk niet in vind ik. Wel kun je binnenkort een speciaal ZFS appliances topic verwachten. Bijvoorbeeld een topic voor ZFSguru/NAS4Free/FreeNAS en eentje voor Solaris+napp-it/Nexenta. Enzovoorts.

ZFSGURU : 0.2.0 Beta 9
FreeBSD: 9.2-001 featuring FreeBSD 9.2-RELEASE with ZFS v5000
M1015: 8 Disks
Onboard 2 Disks + SSD

verder staat er Sabnzbd, Sickbeard, Couchpotato, ..

ik heb vroeger eens geprobeerd om ze handmatig in sleepmodus te krijgen, dat lukte niet, nu lukt dat dus wel. wsl omdat ik al een tijdje niets op de server gedaan had. na 10 minuten (na handmatig spindown) komen ze allemaal vanzelf weer uit spindown. komt dat door Sabnzbd en toestanden?

in de toekomst wil ik ook nog een VM draaien, die meeste van de tijd inactief is. kunnen de disks dan ook in spindown?

[ Voor 12% gewijzigd door MikeVM op 07-04-2014 19:07 ]

[FireDrunk]

Nee, een VM genereerd teveel IO (zelfs als ie niets doet) om disks in spindown te laten gaan. Dat kan je beter op een SSD / USB stick doen.

[]Byte[]

Weet iemand toevallig hoe ik de /proc/diskstats in ZFSguru (terug?) kan krijgen?
Ik kan de /proc wel mounten, maar daarmee heb ik alleen de processen zichtbaar en niet de overige zaken als diskstats, cpuinfo, meminfo, etc.

[-Moondust-]

Maakt het voor ZFS in RAID-Z2 nog veel uit als van de 12 schijven er 8 op SAS2.0 (6Gb/sec) zitten en de overige 4 op SATA300?

[DXaroth]

-Moondust- schreef op dinsdag 08 april 2014 @ 19:58:
Maakt het voor ZFS in RAID-Z2 nog veel uit als van de 12 schijven er 8 op SAS2.0 (6Gb/sec) zitten en de overige 4 op SATA300?

ligt aan je schijven, maar als het allemaal grote schijven zijn, zou dat niet -al- te veel uit moeten maken... als het allemaal SSDs zijn, dan wellicht wel.

[FireDrunk]

Voor gewone schijven merk je het niet, voor SSD's maar sporadisch (zoals DXaroth al zegt)

[]Byte[]

Even een vraagje over de 'Synchronous Writes'
Er zijn 3 opties..
- Standard (default)
- All writes are synchronous writes (slow!)
- Disabled (no application consistency)

Nu zou ik hier alleen de opties 'yes' / 'no' of 'sync' / 'async' verwachten, maar 'Standard' brengt mij wat in verwarring.
Standard = sync writes? of is Standard een andere variant?

[FireDrunk]

Standard = als de applicatie sync writes vraagt krijgt hij ze.
Always = Alle writes worden als sync behandeld (ook waarvan de applicatie zegt dat ze niet sync hoeven te zijn).
Disabled = ZFS doet lekker wat ie zelf wil.

[]Byte[]

Oke.... Die variant had ik nog nooit van gehoord.

Maar hoe gaat dit dan met VM's die op iSCSI staan?
De OS-en in de VM's kletsen niet tegen ZFSguru aan... Moet je die dan hard op Allways zetten?

[FireDrunk]

Nope, het iSCSI protocol voorziet in SCSI Flush Cache commando's. Hierdoor kan ESXi (of beter gezegd, je iSCSI initiator) gewoon zeggen: "HEY, doe eens een cache flush!". Die gaat gewoon helemaal door je iSCSI stack heen, naar ZFS.

[hansdegit]

En als "ZFS doet wat -ie wil", hoe is dán het gedrag?
Reden van de vraag: ik heb hier een SLOG in mirror. Als mij dat ontslaat van de verplichting om sync writes te doen, kan dat wellicht wat snelheid opleveren.

[u_nix_we_all]

hansdegit schreef op woensdag 09 april 2014 @ 17:43:
En als "ZFS doet wat -ie wil", hoe is dán het gedrag?
Reden van de vraag: ik heb hier een SLOG in mirror. Als mij dat ontslaat van de verplichting om sync writes te doen, kan dat wellicht wat snelheid opleveren.

Als je geen synced writes doet helpt een SLOG toch niet, die is toch juist om snel (sneller dan je disks) een sync te kunnen geven.

En "doet wat -ie wil" , ik neem aan dat dat betekent: alles wordt gecached.

[Paul]

hansdegit schreef op woensdag 09 april 2014 @ 17:43:
En als "ZFS doet wat -ie wil", hoe is dán het gedrag?

Gewoon, doe wat upstream van je verwacht. Als er een write binnenkomt die niet aangemerkt is als synchroon dan behandel je die zoals alle asynchrone writes (naar open transaction group, na een tijdje de open group quiescen en syncen). Krijg je een write die wel synchroon moet dan quiesc en sync je de TXG zodra je de write ontvangen hebt, waarna je een ACK (of whatever) terugstuurt.

Reden van de vraag: ik heb hier een SLOG in mirror. Als mij dat ontslaat van de verplichting om sync writes te doen, kan dat wellicht wat snelheid opleveren.

Een SLOG gebruik je juist wanneer je (last van je) sync writes hebt. Je SLOG is bedoeld om synced writes te versnellen.

'ontslaat van de verplichting', wie verplicht je dat? Je kunt het uitzetten. Of je dat wilt is een tweede Als het puur om snelheid gaat en consistency minder belangrijk is dan kun je synced writes compleet uitzetten. Een SSD als SLOG is een goede tweede, en dat heb je dus al

[Verwijderd]

Wanneer ik een zfs filesystem wil aanmaken in linux moet ik dan de casesensitivity=mixed optie gebruiken wanneer ik dit filesystem via samba wil delen naar een Windows 8 client?

Deze guide zegt het volgende:

zfs create -o casesensitivity=mixed -o compression=lz4 officedata1/data1

I have enabled compression and also mixed case sensitivity support which is needed to correctly support Windows clients. Important: casesensitivity can only be set at fs creation time and cannot be changed later.

Klopt dit?

[-Moondust-]

Paul schreef op woensdag 09 april 2014 @ 18:03:
Een SLOG gebruik je juist wanneer je (last van je) sync writes hebt. Je SLOG is bedoeld om synced writes te versnellen.

Ik dacht dat de ZIL/SLOG alleen nodig is als de stroom uitvalt. Op de SLOG wordt alleen geschreven, niet gelezen. Er wordt niets versneld. Of heb ik het echt verkeerd begrepen?

[FireDrunk]

Ik zal een uitgebreide uitleg doen. Gun me even wat schrijftijd

[DXaroth]

-Moondust- schreef op woensdag 09 april 2014 @ 18:36:
[...]

Ik dacht dat de ZIL/SLOG alleen nodig is als de stroom uitvalt. Op de SLOG wordt alleen geschreven, niet gelezen. Er wordt niets versneld. Of heb ik het echt verkeerd begrepen?

Het concept is simpel:

normaal gebruik je SYNC writes; dwz dat je OS zegt : schrijf data X weg naar bestand Y op locatie Z.. je systeem gaat dat dan doen, en blokkeert het process totdat dit ook op disk staat.
Mocht stroom uitvallen, dan ben je uiteraard die data kwijt.

Nu heb je ook ASYNC writes, hierbij wordt het process niet onderbroken zodra het op disk staat, maar direct; in de tussentijd kan je applicatie verder zijn werk doen terwijl ZFS zijn zaken verder afhandelt.

Nu valt de stroom uit; bij sync writes valt te achterhalen precies welke data er mist; immers je process heeft niet 'meer' data kunnen schrijven... bij async writes, daarentegen, kan er een grote hoeveelheid data klaar staan om weggeschreven te worden, die allemaal is verdwenen.

Je ZIL device wordt gebruikt op een manier dat ZFS niet de write-intent-log bijhoudt in geheugen, maar op je ZIL device.. dwz dat je semi-sync draait. je ZIL is immers een supersnel device (althans, dat hoop ik), die een buffer bijhoudt wat er nog weggeschreven moet worden; zodra de langzame opslag disks dan eenmaal weer data weg kunnen zetten, wordt dat uit het buffer getrokken, en weggezet.. met als gevolg dat je applicatie denkt dat alle data netjes op disk staat, maar feitelijk staat het (tijdelijk) nog in je ZIL te wachten.

Mocht er nu een stroomstoring zijn, dan kan ZFS een replay uitvoeren van de ZIL, om zo de ontbrekende data (mits die uiteraard op de ZIL staan) toch weg te kunnen schrijven.

Dit is ook gelijk de reden waarom je een SSD wilt nemen met supercaps; elk opslagdevice heeft een interne buffer waar de acties die nog geschreven moeten worden worden bijgehouden, zo kan je alvast enkele MBs queuen voordat de hdd bijvoorbeeld op de juiste locatie is met zijn schrijfkop... het probleem hierbij is, dat zodra je hdd stroom verliest, dat die queue ook weg is. Supercaps worden gebruikt om nog lang genoeg de schijf 'actief' te houden (ook al is het systeem dat niet meer) om die buffers leeg te gooien naar disk (we hebben het hier nu over secondenwerk).

FireDrunk schreef op woensdag 09 april 2014 @ 18:51:
Ik zal een uitgebreide uitleg doen. Gun me even wat schrijftijd

te laat

[ Voor 4% gewijzigd door DXaroth op 09-04-2014 18:53 ]

[FireDrunk]

Bijna goed, alleen word er nooit van de zil gelezen, alleen na een power failure. Voor de rest word het gewone transactie schema aangehouden.

Zfs werkt transactioneel, writes worden opgespaard en in grote hoeveelheden geflusht.
Normaal word bij een synced write deze cycles geforceerd afgebroken. De synced write word toegevoegd aan de transactie en deze word geforceerd meteen weggeschreven naar de zil op disk. Bij een SLOG word de lopende transactie niet meer geforceerd geflusht maar gaat gewoon door alsof alle data in de transactie async was.

De applicatie krijgt (zodra de SLOG write gelukt is) een signaal dat zijn write geslaagd is, terwijl deze eigenlijk nog gewoon in de transactie zit welke later gewoon geflusht word.

Zodra deze transactie op disk staat, weet ZFS dus, ah, die ene write die op ZIL stond, kan ik nu vrijgeven. Op dat moment word dus ook de data van ZIL weer ongeldig gemaakt (deze staat immers op disk).

De data op de ZIL word dus alleen maar gelezen als een transactie afgebroken is. (Die controle is vrij simpel, je leest bij boot de ZIL, staat daar data in die nieuwer is dan de laatste keer dat het filesystem gewijzigd is, weet je: die data moet nog in een transactie gecommit worden).

[ Voor 37% gewijzigd door FireDrunk op 09-04-2014 19:16 ]

[hansdegit]

Dat lijkt op de manier waarop een net RDBMS het oplost. Alle transacties in je logfiles en wanneer je tijd hebt ga je je datafiles bijwerken. Zodra het in de log staat is je transactie gecommit. En dan is het logisch dat je het schrijven naar die log SYNC wilt uitvoeren.

Geinig. Sun heeft ZFS bedacht toch? Sun => Oracle ...Dan is het een klein bruggetje naar een net RDBMS.

[Verwijderd]

Misschien wat moeilijk om door de grote discussies hier heen te komen maar blijf het toch proberen.

Ik heb wat vragen i.v.m. partities en ZFS. Ik gebruik zfsonlinux met WD Green 4tb schijven.

Verwijderd schreef op vrijdag 23 maart 2012 @ 13:00:
Mijn advies: ALTIJD partities gebruiken en ruimte reserveren op het einde. Alignment start op 1MiB offset (2048 sector) en dan kun je ook gelijk een partitielabel geven.

mijn vragen:

• Aangeraden wordt om ruimte op het einde van je partities te reserveren. ZFSGuru geeft standaard 1 MiB maar hier spreekt men al van 200 MB. Hoeveel wordt aangeraden vrij te houden?
• Wanneer ik probeer te partitioneren met ZFSGuru maakt ie standaard altijd een freebsd-boot partitie aan vooraan de schijven. Is dat ook nodig voor zfsonlinux of is het beter handmatig te partitioneren met b.v. gdisk en geen boot partitie vooraan te voorzien?

Verder blijf ik nog altijd benieuwd naar het casesensitivity=mixed verhaal.

Alvast bedankt!

[Ultraman]

1 tot een paar MiB aan het einde is voldoende. Je laat die ruimte over om kleine verschillen tussen schijven van "dezelfde" capaciteit op te vangen. Bijv. een verschil van minder dan 1MiB tussen een 2TB disk van WD en een 2TB disk van Seagate, en kan zelfs voorkomen tussen schijven van dezelfde fabrikant.
Dit doe je zodat je niet ineens door een miniem ruimteverschil een defecte schijf niet kunt vervangen door een goede disk. Verschillen van 200MiB zijn hier bij niet aan de orde, tot een paar MiB kan voor komen.

[ Voor 9% gewijzigd door Ultraman op 09-04-2014 20:56 ]

[FireDrunk]

Ik geloof dat sinds 2TB schijven de fabrikanten hebben afgesproken dat de schijven dezelfde aantal sectoren hebben. Dacht ergens gelezen te hebben dat daar zelfs een ISO norm van gemaakt is... Maar goed, ik kan het mis hebben.

@Freddy500, die freebsd-boot partitie is niet nodig voor ZFSonLinux, je kan in ZFSguru ook zonder die partitie partitioneren, maar dan moet je het even met de hand doen, en niet via die standaard GPT label manier.

Let op dat booten van ZFS onder Linux heel anders gaat, mocht je dat willen raad ik je aan om even heel goed te kijken wat je gaat doen.

[ Voor 13% gewijzigd door FireDrunk op 09-04-2014 21:01 ]

[Verwijderd]

@FireDrunk: Neen ik wil gelukkig niet booten van zfs.

Heb gevonden hoe je in ZFSGuru handmatig kan partitioneren. Ik zag dat wanneer ik bij alignment 4k boundaries kies dat ie m dan op 40 sectors zet terwijl wanneer ik megabyte boundaries kies hij op 2048 sectors staat. Ik veronderstel dat die laatste correct is?

Moet ik het gpt-type op freebsd-zfs laten staan of wordt dat toch overgeschreven wanneer ik de zpool maak in linux?

En als laatste weet jij als lokale zfsonlinux guru iets van die casesensitivity=mixed instelling? Gebruik jij dat voor je filesystems of misschien heb jij geen windows clients?

Merci!

[FireDrunk]

freebsd-zfs gpt partitie type is inderdaad prima, dat werkt gewoon onder Linux. (heb 'm zelf ook )

Ik gebruik zelf geen case sensitivity. Het is icm Windows troep inderdaad wel lastig, maar je maakt niets kapot ofzo... Als je een directory 2 keer hebt met verschillende case (hoofdletters vs niet hoofdletters) levert Samba gewoon de eerste als je 1 van de twee aanklikt. Je merkt het snel genoeg.

Trek een putty sessie open, delete 1 van de directories et voila. Probleem opgelost.

Ik had er alleen nog maar sporadisch iets over gehoord, nooit gebruikt. Ook nooit behoefte aan gehad.

[Verwijderd]

Ik zie inderdaad dat wanneer ik twee folder onder linux maak, test en TEST dat ze het volgende gedrag vertonen:

Windows (samba client):

• delete een folder en ze verdwijnen allebei
• zet een bestand in 1 folder en het verschijnt in allebei
• het is niet mogelijk een test en TEST folder naast elkaar te creëren, dat kan alleen onder linux

Linux (server):

• folders kunnen apart gedelete worden
• bestanden verschijnen maar in 1 v/d 2 folders

Ik veronderstel dat samba dit doet?

Verder kan ik geen verschil vinden in het gedrag van de casesensitive=mixed en de standaard casesensitive=sensitive zfs instelling. Misschien maakt deze mixed instelling geen verschil wanneer je samba gebruikt omdat samba dit toch al oplost (en caseinsensitive maakt) onder Windows en dus effectief al een mixed systeem creëert? Zie ook hoe Oracle dit beschrijft:

The casesensitivity Property:

This property indicates whether the file name matching algorithm used by the file system should be casesensitive, caseinsensitive, or allow a combination of both styles of matching (mixed).

When a case-insensitive matching request is made of a mixed sensitivity file system, the behavior is generally the same as would be expected of a purely case-insensitive file system. The difference is that a mixed sensitivity file system might contain directories with multiple names that are unique from a case-sensitive perspective, but not unique from the case-insensitive perspective.

For example, a directory might contain files foo, Foo, and FOO. If a request is made to case-insensitively match any of the possible forms of foo, (for example foo, FOO, FoO, fOo, and so on) one of the three existing files is chosen as the match by the matching algorithm. Exactly which file the algorithm chooses as a match is not guaranteed, but what is guaranteed is that the same file is chosen as a match for any of the forms of foo. The file chosen as a case-insensitive match for foo, FOO, foO, Foo, and so on, is always the same, so long as the directory remains unchanged.

[FireDrunk]

Denk dat je hem caseinsensitive moet zetten. Als je dan een directorie Test aanmaakt en er bestaat al een test directory, gaat ie vast mekkeren.

Zeker weten doe ik het niet.

[Verwijderd]

Ja, als ik hem casesensitive=insensitive zet dan kan ik ook onder Linux geen test en TEST maken.

Nog altijd niet helemaal overtuigd van welke instelling te gebruiken. Ik denk gewoon standaard omdat met samba die mixed instelling toch niet veel lijkt uit te maken. De insensitive is misschien wel handig zodat je nooit per ongeluk case sensitive dingen aanmaakt onder Linux die je dan kunnen verwarren onder Windows maar die kans lijkt me toch klein gezien ik de share vanuit Windows zal gebruiken.

Misschien verhoogt het ook de compatibiliteit wanneer je casesensitive kan blijven gebruiken onder linux,bsd, etc. ?

[FireDrunk]

Mwoh, misschien, persoonlijk nooit last mee gehad, en ik heb al jaren geen Windows meer op mijn server.

[Phyt_]

Gister met Freenas en Nas4free aan het spelen geweest.
Maar ik wil eigenlijk ZFSguru nu gaan gebruiken en puur als NAS geen services of andere spullen zoals sabnzbd etc.
Nu heb ik de Live-Cd gedownload en gestart binnen mijn VM omgeving(passtrough lsi9211-8i in it mode met 5x3tb).
Uiteraard wil ik nu zfsguru installeren op de disk van 8gb,(staat op mijn SSD datastore).
Maar dit is niet zo makkelijk als het lijkt volgens mij?

zfsguru > system > Install > dan wil ik kiezen Embedded (not working yet) , maar zoals daar staat werkt dat niet?
Hoe kan ik nu Zfsguru dan installeren op de disk moet toch kunnen lijkt me?

[FireDrunk]

Je moet even een 1 disk pool aanmaken op die schijf.

[Phyt_]

uh ja had ik kunnen bedenken thanks
ga ik weer even verder sjouwen :d

-
Nog wat onduidelijkheden m.b.t. ZFS(guru).
Ik heb 5 disks van 3 tb. de seagate ST3000DM001
Wat ik heb gedaan is:
1) de Disks geformat volgens GPT.
2) De disks in een ZFS Pool gegooid : pool_1 met Raidz (Raid5 (single parity)
3) Bij Files>Filesystem een nieuw filesystem van Pool_1/share en gedeeld middels smb.
4) Compression & Deduplication staat uit.

Vragen/onduidelijkheden:

1) Ik kom er niet uit m.b.t de 4k ondersteuning, bij disk in de Webgui, zie ik sector :512B
Ook lees ik op internet dat je het beste 4K wel aan kan zetten mocht je gaan vervangen naar 4k disks, aangezien dit niet achteraf aangepast kan worden.

[root@zfsguru /home/ssh]# camcontrol identify da2
sector size logical 512, physical 4096, offset 0
Ik heb wel 4k aangevinkt daarom zie ik dit denk ik ook ?
[root@zfsguru /home/ssh]# zdb -C pool_1 | grep ashift
ashift: 12

2) Ik mis wel aardig wat diskruimte de disk worden gezien als 2.7 TiB (size binary) dus dat is 5x300gb = 1.5 tb die ik mis. Boven op de parity raidz1 overhead.
Komt dit door bovenstaande ivm 512b / 4k verhaal?

3) Spindown / APM (Webgui Disks>Advanced)
De Advanced Power Management (APM) staat nu op 128, Maximum power savings without spindown.
Ik krijg deze niet op 1 Maximum powersavings with spindown, of op een andere setting.
resulteerd in error: Warning: failed changing APM setting for disk da1.

Mijn doel is om de 5 disks in spindown te laten gaan na X tijd ongebruikt. moet dit dan op een andere manier?

Heel verhaal geworden, er staat nog geen data op de shares dus kunnen ook opnieuw aangemaakt worden als het moet.

[ Voor 91% gewijzigd door Phyt_ op 10-04-2014 20:53 ]

[Verwijderd]

De disks hoef je niets met sector size te doen. Enige wat je moet doen is je pool 4K optimized maken. Als je naar de Pools pagina gaat en je klikt op een pool, dan zie je dan in het midden iets van 'This pool is optimized for 4K sector disks' - dan weet je dat het goed zit. Op de disks pagina zullen je disks echter nog steeds 512 bytes aangeven. Dat klopt ook, omdat de huidige Advanced Format hardeschijven een sector size van 512 bytes doorgeven, om compatible te blijven met oude besturingssystemen. Native 4K schijven heb je nauwelijks.

APM wordt niet altijd ondersteund. Je kunt 'spindown' utility gebruiken. FireDrunk had daar een dag of wat geleden nog een post over, of hier of in het DIY RAID NAS topic.

[ Voor 13% gewijzigd door Verwijderd op 10-04-2014 21:57 ]

[Phyt_]

@Cipher bedankt, dan ga ik op zoek naar die utility.
Moet zeggen het word allemaal wat duidelijker langzaam aan, moest wel ff wennen aan de webinterface, beetje jaren 90 .
Maar alles werkt naar behoren en met een paar muisklikken, (vast ip instellingen ging wat moeilijker maar dat komt er aan las ik.)
Ik draai nu :
Powered by ZFSguru version 0.2.0-beta9
Running official system image 10.0-002 featuring FreeBSD 10.0-RELEASE with ZFS v5000.
website:version: 0.2.0-beta9

Dan ga ik al mijn data verplaatsen, hopen dat ik alles nog van defecte disk ga krijgen .

Edit- niet echt iets kunnen vinden voor de spindown.

offtopic, maar hoop dat iemand het weet.
edit-- reinstall gedaan en even data pool import en klaar .

[ Voor 72% gewijzigd door Phyt_ op 11-04-2014 10:52 ]

[Q]

Op mijn download server draai ik al een tijdje ZoL. Deze week zag ik super slechte performance can mijn NAS. Het bleek dat 1 disk op 99% usage stond bij disk access en extreem slechte latency.

Defecte disk zou je zegen. Zou heel goed kunnen. Na een reboot bleef dit probleem.

Nadat ik de disk echter uit de vdev heb gehaald en er weer in heb gestopt - en de pool prima resilverde - was er niets meer aan de hand. Dus in hoeverre dit nu hardware was... Smart is clean, disk werkte prima in mijn mac met full format.

Time will tell. Maar de problemen zijn nu over.

[ Voor 5% gewijzigd door Q op 11-04-2014 08:56 ]

[Habana]

Verwijderd schreef op donderdag 10 april 2014 @ 21:57:

APM wordt niet altijd ondersteund. Je kunt 'spindown' utility gebruiken. FireDrunk had daar een dag of wat geleden nog een post over, of hier of in het DIY RAID NAS topic.

Waarom zit zoiets basics als spindown niet standard in ZFSguru geregeld, het is mij ook nog steeds niet helemaal duidelijk, van wat heb ik nodig en wat moet ik doen, een goede uitleg hierover zou wel eens welkom zijn, en via de webpage kunnen instellen nog meer.

Probeer er nu niet iets negatiefs van temaken Q, daar is ZFSguru te leuk voor, maar ik begrijp je humoristische insteek wel , maar dit behoord toch in basis te zijn te geregeld voor die groep gebruikers waarvoor ZFSguru oa. voor bedoelt is, nl die mensen die niet die kennis hebben zoals jij en anderen, de vraag word anders regelmatig gesteld.

[ Voor 24% gewijzigd door Habana op 11-04-2014 23:44 ]

[Q]

Tja CiPHER, je geeft ze een vinger en ze grijpen je hele hand

[HyperBart]

Q schreef op vrijdag 11 april 2014 @ 08:56:
Op mijn download server draai ik al een tijdje ZoL. Deze week zag ik super slechte performance can mijn NAS. Het bleek dat 1 disk op 99% usage stond bij disk access en extreem slechte latency.

Defecte disk zou je zegen. Zou heel goed kunnen. Na een reboot bleef dit probleem.

Nadat ik de disk echter uit de vdev heb gehaald en er weer in heb gestopt - en de pool prima resilverde - was er niets meer aan de hand. Dus in hoeverre dit nu hardware was... Smart is clean, disk werkte prima in mijn mac met full format.

Time will tell. Maar de problemen zijn nu over.

Kan je voor de lol eens voor mij een scrub draaien?

Ik zit nu al een tijdje op ZoL Ubuntu en die scrub snelheden van mij blijven redelijk belabberd:

  pool: juggernaut
 state: ONLINE
  scan: scrub in progress since Sat Apr 12 18:56:40 2014
    203G scanned out of 13.0T at 84.6M/s, 44h9m to go
    0 repaired, 1.52% done
config:

        NAME                 STATE     READ WRITE CKSUM
        juggernaut           ONLINE       0     0     0
          raidz1-0           ONLINE       0     0     0
            disk1-Z300VZN9   ONLINE       0     0     0
            disk5-Z300TQ64   ONLINE       0     0     0
            disk2-Z300VYDE   ONLINE       0     0     0
            disk3-Z300VYAW   ONLINE       0     0     0
            disk4-Z300VXRL   ONLINE       0     0     0
        cache
          PART-EVO250-L2ARC  ONLINE       0     0     0

Waar ik vroeger makkelijk richting de 400 tot 600MB/s ging haal ik nu maar fixed iets van 84.6MB/s, en dat vind ik wel HEEL weinig.

[Q]

code:

root@server:~# zpool status
  pool: server
 state: ONLINE
  scan: scrub in progress since Sat Apr 12 23:41:21 2014
    7.10G scanned out of 5.58T at 291M/s, 5h34m to go
    0 repaired, 0.12% done

Lijkt ok?

[]Byte[]

Dat weet je pas zeker als ie 100% klaar is.

[Quindor]

code:

  pool: RAIDz1-4TB
 state: ONLINE
  scan: scrub in progress since Mon Apr 14 14:33:28 2014
    189G scanned out of 10.4T at 400M/s, 7h26m to go
    0 repaired, 1.77% done
config:

        NAME                                                   STATE     READ WRITE CKSUM
        RAIDz1-4TB                                             ONLINE       0     0     0
          raidz1-0                                             ONLINE       0     0     0
            ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0222324           ONLINE       0     0     0
            ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0229985           ONLINE       0     0     0
            ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0227171           ONLINE       0     0     0
            ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0255219           ONLINE       0     0     0
            ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0250312           ONLINE       0     0     0
        logs
          ata-OCZ-VERTEX2_OCZ-OW3UJ940SP7F1601-part4           ONLINE       0     0     0
          ata-Samsung_SSD_840_EVO_250GB_S1DBNSADC29934T-part2  ONLINE       0     0     0
          ata-Samsung_SSD_840_EVO_250GB_S1DBNSADC25371X-part4  ONLINE       0     0     0
          ata-Samsung_SSD_840_EVO_250GB_S1DBNSADC29936M-part2  ONLINE       0     0     0
        cache
          L2ARC-4TB_1                                          UNAVAIL      0     0     0
          L2ARC-4TB_2                                          UNAVAIL      0     0     0
          ata-OCZ-VERTEX2_OCZ-OW3UJ940SP7F1601-part6           ONLINE       0     0     0
          ata-Samsung_SSD_840_EVO_250GB_S1DBNSADC25371X-part6  ONLINE       0     0     0
          ata-Samsung_SSD_840_EVO_250GB_S1DBNSADC29934T-part4  ONLINE       0     0     0
          ata-Samsung_SSD_840_EVO_250GB_S1DBNSADC29936M-part4  ONLINE       0     0     0

Hier lijkt ook alles prima. Dit is na 35 dagen uptime.
Ubuntu 13.10 met ZoL.

update--
scan: scrub in progress since Mon Apr 14 14:33:28 2014
8.97T scanned out of 10.4T at 439M/s, 0h56m to go
0 repaired, 86.26% done

[ Voor 3% gewijzigd door Quindor op 14-04-2014 20:31 ]

[]Byte[]

Prima???

cache
L2ARC-4TB_1 UNAVAIL 0 0 0
L2ARC-4TB_2 UNAVAIL 0 0 0

[Verwijderd]

Sowieso niet prima. Hij gebruikt zowel OCZ als Samsung als sLOG, hetgeen zeer gevaarlijk is. In feite draait hij nu met ZIL uitgeschakeld. Ik kan dat alleen maar sterk afraden.

[Quindor]

]Byte\[ schreef op maandag 14 april 2014 @ 14:59:
Prima???

[...]

Ah, dat had ik eerder in het topic al eens besproken. Ik ben van FreeBSD naar Ubuntu gemigreerd, helaas is het daarna vanwege een bug in ZoL onmogelijk om deze 2 L2ARC verwijzingen te verwijderen.

Ze zijn gelukkig alleen cosmetisch nog aanwezig en op geen enkele andere manier terug te vinden. En veroorzaken daardoor ook geen problemen.

Verwijderd schreef op maandag 14 april 2014 @ 15:54:
Sowieso niet prima. Hij gebruikt zowel OCZ als Samsung als sLOG, hetgeen zeer gevaarlijk is. In feite draait hij nu met ZIL uitgeschakeld. Ik kan dat alleen maar sterk afraden.

Ik snap dat dit geen Enterprise waardige configuratie is. Ik ben vooral met logs (ZIL) aan het testen geweest.

Verder is het volgens mij zo dat als het systeem gewoon normaal draait dat de ZIL voor sync writes gevuld word maar in principe alles rechtstreeks naar de disks laat gaan (op memory na). Mocht er inderdaad iets uitvallen of wat anders mis gaan dan kan het zijn dat het systeem terug leest wat er in de ZIL staat om de laatste status te kunnen herstellen. Als dat niet het geval is dan zou ik maximaal 5 seconden terug in de tijd gaan heb ik begrepen. De kans op corruptie is daarbij zeer klein en kan eventueel een openstaande file treffen die op dat moment open stond EN aan het schrijven was.

Mocht bovenstaande kloppen, dan accepteer ik dat willend en wetende. Het is zeker niet erger dan een standaard file systeem met caches, etc. zoals bijvoorbeeld windows.

[ Voor 56% gewijzigd door Quindor op 14-04-2014 16:45 ]

[]Byte[]

Verwijderd schreef op maandag 14 april 2014 @ 15:54:
Sowieso niet prima. Hij gebruikt zowel OCZ als Samsung als sLOG, hetgeen zeer gevaarlijk is.[...]

Ligt dat aan de OCZ, Samsung EVO's of de combinatie van die twee?

[Q]

]Byte\[ schreef op zondag 13 april 2014 @ 20:50:
Dat weet je pas zeker als ie 100% klaar is.

scan: scrub repaired 0 in 12h56m with 0 errors on Sun Apr 13 12:37:22 2014

[MdBruin]

Habana schreef op vrijdag 11 april 2014 @ 13:50:
[...]


Waarom zit zoiets basics als spindown niet standard in ZFSguru geregeld, het is mij ook nog steeds niet helemaal duidelijk, van wat heb ik nodig en wat moet ik doen, een goede uitleg hierover zou wel eens welkom zijn, en via de webpage kunnen instellen nog meer.
.....

Stond 1 pagina terug

FireDrunk schreef op maandag 07 april 2014 @ 18:40:
FireDrunk in "Het grote ZFS topic"

Moet er wel bij zeggen dat ik er ook zelf een tijd naar heb lopen zoeken maar heb daardoor al een eerder post van FireDrunk kunnen gebruiken
Dit kan je ook gebruiken voor de freeBSD 9 variant (ZFSGuru 9.2) om spindown te installeren:

pkg_add -r spindown

Voor 10 (ZFSGuru 10.x-00x) (was bij mij al geïnstalleerd) en 11 (ZFSGuru 11.0-001)

pkg install spindown

[ Voor 2% gewijzigd door MdBruin op 14-04-2014 22:37 . Reden: ZFSGuru versienummers vermeld ]

[]Byte[]

Q schreef op maandag 14 april 2014 @ 22:24:
[...]
scan: scrub repaired 0 in 12h56m with 0 errors on Sun Apr 13 12:37:22 2014

Nu weet je zeker dat het goed is... :-)
Ik heb zelf in het begin het probleem gehad van een brakke disk die nog geen 1,5 maand oud was.
Kwam ik ook pas achter na een scrub.
Als ik 3 keer per dag een scrub draaide, had ie altijd wel repairs voor zijn kiezen.
Sinds ik die disk heb vervangen heb ik nooit meer problemen gehad.
Aan de andere kant, sindsdien heb ik ook de spindown uitgeschakeld.
Of het echt de oorzaak was van de spindown.... Ik durf het niet te zeggen.
Maar de 9 disken hebben nu een 'Load cycles' van rond de 4500 en die ene nieuwe disk 0.
Misschien was die disk echt 'rot' maar de spindown... Ik gebruik 'm ff voorlopig niet.

[]Byte[]

Heeft iemand toevallig ervaring met het monitoren via IPMI?
Ik heb een Supermicro bord waar ook IPMI op zit en zou dit ook graag willen monitoren (Zabbix)
Zit (Open)IPMI uberhaupt in ZFSguru?
Ik kan er bijzonder weinig info over vinden icm ZFSguru.

[HyperBart]

Ik draai al een tijdje fysiek op volgende setup Ubuntu met ZoL:

#	Product	Prijs	Subtotaal
1	Samsung 840 EVO 250GB	€ 118,99	€ 118,99
1	Samsung 840 EVO 500GB	€ 204,99	€ 204,99
1	Crucial 2.5" M500 120GB	€ 56,30	€ 56,30
5	Seagate Desktop HDD.15 (OEM), 4TB	€ 128,01	€ 640,05
1	IBM ServeRAID M1015 SAS/SATA Controller for System x	€ 135,59	€ 135,59
2	Kingston KVR1333D3E9SK2/16G	€ 142,20	€ 284,40
1	APC Back-UPS Pro 550 VA	€ 118,12	€ 118,12
1	be quiet! Pure Power L7 300W	€ 51,-	€ 51,-
1	Supermicro X9SCA-F	€ 172,93	€ 172,93
4	Crucial m4 CT128M4SSD2 128GB	€ 124,95	€ 499,80
2	3Ware 3Ware Multi-lane SATA cable CBL-SFF8087OCF-05M	€ 12,75	€ 25,50
1	Intel Xeon E3-1230 Boxed	€ 273,46	€ 273,46
1	Antec New Solution VSK-2000-EC	€ 0,-	€ 0,-
Bekijk collectie Importeer producten		Totaal	€ 2.581,13

Op zich gaat het allemaal prima, maar ik heb nu al voor de tweede keer aan de hand dat de server na een nachtje vol in de downloads te gaan, hij opeens gigantisch begint te swappen en alles heel traag wordt.

top geeft het volgende:

top - 10:50:12 up 29 days, 15:57,  1 user,  load average: 4.43, 2.40, 1.01
Tasks: 566 total,   2 running, 564 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us, 12.7 sy,  0.0 ni, 71.3 id, 15.8 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem:  32921192 total, 32696500 used,   224692 free,     4252 buffers
KiB Swap:  4882428 total,   494216 used,  4388212 free,     8560 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
   77 root      20   0     0    0    0 R 200.5  0.0 113:51.85 kswapd0
16497 root      20   0 2417m  41m 2132 S   5.2  0.1   2:11.19 sabnzbdplus
 7091 root      20   0 1608m 1664 1480 S   2.3  0.0   7:18.09 python
16561 root      20   0 20916  860  496 R   2.3  0.0   0:01.14 top
   17 root      20   0     0    0    0 S   0.3  0.0   9:22.41 rcu_sched
   18 root      20   0     0    0    0 S   0.3  0.0   1:29.88 rcuos/0
 3609 root       0 -20     0    0    0 S   0.3  0.0  33:57.08 l2arc_feed
 4389 root      39  19     0    0    0 S   0.3  0.0   5:36.06 z_wr_iss/7
29610 root      20   0  100m  100  100 S   0.3  0.0   0:19.55 apcupsd
    1 root      20   0 28004    0    0 S   0.0  0.0   0:01.97 init
    2 root      20   0     0    0    0 S   0.0  0.0   0:00.35 kthreadd
    3 root      20   0     0    0    0 S   0.0  0.0   2:09.65 ksoftirqd/0
    4 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0
    5 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0H
    7 root      rt   0     0    0    0 S   0.0  0.0   0:24.95 migration/0
    8 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcu_bh
    9 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/0
   10 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/1
   11 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/2
   12 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/3
   13 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/4
   14 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/5
   15 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/6
   16 root      20   0     0    0    0 S   0.0  0.0   0:00.00 rcuob/7
   19 root      20   0     0    0    0 S   0.0  0.0   0:56.80 rcuos/1
   20 root      20   0     0    0    0 S   0.0  0.0   0:52.88 rcuos/2
   21 root      20   0     0    0    0 S   0.0  0.0   0:47.11 rcuos/3
   22 root      20   0     0    0    0 S   0.0  0.0   0:19.91 rcuos/4
   23 root      20   0     0    0    0 S   0.0  0.0   0:16.33 rcuos/5
   24 root      20   0     0    0    0 S   0.0  0.0   0:16.71 rcuos/6
   25 root      20   0     0    0    0 S   0.0  0.0   1:38.37 rcuos/7
   26 root      rt   0     0    0    0 S   0.0  0.0   0:07.94 watchdog/0
   27 root      rt   0     0    0    0 S   0.0  0.0   0:07.78 watchdog/1
   28 root      rt   0     0    0    0 S   0.0  0.0   0:33.09 migration/1
   29 root      20   0     0    0    0 S   0.0  0.0   3:00.58 ksoftirqd/1
   30 root      20   0     0    0    0 S   0.0  0.0   6:13.43 kworker/1:0
   31 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/1:0H
   32 root      rt   0     0    0    0 S   0.0  0.0   0:06.88 watchdog/2
   33 root      rt   0     0    0    0 S   0.0  0.0   0:34.69 migration/2
   34 root      20   0     0    0    0 S   0.0  0.0   0:30.55 ksoftirqd/2
   36 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/2:0H
   37 root      rt   0     0    0    0 S   0.0  0.0   0:06.88 watchdog/3
   38 root      rt   0     0    0    0 S   0.0  0.0   0:22.63 migration/3
   39 root      20   0     0    0    0 S   0.0  0.0   0:34.91 ksoftirqd/3
   40 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kworker/3:0
   41 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/3:0H
   42 root      rt   0     0    0    0 S   0.0  0.0   0:06.56 watchdog/4
   43 root      rt   0     0    0    0 S   0.0  0.0   0:04.75 migration/4
   44 root      20   0     0    0    0 S   0.0  0.0   0:02.10 ksoftirqd/4
   45 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kworker/4:0
   46 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/4:0H
   47 root      rt   0     0    0    0 S   0.0  0.0   0:06.92 watchdog/5
   48 root      rt   0     0    0    0 S   0.0  0.0   0:05.74 migration/5
   49 root      20   0     0    0    0 S   0.0  0.0   0:00.29 ksoftirqd/5

En daaruit concludeer ik dat het bakje het wel redelijk druk heeft qua geheugen. Bijzonder, als je denkt dat ik 32GB heb waarvan ik 20GB voor ARC gebruik en de rest in principe voor het OS.

Ondertussen (sinds de vorige keer) heb ik in Sabnzbd ook al de article cache gelimiteerd, maar dat biedt blijkbaar ook geen soelaas.

Iemand enig idee? Toen ik virtueel draaide met een VM met 2 vCPU's en 2GB vRAM botste ik nooit tegen dit probleem aan...

Ter info: dezelfde fysieke setup heb ik voor het volgende ook al eens gebruikt, toen geen problemen:

ESXi met een VM er op die FreeBSD draaide en als NAS diende voor een andere VM waar Sabnzbd downloadde: geen probleem
Freebsd native op de hardware, draaide als NAS en diende voor een VM op andere hardware waar Sabnzbd op draaide: geen probleem
FreeBSD native op de hardware met Sabnzbd geïnstalleed op diezelfde installatie: geen probleem

[]Byte[]

Kan het zijn dat de drukte die jij ervaart misschien samenloopt met tijdens het uitpakken of par2-repair van sabnzbd?
Vooral de rapair lurkt redelijk aan je systeem.
Ik zal ook eens een berg downloads aan de gang gooien en kijken wat ie bij mij gaan doen (met 64 GB)
Ik draai mijn huidige sabnzbd nog steeds op mijn QNAP met 1 GB - en die overleeft het ook nog steeds.
Over hoeveel download heb jij het ongeveer?
Maar die 200% load op je kswapd afgezet tegen de 490MB die je gebruikt... Nee, die kan ik ook even niet rijmen.

[HyperBart]

Ik had ongeveer als ik het goed herinner iets van 300GB klaar staan in mijn queue, verdeeld over like een kleine 100 downloads ofzo denk ik?

[syl765]

@hyperbart.

Je kan de volgende patch eens proberen als je onder FreeBSD werkt.
http://www.freebsd.org/cg...cgi?pr=kern%2F187594&cat=

[HyperBart]

Vergeten te vermelden, stom! Het is een Ubuntu met ZoL en het zijn 190 downloads

[ Voor 19% gewijzigd door HyperBart op 15-04-2014 12:39 ]

[]Byte[]

HyperBart schreef op dinsdag 15 april 2014 @ 11:28:
Ik had ongeveer als ik het goed herinner iets van 300GB klaar staan in mijn queue, [...]

Okay... dan moet ik wel heel veel bij elkaar gaan verzamelen...

Het is een Ubuntu met ZoL

Ik zal het evengoed eens proberen om te zien wat ZFSguru ermee gaat doen.

Ik heb even geen Ubuntu operationeel draaien binnen handbereik, maar het volgende werkt ook onder Linux:

grep --color VmSwap /proc/*/status

Dan krijg je een overzicht van de process-id's die swap gebruik(t)en...
Met de pid kan je weer zien welk proces het is.

Misschien dat dit je iets verder helpt...

[HyperBart]

Fuuuuuu, die komt net iets te laat

Ik had per se een aantal dingen nodig voor een kennis in het ziekenhuis dus ik heb de server even een shot gegeven.

FYI het zijn 190 downloads die nu staan te ratelen.

]Byte\[ schreef op dinsdag 15 april 2014 @ 12:35:
[...]


Okay... dan moet ik wel heel veel bij elkaar gaan verzamelen...

Gewoon 2 series volledig proberen binnen te hengelen, kom je zo aan hoor

[ Voor 39% gewijzigd door HyperBart op 15-04-2014 12:47 ]

[]Byte[]

Geeft niets...
Die swap zal ongetwijfeld toch wel weer oplopen.
Mocht ie weer zo baggertraag worden kan je het altijd nog eens uitvoeren.

Output zal er dan ongeveer zo uit kunnen zien:

/proc/1508/status:VmSwap:	       0 kB
/proc/1510/status:VmSwap:	       0 kB
/proc/1514/status:VmSwap:	       0 kB
/proc/1518/status:VmSwap:	       0 kB
/proc/1/status:VmSwap:	      20 kB
/proc/24005/status:VmSwap:	     140 kB
/proc/24006/status:VmSwap:	     308 kB
/proc/24101/status:VmSwap:	       0 kB
/proc/24738/status:VmSwap:	       0 kB
/proc/24763/status:VmSwap:	       0 kB
/proc/24767/status:VmSwap:	       0 kB
/proc/383/status:VmSwap:	     312 kB
/proc/self/status:VmSwap:	       0 kB

[ Voor 67% gewijzigd door ]Byte[ op 15-04-2014 13:04 ]

[HyperBart]

Strak plan, dat wou ik nog even te weten komen, hoe je nakijkt wat swap aan het gebruiken is.

Op zo een momenten mis je dus wel PowerShell eigenlijk... Als je nu PowerShell alike had op UNIX dan kon je gewoon lekker het object wat je hiermee opvraagt doorgeven aan top ofzo, en op basis daarvan ineens netjes de naam laten outputten...

* HyperBart droomt rustig verder

[Q]

Gadverdamme:

code:

IFS=$'\n'
for x in `grep --color VmSwap /proc/*/status`; do echo "-------------"; proc=`echo $x | cut -d "/" -f 3`; echo $x; ps x | grep -i -w $proc | grep -v grep ; done;

Ik snap je voorkeur voor powershell maar ik kan ook niet goed shell programmeren scripten

[ Voor 21% gewijzigd door Q op 15-04-2014 18:07 ]

[]Byte[]

Ik ook niet...

[Verwijderd]

Quindor schreef op maandag 14 april 2014 @ 16:25:
Verder is het volgens mij zo dat als het systeem gewoon normaal draait dat de ZIL voor sync writes gevuld word maar in principe alles rechtstreeks naar de disks laat gaan (op memory na). Mocht er inderdaad iets uitvallen of wat anders mis gaan dan kan het zijn dat het systeem terug leest wat er in de ZIL staat om de laatste status te kunnen herstellen. Als dat niet het geval is dan zou ik maximaal 5 seconden terug in de tijd gaan heb ik begrepen. De kans op corruptie is daarbij zeer klein en kan eventueel een openstaande file treffen die op dat moment open stond EN aan het schrijven was.

Twee dingen goed begrijpen:

• Je hebt consistency van je ZFS filesystem, en je hebt consistency van je client-side filesystem, zoals NTFS of Ext4. Je kunt een situatie hebben dat ZFS prima intact is, maar je client filesystem corruptie vertoont. Dit is echter alleen het geval als je een client filesystem draait. Denk aan: iSCSI volume, ATA-over-Ethernet maar ook simpeler: Virtualbox virtual disk images waarin een client filesystem draait.
• Als je ZIL niet de meest recente data 'onthoudt' dan heeft het geen zin. Een SSD zoals Samsung die een oudere mapping table van een aantal transacties terug herstelt, zal waarschijnlijk geen waarde hebben als sLOG device. sLOG = separate log. Bij gebruik van deze feature verplaatst de ZIL zich van de HDD pool (RAID-Z whatever) naar de SSDs die je als sLOG hebt geconfigureerd. Kortom, je verliest de bescherming op de HDDs - die schakel je hiermee uit. Dat is ook de hele reden dat het snelheidswinst oplevert.

ZFS kan zonder ZIL overleven; dan ga je iets terug in de tijd. Althans, dat kan sinds versie 19 uit mijn hoofd. Tegenwoordig zitten we op 5000.

Maar je data kan niet altijd zonder ZIL. Als je ESXi gebruikt, als je iSCSI gebruikt, als je belangrijke virtual machines op ZFS opslaat, etc. Je data loopt gevaar zonder ZIL. Dat hoeft niet altijd heel kritiek te wezen; je ziet dan zoiets als 'this filesystem need to be checked for consistency' of misschien dat het tegenwoordig allemaal achter de splashscreen draait, ik heb geen idee.

Maar wees dus voorzichtig met zulk soort configs. Ik denk eigenlijk beter dat je je sLOG disks kunt verwijderen (detachen) en de filesystems op sync=disabled instellen. Dan bereik je ook hetzelfde effect. Als je iSCSI gebruikt of een filesystem waar virtual machine images op staan, dan stel je deze filesystems/volumes specifiek in als sync=always (async=sync) of sync=standard (sync=sync).

]Byte\[ schreef op maandag 14 april 2014 @ 20:39:
Ligt dat aan de OCZ, Samsung EVO's of de combinatie van die twee?

Samsung gebruikt onveilige write-back en doet mapping table journal rollback; ik twijfel bijzonder aan het vermogen van Samsung om recente data te blijven tonen na een unexpected power-loss, wat vrij vaak gebeurt. Veel vaker dan echte power failures waar iedereen het over heeft. Ook met UPS heb je nog steeds unexpected power-loss. Denk aan de reset van in je BIOS gaan. Of in RAID BIOS dingen, of zelf een keer power button of reset tijdens POST. Het feit dat SSDs ook dingen 'op de achtergrond' doen maakt het allemaal niet fijner op.

Ik blijf dus liever bij Intel (het allerbeste; 320/S3500/3700) of als budget keuze Crucial (M500) lekker goedkoop per GB en goede performance specs. Je SSD moet capacitors hebben voor sLOG; en zelfs dat is eigenlijk niet voldoende. Zo heeft de M500 niet voldoende vermogen in de capacitors. En inderdaad, ze zijn erg klein, kijk maar... dat is de reden dat velen zeiden dat de M500 geen capacitors had . Maargoed M500 heeft genoeg power om het een fractie van een seconde uit te houden en daarin moet de lopende writecycle netjes voltooid worden. En dan poef, alles in DRAM is weg. Crucial M500 bewaart 4MiB of 6MiB (weet ik niet meer) in de DRAM aan write-back. Maar - zo is mijn stellige vermoeden - ik denk wel dat Crucial zich aan FLUSH CACHE commando's houdt - iets wat Samsung niet doet. In dit geval zal er bij de M500 bij gebruik als sLOG device altijd maar één write request (en één flush request) in de queue staan. Als dat klopt dan lijkt me dit ook zeer geschikt als sLOG. Maar bij Intel 320 weet je het zeker. Die kan de interne SRAM buffercache helemaal wegschrijven en doet zeker aan flush commando's. Nog steeds de beste keus voor het serieuze werk.

[Verwijderd]

Habana schreef op vrijdag 11 april 2014 @ 13:50:
Waarom zit zoiets basics als spindown niet standard in ZFSguru geregeld

APM (Advanced Power Management) en directe spindown zit in ZFSguru, Disks->Advanced.

Spindown met inactivity timer zit niet in ZFSguru, omdat het ook niet (goed) in FreeBSD zit. Bovendien is het elke keer gewijzigd en werkte het niet zoals in de manpage beschreven stond. Nu is het nog steeds zo dat een addon utility ('spindown') nodig is voor goede normale spindown. Dit behoort natuurlijk geïntegreerd in het OS te zitten. Waarom dat allemaal zo lastig is, snap ik ook niet helemaal.

Een web-interface voor 'spindown' is er nog niet, maar in recente systeemversies is deze utility al wel standaard geïnstalleerd. Je moet het alleen nog zelf configureren, wat zeer eenvoudig is. Je hebt wel gelijk dat deze informatie slecht te vinden is. Maar daar heb je het forum voor.

Q schreef op vrijdag 11 april 2014 @ 15:46:
Tja CiPHER, je geeft ze een vinger en ze grijpen je hele hand

Ja ik ken het... CiPHER mag altijd weer opdraven. En het valt ook gelijk op als ik niet snel reageer. Nou wen er maar aan dat dat voortaan iets langer kan duren. Ik krijg het de laatste tijd steeds drukker.

[]Byte[]

Verwijderd schreef op dinsdag 15 april 2014 @ 21:44:
[...]
Ja ik ken het... CiPHER mag altijd weer opdraven.

Tja... Dat is het grote probleem als je alleen bent voor een dergelijk project...
Maar heb je al je gedachten eens laten gaan over een workshop ZFSguru?
Ik meld mij hoe dan ook al vast aan!

[HyperBart]

Vandaag was het weer zo ver. Server hangt compleet, maar nu wordt het wel heel bizar. Ik heb even via IPMI op de remote console aangemeld (ja ja, via de Mac van mijn vrouw, schiet me later maar af FireDrunk)




Server reageert nergens meer op, helemaal onresponsief, paar keer enter rammen doet niks. SSh er naar toe = "host is down".

[ Voor 24% gewijzigd door HyperBart op 16-04-2014 12:49 ]

[Verwijderd]

Foutmeldingen lijken me aardig descriptief.