Het grote ZFS topic

[Keiichi]

Ik had zojuist iets stoms met een nieuwe ZFS setup. Deze bestaat uit 2 ssd's en 10 hdd's. Op de ssd's staat het OS, zil en l2arc.

Boeltje geinstalleerd met een mirror van 2 parts op de ssd's. Reboot, start op. Daarna van de overige 10 hdd's een nieuwe pool gemaakt 'tank', met 2 partities van de ssd's als zil (mirror). Als ik daarna opgestart, zegt ie: 'gptzfsboot: failed to mount default pool tank' (Als je toegang hebt tot het freebsd forum, dan staat er hier eigenlijk hetzelfde probleem: https://forums.freebsd.or...mount-default-pool.48803/ )

Ik had op een gegeven moment alle schijven eruit getrokken, zelfde fout. Daarna in de shell van de FreeBsd 10.1 installer de zil paritities gecleared (zpool labelclear -f EN dd if=/dev/zero of=/dev/gpt/zil) en toen was er niets aan de hand.

/boot/loader.conf geeft de juiste pool om van te booten, ik zie verder ook nergens referenties naar 'tank' staan dat ie daar ook maar iets mee zou moeten.
Is zroot:tank toevallig ook een default instellen of is dit nog iets wat ergens staat of achtergebleven is?

[CurlyMo]

code:

zpool get bootfs tank

En het zelfde even checken bij je root pool.

[Keiichi]

CurlyMo schreef op vrijdag 27 februari 2015 @ 09:49:

code:

zpool get bootfs tank

En het zelfde even checken bij je root pool.

Dit had ik gechecked, 'zroot' bij de root pool en leeg bij tank (-)

[Anoniem: 15758]

Heb je voorheen pools op de disks gehad die je níet hebt verwijderd met 'zpool destroy' ?

[Keiichi]

Anoniem: 15758 schreef op vrijdag 27 februari 2015 @ 13:49:
Heb je voorheen pools op de disks gehad die je níet hebt verwijderd met 'zpool destroy' ?

Deze keer niet. Ik ben er na lang testen achter, mijn ZIL partitie stond voor de 'root' partitie van m'n zroot. Ik heb 'm helemaal leeggehaald met dd if=/dev/zero of=zildevice en daarna startte ie op. Zil aangezet, toen weer niet. Nu heb ik m'n zil partitie achter de root partitie gezet en nu werkt het weer

[jacovn]

Wat is de snelste manier om veel data van zfs server naar zfs server te copieren?

Ik heb wel wat gelezen over zfs send en receive, maar dat lijkt voor snapshots te zijn.
Op mijn servers heb ik 2 raidz2 pools. Beide pools hebben 1 share. In die share staat films, 1 film per directory.
Stel ik wil bijna alles kopiëren naar een andere server.

Kan ik niet simpelweg een folder mounten en met midnight commander copy paste doen?

[GioStyle]

Pool exporteren, aansluiten op desbetreffende server, pool importeren en kopiëren? Dan ben je niet gebonden aan je netwerksnelheid.

[ Voor 3% gewijzigd door GioStyle op 01-03-2015 21:43 ]

[Keiichi]

Hoe werken in ZFS de ACL's eigenlijk?

Op mijn server was ik inlogd als een gebruiker en ik kon gewoon bestanden weggooien van root. Op het UFS filesystem op dezelfde server ging dat niet (permission denied)

[CurlyMo]

@jacovn, zfs send / receive is daarvoor de manier. Zelfs als je je pool in de betreffende server zet zoals aangeraden door GioStyle, is zfs send / receive de manier om de data over te zetten.

@Keiichi, zonder context (bijv. hoe stond ACL daadwerkelijk ingesteld voor die bestanden) is er niks over te zeggen.

[jacovn]

Het staat zo beschreven (op veel sites)

# zfs send tank/originalfilesystem@now | ssh root@192.168.1.21 "zfs receive tank/copyfilesystem"

Ik snap alleen niet wat in de send kant het voorbeeld @now betekent.
Dat moet dan een snapshot zijn lijkt me, en kan ik die simpelweg maken van het complete systeem (de pool is vrij vol, past een snapshot dan wel ?) Na de zfs send gooi ik die snapshot dan maar weg neem ik aan.

[Anoniem: 15758]

ZFS send/receive kan natuurlijk niet goed werken als data tussen het verzenden in zou veranderen. Dus het gaat inderdaad op basis van snapshots. Maar die kan prima tijdelijk zijn. Maak ff een snapshot; 0.1 seconde, dan zfs send/receive, dan destroy de snapshot.

Wil je ook sub filesystems recursief meenemen, dan moet je daar de juiste parameters voor gebruiken. -R uit mijn hoofd. Zorg dan ook dat je snapshots ook zo hebt gemaakt; recursief. Bij 'zfs snapshot' is de parameter daarvoor -r dus kleine R.

[jacovn]

Ik ben nog wat verder aan het lezen, en het schijnt dan SSH de zaak niet echt bespoedigd met de standaard cipher, je schijnt de NONE cipher dan het beste te gebruiken als je je communicatie pad vetrouwd.

https://forums.freebsd.or...ervers.39575/#post-220133

Die NONE cipher moet ik dan toevoegen op de systemen. Dit lijkt in de HPN ssh patch te zitten, hebben we die in zfsguru ?

http://www.psc.edu/index.php/hpn-ssh

[ Voor 4% gewijzigd door jacovn op 02-03-2015 08:09 ]

[CurlyMo]

@jacovn, kijk even in de linkjes van de eerste post, daar heb ik een paar keer send/receive stap voor stap beschreven.

[jacovn]

Ik zie allerlij links in de openingspost.
- CurlyMo in "Het grote ZFS topic" migreren van data binnen dezelfde pool
- CurlyMo in "Het grote ZFS topic" ZFS send/receive van en naar een bestand

Je refereert in een van die 2 naar een andere "blog" post, ik zal zoeken, want de 2 bovenstaande zijn denk ik niet wat ik nodig heb, maar ik kan me vergissen.

[CurlyMo]

Het linkje naar die betreffende blog post staat er nu ook bij.

@Keiichi, ook heb ik een snippit toegevoegd van mijn ACL setup.

[jacovn]

In deze youtube links wordt ook duidelijk uitgelegd hoe je ZFS send en receive doet tussen 2 servers

http://youtu.be/TwsqKBrZ1t8
http://youtu.be/COOAH_-CLws

[ Voor 35% gewijzigd door jacovn op 02-03-2015 11:23 ]

[dubbi3]

Ik heb de volgende vraag. Ik heb nu een FreeNas systeem gebouwd met 4x 1TB in stripe. Ik merk dat write naar de FreeNas snel is maar Read was voorheen sneller (Ubuntu met RAID0).
Ik gebruik de server voor videobestanden 2 tot 8GB bestanden in Adobe Premiere.

Kan ik een L2ARC/ZIL toevoegen via een SSD? Of is er iets anders wat de performance kan verbeteren?
Mijn netwerkverbinding is een 10gbit uplink naar 10gbit switch.

Thnx!

[tweedebas]

Je werkgeheugen vergroten zodat in die ARC gewoon je videobestanden passen is handiger.

Weet niet hoeveel je nu hebt? Als je al 16 gigabyte hebt checken of je ARC meegroeit naar ik gok ongeveer 12 gig.
Zo niet checken of je arc.max lager staat ingesteld bij de tunables in Freenas.

Deze vraag is een aantal posts terug ook voorbij gekomen met meer uitleg.

[Bigs]

dubbi3 schreef op maandag 02 maart 2015 @ 13:42:
Ik heb de volgende vraag. Ik heb nu een FreeNas systeem gebouwd met 4x 1TB in stripe. Ik merk dat write naar de FreeNas snel is maar Read was voorheen sneller (Ubuntu met RAID0).
Ik gebruik de server voor videobestanden 2 tot 8GB bestanden in Adobe Premiere.

Kan ik een L2ARC/ZIL toevoegen via een SSD? Of is er iets anders wat de performance kan verbeteren?
Mijn netwerkverbinding is een 10gbit uplink naar 10gbit switch.

Thnx!

Hoe benader je die bestanden; NFS, iSCSI, Samba? Hoe snel zijn je reads?

[hansdegit]

"Running official system image 11.0-002 featuring FreeBSD 11.0-CURRENT with ZFS v5000."
"version: 0.2.0-beta10"

Ik gebruik ZFS in een VM die via NFS datastores beschikbaar maakt voor ESXi. Naar nu blijkt, haal ik slechts 10MB /sec over NFS, wat volgens mij een stuk sneller kan. Immers, ik heb SLOGs op SSD's.

Het "simpele" testje wat ik deed was een

code:

dd if=/dev/zero of=./test.out bs=1048576 count=512

op de datastore. Vanaf een VM naar zijn "eigen" vmdk (die dus ook via NFS loopt) zijn de cijfers vergelijkbaar. Vanaf een VM naar ZFSGuru via NFS gaat als de brandweer. Logisch redeneren leert volgens mij dat VMware hier de bottleneck lijkt.

Maarrrr, hoe ga ik dat tacklen?

Wat kan ik ondernemen om de snelheid wat op te voeren?

[dubbi3]

Bigs schreef op maandag 02 maart 2015 @ 15:13:
[...]


Hoe benader je die bestanden; NFS, iSCSI, Samba? Hoe snel zijn je reads?

Via AFP. Zijn allemaal apple clients.

[Anoniem: 15758]

@hansdegit: heb je VMXNET3 ingeschakeld in de /boot/loader.conf? Wat is je 'ifconfig' netwerk device?

[hansdegit]

In /boot/loader.conf staat geen regel die VMXNET3 bevat, hetgeen suggereert dat ik de vmware tools moet installeren. Kan je uitleggen hoe dat zou moeten helpen? NFS naar de ZFS server vanaf andere guests gaat prima; alleen het verkeer vanaf de host naar de door hem via NFS gemounte datastores gaat supersloom. Tenminste, de schrijfacties.

[FireDrunk]

ESXi gebruikt SYNC nfs... De NFS server op FreeBSD kan hier niet zo heel goed mee overweg... Er zijn legio topic over te vinden hoe je dit kan patchen/fixen...

In zeldzame gevallen is het toevoegen van een SLOG niet voldoende...

Probeer het eens met 'zfs set sync=disabled pool/filesystem'.

[ Voor 12% gewijzigd door FireDrunk op 02-03-2015 17:36 ]

[hansdegit]

Thx, ik ga het meteen proberen. Ik had al jouw opmerkingen aangaande NFS prestaties al de revue laten passeren. Kan je een tipje van de sluier oplichten over het patchen van FreeBSD vwb NFS prestaties? Google is ook mijn vriend, maar de zoektermen vinden is nog even lastig. Ben echt he-le-maal niet thuis in FreeBSD.

edit:

teee-ring, wat een verschil! Nu even goed analyseren wat de risico's evt zijn. There's no such thing as a free lunch...

[ Voor 17% gewijzigd door hansdegit op 02-03-2015 17:45 ]

[Anoniem: 15758]

hansdegit schreef op maandag 02 maart 2015 @ 17:25:
In /boot/loader.conf staat geen regel die VMXNET3 bevat, hetgeen suggereert dat ik de vmware tools moet installeren.

Bij mij:

code:

# cat /boot/loader.conf | grep -i vmx
# VMXNET3 network interface driver for ESXi virtualised systems
#if_vmx_load="YES"

VMXNET3 zit standaard in FreeBSD. Je hoeft het enkel te activeren door de bovenstaande laatste twee regels in de /boot/loader.conf te zetten. Handmatig kan ook: kldload if_vmx.

[RobboNL]

Zo ik heb recentelijk mijn Unraid server vaarwel gezegd en draai nu op ZFSGuru. Installatie ging met goede adviezen vooraf van Jacovn, redelijk vlekkeloos. Aangezien ik geen SATA DVD-ROM had was daar een oplossing voor vinden het meeste werk. Uiteindelijk opgelost door het transplanteren van de SSD met de systeem software van een donor PC naar de ZFSGuru server.

Dus er draait nu een Supermicro X10SL7, Intel G3420, 16GB ECC met 10x 4TB Seagates. 120GB SSD met 4TB voor de systeem software en 40GB partitie voor de L2ARC.

Prima het draait dus.

Nu de inhoud van oude Reiserfs schijven van de Unraid server overzetten naar de ZFSGuru server. Ik heb daar wat documentatie over gevonden op de FreeBSD website:

FreeBSD provides read-only support for The Reiser file system, ReiserFS.

To load the reiserfs(5) driver:

# kldload reiserfs
Then, to mount a ReiserFS volume located on /dev/ad1s1:

# mount -t reiserfs /dev/ad1s1 /mnt

De reiserfs schijf zie ik in mijn disk overzicht van de ZFSGuru GUI verschijnen als 'ada0' en in mijn /dev/ zie ik ada0 en adap1.

mounten door het bovenstaande lukt, en ik krijg dan melding
'mount /dev/ada0 read only file system' terug

Maar helaas krijg ik geen inhoud van de schijf te zien als ik op /mnt een 'ls' doe. Op dezelfde schijf zie ik dmv 'rfstool' in Windows wel inhoud. Wat doe ik verkeerd ?

[A1AD]

RobboNL schreef op maandag 02 maart 2015 @ 18:57:
120GB SSD met 4TB voor de systeem software en 40GB partitie voor de L2ARC.

_{Wauw held! Kom je dat bij mij ook eens doen?}

[Anoniem: 15758]

@RobboNL: er staat heel duidelijk read-only support - dat betekent dat je het filesystem niet read-write kan mounten lijkt mij. Dus dien je ook bij het mount commando read-only te mounten:

mount -t reiserfs -r /dev/ada0p1 /mnt

mounten door het bovenstaande lukt

Is dat zo? Wat is de return value dan? echo $? direct na het mount commando. En zie je de mountpoint ook terug bij 'mount' output?

[ Voor 27% gewijzigd door Anoniem: 15758 op 02-03-2015 19:18 ]

[RobboNL]

Dank je Cipher. Ik zat al in die richting te zoeken, ondanks dat je zou verwachten dat het voorbeeld op de Freebsd.org website wel valide zou zijn. Maar ik liep te klooien met de syntax.
Dit zijn mijn eerste schreden op FreeBSD met verder zeer beperkte command line ervaring. Dus je snelle antwoord en je werk aan ZFSGuru worden zeer gewaardeerd. Anders was ik er waarschijnlijk niet aan begonnen.

[RobboNL]

Meteen maar de volgende vraag. Ik zie 1 disk soms terugkomen met een Identified as 'xhci0: Port routing mask set to 0x00000000' en nu vandaag nadat ik van SATA poort gewisseld heb als \ ugen2.2: <vendor 0x8087> at usbus2'.

Iets om mijn zorgen te maken? SMART geeft niks aan. Kabel reeds verwisselt. Het is elke keer dezelfde disk, waar dan soms ook weer correct '<ST4000DM000-1F2168 CC52> ATA-8 SATA 3.x device' staat.

[hansdegit]

Anoniem: 15758 schreef op maandag 02 maart 2015 @ 17:59:
[...]

Bij mij:

code:

# cat /boot/loader.conf | grep -i vmx
# VMXNET3 network interface driver for ESXi virtualised systems
#if_vmx_load="YES"

VMXNET3 zit standaard in FreeBSD. Je hoeft het enkel te activeren door de bovenstaande laatste twee regels in de /boot/loader.conf te zetten. Handmatig kan ook: kldload if_vmx.

Gisteravond een nieuwe ZFSGuru machine opgebouwd op basis van 10.1-002. De VM die ZFSGuru draait heb ik ik VMware een VMXNET3 nic toegekend. Hij draait prima, maar ik kan in /boot/loader.conf nog steeds de desbetreffende regels niet vinden. Moet ik me zorgen maken?

Wél heb ik via Services de vm-vmware-drivers toegevoegd.

iSCSI draait inmiddels ook, echt leuk! zvol aanmaken en die als RDM doorgeven aan de vm, gaat als een trein.

[Bigs]

Ik moet onze FreeBSD backup server vervangen door een Linux+ZFSonLinux oplossing ivm software die erop moet komen te draaien die niet in FreeBSD werkt.

Kan ik de pool van mijn FreeBSD installatie gewoon importeren in ZFSonLinux? De server boot van een losse SSD, dus daar kan ik eenvoudig Linux op zetten. Het is een v5000 pool met async_destroy, empty_bpobj, lz4_compress en multi_vdev_crash_dump flags ingeschakeld. Het zou wel echt een uitkomst zijn, dan hoef ik namelijk geen tijdelijk onderkomen te zoeken voor de 10TB data die er al op staat.

[edit]
Ik zie dat ZoL de multi_vdev_crash_dump niet ondersteunt. Ik kan deze echter niet uitzetten:

code:

# zpool set feature@multi_vdev_crash_dump=disabled backup
cannot set property for 'backup': property 'feature@multi_vdev_crash_dump' can only be set to 'enabled'

Iemand suggesties? De feature staat 'enabled', niet 'active' dus misschien zou het gewoon moeten werken. Uit zpool-features(7):

enabled An administrator has marked this feature as enabled on the
pool, but the feature's on-disk format changes have not been
made yet. The pool can still be imported by software that does
not support this feature, but changes may be made to the
on-disk format at any time which will move the feature to the
active state. Some features may support returning to the
enabled state after becoming active. See feature-specific doc-
umentation for details.

Wellicht eens kijken of ik hem met een live CD kan importeren als test.

[ Voor 51% gewijzigd door Bigs op 04-03-2015 12:28 ]

[VorCha]

Bigs schreef op woensdag 04 maart 2015 @ 12:12:
Kan ik de pool van mijn FreeBSD installatie gewoon importeren in ZFSonLinux?

Wellicht eens kijken of ik hem met een live CD kan importeren als test.

Mijn ervaring is dat je gewoon kunt importeren van FreeBSD naar ZFSonLinux.

Een test is natuurlijk goed en prima te doen (zorg desondanks voor een backup maar dat bedoel ik meer als algemene regel). Exporteer de pool eerst voordat je het ergens anders gaat importeren. Je kunt wel geforceerd importeren, maar de nette manier is altijd beter.

[Bigs]

Thanks voor je reactie. Het importeren van de pool werkte zoals verwacht zonder problemen!

ZoL was ook redelijk eenvoudig op te zetten (had alleen even een versie mismatch tussen m'n kernel en kernel-headers).

[FireDrunk]

Hmmm... Mijn storage server (Ubuntu 14.04.2 LTS) wil niet meer booten omdat de ZFS mount keihard blijft hangen...

Interesting... Nu eerst naar een verjaardag, maar vanavond maar eens kijken.

Wat ik zo kan zien: Hij blijft gewoon keihard hangen zodra er iets met ZFS gedaan moet worden.
Klinkt als: Pool is te vol

* FireDrunk moet een nieuwe array maken...

Hmm, met wat reboots werkt het nu eens wel.. Vage shit...

[ Voor 7% gewijzigd door FireDrunk op 06-03-2015 20:13 ]

[Anoniem: 15758]

Soms heb je ook veel RAM nodig bij het importeren van een pool; kan dat het zijn misschien?

[FireDrunk]

Mja, kan, VM heeft 8GB, zou toch wel genoeg moeten zijn... Zal straks de logs eens doorspitten.

[jacovn]

Niet gehinderd door al te veel kennis dacht ik eens een snapshot te maken en weer weg te gooien.
Helaas een pool weg gegooid omdat ik de snapshot naam vergeten was
zfs destroy -r Movietank4/share

Nu zie ik in de gui van zfsguru nog wel dat er 14 TB aan data lijkt te staan.

Kan ik dit nog terughalen ?

De snapshot stond blijkbaar in de share, want die zie ik niet meer met zfs list -t snapshot

[Mystic Spirit]

Het is mij gelukkig nooit overkomen, maar volgens mij moet dat kunnen. Je kan het weer importeren met "zpool import -D".

[ Voor 12% gewijzigd door Mystic Spirit op 09-03-2015 14:19 ]

[jacovn]

ZFS Guru meldt dat er geen deleted pools zijn om te importeren.

Ik ga het wel weer downloaden, zal wel even duren

[ Voor 30% gewijzigd door jacovn op 09-03-2015 14:39 ]

[Anoniem: 15758]

Je hebt ook geen pool gedelete maar een filesystem; en dat kun je niet undo-en.

Het is vervelend, maar dit is inderdaad ook de manier hoe ik (lang geleden) mijn eerste data op ZFS kwijtraakte. Daarom is een web-interface ook zo handig omdat je dan die fouten niet kunt maken: snapshot management zit op een andere pagina dan het (recursief) verwijderen van filesystems.

Het was opzich wel fijn geweest als er ook een undelete voor dit soort operaties was. Maarja, niet dus.

[jacovn]

ach ja, het zijn maar films. wijze les geleerd

Ik wilde die pool leeg hebben, dat is hij nu. Niet geheel de manier die ik bedacht had..

[Pantagruel]

jacovn schreef op maandag 09 maart 2015 @ 14:43:
ach ja, het zijn maar films. wijze les geleerd

Ik wilde die pool leeg hebben, dat is hij nu. Niet geheel de manier die ik bedacht had..

Een beetje bitter, maar t ruimte wel lekker op.
Ik gok dat iedereen wel es een fatale tikfout of te snel op de enter toets heeft gerost zonder het ingetikt commando door te denken.

[jacovn]

Pantagruel schreef op maandag 09 maart 2015 @ 15:07:
[...]


Een beetje bitter, maar t ruimte wel lekker op.
Ik gok dat iedereen wel es een fatale tikfout of te snel op de enter toets heeft gerost zonder het ingetikt commando door te denken.

Tja shit happens. ach ruimt wel weer lekker op inderdaad..

[Habana]

Dass Balen, daarom heb ik mijn oude Synology nas maar in ere hersteld en gebruik deze als 12TB back-up, het zou mij als noob in ZFS ook maar zo kunnen gebeuren, vraagt wel wat extra financiële investeringen maar dat is mij wel waard.

[hansdegit]

Vraagje:

Ik heb een zvol via iSCSI aangeboden aan een Debian Mariadb server. Iedere 2 uur maak ik in zfsguru een snapshot van dit zvol. Ik zou het wel prettig vinden als ik de inhoud van het zvol aan mijn crashplan server kan aanbieden ter backup.

Ik heb geprobeerd rechtstreeks een snapshot van dat zvol te mounten, ik heb ook geprobeerd om een clone van een snapshot van het zvol te mounten:
"Operation not supported by device"

Alternatief is natuurlijk om de db server zélf zijn backup te laten verzorgen en met rsync de files naar een te backuppen share stuur. Maar dan zou ik tijdelijk de database moeten stoppen omwille van de consistentie. Juist die snapshot technologie is zo cool.

Iemand een idee?

[Bigs]

Als dat zvol een partitietabel bevat kun je hem natuurlijk niet zomaar mounten. Wat is de inhoud van je zvol precies?

Let op dat je MariaDB backup op deze manier alleen betrouwbaar is als je het snapshot maakt tussen een FLUSH TABLES WITH READ LOCK en UNLOCK TABLES.

[hansdegit]

Het zvol bevat een ext4 filesystem wat door de Debian db server gemount wordt, aangeboden als iSCSI via VMware.

Ook met InnoDB? Ben een Oracle man van huis uit en zie veel parallellen met InnoDB.

Het past niet helemaal in deze discussie, maar een snapshot is toch een momentopname van de toestand van een filesysteem of zvol? Aangezien de database de write-ordering bewaakt, mag ik er toch vanuit gaan dat het snapshot consistent is? Dwz: ieder zichzelf respecterend db systeem schrijft eerst de logs en daarna de files. Consistentie gewaarborgd op transactieniveau.

[ Voor 11% gewijzigd door hansdegit op 09-03-2015 23:03 ]

[CurlyMo]

Een snapshot moet inderdaad gewoon te mounten zijn als iSCSI mits goed ingesteld.

[hansdegit]

Misschien handig om mijn doel wat beter te specificeren:
ik wil de inhoud van het zvol kunnen backuppen vanaf een andere server. En als dat niet kan, dan in ieder geval de mogelijkheid hebben om het volledige zvol als file voor de backupserver toegankelijk te maken, zodat de backupserver dat zvol naar Crashplan kan sturen.

[Bigs]

hansdegit schreef op maandag 09 maart 2015 @ 23:01:
Het zvol bevat een ext4 filesystem wat door de Debian db server gemount wordt, aangeboden als iSCSI via VMware.

Ook met InnoDB? Ben een Oracle man van huis uit en zie veel parallellen met InnoDB.

Het past niet helemaal in deze discussie, maar een snapshot is toch een momentopname van de toestand van een filesysteem of zvol? Aangezien de database de write-ordering bewaakt, mag ik er toch vanuit gaan dat het snapshot consistent is? Dwz: ieder zichzelf respecterend db systeem schrijft eerst de logs en daarna de files. Consistentie gewaarborgd op transactieniveau.

Je hebt gelijk, als je uitsluitend InnoDB gebruikt (al is de mysql database zelf nog altij MyISAM) lijkt het expliciet locken niet nodig te zijn als ik de diverse fora moet geloven. Echter heeft MySQL sinds 5.6 wel een speciale 'FLUSH TABLES … FOR EXPORT' die speciaal voor snapshots icm InnoDB lijkt te zijn ontworpen, dus wat nou waarheid is?

_{Sorry voor het off-topic gaan maar wilde hansdegit niet onterecht op een dwaalspoor zetten}

[Pantagruel]

CurlyMo schreef op maandag 09 maart 2015 @ 23:02:
Een snapshot moet inderdaad gewoon te mounten zijn als iSCSI mits goed ingesteld.

Second that.

Bij gebruik van OpenIndiana was t redelijk eenvoudig: snapshot clonen, lun aanmaken, lun aanbieden, lun mounten op de target machine et le voila klaar voor een roll-back/browse

[killercow]

Ik ben een nieuwe storageserver aan t bouwen, maar mn performance is maar matig, ongetwijfeld door mn brakke kennis van zfs en aanverwante technieken. Maargoed, daarom zijn we hier, om er mee te spelen en van te leren.

De situatie:
* Supermicro A1SAM-2750F, Avaton cpu (4/8core)
* Adaptec RAID 52445 op pci-e 8x, 512GB battery backed write cache
* 10x Seagate 8TiB archive disks
* Stapeltje sas kabels + sas-> sata backplanes voor de hotswap
* 1x 250GB ssd
* 4x 8GB ecc ram

Ik draai ubuntu 14.10 met de zfs kernel module, dit is geinstalleerd op de ssd.
De 10 hdd's zijn in een raidz3 pool gestopt en gemount. Hier is 50TB beschikbaar

Als ik files copy van de ssd (of uit ram), naar de zfs pool (in een los filesystem) schiet mn iowait naar 100% op een of meer cpu's, heb ik erg lage write-performance (tussen de 17MB/s en 60MB's)
Als ik uit /dev/zero naar een file schrijf op de zfs pool schrijf ik met ~80MB/s, maar soms ook met tussenpozen van een minuut of meer met geen enkele byte (want, iowait)

Waar moet ik zoeken?
Ik kan natuurlijk de hele zooi eens proberen met btrfs, zien of de hardware zelf de snelheden wel haalt die ik verwacht, of zelfs als single disks, of onder mdadm.

Ik heb geen speciale flaggetjes gebruikt bij het aanmaken van mn zfs pool behalve de raidz3 optie.

[FREAKJAM]

arc_min en arc_max ingesteld?

[ Voor 57% gewijzigd door FREAKJAM op 10-03-2015 12:07 ]

[Anoniem: 15758]

De 10 hdd's zijn in een raidz3 pool gestopt

Gaat het om 4K disks en dus een pool met ashift=12? Want dan is 10 disks niet optimaal; 11 disks wel. Zie ook de topicstart.

[killercow]

Anoniem: 15758 schreef op dinsdag 10 maart 2015 @ 12:13:
[...]

Gaat het om 4K disks en dus een pool met ashift=12? Want dan is 10 disks niet optimaal; 11 disks wel. Zie ook de topicstart.

Het gaat inderdaad om 10 disks, met 4k block size (al weet ik niet zeker of zfs dat netjes kan detecteren besef ik me nu) gezien ze achter de aacraid driver zitten (welke ze met expose_physicals=1 als losse disks aan t OS aanbiedt)

Gezien de controller inweze niks doet dan dure sas controller spelen maar mogelijk wel in de weg zit voor dit soort herkennings-trucjes, hoe zie ik de block-size die zfs denkt te hebben gezien?

Ik heb een arc_min en arc_max ingesteld en gereboot, nu zie ik dat na een copy in ieder geval mn ram voor 22gb aan cache is gevuld en netjes de arc_max van 8gb aan zfs data. Nu kom ik op 217MB/s uit, dat is al nuttiger, en zo te zien geen enge iowait spikes meer. Wat voor snelheden moet ik uberhaupt kunnen behalen volgens de kenners?

[FireDrunk]

Het zijn Seagate Archive disks. Ik ben erg beniewd wat de single disk performance is.
Kan je eens testen wat 1 zo'n disk doet?

[Anoniem: 15758]

De schijven kunnen tot 200MB/s sequential, maar bij non-contigous I/O kan de snelheid behoorlijk inzakken.

Zie ook deze review: http://www.storagereview.com/seagate_archive_hdd_review_8tb.

Toch zou ik graag eens de ZFS performacne zien bij een optimale 10-disk RAID-Z2 pool bijvoorbeeld. Dan de pool leeg houden en gewoon met dd if=/dev/zero of=zerofile bs=1M een groot bestand schrijven en kijken hoe snel dat gaat na een aantal minuten.

[FireDrunk]

Wow, die review had ik nog niet gezien...

212ms hoogste latency, met een gemiddelde van 70ms bij een queue depth van 16 voor random writes...

Dat is best wel heel erg hoog...

Ze stippen terecht aan dat rebuilds funest zijn (ze laten het verschil in rebuild tijd duidelijk zien, de Hitachi doet er 19 uur over, de Seagate 57).

[hansdegit]

Pantagruel schreef op dinsdag 10 maart 2015 @ 08:59:
[...]


Second that.

Bij gebruik van OpenIndiana was t redelijk eenvoudig: snapshot clonen, lun aanmaken, lun aanbieden, lun mounten op de target machine et le voila klaar voor een roll-back/browse

Rollback was inderdaad al geregeld met de snapshots. Maar de backup? Ik denk dat ik er niet aan ontkom om met tar oid dagelijks alle database files even over te zetten naar een NFS share.

Aan de commentaren te lezen lijkt het niet mogelijk om een clone of snap van een ext4 iSCSI volume te mounten en te lezen vanaf de ZFS machine zelf.

[Pantagruel]

hansdegit schreef op dinsdag 10 maart 2015 @ 14:24:
[...]

Rollback was inderdaad al geregeld met de snapshots. Maar de backup? Ik denk dat ik er niet aan ontkom om met tar oid dagelijks alle database files even over te zetten naar een NFS share.

Aan de commentaren te lezen lijkt het niet mogelijk om een clone of snap van een ext4 iSCSI volume te mounten en te lezen vanaf de ZFS machine zelf.

Onder ZoL kun je een snapshot regulier 'mounten'

code:

mount -t zfs tank/snapshot-name /mnt/snapshot/tank

(en natuurlijk umount /mnt/snapshot/tank naderhand).

Als je nu de snapshot cloned

code:

zfs clone vol0/iscsi-vol@tankl vol0/iscsi-vol-clone

en je runt daarna

code:

fdisk -l

krijg je dan een nieuw block device te zien? (bijv. /dev/zd1p1

Zo ja dan kun je deze mounten (mits de ZFS machine iets snap van t fs van je block device)

code:

mount -t ext4 -o nouuid /dev/zd1p1 /restore

[killercow]

Anoniem: 15758 schreef op dinsdag 10 maart 2015 @ 13:45:
De schijven kunnen tot 200MB/s sequential, maar bij non-contigous I/O kan de snelheid behoorlijk inzakken.

Zie ook deze review: http://www.storagereview.com/seagate_archive_hdd_review_8tb.

Toch zou ik graag eens de ZFS performacne zien bij een optimale 10-disk RAID-Z2 pool bijvoorbeeld. Dan de pool leeg houden en gewoon met dd if=/dev/zero of=zerofile bs=1M een groot bestand schrijven en kijken hoe snel dat gaat na een aantal minuten.

Ik zal vanavond eens wat testjes draaien, is een Raidz2 qua parity / non-recoverable read errors geen issue met 10 disks? Niet dat t veel boeit, maar dan is een 11de disk aanschaffen niet nodig.

Ik heb nu ook geen ssd als arc-cache oid ingezet, dit kan natuurlijk ook nog behoorlijk wat schelen, maar voor nu leek een overzichtelijke setup me handiger.

[vanaalten]

Nou zat ik mij net te bedenken dat ik waarschijnlijk 4K schijven in m'n ZoL mirror-setup heb (check: WD Green WD60EZRX = 4k) en dat ik bij het aanmaken van de mirror geen seconde over de ashift-waarde heb nagedacht.

Na wat googlen kwam ik op het volgende uit:

code:

root@nas:/# zpool get ashift
NAME      PROPERTY  VALUE   SOURCE
datapool  ashift    0       default

... waarde 0 betekent auto-detect.

Daarna:

code:

root@nas:/# zdb -l  /dev/disk/by-partlabel/DATAPOOL-A-WD-WX51H3xxxxxx | grep ashift
        ashift: 12
        ashift: 12
        ashift: 12
        ashift: 12

Klopt m'n conclusie dat de disken zelf al rapporteren dat het schijven zijn met 4k sectoren - en dat ZFS dus met autodetect ook de juiste sectorgrootte gebruikt?

[Anoniem: 15758]

Min of meer; je kunt detecteren dat het AF-schijven zijn. Zo werkt het onder FreeBSD ook. Die doet nu automatisch 4K optimalisatie. Maar je wilt dit niet altijd omdat het je heel veel ruimte kan kosten in bepaalde pool/disk-configuraties.

In jouw geval heb je een mirror dus zowel ruimte als performance is heel veel minder belangrijk dan wanneer je RAID-Z-familie had gedraaid. Juist voor RAID-Z1/2/3 is de ashift zo cruciaal. Bij mirrors en single disks nauwelijks.

[FireDrunk]

@killercow, ik zou trouwens sowieso die Adaptec RAID controller ertussen uit slopen... Die zorgt alleen maar voor meer ellende...

[tweedebas]

Zojuist een nieuw systeem besteld, waar ik Zfs op wil draaien, zie post in DIY RAID NAS topic.

Om het leuk in te richten was ik over een aantal dingen nog niet uit.

Maakt het met lz4 compressie nog uit of je een 4disk Raidz1 ipv een 3 disk Raidz1?
Dit in verband met macht van 2 schijven en ik ga er even van uit dat het 4k schijven zijn.
Heb er al verschillende dingen over gelezen, en hoe ver van optimaal is het, niet merkbaar, of onwerkbaar.

Kan je binnen Freenas de Jails verplaatsen nadat ze aangemaakt zijn?
Zodra ik een SSD over heb wil ik die gaan gebruiken om o.a. de jails op te plaatsen, torrent, nzb, plex, eventueel Freebsd jail met webserver.
Met als doel om de schijven idle te krijgen voor een spindown.

[FireDrunk]

Compressie uit, misschien merkbaar onder specifieke load.
Compressie aan, niet merkbaar.

[jacovn]

Ik heb een vraag, hoe gaat een zfsguru machine, of freebsd in het algemeen er mee om als er via een extender hdds aan hangen die in een ander fysiek chassis zitten, maar niet ingeschakeld zijn?
Loopt het systeem dan gewoon goed met de interne hdd's en komen bij een reboot als extern chassis aan staat de extra pool er weer bij zonder issues ?

Of kun je wel een chassis bijschakelen als de machine loopt ?
Uitzetten lijkt me minder snugger als de zaak loopt..

[FireDrunk]

Definieer "uitgeschakeld"? Powered Off?

[jacovn]

Power off inderdaad.

Ik heb een Intel RES2SV240 SE91267 RAID Expander SAS/SATA gekocht.
Verder nog een sff8087 naar sff8088 converter en een sff8088 kabel voor weinig via ebay.

Dan kan ik nog een extra box nemen met 10 hdd's met een extender erin, en dan die op een sff8087 poort van een m1015 aansluiten.

Maar als die altijd ook aan moet staan tijdens bootup van de server is het minder interessant.

[Bigs]

Toch even een waarschuwing voor mensen die ZFSonLinux overwegen in een drukke zakelijke omgeving: sinds wij zijn overgestapt van FreeBSD naar ZOL op CentOS 7 (zelfde pool en hardware) hebben we behoorlijke issues met onze pool. Diverse ZFS achtergrondtaken gebruiken regelmatig 100% CPU en bij druk verkeer (veel I/O met kleine bestanden) loopt het systeem soms helemaal vast met een load van >40. We kunnen dan zelfs niet meer inloggen op de console en een harde reset is dan de enige oplossing. Ik heb nu een top in een ooghoek draaien in de hoop dat ik een aanknopingspunt kan vinden maar deze issues zijn natuurlijk niet echt makkelijk te debuggen.

Qua stabiliteit haalt ZOL het in mijn ervaring dus nog niet bij FreeBSD en Illumos.

[matty___]

Bigs schreef op maandag 16 maart 2015 @ 09:03:
Toch even een waarschuwing voor mensen die ZFSonLinux overwegen in een drukke zakelijke omgeving: sinds wij zijn overgestapt van FreeBSD naar ZOL op CentOS 7 (zelfde pool en hardware) hebben we behoorlijke issues met onze pool. Diverse ZFS achtergrondtaken gebruiken regelmatig 100% CPU en bij druk verkeer (veel I/O met kleine bestanden) loopt het systeem soms helemaal vast met een load van >40. We kunnen dan zelfs niet meer inloggen op de console en een harde reset is dan de enige oplossing. Ik heb nu een top in een ooghoek draaien in de hoop dat ik een aanknopingspunt kan vinden maar deze issues zijn natuurlijk niet echt makkelijk te debuggen.

Qua stabiliteit haalt ZOL het in mijn ervaring dus nog niet bij FreeBSD en Illumos.

Misschien niet van toepassing maar je zou de linux apps die je per se nodig hebt in een bhyve vm kunnen draaien zodat je toch ZFS op FreeBSD kunt blijven gebruiken.

[FireDrunk]

Bigs schreef op maandag 16 maart 2015 @ 09:03:
Toch even een waarschuwing voor mensen die ZFSonLinux overwegen in een drukke zakelijke omgeving: sinds wij zijn overgestapt van FreeBSD naar ZOL op CentOS 7 (zelfde pool en hardware) hebben we behoorlijke issues met onze pool. Diverse ZFS achtergrondtaken gebruiken regelmatig 100% CPU en bij druk verkeer (veel I/O met kleine bestanden) loopt het systeem soms helemaal vast met een load van >40. We kunnen dan zelfs niet meer inloggen op de console en een harde reset is dan de enige oplossing. Ik heb nu een top in een ooghoek draaien in de hoop dat ik een aanknopingspunt kan vinden maar deze issues zijn natuurlijk niet echt makkelijk te debuggen.

Qua stabiliteit haalt ZOL het in mijn ervaring dus nog niet bij FreeBSD en Illumos.

Ik ben heel erg beniewd wat jullie tuning/parameters zijn voor ZFS, geen idee of je die informatie mag delen, maar ik zou het erg leerzaam vinden om te horen welke instellingen misschien juist *niet* goed werken.

[Bigs]

FireDrunk schreef op maandag 16 maart 2015 @ 09:49:
[...]

Ik ben heel erg beniewd wat jullie tuning/parameters zijn voor ZFS, geen idee of je die informatie mag delen, maar ik zou het erg leerzaam vinden om te horen welke instellingen misschien juist *niet* goed werken.

Eigenlijk nu gewoon de standaardinstellingen. Op FreeBSD tuneden we ook niets en het lijkt erop dat dat met ZoL ook niet nodig is (als je het standaardgedrag van de ARC geen probleem vindt).

Enige wat er op het systeem draait zijn een aantal rsync processen. Ik zit er nu bovenop maar je zult zien dat het dan altijd goed werkt Zodra ik iets ontdek meld ik het hier als eerste, uiteraard.

[FireDrunk]

Dat is dus (in mijn ogen) een foute aanname... Het is bekend dat ZFS' Memory Management niet helemaal lekker samengaat met Linux' kernel memory management. ARC moet je sowieso een hard limiet geven, anders gaat het niet altijd goed.

Bovendien moet je goed opletten bij het gebruik van ZVOL's, want ook daar is het geheugen gebruik soms wat buitensporig (bekend probleem,wordt aan gewerkt volgens mij).

En bij vol geheugen krijg je precies wat jij beschrijft, hoge CPU load, en een instabiel systeem.

[ Voor 11% gewijzigd door FireDrunk op 16-03-2015 10:33 ]

[Bigs]

FireDrunk schreef op maandag 16 maart 2015 @ 10:32:
Dat is dus (in mijn ogen) een foute aanname... Het is bekend dat ZFS' Memory Management niet helemaal lekker samengaat met Linux' kernel memory management. ARC moet je sowieso een hard limiet geven, anders gaat het niet altijd goed.

Bovendien moet je goed opletten bij het gebruik van ZVOL's, want ook daar is het geheugen gebruik soms wat buitensporig (bekend probleem,wordt aan gewerkt volgens mij).

En bij vol geheugen krijg je precies wat jij beschrijft, hoge CPU load, en een instabiel systeem.

Hmm vreemd dat daar dan in geen enkele ZoL documentatie over wordt gerept (dat een hard limit essentieel is).

De ARC is volgens 'size' in /proc/spl/kstat/zfs/arcstats nu 8,3GB, iets meer dan de helft van het RAM in het systeem. Het systeem heeft nu pas een uptime van 2 uur dus het zou kunnen zijn dat dit op termijn voor problemen zorgt inderdaad. Ik wil het wel eerst fout zien gaan voordat ik een limiet instel, anders vervang je de een aanname door een andere en weet je nog niet of je nu echt de oorzaak hebt aangepakt.

[edit]
Onder een volledige load blijft de ARC tot nu toe ook netjes rond de 8GB schommelen, dus de automatische ARC tuning van ZoL lijkt goed te werken.

[ Voor 6% gewijzigd door Bigs op 16-03-2015 14:03 ]

[Q]

Persoonlijk heb ik nooit gezien dat ZFS ook na lang gebruik al het geheugen wegdrukt en dat het systeem instabiel wordt. Ik heb echter altijd recente ZoL versies gebruikt. Volgens mij kiezen die zelf al automatisch een limiet op basis van RAM capaciteit.

[FireDrunk]

Ik heb het zelf een aantal keer meegemaakt. Zonder hard limiet ging ARC aan de wandel. Ook al is er een dynamisch limiet ingesteld door ZFSonLinux.

Geen idee hoe hoe het komt, en ik had er vooral last van icm ZVOL's.

Overigens zijn er nog best wat issues bekend:
https://www.google.nl/?q=...%20high%20load&gws_rd=ssl

[ Voor 21% gewijzigd door FireDrunk op 16-03-2015 11:19 ]

[RobinMM]

Ik ben aan het testen met een ZFS box, op basis van een i5 2300, 16g en 4 notebook harddisks. Onderstaand wat resultaten van pool benchmarks. Deze zien er in mijn ogen prima uit. Daarna ben ik gaan testen met samba shares, en de read snelheid valt me erg tegen. Die blijft rond de 50MB/s terwijl de Writes gaan met +- 90MB/s. Wat kan hiervan de oorzaak zijn? Ik heb getest met zowel ZFSguru 10.0-001 en 11.0-003. Beide geven nagenoeg dezelfde resultaten.

RAIDZ 3x500gb notebook disk

ZFSguru 0.2.0-beta9 (10.1-001) pool benchmark
Pool : media (1.36T, 0% full)
Test size : 64 GiB
normal read : 109 MB/s
normal write : 128 MB/s
I/O bandwidth : 29 GB/s

RAIDZ 4x500gb notebook disk

ZFSguru 0.2.0-beta9 (10.1-001) pool benchmark
Pool : mediatest (1.81T, 0% full)
Test size : 64 GiB
normal read : 251 MB/s
normal write : 194 MB/s
I/O bandwidth : 28 GB/s

RAIDZ2 4x500gb notebook disk

ZFSguru 0.2.0-beta9 (10.1-001) pool benchmark
Pool : mediatest (1.81T, 0% full)
Test size : 64 GiB
normal read : 178 MB/s
normal write : 123 MB/s
I/O bandwidth : 29 GB/s

RAID0 1x500gb Hitachi Z5K500

ZFSguru 0.2.0-beta9 (10.1-001) pool benchmark
Pool : mediatest (464G, 0% full)
Test size : 64 GiB
normal read : 93 MB/s
normal write : 50 MB/s
I/O bandwidth : 28 GB/s


RAID0 2x500gb Hitachi Z5K500

ZFSguru 0.2.0-beta9 (10.1-001) pool benchmark
Pool : mediatest (928G, 0% full)
Test size : 64 GiB
normal read : 170 MB/s
normal write : 125 MB/s
I/O bandwidth : 29 GB/s

RAID0 4x500gb notebook disk

ZFSguru 0.2.0-beta9 (10.1-001) pool benchmark
Pool : mediatest (1.81T, 0% full)
Test size : 64 GiB
normal read : 304 MB/s
normal write : 316 MB/s
I/O bandwidth : 28 GB/s

RAID1 2x500gb Hitachi Z5K500

ZFSguru 0.2.0-beta9 (10.1-001) pool benchmark
Pool : mediatest (464G, 0% full)
Test size : 64 GiB
normal read : 112 MB/s
normal write : 47 MB/s
I/O bandwidth : 29 GB/s


RAID10 4x500gb notebook disk

ZFSguru 0.2.0-beta9 (10.1-001) pool benchmark
Pool : mediatest (928G, 0% full)
Test size : 64 GiB
normal read : 217 MB/s
normal write : 118 MB/s
I/O bandwidth : 28 GB/s

[matty___]

RobinMM schreef op maandag 16 maart 2015 @ 13:34:
Ik ben aan het testen met een ZFS box, op basis van een i5 2300, 16g en 4 notebook harddisks. Onderstaand wat resultaten van pool benchmarks. Deze zien er in mijn ogen prima uit. Daarna ben ik gaan testen met samba shares, en de read snelheid valt me erg tegen. Die blijft rond de 50MB/s terwijl de Writes gaan met +- 90MB/s. Wat kan hiervan de oorzaak zijn? Ik heb getest met zowel ZFSguru 10.0-001 en 11.0-003. Beide geven nagenoeg dezelfde resultaten.

Wat voor NIC heb je en wat is je client?

[FireDrunk]

Samba is gewoon een beetje brak. Probeer eens een simpele samba tuning guide te volgen waarin wat options gezet worden.

[RobinMM]

Client is Windows 7 met realtek nic, de zfs box heeft een intel pro nic geloof, beide onboard.

[Pakjebakmeel]

Ik zit met een aantal vragen.. Ik heb nu:

6x3TB
2x2TB

De 6x3TB is een dedicated RAIDZ2 data pool. De 2x 2TB heeft MDADM raid boot, swap en root. De overige ruimte, ongeveer 1.9TB is een ZFS mirror. Partities dus.

Het Z2 is voornamelijk voor storage, leuke doorvoersnelheid maar weinig IOPS. Mijn KVM VM's draai ik op ZVOLs, verdeeld over de mirror en het Z2 array om nog een beetje IOPS te halen.

code:

NAME                       USED  AVAIL  REFER  MOUNTPOINT
raid1                      427G  1.27T  14.7G  /mnt/raid1
raid1/vm                   413G  1.27T   136K  none
raid1/vm/cli00             103G  1.27T   136K  none
raid1/vm/cli00/dsk00       103G  1.36T  18.1G  -
raid1/vm/srv00             103G  1.27T   136K  none
raid1/vm/srv00/dsk00       103G  1.36T  13.5G  -
raid1/vm/srv01             103G  1.27T   136K  none
raid1/vm/srv01/dsk00       103G  1.36T  13.4G  -
raid1/vm/srv02             103G  1.27T   136K  none
raid1/vm/srv02/dsk00       103G  1.36T  13.5G  -
storage                   5.75T  4.91T  4.89T  /mnt/raidz2
storage/vm                 434G  4.91T   272K  none
storage/vm/freddie         125G  4.91T   272K  none
storage/vm/freddie/dsk00   125G  5.01T  21.5G  -
storage/vm/john            103G  4.91T   272K  none
storage/vm/john/dsk00      103G  5.00T  9.10G  -
storage/vm/mike            103G  4.91T   272K  none
storage/vm/mike/dsk00      103G  5.01T   144K  -
storage/vm/roger           103G  4.91T   272K  none
storage/vm/roger/dsk00     103G  4.96T  44.2G  -

Ik zit er aan te denken om 2 SSD te nemen speciaal voor de lading IOPS van alle VM's, hier gaan dus mijn vragen over.

Ik zat te denken aan SLOG en L2ARC op de mirror om de bursts van IO op te vangen. Echter na veel leeswerk lijkt een SLOG niet altijd alle writes op te vangen. Het is aan veel factoren afhankelijk en ik krijg de indruk dat vooral sequential writes met sync baat hebben bij SLOG, juist geen random IO.

-of-

SSD's in een mirror, 2x250GB ofzo. Performance zal wel oke zijn, gelezen over x-data-plane en dergelijke. Nadeel is natuurlijk veel minder ruimte dan bij een SLOG en L2ARC op de mirror zetten.

Vraag1: Heeft een SLOG en L2ARC op de mirror zin om IO van meerdere VM's op te vangen? Als bijvoorbeeld 2 of meer VM's bezig zijn updates te installeren.

Vraag2: Hoe gaat ZFS tegenwoordig om met TRIM?

Vraag3: Hoe presenteer ik een ZVOL met als eigenschap 'non-rotational'? De VM die het ZVOL gaat ontvangen mag natuurlijk niet gaan defragmeteren en dergelijke, ik neem aan dat ZFS dan een ZVOL moet aanmaken met als eigenschap dat deze non-rotational is. Zodra Windows een disk krijgt toegewezen die 'non-rotational' is zet het OS prefetch en defrag en zaken uit om de SSD te sparen.

Kan iemand mij een zinnig advies geven? Ik ben al een tijdje internet aan het afscheumen maar ik wordt er niet veel wijzer van..

[Anoniem: 15758]

Vraag1: Hangt helemaal af hoeveel sync I/O je doet of sLOG een voordeel biedt. Als je een goede SSD neemt kun je beide doen en dat kan voordeel hebben. Zeker niet alleen voor sequential I/O het zijn vooral de random sync writes die sLOG zal accelereren. Dat zijn metadata writes van je filesystem op je ZVOL.

Vraag2: FreeBSD ondersteunt propertjes ZFS. Er zijn recent wat commits voor TRIM op ZVOLs geland op HEAD (FreeBSD -CURRENT). Alleen FreeBSD ondersteunt TRIM op ZFS voor zover ik weet (correcties welkom!)

Vraag3: Hoe je een ZVOL non-rotational krijgt; geen idee! Ik denk dat dit weinig met de ZVOL te maken heeft, maar eerder een instelling van de iSCSI daemon is.

[FireDrunk]

Af en toe een defragmentatie doet je ssd niets hoor. Ik zou me daar niet druk om maken... Heel, heel vroeger, in het begintijdperk van SSDs was dat een probleem, maar tegenwoordig maakt het niet zoveel meer uit.

Om hoeveel VMs gaat het? Want het is misschien beter om de VMs in zijn geheel op de SSDs te zetten, dat is in veel gevallen de beste en makkelijkste setup.

[analog_]

Wat waren ook al weer de beperkingen met snapshotting waar je best mee rekening houd? Volume moet vrij genoeg zijn om de intersectie van oude data+bijgewerkte+nieuwe data te bewaren toch?

[Anoniem: 15758]

@FireDrunk: Nouja, het zorgt ervoor dat een hoop static data opeens dynamic data wordt. Maar je kunt het gewoon uitschakelen in Windows neem ik aan.

@analog_: wele beperkingen? Je kunt het beste snapshotten wanneer je filesystem door de client unmounted is. Dus bij iSCSI+ZVOL het beste in Windows/Linux je iSCSI-target unmounten of de machine laten rebooten. Dan een snapshot zodat je filesystem ook schoon is afgesloten. Maar het is opzich niet erg als je dit middenin doet. Dat zou hetzelfde zijn als er op dat moment een crash was en Windows/NTFS zal het filesystem middels de journal weer consistent maken. Dus geen 'enge' schade; hier is NTFS goed voor ontworpen. Maar het betekent wel verlies met wat je op dat moment mogelijk deed. Dat kunnen kleine writes zijn; Windows doet vanalles zoals de thumbnails in .thumbdb stoppen en dat soort dingen. Mac is nog erger wat dat betreft.

[Pakjebakmeel]

Zo, deze post na verder onderzoek maar even helemaal opnieuw begonnen. Was een beetje lang en onoverzichtelijk geworden.

1 SLOG en sync vs async
Voor zover ik begrijp is het ZIL een transactielog net zoals bij een database om bij reboot/crash uitstaande transacties alsnog in de database te verwerken.

• Een async write zal in het RAM geheugen komen en ZFS geeft meteen terug dat de transactie is verwerkt. Op basis van tijd of hoeveelheid data zal de transactiegroep naar de database druppelen. De async writes gaan dus nooit door ZIL.
  
  
• Een sync write gaat naar RAM en de ZIL, ZFS kan nu veilig bevestigen dat de transactie veilig is want hij zit in ZIL dus ook bij reboot/crash gaat hij de database in. De client moet langer op bevestiging wachten omdat de data ook daadwerkelijk eerst naar de ZIL (op disks) moet.
  
  

Omdat een ZIL nogal IO intensief is kun je een SLOG SSD toevoegen (in mirror) om je ZIL op te parkeren, de SSD heeft veel meer IOPS en de ZIL zal dus een stuk sneller worden echter is de SLOG geen generieke write cache zoals ik het begrijp. In priciepe gaat de data altijd van de transactiegroep in RAM naar de disks, nooit van SLOG naar disk. De ZIL wordt nooit gelezen behalve als het systeem crashed en transactie moeten worden terug gerold.



Mijn conclusie is dan ook dan een ZVOL met sync=disabled heeft geen baat bij een SLOG. Elke write zal async zijn en nooit op de SLOG terecht komen. Anders dat een kleine hoeveelheid load van wat transactie administratie zal de de performance van een pool met SLOG niet beter zijn dan een pool zonder SLOG maar met sync=disabled.

1. Als ik dus nu een ZVOL heb met sync=disabled gaat het toevoegen van een SLOG mijn performance niet significant verbeteren?
2. Als ik een grote pool heb die gemount is en bestanden bevat maar ik maak ook een ZVOL in die pool en ik zet sync=disabled op alleen het ZVOL, niet op de hele pool. Loop ik dan het risico dat de hele pool stuk gaat bij een crash of alleen kan op corruptie in het ZVOL waar sync writes uit staan? In dat geval gewoon even een VM opnieuw bouwen.

2 IOPS en VDEVs
Ik was in de veronderstelling dat het aantal devices in een pool/VDEV bepaalt de throughput in MB/s. Hoe meer disks hoe meer throughput. Echter is het aantal IOPS gelimiteerd aan een enkele disk.

Voorbeeld:

RAIDZ2 Pool van 6 disks == IOPS van 1 disk
RAIDZ Pool van 3 VDEVs van 3 disks elk in RAIDZ == IOPS van 3 disks
MIRROR Pool van 2 VDEVs van 2 disks elk in MIRROR == IOPS van 2 disks

Mijn eigen benchmarks zeggen dat mijn 6 disk RAIDZ2 array veel meer IOPS aan kan dan mijn MIRROR van 2 VDEVs van 2 disks in MIRROR. Dit staat haaks op bovenstaande theorie.

Doet ZFS toch stiekem slimme dingen om de IOPS op te krikken of kloppen mijn benchmarks niet?

Hier mijn bevindingen:

2x 2TB WDC_WD20EFRX in een mirror:

code:

read : io=3071.7MB, bw=11149KB/s, iops=2787 , runt=282127msec
write: io=1024.4MB, bw=3717.1KB/s, iops=929 , runt=282127msec

4x (oude bagger) 500GB ST3500841AS in een pool zonder redundancy, dus stripe over 4 disks:

code:

read : io=3071.7MB, bw=23351KB/s, iops=5837 , runt=134701msec
write: io=1024.4MB, bw=7786.2KB/s, iops=1946 , runt=134701msec

6x 3TB WDC_WD30EZRX in een RAIDZ2:

code:

read : io=3071.7MB, bw=215733KB/s, iops=53933 , runt= 14580msec
write: io=1024.4MB, bw=71942KB/s, iops=17985 , runt= 14580msec

Wat mij dus opvalt is dat een RAIDZ2 met 6 schijven veel meer IOPS heeft dan een MIRROR van 2 schijven. Ook nog eens WD Red vs WD Green. Ik zou verwachten dat het aantal IOPS op de MIRROR en de RAIDZ2 pool ongeveer gelijk zouden moeten zijn, zelfs in een licht voordeel naar de MIRROR omdat die REDs zijn ipv GREENs in het RAIDZ2 array.

Kortom, is bovenstaande claim mbt de IOPS nog wel geldig of doe ik gewoon iets verkeerd? (Heul goed mogelijk hoor)

3 SSDs en TRIM
Schijnbaar doet ZFS (nog) geen TRIM. Stel dat ik een pool maak van SSDs dedicated voor VM's zal dat natuurlijk ZOGMWTFBBQ* snel zijn (*technische term). Echter vraag ik me af of dit van lange duur is zonder TRIM. Iemand zal een TRIM command moeten geven om te zorgen dat de boel niet traag wordt op den duur. Wie zou dat moeten doen?

• VM naar het ZVOL? Kan me voorstellen dat als je hem zou kunnen markeren als 'non-rotational' dat een Windows client zal gaan TRIMmen.
• ZFS zelf (in toekomstige builds)
• Een cron scriptje.

4 Mijn huidige opties:

Een SLOG en L2ARC aan mijn trage mirror.

Gezien het feit dat de performance met sync=disabled nog steeds niet best is als er 8 VMs tegelijk op draaien verwacht ik geen wonderen van SLOG, voor zover het al wat zou doen. L2ARC heb ik wel eens gebruikt dus dat zal wel wat toevoegen maar niet als die machines staan te updaten en veel random bestandjes schrijven

kosten: 2 SSDs
winst: weinig
overig: -

Een MIRROR of RAIDZ van SSDs

Dit zal wel werken ja. Vraag is voor hoe lang zonder TRIM?

kosten: 2 of 3 SSDs
winst: veel
overig: TRIM? Lange termijn?

4x 500GB in een striped mirror

4 disks van een klein formaat, bijvoorbeeld 4x 500GB of 1TB verdelen in 2 mirrored VDEVs en die stripen in een pool.

kosten: 4 (goedkope) disks
winst: Dubbele throughput en IOPS van mijn huidige mirror.
overig: -

Zoals je ziet heb ik me zo goed mogelijk proberen in te lezen, ik heb geen onmogelijke verwachtingen van ZFS zoals "Gooi er een SSD in en alles wordt automagisch snel". Gek genoeg wordt dit vaak wel aangeraden terwijl ik het idee heb dat de meeste 'thuis-gebruikers' en zelfs tweakers geen baat gaan hebben bij een SLOG omdat dat niet de limiterende factor is en ook niet bij een L2ARC omdat de systemen sowiezo niet genoeg RAM hebben.

Ik wil een plekje voor mijn VM's met zo veel mogelijk IOPS voor het liefst zo min mogelijk geld (wie niet). Echter heb ik het gevoel dat alle opties niet bepaald ideaal zijn en er overal nadelen aan kleven. De meeste VMz zijn niet mission critical en mogen van mij sync=disabled. Degene die wel belangrijk zijn zet ik wel handmatig sync=enabled.

_{Oke mislukt, nog steeds een lange post maar nu in ieder geval wat structuur aangebracht..}

[ Voor 109% gewijzigd door Pakjebakmeel op 28-03-2015 10:23 ]

[Vaudtje]

Ik heb met behulp van de info uit dit topic nu een RAIDZ2 van 6xWD Green draaien (wdidle3.exe /D), met ZFSGuru 0.2.0beta9 (root-on-zfs op een aparte laptopschijf die aangesloten is via USB wegens gebrek aan SATA).
Hierbij heb ik echter het volgende: de disks spinnen niet down als ik ze niet gebruik.
relevante delen uit /etc/rc.conf:

code: /etc/rc.conf

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

De disks gaan wel standby als ik de knop op Disks/Advanced gebruik (en blijven dan down tot ik ze aanspreek, waarbij de spinup delay merkbaar is).
Handmatig testen met

camcontrol standby ada2 -t 60

laat zien dat camcontrol de -t parameter lijkt te negeren: de disk spint meteen down zonder te wachten.

Ik heb ook de spindown service (gesuggereerd door o.a. FireDrunk) geprobeerd, maar die doet niets.
In debug mode stelt hij zelfs dat de drives spinning zijn die in ZFSGuru als standby vermeld staan, maar de output blijft onveranderd (ook de idle time blijft 0):

spindown -D  -t 30 -d ada3
device: ada3, max_idle_time: 30, rd: 156829, wr: 147757, frees: 0, other: 0, idle time: 0, state: Spinning

Omdat ik een aparte pool op ad0 (USB drive) voor ZFS heb, zou ik verwachten dat de storage pool op ada0 t/m ada5 gewoon idle kan zijn en standby mag. Dit blijkt ook uit het feit dat ze standby blijven als ik ze met de hand standby zet.
Waarom dan geen automatische spindown? Het is nogal irritant om elke avond met de hand de boel plat te moeten meppen

[tweedebas]

Wat gerepresenteerd waarde 255 bij zfsguru_apm_level="255"

In Freenas kan je ook een apm level instellen ind e GUI, 6 varianten laagste 3 met spindown, hoogste 3 zonder spindown. Daar hangt ook een nummer aan, kan er nu even niet bij voor alle gegevens, maar 127 was meeste performance, maar nog wel met spindown. Alles daarboven is zonder spindown.

[FireDrunk]

Pakjebakmeel schreef op dinsdag 17 maart 2015 @ 06:28:
Zo, deze post na verder onderzoek maar even helemaal opnieuw begonnen. Was een beetje lang en onoverzichtelijk geworden.

1 SLOG en sync vs async
Voor zover ik begrijp is het ZIL een transactielog net zoals bij een database om bij reboot/crash uitstaande transacties alsnog in de database te verwerken.

• Een async write zal in het RAM geheugen komen en ZFS geeft meteen terug dat de transactie is verwerkt. Op basis van tijd of hoeveelheid data zal de transactiegroep naar de database druppelen. De async writes gaan dus nooit door ZIL.
  
  [afbeelding]
• Een sync write gaat naar RAM en de ZIL, ZFS kan nu veilig bevestigen dat de transactie veilig is want hij zit in ZIL dus ook bij reboot/crash gaat hij de database in. De client moet langer op bevestiging wachten omdat de data ook daadwerkelijk eerst naar de ZIL (op disks) moet.
  
  [afbeelding]

Omdat een ZIL nogal IO intensief is kun je een SLOG SSD toevoegen (in mirror) om je ZIL op te parkeren, de SSD heeft veel meer IOPS en de ZIL zal dus een stuk sneller worden echter is de SLOG geen generieke write cache zoals ik het begrijp. In priciepe gaat de data altijd van de transactiegroep in RAM naar de disks, nooit van SLOG naar disk. De ZIL wordt nooit gelezen behalve als het systeem crashed en transactie moeten worden terug gerold.

[afbeelding]

Mijn conclusie is dan ook dan een ZVOL met sync=disabled heeft geen baat bij een SLOG. Elke write zal async zijn en nooit op de SLOG terecht komen. Anders dat een kleine hoeveelheid load van wat transactie administratie zal de de performance van een pool met SLOG niet beter zijn dan een pool zonder SLOG maar met sync=disabled.

[list=1]
• Als ik dus nu een ZVOL heb met sync=disabled gaat het toevoegen van een SLOG mijn performance niet significant verbeteren?

Correct.

• Als ik een grote pool heb die gemount is en bestanden bevat maar ik maak ook een ZVOL in die pool en ik zet sync=disabled op alleen het ZVOL, niet op de hele pool. Loop ik dan het risico dat de hele pool stuk gaat bij een crash of alleen kan op corruptie in het ZVOL waar sync writes uit staan? In dat geval gewoon even een VM opnieuw bouwen.
[/list]

Nee, bestanden staan niet op een pool, bestanden staan altijd op een filesystem. By default maakt zfs al een filesystem voor je aan op een pool (technisch gezien hoeft dat niet, maar dat is een ander verhaal).
Zodra je een ZVOL aanmaakt (wat eigenlijk heel veel eigenschappen deelt met een gewoon filesystem), maak je die aan 'onder' een parent filesystem. Het ZVOL neemt een aantal eigenschappen over van zijn parent.

Als je nu op het root filesystem sync=disabled aan zet, zal het ZVOL ook sync=disabled krijgen, omdat default het ZVOL de waarde van zijn parent gebruikt. Stel je daarna op het ZVOL expliciet sync=standard of sync=always in, overruled dat de sync instellingen van zijn parent, en is je ZVOL gewoon beschermt tegen uitval (enigzins).

2 IOPS en VDEVs
Ik was in de veronderstelling dat het aantal devices in een pool/VDEV bepaalt de throughput in MB/s. Hoe meer disks hoe meer throughput. Echter is het aantal IOPS gelimiteerd aan een enkele disk.

Voorbeeld:

RAIDZ2 Pool van 6 disks == IOPS van 1 disk
RAIDZ Pool van 3 VDEVs van 3 disks elk in RAIDZ == IOPS van 3 disks
MIRROR Pool van 2 VDEVs van 2 disks elk in MIRROR == IOPS van 2 disks

Mijn eigen benchmarks zeggen dat mijn 6 disk RAIDZ2 array veel meer IOPS aan kan dan mijn MIRROR van 2 VDEVs van 2 disks in MIRROR. Dit staat haaks op bovenstaande theorie.

Doet ZFS toch stiekem slimme dingen om de IOPS op te krikken of kloppen mijn benchmarks niet?

Alleen voor RAIDZ(-2,-3) geld het limiet van het aantal IOPS van 1 device in de array. Niet voor mirrors.
Je bevindingen kloppen dus.

Bedenk ook goed dat IOPS != Throughput. Dus benches die 1MB grote blokken opvragen geven hele andere resultaten dan benches met 512byte-grote aanvragen

Hier mijn bevindingen:

2x 2TB WDC_WD20EFRX in een mirror:

code:

read : io=3071.7MB, bw=11149KB/s, iops=2787 , runt=282127msec
write: io=1024.4MB, bw=3717.1KB/s, iops=929 , runt=282127msec

4x (oude bagger) 500GB ST3500841AS in een pool zonder redundancy, dus stripe over 4 disks:

code:

read : io=3071.7MB, bw=23351KB/s, iops=5837 , runt=134701msec
write: io=1024.4MB, bw=7786.2KB/s, iops=1946 , runt=134701msec

6x 3TB WDC_WD30EZRX in een RAIDZ2:

code:

read : io=3071.7MB, bw=215733KB/s, iops=53933 , runt= 14580msec
write: io=1024.4MB, bw=71942KB/s, iops=17985 , runt= 14580msec

Wat mij dus opvalt is dat een RAIDZ2 met 6 schijven veel meer IOPS heeft dan een MIRROR van 2 schijven. Ook nog eens WD Red vs WD Green. Ik zou verwachten dat het aantal IOPS op de MIRROR en de RAIDZ2 pool ongeveer gelijk zouden moeten zijn, zelfs in een licht voordeel naar de MIRROR omdat die REDs zijn ipv GREENs in het RAIDZ2 array.

Kortom, is bovenstaande claim mbt de IOPS nog wel geldig of doe ik gewoon iets verkeerd? (Heul goed mogelijk hoor)

Dat is enigzins vreemd, maar ik gok dat het komt omdat je niet Q=1 doet. Op het moment dat er meer dan 1 aanvraag in de transaction groep komt van een RAIDZ device kan hij wel degelijk meerdere iops tegelijk uitlezen volgens mij. Ook is er nog zoiets als VDEV readahead en VDEV cache, maar IOPS van RAIDZ is geen exacte wetenschap, het ligt totaal aan de load... Dat maakt dit benchen erg ingewikkeld.

3 SSDs en TRIM
Schijnbaar doet ZFS (nog) geen TRIM. Stel dat ik een pool maak van SSDs dedicated voor VM's zal dat natuurlijk ZOGMWTFBBQ* snel zijn (*technische term). Echter vraag ik me af of dit van lange duur is zonder TRIM. Iemand zal een TRIM command moeten geven om te zorgen dat de boel niet traag wordt op den duur. Wie zou dat moeten doen?

TRIM is een feature van je OS in samenwerking met ZFS (ZFS moet namelijk zeggen dat er iets leeg gemaakt kan worden, je OS moet zeggen *hoe* het leeggemaakt moet worden). BSD heeft al wel TRIM voor ZFS, ZFSonLinux is er volgens mij nog mee bezig.

[list]
• VM naar het ZVOL? Kan me voorstellen dat als je hem zou kunnen markeren als 'non-rotational' dat een Windows client zal gaan TRIMmen.

TRIM werkt niet in een VM, de virtuele controller slikt dat namelijk in veel gevallen niet.
iSCSI, NFS en FibreChannel doen ook allemaal (nog) geen TRIM.

• ZFS zelf (in toekomstige builds)
• Een cron scriptje.
[/list]

4 Mijn huidige opties:

Een SLOG en L2ARC aan mijn trage mirror.

Gezien het feit dat de performance met sync=disabled nog steeds niet best is als er 8 VMs tegelijk op draaien verwacht ik geen wonderen van SLOG, voor zover het al wat zou doen. L2ARC heb ik wel eens gebruikt dus dat zal wel wat toevoegen maar niet als die machines staan te updaten en veel random bestandjes schrijven

kosten: 2 SSDs
winst: weinig
overig: -

Een MIRROR of RAIDZ van SSDs

Dit zal wel werken ja. Vraag is voor hoe lang zonder TRIM?

kosten: 2 of 3 SSDs
winst: veel
overig: TRIM? Lange termijn?

4x 500GB in een striped mirror

4 disks van een klein formaat, bijvoorbeeld 4x 500GB of 1TB verdelen in 2 mirrored VDEVs en die stripen in een pool.

kosten: 4 (goedkope) disks
winst: Dubbele throughput en IOPS van mijn huidige mirror.
overig: -

Zoals je ziet heb ik me zo goed mogelijk proberen in te lezen, ik heb geen onmogelijke verwachtingen van ZFS zoals "Gooi er een SSD in en alles wordt automagisch snel". Gek genoeg wordt dit vaak wel aangeraden terwijl ik het idee heb dat de meeste 'thuis-gebruikers' en zelfs tweakers geen baat gaan hebben bij een SLOG omdat dat niet de limiterende factor is en ook niet bij een L2ARC omdat de systemen sowiezo niet genoeg RAM hebben.

Ik wil een plekje voor mijn VM's met zo veel mogelijk IOPS voor het liefst zo min mogelijk geld (wie niet). Echter heb ik het gevoel dat alle opties niet bepaald ideaal zijn en er overal nadelen aan kleven. De meeste VMz zijn niet mission critical en mogen van mij sync=disabled. Degene die wel belangrijk zijn zet ik wel handmatig sync=enabled.

_{Oke mislukt, nog steeds een lange post maar nu in ieder geval wat structuur aangebracht..}

Ik heb zelf enige tijd een RAID0 pool van 4 SSD's gehad... Dat is echt heel erg leuk icm ZFS en werkt prima. Tegenwoordig zijn SSD's ook prima in offline Garbage Collection, al worden ze er iets langzamer van. Je hoeft niet te vrezen voor de aloude problemen van SSDs die nog maar 1MB/s doen omdat er geen TRIM gebruikt wordt. Dat is allang niet meer zo is mijn ervaring.

Ja, TRIM helpt, maar het is niet de heilige graal ofzo...

[Vaudtje]

tweedebas schreef op donderdag 19 maart 2015 @ 14:38:
Wat gerepresenteerd waarde 255 bij zfsguru_apm_level="255"

In Freenas kan je ook een apm level instellen ind e GUI, 6 varianten laagste 3 met spindown, hoogste 3 zonder spindown. Daar hangt ook een nummer aan, kan er nu even niet bij voor alle gegevens, maar 127 was meeste performance, maar nog wel met spindown. Alles daarboven is zonder spindown.

APM 255 zou APM uit moeten zijn. In ieder geval ondersteunen de schijven geen APM (dus die hele secie is eigenlijk overbodig), daarom moeten ze met camcontrol op standby worden gezet.
Alleen lijkt het camcontrol commando de -t parameter te negeren.

Aan de andere kant lijkt spindown het met -t 60 wel te doen.
Is er nog een reden om de camcontrol methode van ZFSGuru aan de praat te proberen te krijgen?

[Anoniem: 15758]

tweedebas schreef op donderdag 19 maart 2015 @ 14:38:
Wat gerepresenteerd waarde 255 bij zfsguru_apm_level="255"

255 = APM disabled
254 = maximum performance - dus geen headparking en geen spindown

254 en 255 hebben dus een speciale waarde. Het is 8-bit dus gaat van 0 tot 255. 127/128 verschilt ook.

Mogelijk omdat hij APM op 255 heeft ingesteld dat de spindown niet meer werkt. Dus dat zou ik eerst proberen uit te commenten.

@FireDrunk: BSD doet sinds kort ook TRIM/UNMAP op virtio-block. Dus je kunt je ZVOLs nu ook exporteren op je SSD en de performance met TRIM op peil houden.

[Vaudtje]

Hiervoor had ik APM op 254 staan, dat deed ook niets (camcontrol black magic commando geeft ook een error). Ik ga zfsguru_apm_enable="NO"
nog even proberen (of moeten alle APM regels er dan echt uit?).
Is er trouwens nog een manier om die /etc/rc.conf instellingen opnieuw te laten inlezen zonder reboot?

[ Voor 9% gewijzigd door Vaudtje op 19-03-2015 15:00 ]

[tweedebas]

Vaudtje schreef op donderdag 19 maart 2015 @ 14:57:
Hiervoor had ik APM op 254 staan, dat deed ook niets (camcontrol black magic commando geeft ook een error). Ik ga zfsguru_apm_enable="NO"
nog even proberen (of moeten alle APM regels er dan echt uit?).
Is er trouwens nog een manier om die /etc/rc.conf instellingen opnieuw te laten inlezen zonder reboot?

Als de apm regel invloed heeft zou 254 spindown ook hebben geblokkeerd.

Weet niet of het handiger is de regels eruit de #'en of op NO zetten.

[Anoniem: 15758]

Een # voor de zfsguru_apm_enable is genoeg. Op NO instellen ook. Je hoeft de rest dus niet weg te halen. Aangezien deze instellingen alleen relevant zijn direct na de boot wanneer het script wordt uitgevoerd, is een reboot nodig om veranderingen actief te laten worden.

Maar je kunt wellicht proberen: service zfsguru restart. Edit: dit helpt niet om de eerder ingestelde APM-setting kwijt te raken! Een reboot is mogelijk ook niet voldoende. Je moet het systeem power-cyclen. Dus hardeschijven helemaal uit en dan weer aan. Alleen zo verliest APM zijn instelling.

[ Voor 26% gewijzigd door Anoniem: 15758 op 19-03-2015 15:09 ]

[FireDrunk]

Anoniem: 15758 schreef op donderdag 19 maart 2015 @ 14:51:
[...]
@FireDrunk: BSD doet sinds kort ook TRIM/UNMAP op virtio-block. Dus je kunt je ZVOLs nu ook exporteren op je SSD en de performance met TRIM op peil houden.

Uh, dat geld dus voor BSD VM's die onder KVM of VirtualBox draaien op een VirtIO controller?
Niet voor BSD als Host OS met VirtIO Controllers naar Windows VM's bijvoorbeeld neem ik aan?

Desalniettemin gave ontwikkeling

[ Voor 4% gewijzigd door FireDrunk op 19-03-2015 15:16 ]

[Anoniem: 15758]

Het geldt bijvoorbeeld als BSD host is en met bhyve block I/O aanbiedt via virtio-block. Maar bhyve ondersteunt geen Windows - alleen *BSD en Linux en dan zeker niet alle versies. Toch krijgt bhyve ook de nodige aandacht op -CURRENT en ik kijk er erg naar uit!

Nog meer gave dingen:

LSI controllers blokkeren niet meer I/O van andere disk bij een bad sector/timeout op één disk.
LSI controllers kunnen nu APM/AAM doorgeven aan de disks.
camcontrol kan nu direct APM/AAM instellen ipv met custom commands te werken.

Ook de vorderingen op grafisch gebied en de import van Clang 3.6 vind ik gaaf; maar is niet direct relevant voor storage. Let wel: deze commits zijn naar 11-CURRENT en kan dus even duren voordat 10-STABLE ze heeft.

[ Voor 21% gewijzigd door Anoniem: 15758 op 19-03-2015 15:24 ]

[FireDrunk]

Dat is zeker nice! Dat maakt de LSI SAS2008 familie nog veel beter geschikt voor ZFS!