Het grote ZFS topic

[ronzelver]

FireDrunk schreef op donderdag 20 september 2012 @ 12:02:
UEFI vs BIOS verhaal denk ik zo... Booten van USB3 lijkt me alleen mogelijk met een fatsoenlijke UEFI (achtige) BIOS...

Ik heb gezien dat er een BIOS update is voor mijn ASUS E45M1-I-Deluxe bord met verbeterde ondersteuning voor USB devices. Deze maar erop gaan zetten en zien of dan USB disk wel als preferred boot device te selecteren is

[Ravefiend]

Mijn FreeNAS box (FreeNAS 8.2.0) heeft al een heel tijdje goed gelopen met een RAIDZ2 config en nu dus een eerste serieus probleem. Had een keer de SMART deamon aangezet en het begon een paar weken terug met:

code:

Device: /dev/da5 [SAT], 13 Currently unreadable (pending) sectors

Deze ging na een dag over in:

code:

Device: /dev/da5 [SAT], 2 Offline uncorrectable sectors

Lijkt me duidelijk dat da5 niet meer zo goed zit maar wat doe ik er nu mee? De config is als volgt:

code:

  pool: rpool
 state: ONLINE
 scrub: none requested
config:

    NAME               STATE     READ WRITE CKSUM
    rpool              ONLINE       0     0     0
      raidz2           ONLINE       0     0     0
        gpt/rz2_disk1  ONLINE       0     0     0
        gpt/rz2_disk2  ONLINE       0     0     0
        gpt/rz2_disk3  ONLINE       0     0     0
        gpt/rz2_disk4  ONLINE       0     0     0
        gpt/rz2_disk5  ONLINE       0     0     0
        gpt/rz2_disk6  ONLINE       0     0     0
    spares
      gpt/rz2_disk7    AVAIL

De SMART data van de disk da5:

code:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   195   195   051    Pre-fail  Always       -       6965
  3 Spin_Up_Time            0x0027   253   253   021    Pre-fail  Always       -       966
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       37
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   084   084   000    Old_age   Always       -       12154
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       35
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       34
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       2081
194 Temperature_Celsius     0x0022   115   106   000    Old_age   Always       -       35
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       16
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       1
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       44

[DrFlash]

Je kan de disk offline zetten vanuit de freenas console. Vervolgens kan je deze eruit halen en vervangen.

[FireDrunk]

d1ng schreef op vrijdag 21 september 2012 @ 11:39:
[...]


Misschien ook een idee om in rc.conf dumpdev="AUTO" op te nemen om crashdumps op te vangen.

Goed idee! Ik neem aan dat ik daarna even moet rebooten?

[Patatjemet]

Ravefiend schreef op vrijdag 21 september 2012 @ 12:20:
Lijkt me duidelijk dat da5 niet meer zo goed zit maar wat doe ik er nu mee?

Zolang je een spare op de plank hebt liggen zou ik er voorlopig mee door draaien, voor zover ik het snap ziet de smart er nog prima uit en met raidz-2 zou je hem makkelijk kunnen opvangen.

Zijn al je disks even oud? Draai je wel scrubs?

[Ravefiend]

Patatjemet schreef op vrijdag 21 september 2012 @ 17:37:
[...]
Zolang je een spare op de plank hebt liggen zou ik er voorlopig mee door draaien, voor zover ik het snap ziet de smart er nog prima uit en met raidz-2 zou je hem makkelijk kunnen opvangen.

Zijn al je disks even oud? Draai je wel scrubs?

Wel ja, Reallocated_Sector_Ct is ook nog steeds 0 dus vind ik het een beetje verwarrend. De spare hangt in de pool (disk 7) zelf dus zit wel OK. Alle disks zijn even oud (en identiek) en nee, had nog geen scrubs gedraaid. Daar ga'k straks eens mee aan de slag.

[Verwijderd]

Racefiend, er is niets aan de hand. Je hebt onleesbare sectoren die niet gebruikt worden door ZFS. Althans ik neem even aan dat die disk enkel gebruikt wordt voor ZFS. Als je een scrub succesvol afrondt en je hebt nog steeds Current Pending Sector raw value groter dan 0, dan bevinden die onleesbare sectoren zich in ongebruikte gebieden die lange tijd niet beschreven zijn.

De klassieke bad sector die fysiek beschadigd is kennen we, bij het remappen (overschrijven) hiervan wordt de Reallocated Sector Count raw value met één verhoogd. Echter, bij schijven met hoge datadichtheid komen een ander type bad sector steeds vaker voor: de bad sector zonder fysieke schade. De schijf heeft simpelweg onvoldoende ECC bitcorrectie om de inhoud ervan te ontcijferen. De kans hierop is veel groter als die sector lange tijd niet opnieuw beschreven is, de demagnetisering degradeert de data waardoor meer ECC bitcorrectie nodig is om de data te kunnen destilleren.

Het is dus geen probleem en komt veel vaker voor; lekker laten zitten die bad sectors. Zodra ZFS ze nodig heeft, worden ze overschreven en dan zijn ze dus niet 'bad' meer. Kortom, het lost zichzelf op en is geen probleem. Als je er werkelijk vanaf wilt, kun je het volgende doen:

1. je ZFS pool volschrijven met nullen, dan dat bestand verwijderen. Niet zo lekker als je OS ook op deze pool draait trouwens!

2. De disk detachen/offlinen en overschrijven met nullen, daarna weer attachen/onlinen.

Dit is enkel nodig als je wilt verifiëren of het bad sectors mét of zónder fysieke schade betreft. Indien er geen fysieke schade is, wordt Reallocated Sector Count ook niet verhoogd; enkel de Current Pending Sector wordt verlaagd.

[HyperBart]

Zo... Hier moet zeker wat perf tuning gedaan worden: N40L met 16GB geheugen en twee disks van 400GB ieder...

[root@zfsguru /streep]# dd if=/dev/zero of=test.file bs=10M count=10240
10240+0 records in
10240+0 records out
107374182400 bytes transferred in 942.269422 secs (113952740 bytes/sec)

CPU usage volgens web if van ZFSguru nooit boven 80% uit...

[ Voor 9% gewijzigd door HyperBart op 21-09-2012 23:08 ]

[FireDrunk]

Mirror?

[Patatjemet]

HyperBart schreef op vrijdag 21 september 2012 @ 23:08:
Zo... Hier moet zeker wat perf tuning gedaan worden: N40L met 16GB geheugen en twee disks van 400GB ieder..

Gooi die 3 TB's er nou eens in man!

[FireDrunk]

Hmm, ik zit mij ineens te bedenken:

Wat gebeurt er als ZFS al 80% van je geheugen heeft, en Virtualbox moet 4GB claimen voor een VM?

Misschien veroorzaakt een geheugentekort mijn reboots wel...

Ik heb nu 1 dag uptime terwijl ik geen VM's heb draaien...

[ Voor 13% gewijzigd door FireDrunk op 22-09-2012 09:09 ]

[EnerQi]

EnerQi schreef op vrijdag 21 september 2012 @ 12:00:
Helaas krijg ik de volgende error:
ada3 (nog wat cijfers): read_fpdma_queued. acb: (en vele cijfers)
ada3 (nog wat cijfers): cam status: ata status error
ada3 (nog wat cijfers): ata status: 41 (drdy err), error 40 (UNC)
ada3 (nog wat cijfers): res: (en vele cijfers die per reboot wisselen)
retrying command
etc.

Freebsd wordt geladen maar daarna kan ie iets niet lezen. Omdat de code "ada3" had, dacht ik, disk 2 is verdwenen. Ik heb gecontrolleerd of alle harde schijven in de bios zichtbaar zijn en dit is een ja.

Wat heb ik gedaan?
Ik heb geprobeerd om een dataset van mijn "storage" pool te vernietigen omdat deze niet netjes in windows getoond werd. Dit is overigens "Storage/Share". Nu heb/had ik als test een kleine TB gekopierd in deze verschillende submappen en die wilde ik dus verwijderen.
Via ZFSguru heb ik het gevaarlijk commando uitgevoerd om "storage/share" te verwijderen inclusief 6 onderliggende mappen en vervolgens deed zfsguru niets meer. Na 15/16 minuten eens een poging gedaan de zfsguru portal opnieuw te openen zonder resultaat. Vervolgens de powerknop ingedrukt en de NAS sloot zichzelf juist af (geen harde powerdown! ). Vervolgens de pc aangezet met de bovenstaande error.

Edit: http://unix.stackexchange...s-read-fpdma-queued-error
Hmm ik heb het dus voor elkaar gekregen om ZFS kapot te krijgen xD

Edit2: vanavond maar een nieuwe ZFSguru usbstick maken en kijken of iets werkt (ik boot nu van een usb3.0 500 GB harde schijf)

Hmmm via een verse installatie geboot en ik kan weer gebruik maken van ZFSguru. Nu wil ik mijn "storage" pool importeren en hier loopt alles op vast (zie bovenstaande error). Zoals ik het nu zie zijn er op 2 pools fouten gevonden ("test", 500 GB externe schijf/boot schijf en "storage" Raidz2 met 6x 3 TB) waardoor mijn PC dus niet meer opstarten.

Ansich kan ik nu gewoon de HD's wippen en opnieuw beginnen, maar hoe voorkom ik dit in de toekomst?

[FireDrunk]

Geen idee wat er aan de hand is... Random lezen is sneller dan sequentieel...

Windows 2008R2 -> ESXi -> pvscsi -> NFS -> ZFS (met ZIL & L2ARC).

(overgens staat alle sync aan, dus alle writes in ESXi zijn dan synced, dus de 70MB/s write is de max van mijn ZIL, en dus prima)

[ Voor 24% gewijzigd door FireDrunk op 22-09-2012 10:08 ]

[Ravefiend]

Verwijderd schreef op vrijdag 21 september 2012 @ 18:40:
*knip*

Bedankt voor de heldere uitleg CiPHER! Heb nog even een scrub gelanceerd dus maar eens zien wat het resultaat daarvan is. (scrub in progress for 0h9m, 1.68% done, 9h20m to go).

[HyperBart]

Ik ben nu mijn VMDK van een VirtualBox VM aan het kopieren van het ZFS systeem zelf van een single SATA disk via SMB naar mijn W7 EliteBook 8740w met SSD:

18MB/s

Gadver daar moet toch echt wel wat aan getuned worden...

Als dat proces voltooid is kan ik alle disks er uit trekken en mijn 5 x 3TB er in steken...

[FireDrunk]

Ik ben benieuwd

[HyperBart]

Ik ook, maar die 18MB/s vind ik echt belabberd... Ik heb via de ZFSguru web if al gezegd dat ik wil "her-tunen" naar het feit dat er nu 16GB RAM in zit ipv de stock 2GB maar veel haalt dat precies toch niet uit...

[webfreakz.nl]

Waarom dacht je dat die RAM je wél meer performance zou geven? Het is alleen vet handig als je een hoge user workload hebt (dus tientallen users op je storagebak) dan scheelt dat in prefetching.

[HyperBart]

Ja, niet nu isntantieel met die testjes die ik nu doe, maar wel in de toekomst met caching als ik het ding echt ga gebruiken om dagelijks die VM te laten draaien, mijn bestanden die ik dagelijks/vaak gebruik te accessen enz...

[EnerQi]

Hmm Ik heb op disk 3: 944 active bad sectors en 752 passive bad sectors. Hoe kan ik deze oplossen? Scrub is niet mogelijk omdat ik de pool niet geimporteerd krijg.

Overigens is de harde schijf 14 uur oud .

Edit: disk 3 eruit gehaald en vervolgens geprobeerd de pool te importeren. Dit werkt goed
Edit2: 1048 bad sectoren.... ik denk dat ik het antwoord al weet
Edit3: en nu 8? wel 752 realocated sectoren. Blijkbaar een schijf die niet helemaal goed is. Nog even tegenaan kijken dan.

[ Voor 41% gewijzigd door EnerQi op 22-09-2012 15:01 ]

[HyperBart]

Kijk eens aan :

Met 4 van de 5 3TB Hitachi's van Patatjemet:

[root@zfsguru /hulk]# dd if=/dev/zero of=test/test.file bs=1M count=102400
102400+0 records in
102400+0 records out
107374182400 bytes transferred in 456.220507 secs (235355888 bytes/sec)
[root@zfsguru /hulk]# dd if=test/test.file of=/dev/null bs=1M
102400+0 records in
102400+0 records out
107374182400 bytes transferred in 293.212422 secs (366199296 bytes/sec)

Nu even snel naar het ouderlijk huis sjeezen om een molex naar SATA PSU en een hoeks/straight SATA kabeltje gaan halen .

Kunnen we de 5de disk ook mee laten doen (nieuw pooltje aanmaken).

CPU gaat wel "lichtjes over de limieten" .

Usage van rond 300 à 400 %

[FireDrunk]

Maar dat zijn wel een stuk beter snelheden

[HyperBart]

Inderdaad... Vind het ook wel echt gigantisch verschil... Ik bedoel, 2 (!) disken van 400GB ieder in mirror dat moest toch op zijn minst al richting 100MB/s gaan... Om nog niet te spreken van de stock 250GB, die had toch ook al richting 75MB/s mogen gaan. Nu even testen met SMB

Ben eigenlijk wel curieus hoe die disken zouden knallen onder mijn IBM M1015 in de ESXi

Net even een VDMK van mijn laptop overgepompt via SMB en TeraCopy:

Tijdje aan 84MB/s en daarna regelmatig een drop naar X waarbij X tussen de 20 en 40 lag in het begin, maar nu dat ie al even bezig is gaan de drops tussen de 40 en 60...

[ Voor 44% gewijzigd door HyperBart op 22-09-2012 15:17 ]

[FireDrunk]

Dat heb ik dus ook... Heb je de Transaction settings al gewijzigd?
(je kan ook voor testing purposes zil even uitzetten)

[HyperBart]

Ik was eigenlijk van plan om dat na het bijpluggen van de 5de disk te doen. Ik ben net terug van het ouderlijk huis en ik heb de benodigde kabeltjes...

Heeft iemand van jullie het ook dat als je met ZFSguru een shutdown geeft (of het nu via de console of via de web if is) dat hij blijft hangen op iets omtrent USB?

usbus0: controller shutdown complete
usbus1: controller shutdown

En daar blijft ie op hangen, is dat gewoon het laatste berichtje wat hij spawnt en mag ik 'm nu eigenlijk afzetten of eigenlijk nog niet?

CiPHER?

[Verwijderd]

Ik loop achter met berichten; druk druk druk. Maar die USB bug zit als het goed is niet meer in de beta7 livecd. Gebruik je dus de oudere system image, zet dan dit in je /boot/loader.conf:
hw.usb.no_shutdown_wait=1

Voor nu kun je gewoon resetten of power down doen. Alles is al netjes afgesloten; hij wacht alleen oneindig op USB. Dat is een bug in FreeBSD.
Maargoed, nieuwe ZFSguru heeft dit standaard al gefixed. Voor oudere systeemversies en livecd kun je de bovenstaande workaround gebruiken.

[EnerQi]

Verwijderd schreef op zaterdag 22 september 2012 @ 17:27:
Ik loop achter met berichten; druk druk druk. Maar die USB bug zit als het goed is niet meer in de beta7 livecd.

Helaas wel. Deze bug zit ook in beta7 als ie gevisualiseerd is, op een echt systeem heb je er geen last van.

[FireDrunk]

Gevirtualiseerd?

---

Overigens, voor de mensen die denken snelheidswinst te behalen door Compressie, guess again, mijn performance was half zo hoog. En nee, mijn CPU was niet het probleem (i5-3550)

[ Voor 85% gewijzigd door FireDrunk op 22-09-2012 20:10 ]

[HyperBart]

FireDrunk in "HP Proliant Microserver N40L"



Btw: met mijn 5de disk is de throughput wel omlaag gegaan:

[ssh@zfsguru /hulk/hulkfs]$ dd if=/dev/zero of=test.file bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes transferred in 55.861707 secs (192214288 bytes/sec)

[ Voor 45% gewijzigd door HyperBart op 22-09-2012 20:21 ]

[FireDrunk]

Hej vervuil het topic eens niet zo

---

http://forums.freebsd.org/showthread.php?t=23566&page=2

Als ik dit zo lees, is een écht snelle SSD HEEL belangrijk voor ZIL.
Deze persoon heeft een Vertex 3 (el-cheapo MLC) tegenover een X25-E (enterprise SLC) gezet, en de vertex wint..

What in the world...

[HyperBart]

Het enige wat ik op dit moment kan bedenken is dat er toch iets niet klopt met mijn schijven qua 4K-problematiek:

In ZFSguru geven de schijven aan dat ze 512B-sectorschijven zijn, terwijl toen ik mijn RAIDZ array met 5 disks aanmaakte hij iets aangaf in de trant van: "pas op je hebt 4K-schijven".

En bij het aanmaken van mijn array zonder die 5de disk gaf hij die warnings niet.

[FireDrunk]

Gewoon met 4k optimization aanmaken, volgens mij kan dat geen kwaad... (andersom heb je een write penalty...)

[HyperBart]

Read is omhoog gegaan:

[ssh@zfsguru /hulk/hulkfs]$ dd if=/dev/zero of=test.file bs=1M count=102400
102400+0 records in
102400+0 records out
107374182400 bytes transferred in 557.054506 secs (192753458 bytes/sec)
[ssh@zfsguru /hulk/hulkfs]$ dd if=test.file of=/dev/null bs=1M
102400+0 records in
102400+0 records out
107374182400 bytes transferred in 224.252246 secs (478809842 bytes/sec)

Ik ga nu even mijn pool vernietigen en terug opnieuw aanmaken maar deze keer met ashift=12, staat nu nog op 9, eens kijken wat dat doet...

[FireDrunk]

Mooie read! Ziet er goed uit!

[u_nix_we_all]

FireDrunk schreef op zaterdag 22 september 2012 @ 10:07:
[afbeelding]

Geen idee wat er aan de hand is... Random lezen is sneller dan sequentieel...

Windows 2008R2 -> ESXi -> pvscsi -> NFS -> ZFS (met ZIL & L2ARC).

(overgens staat alle sync aan, dus alle writes in ESXi zijn dan synced, dus de 70MB/s write is de max van mijn ZIL, en dus prima)

Ik kan me vergissen, maar die 70 MB/s sequentieel, die gaat toch niet eerst naar de ZIL ? Er is volgens mij een bepaalde grootte (van een transaction group dacht ik) waarboven de ZIL niet gebruikt wordt ?

Edit:

Read is omhoog gegaan:

Ben je nu niet het effect van ARC / L2ARC aan het testen ?

[ Voor 7% gewijzigd door u_nix_we_all op 22-09-2012 20:56 ]

[FireDrunk]

u_nix_we_all schreef op zaterdag 22 september 2012 @ 20:53:
[...]

Ik kan me vergissen, maar die 70 MB/s sequentieel, die gaat toch niet eerst naar de ZIL ? Er is volgens mij een bepaalde grootte (van een transaction group dacht ik) waarboven de ZIL niet gebruikt wordt ?

Dat dacht ik ook, maar zpool iostat zegt andere dingen...

[HyperBart]

u_nix_we_all schreef op zaterdag 22 september 2012 @ 20:53:
[...]

Ik kan me vergissen, maar die 70 MB/s sequentieel, die gaat toch niet eerst naar de ZIL ? Er is volgens mij een bepaalde grootte (van een transaction group dacht ik) waarboven de ZIL niet gebruikt wordt ?

Edit:

[...]

Ben je nu niet het effect van ARC / L2ARC aan het testen ?

Met 100GB in te lezen? Ik denk het niet . ter info, ik heb ook geen SSD als L2ARC

[u_nix_we_all]

HyperBart schreef op zaterdag 22 september 2012 @ 21:01:
[...]


Met 100GB in te lezen? Ik denk het niet . ter info, ik heb ook geen SSD als L2ARC

Ah, OK. Dat zal dan wel meevallen idd.

Iets anders wat ik me afvraag, heb je de vmware guest tools op die 2008r2 geinstalleerd. Ik ben niet zo bekend met ESX, maar weet wel dat het bij andere hypervisors enorm kan verschillen hoe je de virtuele disk aanbiedt, en of je geoptimaliseerde drivers voor de virtuele diskinterface gebruikt. Kan ook per type guest-OS enorm verschillen.

[FireDrunk]

Jup, pvscsi en vmware tools geinstalleerd.

[u_nix_we_all]

FireDrunk schreef op zaterdag 22 september 2012 @ 21:12:
Jup, pvscsi en vmware tools geinstalleerd.

Doet googlen op pvscsi ... ah, ja. Dat bedoel ik.
Dus het is meer
Windows 2008R2 -> pvscsi -> ESX (-> vmdk) -> NFS -> ZFS (met ZIL & L2ARC).
ipv
Windows 2008R2 -> ESXi -> pvscsi -> NFS -> ZFS (met ZIL & L2ARC).

[HyperBart]

Meh, niet veel verschil met die 4K optimalisatie:

[ssh@zfsguru /hulk/share]$ dd if=/dev/zero of=test.file bs=1M count=30720
30720+0 records in
30720+0 records out
32212254720 bytes transferred in 175.129360 secs (183934063 bytes/sec)
[ssh@zfsguru /hulk/share]$ dd of=/dev/null if=test.file bs=1M
30720+0 records in
30720+0 records out
32212254720 bytes transferred in 60.676685 secs (530883562 bytes/sec)

Read heb ik wel wat bijgesqueezed

[ Voor 4% gewijzigd door HyperBart op 22-09-2012 21:33 ]

[u_nix_we_all]

FireDrunk schreef op zaterdag 22 september 2012 @ 09:05:
Hmm, ik zit mij ineens te bedenken:

Wat gebeurt er als ZFS al 80% van je geheugen heeft, en Virtualbox moet 4GB claimen voor een VM?

Misschien veroorzaakt een geheugentekort mijn reboots wel...

Ik heb nu 1 dag uptime terwijl ik geen VM's heb draaien...

Ik las ergens, volgens mij in de manual van VirtualBox, dat idd het geheugengebruik van je arc moet configureren om voldoende geheugen voor je VM vrij te houden. Dat kon wel eens in het (open)solaris daal hebben gestaan ofzo. Ik ga nog ff zoeken ...

[FireDrunk]

u_nix_we_all schreef op zaterdag 22 september 2012 @ 22:01:
[...]


Ik las ergens, volgens mij in de manual van VirtualBox, dat idd het geheugengebruik van je arc moet configureren om voldoende geheugen voor je VM vrij te houden. Dat kon wel eens in het (open)solaris daal hebben gestaan ofzo. Ik ga nog ff zoeken ...

Dat veklaart precies de spontane reboots die ik had... Heb nu al een tijdje geen VM's meer aanstaan, en de server heeft al een uptime van > 30h.

[u_nix_we_all]

FireDrunk schreef op zaterdag 22 september 2012 @ 22:03:
[...]


Dat veklaart precies de spontane reboots die ik had... Heb nu al een tijdje geen VM's meer aanstaan, en de server heeft al een uptime van > 30h.

Hmm, UserManual.pdf, section 12.8.1

The ZFS file system is known to use all available RAM as cache if the default system settings are
not changed. This may lead to a heavy fragmentation of the host memory preventing VirtualBox
VMs from being started. We recommend to limit the ZFS cache by adding a line
set zfs:zfs_arc_max = xxxx
to /etc/system where xxxx bytes is the amount of memory usable for the ZFS cache.

Maar dat gaat over niet kunnen starten, voor solaris(based) systemen....

Edit: Maar wel het proberen waard denk ik, ben wel benieuwd eigenlijk. Wil ook meer met VirtualBox gaan doen ....

[ Voor 7% gewijzigd door u_nix_we_all op 22-09-2012 22:17 ]

[FireDrunk]

Ik vind het risico eerlijk gezegd een beetje te groot... Spontane reboots is niet leuk, en ik heb een ZIL zonder supercapacitor

[u_nix_we_all]

FireDrunk schreef op zaterdag 22 september 2012 @ 22:22:
Ik vind het risico eerlijk gezegd een beetje te groot... Spontane reboots is niet leuk, en ik heb een ZIL zonder supercapacitor

Hmm, zou daar nou niet iets op te verzinnen zijn ....

[FireDrunk]

Zie sig!!

[wjn]

Vraagje voor diegenen met ESXi:
Gebruik je de E1000 of VMXNET 3 als adapter type?
En als het de VMXNET 3 is, krijg je dat uit de "standaard" VMTools (ik test met ESXi5)

Er zijn op internet wel "handleidingen" te vinden om het e.e.a. te maken, maar dat is nogal een lang verhaal / voor een "beginner" bijna niet te doen.

E1000 draait overigens probleemloos, de VMXNET 3 zou meer tegen de GB moeten kunnen leveren.

[FireDrunk]

Ja, als je VMware tools installeert werkt VMXNET3 meteen. Rebooten is verstandig daarna, vanwege de memoryballooning driver (daar moet je wel voor rebooten).

[u_nix_we_all]

Als E1000 voldoet, maakt het niet heel veel uit. VMXNET3 is pas echt van belang als je 10Gb/s wilt doen IMHO.

[wjn]

@FireDrunk
Dank je, ga ik proberen

@u_nix_we_all
Dat wilde ik dus gaan uitproberen, of het wat uitmaakt in mijn geval. De Dell Poweredge heeft Broadcom NIC's standaard, vandaar het idee.

[FireDrunk]

Voor de throughput scheelt het inderdaad weinig, maar qua CPU verbruik en latency scheelt het wel iets.

[HyperBart]

Ik ben ondertussen wat aan het uitzoeken gegaan:

Ik wil/wou uitsluiten dat het trager zijn van mijn 5 disk array ten opzichte van de 4 disk array lag aan het feit dat de 5de disk aan een aparte SATA-aansluiting op mijn N40L zat (de zogenaamde ODD SATA aansluiting).

Omdat ik met 4 disks betere resultaten haalde dan met 5 disks heb ik dus even terug opnieuw een 4 disk RaidZ aangemaakt, maar deze keer met 3x eentje van de drive cage van de N40L die gevoed wordt door een SAS-kabel en eentje met de drive die op de aparte SATA-poort hangt.

Dit zijn de testresultaten:

[ssh@zfsguru /vierdiskhulk/share]$ dd if=/dev/zero of=test.file bs=1M count=30720
30720+0 records in
30720+0 records out
32212254720 bytes transferred in 139.179654 secs (231443704 bytes/sec)

FD en Patatjemet: aan de ODD SATA poort ligt het dus niet...

@FireDrunk: nog even over het RAM-disk verhaal: hoe kan dat een representatieve test zijn, want ik weet dat mijn bakje tot bepaalde snelheden gaat met 4 disks, maar niet met 5, als ik een dd ga doen naar mijn RAM disk ga ik toch alleen maar zien wat hij maximaal kan verstrouwen 1 op 1 naar RAM, maar niet wat hij kan doen met een RAIDZ-berekening er bij? Ik volg het verhaal even niet meer...

[ Voor 18% gewijzigd door HyperBart op 23-09-2012 01:10 ]

[FireDrunk]

Wat je wil weten is bij hoeveel MB/s je CPU het opgeeft. Hoe dat te testen is, is lastig te achterhalen.

[HyperBart]

Dan kan ik toch even goed gewoon een write doen naar /dev/null en kijken hoe hard hij gaat?

[ssh@zfsguru /hulk/share]$ dd if=/dev/zero of=/dev/null bs=1M count=102400
102400+0 records in
102400+0 records out
107374182400 bytes transferred in 53.807544 secs (1995522829 bytes/sec)
[ssh@zfsguru /hulk/share]$ dd if=/dev/zero of=/dev/null bs=1M count=102400
102400+0 records in
102400+0 records out
107374182400 bytes transferred in 53.276431 secs (2015416211 bytes/sec)
[ssh@zfsguru /hulk/share]$ dd if=/dev/zero of=/dev/null bs=1M count=102400
102400+0 records in
102400+0 records out
107374182400 bytes transferred in 53.442496 secs (2009153582 bytes/sec)

Ook wel interessant: met een disk in offline van een 5 spindles RAIDZ array gaat hij terug sneller:

[ssh@zfsguru /hulk/share]$ dd if=/dev/zero of=test.file bs=1M count=30720
30720+0 records in
30720+0 records out
32212254720 bytes transferred in 134.796583 secs (238969372 bytes/sec)

[ Voor 65% gewijzigd door HyperBart op 23-09-2012 01:32 ]

[FireDrunk]

Je cpu moet wel zfs meuk doen.. kaal naar /dev/null schrijven is te makkelijker.

[HyperBart]

Is een simpel ZFS volume genoeg? Want dan kan ik het zoals je zei wel op een RAM disk plaatsen...

[FireDrunk]

Denk het.

[HyperBart]

Was ondertussen al even aan de slag gegaan, via web if een mem disk aangemaakt en via de command line dan een pool aangemaakt "storage" met een device "md0" die dan een mem disk is van 2G:

[root@zfsguru /hulk/share]# zpool create storage md0
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1024 
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 3.339044 secs (321571622 bytes/sec)
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1500
1500+0 records in
1500+0 records out
1572864000 bytes transferred in 6.425465 secs (244786015 bytes/sec)
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1200
1200+0 records in
1200+0 records out
1258291200 bytes transferred in 5.091746 secs (247123725 bytes/sec)
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1800
1800+0 records in
1800+0 records out
1887436800 bytes transferred in 7.723734 secs (244368439 bytes/sec)
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=900 
900+0 records in
900+0 records out
943718400 bytes transferred in 3.765089 secs (250649690 bytes/sec)
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1900
1900+0 records in
1900+0 records out
1992294400 bytes transferred in 8.275004 secs (240760539 bytes/sec)
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 4.172871 secs (257314879 bytes/sec)
[root@zfsguru /hulk/share]# rm -Rf /storage/test.file           
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 4.366334 secs (245913811 bytes/sec)
[root@zfsguru /hulk/share]# rm -Rf /storage/test.file
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1900
1900+0 records in
1900+0 records out
1992294400 bytes transferred in 8.293635 secs (240219683 bytes/sec)
[root@zfsguru /hulk/share]# rm -Rf /storage/test.file
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1500
1500+0 records in
1500+0 records out
1572864000 bytes transferred in 6.442159 secs (244151691 bytes/sec)
[root@zfsguru /hulk/share]# rm -Rf /storage/test.file
[root@zfsguru /hulk/share]# dd if=/dev/zero of=/storage/test.file bs=1M count=1200
1200+0 records in
1200+0 records out
1258291200 bytes transferred in 5.009194 secs (251196345 bytes/sec)

[ Voor 25% gewijzigd door HyperBart op 23-09-2012 01:44 ]

[FireDrunk]

Mja, dat zegt misschien heel veel, maar zeker weten doe je het ook niet...
Je ziet wel een bottleneck van 250MB/s

Ik zal het zo eens bij mij doen, kijken of ik meer haal.

[Verwijderd]

TIP voor de ZFS liefhebbers

[FireDrunk]

Hej! Terug van weggeweest?

[Verwijderd]

FireDrunk schreef op zondag 23 september 2012 @ 14:33:
Hej! Terug van weggeweest?

ik ben nooit weggeweest hoor.. lees altijd stiekum mee
maar het (grote) storage gebeuren is wel over, ben langzaam de server aan het strippen.

[FireDrunk]

Hoe komt het?

[Dadona]

borroz heeft p0rn streams ontdekt.

[FireDrunk]

LOL

@HyperBart:

[root@NAS /home/ssh]# dd if=/dev/zero of=/memorypool/share/test.000 bs=1G count=1
dd: /memorypool/share/test.000: No space left on device
1+0 records in
0+1 records out
1031405568 bytes transferred in 1.420634 secs (726017782 bytes/sec)

[Verwijderd]

FireDrunk schreef op zondag 23 september 2012 @ 14:37:
Hoe komt het?

oude hobby nieuw leven aan het inblazen
ben dat beeldscherm na tig jaar even helemaal zat.

[ Voor 13% gewijzigd door Verwijderd op 23-09-2012 18:10 ]

[Dadona]

Heerlijk, het allereerst dat ik zag was de naam...Project X.
Dan ga je toch denken, wat voor hobby heeft borroz?

[ Voor 4% gewijzigd door Dadona op 23-09-2012 15:16 ]

[CurlyMo]

Pas na Haren maar op met zo'n naam. Dadelijk heb je duizenden jongeren voor je deur staan

[Verwijderd]

ja dat dacht ik gisteren ook ineens
(toch maar even aangepast)

[ Voor 26% gewijzigd door Verwijderd op 23-09-2012 15:23 ]

[FireDrunk]

Disk:

[root@NAS /home/ssh]# dd if=/dev/da0 of=/dev/null bs=16M count=1024
1024+0 records in
1024+0 records out
17179869184 bytes transferred in 119.365558 secs (143926519 bytes/sec)

ZFS: (5 * 2TB in RAIDZ)

[root@NAS /home/ssh]# dd if=/dev/zero of=/datapool/share/temp/test.012 bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes transferred in 67.833982 secs (158289664 bytes/sec)

Snapt iemand het?

[matty___]

Van de Freebsd mailinglist:

FYI, I just committed TRIM support to ZFS, especially useful for
SSD-only pools. This is something I implemented long time ago, but was
now motivated to get back to it and commit it finally by some great
fixes and improvements from the zfsonlinux project (made by Etienne
Dechamps).

Note that this functionality is turned off by default for now.
To turn it on you need to add vfs.zfs.trim_disable=0 to
/boot/loader.conf. You can see some statistics under
kstat.zfs.misc.zio_trim sysctl.

Zal nog wel een tijdje duren voordat het in de stable zit maar het komt eraan.

[FireDrunk]

Nice! Dat scheelt een hoop in de performance degradatie van SSD's die je voor ZIL en L2ARC gebruikt neem ik aan!

Leuk artikel over ZIL: http://www.nex7.com/node/12

[ Voor 19% gewijzigd door FireDrunk op 24-09-2012 09:30 ]

[Ravefiend]

Ravefiend schreef op zaterdag 22 september 2012 @ 11:03:
[...]
Bedankt voor de heldere uitleg CiPHER! Heb nog even een scrub gelanceerd dus maar eens zien wat het resultaat daarvan is. (scrub in progress for 0h9m, 1.68% done, 9h20m to go).

Even voor de volledigheid het resultaat van de scrub:

code:

scrub completed after 11h42m with 0 errors on Sat Sep 22 22:35:51 2012

Voorlopig moeten we ons dus nog geen zorgen te maken.

Wat ik me nog wel afvraag, om de hoeveel tijd laten jullie een scrub / S.M.A.R.T. (short/long) lopen?

[CurlyMo]

Elke week. Maandag pool 1, dinsdag pool 2, enz.

[FireDrunk]

Iemand hier die wél snelle VM's heeft weten te bouwen onder ZFSGuru met VirtualBox?
Want die dingen zijn hier niet vooruit te branden... (lokale disk IO is prima, maar netwerk is een draak).

[HyperBart]

FireDrunk schreef op maandag 24 september 2012 @ 14:02:
Iemand hier die wél snelle VM's heeft weten te bouwen onder ZFSGuru met VirtualBox?
Want die dingen zijn hier niet vooruit te branden... (lokale disk IO is prima, maar netwerk is een draak).

Praise the lord, he has seen the light

[FireDrunk]

Het heeft volgens mij ook meer met de FreeBSD port te maken dan met VirtualBox, want het verschil met mijn desktop is HEEL groot..

Ik zit te kijken of er andere HyperVisor's te krijgen zijn, maar dat valt best tegen.. BeHyve is nog Alpha, alsook VPS, en KVM schijnt ook niet niet stabiel te zijn...

[victorb]

Zo heb net vast stukje gefilmd voor Deel2 van mijn ZFS server build filmpjes. Eindelijk ff tijd gevonden om begin te maken met filmen. Heb globaal plan met wat onderwerpen die ik wil showen. Maar dan kan elk moment veranderen haha

[DrFlash]

FireDrunk schreef op maandag 24 september 2012 @ 14:47:
Ik zit te kijken of er andere HyperVisor's te krijgen zijn, maar dat valt best tegen.. ... KVM schijnt ook niet niet stabiel te zijn...

Links or it didnt happen !

Meer serieus, ik was in de veronderstelling dat KVM al een tijd stabiel was (draaien al veel grote jongens op KVM). En tegenover virtualbox lever je ook geen features in. Hooguit was lastiger te managen.

Dan back on topic. Ik ben jullie nog stats van m'n freenas schuldig, komen er aan ik heb het alleen errug druk.

[matty___]

FireDrunk schreef op maandag 24 september 2012 @ 14:47:
Het heeft volgens mij ook meer met de FreeBSD port te maken dan met VirtualBox, want het verschil met mijn desktop is HEEL groot..

Ik zit te kijken of er andere HyperVisor's te krijgen zijn, maar dat valt best tegen.. BeHyve is nog Alpha, alsook VPS, en KVM schijnt ook niet niet stabiel te zijn...

Behyve gaat het wel worden voor freebsd. Alleen dat gaat nog even duren

[FireDrunk]

Ik weet het iig zeker nu, de spontane reboots kwamen door VirtualBox, en hadden te maken met te weinig geheugen. Ik heb nu een ARC limiet ingesteld en geen problemen meer.

[Verwijderd]

FireDrunk: heb je SWAP configured? Zo ja: hoe?

FireDrunk schreef op maandag 24 september 2012 @ 14:02:
Iemand hier die wél snelle VM's heeft weten te bouwen onder ZFSGuru met VirtualBox?
Want die dingen zijn hier niet vooruit te branden... (lokale disk IO is prima, maar netwerk is een draak).

75MB/s via virtuele adapter vond ik anders niet tergend traag. Ik doe het hier met 3MB/s met de standaard adapter. Dus dan zijn we al een factor 25 sneller bezig.

En als je geen NFS gebruikte maar Samba haalde je wel veel hogere snelheden? Kun je daar nog een overzichtje van maken?

FireDrunk schreef op maandag 24 september 2012 @ 09:12:
Nice! Dat scheelt een hoop in de performance degradatie van SSD's die je voor ZIL en L2ARC gebruikt neem ik aan!

Nee, als ik het goed heb begrepen geldt de TRIM support alleen voor normale storage; niet voor speciale devices zoals L2ARC of SLOG devices. Dus met name nuttig voor SSD pools waarbij de SSDs als normale opslag gebruikt worden. Voor SLOG lijkt me TRIM onmogelijk/irrelevant, voor L2ARC zou TRIM nog een klein beetje nut kunnen hebben.

Bedenk wel dat TRIM en Copy-on-Write filesystems een vreemde combinatie zijn. Zo zal je SSD geen TRIM ontvangen als je data verwijdert die nog door een snapshot wordt gereferenced. En nog steeds moet cq. wil je overprovisioning toepassen op SSDs die je voor SLOG/L2ARC en misschien nog meer gebruikt.

[FireDrunk]

SWAP: Default 500MB op rootpool (SSD)

75MB/s is via VirtIO naar de Host, onder Linux is VirtIO 10Gb dus is 75MB/s heel traag.
zelfs met iperf haalde ik niet meer dan 75MB/s (600-700 Mbit)

Ik heb net wat anders leuks gevonden, de Vbox Shared Folders zijn WEL heel snel!
Ik trek daar gewoon mijn volledige pool mee dicht, dus ik denk dat ik dat maar ga gebruiken.

Het gaat om een download VM die SabNZBd en consorten draait, en dus moet rarren en parren, dat ging vooral heel traag. Voor het internetverkeer wat die VM doet is 75MB/s weer prima.

[Dadona]

Het maakt de zaak natuurlijk wel minder flexibel. Je host moet dan de data aanbieden. Je kunt niet simpelweg even de VM verplaatsen naar een andere bak en de NAS zo splitsen van het server deel.
Maar ik deel wel je ervaring wat de prestaties betreft. Ik ben er alleen nog niet verder achteraan gegaan waar en wat er allemaal trager begint te lopen. Het systeem voelt in het algemeen trager aan.

[FireDrunk]

De VM moet toch downloaden naar de datapool op ZFSGuru, dus scheiden kan ik ze toch al niet.
Maar je punt is zeker valide, je word er minder flexibel door.

[Verwijderd]

FireDrunk schreef op dinsdag 25 september 2012 @ 11:57:
SWAP: Default 500MB op rootpool (SSD)

Véél te weinig. Probeer het eens met 10GB tot 40GB. Doe je dit op de ZFSguru manier dan is dit met spare allocation dus je SWAP volume neemt pas plek in als hij gebruikt wordt. Zorg wel dat de swap niet corrupt raakt doordat je geen ruimte meer hebt voor je ZVOL storage.

Swap wordt conservatief gebruikt in FreeBSD. Het is nodig voor een heleboel dingen, zoals tmpfs maar vast ook andere zaken als jij bijvoorbeeld met virtualbox gaat spelen wil je zeker swap hebben.

onder Linux is VirtIO 10Gb dus is 75MB/s heel traag.

Wat de 'link speed' aangeeft bij paravirtualisatie drivers zou niet uit mogen maken. Je link kan zeggen '10 megabit' maar toch haal je 10 gigabit, of juist andersom. De PV driver kan hier invullen wat het wil; het heeft geen relevantie omdat het geen fysiek netwerk is.

Wat me wel aannemelijk lijkt is dat PV zoals virtio beter getest cq. geoptimaliseerd is voor Linux icm VM producten. In het algemeen kun je ook wel stellen dat de beter geteste combinaties het beste werken. Om die reden is de hardware support van Windows nog steeds onverslaanbaar. Immers als het daar niet (goed) op werkt, verkoopt het niet.

zelfs met iperf haalde ik niet meer dan 75MB/s (600-700 Mbit)

En met Samba haalde je wel tegen de 100MB/s geloof ik? Gebruik je dan wel meerdere threads bij iperf?

Misschien is het ook mogelijk dat met goede benchmarks de developers nog wat meer uit virtio kunnen halen. Verder kan ik ook melden dat ik soms vastlopers heb bij gebruik van virtio + VirtualBox + FreeBSD, waarbij de host op 25% CPU blijft draaien (single threaded max CPU usage). Alleen rebooten helpt dan nog. Dat is het nadeel van PV: je host kan er instabiel door worden. Vooralsnog hoop ik dus dat virtual networking op FreeBSD nog sneller kan. Maar met 1 gigabit kun je voorlopig redelijk vooruit lijkt me, als het stabiel is tenminste.

[victorb]

Zo weer even wat tijd gevonden voor opnemen van deel2 van mijn ZFS fileserver build filmpje

Heb duidelijke mini howto om lagg te configgen onder zfguru vandaag opgenomen

[FireDrunk]

Verwijderd schreef op dinsdag 25 september 2012 @ 13:14:
[...]

Véél te weinig. Probeer het eens met 10GB tot 40GB. Doe je dit op de ZFSguru manier dan is dit met spare allocation dus je SWAP volume neemt pas plek in als hij gebruikt wordt. Zorg wel dat de swap niet corrupt raakt doordat je geen ruimte meer hebt voor je ZVOL storage.

Swap wordt conservatief gebruikt in FreeBSD. Het is nodig voor een heleboel dingen, zoals tmpfs maar vast ook andere zaken als jij bijvoorbeeld met virtualbox gaat spelen wil je zeker swap hebben.

Waarom? Ik wil eigenlijk helemaal geen swap... ik heb geen tempfs, en al helemaal geen 40GB reserveren voor iets nutteloos als SWAP... SWAP is een last resort middel, geen means to work.
En als er applicaties geforceerd gebruik maken van SWAP vind ik dat nogal een slecht design...
(tmpfs daargelaten misschien...)

[...]

Wat de 'link speed' aangeeft bij paravirtualisatie drivers zou niet uit mogen maken. Je link kan zeggen '10 megabit' maar toch haal je 10 gigabit, of juist andersom. De PV driver kan hier invullen wat het wil; het heeft geen relevantie omdat het geen fysiek netwerk is.

Wat me wel aannemelijk lijkt is dat PV zoals virtio beter getest cq. geoptimaliseerd is voor Linux icm VM producten. In het algemeen kun je ook wel stellen dat de beter geteste combinaties het beste werken. Om die reden is de hardware support van Windows nog steeds onverslaanbaar. Immers als het daar niet (goed) op werkt, verkoopt het niet.

True

En met Samba haalde je wel tegen de 100MB/s geloof ik? Gebruik je dan wel meerdere threads bij iperf?

Dat was niet vanuit virtualbox, samba doet 100MB/s van buitenaf. Ik ga geen SMB gebruiken als het om Linux -> FreeBSD gebruikt, dat is wel heel smerig

Misschien is het ook mogelijk dat met goede benchmarks de developers nog wat meer uit virtio kunnen halen. Verder kan ik ook melden dat ik soms vastlopers heb bij gebruik van virtio + VirtualBox + FreeBSD, waarbij de host op 25% CPU blijft draaien (single threaded max CPU usage). Alleen rebooten helpt dan nog. Dat is het nadeel van PV: je host kan er instabiel door worden. Vooralsnog hoop ik dus dat virtual networking op FreeBSD nog sneller kan. Maar met 1 gigabit kun je voorlopig redelijk vooruit lijkt me, als het stabiel is tenminste.

Waarom zou PV je host instabieler maken dan Emulatie? Slecht geprogrammeerde emulatie lijkt me net zo slecht voor je host als slechte PV. Enige verschil is een wat directere communicatie via een speciale bus, ipv via een driver.

75MB/s is voor mij geen Gigabit Dan had ik net zo goed een NAS kunnen kopen

[ Voor 8% gewijzigd door FireDrunk op 25-09-2012 15:08 ]

[Verwijderd]

FireDrunk schreef op dinsdag 25 september 2012 @ 15:07:
Waarom? Ik wil eigenlijk helemaal geen swap... ik heb geen tempfs, en al helemaal geen 40GB reserveren voor iets nutteloos als SWAP

Als je de swap via ZFSguru aanmaakt, wordt deze via sparse allocation ('thin provisioning') aangemaakt. Dus al maak je hem 100 terabyte; hij gebruikt vrijwel geen RAM totdat je het daadwerkelijk gebruikt.

Het enige punt is nog dat tijdens de boot alle swap volumes gepurged zouden moeten worden, zodat je elke keer met een verse lei begint en nooit nutteloos ruimte kwijt bent.

... SWAP is een last resort middel, geen means to work.
En als er applicaties geforceerd gebruik maken van SWAP vind ik dat nogal een slecht design...
(tmpfs daargelaten misschien...)

Zoals je weet vind ik swap ook een noodmaatregel die nooit bedacht was als de verhouding tussen Software:RAM:Storage optimaal zou zijn geweest. Maar omdat dit in het verleden niet zo was, hebben veel operating systems diep in hun kernel een paging daemon met virtual memory ingebouwd. Dat is hedendaags niet helemaal up-to-date meer, maar blijft een realiteit waar je rekening mee moet houden.

Het zijn overigens geen applicaties die swap gebruiken, maar de kernel pagedaemon die bepaalt wat er geswapt wordt en wat niet. Een memory disk met 'swap' als backend gebruikt gewoon RAM geheugen totdat de paging daemon vindt dat de RAM te laag is en gaat swappen. Applicaties bepalen dus niets, voor zover ik weet.

Mijn ervaring met FreeBSD is dat deze heel conservatief swapt. Dat betekent: heb je genoeg RAM dan wordt hooguit 8K geswapt; wat dat precies is geen idee, maar dat zie ik vaak bij een systeem wat lang draait. Pas als de RAM laag begint te worden, gaat de pagedaemon pages naar de SWAP gooien. Je ziet in top output dan 'xMB out' bij de swap regel, en in de proceslijst zie je sommige processen met < > haakjes ertussen zoals <getty>. Dat betekent dat dit proces - wat lang inactief was - geheel geswapt is.

De echte reden dat je swap nodig hebt is misschien niet eens de daadwerkelijke swapgrootte, maar de defaults die worden gegeneerd op basis van de grootte van RAM en SWAP. FreeBSD raadt volgens mij aan dat de SWAP groter is dan RAM. Ik heb gewoon een 10GB swapfile die vrijwel altijd op 0 bytes staat. Het enige vervelende is dat als hij wel een keer gebruikt is, deze ruimte niet zomaar terug beschikbaar komt. Je kunt dit wel vrij makkelijk fixen door eventjes:

zfs set quota="64m" tank/zfsguru/SWAP
zfs set quota="off" tank/zfsguru/SWAP

te doen, dan wordt de grootte even capped op 64MB en daarna die limiet weggehaald. Als zoiets (of TRIM erase) tijdens elke boot gebeurt, kun je gewoon gigabytes grote swap aanmaken dat boeit verder weinig; je offert in de praktijk geen opslagruimte op.

Waarom zou PV je host instabieler maken dan Emulatie? Slecht geprogrammeerde emulatie lijkt me net zo slecht voor je host als slechte PV. Enige verschil is een wat directere communicatie via een speciale bus, ipv via een driver.

Het hele punt bij Paravirtualisatie is dat de host directer toegang geeft tot de hardware. Dit werkt echter alleen goed als zowel host als guest geen bugs bevatten. Bij HVM kan de guest eigenlijk nooit de host laten crashen, tenzij er een bug zit in de virtualisatie engine. Dus qua security en stability is PV juist een groot nadeel over HVM; terwijl PV qua performance en CPU utilization juist een groot voordeel heeft.

75MB/s is voor mij geen Gigabit Dan had ik net zo goed een NAS kunnen kopen

Oke maar al véél beter dan de paar MB/s die je met de standaard geëmuleerde 'HVM' Intel adapter krijgt. En een typische gigabit NAS zit ook zo rond de 75MB/s, al moet ik toegeven dat ik nu 110MB/s write krijg (en 88MB/s read). Snelheden met Samba waren altijd al vreemd. NFS heeft ook zo zijn issues gehad. Maar normaliter werkt NFS toch wel aardig qua doorvoer.

Ook wil ik opmerken dat ik via VM platforms nog nooit hoger hebt gehaald dan gigabit. Jij hebt wel ervaring met VMXNET3; hoeveel kreeg je daar via Iperf uitgeperst? En als je virtio test met Linux, werkt dat veel sneller dan met FreeBSD?

[FireDrunk]

Verwijderd schreef op dinsdag 25 september 2012 @ 19:41:
zfs set quota="64m" tank/zfsguru/SWAP
zfs set quota="off" tank/zfsguru/SWAP

te doen, dan wordt de grootte even capped op 64MB en daarna die limiet weggehaald. Als zoiets (of TRIM erase) tijdens elke boot gebeurt, kun je gewoon gigabytes grote swap aanmaken dat boeit verder weinig; je offert in de praktijk geen opslagruimte op.

Kijk, das dan weer goed om te weten die moeten we onthouden!

Het hele punt bij Paravirtualisatie is dat de host directer toegang geeft tot de hardware. Dit werkt echter alleen goed als zowel host als guest geen bugs bevatten. Bij HVM kan de guest eigenlijk nooit de host laten crashen, tenzij er een bug zit in de virtualisatie engine. Dus qua security en stability is PV juist een groot nadeel over HVM; terwijl PV qua performance en CPU utilization juist een groot voordeel heeft.

Uh, die vat ik niet... Of beter gezegd, daar ben ik het niet mee eens...
Paravirtualisatie is net zo goed een driver als dat Emulatie dat is. Er is echt geen verschil in manier van werken (als je het over netwerken hebt dan iig).

Waar Paravirtualisatie het van wint, is dat de guest goed/precies weet hoe hij een zo'n efficient mogelijk pakketje op een speciale bus kan zetten zodat de host deze er direct vanaf kan halen, en direct kan verwerken. Even ter vergelijking, de PVSCSI driver van vmware.

De LSI Controller doet dit:

Guest App -> IO request -> kernel -> LSI Driver -> LSI Driver -> LSI block device -> LSI Block Device DMA -> ESXi Kernel -> DMA Remapping -> Disk remapping (Guest io transformeren naar een Host IO) -> Host driver (NFS/iSCSI/VMFS w/e) -> Disk

Bij PVSCSI is dat:

Guest App -> IO Request -> kernel -> pvscsi driver -> ESXi disk engine -> Disk.

Et voila, zie het aantal stappen dat je overslaat... Wat jij suggereert over dat een guest bij de hardware van de host kan is (bij vmware iig) volgens mij niet waar... Bij Linux is dat mischien zo, maar bij vmware kan een guest nooit direct bij een netwerkkaart. Zelfs hele geavanceerde features als VMDq (Meerdere netwerkkaarten maken op een fysieke netwerkkaart zodat VM's persoonlijk kunnen offloaden bij een netwerkkaart, is nog steeds niet direct tussen VM en hardware.)

Oke maar al véél beter dan de paar MB/s die je met de standaard geëmuleerde 'HVM' Intel adapter krijgt. En een typische gigabit NAS zit ook zo rond de 75MB/s, al moet ik toegeven dat ik nu 110MB/s write krijg (en 88MB/s read). Snelheden met Samba waren altijd al vreemd. NFS heeft ook zo zijn issues gehad. Maar normaliter werkt NFS toch wel aardig qua doorvoer.

NFS doet hier nu (na het disablen van sync) van buiten af altijd >100MB/s
Alleen vanuit een VM niet. Maar dat ligt aan de VM, niet aan NFS.

Ook wil ik opmerken dat ik via VM platforms nog nooit hoger hebt gehaald dan gigabit. Jij hebt wel ervaring met VMXNET3; hoeveel kreeg je daar via Iperf uitgeperst? En als je virtio test met Linux, werkt dat veel sneller dan met FreeBSD?

Ik heb wel eens VMXNET3 over 10Gb getest met een dure Cisco ertussen, en daar haalde ik 8Gb. VMXNET3 echt volgens mij hard gecapped op 10Gb, maar je zit veel eerder aan je CPU limiet.
Je moet gebruik maken van VM CPU pinning, omdat anders de VM's elk ruzien om CPU's, en dat komt de performance niet ten goede. Gemiddeld kom je tussen de 2 en 4 Gb.

Op een Ubuntu Host haalde ik tussen 2 Ubuntu VM's met VirtIO 18 Gb met iperf in 1 thread. Disk performance was 95% van de host. (zowel iops als sequentieel).

[ Voor 0% gewijzigd door FireDrunk op 25-09-2012 19:56 . Reden: Relativeren thijs, relativeren... ]

[FireDrunk]

God****, en ik maar roepen dat FreeBSD rebootte omdat er te weinig geheugen was... Bleek niet zo te zijn.
Na alles gelimiteerd te hebben en geen VM's te hebben draaien, crashte gister recht onder mijn neus de server nog een keer. Toen toch maar even crashdumps aangezet in /etc/rc.conf. Even wachten en pats.

m_getcluster in ixgbe.ko... Even googlen leerde mij: Er zit een bug in de 10Gb Intel Netwerkdriver....
Bug is al opgelost, kan je in ports nieuwe versie van downloaden...

Heb voor nu even de kaart eruit gehaald, en probleem is daarmee ook over ga ik vanuit.

[Bigs]

Ik ben even iets helemaal kwijt.

Ik heb op mijn FreeBSD machine 1 pool met daarin wat filesystems:

code:

tank                      1.55T   358G  6.47G  /
tank/tmp                  3.43G   358G  3.43G  /tmp
tank/usr                  1.45T   358G  1.53G  /usr
tank/usr/backup           1.45T   358G  1.45T  /usr/backup

Nu wil ik snapshots gaan maken van directories onder /usr/backup, maar dan moeten dat dus eerst losse fs'en worden. Ik meen dat ik dit in het verleden met andere directories ook heb gedaan (om bijvoorbeeld compressie aan te zetten) zonder dat ik de data moest kopiëren naar het nieuwe filesystem maar ik weet niet meer hoe.

Met andere woorden: is er een manier om een directory te promoten naar een filesystem zodat ik er snapshots van kan maken?

[CurlyMo]

Bigs schreef op woensdag 26 september 2012 @ 11:24:
Met andere woorden: is er een manier om een directory te promoten naar een filesystem zodat ik er snapshots van kan maken?

Om kort te zijn: nee

[wjn]

Ik heb in ZFSGuru wat met deduplication gestoeid, voornamelijk bedoeld voor het filesystem waar backups op komen. Voor "normale" acties is de pool zonder L2ARC en/of SLOG voor mij snel genoeg (via Samba 80-90MB/s).

In mijn eigen situatie (PowerEdge 2950, 8GB geheugen met 6x1TB SATA en SSD boot/cache) een aantal test met een 20GB (2 files) uitgevoerd, elke keer 5x gekopieerd (naar verschillende directories) van een laptop met SSD over een 1GB netwerk naar de pool. Jammer dat de filsystems pagina niet laat zien hoeveel dedup er is (compressie staat er wel indien van toepassing).

Resultaten:

	NO L2ARC	L2ARC	L2ARC 80MB/s
1	6 min	6 min	5 min
2	9,5 min	6,5 min	5 min
3	8 min	6 min	5 min
4	8 min	6 min	5 min
5	8 min	6 min	5 min

(Niet tot op de seconde nauwkeurig, maar vooral om de verschillen aan te duiden. Geen SLOG aan.)

Dedup instelling Fletcher4+Verify. De laatste test nog een herhaald met SHA256+Verify, nagenoeg dezelfde tijden voor het kopieren.

L2ARC zorgt dus voor meer constante datastroom (De dedup tabel wordt o.a. op de L2ARC bijgehouden.), kopieren naar een filesystem zonder dedup gaat in ca. 4 min., dus was nog steeds ongeveer 50% langzamer.

Nu schijnt de L2ARC standaard gelimiteerd te zijn op 8MB/s, terwijl de SSD makkelijk het 20-voudige haalt. Door de setting "vfs.zfs.l2arc_write_max" te wijzigen, kun je dat aanpassen. Ik heb het voor deze test op het 10-voudige gezet, 80MB/s. (Je schijnt ruimte (in MB/s) over te moeten houden voor de leesacties, L2ARC is primair natuurlijk de cache.)

Na herstart dus weer snelheid gewonnen, slechts 25% langzamer dan zonder dedup, ca. 60MB/s. (Ik ben tevreden met dit resultaat.)

Ik heb dit resultaat voornamelijk hier neergezet, omdat ik die L2ARC tuning nog nergens in dit topic heb gezien, terwijl het toch een interessant topic is en je daarmee bv. L2ARC ook voor seriele leesacties kan activeren (prefetch).

Wat relevante bronnen:
http://constantin.glez.de.../zfs-dedupe-or-not-dedupe
http://christopher-techni...rformance-real-world.html
http://storagetuning.word...2/01/zfs-tuning-for-ssds/
http://149.20.54.209/showthread.php?t=29907

[CurlyMo]

wjn schreef op woensdag 26 september 2012 @ 17:03:
Jammer dat de filesystems pagina niet laat zien hoeveel dedup er is (compressie staat er wel indien van toepassing).

Dit is wel te zien met het commando "zpool list":

code:

NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
export   928G  47.5G   881G     5%  1.77x  ONLINE  -
rpool    928G  25.7G   902G     2%  1.40x  ONLINE  -

[FireDrunk]

Ik heb helemaal niets gewijzigd aan mijn L2ARC snelheden, en het ding staat vrolijk met 80MB/s te schrijven en soms >100MB/s te lezen... Andere versie van FreeBSD/ZFSguru?

[wjn]

Ik heb de laatste versie geïnstalleerd: version: 0.2.0-beta7

Als ik iostat oid doe, zie ik ook dat de ssd veel sneller is dan die 8MB/s. Toch na het wijzigen van de instelling wordt het kopieren naar het filesystem met dedub sneller. Bij filesystems zonder dedub meet ik geen verschil (verse installatie wellicht).

Ik heb de instelling trouwens gedaan in /etc/sysctl.conf.
In eerste instantie in loader.conf (en zfsguru geeft dan ook gewijzigde instellingen aan in bij advanced system tuning), maar dat gaf geen effect. Pas na het plaatsen van de instelling in /etc/sysctl.conf had ik de snelheidsverbetering.

[FireDrunk]

Hmm ik heb ook dedup geprobeerd maar daar was het inderdaad tergend langzaam.. straks nog maar eens proberen..

[wjn]

Met dedup blijft het langzamer dan zonder. Maar het snelheidsverschil valt me mee en is puur voor backups.

Ik heb er trouwens geen ESXi meer tussen zitten, kreeg de VMXNET net goed aan de praat, geen tijd om dat uit te zoeken en niet perse een extra ESXi server nodig.

@CurlyMo
"zfs list" laat bij mij idd de filesystems zien, maar zonder deduplication.
NAME; USED; AVAIL; REFER; MOUNTPOINT

zpool list geeft wel deduplication weer, maar dan per pool:
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT