Het grote ZFS topic

[CurlyMo]

@Tha_Butcha Heb je al eens in de kernel logs gekeken met dmesg?

[dcm360]

Als je per se de pending sectors weg wil halen, moet je inderdaad de schijf een keer overschrijven. Maar op zich kan je ook ZFS een scrub laten doen, en als de pending sectors zich in jouw data bevinden zal ZFS na een leesfout de correcte data terugschrijven en zal de schijf de pending sectors wegwerken. Als er te veel pending sectors blijken te zijn zal ZFS geen zin meer hebben in de schijf, maar dan zijn het er op zich ook wel zo veel dat ik de schijf wel als gammel zou bestempelen. En als de pending sectors buiten jouw data liggen, is er ook geen issue (tenzij het aantal oploopt), dan is de eerstvolgende actie die je op de sector doet toch waarschijnlijk schrijven en niet lezen.

[FireDrunk]

ZFS heeft in de basis helemaal geen weet van Pending Sectors. ZFS leest geen smart data uit.
Enige wat ZFS merkt is dat er IO errors optreden vanuit de schijf, doordat ofwel de data niet geleverd wordt, ofwel dat de data niet aan de checksum voldoet.

[willemw12]

@Tha_Butcha: waarschijnlijk niet maar heb je misschien heel veel snapshots? Zie https://jira.ixsystems.co...9?attachmentViewMode=list.

[Tha_Butcha]

update:

ik heb de zfs-utils geupdate (via een externe ppa, meer info hier) en de rest wil nu ook syncen. Dus het probleem lijkt opgelost te zijn

[GioStyle]

Ik heb 3x WD Blue SN550 1TB in huis. Momenteel zijn dit 3 losse pools.

Zijn er enige nadelen als ik een pool raidz1 van deze ssd's maak?

Ja, ik verlies 1/3e aan opslag. Dat snap ik, maar zijn er nog meer nadelen?

[ocaj]

Ik heb een oude externe zfs-schijf waar ik iets van nodig heb, maar ik krijg hem niet geïmporteerd.

De schijf is ooit aangemaakt op mijn vorige server, die draaide openindiana ("solaris-variant") en momenteel heb ik een proxmox-server (linux/debian). Normaal geen problemen om schijven die aangemaakt zijn op de vorige server te importeren, maar nu dus wel.

Output van zpool import:

code:

root@pve:~# zpool import
   pool: backup
     id: 699077873695507153
  state: FAULTED
status: The pool metadata is corrupted.
 action: The pool cannot be imported due to damaged devices or data.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-72
 config:

    backup      FAULTED  corrupted data
      sde       ONLINE

Daarna eerst maar eens gekeken of ik in de output van dmesg iets vreemds zag:

code:

[2767984.110905] usb 3-4: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[2767984.137911] usb 3-4: New USB device found, idVendor=0bc2, idProduct=3321, bcdDevice= 1.00
[2767984.137938] usb 3-4: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[2767984.137949] usb 3-4: Product: Expansion Desk
[2767984.137956] usb 3-4: Manufacturer: Seagate
[2767984.137963] usb 3-4: SerialNumber: NA4KV847
[2767984.162458] usbcore: registered new interface driver usb-storage
[2767984.173887] scsi host9: uas
[2767984.174233] usbcore: registered new interface driver uas
[2767984.175194] scsi 9:0:0:0: Direct-Access     Seagate  Expansion Desk   0604 PQ: 0 ANSI: 6
[2767984.176279] sd 9:0:0:0: Attached scsi generic sg5 type 0
[2767984.176558] sd 9:0:0:0: [sde] Spinning up disk...
[2767985.210372] ............ready
[2767996.474876] sd 9:0:0:0: [sde] 976754645 4096-byte logical blocks: (4.00 TB/3.64 TiB)
[2767996.474890] sd 9:0:0:0: [sde] 16384-byte physical blocks
[2767996.483656] sd 9:0:0:0: [sde] Write Protect is off
[2767996.483682] sd 9:0:0:0: [sde] Mode Sense: 4f 00 00 00
[2767996.483885] sd 9:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[2767996.484405] sd 9:0:0:0: [sde] Optimal transfer size 268431360 bytes not a multiple of physical block size (16384 bytes)
[2767996.571120]  sde: sde1 sde9
[2767996.611457] sd 9:0:0:0: [sde] Attached SCSI disk

Wat me hier opvalt is dat hij aangeeft dat het een schijf met 16k-fysieke blokken is. Verder wordt de schijf prima herkend (4TB externe seagate schijf), fysiek lijkt de schijf dus ok.

Vervolgens met gdisk gekeken hoe die vind dat de schijf eruit ziet:

code:

root@pve:~# gdisk -l /dev/sde
GPT fdisk (gdisk) version 1.0.6

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sde: 976754645 sectors, 3.6 TiB
Model: Expansion Desk  
Sector size (logical/physical): 4096/4096 bytes
Disk identifier (GUID): 36B3EA9F-8BC6-2067-DADC-AA3C7449FA7B
Partition table holds up to 9 entries
Main partition table begins at sector 2 and ends at sector 2
First usable sector is 6, last usable sector is 976754639
Partitions will be aligned on 16-sector boundaries
Total free space is 250 sectors (1000.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1             256       976738255   3.6 TiB     BF01  zfs
   9       976738256       976754639   64.0 MiB    BF07

gdisk herkent de schijf met 4k-sectors (zowel fysiek als logisch), dat is dus al een opvallend verschil met dmesg.
Ik weet niet of de schijf nu 4k of 16k-sectors heeft, maar als het OS het al niet weet, dan lijkt de kans mij aannemelijk dat er bij zpool import een verkeerde aanname gedaan wordt, waardoor hij de metadata niet kan vinden en dus corrupt vind?

Tot slot nog gekeken wat zdb er van vindt:

code:

root@pve:~# zdb -e backup

Configuration for import:
        vdev_children: 1
        version: 28
        pool_guid: 699077873695507153
        name: 'backup'
        state: 1
        hostid: 8899160
        hostname: 'zfsnas'
        vdev_tree:
            type: 'root'
            id: 0
            guid: 699077873695507153
            children[0]:
                type: 'disk'
                id: 0
                guid: 13389692541741061876
                whole_disk: 1
                metaslab_array: 30
                metaslab_shift: 35
                ashift: 14
                asize: 4000714063872
                is_log: 0
                DTL: 198
                create_txg: 4
                path: '/dev/sde1'
                devid: 'usb-Seagate_Expansion_Desk_NA4KV847-0:0-part1'
                phys_path: 'pci-0000:00:10.0-usb-0:4:1.0-scsi-0:0:0:0'
        load-policy:
            load-request-txg: 18446744073709551615
            load-rewind-policy: 2
zdb: can't open 'backup': No such device or address

ZFS_DBGMSG(zdb) START:
spa.c:6084:spa_import(): spa_import: importing backup
spa_misc.c:418:spa_load_note(): spa_load(backup, config trusted): LOADING
spa_misc.c:403:spa_load_failed(): spa_load(backup, config untrusted): FAILED: no valid uberblock found
spa_misc.c:418:spa_load_note(): spa_load(backup, config untrusted): UNLOADING
ZFS_DBGMSG(zdb) END

Hier zie ik wel een ashift = 14, wat overeenkomt met 16k-sectors.
Ook zie ik een whole_disk = 1, terwijl de output van gdisk aangeeft dat er aan het einde van de schijf nog een 64MB-partitie is. Die whole-disk lijkt me terecht, ik gebruik voor externe schijven meestal bij het aanmaken van een zpool simpelweg de device-naam en geen aparte partities op het device. Van de andere kant geeft zdb ook als pad /dev/sde1 aan, wat - in ieder geval in mijn logica - niet overeenkomt met de whole_disk?

Mijn onderbuikgevoel zegt dat er niks mis is met de disk, maar dat ik hem alleen niet op de juiste manier benader....
Iemand suggesties wat ik nog kan proberen om de schijf te importeren?

[CurlyMo]

Even in openindiana proberen lijkt me het meest voor de hand liggend.

[ocaj]

Dat ligt wel voor de hand, ware het niet dat ik die server niet meer heb...

[Thralas]

Gelukkig heb je een hypervisor waar je VMs op kunt draaien Zou wel de hele USB controller passthroughen.

En desnoods boot je een live image met Illumos/OI om te zien of het werkt.

[ocaj]

Thralas schreef op woensdag 9 februari 2022 @ 21:03:
Gelukkig heb je een hypervisor waar je VMs op kunt draaien Zou wel de hele USB controller passthroughen.

En desnoods boot je een live image met Illumos/OI om te zien of het werkt.

Goed punt, had ik nog niet aan gedacht (ik draai er eigenlijk alleen LXC-containers op). Zojuist een openindiana-live-image in een VM gestart met passthrough van de usb-poort waar de schijf op zit (ik zag in proxmox zo gauw geen mogelijkheid om de hele controller te passthrough-en).

Helaas geen verschil. zpool import geeft precies dezelfde melding onder openindiana

[Thralas]

Kun je nog eens kijken of

zdb -lllu /dev/sde1

nieuwe informatie geeft?

Als je zoekt op die error in de ZFS source dan lijkt dat al stuk te gaan op het uitlezen van het label. Vraag je je toch af of zdb dat niet moet kunnen laten zien.

[CurlyMo]

@ocaj Als het een USB schijf is dan kan je ook gewoon een de openindiana live cd booten op een laptop o.i.d? Ik zou het e.e.a. toch even uitsluiten door volledig openindiana te draaien i.p.v. in een VM.

[ocaj]

Thralas schreef op woensdag 9 februari 2022 @ 23:01:
Kun je nog eens kijken of

zdb -lllu /dev/sde1

nieuwe informatie geeft?

Als je zoekt op die error in de ZFS source dan lijkt dat al stuk te gaan op het uitlezen van het label. Vraag je je toch af of zdb dat niet moet kunnen laten zien.

Dank je, dat geeft al interessante extra informatie:

code:

root@pve:~# zdb -lllu /dev/sde1
------------------------------------
LABEL 0
------------------------------------
    version: 28
    name: 'backup'
    state: 1
    txg: 376696
    pool_guid: 699077873695507153
    hostid: 8899160
    hostname: 'zfsnas'
    top_guid: 13389692541741061876
    guid: 13389692541741061876
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 13389692541741061876
        path: '/dev/dsk/c10t0d0s0'
        devid: 'id1,sd@n5000000000000001/a'
        phys_path: '/pci@0,0/pci103c,1609@12,2/storage@2/disk@0,0:a'
        whole_disk: 1
        metaslab_array: 30
        metaslab_shift: 35
        ashift: 14
        asize: 4000714063872
        is_log: 0
        DTL: 198
        create_txg: 4
    features_for_read:
    labels = 0 1 2 3 


ZFS Label NVList Config Stats:
  1088 bytes used, 113560 bytes free (using  0.9%)

   integers:   18    664 bytes (61.03%)
    strings:    6    300 bytes (27.57%)
   booleans:    0      0 bytes ( 0.00%)
    nvlists:    3    124 bytes (11.40%)


    Uberblock[0]
    magic = 0000000000bab10c
    version = 28
    txg = 376696
    guid_sum = 14088770415436569029
    timestamp = 1562707006 UTC = Tue Jul  9 23:16:46 2019
    mmp_magic = 0000000000000000
    checkpoint_txg = 0
        labels = 0 1 2 3 
    Uberblock[2]
    magic = 0000000000bab10c
    version = 28
    txg = 376665
    guid_sum = 14088770415436569029
    timestamp = 1562706880 UTC = Tue Jul  9 23:14:40 2019
    mmp_magic = 0000000000000000
    checkpoint_txg = 0
        labels = 0 1 2 3 
    Uberblock[4]
    magic = 0000000000bab10c
    version = 28
    txg = 376666
    guid_sum = 14088770415436569029
    timestamp = 1562706882 UTC = Tue Jul  9 23:14:42 2019
    mmp_magic = 0000000000000000
    checkpoint_txg = 0
        labels = 0 1 2 3 
    Uberblock[6]
    magic = 0000000000bab10c
    version = 28
    txg = 376667
    guid_sum = 14088770415436569029
    timestamp = 1562706884 UTC = Tue Jul  9 23:14:44 2019
    mmp_magic = 0000000000000000
    checkpoint_txg = 0
        labels = 0 1 2 3 
    Uberblock[8]
    magic = 0000000000bab10c
    version = 28
    txg = 376668
    guid_sum = 14088770415436569029
    timestamp = 1562706885 UTC = Tue Jul  9 23:14:45 2019
    mmp_magic = 0000000000000000
    checkpoint_txg = 0
        labels = 0 1 2 3 
    Uberblock[10]
    magic = 0000000000bab10c
    version = 28
    txg = 376693
    guid_sum = 14088770415436569029
    timestamp = 1562707004 UTC = Tue Jul  9 23:16:44 2019
    mmp_magic = 0000000000000000
    checkpoint_txg = 0
        labels = 0 1 2 3 
    Uberblock[12]
    magic = 0000000000bab10c
    version = 28
    txg = 376670
    guid_sum = 14088770415436569029
    timestamp = 1562706891 UTC = Tue Jul  9 23:14:51 2019
    mmp_magic = 0000000000000000
    checkpoint_txg = 0
        labels = 0 1 2 3 
    Uberblock[14]
    magic = 0000000000bab10c
    version = 28
    txg = 371599
    guid_sum = 14088770415436569029
    timestamp = 1498429194 UTC = Mon Jun 26 00:19:54 2017
    mmp_magic = 0000000000000000
    checkpoint_txg = 0
        labels = 0 1 2 3 
------------------------------------
LABEL 1
------------------------------------
    version: 28
    name: 'backup'
    state: 1
    txg: 376696
    pool_guid: 699077873695507153
    hostid: 8899160
    hostname: 'zfsnas'
    top_guid: 13389692541741061876
    guid: 13389692541741061876
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 13389692541741061876
        path: '/dev/dsk/c10t0d0s0'
        devid: 'id1,sd@n5000000000000001/a'
        phys_path: '/pci@0,0/pci103c,1609@12,2/storage@2/disk@0,0:a'
        whole_disk: 1
        metaslab_array: 30
        metaslab_shift: 35
        ashift: 14
        asize: 4000714063872
        is_log: 0
        DTL: 198
        create_txg: 4
    features_for_read:
    labels = 0 1 2 3 


ZFS Label NVList Config Stats:
  1088 bytes used, 113560 bytes free (using  0.9%)

   integers:   18    664 bytes (61.03%)
    strings:    6    300 bytes (27.57%)
   booleans:    0      0 bytes ( 0.00%)
    nvlists:    3    124 bytes (11.40%)


------------------------------------
LABEL 2
------------------------------------
    version: 28
    name: 'backup'
    state: 1
    txg: 376696
    pool_guid: 699077873695507153
    hostid: 8899160
    hostname: 'zfsnas'
    top_guid: 13389692541741061876
    guid: 13389692541741061876
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 13389692541741061876
        path: '/dev/dsk/c10t0d0s0'
        devid: 'id1,sd@n5000000000000001/a'
        phys_path: '/pci@0,0/pci103c,1609@12,2/storage@2/disk@0,0:a'
        whole_disk: 1
        metaslab_array: 30
        metaslab_shift: 35
        ashift: 14
        asize: 4000714063872
        is_log: 0
        DTL: 198
        create_txg: 4
    features_for_read:
    labels = 0 1 2 3 


ZFS Label NVList Config Stats:
  1088 bytes used, 113560 bytes free (using  0.9%)

   integers:   18    664 bytes (61.03%)
    strings:    6    300 bytes (27.57%)
   booleans:    0      0 bytes ( 0.00%)
    nvlists:    3    124 bytes (11.40%)


------------------------------------
LABEL 3
------------------------------------
    version: 28
    name: 'backup'
    state: 1
    txg: 376696
    pool_guid: 699077873695507153
    hostid: 8899160
    hostname: 'zfsnas'
    top_guid: 13389692541741061876
    guid: 13389692541741061876
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 13389692541741061876
        path: '/dev/dsk/c10t0d0s0'
        devid: 'id1,sd@n5000000000000001/a'
        phys_path: '/pci@0,0/pci103c,1609@12,2/storage@2/disk@0,0:a'
        whole_disk: 1
        metaslab_array: 30
        metaslab_shift: 35
        ashift: 14
        asize: 4000714063872
        is_log: 0
        DTL: 198
        create_txg: 4
    features_for_read:
    labels = 0 1 2 3 


ZFS Label NVList Config Stats:
  1088 bytes used, 113560 bytes free (using  0.9%)

   integers:   18    664 bytes (61.03%)
    strings:    6    300 bytes (27.57%)
   booleans:    0      0 bytes ( 0.00%)
    nvlists:    3    124 bytes (11.40%)

Alle 4 de labels worden prima gelezen (kan ook mooi zien aan het timestamp van de laatste transactie dat ik de schijf al 2,5 jaar niet meer gebruikt had...).
In alle 4 de labels staat de path-name die hij op de oude server had.

In ieder geval versterkt het mijn gevoel dat de schijf prima in orde is en dat ik nu alleen nog een zpool-commando moet vinden waarmee ik de schijf kan importeren.

[Thralas]

Nog even over je eerdere output:

code:

zdb: can't open 'backup': No such device or address

ZFS_DBGMSG(zdb) START:
spa.c:6084:spa_import(): spa_import: importing backup
spa_misc.c:418:spa_load_note(): spa_load(backup, config trusted): LOADING
spa_misc.c:403:spa_load_failed(): spa_load(backup, config untrusted): FAILED: no valid uberblock found
spa_misc.c:418:spa_load_note(): spa_load(backup, config untrusted): UNLOADING
ZFS_DBGMSG(zdb) END

Ik begrijp niet helemaal of die eerste regel een oorzaak of gevolg is (ik vermoed gevolg). In dat geval lijkt hoe toch te suggereren dat hij je uberblocks allemaal afkeurt.

En als je naar de uberblock list kijkt dan is er wel iets opvallends aan de hand. Op m'n eigen zfs pools heb ik 32 entries, die allemaal gebruikt worden, bij jou slaat hij er telkens een over (de txg loopt wel netjes met 1 op). Misschien gewoon een versieverschil...


EDIT: Volgens mij hangt het aantal uberblocks ook samen met de physical block size, dus dat zou het eea. kunnen verklaren.

Laat /proc/spl/kstat/zfs/dbgmsg nog iets zien over het zoeken naar uberblocks?

[ Voor 6% gewijzigd door Thralas op 10-02-2022 09:16 ]

[ocaj]

Daar staat inderdaad dat hij geen geldig ueberblock kan vinden:

code:

1644481863   spa.c:6138:spa_tryimport(): spa_tryimport: importing backup
1644481863   spa_misc.c:415:spa_load_note(): spa_load($import, config trusted): LOADING
1644481863   spa_misc.c:400:spa_load_failed(): spa_load($import, config untrusted): FAILED: no valid uberblock found
1644481863   spa_misc.c:415:spa_load_note(): spa_load($import, config untrusted): UNLOADING

De schijf is een oude zpool-versie en is nog versie 28. Destijds waren de feature-versies nog een beetje nieuw en voor maximale compatibiliteit/migreerbaarheid zat ik toen nog op de laatste pre-oracle (?) versie 28.

Kan het nog een dingetje zijn met verschil in 4k vs 16k-sectors?

Idee van @CurlyMo om openindiana via live-image op aparte hardware te testen ipv in een VM kost even iets meer tijd, omdat ik even geen hardware "over" heb, maar ga ik de komende dagen nog wel regelen.

[raymonvdm]

Ik heb vandaag een stukje hardware gevonden waar ik even een ZFS pool op wil maken. Ik heb de volgende disken tot mijn beschikking

fdisk -l | grep Disk | grep -v model | grep -v label | grep -v identifier | grep 1.82 | wc -l
42

En daarnaast nog

Disk /dev/sdu: 7.45 GiB, 8000000000 bytes, 15625000 sectors (Disk model: ZeusRAM)
Disk /dev/sdv: 7.45 GiB, 8000000000 bytes, 15625000 sectors (Disk model: ZeusRAM)
Disk /dev/sdw: 372.61 GiB, 400088457216 bytes, 781422768 sectors (S842E400M2)

Ik heb dus 42disken, twee write cache SSD`s? en een Read SSD? (mogelijk waren dit er twee en is een dood?)


-----------

Je begint met een 6-disk 2TB RAID-Z2 met goede bescherming, maar wilt later nog wat extra ruimte. Je kunt dan bijvoorbeeld 6 disks 2TB in RAID-Z2 plaatsen voor extra opslagruimte.

code:

 sudo zpool create -f -m /mnt/camera camera raidz2 /dev/sdj /dev/sde /dev/sdf /dev/sdk /dev/sdn /dev/sdi
 sudo zpool add -f camera raidz2 /dev/sdl /dev/sdc /dev/sdg /dev/sdh /dev/sdd /dev/sdr
 sudo zpool add -f camera raidz2 /dev/sdp /dev/sdx /dev/sdm /dev/sdo /dev/sdq /dev/sdaj
 sudo zpool add -f camera raidz2 /dev/sdt /dev/sdak /dev/sdac /dev/sdae /dev/sdab /dev/sdad
 sudo zpool add -f camera raidz2 /dev/sdaa /dev/sdy /dev/sds /dev/sdai /dev/sdz /dev/sdag
 sudo zpool add -f camera raidz2 /dev/sdaf /dev/sdah /dev/sdan /dev/sdam /dev/sdao /dev/sdar
 sudo zpool add -f camera raidz2 /dev/sdau /dev/sdat /dev/sdaq /dev/sdas /dev/sdal /dev/sdap

code:

zpool status
  pool: camera
 state: ONLINE
config:

    NAME        STATE     READ WRITE CKSUM
    camera      ONLINE       0     0     0
      raidz2-0  ONLINE       0     0     0
        sdj     ONLINE       0     0     0
        sde     ONLINE       0     0     0
        sdf     ONLINE       0     0     0
        sdk     ONLINE       0     0     0
        sdn     ONLINE       0     0     0
        sdi     ONLINE       0     0     0
      raidz2-1  ONLINE       0     0     0
        sdl     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
        sdg     ONLINE       0     0     0
        sdh     ONLINE       0     0     0
        sdd     ONLINE       0     0     0
        sdr     ONLINE       0     0     0
      raidz2-2  ONLINE       0     0     0
        sdp     ONLINE       0     0     0
        sdx     ONLINE       0     0     0
        sdm     ONLINE       0     0     0
        sdo     ONLINE       0     0     0
        sdq     ONLINE       0     0     0
        sdaj    ONLINE       0     0     0
      raidz2-3  ONLINE       0     0     0
        sdt     ONLINE       0     0     0
        sdak    ONLINE       0     0     0
        sdac    ONLINE       0     0     0
        sdae    ONLINE       0     0     0
        sdab    ONLINE       0     0     0
        sdad    ONLINE       0     0     0
      raidz2-4  ONLINE       0     0     0
        sdaa    ONLINE       0     0     0
        sdy     ONLINE       0     0     0
        sds     ONLINE       0     0     0
        sdai    ONLINE       0     0     0
        sdz     ONLINE       0     0     0
        sdag    ONLINE       0     0     0
      raidz2-5  ONLINE       0     0     0
        sdaf    ONLINE       0     0     0
        sdah    ONLINE       0     0     0
        sdan    ONLINE       0     0     0
        sdam    ONLINE       0     0     0
        sdao    ONLINE       0     0     0
        sdar    ONLINE       0     0     0
      raidz2-6  ONLINE       0     0     0
        sdau    ONLINE       0     0     0
        sdat    ONLINE       0     0     0
        sdaq    ONLINE       0     0     0
        sdas    ONLINE       0     0     0
        sdal    ONLINE       0     0     0
        sdap    ONLINE       0     0     0

RAIDZ kan natuurlijk ook

code:

zpool status 
  pool: camera
 state: ONLINE
config:

    NAME        STATE     READ WRITE CKSUM
    camera      ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        sdj     ONLINE       0     0     0
        sde     ONLINE       0     0     0
        sdf     ONLINE       0     0     0
        sdk     ONLINE       0     0     0
        sdn     ONLINE       0     0     0
      raidz1-1  ONLINE       0     0     0
        sdl     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
        sdg     ONLINE       0     0     0
        sdh     ONLINE       0     0     0
        sdd     ONLINE       0     0     0
      raidz1-2  ONLINE       0     0     0
        sdp     ONLINE       0     0     0
        sdx     ONLINE       0     0     0
        sdm     ONLINE       0     0     0
        sdo     ONLINE       0     0     0
        sdq     ONLINE       0     0     0
      raidz1-3  ONLINE       0     0     0
        sdt     ONLINE       0     0     0
        sdak    ONLINE       0     0     0
        sdac    ONLINE       0     0     0
        sdae    ONLINE       0     0     0
        sdab    ONLINE       0     0     0
      raidz1-4  ONLINE       0     0     0
        sdaa    ONLINE       0     0     0
        sdy     ONLINE       0     0     0
        sds     ONLINE       0     0     0
        sdai    ONLINE       0     0     0
        sdz     ONLINE       0     0     0
      raidz1-5  ONLINE       0     0     0
        sdaf    ONLINE       0     0     0
        sdah    ONLINE       0     0     0
        sdan    ONLINE       0     0     0
        sdam    ONLINE       0     0     0
        sdao    ONLINE       0     0     0
      raidz1-6  ONLINE       0     0     0
        sdau    ONLINE       0     0     0
        sdat    ONLINE       0     0     0
        sdaq    ONLINE       0     0     0
        sdas    ONLINE       0     0     0
        sdal    ONLINE       0     0     0
      raidz1-7  ONLINE       0     0     0
        sdi     ONLINE       0     0     0
        sdr     ONLINE       0     0     0
        sdaj    ONLINE       0     0     0
        sdad    ONLINE       0     0     0
        sdag    ONLINE       0     0     0
    spares
      sdar      AVAIL   
      sdap      AVAIL

[ Voor 94% gewijzigd door raymonvdm op 10-02-2022 15:17 ]

[nero355]

ocaj schreef op donderdag 10 februari 2022 @ 09:39:
Daar staat inderdaad dat hij geen geldig ueberblock kan vinden:

code:

1644481863   spa.c:6138:spa_tryimport(): spa_tryimport: importing backup
1644481863   spa_misc.c:415:spa_load_note(): spa_load($import, config trusted): LOADING
1644481863   spa_misc.c:400:spa_load_failed(): spa_load($import, config untrusted): FAILED: no valid uberblock found
1644481863   spa_misc.c:415:spa_load_note(): spa_load($import, config untrusted): UNLOADING

De schijf is een oude zpool-versie en is nog versie 28. Destijds waren de feature-versies nog een beetje nieuw en voor maximale compatibiliteit/migreerbaarheid zat ik toen nog op de laatste pre-oracle (?) versie 28.

Kan het nog een dingetje zijn met verschil in 4k vs 16k-sectors?

Idee van @CurlyMo om openindiana via live-image op aparte hardware te testen ipv in een VM kost even iets meer tijd, omdat ik even geen hardware "over" heb, maar ga ik de komende dagen nog wel regelen.

Heb jij niet gewoon het welbekende probleem dat @RobertMe al vaker heeft omschreven :

Een USB Behuizing die een USB Controller heeft die niet de volledige HDD aan het systeem doorgeeft

Als ik het goed begrijp zat jouw HDD ooit in een Server op een SATA Controller/LSI HBA en nu dus in die USB Behuizing ??
Die kan je namelijk niet altijd volledig vertrouwen...

[RobertMe]

nero355 schreef op donderdag 10 februari 2022 @ 17:03:
[...]

Heb jij niet gewoon het welbekende probleem dat @RobertMe al vaker heeft omschreven :

Een USB Behuizing die een USB Controller heeft die niet de volledige HDD aan het systeem doorgeeft

Als ik het goed begrijp zat jouw HDD ooit in een Server op een SATA Controller/LSI HBA en nu dus in die USB Behuizing ??
Die kan je namelijk niet altijd volledig vertrouwen...

Ik neem aan / hoop dat dat toch alleen bij geshuckte drives voor komt. De controller van de WD Elements doet dit in ieder geval, maar of de controller van de WD MyBook dat ook doet weet ik niet. En ik mag toch hopen dat in ieder geval als je gewoon een behuizing / controller koopt dat die sowieso de volledige schijf doorgeeft en niet de laatste X aantal bytes er vanaf haalt voor interne huishouding.

[nero355]

RobertMe schreef op donderdag 10 februari 2022 @ 17:13:
Ik neem aan / hoop dat dat toch alleen bij geshuckte drives voor komt.

Ik vrees dus van niet, want ik ken ook USB Controllers die niet eens de S.M.A.R.T. gegevens 1:1 doorgeven, maar gewoon zelf iets willekeurigs erin zetten!

En ik mag toch hopen dat in ieder geval als je gewoon een behuizing / controller koopt dat die sowieso de volledige schijf doorgeeft en niet de laatste X aantal bytes er vanaf haalt voor interne huishouding.

Ik hoop het ook voor @ocaj maar wie weet heeft hij net dat eene verkeerde model getroffen...

[ocaj]

nero355 schreef op donderdag 10 februari 2022 @ 17:03:
[...]

Heb jij niet gewoon het welbekende probleem dat @RobertMe al vaker heeft omschreven :

Een USB Behuizing die een USB Controller heeft die niet de volledige HDD aan het systeem doorgeeft

Als ik het goed begrijp zat jouw HDD ooit in een Server op een SATA Controller/LSI HBA en nu dus in die USB Behuizing ??
Die kan je namelijk niet altijd volledig vertrouwen...

Nee, dit is gewoon een externe USB-schijf met een losse voeding etc. die op zowel mijn oude als mijn nieuwe server alleen via USB aangesloten is. Ik heb de behuizing nooit open gehad en hem dus ook nooit anders aangesloten.

[cyborgium]

Ik kreeg na mijn vorige vraag kritiek op mijn ashift en blocksize instellingen voor een NVMe striped array, dus ik zou graag willen weten wat voor mijn situatie de beste waardes zouden zijn.

Ik heb 2 samsung PM983 960GB NVMe schijven, welke ik wil stripen (jaja, niet het meest veilige, maak ik mij geen zorgen om). Ze gaan met name gebruikt worden voor VM disks (veeel random writes vanwege kubernetes). Daarnaast komt er ook een volume voor een nextcloud data, hierin kunnen dus bestanden in komen van verschillende groottes.

De VM disks hebben zeker voorrang, ik wil af van de enorm hoge IO_Wait op mijn huidige pool.

Wat zijn hiervoor de beste ashift en blocksize (en eventuele andere parameters) waardes?

[orillion]

cyborgium schreef op zondag 13 februari 2022 @ 13:02:
Ik kreeg na mijn vorige vraag kritiek op mijn ashift en blocksize instellingen voor een NVMe striped array, dus ik zou graag willen weten wat voor mijn situatie de beste waardes zouden zijn.

Ik heb 2 samsung PM983 960GB NVMe schijven, welke ik wil stripen (jaja, niet het meest veilige, maak ik mij geen zorgen om). Ze gaan met name gebruikt worden voor VM disks (veeel random writes vanwege kubernetes). Daarnaast komt er ook een volume voor een nextcloud data, hierin kunnen dus bestanden in komen van verschillende groottes.

De VM disks hebben zeker voorrang, ik wil af van de enorm hoge IO_Wait op mijn huidige pool.

Wat zijn hiervoor de beste ashift en blocksize (en eventuele andere parameters) waardes?

Deze post legt het we aardig uit: https://louwrentius.com/z...-on-4k-sector-drives.html

[cyborgium]

orillion schreef op zondag 13 februari 2022 @ 13:15:
[...]

Deze post legt het we aardig uit: https://louwrentius.com/z...-on-4k-sector-drives.html

Dat maakt het wel wat duidelijker, maar voor zover ik weet, is het wat betreft performance een stuk minder belangrijk bij HDDs, dan bij SSDs als je kijkt naar random reads/writes. Of heb ik dat mis?

[nero355]

cyborgium schreef op zondag 13 februari 2022 @ 13:02:
Ik heb 2 samsung PM983 960GB NVMe schijven, welke ik wil stripen (jaja, niet het meest veilige, maak ik mij geen zorgen om). Ze gaan met name gebruikt worden voor VM disks (veeel random writes vanwege kubernetes).

De VM disks hebben zeker voorrang, ik wil af van de enorm hoge IO_Wait op mijn huidige pool.

Of ik onderschat jouw setup of jij onderschat de snelheid van een enkele NVMe SSD

Hoe zag je oude setup eruit met die hoge IO_Wait op je Pool ?!

Besef dat :
- SSD's idioot snel zijn vergeleken met HDD's waarbij beiden via SATA zijn aangesloten.
- Dat PCIe NVMe SSD's nog eens vele malen sneller zijn :

AHCI has one command queue with 32 commands per queue, while NVMe has 65535 queues and 65536 commands per queue.

Al die HBA's op basis van SAS die ook SATA kunnen kletsen kunnen er veel meer aan, maar komen nog steeds niet eens in de buurt van een NVMe SSD !!!

Kortom : Als je toch al wat wilt "RAID-en" overweeg dan gewoon een Mirror/RAID1 configuratie

cyborgium schreef op zondag 13 februari 2022 @ 14:15:
Dat maakt het wel wat duidelijker, maar voor zover ik weet, is het wat betreft performance een stuk minder belangrijk bij HDDs, dan bij SSDs als je kijkt naar random reads/writes. Of heb ik dat mis?

SSD's zijn over het algemeen zeer gevoelig voor goede alignment en zijn voor zover ik weet allemaal voor 4K en dus ashift=12 geoptimaliseerd!

[cyborgium]

nero355 schreef op zondag 13 februari 2022 @ 15:12:
Hoe zag je oude setup eruit met die hoge IO_Wait op je Pool ?!

Ik had 2 intel 665p DRAMless QCL NVMe ssds in een striped pool, maar ik haalde sustained, nog niet boven de 200MB/s sequential writes.
Dit zorgde dus voor enorm hoge IO_Waits en daardoor hoge CPU usage.

nero355 schreef op zondag 13 februari 2022 @ 15:12:

SSD's zijn over het algemeen zeer gevoelig voor goede alignment en zijn voor zover ik weet allemaal voor 4K en dus ashift=12 geoptimaliseerd!

Ik had met die intel ssds, een ashift van 13 en een recordsize van 16K. In dat geval zal ik denk ik gaan voor een ahisft van 12 en nog steeds een recordsize van 16K

[Thralas]

Zoals al eerder beargumenteerd: je hoeft de ashift niet zelf te zetten, zfs kan namelijk de juiste waarde zelf wel bepalen (dat zal inderdaad 12 zijn).

De enige reden dat je 'm kunt aanpassen is een relikwie van schijven die logen over hun fysieke block sizes, maar die tijd ligt alweer even achter ons.

[orillion]

cyborgium schreef op zondag 13 februari 2022 @ 14:15:
[...]


Dat maakt het wel wat duidelijker, maar voor zover ik weet, is het wat betreft performance een stuk minder belangrijk bij HDDs, dan bij SSDs als je kijkt naar random reads/writes. Of heb ik dat mis?

Toch wil je voorkomen dat je SSD 8 fysieke blokken gaat schrijven als er maar 1 is veranderd of andersom.

[nero355]

cyborgium schreef op zondag 13 februari 2022 @ 15:53:
Ik had met die intel ssds, een ashift van 13 en een recordsize van 16K. In dat geval zal ik denk ik gaan voor een ahisft van 12 en nog steeds een recordsize van 16K

Wacht effe...

Record size als in de welbekende oude Stripe size bij RAID Controllers

Dan is 16K wel erg klein, tenzij je met vreselijk veel kleine files werkt ?!

Vroeger was het ongeveer zoiets :
- 64K als je meer kleine files dan grote files hebt.
- 128K als een soort "balanced" optie.
- 256K als je vooral met grote files werkt.

32K of 16K werden toen als zeer specialistische opties gezien voor zeer specifieke taken...

[cyborgium]

nero355 schreef op zondag 13 februari 2022 @ 23:48:
[...]

Dan is 16K wel erg klein, tenzij je met vreselijk veel kleine files werkt ?!

Ik heb het toen overgenomen van deze bron. Deze pagina werd ooit gebruikt in een youtube video van Lawrence Systems en ik ging er toen dus vanuit dat het een betrouwbare bron was.

Misschien toch maar eens de tijd nemen om wat tests te doen met verschillende blocksizes, etc.

[ocaj]

@cyborgium Maar in die link staat toch dat je na moet denken over je recordsize (er wordt zowel recordsize=16K als recordsize=1MB geadviseerd, of ben je na het lezen van de eerste keer recordsize gestopt met lezen ?)

Default ZFS recordsize is 128K, dat is meestal een prima optimum. Alleen als je een heel specifiek write-patroon hebt kun je daar op tunen (bijvoorbeeld een database of een andere applicatie die altijd in vaste blokgroottes schrijft).

[cyborgium]

@ocaj Ik heb zeker wel verder gelezen, maar er staat ook het volgende:

For most database binaries or VM images, 16K is going to be either an exact match or at least a much better one than the default recordsize, 128K.

Met name het gedeelte over VM image leek voor mij interessant, maar ik moet wel zeggen dat ik niet gekeken heb wat de precies de blocksize is van de VM disks die gemaakt worden door mijn hypervisor.

[ocaj]

Idealiter zoek je op wat de blokgrootte van je hypervisor is, maar je kunt natuurlijk ook experimenteel vergelijken met verschillende recordsizes.

Voordeel van ZFS is dat je vrij eenvoudig (zfs send/receive) je hele filesysteem kunt omzetten naar een
filesysteem met een andere recordsize en dan je tests herhalen en/of zoeken naar opvallende performance-verschillen.

[cyborgium]

ocaj schreef op maandag 14 februari 2022 @ 14:55:
Idealiter zoek je op wat de blokgrootte van je hypervisor is, maar je kunt natuurlijk ook experimenteel vergelijken met verschillende recordsizes.

Voordeel van ZFS is dat je vrij eenvoudig (zfs send/receive) je hele filesysteem kunt omzetten naar een
filesysteem met een andere recordsize en dan je tests herhalen en/of zoeken naar opvallende performance-verschillen.

Ha, dat zou makkelijk zijn inderdaad, waren het niet dat de boot schijf van mijn truenas server, op de ZFS pool in kwestie staat.....

Maar dank voor je tips! Ik ga inderdaad maar wat testen en kijken wat voor mijn situatie het beste is.

[ocaj]

recordsize is een paramter op zfs-niveau, niet op zpool-niveau.
Dat betekent dus ook dat je voor elk filesystem een andere recordsize kunt kiezen.

Zo heb ik mijn mysql-database op een recordsize=16k staan en mijn film-collectie op recordsize=1m (de rest op default 128k). Kan allemaal binnen dezelfde pool, dat is een feestje voor experimenteren dus

[cyborgium]

Nog even een sanity check, als ik dit zie staan:

code:

root@Raptor:~# zfs get recordsize spool
NAME   PROPERTY    VALUE    SOURCE
spool  recordsize  16K      local
root@Raptor:~# zfs get recordsize spool/vm-100-disk-0
NAME                 PROPERTY    VALUE    SOURCE
spool/vm-100-disk-0  recordsize  -        -

dan betekend dit dat vm-100-disk-0 dus ook een recordsize van 16K heeft, omdat ie dit overerft van de pool?

[CurlyMo]

cyborgium schreef op maandag 14 februari 2022 @ 15:42:
dan betekend dit dat vm-100-disk-0 dus ook een recordsize van 16K heeft, omdat ie dit overerft van de pool?

Ja

[ocaj]

Klopt. Maar met de meeste (alle?) zfs-parameters is het zo dat ze pas actief worden bij schrijfacties. Als je dus nu van je bestaande dataset je recordsize zou aanpassen, dan gaat hij niet de hele dataset converteren of zo. De 'oplossing' is om dan een nieuwe dataset aan te maken met juiste parameters en dan middels zfs send | zfs receive de set opnieuw te beschrijven met de aangepaste instellingen.
Uiteraard heb je dan je hele dataset dubbel staan, dus doe dat soort experimenten niet met een al te grote dataset, tenzij je ruimte zat hebt.

Alles wordt vanuit bovenliggende datasets ge-inherit.

[cyborgium]

Top! Dankjulliewel

[nero355]

cyborgium schreef op maandag 14 februari 2022 @ 10:11:
Ik heb het toen overgenomen van deze bron. Deze pagina werd ooit gebruikt in een youtube video van Lawrence Systems en ik ging er toen dus vanuit dat het een betrouwbare bron was.

Misschien toch maar eens de tijd nemen om wat tests te doen met verschillende blocksizes, etc.

Je omschrijft nu heel mooi waarom ik echt een hekel heb gekregen aan die hele "YouTube Tutorials Hype" van de laatste jaren :
De meeste mensen volgen die zooi 1:1 en hebben eigenlijk geen idee waar ze nou echt mee bezig zijn!

Opzich is er niks mis met die website, maar vooral als je met zoiets als ZFS aan de slag gaat moet je echt effe serieus ervoor gaan zitten en eerst gaan lezen wat nou wat is en/of doet en daarna tijdens het opzetten van het geheel nog eens heel goed stap voor stap alles doen en de documentatie ernaast houden!

Pas als er dan een moment komt dat je er constant mee bezig bent dan wordt het routine omdat je al een flinke sloot ervaring ermee hebt opgebouwd!

Om mezelf als voorbeeld te nemen :
- Ik lees dit topic al jarenlang...
- Heb een shitload aan ervaring met (File) Servers en Hardware RAID Controllers...
- Pas vorig jaar ging ik eindelijk een ZFS Pool opbouwen en toen heb ik nog steeds meer tijd besteed aan de ZFS documentatie lezen dan commando's tikken op mijn HTPC/DIY NAS

Waarom ?!

Omdat een goede voorbereiding nou eenmaal een hoop ellende scheelt!

ocaj schreef op maandag 14 februari 2022 @ 15:30:
recordsize is een paramter op zfs-niveau, niet op zpool-niveau.
Dat betekent dus ook dat je voor elk filesystem een andere recordsize kunt kiezen.

Zo heb ik mijn mysql-database op een recordsize=16k staan en mijn film-collectie op recordsize=1m (de rest op default 128k). Kan allemaal binnen dezelfde pool, dat is een feestje voor experimenteren dus

Zo zijn er een hoop dingen die je inderdaad heel mooi voor een bepaald doel kan aanpassen!

[Thralas]

ocaj schreef op maandag 14 februari 2022 @ 11:13:
Default ZFS recordsize is 128K, dat is meestal een prima optimum. Alleen als je een heel specifiek write-patroon hebt kun je daar op tunen (bijvoorbeeld een database of een andere applicatie die altijd in vaste blokgroottes schrijft).

Emphasis mine.

cyborgium schreef op maandag 14 februari 2022 @ 10:11:
Misschien toch maar eens de tijd nemen om wat tests te doen met verschillende blocksizes, etc.

Hoewel ik niemand ervan wil weerhouden te experimenteren, heb ik wel een beetje het gevoel dat je nu mogelijk werk aan het doen bent dat wer-ke-lijk niets uitmaakt in de (nog specifieker: jouw) praktijk.

Je komt van twee brakke QLC ssds die uit hun SLC cache lopen en hebt nu twee uitstekende enterprise disks. Dat is nogal een verschil. Voor iowaits zou ik niet bang zijn, een goedwerkende NVMe SSD heeft al snel meer IOPS dan jij realistisch gezien kunt vullen. Helemaal als je er twee stripet.

Een beetje alsof je een brakke Fiat Panda met de helft van z'n cylinders omruilt voor een Audi RS4 en je vervolgens als eerste afvraagt wat de beste bandenspanning is om de topsnelheid te halen. Deze haalt de 100 wel..

[Tha_Butcha]

ik aan het klooien met zfs (versie zfs-2.1.2-0york0~20.04) en encryptie en begreep dat je van af het begin je dataset moet encrypten en dat je de data die je er dan opzet geencrypt is.

Dus ik heb een nieuwe dataset aangemaakt en geencrypt. En nu wilde ik alles overgooien naar die nieuwe dataset met syncoid en dan is dit de output:

code:

[administrator@srv-nas-01:/pool0]$ sudo syncoid -r pool2/gurus pool0/gurus

CRITICAL ERROR: Target pool0/gurus exists but has no snapshots matching with pool2/gurus!
                Replication to target would require destroying existing
                target. Cowardly refusing to destroy your existing target.

          NOTE: Target pool0/gurus dataset is < 64MB used - did you mistakenly run
                `zfs create pool0/gurus` on the target? ZFS initial
                replication must be to a NON EXISTENT DATASET, which will
                then be CREATED BY the initial replication process.

Oftewel dat kan niet. Moet ik dan gewoon in de weer met rsync om de data over te zetten, naar die nieuwe encrypted dataset? Want ik kreeg de indruk van dit artikel dat wel zou moeten kunnen.

The first step of ZFS encryption is creating the encrypted dataset or zvol itself. You can't encrypt a pre-existing dataset or zvol—it needs to be created that way from the start. (You can, if necessary, full-replicate an existing dataset onto a new child dataset of an encrypted parent, thereby preserving snapshot history and other niceties. Just delete the source after replication has completed and you've verified that everything is good.)

[CurlyMo]

@Tha_Butcha Begin eens met de eigen ZFS tooling. Dan weet je tenminste zeker dat dit aan ZFS zelf ligt of dat het syncoid is. De foutmelding doet me vermoeden dat het niet aan ZFS ligt namelijk.

Overigens lijkt me de foutmelding wel helder. Heeft ook verder niks met encryptie te maken. Precies wat @nero355 eerder al aangaf. Leer eerst de basis principes van je tools goed kennen voordat je specifiekere eisen gaat stellen.

[ Voor 37% gewijzigd door CurlyMo op 15-02-2022 13:03 ]

[Tha_Butcha]

ik zit in een catch22

als ik dit doe:

code:

zfs send -v pool2/backup@autosnap_2022-02-15_01:00:15_daily | zfs recv pool0/backup

dan klaagt ie dat ik de dataset bestaat en -F moet gebruiken voor een overwrite

en als ik dat doe:

code:

zfs send -v pool2/backup@autosnap_2022-02-15_01:00:15_yearly | zfs recv -F pool0/backup

Dan geeft ie de error dat je een encrypted systeem niet kan overschrijven.

Ik heb ook nog geprobeerd met 'zfs recv -x encryption', maar ook dan klaagt ie dat de target al bestaat : /

[GioStyle]

Is het een incremental backup? Moet je dan niet ‘zfs send -I’ en dan twee snapshots doen?

[Borromini]

Volgens mij moet je diffen tussen het laatste snapshot op de doelserver en het laatste op de bronserver. Althans, da's toch hoe ik het doe. Voor zover ik weet vlooit ZFS zelf niet uit wat het laatste snapshot is op je doelserver.

[CurlyMo]

@Tha_Butcha Kan je eens de output tonen van de volgens commando's:

zfs list -t snapshot -r pool2/backup
zfs list -t snapshot -r pool0/backup

[HyperBart]

Tha_Butcha schreef op dinsdag 15 februari 2022 @ 12:15:
ik aan het klooien met zfs (versie zfs-2.1.2-0york0~20.04) en encryptie en begreep dat je van af het begin je dataset moet encrypten en dat je de data die je er dan opzet geencrypt is.

Dus ik heb een nieuwe dataset aangemaakt en geencrypt. En nu wilde ik alles overgooien naar die nieuwe dataset met syncoid en dan is dit de output:

code:

[administrator@srv-nas-01:/pool0]$ sudo syncoid -r pool2/gurus pool0/gurus

CRITICAL ERROR: Target pool0/gurus exists but has no snapshots matching with pool2/gurus!
                Replication to target would require destroying existing
                target. Cowardly refusing to destroy your existing target.

          NOTE: Target pool0/gurus dataset is < 64MB used - did you mistakenly run
                `zfs create pool0/gurus` on the target? ZFS initial
                replication must be to a NON EXISTENT DATASET, which will
                then be CREATED BY the initial replication process.

Oftewel dat kan niet. Moet ik dan gewoon in de weer met rsync om de data over te zetten, naar die nieuwe encrypted dataset? Want ik kreeg de indruk van dit artikel dat wel zou moeten kunnen.


[...]

Dit gaat niet, @FireDrunk probeerde laatst hetzelfde, ook met de raw option.

[CAPSLOCK2000]

nero355 schreef op maandag 14 februari 2022 @ 17:36:
Omdat een goede voorbereiding nou eenmaal een hoop ellende scheelt!

Het is een beetje OT maar op alle gebieden zien we dat het verschil tussen een beginner en iemand met ervaring vooral zit in de voorbereiding. De beginner begint gewoon ergens, de mens met ervaring maakt een plan. Ik roep altijd "Een professional is iemand die de handleiding wel heeft gelezen!".

ZFS is een systeem dat ook echt voorbereiding vereist. ZFS heeft veel mooie kanten maar flexibiliteit hoort daar niet bij. Een aantal keuzes kun je achteraf eigenlijk niet meer veranderen, die moet je in één keer goed krijgen. In mijn ogen is dat ook het grootste nadeel van ZFS. Andere systemen, (zoals BTRFS of LVM+ext4), hebben veel meer mogelijkheden om een bestaan array (online) helemaal te verbouwen. Af en toe is dat gewoon nodig want niemand is vrij van fouten en niemand kan de toekomst voorspellen.

ZFS wordt langzaam beter op dit gebied maar heeft nog steeds flinke beperkingen. Nou ja, je kan in principe extra schijven kopen en daarmee een nieuwe pool bouwen maar dat is in praktijk vaak niet haalbaar, zeker bij de middelgrote installaties waar flink wat schijven in zitten maar waar je niet de hardware hebt om even een paar lades schijven extra aan te sluiten.

[GioStyle]

CAPSLOCK2000 schreef op zondag 27 maart 2022 @ 12:58:

ZFS is een systeem dat ook echt voorbereiding vereist. ZFS heeft veel mooie kanten maar flexibiliteit hoort daar niet bij. Een aantal keuzes kun je achteraf eigenlijk niet meer veranderen, die moet je in één keer goed krijgen. In mijn ogen is dat ook het grootste nadeel van ZFS. Andere systemen, (zoals BTRFS of LVM+ext4), hebben veel meer mogelijkheden om een bestaan array (online) helemaal te verbouwen. Af en toe is dat gewoon nodig want niemand is vrij van fouten en niemand kan de toekomst voorspellen.

Dat is binnenkort wel een non-argument om niet voor ZFS te kiezen. Zie hier

[CAPSLOCK2000]

GioStyle schreef op zondag 27 maart 2022 @ 13:05:
Dat is binnenkort wel een non-argument om niet voor ZFS te kiezen. Zie hier

Mooie feature, die is heel welkom, maar het kan niet tippen aan wat (bv) LVM kan, zoals het ook weer verwijderen van schijven. Eerlijk gezegd ben ik minder bekend met BTRFS maar volgens mij kan dit dat ook. Ik weet je met ZFS ook wel schijven uit een pool kan halen, maar dat is toch anders dan je data te reshapen naar een andere raid(z)-level, of zo iets.

Nu is toevoegen van schijven in praktijk wel veruit het belangrijkste maar als je een fout hebt gemaakt kun je niet meer terug en dat is jammer.

[nero355]

CAPSLOCK2000 schreef op zondag 27 maart 2022 @ 12:58:
Het is een beetje OT maar op alle gebieden zien we dat het verschil tussen een beginner en iemand met ervaring vooral zit in de voorbereiding. De beginner begint gewoon ergens, de mens met ervaring maakt een plan. Ik roep altijd "Een professional is iemand die de handleiding wel heeft gelezen!".

Het probleem is eerder dat ik altijd vanuit het oude GoT denk zeg maar

De huidige generatie doet maar wat en gaat achteraf pas vragen stellen omdat er iets fout is gegaan en dan ook nog eens zonder zelf te zoeken naar de antwoorden, terwijl de oude generatie veel meer aan voorbereidingen deed VOORDAT ze ergens aan begonnen en ook nog eens RESEARCH deed op het moment dat er iets stuk ging!

* nero355 wordt oud...

[CAPSLOCK2000]

nero355 schreef op zondag 27 maart 2022 @ 15:10:
Het probleem is eerder dat ik altijd vanuit het oude GoT denk zeg maar

De huidige generatie doet maar wat en gaat achteraf pas vragen stellen omdat er iets fout is gegaan en dan ook nog eens zonder zelf te zoeken naar de antwoorden, terwijl de oude generatie veel meer aan voorbereidingen deed VOORDAT ze ergens aan begonnen en ook nog eens RESEARCH deed op het moment dat er iets stuk ging!

* nero355 wordt oud...

Hehehe, kom er bij, er is plek zat achter mijn geraniums. Neem je wel je eigen kustgebit mee?

Vroeger deden ze dat ook hoor, alleen zijn de grootste prutsers door de jaren heen afgevallen en iets anders gaan doen waar ze beter in zijn. Wij hebben nu alleen de goeden over van die generatie (doet er niet toe welke generatie precies). Ons falende geheugen heeft de ruwe kantjes van toen er afgepoetst.

Wat wel een rol speelt is veranderende kosten. Tegenwoordig start je in 5 minuten een verse VM op en als je blundert kost het niks. Als je weet dat een fout betekent dat de condensators je om de oren vliegen is het de moeite waard om wat meer tijd in voorbereiding te steken. Ook is er wel een zekere voorselectie omdat tegenwoordig de hele maatschappij met computers en software werkt en niet alleen beta-nerds.
Verder is een natuurlijke groep nu eenmaal altijd als een pyramide opgebouwd met een beperkt aantal experts aan de top en een enorm aantal prutsers aan de basis. Als de pyramide groter wordt dan groeit de basis veel sneller dan de top.

Ik denk maar zo, dankzij al die prutsers heb ik een goede baan.
Maar ik meende het met mijn "Een professional is iemand die de handleding wel heeft gelezen'. De jongste generaties zijn nog niet professioneel, die moeten het nog leren.


Prijs heeft er ook mee te maken. Een "server" met 4 schijven er in is tegenwoordig voor iedereen betaalbaar, je hebt niet eens meer een raidkaart nodig van 1000 gulden Poeh, het koste wat moeite maar ik ben back on topic.

Het soort features waar we het over hadden, expansie, kun je dus zien al 'gebrek aan voorbereiding' maar ook als 'de realiteit accepteren'. Maar omdat menselijke fouten nu eenmaal van alle tijden zijn heb ik weinig "respect" voor 'gebrek aan voorbereiding', flexibiliteit is beter dan een goede voorbereiding.

PS. Als het niet duidelijk is, dit is geen aanval op ZFS ofzo Ik ben zeer tevreden gebruiker. Maar als professional moet je objectief naar verbetering blijven streven, juist bij je lievelingen.

[ Voor 11% gewijzigd door CAPSLOCK2000 op 27-03-2022 15:40 ]

[Raven]

GioStyle schreef op zondag 27 maart 2022 @ 13:05:
[...]


Dat is binnenkort wel een non-argument om niet voor ZFS te kiezen. Zie hier

Zie het niet zo gauw staan, maar wordt het dan bijv. ook mogelijk om van een 4-disk Z1 naar 6-disk Z2 te gaan? Dus niet alleen meer hdd's, maar ook van Z1 naar Z2?

[GioStyle]

Raven schreef op maandag 28 maart 2022 @ 13:52:
[...]

Zie het niet zo gauw staan, maar wordt het dan bijv. ook mogelijk om van een 4-disk Z1 naar 6-disk Z2 te gaan? Dus niet alleen meer hdd's, maar ook van Z1 naar Z2?

Uit een andere bron:

With the new code, you'll be able to attach new disks to an existing RAIDz vdev as well. Doing so expands the vdev in width but does not change the vdev type, so you can turn a six-disk RAIDz2 vdev into a seven-disk RAIDz2 vdev, but you can't turn it into a seven-disk RAIDz3.

Dus ik verwacht het niet. Overigens ben ik ook nog helemaal niet overtuigd van deze nieuwe feature. Ik zie dat de bestaande data niet wordt herschreven, maar slechts verdeeld over een nieuw aantal schijven.



Ik vind bovenstaand plaatje niet echt een nette manier om 'live expansion' toe te passen. Ik zou dan toch eerder een pool slopen en opnieuw opbouwen, maar daar moet je wel natuurlijk de nodige extra opslag in huis voor hebben om tijdelijk kwijt te kunnen.

[orvintax]

GioStyle schreef op maandag 28 maart 2022 @ 14:18:
[...]


Uit een andere bron:


[...]


Dus ik verwacht het niet. Overigens ben ik ook nog helemaal niet overtuigd van deze nieuwe feature. Ik zie dat de bestaande data niet wordt herschreven, maar slechts verdeeld over een nieuw aantal schijven.

[Afbeelding]

Ik vind bovenstaand plaatje niet echt een nette manier om 'live expansion' toe te passen. Ik zou dan toch eerder een pool slopen en opnieuw opbouwen, maar daar moet je wel natuurlijk de nodige extra opslag in huis voor hebben om tijdelijk kwijt te kunnen.

Ik vind het er best logisch uit zien, waarom is dit niet netjes? (Ben een leek in dit soort zaken)

[GioStyle]

orvintax schreef op maandag 28 maart 2022 @ 20:55:
[...]

Ik vind het er best logisch uit zien, waarom is dit niet netjes? (Ben een leek in dit soort zaken)

Ik ben ook een leek, dus als iemand me kan verbeteren of aanvullen graag!

Aan de linkerkant zie je een pool raidz1 met vier schijven. De data is netjes verdeeld over de schijven met parity; 3 blocks aan data plus 1 parity block. Aan de rechterkant wordt de pool uitgebreid met een schijf. De bestaande data blijft verdeeld over vier schijven en niet over vijf.

Stel dat je besluit om de pool nog verder uit te breiden, laten we zeggen tien schijven. Vervolgens lees je je bestaande data af van vier schijven en niet van tien. Dat scheelt nogal wat qua performance. Dan kan je naar mijn mening beter nog steeds een nieuwe pool opzetten. Je zal ongetwijfeld ook je data door middel van zfs send & recieve kunnen 'verversen', zodat alle blocks wel verdeeld worden over de tien schijven, maar in mijn ogen zou dit juist een onderdeel moeten zijn van de expansion feature.

Althans, dit is hoe ik denk dat het gaat werken aan de hand van bovenstaande bronnen.

[ph0t0nix]

Jim Salter heeft er vorig jaar bij Ars Technica een verhaal aan gewijd: https://arstechnica.com/g...-lands-in-openzfs-master/

Over de "breedte" van oude en nieuwe data:

So while the user will see the extra space made available by the new disks, the storage efficiency of the expanded data will not have improved due to the new disks. In the example above, we went from a six-disk RAIDz2 with a nominal storage efficiency of 67 percent (four of every six sectors are data) to a ten-disk RAIDz2. Data newly written to the ten-disk RAIDz2 has a nominal storage efficiency of 80 percent—eight of every ten sectors are data—but the old expanded data is still written in six-wide stripes, so it still has the old 67 percent storage efficiency.

In het artikel gaat hij ook in op eventuele performance impact en waarom niet alle blokken opnieuw herschreven worden:

It might seem odd that the initial expansion process doesn't rewrite all existing blocks to the new width while it's running—after all, it's reading and re-writing the data anyway, right? We asked Ahrens why the original width was left as-is, and the answer boils down to "it's easier and safer that way."

[nero355]

CAPSLOCK2000 schreef op zondag 27 maart 2022 @ 15:35:
Hehehe, kom er bij, er is plek zat achter mijn geraniums. Neem je wel je eigen kustgebit mee?

Daar is toch dit topic voor : GoT bejaardensoos - hier melden deel 2

Prijs heeft er ook mee te maken. Een "server" met 4 schijven er in is tegenwoordig voor iedereen betaalbaar, je hebt niet eens meer een raidkaart nodig van 1000 gulden Poeh, het koste wat moeite maar ik ben back on topic.

Het soort features waar we het over hadden, expansie, kun je dus zien al 'gebrek aan voorbereiding' maar ook als 'de realiteit accepteren'. Maar omdat menselijke fouten nu eenmaal van alle tijden zijn heb ik weinig "respect" voor 'gebrek aan voorbereiding', flexibiliteit is beter dan een goede voorbereiding.

Nou je het zegt...

Ik kan me nog heel goed herinneren dat iemand een topic had gestart in de trant van :
- Peperdure Areca Controller met 12 of 24 poorten.
- Bijbehorende sloot Raptor HDD's om alle poorten te benutten.
- Om vervolgens pas na de aanschaf op GoT te vragen hoe alles aangesloten moest worden!

PS. Als het niet duidelijk is, dit is geen aanval op ZFS ofzo Ik ben zeer tevreden gebruiker.
Maar als professional moet je objectief naar verbetering blijven streven, juist bij je lievelingen.

Ik noem dat altijd "We complain because we care!"

[CAPSLOCK2000]

nero355 schreef op dinsdag 29 maart 2022 @ 14:59:
Daar is toch dit topic voor : GoT bejaardensoos - hier melden deel 2

Je geheugen is het eerste dat je in de steek laat

GioStyle schreef op maandag 28 maart 2022 @ 22:39:
Stel dat je besluit om de pool nog verder uit te breiden, laten we zeggen tien schijven. Vervolgens lees je je bestaande data af van vier schijven en niet van tien. Dat scheelt nogal wat qua performance. Dan kan je naar mijn mening beter nog steeds een nieuwe pool opzetten. Je zal ongetwijfeld ook je data door middel van zfs send & recieve kunnen 'verversen', zodat alle blocks wel verdeeld worden over de tien schijven, maar in mijn ogen zou dit juist een onderdeel moeten zijn van de expansion feature.

Pas op met intuitie of bestaande kennis. Dit onderwerp is behoorlijk complex en ZFS werkt nogal anders dan traditionele RAID en dan hebben we ook nog solid state disks die een hoop aannames uit het verleden ongeldig hebben gemaakt.

Je data over meer schijven verdelen is in het algemeen inderdaad sneller maar ook riskanter. Hoe meer schijven hoe groter de kans op een (dubbele) fout, tenzij je ook meer parity gaat toevoegen. UIteraard ligt het aan de context wat de "beste" keuze is, maar de betrouwbaarheid niet verlagen als de beheerder daar niet expliciet om vraagt lijkt mij de juiste keuze.

Op draaischijven heb je ook nog te maken met latency, waar je idealiter de data zo verdeelt dat het volgende blokje klaar staat op het moment dat de disk onder de leesarm doordraait. Met SSDs heb je dat probleem niet. Bij SSDs heb je heel andere overwegingen, bijvoorbeeld of je controller wel genoeg capaciteit heeft om twee disks tegelijk te vullen of dat die dan toch maar staan te wachten, of dat je blocks moet rewriten of niet.

Ik kan de details niet geven maar wel dat het complex is en dat het gegeven conversieschema in mijn ogen niet problematisch is.

[ Voor 11% gewijzigd door CAPSLOCK2000 op 29-03-2022 15:59 ]

[GioStyle]

CAPSLOCK2000 schreef op dinsdag 29 maart 2022 @ 15:51:

Ik kan de details niet geven maar wel dat het complex is en dat het gegeven conversieschema in mijn ogen niet problematisch is.

Problematisch is het niet, maar eerder suboptimaal.

Uit jouw genoemde bron:

If it really makes your teeth itch knowing you have four-wide stripes on a freshly five-wide vdev, you can just read and re-write your data yourself after expansion completes. The simplest way to do this is to use zfs snapshot, zfs send, and zfs receive to replicate entire datasets and zvols. If you're not worried about ZFS properties, a simple mv operation will do the trick.

Precies wat ik eerder al beschreef. Ik ben wel benieuwd naar deze feature, ik wacht rustig af.

[FireDrunk]

GioStyle schreef op maandag 28 maart 2022 @ 22:39:
[...]


Ik ben ook een leek, dus als iemand me kan verbeteren of aanvullen graag!

Aan de linkerkant zie je een pool raidz1 met vier schijven. De data is netjes verdeeld over de schijven met parity; 3 blocks aan data plus 1 parity block. Aan de rechterkant wordt de pool uitgebreid met een schijf. De bestaande data blijft verdeeld over vier schijven en niet over vijf.

Stel dat je besluit om de pool nog verder uit te breiden, laten we zeggen tien schijven. Vervolgens lees je je bestaande data af van vier schijven en niet van tien. Dat scheelt nogal wat qua performance. Dan kan je naar mijn mening beter nog steeds een nieuwe pool opzetten. Je zal ongetwijfeld ook je data door middel van zfs send & recieve kunnen 'verversen', zodat alle blocks wel verdeeld worden over de tien schijven, maar in mijn ogen zou dit juist een onderdeel moeten zijn van de expansion feature.

Althans, dit is hoe ik denk dat het gaat werken aan de hand van bovenstaande bronnen.

Niets weerhoud je er van om dat zelf te maken. Je kan best een scriptje maken dat een resize / reflow doet, en daarna een ZFS Send + Receive heen, en weer terug (daarna zijn de stripes herschreven).

Het lastige is ZFS absolute consistentie blijft garanderen, en dat kan met de implementaties die je gewend bent niet zomaar.
Ik heb echt al heel wat RAID expansions gedaan, en je krijgt altijd de waarschuwing: Let op dit is gevaarlijk, maak een backup.

ZFS kiest er dus bewust voor dat het een veilige operatie is, waar dan wel een klein nadeel in zit.
Op zich is een ZFS Send & Receive best te doen, en ook weer niet de allermoeilijkste operatie.

Zo heb ik dat van de week nog gedaan om een aantal van mijn Datasets te encrypten, ook zoiets wat niet in-place kan.

[ Voor 4% gewijzigd door FireDrunk op 30-03-2022 10:46 ]

[nero355]

FireDrunk schreef op woensdag 30 maart 2022 @ 10:46:
Ik heb echt al heel wat RAID expansions gedaan, en je krijgt altijd de waarschuwing: Let op dit is gevaarlijk, maak een backup.

Hardware RAID lockups die je amper tot niet kan troubleshooten vind ik veel erger!

Of expansions die vastlopen nadat de boel flink wat uren heeft staan pruttelen...
Soms op te lossen, maar soms ook niet!

[murdock01]

already solved

[ Voor 98% gewijzigd door murdock01 op 05-04-2022 03:04 . Reden: solved :) ]

[GioStyle]

Ik wil op mijn Debian server ZFS on root gaan gebruiken met Docker / KVM/QEMU en een aantal SMB shares. In principe wil ik alles op 1 2TB nvme ssd doen.

Ik zie dat standaard compressie LZ4 aanstaat wanneer je ZFS on root instelt. Is daar een bepaalde reden voor? In principe hoef ik geen compressie, ik wil het liefst zo weinig mogelijk CPU cycles hebben. Kan ik de compressie gewoon uitzetten?

[CurlyMo]

GioStyle schreef op woensdag 11 mei 2022 @ 21:52:
Ik zie dat standaard compressie LZ4 aanstaat wanneer je ZFS on root instelt. Is daar een bepaalde reden voor? In principe hoef ik geen compressie, ik wil het liefst zo weinig mogelijk CPU cycles hebben. Kan ik de compressie gewoon uitzetten?

Ja, maar ik denk dat je spijkers op laag water zoekt wat betreft de CPU belasting van lz4.

[GioStyle]

CurlyMo schreef op woensdag 11 mei 2022 @ 21:55:
[...]

Ja, maar ik denk dat je spijkers op laag water zoekt wat betreft de CPU belasting van lz4.

Met andere woorden zeg je dat ik de compressie lekker aan moet laten en niet al te druk over maken?

[CurlyMo]

GioStyle schreef op woensdag 11 mei 2022 @ 22:10:
[...]


Met andere woorden zeg je dat ik de compressie lekker aan moet laten en niet al te druk over maken?

Dat

[ZaPPZion]

GioStyle schreef op woensdag 11 mei 2022 @ 22:10:
[...]
Met andere woorden zeg je dat ik de compressie lekker aan moet laten en niet al te druk over maken?

Als je zoekt op lz4 compression speed, wordt er aangegeven dat het ongeveer 500 MB/s per core is op de enigszins nieuwe cpu's, Dus als je bijvoorbeeld 4500MB/s zou kunnen lezen, zou je ongeveer 9 cores nodig hebben, maar dan lees je dus eigenlijk nog meer, zeg 6000MB/s. Dus best wel nuttig, maar kost wel iets. Maar goed, als je het hebt over SMB shares, uitgaande van 10gbps (als je dat al hebt), zit je op 1250MB/s max, dus zegmaar 2 a 3 cpu cores. Al met al in principe niets om je zorgen over te maken, tenzij je echt ultra ultra performance nodig hebt. 500MB/s/core is echt snel zat

[joker1977]

ZaPPZion schreef op donderdag 12 mei 2022 @ 02:15:
[...]


Als je zoekt op lz4 compression speed, wordt er aangegeven dat het ongeveer 500 MB/s per core is op de enigszins nieuwe cpu's, Dus als je bijvoorbeeld 4500MB/s zou kunnen lezen, zou je ongeveer 9 cores nodig hebben, maar dan lees je dus eigenlijk nog meer, zeg 6000MB/s. Dus best wel nuttig, maar kost wel iets. Maar goed, als je het hebt over SMB shares, uitgaande van 10gbps (als je dat al hebt), zit je op 1250MB/s max, dus zegmaar 2 a 3 cpu cores. Al met al in principe niets om je zorgen over te maken, tenzij je echt ultra ultra performance nodig hebt. 500MB/s/core is echt snel zat

Als je ultra performance wilt, wil je juist compressie: Juist bij dat soort disk-intensieve I/O is de bottleneck vast niet de CPU, maar de drives. Als je dan een deel van de bottleneck kunt verplaatsen is dat netto-winst.

De cpu-tijd die je inlevert door compressie win je normaliter ruim terug door de tijd die je bespaart te 'wachten' op de disks.

[Brahiewahiewa]

joker1977 schreef op donderdag 12 mei 2022 @ 08:49:
[...]


Als je ultra performance wilt, wil je juist compressie: Juist bij dat soort disk-intensieve I/O is de bottleneck vast niet de CPU, maar de drives. Als je dan een deel van de bottleneck kunt verplaatsen is dat netto-winst.

De cpu-tijd die je inlevert door compressie win je normaliter ruim terug door de tijd die je bespaart te 'wachten' op de disks.

Dat niet alleen. Maar de bewerking die op de data nodig is om het over meerdere schijven te kunnen verdelen is feitelijk al LZ4 compressie. Je moet al chunks uitrekenen en checksums. Als je dat toch al uitgerekend hebt, kun je het maar beter gebruiken

[nero355]

ZaPPZion schreef op donderdag 12 mei 2022 @ 02:15:
Als je zoekt op lz4 compression speed, wordt er aangegeven dat het ongeveer 500 MB/s per core is op de enigszins nieuwe cpu's, Dus als je bijvoorbeeld 4500MB/s zou kunnen lezen, zou je ongeveer 9 cores nodig hebben, maar dan lees je dus eigenlijk nog meer, zeg 6000MB/s. Dus best wel nuttig, maar kost wel iets. Maar goed, als je het hebt over SMB shares, uitgaande van 10gbps (als je dat al hebt), zit je op 1250MB/s max, dus zegmaar 2 a 3 cpu cores. Al met al in principe niets om je zorgen over te maken, tenzij je echt ultra ultra performance nodig hebt. 500MB/s/core is echt snel zat

Zelfs mijn vreselijk cheapo en verouderde Intel G1820 heeft maar 60% CPU belasting op het moment dat ik een 1 Gbps LAN verbinding volprop met Samba File Transfers vanaf een ZFS Pool die LZ4 Compression aan heeft staan en dan komt al die belasting eigenlijk alleen door het Samba proces als ik TOP ernaast draai!

[joker1977]

ZaPPZion schreef op donderdag 12 mei 2022 @ 02:15:
[...]


Als je zoekt op lz4 compression speed, wordt er aangegeven dat het ongeveer 500 MB/s per core is op de enigszins nieuwe cpu's, Dus als je bijvoorbeeld 4500MB/s zou kunnen lezen, zou je ongeveer 9 cores nodig hebben, maar dan lees je dus eigenlijk nog meer, zeg 6000MB/s. Dus best wel nuttig, maar kost wel iets. Maar goed, als je het hebt over SMB shares, uitgaande van 10gbps (als je dat al hebt), zit je op 1250MB/s max, dus zegmaar 2 a 3 cpu cores. Al met al in principe niets om je zorgen over te maken, tenzij je echt ultra ultra performance nodig hebt. 500MB/s/core is echt snel zat

Nog een opmerking: Dit is de compression speed, ofwel als je aan het schrijven bent. Dat is 500 MB/core.

Het lezen is véél sneller, 'multiple GB / core'. Dus voor het lezen van de data heb je meestal vrijwel geen CPU nodig.

[joker1977]

Brahiewahiewa schreef op donderdag 12 mei 2022 @ 10:53:
[...]

Dat niet alleen. Maar de bewerking die op de data nodig is om het over meerdere schijven te kunnen verdelen is feitelijk al LZ4 compressie. Je moet al chunks uitrekenen en checksums. Als je dat toch al uitgerekend hebt, kun je het maar beter gebruiken

Weet je dat zeker? Kun je daar een bron voor geven? Want ik kan me niet voorstellen dat de checksumming al "feitelijk LZ4 compressie" is.

[FireDrunk]

Volgens mij klopt dat inderdaad niet. Bovendien wordt compressie op filesystem niveau geregeld, en je RAID 'level' op pool niveau. Verschillende lagen van ZFS dus.

[GioStyle]

Dan nog een ander gedachtenspinsel:

Ik wil dus alles op 1 2TB nvme ssd doen, dus Docker (stuk of 20+ containers), KVM (2 virtual machines) en een aantal SMB shares. Het enige wat ik automatisch wil laten snapshotten zijn de SMB shares, de rest is niet zo belangrijk en is te herstellen zonder snapshots.

Bij het maken van de rootpool wil ik de volgende regel toevoegen:

code:

-O com.sun:auto-snapshot=false

Hierdoor worden er geen automatische snapshots gemaakt op de rootpool. Vervolgens ga ik bij de filesystems van de SMB shares deze optie wel aanzetten. Dan ben ik er toch? Ja, ik moet nog een aantal settings toevoegen zoals maandelijks, wekelijks, dagelijks snapshots etc...

code:

zpool create -f \
    -o ashift=12 \
    -O com.sun:auto-snapshot=false \
    -O acltype=posixacl -O canmount=off -O compression=lz4 \
    -O dnodesize=auto -O normalization=formD -O relatime=on \
    -O xattr=sa -O mountpoint=/ -R /mnt \
    rpool ${DISK}-part3

[RudolfR]

Hoe erg is het nu werkelijk gesteld met SMR drives i.c.m. ZFS?

Ik heb jaren geleden een raid-z1 (inmiddels z2) ingericht met 4 stuks 2,5" disks met 1TB opslag.
Inmiddels heb ik 2 disks vervangen door 2TB varianten, maar nu ik er daar een van moet vervangen lukt het replacen met een nieuwe 2TB disk eigenlijk niet goed. (FAULTED / too many errors)

Ben ik beter af als ik terugga naar 1TB disks? Want 2,5"/CMR/2TB is volgens mij geen optie.
Vervanging door 3,5" gaat wellicht problemen opleveren met de behuizing en de picopsu.

Tips?

[Daantje20]

Ik heb 2x 2TB (2,5”) SMR in mijn mini servertje, draai daar TrueNAS scale op met ZFS, het werkt, maar snel is anders.

Wel draait er een trim op eens in de zoveel tijd om het behapbaar te houden.

[nero355]

Daantje20 schreef op zaterdag 25 juni 2022 @ 18:30:
Wel draait er een trim op eens in de zoveel tijd om het behapbaar te houden.

Zijn er dan eindelijk HDD's op de markt die iets met TRIM doen

[joker1977]

nero355 schreef op zondag 26 juni 2022 @ 00:39:
[...]

Zijn er dan eindelijk HDD's op de markt die iets met TRIM doen

Jazeker, sommige SRM schijven ondersteunen het.

[Daantje20]

nero355 schreef op zondag 26 juni 2022 @ 00:39:
[...]

Zijn er dan eindelijk HDD's op de markt die iets met TRIM doen

Het zijn twee WD schijven, ze ondersteunen trim en daar ben ik best blij mee want wat kunnen ze af en toe traag zijn.

[orvintax]

Daantje20 schreef op zaterdag 25 juni 2022 @ 18:30:
Ik heb 2x 2TB (2,5”) SMR in mijn mini servertje, draai daar TrueNAS scale op met ZFS, het werkt, maar snel is anders.

Wel draait er een trim op eens in de zoveel tijd om het behapbaar te houden.

Idem hier. Heb een zraid2 array van 4x 2TB en heb ooit een disk vervangen door zo een vervloekte WD Red (SMR) drive die nu heel de array tegenhoud qua performance. Maar het werkt wel.

[Brahiewahiewa]

orvintax schreef op zondag 26 juni 2022 @ 10:36:
[...]

Idem hier. Heb een zraid2 array van 4x 2TB en heb ooit een disk vervangen door zo een vervloekte WD Red (SMR) drive die nu heel de array tegenhoud qua performance. Maar het werkt wel.

Nou, het heeft in jouw geval min-of-meer gewerkt. Denk niet dat je kunt stellen dat het vangen van een CMR disk door een SMR altijd werkt, want er zijn gevallen waarin ZFS er niet uitkomt. Besides geef je zelf ook al aan dat je sindsdien niet meer tevreden bent over de performance

[RobertMe]

Brahiewahiewa schreef op zondag 26 juni 2022 @ 11:54:
[...]

Nou, het heeft in jouw geval min-of-meer gewerkt. Denk niet dat je kunt stellen dat het vangen van een CMR disk door een SMR altijd werkt, want er zijn gevallen waarin ZFS er niet uitkomt. Besides geef je zelf ook al aan dat je sindsdien niet meer tevreden bent over de performance

Het zal natuurlijk ook sterk afhankelijk zijn van de toepassing. Ik heb op een gegeven moment een CMR disk vervangen met een SMR model, maar de performance van de mirror was toen om te huilen. Maar ik had ook software, zoals een database, die daar naartoe deed schrijven, oftewel: random io. Intussen de SMR schrijf aan een OrangePi (3) hangen die puur voor backup doeleinden gebruikt wordt. En met een periodieke send & receive geeft dat geen problemen. En toen ik van single disk naar mirror ben gegaan ging dat ook goed (v.w.b. resilver).

Voor een toepassing met voornamelijk lezen of alleen sequentieel schrijven zal SMR waarschijnlijk wel kunnen. Maar voor meer random io weer niet. Dus bv downloads op SMR bewaren kan prima, maar ook van op SMR torrenten weer niet omdat dat natuurlijk ook random writes geeft. Download je naar een SSD en dan eenmalig kopiëren naar SMR zal het allemaal wel los lopen.

[Brahiewahiewa]

RobertMe schreef op zondag 26 juni 2022 @ 14:56:
[...]
Voor een toepassing met voornamelijk lezen of alleen sequentieel schrijven zal SMR waarschijnlijk wel kunnen. Maar voor meer random io weer niet. Dus bv downloads op SMR bewaren kan prima, maar ook van op SMR torrenten weer niet omdat dat natuurlijk ook random writes geeft. Download je naar een SSD en dan eenmalig kopiëren naar SMR zal het allemaal wel los lopen.

Ja, een losse SMR disk zal wel werken, anders zouden ze niet verkocht worden, toch?

Maar zo lang de fabrikanten van SMR disks ruimhartig aangeven dat SMR disks niet geschikt zijn voor RAID cq ZFS, ben ik geneigd om SMR disks niet te gebruiken voor RAID toepassingen

[orvintax]

Brahiewahiewa schreef op zondag 26 juni 2022 @ 21:46:
[...]

Ja, een losse SMR disk zal wel werken, anders zouden ze niet verkocht worden, toch?

Maar zo lang de fabrikanten van SMR disks ruimhartig aangeven dat SMR disks niet geschikt zijn voor RAID cq ZFS, ben ik geneigd om SMR disks niet te gebruiken voor RAID toepassingen

Ik zou het ook niet aanraden. Maar ik en samen met vele andere waren gedupeerden van die WD RED controverse, zeg maar gerust schandaal.

[RobertMe]

Brahiewahiewa schreef op zondag 26 juni 2022 @ 21:46:
[...]

Ja, een losse SMR disk zal wel werken, anders zouden ze niet verkocht worden, toch?

Maar zo lang de fabrikanten van SMR disks ruimhartig aangeven dat SMR disks niet geschikt zijn voor RAID cq ZFS, ben ik geneigd om SMR disks niet te gebruiken voor RAID toepassingen

Los of RAID maakt denk ik niet heel veel uit? Of anders gezegd: een single SMR disk kun je ook op zijn knieën krijgen, met bv dus veel (random) writes waardoor het cache/CMR deel vol raakt.

En het nadeel voor gebruik met traditionele RAID is denk ik dat RAID controllers nogal picky zijn? Als een write te lang duurt dan wordt de disk als failed gemarkeerd? Gebeurt dit tijdens een rebuild ben je sowieso fucked. En een SMR drive heeft juist meer kans op trage writes dus een grotere kans dat een RAID controller hem op failed gooit.

ZFS heeft dit gedrag echter minder? Door de implementatie of mogelijk door de integratie van volume manager en filesystem, geen idee.

In ieder geval heeft ik meen @FireDrunk een hele tijd terug in dit topic zo ongeveer een live verslag gedaan van ik meen een RAIDZ1 rebuild met SMR drives. En dat was wel traag, maar ging gewoon goed.

[nero355]

RobertMe schreef op zondag 26 juni 2022 @ 22:50:
En het nadeel voor gebruik met traditionele RAID is denk ik dat RAID controllers nogal picky zijn?
Als een write te lang duurt dan wordt de disk als failed gemarkeerd?
Gebeurt dit tijdens een rebuild ben je sowieso fucked.

ZFS heeft dit gedrag echter minder?
Door de implementatie of mogelijk door de integratie van volume manager en filesystem, geen idee.

Dat is het TLER verhaal : Het grote ZFS topic

[FireDrunk]

Ik heb met veel plezier SMR gehad, en zou het in principe zo weer doen, mits niet met veel te grote schijven.
Inmiddels ben ik over op 6*14TB CMR WD Red's.

Mijn 2TB schijven zitten in een RAIDZ2 Array in een machientje bij @HyperBart als externe backup, en werken daar prima.

Je moet je gewoon erg instellen op de snelheid, en je moet er zo min mogelijk Random IO op doen.

[CurlyMo]

Als je het over de duivel hebt. Sinds een paar dagen gaat het verzenden van snapshots erg traag. Ik heb twee verschillende offsite locaties waarnaar ik stuur. Op beide locaties is de internetsnelheid prima. Minimaal 50mbit/s internet abo. Op beide locatie zie ik geen problemen met de ontvangende schijven. Aan mijn kant speelt dit zowel voor mijn SSD pool als voor mijn SMR pool die verder ook beide prima zijn. Buiten de traagheid van de zfs send / recv merk ik geen traagheid bij het lokale gebruik van mijn pools.

Offsite locatie 1:

Testing download speed................................................................................
Download: 56.26 Mbit/s
Testing upload speed......................................................................................................
Upload: 24.91 Mbit/s

Offsite locatie 2:

Testing download speed...............................................................................
.Download: 93.37 Mbit/s
Testing upload speed......................................................................................................
Upload: 0.58 Mbit/s

Dit ben ik zelf:

Testing download speed...............................................................................
.Download: 47.79 Mbit/s
Testing upload speed......................................................................................................
Upload: 5.69 Mbit/s

Iemand een idee waar die traagheid opeens vandaan zou kunnen komen en waar ik kan beginnen met zoeken?

 164MiB 0:56:07 [49.8KiB/s] [                                                 <=>                                                                           ]

Een puur lokale test:

root@pve:/# zfs send data/programs@GMT-2022.06.27-00.00.01 | pv > /media/users/donaldduck/test.img
1.13GiB 0:00:06 [ 203MiB/s] [            <=>                                                

Daarin ook geen problemen. Data is mijn SSD pool. Media mijn SMR pool.

---

root@pve:/#zfs send data/programs@GMT-2022.06.27-00.00.01 | pv | ssh -q backup gzip > /dev/null
2.67MiB 0:00:12 [75.3KiB/s] [                      <=>                                                                                                      ]

[ Voor 71% gewijzigd door CurlyMo op 27-06-2022 16:05 ]

[nero355]

@CurlyMo
Ik zou denken aan :

- iPerf3 gebruiken om de verbindingen te testen i.p.v. Speedtest.net CLI Tool
- Ping/Traceroute tussen de verbindingen checken op het moment dat het zo langzaam gaat!
- Wat zijn eigenlijk de exacte specificaties van elke verbinding
- Welke HDD's en Controllers worden er gebruikt ?
- Smart Data van alle HDD's gecheckt ?
- Krijg je overal wel gewoon de 100 Mbps of 1 Gbps volgepompt als je op het lokale netwerk test ?
- Hoe vol zijn de pools ?
- Overal de gereserveerde lege ruimte optie omlaag gezet of misschien juist te laag gezet ?

Succes alvast!

[CurlyMo]

nero355 schreef op maandag 27 juni 2022 @ 17:09:
@CurlyMo
Ik zou denken aan :

- iPerf3 gebruiken om de verbindingen te testen i.p.v. Speedtest.net CLI Tool
- Ping/Traceroute tussen de verbindingen checken op het moment dat het zo langzaam gaat!
- Wat zijn eigenlijk de exacte specificaties van elke verbinding
- Welke HDD's en Controllers worden er gebruikt ?
- Smart Data van alle HDD's gecheckt ?
- Krijg je overal wel gewoon de 100 Mbps of 1 Gbps volgepompt als je op het lokale netwerk test ?
- Hoe vol zijn de pools ?
- Overal de gereserveerde lege ruimte optie omlaag gezet of misschien juist te laag gezet ?

Succes alvast!

- Kan je goed iperf over SSH draaien? Dat heb ik nog nooit gedaan.
- Ping en traceroute laten geen rare dingen zien.
- Wat bedoel je precies met specificaties van de verbinding?
- Lokaal gaat alles prima, dat zag je al in mijn lokale test.
- Externe pools hebben ruimte zat (125G en 950G).
- Smart data is prima

Aanvullend gaat het wel goed als ik iets vanaf mijn offsite pools naar hier toe kopieer:

Locatie 1 naar lokaal

IMG_0359.MOV                                  15%   36MB   3.5MB/s   00:53 ETA

Het gaat dus alleen mis als ik iets vanaf hier naar mijn offsite pools probeer te sturen.

---

Nog even een andere test. Het gaat specifiek mis bij mijn eigen upload snelheid. Lijkt aardig ZFS onafhankelijk te zijn

Offsite naar lokaal

root@pve:/# ssh offsite gzip -c /IMG_0359.MOV | pv | gzip -d > /dev/null
16.8MiB 0:00:05 [3.65MiB/s]

Lokaal naar offsite

gzip -c IMG_0359.MOV | pv | ssh offsite gzip -d > /dev/null
2.30MiB 0:00:09 [62.1KiB/s]

---

Even een OOKLA speedtest gedraaid en die geeft een prachtige upload snelheid van 0.89Mbps



En dat op mijn 100Mbit glasvezel lijntje...

Ik weet waar ik het moet zoeken.

---

Even de switch gereset. Dat lijkt er meer op:

[ Voor 27% gewijzigd door CurlyMo op 27-06-2022 18:54 ]

[nero355]

CurlyMo schreef op maandag 27 juni 2022 @ 17:33:
- Kan je goed iperf over SSH draaien? Dat heb ik nog nooit gedaan.

Zat meer te denken richting publieke iPerf3 Servers maar dat is inderdaad ook geen gek idee!

Ik gok dat je dan deels dezelfde dingen moet doen zoals wanneer je een SSH Tunnel tussen twee Servers maakt : https://www.section.io/engineering-education/ssh-tunneling/
_{Zeer beperkte ervaring mee dus misschien zeg ik hier wat verkeerd!}

- Wat bedoel je precies met specificaties van de verbinding?

Je had het over 50 Mbps aansluitingen, maar hebben alle betrokken machines ook een 50 Mbps upload qua abonnement ?!

- Lokaal gaat alles prima, dat zag je al in mijn lokale test.

Was niet duidelijk genoeg voor mij qua wat je nou precies zat te testen...

- Externe pools hebben ruimte zat (125G en 950G).

Maar hoe verhoudt dat zich tot dit : Dadona in "Het grote ZFS topic"

Even een OOKLA speedtest gedraaid en die geeft een prachtige upload snelheid van 0.89Mbps

[Afbeelding]

En dat op mijn 100Mbit glasvezel lijntje...

Ik weet waar ik het moet zoeken.

---

Even de switch gereset. Dat lijkt er meer op:
[Afbeelding]

Dat verklaart het dan waarschijnlijk

[FateTrap]

Wat me altijd opvalt, bijna iedereen gebruikt ZFS voor RAID setups. Waarom is het niet veel populairder voor USB sticks?

Het is erg makkelijk om je USB in ZFS te formatteren op FreeBSD:
dd if=/dev/zero of=/dev/da0 bs=1M
gpart destroy da0
zpool create SanDisk da0

In Ubuntu worden dit type USB's automatisch aangekoppeld, en ik heb nog nooit problemen gehad met deze ZFS USB sticks of FreeBSD of Ubuntu, wat ik niet kan zeggen van exFAT en NTFS.

Waarom zien we niet meer ZFS op USB's en SD kaarten?

[GioStyle]

@FateTrap

Omdat het gros Windows gebruikt en ZFS op een USB hdd is nogal een beetje lastig icm Windows..

[FateTrap]

GioStyle schreef op zaterdag 3 september 2022 @ 18:25:
@FateTrap

Omdat het gros Windows gebruikt en ZFS op een USB hdd is nogal een beetje lastig icm Windows..

Ook Linux gebruikers zie je zo goed als nooit ZFS gebruiken op USB hdd's..

Hetzelfde voor macOS gebruikers: https://openzfsonosx.org/

Je zou kunnen zeggen dat bij benadering 10% van de desktop gebruikers het makkelijk zouden kunnen gebruiken voor HDD's. Maar zo goed als niemand doet het.

Met wat extra mankracht kan het makkelijk naar windows gebracht worden: https://github.com/openzfsonwindows/openzfs/releases

Dus waarom is het zo onpopulair voor USB en SD kaart? Dezelfde voordelen zijn toch ook van toepassing op alle gebruiksdoeleinden?

[RobertMe]

FateTrap schreef op zaterdag 3 september 2022 @ 18:38:
Dus waarom is het zo onpopulair voor USB en SD kaart? Dezelfde voordelen zijn toch ook van toepassing op alle gebruiksdoeleinden?

Maar wat heeft het voor nut? Niet dat ik veel met USB doe. Maar dat is meestal erop zetten en later er af halen/ lezen en klaar. ZFS heeft vele voordelen/features, zoals dat je tot een zetabyte een FS kunt maken, het splitsen in datasets met eigen instellingen en quotas, integrity checks, compression. Maar ik zou niet weten welk van deze ik nodig ziu hebben voor een simpele USB stick. Hoogstens integrity checks. Maarja: bij mij is het erop zetten en ergens anders er af halen. Dat blijft geen jaren staan met kans op bitflips of wat dan ook.

[Brahiewahiewa]

FateTrap schreef op zaterdag 3 september 2022 @ 18:38:
[...]

Met wat extra mankracht kan het makkelijk naar windows gebracht worden: https://github.com/openzfsonwindows/openzfs/releases
...

Leuk verzonnen. Maar zolang ZFS for Windows niet OOB door Microsoft wordt geleverd, zou je dus, als je een ZFS geformateerde USB op Windows wilt lezen, er eerst een FAT geformateerde USB stick in moeten steken om ZFS te installeren

[FateTrap]

RobertMe schreef op zaterdag 3 september 2022 @ 18:43:
[...]
Maar wat heeft het voor nut? Niet dat ik veel met USB doe. Maar dat is meestal erop zetten en later er af halen/ lezen en klaar. ZFS heeft vele voordelen/features, zoals dat je tot een zetabyte een FS kunt maken, het splitsen in datasets met eigen instellingen en quotas, integrity checks, compression. Maar ik zou niet weten welk van deze ik nodig ziu hebben voor een simpele USB stick. Hoogstens integrity checks. Maarja: bij mij is het erop zetten en ergens anders er af halen. Dat blijft geen jaren staan met kans op bitflips of wat dan ook.

Bij een simpele USB stick zou het je de mogelijkheid geven om checksums te doen. Ik denk niet dat er een eenvoudigere manier bestaat om de integriteit van een volledig bestandssysteem te verifiëren dan door ZFS het te laten scrubben. Als iemand twee beschadigde bestanden heeft, kan hij er nog veel meer hebben die hij niet gemakkelijk kan detecteren.

Verder spreek ik ook niet enkel en alleen over kleine USB sticks. Je kunt het ook gebruiken op de 500GB/1TB/2TB HDD's/SSD's die mensen met USB verbinden. Daar staat vaak data op die 5 jaar tot 15 jaar op de schijf aanwezig blijft.

Een ander ding dat ik weet is dat redelijk wat mensen USB opslag gebruiken voor hun VM's data op te slaan en ze gebruiken deze data via USB opslag tijdens de live operatie van de VM.

Leuk verzonnen. Maar zolang ZFS for Windows niet OOB door Microsoft wordt geleverd, zou je dus, als je een ZFS geformateerde USB op Windows wilt lezen, er eerst een FAT geformateerde USB stick in moeten steken om ZFS te installeren

Als er FAT16/32 gebruikt wordt dan gaan mensen het vaak sowieso veranderen naar een ander bestandssysteem om de 4GB bestandlimiet te ontlopen.

[nero355]

FateTrap schreef op zondag 4 september 2022 @ 10:43:
Bij een simpele USB stick zou het je de mogelijkheid geven om checksums te doen.

USB Sticks zijn bij mij tijdelijke opslag die ik echt niet ga zitten scrubben! Sorry!

Ik denk niet dat er een eenvoudigere manier bestaat om de integriteit van een volledig bestandssysteem te verifiëren dan door ZFS het te laten scrubben. Als iemand twee beschadigde bestanden heeft, kan hij er nog veel meer hebben die hij niet gemakkelijk kan detecteren.

Maar dan moet ik al mijn USB Sticks gaan Mirroren

Je kunt het ook gebruiken op de 500GB/1TB/2TB HDD's/SSD's die mensen met USB verbinden. Daar staat vaak data op die 5 jaar tot 15 jaar op de schijf aanwezig blijft.

Dat is dan weer wel een legitieme reden om met ZFS aan de slag te gaan!

Een ander ding dat ik weet is dat redelijk wat mensen USB opslag gebruiken voor hun VM's data op te slaan en ze gebruiken deze data via USB opslag tijdens de live operatie van de VM.

NOFI, maar dat is echt ontzettend dom! Zou ik echt NOOIT doen!