Het grote ZFS topic

[Hakker]

vraagje ik wil binnenkort van 10.0.002 en 0.20 beta 9 gaan naar 10.2.003 en 0.31 (leuk trouwens geen changelogs hierover)
anyways mijn vraag is het volgende ik heb ook een 2 tal plekken waarvan ik niet weet of die bij een nieuwe installs blijven bestaan.
Ik heb in root/symlinks een paar symlinks gemaakt voor ncdc en dat is gelijk mijn 2de punt die de nieuwe installatie iets in /home/x11/.ncdc danwel /home/x11 doet als ik ga updaten? Het is een flinke partij werk om 45 TB aan hashfiles weer te maken. Als ik het kan vermijden is dat natuurlijk mooi meegenomen.

[ Voor 7% gewijzigd door Hakker op 30-08-2015 23:45 ]

[HyperBart]

Je vraag is volgens mij niet echt een ZFS related question, eerder weer eentje voor ZFSguru. Misschien best een eigen topicje over aanmaken...

[Compizfox]

HyperBart schreef op maandag 31 augustus 2015 @ 00:18:
Je vraag is volgens mij niet echt een ZFS related question, eerder weer eentje voor ZFSguru. Misschien best een eigen topicje over aanmaken...

Ach, de helft van dit topic gaat over iets anders van ZFS zelf... (meestal FreeBSD of ZFSGuru)

[Tha_Butcha]

Zoals eerder gezegd, is laden van mijn ZFS pool gelukt, alleen nu heb ik problemen met permissies. Ik heb een dataset pool0/download aangemaakt alleen deluge kan daar niet op schrijven (zelfs niet met chmod 777).

Op een andere drive kan ik wel gewoon schrijven, waarbij de permissies precies hetzelfde zijn als de directory op de ZFS mount.

Moet ik nu nog op ZFS niveau de permissies regelen voor die dataset?

[Verwijderd]

Draait Deluxe op dezelfde machine, of heeft die toegang via abstractieprotocollen zoals SMB/NFS/AFP? In dat geval zijn permissies op filesystem niveau slechts één deel van het mechanisme van authenticatie. De protocollen hebben hun eigen permissies.

[Tha_Butcha]

Zelfde machine, daarom vond ik het zo raar. de daemon draait als debian-deluged:debian-deluged en /mnt/pool0/download/bittorrent kan hij niet naar schrijven

code:

drwxrwx--- 31 root debian-deluged    53 Aug 31 09:36 bittorrent

een andere dir (op niet ZFS device) op het zelfde systeem met dezelfde permissies lukt wel.

[Verwijderd]

Hebben /mnt, /mnt/pool0, /mnt/pool0/download ook allemaal de juiste permissies? In het bijzonder, hebben deze 'execute' permissies voor debian-deluged? Zonee, dan heb je nog steeds niet de juiste permissies. als /mnt/pool0 bijvoorbeeld 770 heeft voor root:wheel of wat dan ook, dan heeft debian-deluged helemaal geen enkele permissies op welke onderliggende node. Althans, voor zover mijn POSIX/UNIX-kennis reikt.

[FireDrunk]

POSIX rechten kennen geen inheritance. / is ook root:root terwijl subdirectories wel van gebruikers kunnen zijn.
Dat is een fundamenteel verschil met Windows rechten (waar "Users" op de root al leesrechten hebben).

Als een subdirectory 770 is met als owner debian-deluged kan jouw applicatie daar gewoon bij, *mits* hij het hele pad in 1 keer probeert uit te lezen.

Als je er dus met een filebrowser naar toe moet, gaat dat niet altijd lukken, homedirectories zijn bijvoorbeeld niet 775 (wat veel andere directories wel zijn.) die zijn 770, dat betekend dat niet iedereen in home directories kan.

Wat je simpelweg kan doen:

su - deluged-debian -s /bin/bash

Dan *ben* je die user en kan je vrolijk over je filesystem heen bladeren om te kijken welke directories je wel en niet in mag.

[begintmeta]

FireDrunk schreef op dinsdag 01 september 2015 @ 07:57:
...
Als een subdirectory 770 is met als owner debian-deluged kan jouw applicatie daar gewoon bij, *mits* hij het hele pad in 1 keer probeert uit te lezen.
...

Zoals CiPHER al aangeeft is het dan nog wel nodig dat voorliggende directories een execute-permissie hebben voor debian-deluged

[Tha_Butcha]

thanks guys, eindelijk gefixed! De parent directory (/mnt/pool0/download) had niet de goede ownership. Ik was al in de weer geweest met su, zoals Firedrunk suggereerde, maar had geen shell geforceerd, dus dan werkt het niet. dom,dom,dom.

[FireDrunk]

begintmeta schreef op dinsdag 01 september 2015 @ 08:58:
[...]

Zoals CiPHER al aangeeft is het dan nog wel nodig dat voorliggende directories een execute-permissie hebben voor debian-deluged

Sterker nog, Directories moeten ALTIJD de execute permissie hebben
Anders kom je er niet in

Vandaar het default umask op veel systemen 002. Dan word elke directory die je aanmaakt 775 en elke file 664

[ Voor 13% gewijzigd door FireDrunk op 01-09-2015 13:43 ]

[Verwijderd]

Voor een directory heb je inderdaad zowel read (1) als execute (4) nodig. Dan kom je dus op minimaal 555 uit. 775 Mag uiteraard ook, maar de schrijfrechten zijn op zich niet noodzakelijk (tenzij je wilt schrijven natuurlijk).

[begintmeta]

FireDrunk schreef op dinsdag 01 september 2015 @ 13:42:
...
Sterker nog, Directories moeten ALTIJD de execute permissie hebben
Anders kom je er niet in
...

Dat is min of meer ook wat ik schreef meende ik.

Verwijderd schreef op dinsdag 01 september 2015 @ 18:40:
Voor een directory heb je inderdaad zowel read (1) als execute (4) nodig. ...

r heb je alleen nodig als je de directoryinhoud wil lezen, anders is x voldoende.

Als je r verwijdert (en x laat staan) op bijvoorbeeld de homedirectory kunnen de home-subdirectorygebruikers nog wel in hun eigen directories, maar kunnen ze niet (niet gemakkelijk eigenlijk eerder) uitlezen welke andere homesubdirectories nog bestaan.

[ Voor 52% gewijzigd door begintmeta op 02-09-2015 12:13 ]

[Extera]

Beetje stomme vraag misschien, maar onderstaande pool is in de Freenas GUI snel aangemaakt...

Ik kijk hier toch naar een pool met 2x zraid2? Dus: van iedere vdev kunnen 2x disks falen? (van het 2e vdev nog 1 dus )

code:

  pool: tank
 state: DEGRADED
status: One or more devices has been removed by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Online the device using 'zpool online' or replace the device with
        'zpool replace'.
  scan: none requested
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/2b78596b-4983-11e5-b7e1-a0f3c1109829  ONLINE       0     0     0
            gptid/2be60f90-4983-11e5-b7e1-a0f3c1109829  ONLINE       0     0     0
            gptid/2c4f8a77-4983-11e5-b7e1-a0f3c1109829  ONLINE       0     0     0
            gptid/2d144e5a-4983-11e5-b7e1-a0f3c1109829  ONLINE       0     0     0
          raidz2-1                                      DEGRADED     0     0     0
            8098556764606664835                         REMOVED      0     0     0  was /dev/gptid/2d9f83c2-4983-11e5-b7e1-a0f3c1109829
            gptid/2e4cf258-4983-11e5-b7e1-a0f3c1109829  ONLINE       0     0     0
            gptid/2f08c7e5-4983-11e5-b7e1-a0f3c1109829  ONLINE       0     0     0
            gptid/2f8e4d42-4983-11e5-b7e1-a0f3c1109829  ONLINE       0     0     0

[CurlyMo]

Ja

[justice strike]

Ik vraag me altijd af, waarom zou je ooit voor twee kleinere vdevs gaan als je met een grotere vdev meer redundancy en performance kan halen. Ik zie het vaak maar ik begrijp niet waarom iemand voor 2*4 wil gaan ipv 1*8 met bijv raidz3 met een spare

[Verwijderd]

Dubbele IOps performance, maar dat is niet zo heel spannend. Voor zulke kleine vdevs is het doorgaans beter om minder maar grotere vdevs te nemen, vooral nu met large_blocks feature.

[justice strike]

large_blocks feature?

[Verwijderd]

ZFS zit tegenwoordig op versie 5000, wat inhoudt dat het 'feature flags' kent die specifieke features toevoegen die in- uit uitgeschakeld kunnen worden. Eén van die features is de large_block feature, die zorgt ervoor dat de maximale recordsize van 128KiB naar 1024KiB kan worden verhoogd. Dit is beter voor grote vdevs met veel disks, en zorgt ook voor minder verloren ruimte (slack) bij niet-optimale 4K configuraties.

Stel je hebt 19 disks in RAID-Z3. Dat komt overeen met 16 data disks en dat zou betekenen dat elke disk 128K/16 = 8 kilobyte per request krijgt te verwerken.... maximaal! Dat is zo laag dat dit de prestaties flink doet afnemen. Je wilt per disk eigenlijk 32K tot 128K requests hebben.

Met large_blocks kun je de recordsize tot 1024K verhogen en dat betekent 1024K/16 = 64KiB request per schijf. Zelfs met heel grote vdevs blijf je dan efficiënt werken.

Nadeel is wel dat large_blocks nog niet wordt ondersteund door ZFS-on-Linux of oudere BSD versies zoals FreeNAS enzovoorts. Ook maakt het dat je pool niet langer bootable is. Maar dit is wel een gave feature die je wilt hebben op je data pool.

[Extera]

Kijk! toch weer wat geleerd door deze vraag!

Eigenlijk was het de bedoeling een 8 disk zraid2 te bouwen, maar ach, het is een tijdelijke nas, dus dit is ook prima

Dit krijg je van gehaast werken.

Disk vervangen, de pool is aan het resilveren.... life is good!

[FireDrunk]

Verwijderd schreef op woensdag 02 september 2015 @ 13:11:
ZFS zit tegenwoordig op versie 5000, wat inhoudt dat het 'feature flags' kent die specifieke features toevoegen die in- uit uitgeschakeld kunnen worden. Eén van die features is de large_block feature, die zorgt ervoor dat de maximale recordsize van 128KiB naar 1024KiB kan worden verhoogd. Dit is beter voor grote vdevs met veel disks, en zorgt ook voor minder verloren ruimte (slack) bij niet-optimale 4K configuraties.

Stel je hebt 19 disks in RAID-Z3. Dat komt overeen met 16 data disks en dat zou betekenen dat elke disk 128K/16 = 8 kilobyte per request krijgt te verwerken.... maximaal! Dat is zo laag dat dit de prestaties flink doet afnemen. Je wilt per disk eigenlijk 32K tot 128K requests hebben.

Met large_blocks kun je de recordsize tot 1024K verhogen en dat betekent 1024K/16 = 64KiB request per schijf. Zelfs met heel grote vdevs blijf je dan efficiënt werken.

Nadeel is wel dat large_blocks nog niet wordt ondersteund door ZFS-on-Linux of oudere BSD versies zoals FreeNAS enzovoorts. Ook maakt het dat je pool niet langer bootable is. Maar dit is wel een gave feature die je wilt hebben op je data pool.

*kuch*

https://github.com/zfsonl...878e0cf90c845ed52a2a34d72

[riwi]

Verwijderd schreef op woensdag 02 september 2015 @ 13:11:
Nadeel is wel dat large_blocks nog niet wordt ondersteund door ZFS-on-Linux of oudere BSD versies zoals FreeNAS enzovoorts. Ook maakt het dat je pool niet langer bootable is. Maar dit is wel een gave feature die je wilt hebben op je data pool.

De large block feature wordt dus zoals firedrunk reeds zegt wel degelijk ondersteund door ZoL.
En het is een filesystem property, niet op pool niveau. Dus je kan zo een nieuw zfs fs aanmaken in je pool waar de feature actief is om er mee te experimenteren.

Ik heb er wel mee gespeeld, maar zag zo nog niet veel voor of nadelen kwa storage efficiency of snelheid op mijn test setup met 6x 1.5TB raidz2.

[justice strike]

riwi schreef op donderdag 03 september 2015 @ 10:03:
[...]


De large block feature wordt dus zoals firedrunk reeds zegt wel degelijk ondersteund door ZoL.
En het is een filesystem property, niet op pool niveau. Dus je kan zo een nieuw zfs fs aanmaken in je pool waar de feature actief is om er mee te experimenteren.

Ik heb er wel mee gespeeld, maar zag zo nog niet veel voor of nadelen kwa storage efficiency of snelheid op mijn test setup met 6x 1.5TB raidz2.

wordt pas interessant met SMR schijven. Als je de blocksize kunt afstemen op dat wat handig is voor de schijf dan zou de performance weer omhoog gaan.

[Dutch2007]

een vraag..

heb 6 schijven...

3x WD
3x seagate
3 disks zijn "oude" vorm, 512 sector, 3 4096...
raidz1...

Ga ik veel performance issue's hebben nu de helft oud en de andere nieuw is? (qua hdd sector layout)
hoeveel invloed gaat RAIDZ1 met 6 disk trouwens hebben?


het is op een I3 met 16GB ram...

[ Voor 16% gewijzigd door Dutch2007 op 03-09-2015 17:06 ]

[riwi]

Je kan bij de zpool create de ashift=12 parameter meegeven. Dan forceer je dat de schijven als een 4k sector schijf behandeld wordt. Dan heb je geen last van de 512byte schijven.

Kwa performance maakt dat niks uit met 6x 4k sector schijven.

Je vraag over de invloed van RAIDZ1 met 6 disks snap ik niet. Invloed op wat?
RAIDZ1 heeft kwa performance in worst case dezelfde performance als 1 single disk. In de praktijk merk ik dat het gewoon zeker 2x zo snel is als een enkele disk, maar dat zal van de workload afhangen.

En wat wordt de basis kwa OS ? Linux, BSD, illumos ? ZFSguru of nas4free ?

[Compizfox]

riwi schreef op donderdag 03 september 2015 @ 20:33:
RAIDZ1 heeft kwa performance in worst case dezelfde performance als 1 single disk. In de praktijk merk ik dat het gewoon zeker 2x zo snel is als een enkele disk, maar dat zal van de workload afhangen.

Hoe bedoel je dat, en heb je het over read- of writeperformance? Zover ik weet, heeft RAID-5 (en ook RAID-Z) een readperformance van n*x en een writeperformance van (n-p)*x, met n het totaal aantal schijven, p het aantal parity-schijven en x de performance van een enkele disk.

Met 6 schijven in RAID-Z1 heb je dus 6x de readperformance van een enkel disk, en 5x de writeperformance van een enkele disk. Dit zijn natuurlijk wel theoretische waarden, waarbij o.a. wordt uitgegaan van het feit dat de performance niet ergens anders dan op de schijven zelf is gebottleneckt en dat het berekenen van parity geen extra overhead oplevert. Ook is hier invloed van overhead door ZFS-blocks e.d. niet meegenomen.

[Dutch2007]

riwi schreef op donderdag 03 september 2015 @ 20:33:
Je kan bij de zpool create de ashift=12 parameter meegeven. Dan forceer je dat de schijven als een 4k sector schijf behandeld wordt. Dan heb je geen last van de 512byte schijven.

Kwa performance maakt dat niks uit met 6x 4k sector schijven.

Je vraag over de invloed van RAIDZ1 met 6 disks snap ik niet. Invloed op wat?
RAIDZ1 heeft kwa performance in worst case dezelfde performance als 1 single disk. In de praktijk merk ik dat het gewoon zeker 2x zo snel is als een enkele disk, maar dat zal van de workload afhangen.

En wat wordt de basis kwa OS ? Linux, BSD, illumos ? ZFSguru of nas4free ?

Ok helder bij het AANMAKEN

Mijn disk setup was eerst een 512 sector systeem...

waren paar schijven aan het verrotten dus die vervangen, en ja door 4K sector schijven.. is daar achteraf niet iets aan te doen?

Kan ik trouwens nog iets met ZFS en offline defrag ofzo doen? zie dat mij systeem momenteel ~56% is..

OS: FreeBSD 10.2

[riwi]

Compizfox schreef op donderdag 03 september 2015 @ 20:50:
Hoe bedoel je dat, en heb je het over read- of writeperformance? Zover ik weet, heeft RAID-5 (en ook RAID-Z) een readperformance van n*x en een writeperformance van (n-p)*x, met n het totaal aantal schijven, p het aantal parity-schijven en x de performance van een enkele disk.

Kwa IOPS heb je de performance van de langzaamste disk in je vdev (bij een single vdev pool).
http://constantin.glez.de...zfs-vdevs-and-performance
Zie hoofstukje "RAID-Z Performance Considerations".

Maar kwa sequentiele bandbreedte werkt het wel ongeveer zoals jij stelt. Al gaat er wel wat af voor het lezen/schrijven van de checksum data.

[ Voor 35% gewijzigd door riwi op 03-09-2015 22:16 ]

[riwi]

Dutch2007 schreef op donderdag 03 september 2015 @ 21:59:
waren paar schijven aan het verrotten dus die vervangen, en ja door 4K sector schijven.. is daar achteraf niet iets aan te doen?

Kan ik trouwens nog iets met ZFS en offline defrag ofzo doen? zie dat mij systeem momenteel ~56% is..

Defrag bestaat niet onder ZFS. Da's jammer.

Met zdb -C <poolnaam> kan je zien welke ashift er voor de pool gekozen is bij het aanmaken van de pool. Dit kan je niet achteraf wijzigen volgens mij.

[Compizfox]

riwi schreef op donderdag 03 september 2015 @ 22:00:
[...]
Kwa IOPS heb je de performance van de langzaamste disk in je vdev (bij een single vdev pool).
http://constantin.glez.de...zfs-vdevs-and-performance
Zie hoofstukje "RAID-Z Performance Considerations".

Ah, zo. Dat klinkt logisch ja.

Maar kwa sequentiele bandbreedte werkt het wel ongeveer zoals jij stelt. Al gaat er wel wat af voor het lezen/schrijven van de checksum data.

Jup.

[Verwijderd]

riwi schreef op donderdag 03 september 2015 @ 22:00:
Kwa IOPS heb je de performance van de langzaamste disk in je vdev (bij een single vdev pool).
http://constantin.glez.de...zfs-vdevs-and-performance
Zie hoofstukje "RAID-Z Performance Considerations".

Dat is niet helemaal correct.

RAID-Z gedraagt zich qua performance als RAID3, niet als RAID5. Dat betekent dat de IOps performance lager kan zijn dan de IOps performance van de traagste disk in de RAID-Z vdev. Dit komt omdat de latency kunnen verschillen, en de ene keer is disk1 de langzaamste en de andere keer disk3. Maar elke keer bepaalt de zwakste de latency van de gehele I/O request, die wordt uitgesmeerd over alle disks, wat niet het geval is bij een goed geconfigureerde RAID5 waarbij een leesactie door één disk wordt afgehandeld.

Bij RAID-Z1/2/3 is het dus méér dan RAID5 wenselijk dat je dezelfde schijven en ook dezelfde firmware op de schijven draait. Subtiele latency verschillen die wisselen per I/O kunnen ervoor zorgen dat je uiteindelijk lager uitkomt dan de traagste schijf in de groep.

[dcm360]

Compizfox schreef op donderdag 03 september 2015 @ 20:50:
[...]

Hoe bedoel je dat, en heb je het over read- of writeperformance? Zover ik weet, heeft RAID-5 (en ook RAID-Z) een readperformance van n*x en een writeperformance van (n-p)*x, met n het totaal aantal schijven, p het aantal parity-schijven en x de performance van een enkele disk.

n*x voor lezen lijkt me wel een beetje optimistisch. Dat kan je alleen halen door af en toe stukken data over te slaan op 1 disk (waarbij de n-1 andere disks de data van dat overgeslagen deel op zich nemen), wat dus af en toe een seek vereist en daarmee de maximale doorvoersnelheid wat afneemt. Met SSD's gaat een dergelijke strategie wel n*x benaderen, maar worst-case (dramatisch trage seeks, misschien een SMR-disk?) kan dat wel eens uitlopen op lager dan (n-p)*x. Mocht je een handigere strategie weten ben ik overigens ook wel benieuwd

[Compizfox]

Verwijderd schreef op donderdag 03 september 2015 @ 23:58:
[...]
RAID-Z gedraagt zich qua performance als RAID3, niet als RAID5.

Zou je dat iets verder willen uitleggen? Ben niet echt bekend met RAID-3, maar naar wat ik begrijp doet het byte-level striping in plaats van block-level striping (vergeleken met RAID-4)?

---

dcm360 schreef op vrijdag 04 september 2015 @ 00:03:
[...]

n*x voor lezen lijkt me wel een beetje optimistisch. Dat kan je alleen halen door af en toe stukken data over te slaan op 1 disk (waarbij de n-1 andere disks de data van dat overgeslagen deel op zich nemen), wat dus af en toe een seek vereist en daarmee de maximale doorvoersnelheid wat afneemt. Met SSD's gaat een dergelijke strategie wel n*x benaderen, maar worst-case (dramatisch trage seeks, misschien een SMR-disk?) kan dat wel eens uitlopen op lager dan (n-p)*x. Mocht je een handigere strategie weten ben ik overigens ook wel benieuwd

Dat zou best kunnen, ik weet er het fijne eerlijk gezegd ook niet van. Die n*x heb ik van deze Wikipedia-tabel, die deze bron citeert:

An additional, frequently overlooked advantage to distributing the parity is that it also distributes data over all of the disks rather than over all but one. This allows all disks to participate in servicing read operations in contrast to redundancy schemes with dedicated parity disks in which the parity disk cannot participate in servicing read requests.

Ik kan daar nergens letterlijk vinden dat de performance n*x zou zijn, maar volgens mij is het idee dat een sequentieel blok data van n schijven tegelijk gelezen kan worden. Als je dus een stream van 300 kB wil lezen van een n=3 RAID-5 array, lees je de eerste 100 kB van disk 1, de tweede 100 kB van disk 2 en de derde 100 kB van disk 3. Als het goed is kan dat allemaal tegelijkertijd en dat betekent dus dat je een stream 3x zo snel kunt lezen als met één enkele schijf.

[ Voor 9% gewijzigd door Compizfox op 04-09-2015 00:16 ]

[dcm360]

Compizfox schreef op vrijdag 04 september 2015 @ 00:15:
[...]
Ik kan daar nergens letterlijk vinden dat de performance n*x zou zijn, maar volgens mij is het idee dat een sequentieel blok data van n schijven tegelijk gelezen kan worden. Als je dus een stream van 300 kB wil lezen van een n=3 RAID-5 array, lees je de eerste 100 kB van disk 1, de tweede 100 kB van disk 2 en de derde 100 kB van disk 3. Als het goed is kan dat allemaal tegelijkertijd en dat betekent dus dat je een stream 3x zo snel kunt lezen als met één enkele schijf.

Dat werkt leuk als je chunks van 100KB naar de disks schrijft ja.. Anders lees je 100KB van disk 1 (welke de helft van de eerste 200KB bevat), 100KB van disk 2 (de andere helft van de eerste 200KB). Tegelijkertijd kan je wel leuk 100KB van disk 3 gaan lezen, maar dat bevat dus de helft van de data tussen 200KB en 400KB, en het is niet mogelijk daarvan de derde 100KB te construeren.

Bedenk wel even dat in dit geval de genoemde helften de helft zijn van de data, en niet netjes de eerste en tweede helft van een stuk van 200KB: de data is immers soort van gestriped.

[ Voor 8% gewijzigd door dcm360 op 04-09-2015 00:29 ]

[Verwijderd]

Compizfox schreef op vrijdag 04 september 2015 @ 00:15:
Zou je dat iets verder willen uitleggen? Ben niet echt bekend met RAID-3, maar naar wat ik begrijp doet het byte-level striping in plaats van block-level striping (vergeleken met RAID-4)?

Ja byte-level wordt vaak gezegd door mensen die RAID3 helemaal niet begrijpen, of een vage implementatie ergens in de prehistorie. Nee RAID3 betekent dat voor ELKE I/O-request, ALLE schijven worden betrokken - zowel voor lezen als schrijven. Alleen de parity kan bij lezen worden overgeslagen, maar dit biedt geen performancevoordeel.

RAID3 in de praktijk wil zeggen dat je de RAID-sectorsize uitsmeert over alle schijven. geom_raid3 bijvoorbeeld kan alleen in 3,5,9,17-disks worden gebruikt. Dit komt omdat de sectorsize leidend is en die moet een macht van twee zijn.

Het grote voordeel van RAID3 boven RAID5 is dat alle writes atomic zijn - er bestaan geen read-modify-write - iets wat random writes naar RAID5 zo traag maken. Nadeel van RAID3 is dat je de IOps performance van één disk hebt, terwijl RAID5 theoretisch zo hoog als RAID0 kan gaan.

De 'recordsize' in geval van een ZFS pool met een RAID-Z vdev, is in feite de sectorsize. Deze wordt dynamisch bepaald afhankelijk van de I/O die de applicatie genereert. Daarom is RAID-Z zo cool omdat het geen onveilige en trage read-modify-write procedures meer kent, die bij RAID5 niet te voorkomen zijn behalve voor contiguous sequential writes. Daar kun je met een write-combine engine de optimale write size vinden. Voor een 4-disk RAID5 met 32KiB stripesize is dat (4-1) * 32K = 96KiB. Alleen writes met die grootte zijn optimaal en vereisen geen read-modify-write. RAID3 en RAID-Z kennen dit probleem niet. RAID-Z is superieur aan RAID3 omdat het RAID-Z een variabele stripesize kent, iets wat geen enkele RAID engine ooit kan doen omdat dit kennis van het filesystem vereist. Daarom wordt ZFS ook beticht van een 'schending' van twee werelden: filesystem en RAID-laag. Maar daar zit nu juist de kracht en ook de voordelen....

Ik kan daar nergens letterlijk vinden dat de performance n*x zou zijn, maar volgens mij is het idee dat een sequentieel blok data van n schijven tegelijk gelezen kan worden. Als je dus een stream van 300 kB wil lezen van een n=3 RAID-5 array, lees je de eerste 100 kB van disk 1, de tweede 100 kB van disk 2 en de derde 100 kB van disk 3. Als het goed is kan dat allemaal tegelijkertijd en dat betekent dus dat je een stream 3x zo snel kunt lezen als met één enkele schijf.

Met RAID3, RAID4, RAID5, RAID6 en alle RAID-Z1/2/3 levels kun je bij leesacties alle disks aan het werk krijgen. In principe zou je een evengrote performance als RAID0 kunnen behalen. Toch lukt dit niet en dit is niet de schuld van de RAID-implementatie. Het zijn hardeschijven die in geval van de parity-schijf een gedeelte moet overslaan. Hierdoor kan het niet op volle snelheid lezen. Ditzelfde gebeurt bij mirrors die je als RAID0 gebruikt. Dat is nauwelijks sneller dan een domme mirror die van één disk leest. Dit komt omdat de schijven continu 50% van hun LBA moeten skippen. Intelligente RAID1 implementaties zoals ZFS lezen grotere blokken waardoor dit nadeel gemarginaliseerd wordt. En bij SSDs is dit nadeel geheel afwezig.

[Compizfox]

Verwijderd schreef op vrijdag 04 september 2015 @ 00:30:
[...]
Ja byte-level wordt vaak gezegd door mensen die RAID3 helemaal niet begrijpen, of een vage implementatie ergens in de prehistorie. Nee RAID3 betekent dat voor ELKE I/O-request, ALLE schijven worden betrokken - zowel voor lezen als schrijven. Alleen de parity kan bij lezen worden overgeslagen, maar dit biedt geen performancevoordeel.

Dan mag je dat Wikipedia-artikel editen

Maar eh, volgens mij snap ik het nog niet helemaal. Bij elke I/O-request moeten toch sowieso alle schijven worden betrokken? Je moet immers de data stripen over je data-disks en parity schrijven op je parity-disk.

De 'recordsize' in geval van een ZFS pool met een RAID-Z vdev, is in feite de sectorsize. Deze wordt dynamisch bepaald afhankelijk van de I/O die de applicatie genereert. Daarom is RAID-Z zo cool omdat het geen onveilige en trage read-modify-write procedures meer kent, die bij RAID5 niet te voorkomen zijn behalve voor contiguous sequential writes. Daar kun je met een write-combine engine de optimale write size vinden. Voor een 4-disk RAID5 met 32KiB stripesize is dat (4-1) * 32K = 96KiB. Alleen writes met die grootte zijn optimaal en vereisen geen read-modify-write. RAID3 en RAID-Z kennen dit probleem niet.

Eigenlijk is RAID-Z dus eerder een soort RAID-3 met distributed parity?

RAID-Z is superieur aan RAID3 omdat het RAID-Z een variabele stripesize kent, iets wat geen enkele RAID engine ooit kan doen omdat dit kennis van het filesystem vereist. Daarom wordt ZFS ook beticht van een 'schending' van twee werelden: filesystem en RAID-laag. Maar daar zit nu juist de kracht en ook de voordelen....

Ik heb eigenlijk nog nooit gehoord van iemand die dat als nadeel ziet, ik weet inderdaad dat dat de 'truc' van ZFS is

[...]
Met RAID3, RAID4, RAID5, RAID6 en alle RAID-Z1/2/3 levels kun je bij leesacties alle disks aan het werk krijgen. In principe zou je een evengrote performance als RAID0 kunnen behalen. Toch lukt dit niet en dit is niet de schuld van de RAID-implementatie. Het zijn hardeschijven die in geval van de parity-schijf een gedeelte moet overslaan. Hierdoor kan het niet op volle snelheid lezen. Ditzelfde gebeurt bij mirrors die je als RAID0 gebruikt. Dat is nauwelijks sneller dan een domme mirror die van één disk leest. Dit komt omdat de schijven continu 50% van hun LBA moeten skippen. Intelligente RAID1 implementaties zoals ZFS lezen grotere blokken waardoor dit nadeel gemarginaliseerd wordt. En bij SSDs is dit nadeel geheel afwezig.

Aha, ik denk dat ik het snap. De blocks zijn te klein waardoor het veel seeking oplevert in de schijven... is dat het?

[dcm360]

Verwijderd schreef op vrijdag 04 september 2015 @ 00:30:
[...]
Met RAID3, RAID4, RAID5, RAID6 en alle RAID-Z1/2/3 levels kun je bij leesacties alle disks aan het werk krijgen. In principe zou je een evengrote performance als RAID0 kunnen behalen. Toch lukt dit niet en dit is niet de schuld van de RAID-implementatie. Het zijn hardeschijven die in geval van de parity-schijf een gedeelte moet overslaan. Hierdoor kan het niet op volle snelheid lezen. Ditzelfde gebeurt bij mirrors die je als RAID0 gebruikt. Dat is nauwelijks sneller dan een domme mirror die van één disk leest. Dit komt omdat de schijven continu 50% van hun LBA moeten skippen. Intelligente RAID1 implementaties zoals ZFS lezen grotere blokken waardoor dit nadeel gemarginaliseerd wordt. En bij SSDs is dit nadeel geheel afwezig.

Meer geheugenbuffers er tegen aan mikken zou ik nou niet per se intelligent willen noemen.

Compizfox schreef op vrijdag 04 september 2015 @ 00:40:
[...]
Aha, ik denk dat ik het snap. De blocks zijn te klein waardoor het veel seeking oplevert in de schijven... is dat het?

Het gaat inderdaad over optimaliseren van de hoeveelheid benodigde seeks

[Verwijderd]

Compizfox schreef op vrijdag 04 september 2015 @ 00:40:
Dan mag je dat Wikipedia-artikel editen

Ja Wikipedia is ook maar een napraat-wiki - de SMART pagina bijvoorbeeld. Pffff. Mensen die dat hebben getypt, snappen echt niet waar ze het over hebben. En zo geldt dit voor meer dingen. Er wordt gekopieerd wat er op andere sites staan. En dat is soms ook incorrect.

Maar eh, volgens mij snap ik het nog niet helemaal. Bij elke I/O-request moeten toch sowieso alle schijven worden betrokken?

Niet bij RAID4 en RAID5 en RAID6 (parity RAID). Je hoeft alleen één disk + de parity te updaten. Bij ZFS RAID-Z en legacy RAID3 moeten alle disks betrokken worden bij zo'n write. Hoe klein ook.

Daarom kun je ook niet 512 bytes schrijven naar een RAID3 - de sectorsize wordt verhoogd. Bij een 5-disk RAID3 betekent dit dat de sectorsize 4 keer dat van een normale schijf is: 4*512B = 2KiB. Dat betekent dat je alleen in blokjes van 2KiB naar de RAID3 kunt schrijven; 512 bytes schrijven is simpelweg niet mogelijk. Een simpele dd if=/dev/zero of=/dev/raid3/testvolume bs=512 count=1 is dus gedoemd om te mislukken; je krijgt dan een error.

Eigenlijk is RAID-Z dus eerder een soort RAID-3 met distributed parity?

Ja. Met het verschil dan dat ZFS ook een dynamische stripesize gebruikt, met padding. Dit is niet te imiteren door welke RAID-implementatie dan ook. Maar afgezien daarvan is het qua performance-karakteristieken gelijk aan RAID3.

Ik heb eigenlijk nog nooit gehoord van iemand die dat als nadeel ziet, ik weet inderdaad dat dat de 'truc' van ZFS is

Nouja er zijn wat boze autistische *KUCH* geestelijk rechtlijnige mensen die vinden dat die werelden gescheiden moeten blijven, omdat zo een RAID-engine nooit kan nadoen wat ZFS doet. Maar boeie..?!

dcm360 schreef op vrijdag 04 september 2015 @ 00:45:
Meer geheugenbuffers er tegen aan mikken zou ik nou niet per se intelligent willen noemen.

Dat doet elke RAID5 engine ook dus dat is niets nieuws. Anders zou elke RAID5 engine tegen <10MB/s schrijven. Je hebt een split&combine-engine nodig. Dit betekent dat je requests moet opsparen, en dan in stukjes moet hakken van de gewenste optimale grootte, in mijn voorbeeld een paar posts terug was dat 96KiB, maar meestal is dit veel groter. Dat vereist inderdaad wat bufferruimte. Staat totaal niet in verhouding met de megabytes tot meerdere gigabytes die ZFS kan gebruiken voor één transactie. Dat is nog fftjes wat grotere buffer.

Het hele idee met intelligente RAID1 implementaties zoals geom_raid1 met load_balancing algoritme, is dat de disks zoveel mogelijk sequential I/O kunnen doen maar ook contiguous I/O. Oftewel, de blokjes die moeten worden gelezen of beschreven, moeten direct aaneensluitend zijn. Als de disks elke keer een blokje over moeten slaan, betekent dit 50% performanceverlies en daar gaat het hele voordeel van meer-dan-van-één-disk-lezen bij RAID1.

Wil je met RAID1 kunnen lezen zo snel als RAID0 dat doet, dan moet je zeggen disk1 doe jij LBA 1 tot 100 en disk2 doe jij LBA 101 tot 200. Dus niet zoals RAID0 doet: disk1 LBA1-2-3-4 en disk2 LBA5-6-7-8. Want dit betekent dat bij een volgende keer disk1 niet LBA5-6-7-8 moet lezen, maar 9-10-11-12, en dus moet het eerst 5-6-7-8 overslaan. Bij RAID1 staat die data ook op disk1, bij RAID0 niet. Daarom heb je bij RAID0 geen last van dit probleem, bij RAID1 moet je dus 'intelligente trucjes' uitvoeren om toch dezelfde performancepotentie te verzilveren als bij RAID0 gebruikelijk is.

[dcm360]

Ik zou het eerder willen omschrijven als 'intelligent trucjes uitvoeren', in plaats van 'intelligente trucjes uitvoeren'. Je (als zijnde implementatie) moet goed inschatten of een trucje toepassen wel handig is (en/of in welke mate): de (ik denk meeste?) trucjes toepassen kan namelijk best nadelig zijn als je worst-cases gaat toepassen tegen het trucje terwijl de worst-case zonder trucje minder nadelig was. Als je door een trucje lomp snel sequentieel kan lezen, maar in de praktijk nu de meeste random I/O door 1 disk van de hele set uitgevoerd moet worden (in plaats van netjes verdeeld over de schijven), is het trucje misschien niet geschikt voor dat gebruik. Terwijl iemand anders toch alleen maar veel sequentieel leest en de maximale performancepotentie kan benaderen (verzilveren vind ik te sterk om te gebruiken).

[Verwijderd]

Maar dat is hier niet het geval - de optimalisaties (trucjes) gaan niet ten koste van andere performance workloads. Het filesystem zorgt voor read-ahead - bij UFS standaard 8 * MAXPHYS dus 8*128KiB = 1MiB. Dus dat is je read-ahead. Dat is wat de RAID-laag aan requests krijgt. Dus dan moet het 1MiB gaan lezen. Dat kan het doen door domweg de disks te laten seeken, of door trucjes zoals hierboven te gebruiken. Maar als de RAID-laag één request van 512-byte read krijgt, zal het alleen die ene read uitvoeren en niet de rest. Filesystem read-ahead is nodig om de 'trucjes' daadwerkelijk te activeren, of async I/O vanuit de applicatie.

[FireDrunk]

Verwijderd schreef op vrijdag 04 september 2015 @ 00:52:
*knip

Ja. Met het verschil dan dat ZFS ook een dynamische stripesize gebruikt, met padding. Dit is niet te imiteren door welke RAID-implementatie dan ook. Maar afgezien daarvan is het qua performance-karakteristieken gelijk aan RAID3.

*knip*

Behalve BTRFS dan

[Verwijderd]

Leg dat is uit? Ik ken Btrfs niet, ik weet niet in hoeverre het afwijkt van ZFS. Maar als RAID kan doen wat Btrfs doet, betekent dit dat Btrfs flink minder geavanceerd is dan ZFS.

[M2M]

Inmiddels heb ik mijn tweede pool van 4 4TB schijven aan de Freenas toegevoegd, met uiteraard ZFS als filesystem. Nu zag ik echter dat er mogelijkheden zijn om logfiles en cache files toe te voegen aan het ZFS array met behulp van 1 of meerdere SSD's. Echter heb ik niet zo veel SATA poortjes meer over en zou ik graag voor beide arrays, 1 SSD willen gebruiken met logfiles en stukken cache van beide ZFS pools.

Is dat mogelijk?

[Bigs]

M2M schreef op vrijdag 04 september 2015 @ 11:10:
Inmiddels heb ik mijn tweede pool van 4 4TB schijven aan de Freenas toegevoegd, met uiteraard ZFS als filesystem. Nu zag ik echter dat er mogelijkheden zijn om logfiles en cache files toe te voegen aan het ZFS array met behulp van 1 of meerdere SSD's. Echter heb ik niet zo veel SATA poortjes meer over en zou ik graag voor beide arrays, 1 SSD willen gebruiken met logfiles en stukken cache van beide ZFS pools.

Is dat mogelijk?

Vanwaar de keuze voor een tweede pool boven een extra vdev aan je eerste pool? Dat laatste presteert in de meeste gevallen beter en bovendien heb je dan aan een enkel log/cache device genoeg.

Anders kun je je SSD's partitioneren zodat je voor elke pool een eigen log+cache partitie hebt.

[begintmeta]

Verwijderd schreef op vrijdag 04 september 2015 @ 10:45:
Leg dat is uit? Ik ken Btrfs niet, ik weet niet in hoeverre het afwijkt van ZFS. Maar als RAID kan doen wat Btrfs doet, betekent dit dat Btrfs flink minder geavanceerd is dan ZFS.

Ik zou vermoeden dat FireDrunk bedoelt dat btrfs kan doen wat zfs doet.

[Verwijderd]

Nou ook niet, want Btrfs snap het on-disk format van ZFS niet; die gebruikt zijn eigen formaat. Het doet hooguit iets equivalents van wat ZFS doet: het mixen van de RAID en filesystem lagen.

[DXaroth]

Verwijderd schreef op vrijdag 04 september 2015 @ 10:45:
Leg dat is uit? Ik ken Btrfs niet, ik weet niet in hoeverre het afwijkt van ZFS. Maar als RAID kan doen wat Btrfs doet, betekent dit dat Btrfs flink minder geavanceerd is dan ZFS.

Ik denk dat hij er op doelt dat Btrfs ook dynamische stripe-size aan kan...

[M2M]

Bigs schreef op vrijdag 04 september 2015 @ 11:25:
[...]


Vanwaar de keuze voor een tweede pool boven een extra vdev aan je eerste pool? Dat laatste presteert in de meeste gevallen beter en bovendien heb je dan aan een enkel log/cache device genoeg.

Anders kun je je SSD's partitioneren zodat je voor elke pool een eigen log+cache partitie hebt.

kon dat dan? Ik kon namelijk mijn zfs pool 1 enkel uitbreiden met stripe of mirror, ik kon 'm niet uitbreiden met raidz1. Of zie ik wat over het hoofd? Ik draai de laatste stabiele release van freenas overigens (geupdate vlak voor de harddisk uitbreiding)

[Verwijderd]

Vanaf ZFS versie één kun je elke ZFS pool uitbreiden met een extra stripe/mirror/RAID-Z1/2/3 vdev. Dus dat kan onder elke ZFS implementatie.

Wat niet kan is een bestaande vdev uitbreiden van 4 naar 6 disks, bijvoorbeeld. Dat is een beperking van ZFS.

[dcm360]

Verwijderd schreef op vrijdag 04 september 2015 @ 01:19:
Maar dat is hier niet het geval - de optimalisaties (trucjes) gaan niet ten koste van andere performance workloads. Het filesystem zorgt voor read-ahead - bij UFS standaard 8 * MAXPHYS dus 8*128KiB = 1MiB. Dus dat is je read-ahead. Dat is wat de RAID-laag aan requests krijgt. Dus dan moet het 1MiB gaan lezen. Dat kan het doen door domweg de disks te laten seeken, of door trucjes zoals hierboven te gebruiken. Maar als de RAID-laag één request van 512-byte read krijgt, zal het alleen die ene read uitvoeren en niet de rest. Filesystem read-ahead is nodig om de 'trucjes' daadwerkelijk te activeren, of async I/O vanuit de applicatie.

Volgens mij zijn we het inhoudelijk gewoon met elkaar eens als ik dit zo lees

[FireDrunk]

DXaroth schreef op vrijdag 04 september 2015 @ 12:01:
[...]


Ik denk dat hij er op doelt dat Btrfs ook dynamische stripe-size aan kan...

@CiPHER, dit dus inderdaad. BTRFS doet ook dynamic striping voor zover ik weet.

[Verwijderd]

Akkoord.

[FireDrunk]

Binnenkort krijg ik (eindelijk ) mijn 4*4TB schijven weer terug, dan kan ik lekker eens gaan spelen met BTRFS. Ik heb het plan om een keer een flinke vergelijking te maken met ZFS.

Als er nog mensen zijn die bepaalde scenario's getest willen hebben, laat maar weten

[DXaroth]

FireDrunk schreef op vrijdag 04 september 2015 @ 15:20:
Binnenkort krijg ik (eindelijk ) mijn 4*4TB schijven weer terug, dan kan ik lekker eens gaan spelen met BTRFS. Ik heb het plan om een keer een flinke vergelijking te maken met ZFS.

Als er nog mensen zijn die bepaalde scenario's getest willen hebben, laat maar weten

libzfs-python op bsd zou wel gewaardeerd worden (maar ben er niet rouwig op als dat niet mogelijk is).. qua vergelijkingen, meh, niet echt.

[FireDrunk]

BSD doe ik sowieso niet
Het wordt wel een vergelijking tussen ZoL en BTRFS

[Bigs]

Ik heb laatst even met btrfs gespeeld omdat ik ZOL niet werkend kreeg op mijn arm platform, maar als je in de ZFS mindset zit is het wel even wennen (en sommige dingen waren ronduit lastig). Uiteindeiljk was de CPU belasting veel te veel voor de magere ARM SoC uit mijn QNAP NAS dus ben er niet mee verder gegaan, maar voor mijn andere systemen vind ik ZOL voorlopig nog prima.

[Compizfox]

Verwijderd schreef op vrijdag 04 september 2015 @ 00:52:
[...]

Ja Wikipedia is ook maar een napraat-wiki - de SMART pagina bijvoorbeeld. Pffff. Mensen die dat hebben getypt, snappen echt niet waar ze het over hebben. En zo geldt dit voor meer dingen. Er wordt gekopieerd wat er op andere sites staan. En dat is soms ook incorrect.

Ik ben het daar over het algemeen niet mee eens; de meeste artikelen zijn gewoon van hoge kwaliteit. Alleen wat 'obscure' artikelen zoals deze willen wel eens incorrect/outdated informatie bevatten.

Het mooie van Wikipedia is dan natuurlijk dat jij, als iemand die het beter weet, het gewoon kan aanpassen. Dan moet je dat dus ook doen imho in plaats van te gaan zeuren

[...]

Niet bij RAID4 en RAID5 en RAID6 (parity RAID). Je hoeft alleen één disk + de parity te updaten. Bij ZFS RAID-Z en legacy RAID3 moeten alle disks betrokken worden bij zo'n write. Hoe klein ook.

Daarom kun je ook niet 512 bytes schrijven naar een RAID3 - de sectorsize wordt verhoogd. Bij een 5-disk RAID3 betekent dit dat de sectorsize 4 keer dat van een normale schijf is: 4*512B = 2KiB. Dat betekent dat je alleen in blokjes van 2KiB naar de RAID3 kunt schrijven; 512 bytes schrijven is simpelweg niet mogelijk. Een simpele dd if=/dev/zero of=/dev/raid3/testvolume bs=512 count=1 is dus gedoemd om te mislukken; je krijgt dan een error.
[...]
Ja. Met het verschil dan dat ZFS ook een dynamische stripesize gebruikt, met padding. Dit is niet te imiteren door welke RAID-implementatie dan ook. Maar afgezien daarvan is het qua performance-karakteristieken gelijk aan RAID3.

Bedankt voor de uitleg, het is me een stuk duidelijker!

[Verwijderd]

Dit wordt een beetje offtopic, dus ik heb mijn reactie hier geplaatst: Verwijderd in "De CSL/OT-kroeg".

[Loekie]

Zoek hier sparringpartners voor inrichten nieuwe ZFS-nas:
Hardware:
Virtueel systeem op basis van ZFSguru met 36 TiB die huidig ZFS met 12 TiB (telkens 8 disk/raidz2)gaat overnemen.
Huidige layout:

code:

/ZFS_12TB
/ZFS_12TB/BACKUPS
/ZFS_12TB/MUSIC
/ZFS_12TB/MYTHTV
/ZFS_12TB/OWNCLOUD
/ZFS_12TB/ZONEMINDER
/ZFS_12TB/share

Waarbij media als films muziek en downloads via het share filesystem worden doorgegeven aan de linuxhost die download en via plex aan clients aanbied.
Daarnaast worden er opnames via mythtv gemaakt, securitycams die via zoneminder plaatjes dumpen en is er een beperkte owncloud implementatie alles via zelfde linuxhost.
Linux host was in verleden mainserver en regelde ook storage, ZFSGuru is v.w.b. storage drop-in replacement en biedt bestanden aan via NFS aan linux host en via SMB aan windowsclients.
De 12 TB zal straks als backup gaan dienen voor de nieuwe host en wil ik d.m.v. zfs send/receive snapshots gaan voeren vanaf de mainhost van in ieder geval de Backups en owncloud en na verloop van tijd buiten de deur plaatsen.

Vraag is nu of het verstandig is de huidige share op te gaan delen naar media-gebruik(dus FILMS/ series apart evenals downloads van diezelfde films series) of MEDIA als 1 filesystem te houden t.b.v. snelle moves op 1 filesytem?

Daarnaast vraag wat beste strategie is m.b.t. compression en deduplicatie(vermoed dat dit voor de backups zinnig kan zijn als die veel documenten/textfiles bevatten) en of SSD's voor L2ARC en SLOG daar nog iets in betekenen.

[DXaroth]

Ik gebruik persoonlijk 3 aparte filesystems, 1 voor zooi dat verwerkt moet worden, 1 voor series, 1 voor films .. het is niet zo dat een film een serie gaat worden, of andersom, dus die ene keer dat je iets verkeerd verplaatst gaat niet zo'n probleem zijn.

Voor mij was het meer om fragmentatie tegen te gaan, als er tegelijk items klaargezet worden, dan zit je behoorlijk gefragmenteerd te schrijven, door daarna een aparte slag te maken naar de goede groep, zorg je er ook gelijk voor dat je het ietwat defragmenteerd... maar dat is meer persoonlijke smaak.

Daarnaast is het nu voor mij mogelijk om makkelijk een kopie te maken van enkel mn films of enkel mn series, zodat ik dus ze apart in de backup kan duwen, zonder dat die backups last hebben van zooi dat nog niet verwerkt is.

[HyperBart]

Wel, sinds kort zat ik met hetzelfde verhaaltje, en eigenlijk was het makkelijker geweest als ik voor Series en Films een apart filesystem had gemaakt.

Om je nu een idee te geven waarom:

Ik had van FireDrunk al een paar keer te horen gekregen dat Sonarr een pak beter werkt met failed download handling dan Sick Beard. Nu ja, Sick Beard draaide en ik had zoiets van "it ain't broken, don't fix it". Maar op een gegeven moment ging er toch heel wat mis waardoor ik Sonarr eens wou testdraaien, zo gezegd zo gedaan. Ik heb een zfs clone gemaakt van mijn Video-share (bij jou media) en aan de slag gegaan.

Maar daar zit ook nog een submapje Movies en eentje van Series onder, die Movies heb ik niet nodig, ok het kost niks met ZFS omdat het een snapshot is, maar dan kon ik ook makkelijker overstappen, nu zit ik ook nog eens met die Movies folder...

Dat hoeft op zich ook geen probleem te zijn want ik heb nu ample space om een promote van die clone te doen en twee opzichzelf staande FS'en te maken...

[FireDrunk]

Mijn Nieuwsgroepen downloads en Torrents komen beide op een /data/incoming binnen welke op een SSD buiten ZFS ligt.

Daarna verplaatsen de desbetreffende applicaties (Sonarr en Couchpotato) deze naar mijn ZFS volume welke opgedeeld is in verschillende Filesystems voor al die dingen.

Ik heb:

/archive
/archive/Series
/archive/Movies
/archive/Programs
/archive/Music
/archive/Backup

etc.

Works for me

Moves van Movies naar Series komen nooit voor, en moves van /data/incoming naar /archive gaan tegen 500MB/s dus die duren ook maar kort.

[ Voor 14% gewijzigd door FireDrunk op 11-09-2015 15:02 ]

[maomanna]

begrijp ik het nou goed dat je dus 1 ZFS pool hebt, "die gezien wordt als 1 hdd", met bijv ext4 als extensie en daarin verschillende mappen? Of heb je je ZFS pool gepartitioneerd, elke partitie een FS gegeven en daarop je dirs?

En wat doe je in je dir Programs?
Je installatiepakketen van software? of installeer je daar Sonarr op?

[ Voor 19% gewijzigd door maomanna op 11-09-2015 15:07 ]

[DXaroth]

maomanna schreef op vrijdag 11 september 2015 @ 15:06:
begrijp ik het nou goed dat je dus 1 ZFS pool hebt, "die gezien wordt als 1 hdd", met bijv ext4 als extensie en daarin verschillende mappen? Of heb je je ZFS pool gepartitioneerd, elke partitie een FS gegeven en daarop je dirs?

En wat doe je in je dir Programs?
Je installatiepakketen van software? of installeer je daar Sonarr op?

je hebt een paar lagen:

1) disk
2) vdev (een enkele of groep aan disks, een mirror van een X aantal vdevs of een raidz(X) van een aantal vdevs.. een vdev kan ook een disk zijn, maar ook een file)
3) zpool (een groep aan vdevs die samen je opslag worden)
4) dataset (een filesystem, of een volume als je de iscsi kant op gaat)

in een simpele raidz setup heb je dus 1 vdev van 2 of meer disks die als 1 zpool gezien wordt.. je kan er later nog een vdev bijgooien (een raidz2 bijvoorbeeld) om zo de zpool groter te maken... onder je zpool heb je de root dataset (die hetzelfde heet als je zpool), maar je kan ook sub-datasets aanmaken, zodat /storage/movies en /storage/series beide op dezelfde zpool verblijven, maar 2 aparte datasets zijn.

Verplaatsen tussen datasets is niet-instantaneous, dwz dat zfs letterlijk data gaat lezen en schrijven op je disks.

[maomanna]

ah dus als een dataset verdeeld wordt in meerdere subdatasets, is dit gelijk aan een gepartitioneerde hardeschijf in een windowsomgeving?

[Loekie]

Niet helemaal, want in jouw voorbeeld ligt de bovengrens qua ruimte vast, hier is het zo groot als onderliggende pool.

[maomanna]

het principe is dus hetzelfde, maar variabele grote waarbij alle sub datasets (partitities uit het vorige voorbeeld) gezamelijk de grote kunnen aannemen van de zpool.

Dat is dan erg handig en lijkt mij ook een goede toepassing voor mij.

[ Voor 30% gewijzigd door maomanna op 11-09-2015 15:32 ]

[DXaroth]

maomanna schreef op vrijdag 11 september 2015 @ 15:31:
het principe is dus hetzelfde, maar variabele grote waarbij alle sub datasets (partitities uit het vorige voorbeeld) gezamelijk de grote kunnen aannemen van de zpool.

Dat is dan erg handig en lijkt mij ook een goede toepassing voor mij.

Plus je kan features aan/uit zetten per dataset, zoals quotas, async of dedup.

[rikadoo]

Vandaag maar even de stoute schoenen aangetrokken en even een beetje wezen rondneuzen in ZFSGuru op mijn T3500 systeem. Ziet er leuk uit en werkt opzich prima! Wel een vraag bij XPenology(wat ik nu heb) heb je veel packages etc, is zoiets er ook voor ZFSGuru?

[Dutch2007]

rikadoo schreef op vrijdag 11 september 2015 @ 16:59:
Vandaag maar even de stoute schoenen aangetrokken en even een beetje wezen rondneuzen in ZFSGuru op mijn T3500 systeem. Ziet er leuk uit en werkt opzich prima! Wel een vraag bij XPenology(wat ik nu heb) heb je veel packages etc, is zoiets er ook voor ZFSGuru?

Je kan of de packages gebruiken van ZFSGuru... of je gebruik de ports van FreeBSD zelf (en gebruikt mogelijk ZFSGuru alleen als web-shell.. --> https://freshports.org/ (en dan gewoon naar tool zoeken wat je wil hebben

voorbeeld --> https://freshports.org/search.php?query=samba42

To install the port: cd /usr/ports/net/samba42/ && make install clean
To add the package: pkg install net/samba42

Let op: ivm de manier hoe ZFSGuru iig z'n ideeën heeft over packages aanbieden kan ik iig niet verantwoordelijk gehouden worden als je en packages van zfsguru gebruiken + freebsd.... sommige nieuwe versies (bijv. van PHP5 wilden in het verleden wel eens de web-gui om zeep helpen enzo...)

** ports werkt via de terminal console, welke ook in de web-gui van zfsguru zit dus putty is niet nodig perse....

eerste keer in die cli @web-gui het volgende invullen en je kan de boven gelinkte site daarna usen is...

portsnap fetch extract

laatste ports binnen halen:

portsnap update

met portmater kan je alle geinstalleerde ports updaten..

command:

pkg install ports-mgmt/portmaster

en daarna kan je dan..

portmaster -a

uitvoeren in de cli...

[ Voor 20% gewijzigd door Dutch2007 op 11-09-2015 17:09 ]

[rikadoo]

Dutch2007 schreef op vrijdag 11 september 2015 @ 17:04:
[...]

Je kan of de packages gebruiken van ZFSGuru... of je gebruik de ports van FreeBSD zelf (en gebruikt mogelijk ZFSGuru alleen als web-shell.. --> https://freshports.org/ (en dan gewoon naar tool zoeken wat je wil hebben

voorbeeld --> https://freshports.org/search.php?query=samba42

[...]


Let op: ivm de manier hoe ZFSGuru iig z'n ideeën heeft over packages aanbieden kan ik iig niet verantwoordelijk gehouden worden als je en packages van zfsguru gebruiken + freebsd.... sommige nieuwe versies (bijv. van PHP5 wilden in het verleden wel eens de web-gui om zeep helpen enzo...)

Super bedankt! Ik zal eens rondkijken. Mocht het fout dan, dan installeer ik zfsguru wel weer opnieuw. Is toch mijn test server met 2x 250gb. Staat ook geen data op.

[Dutch2007]

rikadoo schreef op vrijdag 11 september 2015 @ 17:08:
[...]


Super bedankt! Ik zal eens rondkijken. Mocht het fout dan, dan installeer ik zfsguru wel weer opnieuw. Is toch mijn test server met 2x 250gb. Staat ook geen data op.

no problemo...



darn is een mogelijk resultaat als je portmaster -a doet.. als ie packages heeft om te updaten...

via putty een cli doen is trouwens aan te raden en dan bijv eerst "screen" te installeren, als je de putty verbinding verbreekt gaat ie wel gewoon door met de commands welke je hebt opgegeven.... als je een normale putty verbinding in 't midden van iets stops dan niet nml ;-)

[Tsurany]

rikadoo schreef op vrijdag 11 september 2015 @ 16:59:
Vandaag maar even de stoute schoenen aangetrokken en even een beetje wezen rondneuzen in ZFSGuru op mijn T3500 systeem. Ziet er leuk uit en werkt opzich prima! Wel een vraag bij XPenology(wat ik nu heb) heb je veel packages etc, is zoiets er ook voor ZFSGuru?

Bij FreeNAS werken de standaard plugins erg eenvoudig. Komen ook keurig in een eigen jail terecht. De rest van de software die je wilt hebben kan je zelf installeren in jails. Ik draai zelfs een jail met VirtualBox met daarin XPEnology.

[CurlyMo]

@Loekie, voor mij geldt, wil ik data backuppen? Dan in een aparte FS. Als voorbeeld mijn indeling:

code:

data/users/user1/Hobby                 28.6G  1.30T  28.6G  /data/users/user1/Hobby
data/users/user1/Persoonlijk           12.0G  1.30T  11.9G  /data/users/user1/Persoonlijk
data/users/user1/School                89.4G  1.30T  89.4G  /data/users/user1/School
data/users/user1/Temp                   153M  1.30T   153M  /data/users/user1/Temp
data/users/user1/Werk                  5.66G  1.30T  5.56G  /data/users/user1/Werk
data/users/user2                        117G  1.30T  48.9M  /data/users/user2
data/users/user2/Hobby                 36.8G  1.30T  15.6G  /data/users/user2/Hobby
data/users/user2/Persoonlijk           42.1G  1.30T  41.9G  /data/users/user2/Persoonlijk
data/users/user2/School                25.1G  1.30T  25.1G  /data/users/user2/School
data/users/user2/Temp                  11.6G  1.30T  11.6G  /data/users/user2/Temp
data/users/user2/Werk                  1.13G  1.30T   655M  /data/users/user2/Werk
data/users/shared                      1.83T  1.30T   279K  /data/users/shared
data/users/shared/Audio                37.3G  1.30T  37.3G  /data/users/shared/Audio
data/users/shared/Fotografie            414G  1.30T   414G  /data/users/shared/Fotografie
data/users/shared/Gedeeld               550M  1.30T   246M  /data/users/shared/Gedeeld
data/users/shared/Internet             48.2G  1.30T   267K  /data/users/shared/Internet
data/users/shared/Internet/Downloads   16.1G  1.30T  16.1G  /data/users/shared/Internet/Downloads
data/users/shared/Internet/Incompleet  23.8G  1.30T  23.8G  /data/users/shared/Internet/Incompleet
data/users/shared/Internet/Torrents    8.24G  1.30T  8.24G  /data/users/shared/Internet/Torrents
data/users/shared/Systeem              41.7G  1.30T  41.7G  /data/users/shared/Systeem
data/users/shared/Video                1.30T  1.30T  4.55G  /data/users/shared/Video
data/users/shared/Video/Films           682G  1.30T   682G  /data/users/shared/Video/Films
data/users/shared/Video/Persoonlijk     143G  1.30T   143G  /data/users/shared/Video/Persoonlijk
data/users/shared/Video/TV              506G  1.30T   506G  /data/users/shared/Video/TV

Ik backup alle gebruikersmappen (behalve Temp), en vanuit shared alleen Fotografie, Gedeeld en Video/Persoonlijk.

[Q]

ZFS voor Linux is uit met largeblocks support, dit is *HUGE*.

https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5

[maomanna]

zojuist mn ZFS pool gemaakt met 4x 5TB.
Hou een mooie 18TB over in raidZ1. Niet slecht

[Verwijderd]

1 ding snap ik niet. stel je hebt de volgende situatie:

• datapool [list]
• raidz1-0
  • c0t5001
  • c0t5002
  • c0t5003
• raidz1-1
  • c0t5004
  • c0t5005
  • c0t5006
• [/list]

dan heb je dus een stripe over 2 raidz's (?) en áls 1 van die raidz's failed dan is ál je data weg omdat het een stripe is. of zie ik dit fout?

[Verwijderd]

@Q: ik dacht dat jullie zeiden dat ZoL allang large_blocks ondersteuning had?

@IBMFD3S: dat begrijp je juist. Daarom geen RAID-Z gebruiken maar RAID-Z2.

[syl765]

@CiPHER

En hoe helpt raidz2 als de hele raidz2 vdev weg valt?

@IBMFD3S
Je kunt met zfs geen vdev verliezen. Wel schijven in een mirrored, en raidz(x) vdev.
Hoeveel schijven je kan missen in een vdev hangt af van de raid versie of in een mirrored setup hoeveel schijven je in een mirror hebt.

In een raidz1 vdev kun je 1 disk missen, in een raidz2 vdev kun je twee schijven missen en in een raidz3 kun je drie schijven missen.
In een 2way mirror kun je 1 schijf missen, in een 3way mirror weer twee en in een 4way mirror 3 enz enz, een 3 way en hogere mirror is natuurlijk wel erg inefficient.

In een zpool met 20 2way mirrors, kun je in theory dus 20 schijven missen zolang er van iedere vdev maar 1 schijf stuk gaat. In een zpool met 20 raidz1 vdevs kun je 20 schijven missen, zolang er maar 1 schijf in iedere vdev sneuvelt. In een pool met 20 raidz2 vdevs kun je 40 schijven verliezen zolang er maar maximaal 2 schijven per vdev sneuvelen.

In jou geval kun je twee schijven missen.
1 in vdev raidz1-0 en 1 in raidz1-1 je kan niet twee schijven missen in raidz1-0 of raidz1-1.

gr

[Verwijderd]

@syl765: RAID-Z2 moeten 3 disks falen voordat deze 'wegvalt' - dat is zeer ongebruikelijk zonder gemeenschappelijke oorzaak. Met jouw argument is geen enkele opslagmethode veilig. Wat als een meteoriet de Aarde vernietigt? Duh...

[riwi]

Verwijderd schreef op zaterdag 12 september 2015 @ 17:55:
@Q: ik dacht dat jullie zeiden dat ZoL allang large_blocks ondersteuning had?

Dat is ook al een paar maanden het geval. Tenminste als je git head volgt.

Echter is er nu (dit weekend) een nieuwe tag gekomen 0.6.5 waarin dus de large block feature ook beschikbaar is.
Voor mensen die de major releases volgen is het er dus nu ook. En dat betekent ook dat het nu in de beschikbare distributie packages automatisch geleverd zal worden

[ Voor 6% gewijzigd door riwi op 12-09-2015 20:40 ]

[Q]

Ik had begrepen dat Large_blocks helpt om de overhead te reduceren die je krijgt met 128K blocks en grote files, en helemaal als je een niet optimaal aantal disks in een VDEV stopt, maar ik kan daar eigenlijk nergens meer informatie over terug vinden. Iemand tips?

[ Voor 18% gewijzigd door Q op 12-09-2015 21:04 ]

[Verwijderd]

Dat klopt niet wat je zegt. Ik had het een tijd geleden goed uitgelegd. large_blocks zorgt ervoor dat je een recordsize hoger dan 128K kunt instellen. Het moet een macht van 2 zijn (geen veelvoud!) dus concreet betekent dit: 256K, 512K tot maximaal 1024K.

Dit zorgt zeker voor lagere overhead, want 1024K gedeeld door het aantal data disks zorgt nu voor een groter getal. Laat dit bijvoorbeeld 353.5K zijn, dan is bij 4K optimalisatie de hoeveelheid slack procentueel veel minder groot dan wanneer je 21.5K per disk zou doen. Dus je hebt vrijwel geen ruimteverlies meer bij niet-optimale pools zoals een 11-disk RAID-Z2 met ashift=12.

Daarnaast zorgen de grote blocks ervoor dat hardeschijven efficiënter werken. SSDs hebben hier minder last van.

[riwi]

Ik heb het op mijn testbak uitgeprobeerd met 1MB blocksize maar merkte weinig verschil.
Dwz 1 zfs met en 1 zfs zonder onder dezelfde pool met dezelfde content (files gekopieerd).

Ik las dat het met name voor zvol gebruik voordelen opleverde.

[ Voor 3% gewijzigd door riwi op 12-09-2015 21:24 ]

[Verwijderd]

Nee de voordelen zijn evengoed voor normale filesystems.

De vraag is natuurlijk: wat was je pool configuratie. Onder ashift=9 pools heb je weinig voordeel. Onder ashift=12 pools met optimale disk count in RAID-Z1/2/3 heb je weinig voordeel. En mirror/stripe pools hebben weinig voordeel.

Het voordeel zit hem in grote hoeveelheden disks in RAID-Z1/2/3 vdevs die met ashift=12 (4K optimalisatie) worden aangemaakt, terwijl je niet een optimaal aantal disks hebt. Dus 9 disks in RAID-Z2 bijvoorbeeld.

[maomanna]

wanneer is het verstandig om voor de 4k optimalisatie te gaan?

[Verwijderd]

Altijd eigenlijk. Want native 4K disks kun je niet meer toevoegen aan een ashift=9 (512-byte) vdev.

Standaard wordt nu bijna alles 4K aangemaakt, dus ashift=12.

[Q]

@CiPHER bedankt voor de toelichting.

Ik had de essentie wel goed mee gekregen: dat NAS bouwers nu zonder serieus nadeel een sub-optimaal aantal disks in een RAIDZx VDEV kan stoppen als je de record size op bijv 1 MB zet.

Een 8-disk RAIDZ2 is dus opeens wel OK, je hoeft niet of 6 of 10 disks te kiezen. Dat is weer interessant voor die discussie die in het DIY NAS liep denk ik (Over setup van HenryM).

[ Voor 8% gewijzigd door Q op 12-09-2015 22:30 ]

[Verwijderd]

Ik lees je bericht nu terug en ik heb het denk ik verkeerd gelezen, sorry! Ik dacht juist dat je zei dat het GEEN verschil zou maken. Dat is niet wat je typte. Dus ik heb te snel gelezen.

[syl765]

@CiPHER
Dit is wat IBMFD3S vroeg

dan heb je dus een stripe over 2 raidz's (?) en áls 1 van die raidz's failed dan is ál je data weg omdat het een stripe is. of zie ik dit fout?

Hij vraagt dus als 1 van de raidz's failed.. Dat lees ik als een hele vdev en daar helpt geen enkele raid level tegen. Vandaar dus even mijn vraag aan jou aangezien ik jou toch hoog heb zitten waar het gaat om ZFS storage enz. Houd er rekening mee dat veel mensen jou antwoord als waarheid aannemen, in deze geef je dus een verkeerd antwoord. Als jij dan even netjes antwoord inderdaad bij het verliezen van een vdev of zoals de originele vraagsteller deze raidz noemt dan gaat de vrager niet om een verkeerde reden over op raidz2.

Welk argument haal ik aan dat geen enkele raid level voldoet? Die duh op het einde van jou reactie is dan ook nergens voor nodig.

[ Voor 28% gewijzigd door syl765 op 13-09-2015 01:03 ]

[Verwijderd]

Waarop ik antwoord:

dat begrijp je juist. Daarom geen RAID-Z gebruiken maar RAID-Z2.

Dan reageer jij met de vraag hoe een RAID-Z2 dan zou helpen. Dat laat zich raden: omdat een RAID-Z2 vrijwel niet faalt met een laag nummer aan disks - dat is zeer ongebruikelijk. Tenzij je inderdaad over statistisch insignificante risico's praat. Dus een RAID-Z2 helpt omdat het zorgt dat je geen vdev meer verliest - tenzij dit door een gemeenschappelijke oorzaak komt zoals een voeding die doorfikt, brand, diefstal enzovoorts. Maar mijn punt is dat dan geen enkel RAID level meer zou helpen, dus dat maakt het punt van meerdere vdevs in stripe weer overbodig. Dat bedoelde ik met 'duh' - maar dat was niet onaardig bedoeld.

[ Voor 4% gewijzigd door Verwijderd op 13-09-2015 01:03 ]

[syl765]

Ik weet dat het verliezen van een hele vdev niet aannemelijk is door schijf falen. Maar het blijft een feit dat als je hem verliest dat je pool weg is. Bedenk ook dat er mensen zijn die bij een upgrade een extra HBA kopen of een raid kaartje en daar dan de 5 nieuwe disks aanhangen en deze in een raidz2 aan de pool toevoegen. De kans is nu al een stuk groter dat je een vdev verliest als de hba of het raid kaartje de geest geeft.
En in deze maakt het helemaal niets uit of je raidz2, 3 of een 8way mirror gebruikt.

[ Voor 4% gewijzigd door syl765 op 13-09-2015 01:14 ]

[Verwijderd]

Maar het blijft een feit dat als je hem verliest dat je pool weg is.

Ik snap je punt. Maar mijn punt is dus dat dit geen issue is omdat het verlies van een RAID-Z2 - zonder een gemeenschappelijke oorzaak zoals de voeding of brand enzovoorts - statistisch insignificant is, mits je met beperkt aantal disks werkt.

Het verschil tussen een RAID-Z2 en en een vdev met twintigduizend parity schijven zal statistisch niet eens zo groot zijn. De andere risico's - die je met redundancy niet kunt afdekken - blijven dan onverminderd groot zodat een backup dan wel high availability veel meer voor de hand ligt.

[ Voor 6% gewijzigd door Verwijderd op 13-09-2015 01:23 ]

[riwi]

Verwijderd schreef op zaterdag 12 september 2015 @ 21:36:
Nee de voordelen zijn evengoed voor normale filesystems.

De vraag is natuurlijk: wat was je pool configuratie. Onder ashift=9 pools heb je weinig voordeel. Onder ashift=12 pools met optimale disk count in RAID-Z1/2/3 heb je weinig voordeel. En mirror/stripe pools hebben weinig voordeel.

Ik las van mensen die ermee testen dat ze duidelijke performance winst haalden bij zvol gebruik. Ikzelf merkte met files niet direct een verschil in performance.
Kwa optimaal gebruik maken van de diskspace zal er geen verschil zijn tussen zvol en normale files.

Mijn test was met een raid-z2 single vdev pool met 6x 1.5T schijven met ashift=12 want vrijwel alle schijven zijn 4k tegenwoordig.

[Verwijderd]

riwi schreef op zondag 13 september 2015 @ 13:25:
Mijn test was met een raid-z2 single vdev pool met 6x 1.5T schijven met ashift=12 want vrijwel alle schijven zijn 4k tegenwoordig.

Ja....

Zoals gezegd heb je vrijwel geen voordeel bij optimale configuraties. Jouw 6 disks in RAID-Z2 is een optimale configuratie. Dus logisch dat je weinig voordeel merkt - dat is er ook nauwelijks.

[Loekie]

Ik heb een typisch probleempje met importeren van de RAIDZ2 pool, deze wordt wel netjes geïmporteerd. Maar lijkt daarna vol te zijn(in vorige systeem was er nog ca 93GB vrij) en kan ik ook via cli geen directory meer aanmaken.
Pool name SPA Redundancy Capacity Used Free Status
DUALUSB 5000 RAID1 (mirroring) 7.12G 2.19G 4.94G ONLINE
ZFS_12TB 5000 RAID6 (double parity) 14.5T 14.1T 380G ONLINE

[root@zfsguru /home/ssh]# mkdir /ZFS_12TB/share/TEST
mkdir: /ZFS_12TB/share/TEST: No space left on device

Overzicht van files onder ZFSGuru:

code:

Filesystem  Used    Avail   Refer   Mountpoint
DUALUSB     2.19G   4.72G   160K    /DUALUSB
DUALUSB/share   152K    4.72G   152K    /DUALUSB/share
ZFS_12TB    10.0T   0   444K    /ZFS_12TB
ZFS_12TB/BACKUPS    45.8G   0   45.8G   /ZFS_12TB/BACKUPS

Iemand vermoeden wat dit kan zijn?

[ Voor 13% gewijzigd door Loekie op 13-09-2015 23:48 ]

[Verwijderd]

Reserveringen en interne ZFS dingen (log, metadata) zorgen voor een verschil tussen de vrije ruimte die zpool list aangeeft en wat zfs list aangeeft. Dat laatste is leidend - dat is bruikbare ruimte. In jouw geval 444K dus dat betekent dat hij vol zit.

Heb je bijvoorbeeld een SWAP zvol van meerdere gigabytes, dan is deze waarschijnlijk sparse aangemaakt want dat doet de ZFSguru installer voor je. Dat betekent ook dat die ruimte enkel gereserveerd wordt. zpool list geeft aan dat er nog vrije ruimte is, maar zfs list geeft aan dat alles vol zit (444K is vrijwel 'vol').

Het is overigens onverstandig om je pool zo vol te maken, want je zorgt voor fragmentatie op je pool. Omdat je een oudere versie draait, kun je die fragmentatie niet zien in de zpool list output, want die wordt bij recente versies wel getoond.

[Loekie]

Ik vind dat toch typisch, vanochtend van oude machine verhuisd naar 'nieuwe' machine waarop laatste zfsguru draait en dan ineens 93GB weg?
Ik heb even overzicht bijgewerkt, zodat het wat duidelijker weergegeven wordt.

Ik heb al een 20GB verwijderd op nieuwe machine, maar levert geen ruimte op.

V.w.b. ruimte: Dat is ook reden voor nieuwe Array van 6 TB disks, dat draait inmiddels redelijk lekker.

[Verwijderd]

Als je dingen verwijdert, maar het levert geen ruimte op, is dat meestal omdat je een snapshot hebt die de data nog referenced. Dus dan moet je ook de snapshot verwijderen.

[Loekie]

Filesystem @ Snapshot name Used Refer Operation
0 B Total snapshot usage
Het rare is dat bij verwijderen van die 20G wel zpool status bijgewerkt wordt, maar niet zfs status.
Ik laat wel even een scrub lopen, want:

code:

[root@zfsguru /home/ssh]# zpool list
NAME       SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
DUALUSB   7.12G  2.38G  4.74G         -      -    33%  1.00x  ONLINE  -
ZFS_12TB  14.5T  14.1T   380G         -    25%    97%  1.00x  ONLINE  -
[root@zfsguru /home/ssh]# zfs list
NAME                                USED  AVAIL  REFER  MOUNTPOINT
DUALUSB                            2.44G  4.46G   168K  /DUALUSB
ZFS_12TB                           10.0T      0   444K  /ZFS_12TB

Ik zal eens een scrub laten lopen, zien of dat wat oplevert. Maar vind het vreemd dat die 93 GB die vanaochtend nog op oude systeem aanwezig was, op het nieuwe systeem compleet niet meer aanwezig lijkt.