Het grote ZFS topic

[Brahiewahiewa]

kiekerjan schreef op maandag 28 september 2020 @ 14:07:
Ik zie in de logfiles niet terug dat er problemen waren met de SATA controllers of andere communicatie zaken. Ik zie nu wel dat zed tijdens boot meldt:

code:

zed: eid=1 class=statechange pool_guid=0xEA45DF2870F3BD69 vdev_path=/dev/sda1 vdev_state=UNAVAIL
zed: eid=2 class=statechange pool_guid=0xEA45DF2870F3BD69 vdev_path=/dev/sdb1 vdev_state=UNAVAIL

Ik zie echter niet waarom, alle schijven lijken "gewoon" voorbij te komen in de logfiles, geen foutmeldingen. (jaren geleden, toen deze server net nieuw was, heb ik idd problemen gehad met sata links die wegvielen. Dat was toen een combinatie van kapotte voeding en slechte sata drive bays. Die foutmeldingen waren makkelijk terug te vinden)

De 2 schijven die hier door zed gemeld worden zijn net de 2 vdevs die nog als ONLINE worden gerapporteerd, maar wel met de opmerking (resilvering). Hoe zit dat dan?
Het resilveren heb ik dus vannacht laten doorlopen, ik zie nu ook dat het aantal errors een stuk lager is??? Met name de data errors, er lijken dus een flink aantal minder bestanden verloren zijn gegaan.

code:

paranoidandroid:/var/log$ sudo zpool status
  pool: clusterone
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Sep 28 07:36:56 2020
        1.68T scanned at 77.8M/s, 943G issued at 42.7M/s, 1.69T total
        158G resilvered, 54.50% done, 0 days 05:14:11 to go
config:

        NAME                                   STATE     READ WRITE CKSUM
        clusterone                             DEGRADED     0     0     0
          raidz2-0                             DEGRADED     0     0     0
            sdf1                               DEGRADED     0     0   182  too many errors
            sda1                               ONLINE       0     0   187  (resilvering)
            sdg1                               DEGRADED     0     0   182  too many errors
            sdb1                               ONLINE       0     0   188  (resilvering)
            sdd1                               DEGRADED     0     0    20  too many errors
            replacing-5                        DEGRADED     0     0 11.2K
              12164345398775943827             FAULTED      0     0     0  was /dev/sde1
              ata-ST3000LM024-2AN17R_WCK590JX  ONLINE       0     0     0  (resilvering)
        logs
          mirror-1                             ONLINE       0     0     0
            sdc5                               ONLINE       0     0     0
            sdc6                               ONLINE       0     0     0
        cache
          sdc7                                 ONLINE       0     0     0

errors: 11 data errors, use '-v' for a list

ST3000LM024? Dat zijn toch van die SCM schijven die stuk gaan als de load cycle count boven de 300000 uit komt?

[kiekerjan]

Brahiewahiewa schreef op maandag 28 september 2020 @ 21:23:
[...]

ST3000LM024? Dat zijn toch van die SCM schijven die stuk gaan als de load cycle count boven de 300000 uit komt?

Wellicht, nu staat de load cycle count op 16, dus maak ik me er (nog) geen zorgen over

Wat ik eerst wil achterhalen is waar al die checksum errors vandaan komen. Ik zie geen enkele melding hierover in mijn logs (maar misschien kijk ik verkeerd ) Wat verder googlen en logs bekijken lijkt het erop dat er meerdere resilvers zijn gestart. Na elke resilver start zfs blijkbaar een scrub, en is ie net begonnen aan de 2e scrub van de dag. Wat ik heb onder andere heb gevonden is dat een resilver wordt gestart als een vdev (kort) offline is geweest. Nu heb ik een hypothese: sda en sdb zijn kort offline geweest. Normaal gesproken geen issue, maar nu wel omdat ook sde afwezig was. Kunnen al die checksum errors het gevolg van al deze resilver activiteiten zijn?

code:

kiekerjan@paranoidandroid:/var/log$ sudo zpool status -v
  pool: clusterone
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: scrub in progress since Mon Sep 28 21:33:59 2020
        962G scanned at 1.11G/s, 458G issued at 542M/s, 1.69T total
        0B repaired, 26.50% done, 0 days 00:40:01 to go
config:

        NAME                                   STATE     READ WRITE CKSUM
        clusterone                             DEGRADED     0     0     0
          raidz2-0                             DEGRADED     0     0     0
            sdf1                               DEGRADED     0     0   226  too many errors
            sda1                               ONLINE       0     0   231
            sdg1                               DEGRADED     0     0   226  too many errors
            sdb1                               ONLINE       0     0   232
            sdd1                               DEGRADED     0     0    52  too many errors
            replacing-5                        DEGRADED     0     0 11.2K
              12164345398775943827             FAULTED      0     0     0  was /dev/sde1
              ata-ST3000LM024-2AN17R_WCK590JX  ONLINE       0     0     0
        logs
          mirror-1                             ONLINE       0     0     0
            sdc5                               ONLINE       0     0     0
            sdc6                               ONLINE       0     0     0
        cache
          sdc7                                 ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        clusterone/homes@2020-09-27_18.21.01--2d:/jan/.config/syncthing/index-v0.14.0.db/LOG
        clusterone/homes:<0x500a>
        clusterone/vars@2020-09-28_01.31.01--2w:<0x46de6>

Er zijn echter nog maar 3 permanent errors over. Daar ga ik geen last van hebben. Die bestanden zijn blijkbaar al verwijdered, en hopelijk verdwijnen de errors helemaal als de snapshots verwijderd worden.

Update 29-9
vanochtend stond het ding nog steeda te scrubben. Als ik naar de zed meldingen kijk lijkt het erop dat er steeds opnieuwe een resilver plaatsvindt, gevolgd door een scrub.
wat googlen suggereert het verwijderen van de oude vdev en het verwijderen van de kapotte files. Zou dat ook jullie advies zijn?

[ Voor 4% gewijzigd door kiekerjan op 29-09-2020 06:41 . Reden: Status update ]

[Unicron]

Dadona schreef op zondag 27 september 2020 @ 17:39:
[...]
Recent zoiets moeten doen, klopt inderdaad.
Procesgang is dat je de nieuwe disc met GPT moet initialiseren, erna de opbouw moet kopiëren, vervolgens het boot deel kopiëren (partitie 1 en 2 voor legacy en uefi boot) en tot slot de derde partitie aan de rpool moet toevoegen (attach, resilver, joy). Commando's/stappen (in dit geval is sdc de nieuwe disc):

1. Replace the physical failed/offline drive, /dev/sdc
2. Initialize Disk with GPT (/dev/sdc)
3. Copy the partition table from /dev/sda to /dev/sdc
   sgdisk --replicate=/dev/sdc /dev/sda
4. Ensure the GUIDs are randomized
   sgdisk --randomize-guids /dev/sdc
5. Install the Grub on the new disk
   grub-install /dev/sdc
6. Then replace/attach/... the disk in the ZFS pool, several options, opted for this one:
   zpool attach rpool /dev/disk/by-id/<oude disc>-part3 /dev/disk/by-id/<nieuwe disc>-part3
7. Remove old disc
   zpool detach rpool <oude disc>
8. Install grup failed for some reason on my end, therefore copied the set over using dd
   dd if=/dev/sda1 of=/dev/sdb1
   dd if=/dev/sda2 of=/dev/sdb2

In het Engels omdat ik misschien ooit dit soort zaken eens ergens in een blog post. Maar ja, dat is project #4534 En uiteraard nog even de gebruikelijke disclaimers, test het zelf nog even, ik moet het binnenkort zelf nog even dubbelchecken, maar dit zou het moeten zijn.

Net de zfs disk met de root pool gewisseld en met deze stappen alles weer gemaakt

[Dadona]

Mooi dat het gelukt is.

[kiekerjan]

Nu begin ik me toch zorgen te maken. Mijn pool lijkt in een soort eindeloze loop van resilver / scrub te komen. Resilver is klaar, scrub begint. Scrub klaar, resilver begint. Zo draait die pool zichzelf wel in de vernieling

Wel iets gevonden op internet: zed uitzetten, dat heb ik gedaan, maar lijkt niet te heloen. Verder de defer silver feature controleren, maar die staat aan. Die raak ik verder niet aan.
Wat kan ik doen om die loop te stoppen? De replace stoppen? Maar hoe dan? Of de nieuwe schijf eruit halen om "iets" te forceren?

[Thralas]

kiekerjan schreef op donderdag 1 oktober 2020 @ 20:39:
Wat kan ik doen om die loop te stoppen?

Zed stoppen.

Volgens mij doet ZFS verder niets automagisch. Wat zegt zpool events -v na de scrub?

[kiekerjan]

Thralas schreef op donderdag 1 oktober 2020 @ 20:51:
[...]


Zed stoppen.

Volgens mij doet ZFS verder niets automagisch. Wat zegt zpool events -v na de scrub?

Zed is gestopt

code:

kiekerjan@paranoidandroid:/var/log$ sudo systemctl status zed.service
● zfs-zed.service - ZFS Event Daemon (zed)
     Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Thu 2020-10-01 00:11:44 CEST; 22h ago
       Docs: man:zed(8)
    Process: 7307 ExecStart=/usr/sbin/zed -F (code=exited, status=0/SUCCESS)
   Main PID: 7307 (code=exited, status=0/SUCCESS)

Zojuist is een resilver gestopt. En start gewoon de volgende

code:

Oct  1 2020 22:16:19.485868837 sysevent.fs.zfs.history_event
        version = 0x0
        class = "sysevent.fs.zfs.history_event"
        pool = "clusterone"
        pool_guid = 0xea45df2870f3bd69
        pool_state = 0x0
        pool_context = 0x0
        history_hostname = "paranoidandroid"
        history_internal_str = "errors=2"
        history_internal_name = "scan done"
        history_txg = 0x2389340
        history_time = 0x5f763913
        time = 0x5f763913 0x1cf5c525
        eid = 0x2da

Oct  1 2020 22:16:19.505869154 sysevent.fs.zfs.resilver_finish
        version = 0x0
        class = "sysevent.fs.zfs.resilver_finish"
        pool = "clusterone"
        pool_guid = 0xea45df2870f3bd69
        pool_state = 0x0
        pool_context = 0x0
        time = 0x5f763913 0x1e26f362
        eid = 0x2db

Oct  1 2020 22:16:19.505869154 sysevent.fs.zfs.history_event
        version = 0x0
        class = "sysevent.fs.zfs.history_event"
        pool = "clusterone"
        pool_guid = 0xea45df2870f3bd69
        pool_state = 0x0
        pool_context = 0x0
        history_hostname = "paranoidandroid"
        history_internal_str = "errors=1"
        history_internal_name = "starting deferred resilver"
        history_txg = 0x2389340
        history_time = 0x5f763913
        time = 0x5f763913 0x1e26f362
        eid = 0x2dc

Oct  1 2020 22:16:24.741951844 sysevent.fs.zfs.resilver_start
        version = 0x0
        class = "sysevent.fs.zfs.resilver_start"
        pool = "clusterone"
        pool_guid = 0xea45df2870f3bd69
        pool_state = 0x0
        pool_context = 0x0
        time = 0x5f763918 0x2c394964
        eid = 0x2dd

Oct  1 2020 22:16:24.741951844 sysevent.fs.zfs.history_event
        version = 0x0
        class = "sysevent.fs.zfs.history_event"
        pool = "clusterone"
        pool_guid = 0xea45df2870f3bd69
        pool_state = 0x0
        pool_context = 0x0
        history_hostname = "paranoidandroid"
        history_internal_str = "func=2 mintxg=3 maxtxg=37247565"
        history_internal_name = "scan setup"
        history_txg = 0x2389341
        history_time = 0x5f763918
        time = 0x5f763918 0x2c394964
        eid = 0x2de

[CurlyMo]

@kiekerjan Heb je memtest86 gedraaid voor tenminste 24 uur?

[kiekerjan]

CurlyMo schreef op donderdag 1 oktober 2020 @ 22:23:
@kiekerjan Heb je memtest86 gedraaid voor tenminste 24 uur?

Toen ik de server installeerde. Maar dat is alweer enkele jaren geleden ...
Ik zal eens een usb stick zoeken en daarmee aan de slag gaan.

[ Voor 10% gewijzigd door kiekerjan op 01-10-2020 22:29 ]

[Thralas]

kiekerjan schreef op donderdag 1 oktober 2020 @ 22:22:
Zojuist is een resilver gestopt. En start gewoon de volgende

Zou wel eens deze bug kunnen zijn: Resilver restarts unnecessarily when it encounters errors #10291

We have observed that if any errors are encountered during resilver, the entire resilver is restarted from the beginning every time it finishes, never completing, as opposed to finishing the resilver and possibly restarting using DTL_SCRUB.

Let wel: de grondoorzaak is dus dat er errors blijven optreden. Dat moet je verhelpen.

kiekerjan schreef op donderdag 1 oktober 2020 @ 22:29:
Toen ik de server installeerde. Maar dat is alweer enkele jaren geleden ...
Ik zal eens een usb stick zoeken en daarmee aan de slag gaan.

Zinloos lijkt me. Je hebt immers ECC, dan zie je wel in de kernel logs als er wat gecorrigeerd wordt of een uncorrectable error optreedt. Zie ook Monitoring ECC memory on Linux with rasdaemon voor een query utility (blijkbaar is edac-util deprecated).

Met checksum errors op zoveel disks zou ik even een andere controller of machine proberen. Ja, dat is vervelend..

[P5ycho]

Het is wel typisch dat er geen errors gegeven worden op de controller comms in de logging, maar wel eindigen op de disks.

Ik heb ook het idee dat 0.8.x niet zo stabiel is als de gemiddelde FreeBSD release.

[kiekerjan]

Thralas schreef op donderdag 1 oktober 2020 @ 23:13:
[...]
Zou wel eens deze bug kunnen zijn: Resilver restarts unnecessarily when it encounters errors #10291

Ik denk dat ik m hiermee te pakken heb! Dat bug report heeft een patch klaarstaan die waarschijnlijk in 0.8.5 meegaat. Daar heb ik nu niets aan, maar wat googlen leidde naar de parameter zfs_scan_ignore_errors Deze aangezet en een tijd later stoppen de resilvers. Nog een scrub verder en ik lijk een bijna schone pool te hebben.

code:

kiekerjan@paranoidandroid:~$ sudo zpool status -v
  pool: clusterone
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: scrub repaired 0B in 0 days 01:31:09 with 1 errors on Sat Oct  3 12:02:47 2020
config:

        NAME                                 STATE     READ WRITE CKSUM
        clusterone                           ONLINE       0     0     0
          raidz2-0                           ONLINE       0     0     0
            wwn-0x5000cca6accff2bd-part1     ONLINE       0     0     0
            wwn-0x5000cca6accff2e2-part1     ONLINE       0     0     0
            wwn-0x5000cca6accff303-part1     ONLINE       0     0     0
            wwn-0x5000cca6accff3f0-part1     ONLINE       0     0     0
            wwn-0x5000cca6accff44c-part1     ONLINE       0     0     0
            ata-ST3000LM024-2AN17R_WCK590JX  ONLINE       0     0     0
        logs
          mirror-1                           ONLINE       0     0     0
            wwn-0x500a07510c1b4ea9-part5     ONLINE       0     0     0
            wwn-0x500a07510c1b4ea9-part6     ONLINE       0     0     0
        cache
          wwn-0x500a07510c1b4ea9-part7       ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        clusterone/vars:<0x46de6>

Ik heb meteen van de gelegenheid gebruik gemaakt om de vdevs naar by-id te laten wijzen in plaats van naar /dev.

Let wel: de grondoorzaak is dus dat er errors blijven optreden. Dat moet je verhelpen.
[...]
Zinloos lijkt me. Je hebt immers ECC, dan zie je wel in de kernel logs als er wat gecorrigeerd wordt of een uncorrectable error optreedt. Zie ook Monitoring ECC memory on Linux with rasdaemon voor een query utility (blijkbaar is edac-util deprecated).

Ik heb inderdaad edac util gebruikt, die gaf niks. Daarnaast nu dus ook rasdaemon
Toch memtest laten draaien, daar kwam niets uit.

Met checksum errors op zoveel disks zou ik even een andere controller of machine proberen. Ja, dat is vervelend..

Deze pool gebruikt nu al 2 verschillende controllers. Ik heb helaas geen andere hardware in huis om de pool op aan te sluiten. Zou het ook kunnen met een usb-sata controller? Deze gebruik ik normaal gesproken voor een externe backup (zfs send receive) Ik kan dan maar 2 schijven verplaatsen. Is dat genoeg?

In ieder geval bedankt voor de hulp. De urgentie is er nu enigzins af. Rest me nog uit te vinden of en wat er nu nog mis is. Ik verdenk nu nog de nieuwe schijf, wellicht dat die electrisch iets stouts doet. Ik heb al een nieuwe schijf binnen die ik daarvoor zou kunnen gebruiken. Misschien is de voeding ook wel gaar.

Zouden jullie de pool nog vertrouwen? Of is een rebuild verstandig?

[Thralas]

kiekerjan schreef op zaterdag 3 oktober 2020 @ 13:48:
Zou het ook kunnen met een usb-sata controller? Deze gebruik ik normaal gesproken voor een externe backup (zfs send receive) Ik kan dan maar 2 schijven verplaatsen. Is dat genoeg?

Lijkt me prima.

Zouden jullie de pool nog vertrouwen? Of is een rebuild verstandig?

Je scrub output laat nu geen errors zien toch? Lijkt me in principe oke.

Als ik errors: Permanent errors have been detected in the following files: #9705 mag geloven dan heb je nog een tweede scrub nodig om van die permanent error af te komen (die zal dan nog van vóór de laatste scrub zijn).

Pas als je weer op alle disks checksums erros ziet zou ik kijken of je verschil ziet als één disk op een usb-sata controller hangt.

[F-Tim]

Gents... ik zit met een vreemd issue, afgelopen weekend, érg long overdue, onderhoud aan mn eigen NAS gedaan... en de overstap gemaakt van FreeBSD (9) naar Debian (10.6) met ZFS-on-linux (0.8.4).

Maar, ik merk nu al een paar dagen in de ochtend dat de NAS unresponsive is op het netwerk, terwijl deze wél gewoon aanstaat.

Aangezien het elke dag voorkwam sinds het weekend, heb ik al wat stappen gecontroleerd...

Mijn eerste vermoeden was slaapstand... dus eerst alle power saving targets gedisabled:

code:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Daarna heb ik de keer erop een USB receiver voor een toetsenbord ingestoken, om te kijken of het eraan lag dat het apparaat toch in slaapstand zat... maar het toetsenbord gaf met een mooi rood lampje aan geen verbinding met de receiver te krijgen. Ofwel... het lijkt geen power saving te zijn.

Daarna alle missende firmwares geinstalleerd die ik voorbij zag komen via

code:

sudo dmesg

, en vervolgens met

code:

apt-cache search <identifier>

de ontbrekende packages gezocht en vervolgens geïnstalleerd. Daarbij zijn de meeste firmware issues opgelost, al geeft hij nog steeds een foutmelding op de bluetooth maar aangezien ik dat niet gebruik... negeer ik die even (plus kan ik me niet voorstellen dat bluetooth dit probleem veroorzaakt).

Ook nog de intel-microcode package erbij geknald omdat er TSC_DEADLINE disabled due to Errata foutmelding voorbij kwam als eerste bij opstarten, en er geen BIOS update voor mijn mobo is.

Vervolgens ook in /var/log gekeken naar syslog en syslog.1, maar dat kan ik niet goed interpreteren. Ik zie regelmatig van NetworkManager een melding voorbij komen, maar deze is volgens mij niet zo spannend toch?

code:

Oct  8 04:17:01 Node304 CRON[29761]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct  8 04:17:26 Node304 NetworkManager[1027]: <info>  [1602123446.4685] device (wlp3s0): set-hw-addr: set MAC address to 76:58:83:C3:FC:5F (scanning)
Oct  8 04:17:26 Node304 kernel: [30605.634838] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
Oct  8 04:17:26 Node304 NetworkManager[1027]: <info>  [1602123446.5090] device (wlp3s0): supplicant interface state: inactive -> disconnected
Oct  8 04:17:26 Node304 NetworkManager[1027]: <info>  [1602123446.5165] device (wlp3s0): supplicant interface state: disconnected -> inactive
Oct  8 04:17:26 Node304 wpa_supplicant[1028]: wlp3s0: Reject scan trigger since one is already pending

De eerstvolgende melding opvolgend komt is weer de bootcyclus.

Dus ergens gaat iets niet goed, maar ik heb geen idee wat... hebben jullie enig idee waar dit aan kan liggen?

Fun fact, tijdje geleden een andere NAS in elkaar gedraaid met Debian 10.4 op een oude HP Microserver, en geen enkele van deze issues gehad

[FireDrunk]

Is WiFi de enige netwerkverbinding die je server heeft?

[F-Tim]

FireDrunk schreef op donderdag 8 oktober 2020 @ 11:45:
Is WiFi de enige netwerkverbinding die je server heeft?

Nope, heb het apparaat bekabeld aangesloten, met een static IP (geconfigureerd via de UI, dus niet via de CLI in /etc/network/interfaces als ik het goed herinner).

Wellicht nog overbodige extra info, ten tijde van de partitionering heb ik 2x een 8GB partitie aangemaakt als swaparea, ondanks dat er slechts 8GB fysiek ram is. (Meer swap dan ram lijkt me geen probleem).

[FireDrunk]

Ethernet zal niet uitvallen vanwege power saving... Dat lijkt me sterk.
De logs die je laat zien zijn allemaal van wifi. Ik verwacht dat je ethernet adapter iets heeft als 'eno1' of 'enp0'.

Zie je daar niets over in de kernel logs?

[F-Tim]

FireDrunk schreef op donderdag 8 oktober 2020 @ 12:12:
Ethernet zal niet uitvallen vanwege power saving... Dat lijkt me sterk.
De logs die je laat zien zijn allemaal van wifi. Ik verwacht dat je ethernet adapter iets heeft als 'eno1' of 'enp0'.

Zie je daar niets over in de kernel logs?

Klopt, de ethernet adapter is idd eno1, en nope... daar komt niets van voorbij in de syslog files. Ik heb even de uitsnede gemaakt, van afgelopen nacht 0:00 tot het moment van reboot, en op PasteBin gezet: https://pastebin.com/qQekYhjM

[FireDrunk]

Staat er iets op de console van de machine? Kan je met een fysiek toetsenbord nog wel iets op de bak?

[F-Tim]

FireDrunk schreef op donderdag 8 oktober 2020 @ 12:28:
Staat er iets op de console van de machine? Kan je met een fysiek toetsenbord nog wel iets op de bak?

Zal ik morgen eens kijken heb hem momenteel nl. headless draaien, dus tot op heden nog niets gezien van de console.

[FireDrunk]

Reboot je de server dan als deze unresponsive wordt? Of wat zorgt er voor dat je server weer bereikbaar is?

[vanaalten]

F-Tim schreef op donderdag 8 oktober 2020 @ 13:08:
Zal ik morgen eens kijken heb hem momenteel nl. headless draaien, dus tot op heden nog niets gezien van de console.

Ik had/heb zo'n zelfde vergelijkbaar probleem. In mijn geval - en het kan bij jou iets totaal anders zijn - lijkt het een kernel bug te zijn die je in de log niet terugvindt, maar wel op het scherm voorbij ziet komen. Dus kan verstandig zijn om een monitor er aan te hangen.

[Borromini]

@F-Tim Ik zie een vergelijkbaar probleem hier op een zelfbouw NAS (G1610, Ivy Bridge). Die heeft lang probleemloos gedraaid maar hangt nu af en toe. Loopt hier ook af en toe vast, scherm aan gehangen, maar lijkt ook niks op te komen (draait bij familie).

[FireDrunk]

Ik had een aantal weken gelden hetzelfde issue met Debian 10, ik heb sindsdien de kernel (lichtelijk geforceerd) geupgrade naar 5.4.

Stappen:

1) Enable Backports repo (google is je vriend)
2)

apt install linux-image-5.4.0-0.bpo.2-amd64
apt install linux-headers-5.4.0-0.bpo.2-amd64

3) reboot
4) (eventueel) oude kernel verwijderen.

Waarschuwing, dit kan potentieel je ZFS kernel module setup breken, use-with-caution
Dat had ik ook, een 'simpele' geforceerde reinstall van het zfs-dkms package hielp, maar YMMV.

Sindsdien geen crashes meer gehad.

[ Voor 25% gewijzigd door FireDrunk op 08-10-2020 17:29 ]

[Eric_1993]

Beste lezers,

Ik heb 5 WD Blue schijven die ik graag wil gebruiken voor back-up. Ik wil daarbij het ZFS met Raid Z3 gebruiken. Ik heb alleen ervaring met Windows. Hoe kan ik gebruik maken van ZFS?

Ik heb NAS4Free geïnstalleerd op Virtualbox. Dat gaat erg traag en vraag mij af of er een ander mogelijkheid is...

[FireDrunk]

@Eric_1993
FreeNAS of tegenwoordig TrueNAS is iets beter in ZFS, maar dat draait inderdaad niet super snel in Virtualbox.

Waar ben je naar op zoek?, ZFS is behoorlijk geavanceerde technologie, en niet voor de 'faint-of-heart'

[ Voor 3% gewijzigd door FireDrunk op 08-10-2020 17:38 ]

[Eric_1993]

FireDrunk schreef op donderdag 8 oktober 2020 @ 17:38:
@Eric_1993
FreeNAS of tegenwoordig TrueNAS is iets beter in ZFS, maar dat draait inderdaad niet super snel in Virtualbox.

Waar ben je naar op zoek?, ZFS is behoorlijk geavanceerde technologie, en niet voor de 'faint-of-heart'

Ik wil graag mijn backup op die 5 schijven zetten met het liefst een bestandsysteem of software die periodiek controleert met checksums of de backup niet corrupt is.

[FireDrunk]

Je hebt dus ergens een 'bron' systeem waarin genoeg storage zit om die 5 schijven te vullen?
Zijn die 5 WD Blue's ook externe schijven? Of wil je die in een dock gaan plaatsen ofzo?

[Eric_1993]

FireDrunk schreef op donderdag 8 oktober 2020 @ 17:44:
Je hebt dus ergens een 'bron' systeem waarin genoeg storage zit om die 5 schijven te vullen?
Zijn die 5 WD Blue's ook externe schijven? Of wil je die in een dock gaan plaatsen ofzo?

Die WD blue's zijn interne schijven die ik in een dock heb geplaatst van Orico. De dock is verbonden met USB 3.0.

[FireDrunk]

ZFS is sowieso een filesystem waarbij de schijven continue allemaal beschikbaar moeten zijn, niet iets wat achteraf een pariteitsberekening maakt, je zal dus altijd alle schijven tegelijk moeten gebruiken.

Doorgaans bouwen de meeste mensen een losse PC om tot NAS, en installeren hierop een besturingssysteem met support voor ZFS.

Je kan niet zomaar ZFS gebruiken op een Windows systeem. In jouw geval zal je dus de data van je Windows systeem via het netwerk naar een systeem met ZFS moeten kopieren.

[Eric_1993]

FireDrunk schreef op donderdag 8 oktober 2020 @ 18:04:
ZFS is sowieso een filesystem waarbij de schijven continue allemaal beschikbaar moeten zijn, niet iets wat achteraf een pariteitsberekening maakt, je zal dus altijd alle schijven tegelijk moeten gebruiken.

Doorgaans bouwen de meeste mensen een losse PC om tot NAS, en installeren hierop een besturingssysteem met support voor ZFS.

Je kan niet zomaar ZFS gebruiken op een Windows systeem. In jouw geval zal je dus de data van je Windows systeem via het netwerk naar een systeem met ZFS moeten kopieren.

Dat heb ik dus geprobeerd met NAS4Free op Virtualbox. Het kopiëren van de bestanden lukt, gaat wel langzaam. Maar bij het lezen van de bestanden in de ZFS container krijg ik een foutmelding in Windows verkenner en is de smb share niet meer bereikbaar. Ik moet dan nas4free opnieuw opstarten, en dan is de smb share weer bereikbaar, maar bij het lezen van het bestand word de share weer onbereikbaar met een foutmelding. NAS4Free krijgt 4 cores CPU en 8 GB RAM.

[mcDavid]

Als ik heel eerlijk mag wezen, @Erik1 , ik denk dat je jouw oplossing helemaal niet in ZFS moet zoeken.

Je zegt dat je backups wilt maken en daarvan periodiek de checksums wilt controleren. Waarom gebruik je niet gewoon normale backupsoftware daarvoor?

Ik heb geen ervaring met virtualisatie op een windows-host, maar... kun je uberhaupt fysieke block-devices aan een guest koppelen? Het klinkt iig als een héél slecht idee. Een RaidZ-3 pool van 5 disks lijkt me overigens óók geen bijster praktisch idee.

[Eric_1993]

mcDavid schreef op donderdag 8 oktober 2020 @ 18:45:
Als ik heel eerlijk mag wezen, @Erik1 , ik denk dat je jouw oplossing helemaal niet in ZFS moet zoeken.

Je zegt dat je backups wilt maken en daarvan periodiek de checksums wilt controleren. Waarom gebruik je niet gewoon normale backupsoftware daarvoor?

Ik heb geen ervaring met virtualisatie op een windows-host, maar... kun je uberhaupt fysieke block-devices aan een guest koppelen? Het klinkt iig als een héél slecht idee. Een RaidZ-3 pool van 5 disks lijkt me overigens óók geen bijster praktisch idee.

Wat ik bij VirtualBox deed was 5 VDI’s maken en het dan verdelen over de 5 schijven.

Wat voor software zou u dan aanraden? Het gaat om 90 mappen met totale grootte van 900 GB.

[F-Tim]

FireDrunk schreef op donderdag 8 oktober 2020 @ 13:25:
Reboot je de server dan als deze unresponsive wordt? Of wat zorgt er voor dat je server weer bereikbaar is?

Dat inderdaad... op de harde manier met de power knop.

vanaalten schreef op donderdag 8 oktober 2020 @ 13:29:
[...]

Ik had/heb zo'n zelfde vergelijkbaar probleem. In mijn geval - en het kan bij jou iets totaal anders zijn - lijkt het een kernel bug te zijn die je in de log niet terugvindt, maar wel op het scherm voorbij ziet komen. Dus kan verstandig zijn om een monitor er aan te hangen.

Ik zal het morgenochtend zien hopelijk, al ben ik benieuwd of ik een console te zien krijg... of een Gnome login UI. Of kan ik gnome tijdelijk uitschakelen?

Update: Dit gedaan met het commando systemctl set-default multi-user.target, reboot en enkel de console zichtbaar Na een paar acties op de console te doen, traden er artefacten op op het scherm, en hing de machine...! Dus onderstaande ook alvast gedaan...

FireDrunk schreef op donderdag 8 oktober 2020 @ 17:28:
Ik had een aantal weken gelden hetzelfde issue met Debian 10, ik heb sindsdien de kernel (lichtelijk geforceerd) geupgrade naar 5.4.

Stappen:

1) Enable Backports repo (google is je vriend)
2)

apt install linux-image-5.4.0-0.bpo.2-amd64
apt install linux-headers-5.4.0-0.bpo.2-amd64

3) reboot
4) (eventueel) oude kernel verwijderen.

[color=red]Waarschuwing, dit kan potentieel je ZFS kernel module setup breken, use-with-caution[/color]
Dat had ik ook, een 'simpele' geforceerde reinstall van het zfs-dkms package hielp, maar YMMV.

Sindsdien geen crashes meer gehad.

Hmmm backports draai ik al, kan morgen eens proberen of dit helpt. Ben benieuwd of k hier helemaal uit kom.... zal eerst even m’n Plex folder backuppen just to be sure mocht t niet lukken, dan maar een reinstall zonder desktop env

Update: Vanuit backports zowel de nieuwe linux-image als de linux-headers opgehaald... reboot, en eigenlijk bleef ZFS gewoon werken. Gecontroleerd met uname -r, maar die gaf mooi de nieuwe 5.4.0-0.bpo.2-amd64 aan... dus deze stap ging in ieder geval goed.

Nu nog even fingers crossed wat de machine de komende dagen doet

[ Voor 14% gewijzigd door F-Tim op 08-10-2020 22:12 ]

[mcDavid]

Eric_1993 schreef op donderdag 8 oktober 2020 @ 19:34:
[...]


Wat ik bij VirtualBox deed was 5 VDI’s maken en het dan verdelen over de 5 schijven.

Wat voor software zou u dan aanraden? Het gaat om 90 mappen met totale grootte van 900 GB.

Kijk eens naar duplicati bijvoorbeeld.

[Eric_1993]

mcDavid schreef op donderdag 8 oktober 2020 @ 22:13:
[...]

Kijk eens naar duplicati bijvoorbeeld.

Dat heb ik ook geprobeerd, het issue daarbij is, is dat ik 5 verschillende backup profielen moet maken en ze dan vervolgens 1 voor 1 moet starten omdat Duplicati geen wachtrij ondersteuning heeft.

Mocht iemand nog een goed back-up software weten, hoor ik het graag.

[F-Tim]

Damn.... helaas was dit niet de oplossing, wederom artefacten op het scherm deze ochtend.



Alleen nu de hamvraag, hoe ga ik uitvinden wat het issue is?
Ik zou haast denken dat een driver niet de juiste is, waarbij ik initieel de grafische driver verwacht...

[CurlyMo]

F-Tim schreef op vrijdag 9 oktober 2020 @ 08:37:
Damn.... helaas was dit niet de oplossing, wederom artefacten op het scherm deze ochtend.

[Afbeelding]

Alleen nu de hamvraag, hoe ga ik uitvinden wat het issue is?
Ik zou haast denken dat een driver niet de juiste is, waarbij ik initieel de grafische driver verwacht...

Ik zie linksboven nog steeds een prompt. Of is je systeem in deze staat vastgelopen?

[F-Tim]

CurlyMo schreef op vrijdag 9 oktober 2020 @ 08:42:
[...]

Ik zie linksboven nog steeds een prompt. Of is je systeem in deze staat vastgelopen?

Vastgelopen in deze staat... unresponsive via tobo en ook niet met SSH

Edit: Zojuist de package xserver-xorg-video-intel verwijderd, op deze site van Debian staat dat het gebruik van deze discouraged is... kijken of dat nog iets helpt

[ Voor 30% gewijzigd door F-Tim op 09-10-2020 09:09 ]

[nero355]

F-Tim schreef op vrijdag 9 oktober 2020 @ 08:37:
Damn.... helaas was dit niet de oplossing, wederom artefacten op het scherm deze ochtend.

[Afbeelding]

Alleen nu de hamvraag, hoe ga ik uitvinden wat het issue is?
Ik zou haast denken dat een driver niet de juiste is, waarbij ik initieel de grafische driver verwacht...

Kan je proberen, maar wat mij betreft is dit gewoon een brakke GPU en in dit geval dus de iGPU

Wat doet een losse GPU met de iGPU uitgeschakeld

[F-Tim]

nero355 schreef op vrijdag 9 oktober 2020 @ 19:03:
[...]

Kan je proberen, maar wat mij betreft is dit gewoon een brakke GPU en in dit geval dus de iGPU

Wat doet een losse GPU met de iGPU uitgeschakeld

Ik zal eens vrienden vragen of ze nog een GPU hebben liggen... heb zelf nl niks.

Wel bijzonder dat de GPU op FreeBSD geen issues gaf. Kan ik Debian niet zo configureren dat ie geen visuele zaken nodig heeft?

Het heeft nl op BSD bijna 5 jaar stabiel gedraaid, en kan tuurlijk kapot zijn, maar dat zou dan wel echt vette pech zijn qua timing... dat zet me nl erg aan t twijfelen

[ Voor 16% gewijzigd door F-Tim op 10-10-2020 10:52 ]

[Giesber]

Zulke artifacts geven bij mij ook de trigger om naar de GPU te kijken, maar het zou ook aan het geheugen van de GPU kunnen liggen. In het geval van een iGPU is dat dus het gewone RAM geheugen. Kan je een memtest draaien, 1 van de 2 latjes verwijderen (als je er 2 hebt), of andere latjes proberen?

Of ben ik hier onzin aan het uitkramen?

[F-Tim]

Giesber schreef op zaterdag 10 oktober 2020 @ 10:45:
Zulke artifacts geven bij mij ook de trigger om naar de GPU te kijken, maar het zou ook aan het geheugen van de GPU kunnen liggen. In het geval van een iGPU is dat dus het gewone RAM geheugen. Kan je een memtest draaien, 1 van de 2 latjes verwijderen (als je er 2 hebt), of andere latjes proberen?

Of ben ik hier onzin aan het uitkramen?

Ik ga memtest eens proberen met n live-cd van n Ubuntu, kijken wat eruit komt

[F-Tim]

En toch typisch gevalletje defect geheugen.... Memtest gaf een error aan op de 8GB module die erin zat.

Had toevallig nog 2x2GB liggen.... die erin geplaatst, nog een test uitgevoerd, zonder enige fout, en die draait sindsdien al 1,5 dag zonder enig issue. Rest van de week eens kijken... maar toch een gevalletje vette pech zo lijkt het.

[FireDrunk]

BSD en Linux hebben mogelijk het geheugen anders aan gesproken (Linux begint vaak achteraan, Windows vooraan). Geen idee wat BSD anders doet.

Zou natuurlijk al langer kapot kunnen zijn, maar je merkt het mogelijk nu pas

[F-Tim]

Zucht... waarom heeft Windows altijd kuren met Samba...?

Ik had ten tijde van de migratie Samba geconfigureerd voor anoniem gebruik (want tijdgebrek), werkte als een tierelier. Vandaag dacht ik, ik ga weer users toevoegen zodat ik ook de persoonlijke shares kan gebruiken.

Dus... de volgende set commando's gebruikt om de groep en user(s) aan te maken, :

groupadd thuis
adduser --no-create-hom --shell /usr/sbin/nologin/tim
smbpasswd -a tim
smbpasswd -e tim
usermod -G tim,thuis tim
chown -R tim:thuis /tank/personal/Tim

Vervolgens nog geen wijzigingen gedaan aan de smb.conf, maar ik merkte al op dat Windows niet meer kon inloggen op de (anonieme) share...

En de crux is... op mijn iOS devices kan ik wél navigeren naar de anonieme share.

Vervolgens ook nog de smb.conf aangepast zodat ik [Personal] share de write list = @thuis gaf, maar ook dat bood geen soelaas voor Windows. Wel weer op iOS, want ik kon nu netjes bij de persoonlijke map komen (en ook zoals hoort *niet* in de andere persoonlijke mappen).

Wat doet mijn Win10 machine nu fout?

Edit:
Ik heb toevallig ook nog de SMB1.0 features ge-enabled in Windows (legacy van de oude BSD configuratie), dus daar kan het niet aan liggen, en ter controle in smb.conf heb ik de client min protocol en client max protocol op SMB2 en SMB3 ingesteld. Als ik SMB1 instel, dan krijg ik fouten bij het herstarten van de smbd service.

Edit 2:
Stapje verder gekomen... hele nieuwe smb.conf aangemaakt vanuit een ander forum, werkte nog steeds niet. Vergeleken met mijn oude BSD smb.conf, zag ik dat daar regel

guest user = share

in stond. Deze toegevoegd, met het admin account... en één en ander bleek te gaan werken... in ieder geval anoniem weer (maar.. snap ik, want admin credentials... voor anonieme gebruikers, en dus ook onveilig). Heb daarna ook weer de file grotendeels gestript, en gekeken wanneer iets omviel, nu dus de meest lean versie ervan gemaakt.

Heb een share die "read only" is voor anonieme gebruikers, een share die "read write" is, en een 2 persoonlijke shares.... en de grap is, de read only, en de read write werken.... maar de persoonlijke shares willen gewoon totaal niet openen.... op Windows op iOS gaat alles goed!

Maar wat ik ook doe, ik krijg geen werkende login op Windows voor elkaar... wie heeft nog een goeie tip voor me?

Edit 3:
Het is --grotendeels-- voor elkaar... de optie

ntlm auth = yes

, in combinatie met de in Windows gemounte netwerk map vergeten bleek de oplossing. Nu alleen nog een keer de admin credentials op de guest toegang eraf halen, en dan is het er. Maar dat parkeer ik voor nu even

[ Voor 44% gewijzigd door F-Tim op 20-10-2020 16:22 ]

[FireDrunk]

downloads: TrueNAS 12.0

Paar mooie features erbij!

[Giesber]

FireDrunk schreef op donderdag 22 oktober 2020 @ 14:06:
downloads: TrueNAS 12.0

Paar mooie features erbij!

Over een maand of zo zal ik maar eens updaten dan .

[engessa]

Ik ga wat schuiven met mijn data en kan zonder kosten upgraden naar 5 x 4TB in RAIDZ1. Op dit moment is dat 4x 4TB.

Een 4TB schijf kost rond de 100 euro en ik kan er daarom ook voor kiezen om 6x 4TB in RAIDZ2 van maken of twee arrays van 3x 4TB in RAIDZ1. Beide opties leveren evenveel vrije ruimte op.

Iemand een advies wat te doen? 2x RAIDZ1 of 1x RAIDZ2? Een deel van de schijven draait al een jaar of 4 zonder problemen maar het is natuurlijk maar de vraag hoe lang dat nog zo blijft. Iets meer zekerheid van een geslaagde recovery voelt wel fijn.

[ Voor 7% gewijzigd door engessa op 23-10-2020 14:52 ]

[Brahiewahiewa]

engessa schreef op vrijdag 23 oktober 2020 @ 14:43:
...Een 4TB schijf kost rond de 100 euro..
... Een deel van de schijven draait al een jaar of 4 zonder problemen...

Een 4TB schijf van 100 €uro is een exemplaar met maar twee jaar fabrieksgarantie.
Een exemplaar met 5 jaar fabrieksgarantie is bijna twee keer zo duur.
Je moet een afweging maken hoe belangrjk de data in kwestie voor je is, hoe goed je je backup hebt ingericht, wat de benodigde tijd is om die backup te restoren

ZFS is een fantastisch product maar het is niet bedoeld om de levensduur van ranzige desktop schijven significant te verlengen

[engessa]

Ja, das allemaal leuk en aardig maar dat is niet de info waar ik naar op zoek ben. Ik wil best reageren op je vragen hoor, dat is namelijk niet belangrijk, geen backups en geen idee. In de vijftien jaar dat ik mn eigen NAS draai nog nooit een drive hoeven recoveren.

[Giesber]

Bij beide ga je vanaf 3 kapotte schijven gegarandeerd dataverlies hebben, maar bij 2x RAIDZ1 kan je ook al vanaf 2 schijven de helft van je data kwijt zijn. Daarentegen ben je bij 3 kapotte schijven wel zeker dat je bij 2x RAIDZ1 nog de helft van je data hebt. Alleen, wat koop je daarmee? Je weet niet welke data er nog zal zijn.

Waarom zou je 2x RAIDZ1 overwegen? Ik zie eigenlijk maar weinig voordelen tegenover 1x RAIDZ2. Als je 1 grote array maakt ga je ook efficiënter met je capaciteit kunnen omgaan: je moet het niet verdelen over 2 arrays. Misschien is een upgradescenario gemakkelijker bij 2 kleinere arrays, dan zou je in de toekomst 3 schijven kunnen vervangen door grotere. Maar je blijft dan zitten met maar 1 schijf redundantie (iets waar je vanaf lijkt te willen).

Maak je geen zorgen over de 4 jaar oude schijven, die blijven misschien nog 7 jaar probleemloos draaien. Wees je er wel van bewust dat de kans een beetje groter gaat worden dat je ze gaat moeten vervangen, maar ik zou ze gewoon houden.

[mcDavid]

Giesber schreef op vrijdag 23 oktober 2020 @ 17:15:
Waarom zou je 2x RAIDZ1 overwegen? Ik zie eigenlijk maar weinig voordelen tegenover 1x RAIDZ2. Als je 1 grote array maakt ga je ook efficiënter met je capaciteit kunnen omgaan: je moet het niet verdelen over 2 arrays. Misschien is een upgradescenario gemakkelijker bij 2 kleinere arrays, dan zou je in de toekomst 3 schijven kunnen vervangen door grotere. Maar je blijft dan zitten met maar 1 schijf redundantie (iets waar je vanaf lijkt te willen).

Als je meerdere RaidZ1's in één pool hebt, wordt de data daarover gestriped, wat de performance behoorlijk ten goede kan komen. Als redundancy belangrijker is dan performance zou één RaidZ2 idd meer sense maken.

edit: qua capaciteit maakt het overigens geen zak uit? Data wordt automatisch gestriped en je hebt in beide scenario's evenveel pariteit.

[ Voor 8% gewijzigd door mcDavid op 23-10-2020 17:56 ]

[engessa]

Ah, das een goede. Ik had er inderdaad nog niet aan gedacht dat twee raidz1 arrays in een gezamenlijke pool kunnen. Nu is performance ook niet echt heel belangrijk (het gaat hier om een plex server met films en series) maar wel goed om te weten.

De afweging om voor twee x raidz1 te gaan is om een upgradescenario makkelijker te maken. Als ik bv overstap op drie x 14 tb dan kan ik met de meeste moederborden (die hebben zes sata poorten) de data stap voor stap over zetten. Als alles in een array (of pool) zit dan heb ik altijd een extra controller (of server) nodig om de boel te verplaatsen.

[Q]

Brahiewahiewa schreef op vrijdag 23 oktober 2020 @ 15:14:
[...]

Een 4TB schijf van 100 €uro is een exemplaar met maar twee jaar fabrieksgarantie.
Een exemplaar met 5 jaar fabrieksgarantie is bijna twee keer zo duur.
Je moet een afweging maken hoe belangrjk de data in kwestie voor je is, hoe goed je je backup hebt ingericht, wat de benodigde tijd is om die backup te restoren

ZFS is een fantastisch product maar het is niet bedoeld om de levensduur van ranzige desktop schijven significant te verlengen

Ik zou dan kiezen voor 6 x 4TB in RAIDZ2 als je de performance niet nodig hebt, wat waarschijnlijk is.

Ik weet niet of 5 drives (oneven) een issue is voor ZFS RAIDZ maar bedenk wel dat je een VDEV niet kunt uitbreiden. Je kunt alleen met VDEVS uitbreiden. Dus het is waarschijnlijk practischer om nu voor 6 drives te gaan.

RAIDZ1 zou ook redelijk zijn, maar je moet zelf bepalen of je dat risico met 2 extra disks wilt gaan lopen. Niet dat ik RAIDZ1 zo gevaarlijk vind, maar als je echt zo min mogelijk risico wilt lopen is RAIDZ2 een stuk veiliger.

[ Voor 10% gewijzigd door Q op 23-10-2020 18:33 ]

[mcDavid]

engessa schreef op vrijdag 23 oktober 2020 @ 18:17:
Ah, das een goede. Ik had er inderdaad nog niet aan gedacht dat twee raidz1 arrays in een gezamenlijke pool kunnen. Nu is performance ook niet echt heel belangrijk (het gaat hier om een plex server met films en series) maar wel goed om te weten.

De afweging om voor twee x raidz1 te gaan is om een upgradescenario makkelijker te maken. Als ik bv overstap op drie x 14 tb dan kan ik met de meeste moederborden (die hebben zes sata poorten) de data stap voor stap over zetten. Als alles in een array (of pool) zit dan heb ik altijd een extra controller (of server) nodig om de boel te verplaatsen.

Da's niet helemaal hoe het werkt, je kunt niet een raidz zomaar uit je pool halen. Al zou je theoretisch disk voor disk kunnen vervangen mits ze compatibel zijn.
Al kan dat natuurlijk ook in een raidz2 van 6 disks, maar dan duurt het wat langer voordat je de capaciteit erbij krijgt

Q schreef op vrijdag 23 oktober 2020 @ 18:31:
[...]

RAIDZ1 zou ook redelijk zijn, maar je moet zelf bepalen of je dat risico met 2 extra disks wilt gaan lopen. Niet dat ik RAIDZ1 zo gevaarlijk vind, maar als je echt zo min mogelijk risico wilt lopen is RAIDZ2 een stuk veiliger.

In dit geval idd waar, maar niet perse het geval. Het ligt er allemaal aan hoeveel pariteit je pool heeft en hoe die verdeeld is.

[engessa]

mcDavid schreef op vrijdag 23 oktober 2020 @ 20:43:
[...]

Da's niet helemaal hoe het werkt, je kunt niet een raidz zomaar uit je pool halen. Al zou je theoretisch disk voor disk kunnen vervangen mits ze compatibel zijn.
Al kan dat natuurlijk ook in een raidz2 van 6 disks, maar dan duurt het wat langer voordat je de capaciteit erbij krijgt

Je hebt gelijk. Als ik het goed begrijp heb ik drie opties:

Optie A: 2 RAIDZ1 arrays (eigenlijk dus VDEVS) in 2 verschillende pools
Optie B: 2 RAIDZ1 arrays in 1 pool
Optie C: 1 RAIDZ2 array in 1 pool

In het geval van optie A moet het volgens mij wel kunnen. Maar optie B zou wel beter zijn, is sneller en efficiënter met ruimtegebruik.

Maar als ik jullie reacties zo lees lijkt mij optie C het beste. Meest efficiënt mbt ruimtegebruik en iets robuuster in het geval van disc failure.

[ Voor 11% gewijzigd door engessa op 23-10-2020 21:25 ]

[P5ycho]

A heeft dubbele IOps van de rest. B heeft de minste redundantie, C de meeste. Ik zou nooit voor A kiezen, als je hoge IOps wilt zijn er betere keuzes. Geen backups, dus lekker C kiezen.

Schijven vervangen doe je het makkelijkst met een externe usb enclosure trouwens.

[Q]

mcDavid schreef op vrijdag 23 oktober 2020 @ 20:43:
In dit geval idd waar, maar niet perse het geval. Het ligt er allemaal aan hoeveel pariteit je pool heeft en hoe die verdeeld is.

@mcDavid Sorry, dit snap ik niet zo goed. De pool kent geen pariteit, alleen VDEVs kennen redundancy/parity toch?

[mcDavid]

Q schreef op zaterdag 24 oktober 2020 @ 17:33:
[...]


@mcDavid Sorry, dit snap ik niet zo goed. De pool kent geen pariteit, alleen VDEVs kennen redundancy/parity toch?

Ja, klopt. Maar 1 RaidZ2 VDEVs is bijv niet perse "veiliger" dan 3 RaidZ1 VDEVs. In dat laatste geval heb je in totaal meer pariteit. RAIDZ2 is dus geen magische "fix-all" oplossing. Je moet gewoon goed nadenken wat het meest geschikt is voor het materiaal wat je gebruikt en de eisen die je stelt.

Maar zoals ik al zei, in dit geval ben ik helemaal met je eens dat RAIDZ2 waarschijnlijk de meest geschikte oplossing is.

[dcm360]

mcDavid schreef op zaterdag 24 oktober 2020 @ 18:57:
[...]


Ja, klopt. Maar 1 RaidZ2 VDEVs is bijv niet perse "veiliger" dan 3 RaidZ1 VDEVs. In dat laatste geval heb je in totaal meer pariteit. RAIDZ2 is dus geen magische "fix-all" oplossing. Je moet gewoon goed nadenken wat het meest geschikt is voor het materiaal wat je gebruikt en de eisen die je stelt.

Maar zoals ik al zei, in dit geval ben ik helemaal met je eens dat RAIDZ2 waarschijnlijk de meest geschikte oplossing is.

Meer pariteit is niet altijd beter. Stel je pakt 9 schijven, en die deel je in in jouw voorgestelde arrays (dus een Z2 van 9 schijven, en driemaal een Z1 van 3 schijven). Één van de schijven is gesneuveld, en de overige 8 werken nog. Welke situatie is veilig, en welke niet? Bij de grote Z2-array kan er nog een willekeurige schijf sneuvelen zonder gevolgen. Bij de kleine Z1-arrays, heb je 1 array die nog een defecte schijf niet zal overleven. De kans is 25% dat de tweede schijf die defect raakt, leidt tot dataverlies. Ondanks de extra pariteit, heb je dus meer kans op dataverlies bij 3 Z1-arrays ten opzichte van een enkele Z2-array.

[mcDavid]

dcm360 schreef op zaterdag 24 oktober 2020 @ 21:48:
[...]

Meer pariteit is niet altijd beter. Stel je pakt 9 schijven, en die deel je in in jouw voorgestelde arrays (dus een Z2 van 9 schijven, en driemaal een Z1 van 3 schijven). Één van de schijven is gesneuveld, en de overige 8 werken nog. Welke situatie is veilig, en welke niet? Bij de grote Z2-array kan er nog een willekeurige schijf sneuvelen zonder gevolgen. Bij de kleine Z1-arrays, heb je 1 array die nog een defecte schijf niet zal overleven. De kans is 25% dat de tweede schijf die defect raakt, leidt tot dataverlies. Ondanks de extra pariteit, heb je dus meer kans op dataverlies bij 3 Z1-arrays ten opzichte van een enkele Z2-array.

Sja, echter bij 3 defecte schijven heb je dan 100% kans op dataverlies... Bovendien is je performance scenario compleet anders. Ik wil nadrukkelijk niet beweren dat het een beter is dan het ander, enkel dat je per toepassing een juiste keuze moet maken.

[dcm360]

mcDavid schreef op zaterdag 24 oktober 2020 @ 23:22:
[...]

Sja, echter bij 3 defecte schijven heb je dan 100% kans op dataverlies... Bovendien is je performance scenario compleet anders. Ik wil nadrukkelijk niet beweren dat het een beter is dan het ander, enkel dat je per toepassing een juiste keuze moet maken.

Het argument dat je echter aandroeg was 'meer pariteit'. Dat is echter misleidend, want de kans op dataverlies is groter. Dat met 3 schijven defect de raid Z2 kansloos is is evident, maar ook de variant met 3maal een Z1 kan niet zo goed tegen 3 uitvallende schijven: de kans op dataverlies is 68% (met de hoeveelheid schijven uit mijn voorbeeld. Als je meer schijven hebt, wordt de kans op dataverlies groter). En dat is overigens in het ideale geval, de praktijk zal minder mooi zijn, aangezien intensief in gebruik zijnde schijven meer kans op falen hebben dan schijven in idle, en de kans op een defect op de 'verkeerde' array die al een schijf mist groter is dan op een 'goede' array die nog een schijf meer heeft.

De kans op dataverlies ruil je dus in tegen performance, dat is duidelijk. Maar de Z2-array is sowieso veiliger dan 3maal een Z1-array.

[Giesber]

mcDavid schreef op zaterdag 24 oktober 2020 @ 23:22:
[...]

Sja, echter bij 3 defecte schijven heb je dan 100% kans op dataverlies... Bovendien is je performance scenario compleet anders. Ik wil nadrukkelijk niet beweren dat het een beter is dan het ander, enkel dat je per toepassing een juiste keuze moet maken.

Met redundantie wil je toch net alle risico's afdekken? En niet het risico willen lopen dat je bij 2 defecte schijven toch nog dataverlies hebt (al is dat risico maar 1%).

Of als je de redenering doortrekt dat je de kleine kansen negeert: de kans op een defecte schijf is maar 1 of 2% per jaar. Als je dus helemaal geen redundantie neemt heb je nog meer ruimte, en de kans op dataverlies is toch maar minimaal. Heck, met die redenering kan je de boel ook in RAID0 gaan zetten voor extra snelheid. Er is toch maar een paar procent kans dat het mis gaat.

Ik wil maar zeggen dat je met redundantie net die kleine kansen wil afdekken dat je server toch data verliest door een defecte harde schijf. Dan wil je meestal dus met een bepaald aantal schijven 100% zekerheid dat er een aantal mag uitvallen, en geen 90% zekerheid of zo.

[Paul]

P5ycho schreef op zaterdag 24 oktober 2020 @ 16:52:
Schijven vervangen doe je het makkelijkst met een externe usb enclosure trouwens.

Zelf gebruik ik 5.25" naar 3.5" hot swap behuizingen, werkt ook erg goed, en je zit native op SATA zonder allemaal kabels en stroomvoorziening naast je computer.

Die zijn redelijk prijzig (al zijn goede USB-behuizingen ook niet bepaald gratis), maar ik was het schroeven beu dus ik had het er voor over.

[P5ycho]

Paul schreef op maandag 26 oktober 2020 @ 09:57:
[...]
Zelf gebruik ik 5.25" naar 3.5" hot swap behuizingen, werkt ook erg goed, en je zit native op SATA zonder allemaal kabels en stroomvoorziening naast je computer.

Die zijn redelijk prijzig (al zijn goede USB-behuizingen ook niet bepaald gratis), maar ik was het schroeven beu dus ik had het er voor over.

Dat werkt handig als je nog een SATA poort over hebt, of een gefaalde drive vervangt. Als je een mobo met 6 poorten in gebruik hebt en een raidZ1/2 array van 6 disks wilt upgraden, dan zul je of tijdelijk parity moeten opgeven of een externe enclosure moeten gebruiken.

Ik doe zelf niet aan hotswap, kan alleen maar stuk gaan. Ik heb wat simpele brackets waarmee 4 2.5" disks in een 5.25 bay passen.

[Paul]

True, als je geen vrije SATA-poorten meer hebt dan moet je iets verzinnen, en dan is USB wel makkelijk idd.

Qua "kan stuk", het is maar een dom ding, er zit geen logica in zo'n bracket. Een SATA-kabel kan ook stuk Ook kan het meer dan "alleen maar stuk gaan", het kan ook blijven werken (en dat doet het 99+% van de tijd) en gemak bieden bij het vervangen van schijven. Ieder moet die beslissing voor zichzelf maken.

[Morphix]

Hoe kan ik het beste een raidz1 opbouwen met disks van verschillende grootte?

Ik heb 1x 4TB en 2x 5TB disks. Na wat zoeken naar partities vs. de hele disk, lijkt het dat aanbevolen wordt om zfs de hele disk te geven (waarom?). Kan ik gewoon

zpool create tank raidz disk4tb disk5tb-1 disk5tb-2

uitvoeren, of moet ik eerst zorgen dat alle disks een partitie hebben van dezelfde (4TB) grootte?

[Paul]

Definieer "het beste"? Het makkelijkste voor jezelf en wat het minste kans op fouten geeft als je schijven moet vervangen is inderdaad de hele schijf opgeven, en accepteren dat je daarbij 2 TB bruto verliest. Je hebt dan 7 TiB bruikbare ruimte. Vervang je de 4 TB schijf door een 5 TB variant dan ga je naar 8.7 TiB bruikbare ruimte (berekend met https://wintelguy.com/zfs-calc.pl ).

Als je wel partities gebruikt dan hou je op beide 5 TB schijven een partitie (of niet-gealloceerde ruimte) over van ~1TB. Wat wil je daar mee doen?

[Morphix]

Dankjewel. Ik heb inderdaad gewoon de hele disks opgegeven. Ik was er niet zeker van of zfs die verschillende groottes goed zou afhandelen. Ik wilde niet met een zpool eindigen met meer dan ±8TB, waarbij data in de praktijk niet redundant zou worden opgeslagen.

Dat gaat gelukkig gewoon goed

[FireDrunk]

Je zou in theorie 3 * 4TB partities in RAIDZ1 en 2 * 1TB partities in een mirror kunnen zetten.
Nadeel is dat als je ze tegelijk gebruikt, de performance abominabel is. ( Je moet ze dus ook nooit samen in 1 pool zetten)

Qua redundancy is dat prima.

[ Voor 11% gewijzigd door FireDrunk op 29-10-2020 13:10 ]

[Morphix]

Heh, goede suggestie voor als je inderdaad echt alle ruimte nodig hebt. Die ene TB ga ik voorlopig niet missen en ik heb liever een non-frankenstein systeem

[FireDrunk]

Altijd een verstandige keuze

[Mr.Sun]

Hey all.. nieuw in dit forum.

Dit is een vraag over hoe je in FreeNAS/ZFS de queuedepth in kan stellen (kan beperken).


Heb obv FreeNAS een NAS opgezet tbv grote collectie audiofiles (2-3 mio).
1e NAS... en ook nieuw met FreeNAS/ZFS.
Prachtig project. Mooie uitdaging om een NAS op te zetten waarmee je redelijk vlot door deze massa audio-files moet kunnen 'ploegen' ... (ik werk via een direct (via 10Gb lijn) gekoppelde PC aan het samenstellen en opschonen etc van de collectie; files en folders 'in alle hoeken' worden gelezen en geschreven en geherschreven etc....).

Heb de transferspeed, het lezen/schrijven van files/folders ondertussen wel goed in orde (ca 500MB/s maar gaat naar ca 750MB/s).
Maar het 'tags lezen' gaat nog erg langzaam. (denk 30 tags per sec)(bij 2 VDEVs).
De 'tags' bestaat dus uit de standaard file-info (filenaam, etc) maar ook inhoudinfo als 'artiestnaam' etc.

Ik merk dat de standaard file-info's wél in de ZFS-metadata zitten (die komen dus in ARC en lezen/schrijven erg vlot).
Maar het overige deel ('artiestnaam' etc) zit niet de metadata vlgns mij. En die moeten dus vanuit de diskpool gelezen/geschreven.

Die 'tagdata' staat dus op het 1e block van de file. En dan volgen er nog zeg 20 blocks van die zelfde file, daarna komt de volgende file, het volgende tags-block dat gelezen moet worden.
Dit tags lezen/schrijven gaat dus volgens mij hierdoor altijd 'random' (de blocks sluiten nooit aan).

Dus elke read/write krijgt de volle latency.
En die latency is erg hoog (60-70ms) bij hoge queuedepths.
Ik ken de tabellen met de QD/latency en QD/IOPS-waardes.

Dus... mijn opzet was om de queuedepth te beperken.
En dan een optimum op te zoeken waarbij de file-transfer nog steeds goede speed houd maar dit tags lezen ook wat vlotter gaat.

De Tunables die ik daarvoor gevonden heb, die doen echter niks (werken niet of ik doe iets verkeerd of er is nog iets anders dat de speed fiks belemmert....).

Ik heb sync op disabled dus alleen maar async writes/reads.
Dus ik heb in de Tunables op mijn systeem opgenomen (als een ‘sysctl’):
- vfs.zfs.vdev_async_write_max_active (10)
- vfs.zfs.vdev_async_read_max_active (3).
Maar ik krijg de indruk dat deze tunable niks doet; dat het systeem altijd naar max queuedepth van 32 gaat (met bijhorende hoge latency).
Als ik die queuedepth hier verander naar 1 of naar 32 is er geen enkel verschil in de r/w snelheid (ik check dat door een aantal testfolders in te lezen en te timen (nadat NAS en werkstation steeds zijn gereboot).

Als ik met camcontrol kijk (per disk) naar wat de ‘maxtags’ zijn dan staat deze op ‘255’ (bij welke instelling van max_active dan ook).
Dat is dus de default instelling, die 255.
(Ik check dat via de shell met: ‘camcontrol maxtags daX –v’)

Ik heb ook 2 SSD's nu nog direct op de moederbord sata-poortjes en deze hebben magtags32.

Ik vermoed dat de disk-controller (lsi 9217-8i / 2308) die max 255 toewijst aan de disks.
(ik vermoed dat er een max van 600 geldt voor de controller-totaal en 255 per disk).

Dus.... vraag:

1)
Hoe stel je normaliter de max queue-depth in op FreeNAS/ZFS?

2)
Is dat camcontrol command de aangewezen methode om de queue-depth te checken of is er een betere manier?

Hieronder uiteraard de systeem-info.
(systeem is nog niet definitief maar in testfase; draait nog enkel met testdata erop)

Alvast dank!

Gerard


Systeem-info:

FreeNAS v 12
SuperMicro X8DTL-iF
Dual Intel Xeon X5670 CPU's (3Ghz - 6c/12t)
4x 8GB ECC-RAM

IT-flashed LSI 9217-8i/2308 disk-controller (komt een 16poorts voor)
DiskPool van 2x 4x 8TB WD-Red hard-disks (2x Z2-VDEV) (gaat naar 2x 6 disks)
2x 120GB SSD (tbv metadata-VDEV)
NIC: 10Gb Emulex dual-port SFP+

Werkstation obv Windows, via SFP-kabel/10Gb met NAS verbonden.

Data-sets instellingen:
Dedup off
Compression on
Atime on
Prefetch on
Blocksize 1MB (meeste files ca 10MB danwel ca 35MB)
(tagdata-size ca 100kB)

[ocaj]

Queue-depth weet ik niet, maar hoe groot heb je de ARC-cache ingesteld? Als je die machine alleen als NAS gebruikt kun je de max-ARC grootte denk ik wel richting de 30GB instellen.

je kunt dit instellen met de tunable: zfs_arc_max

En middels arc_summary kun je controleren of de ARC-cache al vol zit met zoveel bestanden. Je kunt daar ook de verhouding tussen metadata en echte data bekijken.

O, en stating-the-obvious: je doet je meting wel meer dan 1 keer? De 1e keer is altijd trager omdat je cache dan nog niet vol is.
Wat ik trouwens niet weet is hoe snel het ARC-algoritme weet wat de "most-frequently-used" files zijn. Je meet (heel netjes en reproduceerbaar) na een reboot. Nou doe ik zelden reboots, maar mijn ARC hit-rate zit wel altijd >99%.

Zeker als jij vaak die tags opnieuw scant zou hij dat m.i. zo door moeten hebben dat hij die informatie moet cachen.

Mocht je cache vol zitten bij jouw hoeveelheid bestanden en typisch gebruik, dan kun je 2 dingen:
- meer RAM plaatsen
- L2ARC op een SSD bijplaatsen

Nog een laatste idee:
Volgens mij cached de ARC blocken en geen schijf-sectoren. Aangezien jij een hele grote block-size heb ingesteld (1MB) zit misschien je cache daardoor te snel vol? Probeer eens een block-size van 128KB, de default van ZFS die eigenlijk bijna altijd een prima gulden middenweg is.

[P5ycho]

ZFS moet zijn ARC cache na elke reboot opnieuw opbouwen, dus je benchmarks zijn misschien niet representatief met je gebruiksscenario. Je test steeds met een lege ARC. Alle info, ook de metadata, moet de eerste keer van disk komen. Als je dezelfde run 2x doet is de performance al een stuk beter waarschijnlijk.
Ook de 1MB blocksize nekt je hier een beetje denk ik, cachen gaat per block namelijk.
Er zijn geen easy workarounds voor helaas, aangezien ZFS nu eenmaal geen glazen bol ingebouwd heeft.

Voor opslag was die 1MB blocksize prima, maar voor (herhaaldelijk) bewerken is dat helemaal niet zo gunstig helaas. Nu lijkt het me dat je het taggen en opschonen van je id3 data maar 1x doet, dus zo kritisch is het nu ook weer niet misschien?

[FireDrunk]

@Mr.Sun Waarom denk je dat het instellen van een max queue depth helpt in performance?

Je zegt feitelijk: Er mogen niet meer dan x requests klaar staan in de rij.
Als er dan toch een request bij komt, zal dat gaan hangen in de applicatie die de aanvraag doet (in dit geval gok ik NFS of Samba?), en zal de IO daar hangen tot de applicatie een timeout geeft.

Wil je dat gedrag?

Wat ik zo lees, is dat je graag wil dat er meer specifieke data gecached wordt, namelijk meer specifieke file info? Het lastige is dat ZFS ARC opdeelt in 50% MFU (Most Frequently Used) en 50% MRU (Most Recently Used).

Die verhouding kan je tunen, en kan in jouw geval helpen. Lastige is alleen, dat ZFS het verschil niet kan zien tussen de daadwerkelijke file data, en de 'headers' in de file, waar de tags in staan, waar jij het over hebt.

ZFS cached gewoon wat er opgevraagd wordt. Als jij dus 4x de inhoud van een muziek file opvraagt, en daarna 1 keer de metadata, zal ZFS nog steeds de inhoud van de file 'belangrijker' vinden, dan die headers.

Je kan niet zomaar 'sturen' op wat er wel en niet gecached wordt, omdat *jij* weet wat er nuttiger is om te cachen. ZFS heeft dat inzicht namelijk niet. Die ziet gewoon "IO" langs komen. (Uitzondering is metadata vs file inhoud, dat verschil weet ZFS wel).

Je kan proberen om de verhouding van MRU/MFU bijvoorbeeld op 25/75 te zetten. Dan is je ARC minder gevuld met recente data, maar meer met veelvuldig opgevraagde data. Als je dan een flink aantal runs doet om de tags uit te lezen, zullen die vanzelf sneller worden.

[ Voor 4% gewijzigd door FireDrunk op 14-11-2020 14:42 ]

[Mr.Sun]

Bedankt voor de reactie ocaj.
In de standaard situaties helpen deze manieren van instellen en werken inderdaad goed, maar er is bij het gebruik van deze NAS/deze collectie geen 'pakket van veelgebruikte data' dus file-caching en gebruik van ARC hiervoor helpt hier dus niets.

Er moet hier dus 'gewoon ff' de max queue-depth ingesteld, en dat is ook wel een bekend iets, maar mij lukt dat nog niet. Dus daar heb ik ff hulp bij nodig.

..................................

Ik had dit nog wat duidelijker kunnen aangeven maar je moet ervan uitgaan dat er dus "in alle hoeken steeds andere files en folders gelezen en herschreven worden" (het gebruik van de collectie kenmerkt zich erdoor dat enerzijds alle files/folders steeds benaderd worden tijdens het constant kruisvergelijken en 'beste selecteren' en 'beste verbeteren'; daarnaast zal ook het raadplegen/downloaden vooral gericht zijn op 'het ontdekken van het nieuwe en bijzondere").

In de standaard, voor FreeNAS/ZFS makkelijke situatie, wordt er in wezen een 'grote RAM-disk' gevormd waarop de files staan waarmee gewerkt wordt; de diskpool is in feite 'dood' (bevat de niet gebruikte files).
In die makkelijke situatie zijn er niet veel eisen aan de performance van de diskpool.

In de situatie van dit project moeten we het hebben van de performance van de diskpool.
Dat is ook wel goed te doen, want de files zijn relatief groot (ca 10MB resp 35MB meestal) dus je kan met grote blocks werken, kunt sequencing in de hand werken etc etc.
Ik kom dus wel op 500MB/s nu al voor het normale files lezen/schrijven (en denk ca 750MB/s te halen).

Maar het 'tags lezen' gaat dus nog bijzonder traag.
Dat komt dus doordat dit per definitie 'random read/write' is, dus de volle latency valt op elke read/write.
En die latency is (altijd) erg hoog bij hoge queue-depths (60-70ms bij QD32)(vs 3ms bij QD1).

Dus.... de max queue-depth moet 'alleen ff' ingesteld.
Zodat er een optimalisatie kan komen tussen de speed bij (random) alleen-tags lezen/schrijven en bij (sequentieel) hele-files lezen/schrijven.

Dit gedrag van hoge latency bij hoge QD en het max queue-depth instellen is dus ook wel een bekend iets zie ik in diverse forums/threads. En die Tunables die ik noemde (... "max_active") staan ook in de ZFS tuningguide.
Maar zoals gezegd, als ik deze instel, zie ik niks veranderen qua gemeten speed. En ik zie ook niks veranderen als ik naar de 'maxtags' instelling op de disks kijk (met dat 'camcontrol maxtags' command).

Dus... ik snap het ff niet...

Ik denk dat andere (FreeNAS/ZFS gebruikende/kennende) forumleden dit wel weten?

[Mr.Sun]

Dus... ff kort:

Wie kan er svp aangeven hoe je de max queue-depth (QD) instelt op FreeNAS/ZFS?

[Mr.Sun]

Ah... ik had de reacties van P5ycho en Firedrunk nog niet gezien.
In mijn vorige reactie staat al wel grotendeels de toelichting.
Maar ik zal nog ff op de gegeven reacties ingaan.

[FireDrunk]

Dat de latency oploopt met een hoge QD is gewoon logisch gedrag, en heeft niets te maken met de *max* queue depth.

De queue depth verlagen in dit geval gaat je echt niet helpen. Als er minder queue depth is, wil dat niet op magische wijze zeggen, dat FreeNAS die requests sneller kan afhandelen.

Queue depth verlagen wil gewoon zeggen, ik wil dat er geen wachtrij is.

Als er dan *toch* requests worden aangeboden, gaan die gewoon dood...

Het gedrag wat je ziet bij lage vs hoge queue depth komt gewoon door de seek snelheid van je schijven, en is gewoon verwacht gedrag.

[Mr.Sun]

ARC-gebruik::
ARC/file-caching heeft dus geen (noemenswaardige) functie hier.
(de 'hits-ratio' zal ws onder 5% zitten ofzo).

Wel staat prefetch nog aan en wordt de ARC dus daartoe wel gebruikt.
(ik zie een beperkte verbetering bij de testruns bij prefetch aan (+10%).


Blocksize:
Ik zie geen verschillen in speed bij tags lezen/schrijven tussen blocks van 1MB of van 256kB.

(dat is uiteraard vreemd want bij grote blocks wordt er uiteraard meer gelezen/geschreven en verhoogt de lees/schrijftijd (zeker als prefetch aan staat).
(maar ik vermoed dat de snelheid zo 'gedrowned' wordt door enorme latency dat je die extra lees/schrijftijd niet merkt)

[Mr.Sun]

#firedrunk:

Hoor wat je zegt.

Idealiter zou ik sec de tagdata uiteraard op snellere drager willen hebben staan.
Heb daarvoor wel ideeen maar weet niet hoe makkelijk dat te realiseren is.

Dus ik dacht: eerst ff zien dat ik de diskpool optimaliseer.

Hoe kan ik testen wat er gebeurt bij een ingestelde max queuedepth?
Dus: hoe moet dat, max queue-depth instellen?

[Mr.Sun]

Hier vind je de informatie mbt de performance van de door mij gebruikte hard disks, mbt IOPS bij diverse queue-depths en latency bij diverse queue-depths:

https://www.tweaktown.com...a,of%2023.9ms%20at%20QD32.

[Mr.Sun]

Mijn inschatting is (maar schiet er vooral op, ik ben nieuw hierin..) dat er een optimaal punt is waarbij je de queue-depth bijv beperkt tot 8.
Daarbij is er dan nog voldoende IOPS-capaciteit (m.n. relevant voor dat puur random tags lezen/schrijven) en is ook de beperking agv hoge latency minder (zodat het effectieve, resulterende aantal reads/writes dat de diskpool kan doen, de maximale hoogte haalt).

Maar geef maar aan of ik op de juiste manier denk.

All comments welkom en waardevol.

[FireDrunk]

Mr.Sun schreef op zaterdag 14 november 2020 @ 16:34:
Mijn inschatting is (maar schiet er vooral op, ik ben nieuw hierin..) dat er een optimaal punt is waarbij je de queue-depth bijv beperkt tot 8.
Daarbij is er dan nog voldoende IOPS-capaciteit (m.n. relevant voor dat puur random tags lezen/schrijven) en is ook de beperking agv hoge latency minder (zodat het effectieve, resulterende aantal reads/writes dat de diskpool kan doen, de maximale hoogte haalt).

Maar geef maar aan of ik op de juiste manier denk.

All comments welkom en waardevol.

Ik kan het volgens mij niet harder zeggen, maar het antwoord is eigenlijk gewoon: Nee.
De Queue Depth limiteren heeft *nooit* zin...

Er gebeurt niets... Alles wat de queue niet in kan, gaat ofwel in andere queues (OS vs Device Queues), of gaat stuk.

Het gedrag van je disks veranderd *niet*.

Grotere queues zijn juist goed, daardoor kan er meer parrallelisatie gebeuren.
NVMe heeft bijvoorbeeld 64K queues met elk 64K requests. Dat zijn in totaal 4 *miljard* IO's in de queue.

Als queue depth beperken zin had, hadden ze het daar wel gedaan

Het enige wat je kan doen, is het aantal IO's wat je in een ZFS Transactie stopt verlagen. Dat zorgt er voor dat ZFS minder lang wacht met het 'verzamelen' van requests, waardoor heel soms je IO latency iets verbeterd, maar over het algemeen kan ZFS dat prima zelf regelen.

https://zfsonlinux.org/ma...-module-parameters.5.html
De setting: zfs_vdev_max_active
Maar wees dubbel gewaarschuwd, hiermee kloten gaat je waarschijnlijk meer kopzorgen geven dan plezier.

[ Voor 17% gewijzigd door FireDrunk op 14-11-2020 16:42 ]

[Mr.Sun]

Ja, die 'vdev_max_active' kende ik ook al wel.
Zie de 1e text van deze thread: daarin noem ik de 'onderliggende varianten' op deze 'overkoepelende' vdev_max_active (die hetzelfde doen maar gericht op max async writes cq max async reads).

En ik heb ook al wel getest met die 'vdev_max_active'.
Maar... (je voelt'm wel aankomen...) ook daar geen enkel verschil te zien in de read-speed of write-speed.

Wat ik in ieder geval op dit moment konkludeer/leer (dank u) is:
1)
Het gaat niet om het 'queue-depth' veranderen/anders instellen, maar om het aanpassen van de IO-stroom (zodat als gevolg daarvan de diskpool (wellicht) niet op al te hoge QD komt en (wellicht) betere snelheden geeft).
2)
Die 'max_active' tunables veranderen 'dus' ook niks aan de QD-instelling. Het klopt dat de 'maxtags' gewoon op 255 blijft staan.

Plezierig dat er wat logica komt.

Maar bij de testen tot nu toe, met het instellen van beperkende waardes voor die 'max_active' tunables, merk ik tot nu toe nog geen enkel verschil. Speed blijft dus erg laag (ca 30 tags per sec).

Ik kan het dus ook uitrekenen/verklaren, en kom dan op de conclusie dat er steeds op QD32 gewerkt wordt:
(ook al stel ik de max_active in op bijv 4):

- de (read) latency is dan ca 55ms
- + de readtime ca 15ms (ivm prefetch 3 blocks van 1MB)
- total 70ms => 1000/70 = 14 reads
- x 2VDEVs => 28 (is ca 30 reads).

Dus daarom vermoed ik dat het systeem steeds op die max QD van 32 draait.

Hoe/met welke instelling van die max_active zouden we wél een verschil moeten kunnen zien?
(ik weet niet meer of ik ook "1" heb getest, maar dat zou toch zeker moeten leiden tot lagere QD?).
(of in ieder geval te merken moeten zijn in de read-speed?).

[Mr.Sun]

Info nog mbt de IOPS die het systeem laat zien (in de Reporting in de GUI):

Bij hele-files (ca 10-35MB; blocks 1MB)
- lezen 500 IOPS per disk (ik denk: voor 2 VDEVs x2 = 1000)
- schrijven 1200 IOPS per disk (ik denk: voor 2 VDEVs x2 = 2400)

Bij tags (ca 100kB: blocks 1MB)
- lezen 50 IOPS (yup..) per disk (ik denk: voor 2 VDEVs x2 = 100 IOPS)
- schrijven weet ik ff niet precies maar was ook erg laag.

Dus extreem veel lagere IOPS bij het tags lezen.

[ocaj]

@Mr.Sun Het lijkt er dus op dat je een echt random lees/schrijf-gedrag hebt? Je schrijft dat de hit-rate "waarschijnlijk" 5% is, maar heb je de hit-rates al bekeken middels arc_summary? Ook nadat je de ARC de gelegenheid hebt gegeven om zich wat te vullen (draai je benchmark/test-scripts bijvoorbeeld eerst 10 keer na een reboot) En heb je inderdaad al je geheugen aan ARC toegekend?

Ik kan het me moeilijk voorstellen, meestal is er best veel te cachen. Als het echt random is, dan helpt er uiteraard geen enkele caching-strategie en zul je de focus puur moeten leggen op de maximale IO-performance.

Je schrijft dat je 2 VDEVS hebt met 4 schijven in RaidZ2. Misschien zou je eens kunnen proberen om meer vdevs te maken door steeds 2 schijven als mirror te gebruiken. Dan krijg je 4 Vdevs met elk 2 schijven. Mogelijk presteert ZFS daar beter mee als je intensieve IO hebt? ZFS verdeelt normaal gesproken alle data gelijkmatig over alle VDEVs. Als het echte random IO is dan vergroot dat in theorie de kans dat de VDEV niet bezig is met iets anders.

[Mr.Sun]

Tx allen voor de input van vandaag. Zojuist nog een serie van testen gedaan.

Ik komt er morgen op terug.

Nu eerst ff een biertje... ;-)
(je krijgt wel dorst van die blazende fans...)

[Mr.Sun]

OK, ik ga eerst ff in nog op de opmerkingen van Ocaj mbt de pooldata en het gebruiksgedrag + het tags r/w -edrag.
In het volgende blokje op de ideeen/mogelijkheden om dat tags lezen/schrijven wat vlotter te krijgen.

Pooldata en gebruiksgedrag:

"Meestal doet de cache het toch wel goed etc". Ja, van wat ik weet is de ARC/filecache een prima functie van ZFS; in wezen denk ik de bestaansreden voor FreeNAS, want normaliter draait FreeNAS/ZFS alleen maar goed omdat alle bestanden die gebruikt worden dus op de ARC staan (en sneller als vanaf RAM werken gaat niet ... ;-).

Maar hier gaat het dus om ca 40-50TB aan data. Ca 3 mio bestanden.
En het gebruik kenmerkt zich erdoor dat alle (alle) bestanden regelmatig gelezen worden en herschreven bij het constant kruisvergelijken van nieuwe toevoegingen met bestaande collectie etc en daarnaast zijn de opvragingen/downloads ook juist gericht op het 'nieuwe ontdekken'.
Dus de kans dat een file die opgevraagd wordt in de ARC zit is bijzonder klein (ook al zet ik er 5TB aan SSD/L2ARC in (wat ook weer niet optimaal werkt met bijv 512GB aan ARC)... etc etc.
Dus kortweg: zoals ik het zie zal de ARC (file-caching) geen waarde hebben hier.

We moeten het dus hebben van de performance van de diskpool zelf.

- enerzijds vwb hele-files lezen/schrijven: dat loopt dus al wel goed (ca 500 MB/s reads / ca 600 MB/s writes)
- daarnaast vwb het tags lezen/schrijven: dat loopt dus erg traag (ca 30 tags per sec). (dit is echt erg traag: ter vergelijking: dezelfde activiteit met 1 ouwe harddisk gewoon onder Windows doet ca 90 tags per sec...).


Tags r/w-gedrag:

Firedrunk gaf het denk ik ook al wel aan. Maar 'tags' lezen/schrijven is per definitie denk ik altijd "random read cq random write" maw er is nooit sprake van sequentieel read/write.

Reden is dat die 'tagdata' (file-info) altijd in de header van de file staat. En de file bestaat dus uit x blocks (zeg 20 van 1MB in dit project). En de tagdata staat dus op het 1e block.
Als dat gelezen is, moet het systeem eerst doorroteren/verplaatsen naar het volgende block waar weer tagdata op staat.
Dus bij elke read/write heb je die zoektijd/latency.
Die volle latency valt op elke read/write.

Dit in tegenstelling tot de sequential writes/reads, daar wordt er meestal (zover ik nu kan overzien) de blockserie van een hele file in 1 keer/1read/write gedaan. Dus de latency gaat over 10 of 20 blocks (al naar gelang filegrootte en blocksize)(grotere file; grotere blocks; meer MB per read/write).

Prefetch ('read-ahead')

Hier speelt bij het readen ook de 'prefetch' mee. Zover ik nu kan overzien wordt bij file readen steeds 1 extra file meegenomen in dezelfde read. Bij het tags readen zie ik in de testen dat er ca een half MB extra ge-read wordt.
Bij het file readen is dit dus zinvol. Bij het tags readen zinloos (heb het geprobeerd uit te zetten middels de daarvoor bestemde tunable maar het systeem blijft gewoon extra blocks bijlezen (en in ARC zetten..)

[ph0t0nix]

Heb je al eens gekeken naar special devices/allocation classes? Dat houdt in dat je een snel (SSD) vdev aan je RAIDZ vdev toevoegt. Op dat vdev wordt dan de metadata opgeslagen. Dat versnelt waarschijnlijk het lezen van je tags niet, maar wel andere operaties (zoals file listings of

code:

zfs list

operaties).

Daarnaast kun je aangeven dat blocks tot een bepaalde grootte ook op dat vdev terecht moeten komen. Misschien dat dat bij jouw recordsize van 1M nog wat snelheid kan geven door bijvoorbeeld blocks van 32k of zelfs 256k daar op te slaan.
Let wel op de benodigde SSD ruimte als je small blocks op je special device toestaat.

[Mr.Sun]

Dan mbt de ideeen/methodes om dat tags lezen/schrijven wat vlotter te krijgen:

Meer VDEVs

Ja inderdaad krijg je bij elke extra VDEV in de pool extra snelheid (ik denk zelfs dat het 100% doorstapelt; dus 2 VDEVs zijn 2x zo snel als 1 VDEV en 4 VDEVs zijn 2x zo snel als 2 VDEVs etc).
Maar de snelheid die er bij het tags lezen nu uitrolt is dermate laag, dat ik er wel exorbitant veel disks moet inzetten om zo veel VDEVs te kunnen maken dat het nog op een redelijke snelheid uitkomt.
Per VDEV nu dus ca 15 tags/sec (vs 90 tags/sec bij een ouwe harddisk)....

Dus alleen nog maar om de snelheid van een ouwe harddisk te halen zou ik 6 VDEVs moeten bouwen... dus bijv 6 mirrors van 2 disks. 12 disks in de bak... die me dan ook nog maar voor 6 disks aan data-ruimte geven...
(en in realiteit moet het naar zeg 200 tags/sec, dus.... dat zou dan 12 VEDV's/24 disks betekenen...).
Dus dat is te ver van het reeele af: die snelheid van 15 tags/sec is gewoon te laag.
En daar probeer ik dus wat in te verbeteren.

En dat moet (zover ik nu kan overzien) ook wel kunnen. Ik zie dus oa bij het testen extreem lage IOPS-scores, veel lager dan opgegeven voor deze disk bij random reads.

[Mr.Sun]

@ph0t0nix:

Ja, metadata-VDEV zit er al op. Had ik meen ik ook in de 1e beschrijving meegenomen.

Helpt idd goed bij het hele-files lezen/schrijven.
In wezen alleen maar doordat het de IO-load op de diskpool vermindert.
(per read/write zijn er minder IO's).

(small-block-files hebben we in dit projekt niks aan: de audiofiles beginnen van zeg 5MB op z'n kleinst; bij blocksize 1MB valt er niks in de klassen '128kB of kleiner'...).


Voor het tags lezen maakte die 'special class VDEV' ook niks uit.

(maar ik had nog wel ideeen hier; zie latere input...)

[Mr.Sun]

IOPS & Latency van de disks, bij diverse queue-depths

Ik herhaal nog ff de link naar een uitgebreide test waarbij de IOPS en Latency van de disks die ik gebruik in kaart zijn gebracht.
https://www.tweaktown.com...a,of%2023.9ms%20at%20QD32

Ik heb hier al een tijdje op zitten puzzelen, maar die lage snelheid van tags lezen/schrijven moet toch komen van het een of het ander:
- ofwel van te lage IOPS (=capaciteit) > IOPS bij read gaat dus van 170 (QD1) tot 575 (QD32)
- danwel van te hoge latency (=zoektijd/remming) > latency bij read van 7ms (QD1) tot 55ms (QD32).
(ik kijk dus naar '4k random read')

In de testen die ik doe zie ik constant:
- bij hele-files lezen: 500 IOPS
- bij tags lezen: 45 IOPS.

Mijn 1e indruk was/is dus dat de trage snelheid veroorzaakt wordt door de hoge latency.
Wanneer je de latency neemt van QD32 (55ms) en daar een beetje read-time bij optelt (8ms), dan kom je wel op die ca 15 tags/sec (1000ms/63ms=15).

Maar je ziet dus in de testgrafieken wel dat bijv bij QD4 er veeel lagere latency is, en nog steeds een redelijke IOPS-capaciteit. Dus vandaar dat ik deze 'thread' begon met de vraag "hoe kunnen we de queue-depth controleren/maximeren".

[Mr.Sun]

Controleren/beheersen van de queue-depth

Firedrunk heeft hier ook al wat input op gegeven. Ook die ene Tunable gestuurd.
Er is dus een set met 'max_active' tunables, waarmee je de IO-stroom kunt beinvloeden.
Dit zou dus in theorie de queue-depth moeten beinvloeden/bepalen.

Dit is de hele set aan Tunables uit die groep:


Ik heb dus sync op disabled, dus alleen maar async reads/writes.

In die set met Tunables zie ik dus:
- 'max' types: voor het maximeren van een stroomhoeveelheid
- 'min' types: voor het aangeven van een minimum stroomhoeveelheid

Ik heb ondertussen diverse testen gedaan.
Met:
- read-max-active (staat default op 3: getest op 1, 2, 10, 32)
- vdev-max-active (staat default op 1000; ook getest op 1, 2, 10 en 32).
Conclusie: maakt in het geheel geen verschil (exact dezelfde snelheden)(elke keer ge-reboot ;-(

Dus: die max instellingen doen (in dit systeem) helemaal niets op de snelheden.
(gewoon FreeNAS versie 12 met geen bijzonderheden; zie 1e input voor instellingen).

Vervolgens ook nog geprobeerd of 'de wereld misschien helemaal andersom is'..... ook de min_actives uitgeprobeerd.
Ook dit maakte geen enkel verschil.

[Thralas]

Maar je ziet dus in de testgrafieken wel dat bijv bij QD4 er veeel lagere latency is, en nog steeds een redelijke IOPS-capaciteit. Dus vandaar dat ik deze 'thread' begon met de vraag "hoe kunnen we de queue-depth controleren/maximeren".

Volgens mij snap je de grafieken niet.

Als een queue niet zo diep is dan kan een HDD het nog wel bijbenen met z'n trage seeks. Wordt de queue iets dieper dan zullen requests langer in de queue spenderen: de average latency gaat dan omhoog.

Je zoekacties vragen véél meer IOPS dan je (trage) schijven kunnen leveren. Wil je meer IOPS, dan is er maar één goed antwoord: SSDs. NVMe levert meer IOPS dan je raad mee weet.

Nu is het vervelende dat die special vdev je probleem niet magisch voor je oplost omdat het alleen gehele (kleine) files daarop zal alloceren. Wat jij eigenlijk nodig hebt is enkel het eerste of het laatste blok (zodat de media metadata erinzit).

Daar is geen hapklare oplossing voor lijkt me. Je zou op een regenachtige zondagmiddag een FUSE filesystem kunnen schrijven dat alle eerste/laatste chunks in een hele aparte file cachet. Omdat je een special vdev hebt komen die dan vanzelf wel op een SSD terecht.

Ter inspiratie: splitfs (en zo zijn er nog 1000). Dat doet al bijna wat je nodig hebt, maar net niet helemaal.

[Mr.Sun]

Vragen op dit moment


1)
Mijn veronderstelling was (maar schiet maar, ik ben nieuw hierin) dat je bij het opzetten van een ZFS-systeem een optimum kunt zoeken waarbij je (1) voldoende IOPS-capaciteit hebt en (2) niet te hoge latency.

(dit is dan per gebruiksgeval anders want elke set-up heeft eigen IO-verbruik etc).

En door het sturen van IO-stromen kan je dan de Queue-Depth beinvloeden en zodoende dat realiseren.

- Of klopt dit niet?
- Of is er een andere manier om een optimum te vinden?
(score is nu dus 45 IOPS).

2)
Hoe kan je in beeld krijgen wat de werkelijke queue-depth (of 'iodepth') was tijdens gedane runs?
(ik ben zover dat ik weet dat er zoiets bestaat als 'fio' en 'iostat' maar weet niet hoe deze te gebruiken).

Bij voorbaat dank voor de input.

[FireDrunk]

@Mr.Sun Toffe usecase dit. Leuk dat je dit met ons deelt! Leuk om te lezen hoe diep je er in duikt.

Paar dingen:
Die readahead die je ziet komt waarschijnlijk van ofwel de vdev readahead, ofwel de fysieke disk readahead. Maar die veel lager zetten heeft weinig zin waarschijnlijk.
De moeite die het een schijf kost om 128k te lezen ipv 16k is echt minimaal (<1ms). De track zelf opzoeken kost zoals je zelf al zei veel meer tijd.

Waar ik erg beniewd naar ben is hoe je aan doe 575 iops komt als je zelf test. Ik verwacht namelijk dat een benchmark altijd te rooskleurige getallen zal geven omdat de test area te klein is. Veel benchmarks gebruiken een gebied van hooguit een paar GB om random reads te testen. Op een complete vdev is 8GB dicht bij elkaar en is de track-to-track latency een stuk lager dan op een hele pool.

Je kan eens een benchmark proberen die raw devices snapt en een read latenty benchmark doen met een 'size' van meerdere TB, dan ga je denk ik veel lagere IOPS zien.

575 voor een single vdev disk pool is denk ik zelfs aan de hoge kant.
Als je echt meer performance wil, zal je naar mirrors of zelfs single disk vdevs moeten gaan, en goede backups maken ipv op RAIDZ vertrouwen.

[Mr.Sun]

@Thralas

Correct me if I'm wrong:

Jij geeft in wezen dus aan:
wanneer er een (beetje meer dan beperkte) sequence aan (read/write) requests op een harddisk komt, schiet deze gelijk naar maximale queue-depth (want hij kan het niet bijbenen) en dus heb je dan direct te maken met hoge latency.

(het gaat in wezen niet om de IOPS-capaciteit (deze gaat van 170 bij QD1 tot 575 bij QD32 zoals je ziet) maar dit wordt overruled door de hoge latency (deze maakt dat er simpelweg heel beperkte tijd overblijft per seconde om IO te doen).

Check?