Even niets...
Zijn de RED's een beetje te draaien met een 512 blocksize? Dat kan ik nog wel even proberen en natuurlijk ga ik de pool ook nog even weer afbreken en naar 6 schijven RZ2 brengen om te kijken wat dat oplevert.
zpool list geeft de ruwe ruimte weer. Bij RAID-Z2 is dat dus inclusief de pariteit. Ook de gebruikte ruimte is dus inclusief pariteit.
zfs list geeft de bruikbare ruimte weer. Dat is exclusief overhead, exclusief pariteit.
19T betekent 19TiB en dat lijkt me correct voor 7x 3TB in RAID-Z2. 21TB ~= 19TiB. Effectief kun je gebruiken: 5x3TB= 15TB = 13,64TiB. Wat klopt er niet volgens jou? Misschien dat je het nog even op een rijtje kunt zetten want met je verschillende posts raak ik een beetje in de war.
Edit: ah je bent met ashift aan het spelen. En je test hoeveel ruimte je kwijt bent met een dergelijke niet-optimale config. I see.
[ Voor 10% gewijzigd door Verwijderd op 20-11-2013 20:17 ]
In een niet ZFS situatie zou mijn config dit opleveren:
schijf | TB | TiB (/1,024) | data | pariteit | pool |
1 | 3 | 2.9296875 | 2.9296875 | 2.9296875 | |
2 | 3 | 2.9296875 | 2.9296875 | 2.9296875 | |
3 | 3 | 2.9296875 | 2.9296875 | 2.9296875 | |
4 | 3 | 2.9296875 | 2.9296875 | 2.9296875 | |
5 | 3 | 2.9296875 | 2.9296875 | 2.9296875 | |
6 | 3 | 2.9296875 | 2.9296875 | 2.9296875 | |
7 | 3 | 2.9296875 | 2.9296875 | 2.9296875 | |
totaal | 21 | 20.5078125 | 14.6484375 | 5.859375 | 20.5078125 |
In de situatie die ik nu heb levert het 19TiB op wat sowieso al 1,5 TIB minder is. Uit mijn dataset blijkt ook nog eens dat ik effectief bij het schrijven van de files niet 1 TiB = 1,4 TiB inclusief pariteit haal, maar dat het rond de 1TiB = 1,6 TiB ligt. Wat nog eens een 15% verlies inhoud. Daarmee komt het totale verlies van de 7e schijf op ongeveer 65%. Dat is natuurlijk alles behalve goed voor je €/GB ratio.
Zelfs op mijn SSD-pool haal ik dramatische snelheden.
ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool : pool2 (928G, 0% full)
Test size : 64 GiB
normal read : 2 GB/s
normal write : 286 MB/s
I/O bandwidth : 36 GB/s
Ik heb dit nu getest met de LSI Logic SAS-controller.
Ik heb de VM aangemaakt met 16GB mem, 2 cpu's met 2 cores per cpu.
(met de M1015's in passthru hangt de hele server zodra de VM boot. dat doe ik dus maar ff niet meer)
Heeft iemand nog een idee?
Anders ga ik denk ik maar weer terug naar ZFSguru op fysiek ijzer en de ML110 op ESX laten.
(het was zo mooi geweest als het wel goed zou werken...)
Misschien dus andere ESXi proberen of andere ZFSguru?
3TB = 2,728 TiB en geen 2,929 TiB.
@]byte[: probeer je passthrough opnieuw te doen. Dat trucje hoor ik soms van ESXi icm BSD + vt-d passthrough. Maar geen idee of dat helpt. ESXi is wat gevoelig. Als het eenmaal wel goed werkt kan het prima performen. Je kunt eens kijken met top en shift+S wat je systeemverbruik is (interrupts/devicekerneldriver).
[ Voor 61% gewijzigd door Verwijderd op 20-11-2013 22:10 ]
ik zal 5.1 eens downloaden en testen.
Ik gebruik nu 5.5 met 9.2-001.
Welke fw heb je op de M1015's zitten? P17?
Welke getallen haal jij nu met benchmarks?

@]Byte[: Ik weet niet meer welke firmware ik geflashed heb, maar die heb ik iets van 4 maanden geleden geflashed en ik heb toen denk ik gewoon de laatste gepakt. Ik weet niet van wanneer 17 is, maar denk dat development redelijk stil staat voor deze oude controler.
Ik heb nog niet echt gebenched omdat ik bezig was met mijn capaciteits-issue.
Nu dat is opgelost wil ik best even benchen. Bench je met de ZFSguru ingebouwde benchmark?
JaMystic Spirit schreef op woensdag 20 november 2013 @ 22:24:
[...] Bench je met de ZFSguru ingebouwde benchmark?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| Release date: 10/15/12 ====================== Supported Controllers: ====================== MegaRAID SAS 9240-4i MegaRAID SAS 9240-8i Component: ========= SAS MegaRAID Firmware Release for MegaRAID Controllers Release date: 10/15/2012 Version Numbers: =============== Current Firmware Package: 20.10.1-0119 (Merged) Firmware 2.130.364-1847 WebBIOS 4.0-59-e_48-Rel ROMENV 1.08 BootBlock 2.02.00.00-0001 NVDATA 3.09.03-0043 PCLI 03.02.20 Hii 1.31.00 UEFI_Driver 0x05180000 FCODE 4.12.05.00 BIOS 4.31.00 |
Een snelle 8GiB bench levert het volgende op:
1
2
3
4
5
6
| ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark Pool : ZFS_RZ2 (19T, 8% full) Test size : 8 GiB normal read : 462 MB/s normal write : 419 MB/s I/O bandwidth : 11 GB/s |
[ Voor 27% gewijzigd door Mystic Spirit op 20-11-2013 22:35 ]
Hoe is je pool opgebouwd? Z2? hoeveel spindels?
[ Voor 52% gewijzigd door ]Byte[ op 20-11-2013 22:42 ]
Benchmark 64GiB
1
2
3
4
5
6
| ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark Pool : ZFS_RZ2 (19T, 8% full) Test size : 64 GiB normal read : 652 MB/s normal write : 342 MB/s I/O bandwidth : 29 GB/s |
Ik heb trouwens maar 6GB memory toegewezen en een enkele core, dus het kan mogelijk sneller als ik meer toewijs.
EDIT:
Benchmark 128 GiB
1
2
3
4
5
6
| ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark Pool : ZFS_RZ2 (19T, 8% full) Test size : 128 GiB normal read : 548 MB/s normal write : 340 MB/s I/O bandwidth : 29 GB/s |
[ Voor 16% gewijzigd door Mystic Spirit op 20-11-2013 23:02 ]
Ik heb het al 3 keer geprobeerd, diverse reboots etc. maar zodra ik de VM start...Verwijderd schreef op woensdag 20 november 2013 @ 22:07:
@]byte[: probeer je passthrough opnieuw te doen. Dat trucje hoor ik soms van ESXi icm BSD + vt-d passthrough.
1 * PSOD
2 * volledig hangend systeem (zelfs de [NumLock] op het Keyboard reageerde niet meer)
Maar in naam van de wetenschap... Ik zal het nog eens proberen.
Ik moet zo weg, maar laat het jullie morgen wel even weten wat er uitgekomen is,
In de topicstart staat dat het handig is om machten van 2 te gebruiken voor het aantal effectieve schijven, maar ga je dat direct in performance merken als dit niet precies klopt?
[ Voor 35% gewijzigd door CU2morO op 21-11-2013 05:23 ]
Gebruik 1 eenheid, en geen verschillende door elkaar.
Enig idee hoe groot dat verlies is?Mystic Spirit schreef op donderdag 21 november 2013 @ 06:54:
Dat is precies wat ik nu aan het onderzoeken ben. De performance is het probleem niet. Het is vooral dat je er ruimte door verliest omdat de 4k block size niet goed past en je dus van iedere 4k op een schijf <4k daadwerkelijk gebruiken kan.
De keuze voor 4TB schijven was in ieder geval in mijn berekeningen verwachting niet gunstig. Voor de prijs van vier 4TB schijven koop je ongeveer zes 3TB schijven. Als de laatste 3TB schijf dan maar voor 33% effectief is, blijven 3TB schijven goedkoper. Vandaar dat ik voor 3TB ben gegaan en nu aan het kijken ben wat het oplevert.
Overigens is het zo dat als je 512 byte blocken naar je hdd blijft schrijven en je HDD deze om laat zetten naar 4K blokken dat dat waarschijnlijk qua ruimte betere resultaten geeft, maar dat de performance daarvan weer minder is.
Ik ben er nog niet over uit of ik dat wil testen. Dat hangt er vanaf hoe lang mijn data erover doet om van mijn oude NAS naar mijn nieuwe ZFS storage VM te kopieren. Dat lijkt nu ruim twee dagen te gaan kosten...
[ Voor 27% gewijzigd door Mystic Spirit op 21-11-2013 13:00 ]
Even niets...
Het was zo mooi geweest om het in een VM te kunnen draaien, maar ik krijg de HBA's gewoonweg niet in passthru zonder dat de hele machine gaat hangen.
En de andere optie kost mij teveel performance.
Ik ga over op FC (heb nog twee QLE2460's liggen) die ik in ieder geval op de ESX-host wil gaan gebruiken (ML110).
De rest gaat over iSCSI / NAS / ...
[ Voor 4% gewijzigd door ]Byte[ op 21-11-2013 13:48 ]
Even niets...
Het begint behoorlijk offtopic te raken, maar die 2 schijven extra is ook 3TB (met verlies misschien 1,5) extra ruimte. Dus je bent die 6e schijf niet nodig voor dezelfde hoeveelheid ruimte. Laat je die achterwege dan heb je opeens geld "over" voor 12 jaar stroom. Dan zijn die schijven al lang weer vervangen voor een andere config.FireDrunk schreef op donderdag 21 november 2013 @ 13:11:
Je vergeet stroomverbruik. 2 schijven extra is 8-10W meer verbruik. dat is 20 euro per jaar. Dat is het verschil in prijs met 4TB schijven.
@]Byte[
Jammer dat het niet wil lukken op ESXi. De performance van mijn setup is toch niet slecht voor gewone schijven?
1
2
3
4
5
6
| ZFSguru 0.2.0-beta8 (9.1-006) pool benchmark Pool : ZFS_RZ2 (19T, 8% full) Test size : 128 GiB normal read : 548 MB/s normal write : 340 MB/s I/O bandwidth : 29 GB/s |
Als ik zie dat ik op bare-metal dit haal:
pool1 (10*4 TB WD Red's in RAID-Z2)
1
2
3
4
5
6
7
8
9
10
| ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark Pool : pool1 (36.2T, 0% full) Test size : 128 GiB normal read : 537 MB/s normal write : 699 MB/s lzjb read : 5 GB/s lzjb write : 3 GB/s gzip read : 5 GB/s gzip write : 3 GB/s I/O bandwidth : 37 GB/s |
pool2 (4 * 250 GB Samsung 840 EVO's in RAID-Z)
1
2
3
4
5
6
| ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark Pool : pool2 (928G, 0% full) Test size : 128 GiB normal read : 2 GB/s normal write : 749 MB/s I/O bandwidth : 38 GB/s |
Dan snap je dat ik niet vrolijk wordt van maar 60 MB ipv 699 MB writes op mijn WD's en 275 MB ipv 749 MB op mijn SSD's
@ FireDrunk: Nee. Oke, zal vanavond proberen met de 9.1-RC3 build.
ff USB-stickie maken...
Status voor mijn dataset is momenteel:
3,4TiB daadwerkelijk in gebruik door files.
5,11TiB in gebruik inclusief pariteit en verlies.
Verlies is dus bijna 8% momenteel.
Dezelfde config, maar dan met ZFSguru 9.1-RC3 haal ik in een VM op de SSD-pool nu een write van 456 MB/s tov 275 MB/s met 9.2-001
En de grote test... de M1015's in passthru...
NO WAY!
Alleen hangt ESXi nu niet meer als de VM opstart!
In de console van ZFSguru blijft ie hangen op:
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config mps_startup mps_startup
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config mps_startup mps_startup
run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config mps_startup mps_startup
run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config mps_startup mps_startup
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config mps_startup mps_startup
en van de VM lopen 3 van de 4 cores op 100% load en de 4e core 12-15% load.
<zucht...>
nu maar ff kijken of ik ESXi 5.1 kan downloaden en dan het zelfde testrondje nogmaals maken...
Succes!
Even msix uitzetten.
Even niets...
Even de boot onderbreken (bij het keuze schermpje)
en invoeren:
set hw.mps.disable_msix=1 boot
Is niet permanent, maar voor testen goed genoeg om je interrupt probleem op te lossen.
[ Voor 9% gewijzigd door Mystic Spirit op 21-11-2013 20:57 ]
Ik heb P17, en voor zover ik weet is dat de laatste.Verwijderd schreef op donderdag 21 november 2013 @ 20:27:
Draai je wel moderne firmware op je M1015? Ik dacht dat dat een issue was met die foutmelding.
@FireDrunk & Mystic: tnx voor de tip. Ga ik ff doen.
[update]
Dit was een gedeeltelijk succes.
Booten ging nu allemaal goed, en ook zag ik de disken en de pools die al eerder aangemaakt waren.
(ik helemaal blij...)
Alleen zodra ik 1 van de pools opnieuw wilde importeren hing de VM zich helemaal op!
De laatste error in het console:
panic: mps_reinnit transition operational failed with error 6
<zucht>

[update 2]
Grrrrrr....
Nu weer een PSOD
Ik hou het even voor gezien.
Ik heb de USB-stick er uit getrokken en de mSATA er uitgehaald...
Draait nu weer als een zonnetje met 9.2-001 op bare-metal.
(dan de VM's maar op FC en/of iSCSI)
[ Voor 51% gewijzigd door ]Byte[ op 21-11-2013 23:24 ]
Ik krijg mijn netwerk kaarten niet op MTU 9000, althans, 1tje niet, 1tje wel.
Nu had ik om te beginnen 2xIntel Pro/1000 PT, prima dingen, niet al te nieuw meer, maar toch. Deze gebruikten de ME driver. Hiermee heb ik dat uren proberen te testen maar wilde het niet werken, wat ik ook deed.
Ik heb vandaag een i350T-4 ingebouwd in de ZFSguru server en een i350T-2 in mijn ESXi server. Die deed het eerder ook al prima met de PT's maar ik wilde graag daar ook naar de nieuwere kaarten vanwege de betere offloading, toen ik vervolgens ook nog eens goede aanbeidingen op ebay vond was het zo gedaan.
Efin, net lopen testen.... EXACT hetzelfde probleem aan de kant van ZFSguru. igb0 schakelt zonder problemen naar MTU 9000. De igb1 doet dit ook, zegt succesfull maar komt nooit online. igb2 heb ik niet in gebruik en igb4 is mijn LAN NIC en werkt ook prima (MTU 1500).
Hoewel dit dus een andere driver is (en zelfs een ander moederbord, maar dat is een ander verhaal) heb ik dus exact hetzelfde probleem nog steeds. Dat doet me denken dat het iets in het OS is.
Heeft iemand een clue? Ik heb dit wel vaker geconfigureerd binnen VMware, Switches, Storage, etc. en daar was het nooit een probleem zolang je de juiste drivers, revisies, etc. gebruikte. Mijn FreeBSD kennis is echter beperkt (Word snel meer) maar hier sta ik eventjes voor een raadsel.
Met MTU1500 zijn mijn resultaten al een stuk beter dan hiervoor. Alles 'voelt' ook sneller, maar dan natuurlijk een placebo effect zijn.

Mijn trage snelheid van het zenden van ZFSguru naar VMware is in ieder geval gefixed. Nou kan het zijn dat die PRO/1000 PT's gaar waren, maar toch! En dat is nog zonder enige netwerk tuning settings voor de i350T's!
update--
Fixed it, er moesten enkele tunables aangepast worden binnen ZFSguru/FreeBSD om genoeg buffer ruimte vrij te maken voor de jumbo frames.
Wat exact is eventjes te complex om neer te zetten maar gaat sowieso verwerkt worden in een blog post die ik aan het schrijven ben.
De belangrijkste daarbij was waarschijnlijk n de /etc/sysctrl.conf:
kern.ipc.maxsockbuf=16777216
kern.ipc.nmbclusters=131072
kern.ipc.nmbjumbo9=38400
De nmbclusters is veel over te lezen in combinatie met meerdere cores en meerdere netwerk kaarten en al helemaal als er jumbo frames gebruikt worden.
Ik heb nog veel meer aangepast, maar dit was het voornaamste om het werkend te krijgen verwacht ik.
Benchmark laat niet al te veel verschil zien, maar ach.

[ Voor 35% gewijzigd door Quindor op 22-11-2013 02:02 ]
Ik denk dat ik eerder ergens een foutje gemaakt heb... maar wat...?
[pool] => [Cache devices]:
boot_mirror - MUST BE 7+ !! RAID1 (mirroring) 27.8G 2.32G 25.4G ONLINE
en de tab [Log devices]
boot_mirror - MUST BE 10+ !! RAID1 (mirroring) 27.8G 2.32G 25.4G ONLINE
Iemand een idee hoe ik deze melding er uit kan krijgen?
Ik heb ook al geprobeerd om de partities te destroyen en opnieuw aan te maken, maar deze melding blijft terugkomen.
met een zool status lijkt alles goed te zijn:
[root@zfsguru ~]# zpool status pool: boot_mirror state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Fri Nov 22 00:52:39 2013 config: NAME STATE READ WRITE CKSUM boot_mirror ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/boot ONLINE 0 0 0 gpt/boot2 ONLINE 0 0 0 errors: No known data errors pool: hdd_pool1 state: ONLINE status: The pool is formatted using a legacy on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on software that does not support feature flags. scan: none requested config: NAME STATE READ WRITE CKSUM hdd_pool1 ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 gpt/hdd_dsk_0 ONLINE 0 0 0 gpt/hdd_dsk_1 ONLINE 0 0 0 gpt/hdd_dsk_2 ONLINE 0 0 0 gpt/hdd_dsk_3 ONLINE 0 0 0 gpt/hdd_dsk_4 ONLINE 0 0 0 gpt/hdd_dsk_5 ONLINE 0 0 0 gpt/hdd_dsk_6 ONLINE 0 0 0 gpt/hdd_dsk_7 ONLINE 0 0 0 gpt/hdd_dsk_8 ONLINE 0 0 0 gpt/hdd_dsk_9 ONLINE 0 0 0 logs mirror-1 ONLINE 0 0 0 gpt/slog ONLINE 0 0 0 gpt/slog2 ONLINE 0 0 0 cache gpt/l2arc ONLINE 0 0 0 gpt/l2arc2 ONLINE 0 0 0 errors: No known data errors pool: ssd_pool1 state: ONLINE status: The pool is formatted using a legacy on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on software that does not support feature flags. scan: none requested config: NAME STATE READ WRITE CKSUM ssd_pool1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gpt/ssd_dsk_0 ONLINE 0 0 0 gpt/ssd_dsk_1 ONLINE 0 0 0 gpt/ssd_dsk_2 ONLINE 0 0 0 gpt/ssd_dsk_3 ONLINE 0 0 0 errors: No known data errors [root@zfsguru ~]#
Leeg gooien en alles opnieuw installeren is ook een optie, maar wil eigenlijk weten wat ik fout gedaan heb, en hoe op te lossen.
[ Voor 3% gewijzigd door ]Byte[ op 22-11-2013 09:46 ]
Je zpool status zou dit ook suggeren.
[ Voor 12% gewijzigd door Quindor op 22-11-2013 10:10 ]
Heb net de twee pools ook een zpool upgrade gegeven, en in de interface geeft ie daar nu dezelfde melding op.
Was mij nog niet eerder opgevallen.
tnx!
[update]
vraagje:
Moet ik nog iets doen voor ARC (dus niet L2ARC) om dat te laten gebruiken voor een pool? (ramdisk aanmaken?)
[ Voor 28% gewijzigd door ]Byte[ op 22-11-2013 14:38 ]
Of kan ik beter WOL instellen?
Even niets...
ok thnxFireDrunk schreef op vrijdag 22 november 2013 @ 16:36:
Automatisch uit kan in een cronjob, automatisch aan moet in je BIOS(/UEFI). Remote aanzetten kan inderdaad ook via WoL.
Level 1 ARC is je RAM-geheugen, Level 2 ARC is optioneel een SSD. Beide worden standaard actief zonder verdere interventie, door de instellingen: primarycache en secondarycache. Die kun je instellen op All (Metadata+Data) Metadata en None. Vooral de metadata-instelling is interessant. Dan wordt er geen data gecached maar enkel metadata. Dat is overal nuttig, vooral bij zoekopdrachten, grote directories en vermindert het aantal seeks wat je hardeschijven moeten verrichten. Hierdoor kunnen de schijven zich vooral op sequentiële toegang richten, dat is het idee met L2ARC (en ook L1ARC).]Byte\[ schreef op vrijdag 22 november 2013 @ 11:30:
vraagje:
Moet ik nog iets doen voor ARC (dus niet L2ARC) om dat te laten gebruiken voor een pool? (ramdisk aanmaken?)
Maar in plaats van alles botweg te activeren, kun je ook wat gaan tunen. Dit kan via de ZFSguru web-interface op de Files pagina zodra je op een filesystem klikt. Dan kun je onderaan bij Cache strategy zowel L1 ARC als L2 ARC instellen.
Ik raad aan dat je L2ARC op 'metadata' instelt voor de hele pool. Dan zal de SSD standaard enkel metadata cachen en pas data gaan cachen wanneer jij dit expliciet aangeeft. Bijvoorbeeld je filesystem vol met virtual machine images. Of een ZVOL die je als iSCSI-target gebruikt. Enzovoorts.
Er zijn ook mensen die L1ARC tunen naar metadata, maar daar moet je erg voorzichtig mee zijn. Je kunt hierdoor performance mislopen. Al zou bij je huidige patroon dit in sommige gevallen gunstig kunnen uitpakken, in de toekomst kan dit dubbel weer terugkomen en dan was je die instelling allang vergeten.
Concluderend: L1 lekker zo houden (All-instelling) en L2 alleen metadata cachen by default tenzij jij een fs op 'All' instelt. Dat lijkt mij het beste advies.
Er zit 32 GB RAM in en is dus wel ff voldoende.
Ben nu bezig met een rsync om data van mijn QNAP's over te pompen naar m'n ZFS-doos.
puntjes van onderwerp zijn nu nog FC en iSCSI.
Vraag:
De eerste share heb ik overgezet (met rsync)
Dit zijn 40126 files met een totale size (du -h) van 353 GB
Kijk ik met een zpool iostat hdd_pool1 geeft ie een alloc. cap. aan van 464 GB
Als ik dit even plat doorreken is dit een overhead van 2,766 MB/file gemiddeld.
Weten jullie mij hier iets meer duidelijkheid over?
(ik ben benieuwd wat dit straks met de Foto's voor impact heeft (74 GB - 35411 files))
[ Voor 49% gewijzigd door ]Byte[ op 23-11-2013 10:13 ]
Probleem ziet er als volgt uit:
Op de Synology heb ik een mappen structuur en komt daarbij dit voor:
/Map_naam/nog_een_map/files.x
/MAP_NAAM/een_andere_map/files
de eerste directory heeft dus feitelijk dezelfde naam, maar de een bestaat uit hoofdletters en dan andere voornamelijk kleine letters.
Bij het kopiëren van de synology naar ZFSguru worden beide mappen door ZFSguru tot een map samengevoegd waardoor mijn synology de back-up failed, want voor de synology klopt de map indeling niet meer.
Klopt het dat ZFSguru / FreeBSD mappen met hoofdletters en kleine letters als een en dezelfde map ziet of is dit toch een dingetje aan de synology kant?
Een bestand file1.txt en File1.txt in dezelfde map... tja, dat gaat inderdaad niet goed komen.Mystic Spirit schreef op zaterdag 23 november 2013 @ 10:09:
Klopt het dat ZFSguru / FreeBSD mappen met hoofdletters en kleine letters als een en dezelfde map ziet of is dit toch een dingetje aan de synology kant?
[ Voor 8% gewijzigd door ]Byte[ op 23-11-2013 10:24 ]
Als jullie Samba gebruiken, oftewel Windows filesharing, dan zijn de defaults volgens mij ook dat opslag case insensitive is, omdat anders Windows in de war kan raken met bepaalde dingen. Ik had daar in een ver verleden ooit mee te maken.
Wil je Samba case insenstive gebruiken, zul je smb.conf moeten instellen met:
case sensitive = yes
Dit zal niet aan ZFS, ZFSguru of FreeBSD liggen. In Unix zijn directories en filenames case-sensitive.Mystic Spirit schreef op zaterdag 23 november 2013 @ 10:09:
Bij het kopiëren van de synology naar ZFSguru worden beide mappen door ZFSguru tot een map samengevoegd
[..]
Klopt het dat ZFSguru / FreeBSD mappen met hoofdletters en kleine letters als een en dezelfde map ziet of is dit toch een dingetje aan de synology kant?
Ik heb even een lege dir aangemaakt en daarin drie op dezelfde manier gespelde dirs aangemaakt als voorbeeld:
$ mkdir dir_naam $ mkdir DIR_Naam $ mkdir DIR_NAAM $ ls -l total 18 drwxr-xr-x 2 stefan stefan 2 Nov 23 16:32 DIR_NAAM drwxr-xr-x 2 stefan stefan 2 Nov 23 16:32 DIR_Naam drwxr-xr-x 2 stefan stefan 2 Nov 23 16:32 dir_naam
Dit zijn dus drie verschillende directories.
Als ik een file kopieer naar directory DIR_NAAM, dan komt hij daar in terecht en niet in DIR_naam en/of dir_naam.
Kopieer je je file mogelijk via Samba?
Want volgens mij zit daar wel een dergelijke case-insensitive mechanisme in. Omdat directories onder oudere Windows en DOS versies niet case-sensitive waren, alles was in CAPS immers. Later zijn daar kleine letters en lange bestandsnamen aan toegevoegd (vanaf Win95). Maar FAT filesystems zijn bij mijn weten niet case-sensitive. NTFS weet ik eigenlijk niet zeker, en ik heb ook geen Windows bak draaien om het even te proberen...
Dus als je Samba gebruikt wil je daar mogelijk case sensitivity inschakelen.
[edit]
CiPHER was mij net voor zo te zien.
[ Voor 5% gewijzigd door Ultraman op 23-11-2013 17:32 ]
Als je stil blijft staan, komt de hoek wel naar jou toe.
Nu al mijn files gekopieerd zijn heb ik trouwens ook besloten om niet te gaan testen met blocks van 512 bytes. Het verlies is momenteel maar ruim 7%. Dat is dus heel erg beperkt. Volledig tegen mijn verwachting in lijken kleinere files minder verlies te geven dan grotere files.
[ Voor 37% gewijzigd door Mystic Spirit op 23-11-2013 17:45 ]
Als ik in een VM een 4k write benchmark draai, zie ik ongeveer een gelijk aantal operations als wat er daadwerkelijk door de VM gedaan worden, maar qua size klopt het gewoon niet.
De VM doet bijvoorbeeld 3000 4k writes (12MB/s), maar via zpool iostat zie ik soms wel dik 400-500 MB/s langskomen (dat zouden dan haast 100.000 IOPS moeten zijn).
Er word dus ergens in de keten meer geschreven dan er daadwerkelijk nodig was. iemand die daar een idee over heeft?
Even niets...
Even niets...
Het is misschien ver gezocht, maar ik begrijp je wantouwen wel.
Ik weet niet uit hoeveel en welke disken jou pool bestaat, maar voor 100k IOPS ga je met geen mogelijkheid halen op HDD's.
Ik heb zo'n vermoeden dat hier ook veel mem./cache IOPS in verwekt zitten.
(of jij moet een FusionIO-drive hebben...
[ Voor 6% gewijzigd door ]Byte[ op 23-11-2013 20:47 ]
dd if=/dev/zero of=test.4k bs=4k oflag=sync count=1024000 capacity operations bandwidth pool alloc free read write read write ----------- ----- ----- ----- ----- ----- ----- propool 35.3G 203G 0 490 0 3.83M propool-A 17.7G 101G 0 245 0 1.92M propool-B 17.7G 101G 0 244 0 1.91M ----------- ----- ----- ----- ----- ----- -----
Dat is fysiek op de bak.
Als ik deze tests via ESXi (NFS) doe, zie ik dezelfde snelheden (3-10MB/s) maar zpool iostat geeft meer zoiets:
capacity operations bandwidth pool alloc free read write read write ----------- ----- ----- ----- ----- ----- ----- propool 37.7G 200G 32 3.96K 49.0K 481M propool-A 18.8G 100G 18 1.99K 30.5K 239M propool-B 18.8G 100G 13 1.97K 18.5K 242M
Even niets...
Ik verwacht niet dat de M1015 een probleem zal geven.
Daarmee zijn getallen tot 2500 MB/s en 350k IOPS ge-benchmarkt.
Andere optie... Heb je al eens geprobeerd om jumbo-frames te gebruiken?
Kijken of die IOPS op de pool dan omlaag gaan.
Mijn idee erachter is... Je schrijft met 4k blocks... Je MTU is standaard 1500.
Ergo voor een 4k block het je op je netwerk minimaal 3 blocks nodig om die 4k te versturen ex overhead!
(de cursus 'Computernetwerken en Protocollen' is al weer tijdje geleden, weet dus ff niet de exacte getallen meer uit mijn hoofd)
Maar het gaat er om dat een enkele 4k write opgedeeld wordt in meerdere pakketten op je netwerk.
Dit zou dus wel een verschil kunnen verklaren van lokaal tov via NFS.
[update ...]
Ik heb de dd-test van jou eens gedaan (zonder de oflag - die kent ie niet) zowel naar disk, maar ook van disk naar /dev/null.
Wat mij opvalt is dat ik volgens de iostat rond de 900 MB/s uitkom (read vanaf disk), maar dd komt iets hoger uit...
[root@zfsguru /ssd_pool1/share]# dd of=/dev/null if=test.4k bs=4k count=4096000 4096000+0 records in 4096000+0 records out 16777216000 bytes transferred in 12.370682 secs (1356207847 bytes/sec)
Dit is dus volgens dd geen 900 MB/s maar 1,3 GB/s. (4 * Samsung 840 EVO in RAID-Z op de M1015)
Bijzonder....
[ Voor 90% gewijzigd door ]Byte[ op 23-11-2013 23:27 ]
Als ik hier met CDM of AS SSD een benchmark draai, dan haal ik om en bij de 1 à 2MB/s aan 4K writes maar op de pool geeft dat gemiddeld 30MB. (zakt soms tot 20 of lager en geeft dan af en toe een piek van 80/90/100/111MB/s)
In AS SSD is de snelheid 1.08MB/s
Op zpool iostat
capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- m4ftw 60.2G 416G 29 80 3.64M 5.34M m4ftw 60.2G 416G 0 316 0 2.48M m4ftw 60.2G 416G 0 1.03K 0 100M m4ftw 60.2G 416G 0 820 0 62.7M m4ftw 60.2G 416G 0 305 0 2.39M m4ftw 60.2G 416G 0 303 0 2.37M m4ftw 60.2G 416G 0 305 0 2.39M m4ftw 60.2G 416G 0 1.34K 0 143M m4ftw 60.2G 416G 0 468 0 19.6M m4ftw 60.2G 416G 0 311 0 2.44M m4ftw 60.2G 416G 0 300 0 2.35M m4ftw 60.2G 416G 0 312 0 2.44M m4ftw 60.2G 416G 0 1.36K 0 146M m4ftw 60.2G 416G 0 611 0 21.6M m4ftw 60.2G 416G 0 301 0 2.36M m4ftw 60.2G 416G 0 312 0 2.44M m4ftw 60.2G 416G 0 310 0 2.43M m4ftw 60.2G 416G 0 1.12K 0 119M m4ftw 60.3G 416G 0 687 0 48.8M m4ftw 60.3G 416G 0 347 0 2.72M m4ftw 60.3G 416G 0 304 0 2.38M m4ftw 60.3G 416G 0 281 0 2.20M m4ftw 60.3G 416G 0 1.47K 0 161M m4ftw 60.2G 416G 0 333 0 2.73M m4ftw 60.2G 416G 0 350 0 2.74M m4ftw 60.2G 416G 0 270 0 2.11M m4ftw 60.2G 416G 0 321 0 2.51M m4ftw 60.2G 416G 0 1.53K 0 161M m4ftw 60.2G 416G 0 339 0 2.65M m4ftw 60.2G 416G 0 309 0 2.42M m4ftw 60.2G 416G 0 301 0 2.36M m4ftw 60.2G 416G 0 340 0 2.66M
[ Voor 80% gewijzigd door HyperBart op 23-11-2013 23:41 ]
Maar de ARC... die zou wel eens wat extra roet in het eten kunnen gooien.
Bij een read van mijn 16 GB file in 4k blocks lees, dan gaat ie maar een paar keer even vanaf de pool lezen. de rest... 0
[root@zfsguru ~]# zpool iostat ssd_pool1 1 capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- ssd_pool1 355G 573G 16 39 2.06M 4.76M ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 1.10K 0 140M 0 ssd_pool1 355G 573G 3.96K 0 507M 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 50 0 6.37M 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 ssd_pool1 355G 573G 0 0 0 0 [...]
Even niets...
Dat is niet zo vreemd. Je test deels je RAM geheugen op deze manier. IOstat kan minder aangeven omdat een deel van de requests uit L1ARC RAM cache komt. Ik denk dat je dat niet terugziet in iostat commando; dat is meer wat er naar de disks worden gestuurd (met -v flag in detail).]Byte\[ schreef op zaterdag 23 november 2013 @ 21:40:
Wat mij opvalt is dat ik volgens de iostat rond de 900 MB/s uitkom (read vanaf disk), maar dd komt iets hoger uit...
[root@zfsguru /ssd_pool1/share]# dd of=/dev/null if=test.4k bs=4k count=4096000 4096000+0 records in 4096000+0 records out 16777216000 bytes transferred in 12.370682 secs (1356207847 bytes/sec)
Dit is dus volgens dd geen 900 MB/s maar 1,3 GB/s. (4 * Samsung 840 EVO in RAID-Z op de M1015)
Bijzonder....
In plaats van 16GiB test file dien je minimaal 8 * RAM te doen. Of je moet je (test) pool exporteren en weer importeren. Dan ben je alle cache kwijt. Dus wat je kunt doen is dd write, export, import, dd read. Dan krijg je andere resultaten vermoed ik.
Propool-B is het GPT label van de SSD.
root@NAS2:/# dd if=/dev/zero of=/dev/disk/by-partlabel/propool-B bs=4k count=2048000 oflag=sync 84693+0 records in 84693+0 records out 346902528 bytes (347 MB) copied, 133.747 s, 2.6 MB/s
Test waarin ik direct schrijf naar de SSD (zonder filesystem dus).
Dat is natuurlijk echt pokke traag... 665 IOPS.
Iemand een idee? Dit is onder Linux btw.
Even niets...
Bronnen:
http://www.nexentastor.org/boards/5/topics/6465
http://forums.freenas.org...hy-is-iscsi-faster.12506/
http://blog.laspina.ca/ub...ver-nfs-as-a-vmware-store
https://communities.vmware.com/thread/263165And there are the cons:
Every write I/O from VMware is an O_SYNC write.
Nou is dat wel per VM volgens mij, dus meerdere VM's gaan niet op elkaars O_SYNC wachten, en een O_SYNC geld volgens mij alleen voor de NFS thread die op dat moment loopt. Nexenta zegt ook dat je het aantal NFS worker threads op 2048 moet zetten, hierdoor krijg je misschien wel een hoog aantal concurrent SYNC writes binnen op ZFS en zou het misschien nog kunnen performen.
Maar dat neemt niet weg dat met O_SYNC schrijven naar een SSD niet zulke belabberde resultaten op zou moeten leveren...
[ Voor 38% gewijzigd door FireDrunk op 24-11-2013 14:31 ]
Even niets...
Als ze writes bufferen moet dat toch ook slechte resultaten geven onder AS SSD en CDM als de SSD zelf getest wordt. Met ESXi en een datastore gaat het stevig vooruit hoor...Verwijderd schreef op zondag 24 november 2013 @ 13:43:
Maar dat is het punt; als alle writes sync zijn, dan is je performance klote. Ik denk wel dat sommige SSDs stiekem helemaal geen echte sync writes doen, maar nog steeds writes bufferen maar dan in beperkte mate. Echte sync writes zijn gewoon heel traag; de SSD kan dan maar één kanaal (zelfs maar één die per kanaal) gebruiken. Pas als een SSD vals speelt en stiekem toch writes opspaart, kan het toch meerdere kanalen tegelijk gebruiken. Ik ben dus wel benieuwd als je deze test uitvoert met een Samsung SSD en met een echte Intel (320/S3500). Ergens verwacht ik dat Samsung sync writes gedeeltelijk negeert. Zou me weinig verbazen in elk geval.
Nee. AS SSD en CDM testen inderdaad wel 4K writes met qd=1. Maar dat is niet hetzelfde als sync writes!HyperBart schreef op zondag 24 november 2013 @ 15:06:
[...]
Als ze writes bufferen moet dat toch ook slechte resultaten geven onder AS SSD en CDM als de SSD zelf getest wordt. Met ESXi en een datastore gaat het stevig vooruit hoor...
4K write met qd=1 kun je bereiken door zogenaamde 'blocking I/O'. De applicatie stuurt een API-request en wacht totdat die request is afgehandeld. Je kunt qd=10 bereiken door 10 threads blocking I/O te laten doen, of door één thread non-blocking I/O te laten doen. De applicatie wacht dan niet totdat de data binnen is maar kan andere dingen gaan doen.
Bij een sync write wordt de write request gevolgd door een 'FLUSH' commando. Dat flush commando is voor de SSD een boosdoener. Dit beveelt dat de SSD de write eerst moet afhandelen voordat het andere writes mag behandelen.
Met async writes zoals in AS SSD en CDM kan de SSD deze gewoon bufferen, terwijl dat bij sync writes onmogelijk is. Ook met qd=1 kan de SSD een buffer van writes aanleggen, datzelfde doen mechanische schijven ook trouwens. Alleen de SSD kan extra voordeel bereiken omdat het alle 8 kanalen (* 2 dies per channel = 16-way interleaved minus 1 vanwege parity) kan aanspreken en zo 4K writes met bakken tegelijk wegzetten. Dat gaat veel sneller (maximaal tot 15 keer sneller) dan met sync writes.
Bovenstaande zou ik nog verder willen testen om er zeker van te zijn dat het klopt. Maar ik denk van wel. Sync writes en qd=1 writes zijn niet hetzelfde, dat is denk ik de conclusie.
De waarheid zal dus ergens in het midden liggen.
Even niets...
En die kan je vervolgens weer voorkomen door gebruik te maken van MPIO.Verwijderd schreef op zondag 24 november 2013 @ 16:18:
[...]
4K write met qd=1 kun je bereiken door zogenaamde 'blocking I/O'.
De IO RoundRobin zet je in ESX vervolgens van de standaard 1000 IO's (zo even snel uit mijn hoofd) naar 1... en voila...
Ik heb een file system aangemaakt op mijn pool /zfs_rz2/share/ nu heb ik al mijn files in die directory gekopieerd vanaf mijn synlogy. Nu wil ik eigenlijk submappen delen via samba en nfs, maar zie in de interface van ZFSguru hier geen mogelijkheden voor.
Kan ik alleen maar andere / nieuwe filesystems aan maken en die sharen of is het ook mogelijk voor submappen in een filesystem?
Het eerste waar ik tegenaan liep was het gebruik van een afwijkende dd in FreeBSD tov linux of illumos. Daar heb ik een minimalistische equivalent voor geschreven die portable is maar wel alle essentiele functies biedt.
Tweede is het soort workload en benchmark. De meeste tweakers zijn alleen geinteresseerd in sequentiele overdrachten, oftewel je HD film opslaan en lezen. Bijna niemand heeft echt concurrency. In het bedrijfsleven is dat juist precies andersom. Ik had niet echt een goed beeld van de performance karakteristiek van ZFS bij dit soort streaming workloads. Er is eigenlijk heel weinig data over bekend in het algemeen. Enthousiast begin ik met het schrijven van een testsuite. Dat ging prima. Alleen toen ik de resultaten zag was ik niet blij en ronduit verast. Ik zag enorme variaties in MB/sec en latency per write. Ook high level testen via SMB en NFS lieten een onregelmatig patroon zien.
Na veel Dtrace bleek er een stukje code te ontbreken in de nieuwe ZFS IO scheduler. (Overigens niet door mij als eerste gevonden, iemand die aan de ZFS voor Linux implementatie heeft het als eerste gevonden)
Ik heb snel de patch op mijn source tree geinstalleerd en ...
wauw!
De nieuwe scheduler weet ongeacht block grootte een constante schrijfsnelheid vast te houden. Iedereen kent wel het trappetje van atto. Na deze patch zijn alle rode lijntjes even lang. Dit op een zpool waar geen andere processen i/o's op doen, dus niet je root zpool! Bij meer threads neemt de performance wel af. Niet dramatisch maar ik moet daar verder naar kijken. Wel is het zo dat alle threads mooi even hard schrijven. De scheduler verdeelt de writes heel evenredig over de threads.
Ik denk dat de nieuwe ZFS IO scheduler samen met deze patch veel goeds betekent voor de tweakers hier. Het zal wel een tijdje duren voor dat dit beschikbaar komt.
Nog even een waarschuwing. Inmiddels weet een ieder dat ZFS zich niet gedraagt als NTFS of EXT4. Het benchmarken van ZFS is ronduit lastig. Ook bij het maken van deze benchmark liep ik weer tegen wat unieke kenmerken van ZFS aan. Het belangrijkste voor hier is laat ik het maar de "write cache" noemen (is het niet maar voldoet voor nu even) Deze "write cache" is afhankelijke van de hoeveelheid ram. Met een paar GB ram maakt het niet zoveel uit maar van 16GB zijn de effecten goed zichtbaar. En Firedrunk met 64GB ram in zijn ZFS NAS zal hier helemaal last of voordeel van hebben. Als je test niet goed inelkaar zit meet je alleen je RAM snelheid. Als je even snel een grote file wilt schrijven is dat prachtig. Je schrijft een paar GB ongeveer direct. Fijn, zolang je daarna even niks doet. Want die data moet uiteindelijk natuurlijk een keer op disk komen en dat gaat veel minder snel. Als je wel meer dan een paar GB wilt schrijven dan zal je zien dat die eerste paar GB weer extreem snel gaat en dat daarna je de schrijfsnelheid van de zpool benadert. Als je test niet goed inelkaar zit meet je die eerste paar GB (ook).
@Firedrunk,
nu dit is opgelost zal ik weer aan jouw project wat tijd besteden.
Hieronder het resultaat van met een kleine zpool met twee mirrors en gewone desktop sata drives.
All files are 4GB Blocksize | 4096 | 8192 | 16384 | 32768 | 65536 | 131072 Thread 1 of 1 | 245 | 231 | 282 | 244 | 241 | 181 Blocksize | 4096 | 8192 | 16384 | 32768 | 65536 | 131072 Thread 1 of 2 | 112 | 119 | 108 | 123 | 130 | 126 Thread 2 of 2 | 109 | 119 | 108 | 122 | 132 | 125 Blocksize | 4096 | 8192 | 16384 | 32768 | 65536 | 131072 Thread 1 of 4 | 54.8 | 45.9 | 49.3 | 40.5 | 39.5 | 39.8 Thread 2 of 4 | 54.6 | 47.8 | 51.1 | 39.8 | 39.4 | 39.5 Thread 3 of 4 | 54.2 | 46.0 | 49.3 | 39.8 | 39.4 | 39.3 Thread 4 of 4 | 54.2 | 45.6 | 50.7 | 40.1 | 39.8 | 39.3 Blocksize | 4096 | 8192 | 16384 | 32768 | 65536 | 131072 Thread 1 of 8 | 20.7 | 21.6 | 20.9 | 21.5 | 23.3 | 22.1 Thread 2 of 8 | 20.9 | 22.1 | 20.8 | 20.3 | 23.0 | 22.2 Thread 3 of 8 | 20.6 | 22.2 | 20.8 | 20.4 | 23.0 | 22.0 Thread 4 of 8 | 20.9 | 21.4 | 20.8 | 20.3 | 23.0 | 22.1 Thread 5 of 8 | 20.7 | 22.2 | 20.8 | 21.5 | 23.0 | 24.0 Thread 6 of 8 | 20.7 | 21.4 | 21.4 | 22.2 | 23.0 | 22.0 Thread 7 of 8 | 20.7 | 21.4 | 21.1 | 20.4 | 23.1 | 22.0 Thread 8 of 8 | 20.7 | 21.4 | 21.0 | 20.5 | 23.0 | 22.2
Is dit in ZoL dan al gepatched (in de huidige stabiele versie)?(Overigens niet door mij als eerste gevonden, iemand die aan de ZFS voor Linux implementatie heeft het als eerste gevonden)
[ Voor 10% gewijzigd door Durandal op 25-11-2013 04:58 ]
Vermoedelijk gaat dit een tijdje duren voordat dit algemeen beschikbaar is, sorry voor de teleurstelling.
Daarnaast zal er de komende tijd door een aantal mensen kritisch gekeken worden naar de (performance) karakteristieken van de nieuwe scheduler om mogelijke regressies op te sporen. Ik ga ervan uit dat er geen fouten in de scheduler zitten maar een regressie kan altijd.
Ik heb 2* 840Pro 128GB, 1*840Pro 256GB en 3*320GB 2.5" schijfjes waar je elke test mee mag verzinnen die je wil. Ze kunnen in een i5 server met 8GB ram als FreeBSD / ZFSonLinux of van mij part Solaris install getest worden. Of ik hang ze in mijn Opteron.
Roep maar wat jij handig vindt.
Even niets...
na de lunch kom ik erop terug. Maar ik denk aan het volgende:
je FreeBSD 10 beta 3 op de i5 met 8GB
2x840PRO als mirror mspool
3x320GB als raidz1 rzpool
de opteron heeft teveel ram en maakt testen lastiger. De test bij 8GB zal veel meer mensen een goede indruk geven. Als je daarna switch naar de opteron zal de resultaten weer wat verbeteren.
Het andere waar even wat aandacht aan besteed moet worden zijn de SSD's. Kan je die beperken tot 100GB? Het liefst via het instellen van de HPA via iets als HDAT. En kan je evt de SSD's eerst terug brengen in fabriekstoestand of wipen? Anders lopen we direct tegen de garbage collection van de ssd aan.
Het andere is dat jij nog niet de nieuwe scheduler hebt, maakt niet uit maar is om de verwachtingen wat te temperen.
De 840 Pro stond geloof ik bekend als een SSD met vrij goede garbage collection, maar FreeBSD ondersteund gewoon TRIM (zelfs op partities) dus dat zou toch niet zo'n probleem moeten zijn?
Ik wil ze best even Secure Erasen hoor, maar in mijn ogen is TRIM toch voldoende?
PS: persoonlijk wilde ik de SSD's als stripe inzetten zodat ik wat meer ruimte heb, en 's nachts een ZFS send en Receive backup doen naar de 320GB pool. Maar als jij graag wil testen met een mirror vind ik dat ook best.
[ Voor 21% gewijzigd door FireDrunk op 25-11-2013 11:13 ]
Even niets...
Met of zonder patch we kunnen natuurlijk en de mirror en de stripe testen of welke config dan ook. Behalve verschillende modellen drives.
Wel denk ik dat het voor de performance en de levensduur van je ssd beter is om toch de ssd's te beperken tot 100GB via HPA oid. Zie ook http://www.storagereview.com/samsung_ssd_840_pro_review. Kijk vooral even halverwege bij het onderdeel preconditioning. Het is duidelijk dat de 840PRO het over tijd steeds moeilijker krijgt, ondanks TRIM. Ik kan de bron van een review over de 840 PRO en overprovisioning even niet zo snel vinden. Maar je kan uit het andere artikel wel halen dat de 840PRO wel degelijk vatbaar is voor performance verlies over tijd.
Heb jij al mbuffer op beide systemen, voor send and receive?
Even niets...
ik ben nog aan het uitzoeken wat er nu wel of niet qua ZFS commits in FreeBSD 10 en head zit.
Misschien hem (Andriy Gapon <avg@freebsd.org of Xin LI <delphij@freebsd.org> ) mailen. Zij verzorgen de meeste patches vanuit de openzfs groep.tvwes schreef op maandag 25 november 2013 @ 23:02:
@Firedrunk,
ik ben nog aan het uitzoeken wat er nu wel of niet qua ZFS commits in FreeBSD 10 en head zit.
Wow, even een vergelijking gevonden van jongens die hele uitgebreide tests doen.
Als ik zo kijk, zijn mijn scores zo slecht nog niet
Even niets...
ohh nice, zitten wel leuke dingen in zoals, debian 7 jails! ik heb helemaal geen esxi meer nodig jongens
Als je goede DNS thuis hebt, is het misschien wel te doen, maar om nou voor 3-7 jails allemaal losse IP's te moeten gebruiken
Wil je FTP-en naar je server moet je ip .2 hebben, gebruik je OwnCloud moet je weer .3 hebben... Niks voor mij...
Even niets...
[ Voor 64% gewijzigd door Tsurany op 27-11-2013 12:36 ]
SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N
Reverse proxy of niet, ik heb het liefst gewoon 1 IP
Even niets...
Je kan toch gewoon ftp.server(.lan) en cloud.server(.lan) voor je verschillende virtuele machines gebruiken als je dat wil. Niet eens een domein naam nodig.
Hoe los je trouwens 2 FTP servers op dezelfde poort op verschillende virtuele machines op, als ze hetzelfde IP hebben?
[ Voor 5% gewijzigd door Durandal op 27-11-2013 13:18 ]
En FTP kan toch ook via een reverse proxy?
SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N
Even niets...
Ik ben van plan dit er te voor aan te schaffen (Ik weet niet of de AMC CBL-SFF8087OCF-10M gaat werken met de IBM M1015) :
# | Product | Prijs | Subtotaal |
1 | AMC CBL-SFF8087OCF-10M | € 15,- | € 15,- |
1 | IBM ServeRAID M1015 SAS/SATA Controller for System x | € 118,58 | € 118,58 |
Bekijk collectie Importeer producten | Totaal | € 133,58 |
Op dit moment heb ik de volgende hardware draaien:
# | Product | Prijs | Subtotaal |
1 | Intel Core i5 4670 Boxed | € 187,90 | € 187,90 |
1 | Intel Desktop Board DB85FL | € 77,10 | € 77,10 |
1 | WD Green SATA 6 Gb/s, 1TB | € 51,99 | € 51,99 |
1 | Western Digital Red WD30EFRX, 3TB | € 114,40 | € 114,40 |
1 | BitFenix Merc Alpha | € 32,- | € 32,- |
1 | Kingston DataTraveler 100 G2 8GB Zwart | € 8,90 | € 8,90 |
1 | Intel Gigabit CT Desktop Adapter | € 22,13 | € 22,13 |
1 | Crucial Ballistix Sport BLS4C8G3D1609ES2LX0BEU | € 265,53 | € 265,53 |
1 | be quiet! Pure Power L7 300W | € 38,40 | € 38,40 |
1 | Seasonic G-Serie 360Watt | € 54,30 | € 54,30 |
1 | Samsung 840 series Pro 256GB | € 192,95 | € 192,95 |
Bekijk collectie Importeer producten | Totaal | € 1.045,60 |
Nu ben ik op het moment nog bezig om te kijken hoeveel IO performance mijn huidige setup gebruikt. Doormiddel van ESXi te monitoren met de ingebouwde performance grafiekjes. En ook door IOStat te gaan draaien in sommige Guests.
Is het nu handig om straks een L2ARC te maken van de Samsung 840 Pro SSD, en dan de Guests op een disk pool te draaien met de WD RED en de SSD als L2ARC om zo meer read performance te behalen. Of is het nu handiger om de SSD te gebruiken in een pool zonder een achterliggende hardeschijf inplaats van L2ARC.
Natuurlijk gebruik ik een ISCSi om een gedeelte van de pool door te geven aan ESXi.
Ook weet ik niet hoe ZFS omgaat met de pool en L2ARC als datastore ( hoeveel er gecached wordt van de .vmdk bestanden ).
Voor de Guests ben ik van plan NFS te gaan gebruiken zodat de Guests ( Linux ) hun bestanden op ZFS kunnen opslaan. Hier kan ik op het moment nog geen tests van doen dus ik weet ook nog niet of ik een ZIL nodig heb voor NFS om de performance een boost te geven.
Of ik lees verkeerd of er gaat iets heel erg mis in je uitwerking van je systeem.
>want je ZFS pool kan niet starten zonder dat je VM is gestart en je VM kan straks niet starten omdat die op de ZFSpool staat die niet bereikbaar is omdat de VM nog niet draait.Mystic Spirit schreef op donderdag 28 november 2013 @ 14:31:
Ik volg niet helemaal wat je wilt bereiken met het maken van de ZFS pool en de L2ARC cache etc. Sterker nog zoals ik je verhaal lees kom je er helemaal niet uit, want je ZFS pool kan niet starten zonder dat je VM is gestart en je VM kan straks niet starten omdat die op de ZFSpool staat die niet bereikbaar is omdat de VM nog niet draait.
Of ik lees verkeerd of er gaat iets heel erg mis in je uitwerking van je systeem.
The Hyperactive Blog: An all in one ESXi-NAS-SAN build
>Ik volg niet helemaal wat je wilt bereiken met het maken van de ZFS pool en de L2ARC cache etc.
Ik heb op dit moment een WD Red 3 TB en een Samsung 840 Pro 256GB.
Wat ik nu wil doen is een pool maken van de SSD en daar dan de Guests op te zetten en dan via de all in one esxi nas build opstarten.
Of de 3TB WD Red inzetten als pool en hier dan de Samsung 840 Pro 256GB aanhangen als L2ARC.
Ik weet dus niet welke van de 2 methodes het beste is, dus de vraag is welke van de 2 beter is?
Het klopt wel wat Eagleman7 zegt, ook al heb je zoals mijn blogpost een all in one. Je hebt nog altijd een onafhankelijk medium nodig op je machine die virtueel draait en ZFS storage aanbiedt op te stockeren.Eagleman7 schreef op donderdag 28 november 2013 @ 15:38:
[...]
>want je ZFS pool kan niet starten zonder dat je VM is gestart en je VM kan straks niet starten omdat die op de ZFSpool staat die niet bereikbaar is omdat de VM nog niet draait.
The Hyperactive Blog: An all in one ESXi-NAS-SAN build
Of je kan als ie aan staat wel die VM sVMotionen naar die datastore, maar als de stroom dan uitvalt is het gedaan
Dan blijft mijn basis vraag nog steeds overeind, wat Eagleman7 bereiken wil. Het een is namelijk niet beter als het ander. Het plaatsen van SSD als L2ARC is handig als je SSD onvoldoende storage biedt voor je VM's. Als je die storage niet nodig hebt kun je beter gewoon op je SSD blijven draaien en je WD red voor andere doeleinden inzetten.
Daarom de vraag:Mystic Spirit schreef op donderdag 28 november 2013 @ 16:42:
Met wat tweakwerk is het dus kennelijk mogelijk om een ZFSpool als datastore in te zetten in ESXi zonder dat je daarvoor een geboote VM nodig hebt.
Dan blijft mijn basis vraag nog steeds overeind, wat Eagleman7 bereiken wil. Het een is namelijk niet beter als het ander. Het plaatsen van SSD als L2ARC is handig als je SSD onvoldoende storage biedt voor je VM's. Als je die storage niet nodig hebt kun je beter gewoon op je SSD blijven draaien en je WD red voor andere doeleinden inzetten.
Ook weet ik niet hoe ZFS omgaat met de pool en L2ARC als datastore ( hoeveel er gecached wordt van de .vmdk bestanden ).
Als er genoeg gecached wordt van de Guests op de SSD en de snelheid niet lager komt dan ongeveer 25% dan als het normaal op een SSD draait, biedt zo'n L2ARC meer voordelen omdat de bestanden die op de HDD staan ook meteen gecached worden, win win lijkt mij.
Alleen dit ligt er natuurlijk aan hoeveel er gecached wordt.
Draai je een actieve MySQL binnen een vmdk dan zal de L2ARC deze database blocks zo snel mogelijk proberen te cachen.
ZFS kan de volledige snelheid van een SSD benutten als de L2ARC eenmaal is opgewarmt..
Ik gebruik hiervoor een bestaand perl scriptje om de status van ARC/L2ARC te monitoren.
Google hiervoor op arcstat.pl
Deze geeft het volgende netjes weer: read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size
Zo kan je zien hoeveel hits er uit je ARC (ram) dan wel L2ARC (ssd) komen..
Dit in combinatie met: zpool iostat -v
En je weet vrij nauwkeurig hoe vol je cache devices zijn en hoeveel data er als cache hit word uitgelezen..
Na het 4 keer draaien van een FIO benchmark (binnen 15 minuten) met een benchmark bestand van 8GB was nagenoeg de volledige 8GB aan data op mijn L2ARC aanwezig en zag ik met arcstat.pl 70% L2ARC hits en 30% ARC hits..
Volgende resultaten komen van een linux VM over een 1gbE iSCSI verbinding van SAN naar VMWare ESXi 5.1
Sequential read: Random read: Sequential write: Random write: | io=3127.4MB, bw=106735KB/s, iops=26683 , runt= 30003msec io=3093.2MB, bw=105598KB/s, iops=26399 , runt= 30003msec io=3038.7MB, bw=103689KB/s, iops=25922 , runt= 30003msec io=2368.6MB, bw=80821KB/s, iops=20205 , runt= 30003msec |
Om alles op 10gbE over te zetten kost me helaas nog meer dan de hele SAN bij elkaar dus dat zit er nog even niet in..
Echter.. lokaal zonder iSCSI lopen de benchmark resultaten op van 20k (90mbps HDD) tot 280k iops (500mbps L2ARC) tot 1500k iops (6000mbps ARC)
Ik heb 16GB ram in mijn SAN en mijn ZFS configuratie heeft een verhoogde L2ARC fillrate ten opzichte van de defaults: (/etc/modprobe.d/zfs.conf)
# ZFS zfs_prefetch_disable options zfs zfs_prefetch_disable=1 # ZFS zfs_write_limit_overwrite from 0 to 1073741824 (1GB) options zfs zfs_write_limit_override=1073741824 # ZFS zfs_no_write_throttle options zfs zfs_no_write_throttle=1 # L2ARC noprefetch from 1 to 0 options zfs l2arc_noprefetch=1 # L2ARC write max from 8388608 to 67108864 (8MB to 64MB * 4 = 256MB) options zfs l2arc_write_max=16777216 # L2ARC write boost from 8388608 to 100663296 (8MB to 96MB * 4 = 384MB) options zfs l2arc_write_boost=33554432 # L2ARC headroom from 2 to 4 options zfs l2arc_headroom=4
Ik heb echter l2arc_noprefetch=1 gewoon gelaten voor wat het was aangezien sequentieel vanaf HDD mirrors snel genoeg is en niet via SSD hoeft te verlopen en dus voortijdig SSD slijtage voorkomt.
Hopelijk geeft deze post wat meer inzicht in mogelijke resultaten en hoe ZFS intern werkt..
Als je meer wilt weten over bijvoorbeeld gebruikte instellingen drop me dan ff een PM
[ Voor 10% gewijzigd door damanseb op 28-11-2013 18:53 ]
Krijg ik nog problemen met deze kabels en de raid controller, of gaat dit gewoon werken?
# | Product | Prijs | Subtotaal |
1 | AMC CBL-SFF8087OCF-10M | € 15,- | € 15,- |
1 | IBM ServeRAID M1015 SAS/SATA Controller for System x | € 118,58 | € 118,58 |
Bekijk collectie Importeer producten | Totaal | € 133,58 |
[ Voor 1% gewijzigd door Verwijderd op 28-11-2013 20:46 ]
Na aanleiding van: https://wiki.freebsd.org/ZFSTuningGuidematty___ schreef op donderdag 28 november 2013 @ 20:01:
Waarom heb je de zfs_prefetch uit staan?
Ik heb ik met deze instelling zitten spelen en ik heb er goeie ervargingen mee in de zin dat het betere random read/write resultaten oplevert terwijl de impact op sequentieel minimaal is.
(Na een hele week benchmarken met nagenoeg alle mogelijk combinaties aan instellingen)
Ik gebruik SSDs voor ZIL en L2ARC en deze setting lijkt voor wat balans te zorgen tussen de performance van de HDDs en de SSDs
Ik draai nu al een paar maanden stabiel ZFS on Linux op Ubuntu 12.04 LTS met SCST voor exporteren via iSCSI naar VMWare en in tegenstelling tot OP moet ik zeggen dat op moment van schrijven ZoL behoorlijk volwassen is want het loopt hier vooralsnog zonder problemen als een trein..
VMWare voelt super responsive aan; virtuele machines installeren gaat extreem snel en benchmarks met FIO binnen VMs trekken de beschikbare gbE verbindingen helemaal vol..
ZFS op deze manier voelt aan als een 3000 euro raidkaart met superieure IO scheduler, 16gb aan RAM en SSD all rolled into one, I LOVE IT!
De complete configuratie van het OS tot Multi Path IO op iSCSI niveau..
Hiervoor heb ik een HOWTO bijgehouden en ben meer dan bereid deze te delen als iemand interesse heeft..
[ Voor 61% gewijzigd door damanseb op 28-11-2013 21:55 ]
Voor het bouwen van een ZFS NAS en andere hardwarevragen kun je beter terecht in Het grote DIY RAID NAS topic deel 3, zodat we dit topic reserveren voor ZFS-specifieke vragen en discussies.