Het grote ZFS topic

[HyperBart]

code:

pool: stavanger
 state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
        repaired.
  scan: scrub repaired 0B in 18h51m with 0 errors on Mon Mar 16 20:51:52 2020
config:

        NAME                 STATE     READ WRITE CKSUM
        stavanger            DEGRADED     0     0     0
          raidz2-0           DEGRADED     0     0     0
            disk1-XXXXXXXXX   ONLINE       0     0     0
            disk2-XXXXXXXXX   ONLINE       0     0     0
            disk3-XXXXXXXXX   ONLINE       0     0     0
            disk4-XXXXXXXXX   ONLINE       0     0     0
            disk5-XXXXXXXXX   FAULTED      0     0     2  too many errors
            disk6-XXXXXXXXX   ONLINE       0     0     0
            disk7-XXXXXXXXX   ONLINE       0     0     0
            disk8-XXXXXXXXX   ONLINE       0     0     0
            disk9-XXXXXXXXX   ONLINE       0     0     0
            disk10-XXXXXXXXX   ONLINE       0     0     0

-------------------------------------------------------------------------------------------------------------------
| Dev   | Model                     | Serial Number   | GB   | Firmware | Temp | Hours | PS   | RS    | RSE | CRC |
-------------------------------------------------------------------------------------------------------------------
| loop1 |                           |                 | 0    |          | ?    | ?     | ?    | ?     | ?   | ?   |
| loop2 |                           |                 | 0    |          | ?    | ?     | ?    | ?     | ?   | ?   |
| sda   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 42   | 54547 | 0    | 0     | ?   | 0   |
| sdb   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 47   | 54555 | 0    | 0     | ?   | 0   |
| sdc   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 46   | 54551 | 0    | 0     | ?   | 0   |
| sdd   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 43   | 54543 | 0    | 0     | ?   | 0   |
| sde   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 45   | 44762 | 0    | 0     | ?   | 0   |
| sdf   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 41   | 45680 | 0    | 0     | ?   | 0   |
| sdg   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 46   | 45676 | 0    | 0     | ?   | 0   |
| sdh   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 42   | 45677 | 0    | 0     | ?   | 0   |
| sdi   | Samsung SSD 840 EVO 500GB | XXXXXXXXXXXXXXX | 500  | EXT0AB0Q | ?    | 81737 | ?    | 0     | ?   | ?   |
| sdj   | Samsung SSD 840 EVO 250GB | XXXXXXXXXXXXXXX | 250  | EXT0AB0Q | ?    | 84478 | ?    | 3     | ?   | ?   |
| sdk   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 49   | 45676 | 0    | 0     | ?   | 0   |
| sdl   | ST4000DM000-1F2168        | XXXXXXXX        | 4000 | CC52     | 47   | 54540 | 2616 | 28440 | ?   | 0   |
-------------------------------------------------------------------------------------------------------------------

Maar, ZFS . Ik denk dat ik 'm seffens ga clearen, zolang hij nog beperkt mee doet en kan bijdragen wat ie kan is het beter dan een volledig device offline hebben lijkt me. Spare is al besteld via V&A.

[ Voor 49% gewijzigd door HyperBart op 20-03-2020 21:45 ]

[CurlyMo]

@HyperBart toch altijd weer fijn om te weten dat je met ZFS tenminste op de hoogte bent

[HyperBart]

CurlyMo schreef op vrijdag 20 maart 2020 @ 21:45:
@HyperBart toch altijd weer fijn om te weten dat je met ZFS tenminste op de hoogte bent

Yes. Alleen is het nu per toeval dat ik het zie, ik heb er (nog geen) monitoring op actief.

In mijn vorige build (ik heb recent wat geupgraded, paar posts terug in zuinige server topic) had ik periodieke smart logging (alles van smartctl naar een SSD dumpen en nog wat stats zoals dat van Louwrentius/@Q ) maar met die nieuwe build had ik dat nog niet aanstaan, jammer want dan had ik even kunnen nakijken sinds wanneer dit probleem zich stelde... Nu ja, "op tijd" er bij...

[CurlyMo]

HyperBart schreef op vrijdag 20 maart 2020 @ 21:48:
[...]

Yes. Alleen is het nu per toeval dat ik het zie, ik heb er (nog geen) monitoring op actief.

[HyperBart]

Nuance: ik log "regelmatig" aan op mijn machine en loop dan de pools even na.

In dit geval:

code:

Feb 24 2020 16:31:26.581530150 resource.fs.zfs.statechange
        version = 0x0
        class = "resource.fs.zfs.statechange"
        pool = "stavanger"
        pool_guid = 0xcaa1e4ce01ce1319
        pool_state = 0x0
        pool_context = 0x0
        vdev_guid = 0x8f09963dd9279822
        vdev_state = "FAULTED" (0x5)
        vdev_path = "/dev/disk/by-partlabel/disk5-Z300TQ64"
        vdev_laststate = "ONLINE" (0x7)
        time = 0x5e53fa5e 0x22a97226
        eid = 0x34

Maarreh, je hebt gelijk ja. Slecht... Het is blijkbaar al een kleine maand zo...

[ Voor 6% gewijzigd door HyperBart op 20-03-2020 22:00 ]

[nero355]

HyperBart schreef op vrijdag 20 maart 2020 @ 21:14:
ST4000DM000-1F2168

Jij houdt wel van een gokje of niet ?!

Dat zijn nou echt disks die ik z.s.m. preventief zou vervangen of gewoon een nieuwe array ernaast zou bouwen en dan alles overzetten!

[HyperBart]

nero355 schreef op vrijdag 20 maart 2020 @ 23:35:
[...]

Jij houdt wel van een gokje of niet ?!

Dat zijn nou echt disks die ik z.s.m. preventief zou vervangen of gewoon een nieuwe array ernaast zou bouwen en dan alles overzetten!

Wekelijkse scrub en dat ging eigenlijk al die tijd prima? Af en toe ging ik eens kijken hoe het met de PS en RS zat en dat zat/zit (zie code) redelijk goed.
Ik weet het niet? Vertel eens, want (klopt even af) tot nu toe hebben ze prima hun werk gedaan maar ik zit inderdaad al een tijdje te tobben over wat ik er mee ga doen.

Ik heb ooit de 2TB broertjes gehad langer geleden in een QNAP (de akelige pre-ZFS tijd) en toen had ik gezworen om nooit meer Seagate te nemen maar indertijd toch overstag gegaan op basis van statistieken van Backblaze (die er nu wat slechter uit zien ) en het feit dat ik op ZFS zat.

Ga ik ze vervangen 1 op 1 door andere disks? Bouw ik er een pool langs en downsize ik wat?
10 x 10TB is een kostelijke grap, meer dan wat ik ooit betaald heb voor disks. Downsizen in # spindles zou kunnen. 30TiB netto zou ik wel graag willen hebben. 6 x 10TB is dan ook een optie en vind ik eigenlijk netjes.

NAME USED AVAIL REFER MOUNTPOINT
stavanger 24.1T 2.61T 238K /stavanger


Trouwens, kan iemand me nog eens uitleggen waar een TB's naar toe is? Ik ben bekend met het verschil van de output in zfs pool en zfs list.

Maar in ZFS list zie ik nu het volgende:

code:

NAME                            USED  AVAIL  REFER  MOUNTPOINT
stavanger                      24.1T  2.61T   238K  /stavanger

4 x 10TB disks minus 2 parity en dat omgezet naar TiB kom ik op 29,10 TiB netto capacity van de disks raw.

Zelfs al tel ik met een overhead van 5% op 29,10 TiB (bron: Google Sheet, zie rij 9) dan kom ik op een overhead van 1.46 TiB. Wat me sterk lijkt want het merendeel zijn echt grote media files, dus dan zou ik record sizes van 1MB verwachten?

24.10 + 2.61 + 1.46 = 28.17. Waar is die laatste TiB naar toe?

[ Voor 64% gewijzigd door HyperBart op 21-03-2020 00:49 ]

[HyperBart]

CurlyMo schreef op vrijdag 20 maart 2020 @ 21:52:
[...]

https://github.com/leovp/telegram_notifications

Net getest en werkt prima

[FireDrunk]

Bah, Telegram. Signal ftw

[HyperBart]

FireDrunk schreef op zaterdag 21 maart 2020 @ 16:57:
Bah, Telegram. Signal ftw

Boeien, de Roskomnadzor mag weten hoe het met mijn server gesteld is

A propos, hoe gaat het met Signal en bots dan?

[Q]

Misbruikt niemand twitter voor notificaties? 🤭

Werkt ook prima 😄

[MartenBE]

Ik heb een riot/matrix gebruiker aangemaakt als bot. Deze pushed notificaties naar een chatroom met mijn eigen account erbij. Works like a charm:

Script:

code:

#!/usr/bin/env python3

from datetime import datetime
import requests
import json
import sys

if __name__ != "__main__":
    raise RuntimeError()

message = sys.stdin.read()
if not message:
    raise RuntimeError()

HOMESERVER = "matrix.org"
ROOM = "!dF...*snip*...VV:matrix.org"
ACCESSTOKEN = "MDA...*snip*...eCg"

print(f"Sending \"{message}\" to room {ROOM}")
print()

url = f"https://{HOMESERVER}/_matrix/client/r0/rooms/{ROOM}/send/m.room.message?access_token={ACCESSTOKEN}"
json_data = json.dumps({
    "body": message,
    "format": "org.matrix.custom.html",
    "formatted_body": f"<pre><code>{message}</code></pre>",
    "msgtype": "m.text"
})

response = requests.post(url, json_data)

print(response.status_code, response.json())

Crontab:

code:

0 3 1 * * /usr/sbin/zpool scrub backup &> /dev/null
0 3 2 * * /usr/sbin/zpool scrub random &> /dev/null
0 3 3 * * /usr/sbin/zpool status | python3 /home/martenbe/sendmatrix.py

Edit: je moet wel een room aanmaken met jou en de bot via het bot-account alvorens dit werkt

[ Voor 3% gewijzigd door MartenBE op 24-03-2020 09:20 ]

[FireDrunk]

Ik ga eens naar Telegram kijken. Het alleen gebruiken voor onschuldige notificaties is natuurlijk prima.
Ik heb al Pushover, maar wil eigenlijk 2-weg verkeer met mijn server op een simpele manier.

[CurlyMo]

FireDrunk schreef op dinsdag 24 maart 2020 @ 11:44:
Ik ga eens naar Telegram kijken. Het alleen gebruiken voor onschuldige notificaties is natuurlijk prima.
Ik heb al Pushover, maar wil eigenlijk 2-weg verkeer met mijn server op een simpele manier.

Wat is de reden dat een vanouds mailtje niet werkt?

2-weg verkeer doe ik door VPN en een SSH app. Kan ik de meest broodnodige dingen altijd doen via de telefoon.

[FireDrunk]

Heb ik ook, maar in Pushover kan je bepaalde categorien classificeren als erg belangrijk.
Handig om dus niet continue gestoord te worden op momenten dat het niet handig is.
Zo kan ik notificaties van Sonar en Radar een lage prio geven, en die van ZFS en SMART een hoge.

[HyperBart]

Resilver is begonnen . Helaas wel een andere merk en type disk moeten aanschaffen, een WD Red 4TB en die kwam gelukkig ook netjes overeen kwam sectors .

  pool: stavanger
 state: ONLINE
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 Tue Mar 24 16:39:50 2020
        120G scanned out of 31.7T at 428M/s, 21h28m to go
        11.4G resilvered, 0.37% done
config:

        NAME                      STATE     READ WRITE CKSUM
        stavanger                 ONLINE       0     0     0
          raidz2-0                ONLINE       0     0     0
            disk1-XXXXXXXX        ONLINE       0     0     0
            disk2-XXXXXXXX        ONLINE       0     0     0
            disk3-XXXXXXXX        ONLINE       0     0     0
            disk4-XXXXXXXX        ONLINE       0     0     0
            replacing-4           ONLINE       0     0     7
              disk5-XXXXXXXX      ONLINE       0     0     0
              disk5-XXXXXXXXXXXX  ONLINE       0     0     0  (resilvering)
            disk6-XXXXXXXX        ONLINE       0     0     0
            disk7-XXXXXXXX        ONLINE       0     0     0
            disk8-XXXXXXXX        ONLINE       0     0     0
            disk9-XXXXXXXX        ONLINE       0     0     0
            disk10-XXXXXXXX       ONLINE       0     0     0

Zelfs nog even een reboot gedaan om tussendoor iets voor de fans na te kijken en ZFS pikt gewoon terug op .

Voor ik de reboot deed was de disk er uit getrapt omdat hij teveel I/O errors gaf, maar na een reboot "zat hij al wat verder in de resilver" waardoor hij nu wel nog mee doet voor wat hij kan.

@nero355 @CurlyMo

[ Voor 3% gewijzigd door HyperBart op 24-03-2020 17:50 ]

[CurlyMo]

Eindelijk zie ik de device removal in de praktijk, omdat ik zelf weer eens te dom was bij het aanmaken van mijn pool:

code:

  pool: media
 state: ONLINE
  scan: none requested
remove: Evacuation of /dev/disk/by-id/usb-Seagate_Expansion_NAARHJ8G-0:0-part1 in progress since Thu Mar 26 13:46:05 2020
    2.36G copied out of 11.1G at 69.1M/s, 21.30% done, 0h2m to go
config:

        NAME                                  STATE     READ WRITE CKSUM
        media                                 ONLINE       0     0     0
          usb-Seagate_Expansion_NAAR6WAX-0:0  ONLINE       0     0     0
          usb-Seagate_Expansion_NAARHJ8G-0:0  ONLINE       0     0     0

Dit had dus een mirror moeten zijn

[HyperBart]

CurlyMo schreef op donderdag 26 maart 2020 @ 13:47:
Eindelijk zie ik de device removal in de praktijk, omdat ik zelf weer eens te dom was bij het aanmaken van mijn pool:

code:

  pool: media
 state: ONLINE
  scan: none requested
remove: Evacuation of /dev/disk/by-id/usb-Seagate_Expansion_NAARHJ8G-0:0-part1 in progress since Thu Mar 26 13:46:05 2020
    2.36G copied out of 11.1G at 69.1M/s, 21.30% done, 0h2m to go
config:

        NAME                                  STATE     READ WRITE CKSUM
        media                                 ONLINE       0     0     0
          usb-Seagate_Expansion_NAAR6WAX-0:0  ONLINE       0     0     0
          usb-Seagate_Expansion_NAARHJ8G-0:0  ONLINE       0     0     0

Dit had dus een mirror moeten zijn

Oh cool, dus als je gewoon een setje disks in ZFS gooit en je wil er één uithalen dan kan hij dat gewoon door een move te doen. Dat wist ik nog niet.

[CurlyMo]

HyperBart schreef op vrijdag 27 maart 2020 @ 19:51:
[...]

Oh cool, dus als je gewoon een setje disks in ZFS gooit en je wil er één uithalen dan kan hij dat gewoon door een move te doen. Dat wist ik nog niet.

Niet in alle configuraties. Bijv. een schijf uit je RAIDZ halen kan niet. Een per ongeluk toegevoegde enkele schijf vdev zoals ik dit geval wel.

[HaTe]

Ik draai nu sinds 2 dagen Proxmox met ZFS. Dat was gisteren helemaal in de soep gelopen, na het kopiëren van data van oude HDD's naar de ZFS pool in de (Xpenology) DSM VM en na het instellen van Timeshift: De hele pool zat 100% vol en niks werkte meer. Proxmox was ook geïnstalleerd op de zpool, welke ik nooit meer aan de praat heb gekregen na een reboot (hele avond verprutst). Grub herkende het filesystem niet meer. Heb Proxmox nu maar even op een USB geïnstalleerd tijdelijk

code:

root@pve:~# zfs get all rpool/data/vm-100-disk-1 | grep used
rpool/data/vm-100-disk-1  used                  9.34T                  -
rpool/data/vm-100-disk-1  usedbysnapshots       0B                     -
rpool/data/vm-100-disk-1  usedbydataset         9.34T                  -
rpool/data/vm-100-disk-1  usedbychildren        0B                     -
rpool/data/vm-100-disk-1  usedbyrefreservation  0B                     -
rpool/data/vm-100-disk-1  logicalused           6.46T                  -

Het issue is hierboven al te zien. Used is veel groter dan logicalused. Nu heb ik al gevonden dat ik dit kan oplossen door trim te gebruiken in de VM. Ik ben nu fstrim aan het uitvoeren maar het gaat nog niet heel snel..

Nu gebruik ik 1 VM voor TVheadend en had de timeshift en opnames op 1 zvol staan. Na een avondje TV kijken was "used" al ver boven de grootte van het volume (600GiB). Trim krijgt denk ik geen tijd om de verwijderde (oude) timeshift data echt vrij te maken. Hoe moet ik dit aanpakken zodat ik straks niet weer een volgelopen zpool heb?

edit:
fstrim is klaar op DSM VM, maar het resultaat is niet helemaal naar wens:

code:

root@pve:~# zfs get all rpool/data/vm-100-disk-1 | grep used
rpool/data/vm-100-disk-1  used                  8.11T                  -
rpool/data/vm-100-disk-1  usedbysnapshots       0B                     -
rpool/data/vm-100-disk-1  usedbydataset         8.11T                  -
rpool/data/vm-100-disk-1  usedbychildren        0B                     -
rpool/data/vm-100-disk-1  usedbyrefreservation  0B                     -
rpool/data/vm-100-disk-1  logicalused           5.61T                  -

De logicalused komt in ieder geval nu wel overeen met wat de VM zelf ook ziet. Hoe krijg ik used nog meer omlaag?

Hieronder mijn config

code:

root@pve:~# zfs get all
NAME                      PROPERTY              VALUE                   SOURCE
rpool                     type                  filesystem              -
rpool                     creation              Wed Apr  1 21:07 2020   -
rpool                     used                  8.11T                   -
rpool                     available             2.12T                   -
rpool                     referenced            151K                    -
rpool                     compressratio         1.00x                   -
rpool                     mounted               yes                     -
rpool                     quota                 none                    default
rpool                     reservation           none                    default
rpool                     recordsize            128K                    default
rpool                     mountpoint            /rpool/ROOT/pve-1       local
rpool                     sharenfs              off                     default
rpool                     checksum              on                      default
rpool                     compression           lz4                     local
rpool                     atime                 off                     local
rpool                     devices               on                      default
rpool                     exec                  on                      default
rpool                     setuid                on                      default
rpool                     readonly              off                     default
rpool                     zoned                 off                     default
rpool                     snapdir               hidden                  default
rpool                     aclinherit            restricted              default
rpool                     createtxg             1                       -
rpool                     canmount              on                      default
rpool                     xattr                 sa                      local
rpool                     copies                1                       default
rpool                     version               5                       -
rpool                     utf8only              off                     -
rpool                     normalization         none                    -
rpool                     casesensitivity       sensitive               -
rpool                     vscan                 off                     default
rpool                     nbmand                off                     default
rpool                     sharesmb              off                     default
rpool                     refquota              none                    default
rpool                     refreservation        none                    default
rpool                     guid                  2907522485319112031     -
rpool                     primarycache          all                     default
rpool                     secondarycache        all                     default
rpool                     usedbysnapshots       0B                      -
rpool                     usedbydataset         151K                    -
rpool                     usedbychildren        8.11T                   -
rpool                     usedbyrefreservation  0B                      -
rpool                     logbias               latency                 default
rpool                     objsetid              54                      -
rpool                     dedup                 off                     default
rpool                     mlslabel              none                    default
rpool                     sync                  disabled                local
rpool                     dnodesize             legacy                  default
rpool                     refcompressratio      1.00x                   -
rpool                     written               151K                    -
rpool                     logicalused           5.62T                   -
rpool                     logicalreferenced     46K                     -
rpool                     volmode               default                 default
rpool                     filesystem_limit      none                    default
rpool                     snapshot_limit        none                    default
rpool                     filesystem_count      none                    default
rpool                     snapshot_count        none                    default
rpool                     snapdev               hidden                  default
rpool                     acltype               off                     default
rpool                     context               none                    default
rpool                     fscontext             none                    default
rpool                     defcontext            none                    default
rpool                     rootcontext           none                    default
rpool                     relatime              off                     default
rpool                     redundant_metadata    most                    local
rpool                     overlay               off                     default
rpool                     encryption            off                     default
rpool                     keylocation           none                    default
rpool                     keyformat             none                    default
rpool                     pbkdf2iters           0                       default
rpool                     special_small_blocks  0                       default
rpool/ROOT                type                  filesystem              -
rpool/ROOT                creation              Mon Apr  6 20:56 2020   -
rpool/ROOT                used                  1.10G                   -
rpool/ROOT                available             2.12T                   -
rpool/ROOT                referenced            140K                    -
rpool/ROOT                compressratio         1.80x                   -
rpool/ROOT                mounted               yes                     -
rpool/ROOT                quota                 none                    default
rpool/ROOT                reservation           none                    default
rpool/ROOT                recordsize            128K                    default
rpool/ROOT                mountpoint            /rpool/ROOT/pve-1/ROOT  inherited from rpool
rpool/ROOT                sharenfs              off                     default
rpool/ROOT                checksum              on                      default
rpool/ROOT                compression           lz4                     inherited from rpool
rpool/ROOT                atime                 off                     inherited from rpool
rpool/ROOT                devices               on                      default
rpool/ROOT                exec                  on                      default
rpool/ROOT                setuid                on                      default
rpool/ROOT                readonly              off                     default
rpool/ROOT                zoned                 off                     default
rpool/ROOT                snapdir               hidden                  default
rpool/ROOT                aclinherit            restricted              default
rpool/ROOT                createtxg             113820                  -
rpool/ROOT                canmount              on                      default
rpool/ROOT                xattr                 sa                      inherited from rpool
rpool/ROOT                copies                1                       default
rpool/ROOT                version               5                       -
rpool/ROOT                utf8only              off                     -
rpool/ROOT                normalization         none                    -
rpool/ROOT                casesensitivity       sensitive               -
rpool/ROOT                vscan                 off                     default
rpool/ROOT                nbmand                off                     default
rpool/ROOT                sharesmb              off                     default
rpool/ROOT                refquota              none                    default
rpool/ROOT                refreservation        none                    default
rpool/ROOT                guid                  7783028782522993004     -
rpool/ROOT                primarycache          all                     default
rpool/ROOT                secondarycache        all                     default
rpool/ROOT                usedbysnapshots       0B                      -
rpool/ROOT                usedbydataset         140K                    -
rpool/ROOT                usedbychildren        1.10G                   -
rpool/ROOT                usedbyrefreservation  0B                      -
rpool/ROOT                logbias               latency                 default
rpool/ROOT                objsetid              883                     -
rpool/ROOT                dedup                 off                     default
rpool/ROOT                mlslabel              none                    default
rpool/ROOT                sync                  disabled                inherited from rpool
rpool/ROOT                dnodesize             legacy                  default
rpool/ROOT                refcompressratio      1.00x                   -
rpool/ROOT                written               0                       -
rpool/ROOT                logicalused           1.72G                   -
rpool/ROOT                logicalreferenced     42K                     -
rpool/ROOT                volmode               default                 default
rpool/ROOT                filesystem_limit      none                    default
rpool/ROOT                snapshot_limit        none                    default
rpool/ROOT                filesystem_count      none                    default
rpool/ROOT                snapshot_count        none                    default
rpool/ROOT                snapdev               hidden                  default
rpool/ROOT                acltype               off                     default
rpool/ROOT                context               none                    default
rpool/ROOT                fscontext             none                    default
rpool/ROOT                defcontext            none                    default
rpool/ROOT                rootcontext           none                    default
rpool/ROOT                relatime              off                     default
rpool/ROOT                redundant_metadata    most                    inherited from rpool
rpool/ROOT                overlay               off                     default
rpool/ROOT                encryption            off                     default
rpool/ROOT                keylocation           none                    default
rpool/ROOT                keyformat             none                    default
rpool/ROOT                pbkdf2iters           0                       default
rpool/ROOT                special_small_blocks  0                       default
rpool/ROOT@move           type                  snapshot                -
rpool/ROOT@move           creation              Sun Apr  5 12:29 2020   -
rpool/ROOT@move           used                  0B                      -
rpool/ROOT@move           referenced            140K                    -
rpool/ROOT@move           compressratio         1.00x                   -
rpool/ROOT@move           devices               on                      default
rpool/ROOT@move           exec                  on                      default
rpool/ROOT@move           setuid                on                      default
rpool/ROOT@move           createtxg             113822                  -
rpool/ROOT@move           xattr                 sa                      inherited from rpool
rpool/ROOT@move           version               5                       -
rpool/ROOT@move           utf8only              off                     -
rpool/ROOT@move           normalization         none                    -
rpool/ROOT@move           casesensitivity       sensitive               -
rpool/ROOT@move           nbmand                off                     default
rpool/ROOT@move           guid                  2509216898743628839     -
rpool/ROOT@move           primarycache          all                     default
rpool/ROOT@move           secondarycache        all                     default
rpool/ROOT@move           defer_destroy         off                     -
rpool/ROOT@move           userrefs              0                       -
rpool/ROOT@move           objsetid              886                     -
rpool/ROOT@move           mlslabel              none                    default
rpool/ROOT@move           refcompressratio      1.00x                   -
rpool/ROOT@move           written               140K                    -
rpool/ROOT@move           clones                                        -
rpool/ROOT@move           logicalreferenced     42K                     -
rpool/ROOT@move           acltype               off                     default
rpool/ROOT@move           context               none                    default
rpool/ROOT@move           fscontext             none                    default
rpool/ROOT@move           defcontext            none                    default
rpool/ROOT@move           rootcontext           none                    default
rpool/ROOT@move           encryption            off                     default
rpool/ROOT/pve-1          type                  filesystem              -
rpool/ROOT/pve-1          creation              Mon Apr  6 20:56 2020   -
rpool/ROOT/pve-1          used                  1.10G                   -
rpool/ROOT/pve-1          available             2.12T                   -
rpool/ROOT/pve-1          referenced            1.05G                   -
rpool/ROOT/pve-1          compressratio         1.80x                   -
rpool/ROOT/pve-1          mounted               yes                     -
rpool/ROOT/pve-1          quota                 none                    default
rpool/ROOT/pve-1          reservation           none                    default
rpool/ROOT/pve-1          recordsize            128K                    default
rpool/ROOT/pve-1          mountpoint            /pve-1                  local
rpool/ROOT/pve-1          sharenfs              off                     default
rpool/ROOT/pve-1          checksum              on                      default
rpool/ROOT/pve-1          compression           lz4                     inherited from rpool
rpool/ROOT/pve-1          atime                 off                     inherited from rpool
rpool/ROOT/pve-1          devices               on                      default
rpool/ROOT/pve-1          exec                  on                      default
rpool/ROOT/pve-1          setuid                on                      default
rpool/ROOT/pve-1          readonly              off                     default
rpool/ROOT/pve-1          zoned                 off                     default
rpool/ROOT/pve-1          snapdir               hidden                  default
rpool/ROOT/pve-1          aclinherit            restricted              default
rpool/ROOT/pve-1          createtxg             113825                  -
rpool/ROOT/pve-1          canmount              on                      default
rpool/ROOT/pve-1          xattr                 sa                      inherited from rpool
rpool/ROOT/pve-1          copies                1                       default
rpool/ROOT/pve-1          version               5                       -
rpool/ROOT/pve-1          utf8only              off                     -
rpool/ROOT/pve-1          normalization         none                    -
rpool/ROOT/pve-1          casesensitivity       sensitive               -
rpool/ROOT/pve-1          vscan                 off                     default
rpool/ROOT/pve-1          nbmand                off                     default
rpool/ROOT/pve-1          sharesmb              off                     default
rpool/ROOT/pve-1          refquota              none                    default
rpool/ROOT/pve-1          refreservation        none                    default
rpool/ROOT/pve-1          guid                  14423282695699430639    -
rpool/ROOT/pve-1          primarycache          all                     default
rpool/ROOT/pve-1          secondarycache        all                     default
rpool/ROOT/pve-1          usedbysnapshots       46.9M                   -
rpool/ROOT/pve-1          usedbydataset         1.05G                   -
rpool/ROOT/pve-1          usedbychildren        0B                      -
rpool/ROOT/pve-1          usedbyrefreservation  0B                      -
rpool/ROOT/pve-1          logbias               latency                 default
rpool/ROOT/pve-1          objsetid              375                     -
rpool/ROOT/pve-1          dedup                 off                     default
rpool/ROOT/pve-1          mlslabel              none                    default
rpool/ROOT/pve-1          sync                  disabled                inherited from rpool
rpool/ROOT/pve-1          dnodesize             legacy                  default
rpool/ROOT/pve-1          refcompressratio      1.83x                   -
rpool/ROOT/pve-1          written               46.8M                   -
rpool/ROOT/pve-1          logicalused           1.72G                   -
rpool/ROOT/pve-1          logicalreferenced     1.67G                   -
rpool/ROOT/pve-1          volmode               default                 default
rpool/ROOT/pve-1          filesystem_limit      none                    default
rpool/ROOT/pve-1          snapshot_limit        none                    default
rpool/ROOT/pve-1          filesystem_count      none                    default
rpool/ROOT/pve-1          snapshot_count        none                    default
rpool/ROOT/pve-1          snapdev               hidden                  default
rpool/ROOT/pve-1          acltype               off                     default
rpool/ROOT/pve-1          context               none                    default
rpool/ROOT/pve-1          fscontext             none                    default
rpool/ROOT/pve-1          defcontext            none                    default
rpool/ROOT/pve-1          rootcontext           none                    default
rpool/ROOT/pve-1          relatime              off                     default
rpool/ROOT/pve-1          redundant_metadata    most                    inherited from rpool
rpool/ROOT/pve-1          overlay               off                     default
rpool/ROOT/pve-1          encryption            off                     default
rpool/ROOT/pve-1          keylocation           none                    default
rpool/ROOT/pve-1          keyformat             none                    default
rpool/ROOT/pve-1          pbkdf2iters           0                       default
rpool/ROOT/pve-1          special_small_blocks  0                       default
rpool/ROOT/pve-1@move     type                  snapshot                -
rpool/ROOT/pve-1@move     creation              Sun Apr  5 12:30 2020   -
rpool/ROOT/pve-1@move     used                  46.9M                   -
rpool/ROOT/pve-1@move     referenced            1.05G                   -
rpool/ROOT/pve-1@move     compressratio         1.83x                   -
rpool/ROOT/pve-1@move     devices               on                      default
rpool/ROOT/pve-1@move     exec                  on                      default
rpool/ROOT/pve-1@move     setuid                on                      default
rpool/ROOT/pve-1@move     createtxg             113848                  -
rpool/ROOT/pve-1@move     xattr                 sa                      inherited from rpool
rpool/ROOT/pve-1@move     version               5                       -
rpool/ROOT/pve-1@move     utf8only              off                     -
rpool/ROOT/pve-1@move     normalization         none                    -
rpool/ROOT/pve-1@move     casesensitivity       sensitive               -
rpool/ROOT/pve-1@move     nbmand                off                     default
rpool/ROOT/pve-1@move     guid                  4218687410806352367     -
rpool/ROOT/pve-1@move     primarycache          all                     default
rpool/ROOT/pve-1@move     secondarycache        all                     default
rpool/ROOT/pve-1@move     defer_destroy         off                     -
rpool/ROOT/pve-1@move     userrefs              0                       -
rpool/ROOT/pve-1@move     objsetid              378                     -
rpool/ROOT/pve-1@move     mlslabel              none                    default
rpool/ROOT/pve-1@move     refcompressratio      1.83x                   -
rpool/ROOT/pve-1@move     written               1.05G                   -
rpool/ROOT/pve-1@move     clones                                        -
rpool/ROOT/pve-1@move     logicalreferenced     1.67G                   -
rpool/ROOT/pve-1@move     acltype               off                     default
rpool/ROOT/pve-1@move     context               none                    default
rpool/ROOT/pve-1@move     fscontext             none                    default
rpool/ROOT/pve-1@move     defcontext            none                    default
rpool/ROOT/pve-1@move     rootcontext           none                    default
rpool/ROOT/pve-1@move     encryption            off                     default
rpool/data                type                  filesystem              -
rpool/data                creation              Wed Apr  1 21:08 2020   -
rpool/data                used                  8.11T                   -
rpool/data                available             2.12T                   -
rpool/data                referenced            140K                    -
rpool/data                compressratio         1.00x                   -
rpool/data                mounted               yes                     -
rpool/data                quota                 none                    default
rpool/data                reservation           none                    default
rpool/data                recordsize            128K                    default
rpool/data                mountpoint            /rpool/ROOT/pve-1/data  inherited from rpool
rpool/data                sharenfs              off                     default
rpool/data                checksum              on                      default
rpool/data                compression           lz4                     inherited from rpool
rpool/data                atime                 off                     inherited from rpool
rpool/data                devices               on                      default
rpool/data                exec                  on                      default
rpool/data                setuid                on                      default
rpool/data                readonly              off                     default
rpool/data                zoned                 off                     default
rpool/data                snapdir               hidden                  default
rpool/data                aclinherit            restricted              default
rpool/data                createtxg             8                       -
rpool/data                canmount              on                      default
rpool/data                xattr                 sa                      inherited from rpool
rpool/data                copies                1                       default
rpool/data                version               5                       -
rpool/data                utf8only              off                     -
rpool/data                normalization         none                    -
rpool/data                casesensitivity       sensitive               -
rpool/data                vscan                 off                     default
rpool/data                nbmand                off                     default
rpool/data                sharesmb              off                     default
rpool/data                refquota              none                    default
rpool/data                refreservation        none                    default
rpool/data                guid                  15199445813322396506    -
rpool/data                primarycache          all                     default
rpool/data                secondarycache        all                     default
rpool/data                usedbysnapshots       0B                      -
rpool/data                usedbydataset         140K                    -
rpool/data                usedbychildren        8.11T                   -
rpool/data                usedbyrefreservation  0B                      -
rpool/data                logbias               latency                 default
rpool/data                objsetid              387                     -
rpool/data                dedup                 off                     default
rpool/data                mlslabel              none                    default
rpool/data                sync                  disabled                local
rpool/data                dnodesize             legacy                  default
rpool/data                refcompressratio      1.00x                   -
rpool/data                written               140K                    -
rpool/data                logicalused           5.61T                   -
rpool/data                logicalreferenced     42K                     -
rpool/data                volmode               default                 default
rpool/data                filesystem_limit      none                    default
rpool/data                snapshot_limit        none                    default
rpool/data                filesystem_count      none                    default
rpool/data                snapshot_count        none                    default
rpool/data                snapdev               hidden                  default
rpool/data                acltype               off                     default
rpool/data                context               none                    default
rpool/data                fscontext             none                    default
rpool/data                defcontext            none                    default
rpool/data                rootcontext           none                    default
rpool/data                relatime              off                     default
rpool/data                redundant_metadata    most                    inherited from rpool
rpool/data                overlay               off                     default
rpool/data                encryption            off                     default
rpool/data                keylocation           none                    default
rpool/data                keyformat             none                    default
rpool/data                pbkdf2iters           0                       default
rpool/data                special_small_blocks  0                       default
rpool/data/vm-100-disk-0  type                  volume                  -
rpool/data/vm-100-disk-0  creation              Wed Apr  1 21:32 2020   -
rpool/data/vm-100-disk-0  used                  41.0M                   -
rpool/data/vm-100-disk-0  available             2.12T                   -
rpool/data/vm-100-disk-0  referenced            41.0M                   -
rpool/data/vm-100-disk-0  compressratio         1.05x                   -
rpool/data/vm-100-disk-0  reservation           none                    default
rpool/data/vm-100-disk-0  volsize               52M                     local
rpool/data/vm-100-disk-0  volblocksize          8K                      default
rpool/data/vm-100-disk-0  checksum              on                      default
rpool/data/vm-100-disk-0  compression           lz4                     inherited from rpool
rpool/data/vm-100-disk-0  readonly              off                     default
rpool/data/vm-100-disk-0  createtxg             218                     -
rpool/data/vm-100-disk-0  copies                1                       default
rpool/data/vm-100-disk-0  refreservation        none                    default
rpool/data/vm-100-disk-0  guid                  6310424035607826424     -
rpool/data/vm-100-disk-0  primarycache          all                     default
rpool/data/vm-100-disk-0  secondarycache        all                     default
rpool/data/vm-100-disk-0  usedbysnapshots       0B                      -
rpool/data/vm-100-disk-0  usedbydataset         41.0M                   -
rpool/data/vm-100-disk-0  usedbychildren        0B                      -
rpool/data/vm-100-disk-0  usedbyrefreservation  0B                      -
rpool/data/vm-100-disk-0  logbias               latency                 default
rpool/data/vm-100-disk-0  objsetid              23                      -
rpool/data/vm-100-disk-0  dedup                 off                     default
rpool/data/vm-100-disk-0  mlslabel              none                    default
rpool/data/vm-100-disk-0  sync                  disabled                inherited from rpool/data
rpool/data/vm-100-disk-0  refcompressratio      1.05x                   -
rpool/data/vm-100-disk-0  written               41.0M                   -
rpool/data/vm-100-disk-0  logicalused           29.9M                   -
rpool/data/vm-100-disk-0  logicalreferenced     29.9M                   -
rpool/data/vm-100-disk-0  volmode               default                 default
rpool/data/vm-100-disk-0  snapshot_limit        none                    default
rpool/data/vm-100-disk-0  snapshot_count        none                    default
rpool/data/vm-100-disk-0  snapdev               hidden                  default
rpool/data/vm-100-disk-0  context               none                    default
rpool/data/vm-100-disk-0  fscontext             none                    default
rpool/data/vm-100-disk-0  defcontext            none                    default
rpool/data/vm-100-disk-0  rootcontext           none                    default
rpool/data/vm-100-disk-0  redundant_metadata    most                    inherited from rpool
rpool/data/vm-100-disk-0  encryption            off                     default
rpool/data/vm-100-disk-0  keylocation           none                    default
rpool/data/vm-100-disk-0  keyformat             none                    default
rpool/data/vm-100-disk-0  pbkdf2iters           0                       default
rpool/data/vm-100-disk-1  type                  volume                  -
rpool/data/vm-100-disk-1  creation              Wed Apr  1 21:35 2020   -
rpool/data/vm-100-disk-1  used                  8.11T                   -
rpool/data/vm-100-disk-1  available             2.12T                   -
rpool/data/vm-100-disk-1  referenced            8.11T                   -
rpool/data/vm-100-disk-1  compressratio         1.00x                   -
rpool/data/vm-100-disk-1  reservation           none                    default
rpool/data/vm-100-disk-1  volsize               8.79T                   local
rpool/data/vm-100-disk-1  volblocksize          8K                      default
rpool/data/vm-100-disk-1  checksum              on                      default
rpool/data/vm-100-disk-1  compression           lz4                     inherited from rpool
rpool/data/vm-100-disk-1  readonly              off                     default
rpool/data/vm-100-disk-1  createtxg             253                     -
rpool/data/vm-100-disk-1  copies                1                       default
rpool/data/vm-100-disk-1  refreservation        none                    default
rpool/data/vm-100-disk-1  guid                  299827836481902873      -
rpool/data/vm-100-disk-1  primarycache          all                     default
rpool/data/vm-100-disk-1  secondarycache        all                     default
rpool/data/vm-100-disk-1  usedbysnapshots       0B                      -
rpool/data/vm-100-disk-1  usedbydataset         8.11T                   -
rpool/data/vm-100-disk-1  usedbychildren        0B                      -
rpool/data/vm-100-disk-1  usedbyrefreservation  0B                      -
rpool/data/vm-100-disk-1  logbias               latency                 default
rpool/data/vm-100-disk-1  objsetid              147                     -
rpool/data/vm-100-disk-1  dedup                 off                     default
rpool/data/vm-100-disk-1  mlslabel              none                    default
rpool/data/vm-100-disk-1  sync                  disabled                inherited from rpool/data
rpool/data/vm-100-disk-1  refcompressratio      1.00x                   -
rpool/data/vm-100-disk-1  written               8.11T                   -
rpool/data/vm-100-disk-1  logicalused           5.61T                   -
rpool/data/vm-100-disk-1  logicalreferenced     5.61T                   -
rpool/data/vm-100-disk-1  volmode               default                 default
rpool/data/vm-100-disk-1  snapshot_limit        none                    default
rpool/data/vm-100-disk-1  snapshot_count        none                    default
rpool/data/vm-100-disk-1  snapdev               hidden                  default
rpool/data/vm-100-disk-1  context               none                    default
rpool/data/vm-100-disk-1  fscontext             none                    default
rpool/data/vm-100-disk-1  defcontext            none                    default
rpool/data/vm-100-disk-1  rootcontext           none                    default
rpool/data/vm-100-disk-1  redundant_metadata    most                    inherited from rpool
rpool/data/vm-100-disk-1  encryption            off                     default
rpool/data/vm-100-disk-1  keylocation           none                    default
rpool/data/vm-100-disk-1  keyformat             none                    default
rpool/data/vm-100-disk-1  pbkdf2iters           0                       default
rpool/data/vm-101-disk-0  type                  volume                  -
rpool/data/vm-101-disk-0  creation              Wed Apr  1 21:57 2020   -
rpool/data/vm-101-disk-0  used                  6.27G                   -
rpool/data/vm-101-disk-0  available             2.12T                   -
rpool/data/vm-101-disk-0  referenced            6.27G                   -
rpool/data/vm-101-disk-0  compressratio         1.17x                   -
rpool/data/vm-101-disk-0  reservation           none                    default
rpool/data/vm-101-disk-0  volsize               16G                     local
rpool/data/vm-101-disk-0  volblocksize          8K                      default
rpool/data/vm-101-disk-0  checksum              on                      default
rpool/data/vm-101-disk-0  compression           lz4                     inherited from rpool
rpool/data/vm-101-disk-0  readonly              off                     default
rpool/data/vm-101-disk-0  createtxg             509                     -
rpool/data/vm-101-disk-0  copies                1                       default
rpool/data/vm-101-disk-0  refreservation        none                    default
rpool/data/vm-101-disk-0  guid                  14456171849037122168    -
rpool/data/vm-101-disk-0  primarycache          all                     default
rpool/data/vm-101-disk-0  secondarycache        all                     default
rpool/data/vm-101-disk-0  usedbysnapshots       0B                      -
rpool/data/vm-101-disk-0  usedbydataset         6.27G                   -
rpool/data/vm-101-disk-0  usedbychildren        0B                      -
rpool/data/vm-101-disk-0  usedbyrefreservation  0B                      -
rpool/data/vm-101-disk-0  logbias               latency                 default
rpool/data/vm-101-disk-0  objsetid              153                     -
rpool/data/vm-101-disk-0  dedup                 off                     default
rpool/data/vm-101-disk-0  mlslabel              none                    default
rpool/data/vm-101-disk-0  sync                  disabled                inherited from rpool/data
rpool/data/vm-101-disk-0  refcompressratio      1.17x                   -
rpool/data/vm-101-disk-0  written               6.27G                   -
rpool/data/vm-101-disk-0  logicalused           5.05G                   -
rpool/data/vm-101-disk-0  logicalreferenced     5.05G                   -
rpool/data/vm-101-disk-0  volmode               default                 default
rpool/data/vm-101-disk-0  snapshot_limit        none                    default
rpool/data/vm-101-disk-0  snapshot_count        none                    default
rpool/data/vm-101-disk-0  snapdev               hidden                  default
rpool/data/vm-101-disk-0  context               none                    default
rpool/data/vm-101-disk-0  fscontext             none                    default
rpool/data/vm-101-disk-0  defcontext            none                    default
rpool/data/vm-101-disk-0  rootcontext           none                    default
rpool/data/vm-101-disk-0  redundant_metadata    most                    inherited from rpool
rpool/data/vm-101-disk-0  encryption            off                     default
rpool/data/vm-101-disk-0  keylocation           none                    default
rpool/data/vm-101-disk-0  keyformat             none                    default
rpool/data/vm-101-disk-0  pbkdf2iters           0                       default
rpool/data/vm-101-disk-1  type                  volume                  -
rpool/data/vm-101-disk-1  creation              Tue Apr  7 20:13 2020   -
rpool/data/vm-101-disk-1  used                  10.2M                   -
rpool/data/vm-101-disk-1  available             2.12T                   -
rpool/data/vm-101-disk-1  referenced            10.2M                   -
rpool/data/vm-101-disk-1  compressratio         2.12x                   -
rpool/data/vm-101-disk-1  reservation           none                    default
rpool/data/vm-101-disk-1  volsize               600G                    local
rpool/data/vm-101-disk-1  volblocksize          8K                      default
rpool/data/vm-101-disk-1  checksum              on                      default
rpool/data/vm-101-disk-1  compression           lz4                     inherited from rpool
rpool/data/vm-101-disk-1  readonly              off                     default
rpool/data/vm-101-disk-1  createtxg             122945                  -
rpool/data/vm-101-disk-1  copies                1                       default
rpool/data/vm-101-disk-1  refreservation        none                    default
rpool/data/vm-101-disk-1  guid                  16624083689465713695    -
rpool/data/vm-101-disk-1  primarycache          all                     default
rpool/data/vm-101-disk-1  secondarycache        all                     default
rpool/data/vm-101-disk-1  usedbysnapshots       0B                      -
rpool/data/vm-101-disk-1  usedbydataset         10.2M                   -
rpool/data/vm-101-disk-1  usedbychildren        0B                      -
rpool/data/vm-101-disk-1  usedbyrefreservation  0B                      -
rpool/data/vm-101-disk-1  logbias               latency                 default
rpool/data/vm-101-disk-1  objsetid              889                     -
rpool/data/vm-101-disk-1  dedup                 off                     default
rpool/data/vm-101-disk-1  mlslabel              none                    default
rpool/data/vm-101-disk-1  sync                  disabled                inherited from rpool/data
rpool/data/vm-101-disk-1  refcompressratio      2.12x                   -
rpool/data/vm-101-disk-1  written               10.2M                   -
rpool/data/vm-101-disk-1  logicalused           14.2M                   -
rpool/data/vm-101-disk-1  logicalreferenced     14.2M                   -
rpool/data/vm-101-disk-1  volmode               default                 default
rpool/data/vm-101-disk-1  snapshot_limit        none                    default
rpool/data/vm-101-disk-1  snapshot_count        none                    default
rpool/data/vm-101-disk-1  snapdev               hidden                  default
rpool/data/vm-101-disk-1  context               none                    default
rpool/data/vm-101-disk-1  fscontext             none                    default
rpool/data/vm-101-disk-1  defcontext            none                    default
rpool/data/vm-101-disk-1  rootcontext           none                    default
rpool/data/vm-101-disk-1  redundant_metadata    most                    inherited from rpool
rpool/data/vm-101-disk-1  encryption            off                     default
rpool/data/vm-101-disk-1  keylocation           none                    default
rpool/data/vm-101-disk-1  keyformat             none                    default
rpool/data/vm-101-disk-1  pbkdf2iters           0                       default

[ Voor 112% gewijzigd door HaTe op 07-04-2020 21:45 ]

[CurlyMo]

HaTe schreef op dinsdag 7 april 2020 @ 21:19:
Nu gebruik ik 1 VM voor TVheadend en had de timeshift en opnames op 1 zvol staan. Na een avondje TV kijken was "used" al ver boven de grootte van het volume (600GiB).

Je hebt hier toch al precies de oorzaak genoemd? Dan is het probleem toch ook zo opgelost.

[HaTe]

CurlyMo schreef op dinsdag 7 april 2020 @ 21:53:
[...]

Je hebt hier toch al precies de oorzaak genoemd? Dan is het probleem toch ook zo opgelost.

Ik kan het wel oplossen, maar dan kan ik geen TV meer kijken. Dus waar kan ik dan de timeshift stream plaatsen?

[CurlyMo]

HaTe schreef op dinsdag 7 april 2020 @ 22:01:
[...]

Ik kan het wel oplossen, maar dan kan ik geen TV meer kijken. Dus waar kan ik dan de timeshift stream plaatsen?

Op een plek waar er ruimte is. Dat heeft toch verder niks met ZFS te maken?

[HaTe]

CurlyMo schreef op dinsdag 7 april 2020 @ 22:04:
[...]

Op een plek waar er ruimte is. Dat heeft toch verder niks met ZFS te maken?

De VM zal na het verwijderen van de timeshift data dus niet de ruimte direct teruggeven. Hier moet eerst een trim commando op los gelaten worden. Ik kan de tiemshift wel op een maximum instellen van bijvoorbeeld 100GB, maar na 3x loopen, zit je al op 300GB, omdat de ruimte niet vrij komt.

[CurlyMo]

HaTe schreef op dinsdag 7 april 2020 @ 22:09:
[...]

De VM zal na het verwijderen van de timeshift data dus niet de ruimte direct teruggeven. Hier moet eerst een trim commando op los gelaten worden. Ik kan de tiemshift wel op een maximum instellen van bijvoorbeeld 100GB, maar na 3x loopen, zit je al op 300GB, omdat de ruimte niet vrij komt.

Nee, dat heeft niks met trim te maken. Er gaat dan ergens anders iets mis als die ruimte niet direct vrijkomt. Je purged ook daadwerkelijk de VM in je webGUI?

[HaTe]

CurlyMo schreef op dinsdag 7 april 2020 @ 22:10:
[...]

Nee, dat heeft niks met trim te maken. Er gaat dan ergens anders iets mis als die ruimte niet direct vrijkomt. Je purged ook daadwerkelijk de VM in je webGUI?

Ik wil geen volume verwijderen, dan werkt de VM niet meer
Volgens mij is het nog steeds niet helemaal duidelijk. Ik zal even kijken of ik straks een voorbeeld kan maken.

[CurlyMo]

HaTe schreef op dinsdag 7 april 2020 @ 22:12:
[...]

Ik wil geen volume verwijderen, dan werkt de VM niet meer
Volgens mij is het nog steeds niet helemaal duidelijk. Ik zal even kijken of ik straks een voorbeeld kan maken.

Graag, want ik vind met de informatie die je nu geeft volstrekt logisch wat er gebeurt.

[HaTe]

CurlyMo schreef op dinsdag 7 april 2020 @ 22:14:
[...]

Graag, want ik vind met de informatie die je nu geeft volstrekt logisch wat er gebeurt.

Het gaat hier om een pas geformateerd volume (in de VM). Voor ik de opname startte (was even makkelijker dan timeshift):

root@pve:~# zfs get all rpool/data/vm-101-disk-1 | grep used
rpool/data/vm-101-disk-1  used                  10.2M                  -
rpool/data/vm-101-disk-1  usedbysnapshots       0B                     -
rpool/data/vm-101-disk-1  usedbydataset         10.2M                  -
rpool/data/vm-101-disk-1  usedbychildren        0B                     -
rpool/data/vm-101-disk-1  usedbyrefreservation  0B                     -
rpool/data/vm-101-disk-1  logicalused           14.2M                  -

Opname is klaar:

root@pve:~# zfs get all rpool/data/vm-101-disk-1 | grep used
rpool/data/vm-101-disk-1  used                  432M                   -
rpool/data/vm-101-disk-1  usedbysnapshots       0B                     -
rpool/data/vm-101-disk-1  usedbydataset         432M                   -
rpool/data/vm-101-disk-1  usedbychildren        0B                     -
rpool/data/vm-101-disk-1  usedbyrefreservation  0B                     -
rpool/data/vm-101-disk-1  logicalused           306M                   -

Opname bestand is verwijderd:

root@pve:~# zfs get all rpool/data/vm-101-disk-1 | grep used
rpool/data/vm-101-disk-1  used                  432M                   -
rpool/data/vm-101-disk-1  usedbysnapshots       0B                     -
rpool/data/vm-101-disk-1  usedbydataset         432M                   -
rpool/data/vm-101-disk-1  usedbychildren        0B                     -
rpool/data/vm-101-disk-1  usedbyrefreservation  0B                     -
rpool/data/vm-101-disk-1  logicalused           306M                   -

Blijkbaar wist hij ook niet logicalused. Daar is dus trim voor.
En blijkbaar werkt fstrim niet met virtio...

fstrim: /mnt/data: the discard operation is not supported

Ook zie ik nu ook dat used ook al groter is als ik nog niks verwijderd, ik lees al ergens dat dat met de blocksize te maken heeft.. Stof om morgen verder naar te kijken

[ Voor 6% gewijzigd door HaTe op 07-04-2020 23:01 ]

[dcm360]

Hardware-veranderingen vereisen inderdaad vaak dat je de VM even uitzet en weer aanzet. De juiste optie zou overigens discard=on moeten zijn (niet True). Wat nog een beetje ontbreekt in het verhaal is overigens welk filesystem je gebruikt (in de VM). Niet alle filesystems voeren trim/discard direct door, maar doen dat dan periodiek.

Los hiervan is mijn ervaring dat tvheadend (met tv-tuner) werkend te krijgen is in een LXC-container, en dat dat stabieler is dan in een VM. Daar kan ik op verzoek nog wel wat meer over vertellen (in het Proxmox-topic dan, hier gaat dat off-topic).

Hee, daar is iets veranderd ook
Discard/trim zou moeten werken met de SCSI-controller 'VirtIO SCSI' en schijftype SCSI (niet VirtIO Block kiezen daar).

[ Voor 12% gewijzigd door dcm360 op 07-04-2020 23:17 ]

[CurlyMo]

@HaTe Plaats in het proxmox topic eens de config van je container: /etc/pve/lxc/1XX.conf met op de XX even het juiste nummer.

[Symyr]

Heb gisteren voor de eerste keer freenas geinstalleerd, geen probleem daar.
Maar ik had het idee dat als ik freenas installeer op 2 120gb ssd's dat ik dan diezelfde ssd's ook nog kan gebruiken voor een eventuele vm op te draaien. Kan dit of niet?

Ik vind precies geen optie om een plugin op die ssd's te laten draaien, ook geen optie om aan die mirror (volgens guides online is het tenminste een mirror als je beide schijven selecteert bij de install) te geraken.

[CurlyMo]

Symyr schreef op dinsdag 14 april 2020 @ 15:48:
Heb gisteren voor de eerste keer freenas geinstalleerd, geen probleem daar.
Maar ik had het idee dat als ik freenas installeer op 2 120gb ssd's dat ik dan diezelfde ssd's ook nog kan gebruiken voor een eventuele vm op te draaien. Kan dit of niet?

Ik vind precies geen optie om een plugin op die ssd's te laten draaien, ook geen optie om aan die mirror (volgens guides online is het tenminste een mirror als je beide schijven selecteert bij de install) te geraken.

Heeft niks met ZFS te maken, maar alles met FreeNAS

[Symyr]

DIY RAID NAS topic deel 3 dan?

[CurlyMo]

Symyr schreef op dinsdag 14 april 2020 @ 18:37:
DIY RAID NAS topic deel 3 dan?

Wellicht, ik draai zelf geen FreeNAS.

[CurlyMo]

Een crosspost vanuit het SMR schijven nieuwsbericht en wellicht ook wel interessant voor hier.
CurlyMo in 'nieuws: Hdd-fabrikanten verzwegen gebruik shingled magnetic recor...

Ik heb hier een ZFS mirror van twee 5TB SMR schijven via USB3 aangesloten. Deze is voor 90% vol (4.10T / 4.55T). Een scrub duurt 13 uur. Dat vind ik meer dan redelijk. Ook goed om te realiseren:

Scrub and resilver use exactly the same code

Uit de video hieronder gelinkt.

Daarbij is het probleem wat je beschrijft inderdaad lang van toepassing geweest binnen ZFS. Echter met de sequential scrub and resilver een stuk minder een probleem. Je zal in recente ZFS versies ook zien dat de output van de scrub anders is dan je gewend was.

root@pve:/# zpool status rpool
  pool: rpool
 state: ONLINE
  scan: scrub in progress since Fri Apr 17 20:23:18 2020
        4.93G scanned at 505M/s, 2.70G issued at 276M/s, 4.93G total
        0B repaired, 54.68% done, 0 days 00:00:08 to go

Het verschil is de nu scanned en issued splitsing die er in oudere versies niet was.
Dit is overigens een ZFS mirror van SSD's. De oude output was dit (willekeurig van internet):

# zpool status tank
  pool: tank
 state: ONLINE
 scan: scrub in progress since Sat Dec  8 08:06:36 2012
    32.0M scanned out of 48.5M at 16.0M/s, 0h0m to go
    0 repaired, 65.99% done

Uitleg van de commit in ZoL

Currently, scrubs and resilvers can take an extremely long time to complete. This is largely due to the fact that zfs scans process pools in logical order, as determined by each block's bookmark. This makes sense from a simplicity perspective, but blocks in zfs are often scattered randomly across disks, particularly due to zfs's copy-on-write mechanisms.

This patch improves performance by splitting scrubs and resilvers into a metadata scanning phase and an IO issuing phase. The metadata scan reads through the structure of the pool and gathers an in-memory queue of I/Os, sorted by size and offset on disk. The issuing phase will then issue the scrub I/Os as sequentially as possible, greatly improving performance.

This patch also updates and cleans up some of the scan code which has not been updated in several years.

https://github.com/openzf...df6d0ae33196f5b5decbc48fd
https://github.com/openzfs/zfs/pull/6256

How Has This Been Tested?

Initial performance tests show scrubs taking 5-6x less time with this patch on a 47TB pool consisting of data mimicking our production environment. On zfs version 0.6.8, the scrub took a little over 125 hours while it only took 22.5 with this patch. @skiselkov 's presentation at the developer summit cited a 16x performance improvement for a worst case scenario.

As this patch solidifies we will add more formalized automated tests.

PDF van de oorspronkelijke PoC van dit idee:
https://drive.google.com/...e4cdmVU91cml1N0pKYTQ/view
met een presentatie:
YouTube: Scrub/Resilver Performance by Saso Kiselkov

Presentatie van de OpenZFS Developer Summit:
YouTube: New prefetcher for sequential scrub by Tom Caputi

Het zit dus al in ZoL 0.8 and FreeNAS 11.1
https://www.ixsystems.com...ntial-scrub-and-resilver/

Mijn ervaringen worden gedeeld door andere gebruikers:

Both the scrub and resilver performace is MANY times faster with the new sequential scrub/resilver code. On my 6TB WD ES drives, it starts off slow at ~80-100 MB/s, then after about 15 minutes or so ramps up unto the hundreds of MB/s and stays there until it's done. Its also much quieter. Scrubs and resilvers used to thrash drives terribly, and now they thrash for the first minute or so then go almost silent unless you try to access the array during the resilver process.

https://arstechnica.com/c....php?p=37591199#p37591199

[RobertMe]

CurlyMo schreef op zaterdag 18 april 2020 @ 21:53:
Een crosspost vanuit het SMR schijven nieuwsbericht en wellicht ook wel interessant voor hier.
CurlyMo in 'nieuws: Hdd-fabrikanten verzwegen gebruik shingled magnetic recor...

Ik heb hier een ZFS mirror van twee 5TB SMR schijven via USB3 aangesloten. Deze is voor 90% vol (4.10T / 4.55T). Een scrub duurt 13 uur. Dat vind ik meer dan redelijk. Ook goed om te realiseren:

[...]

Uit de video hieronder gelinkt.

Daarbij is het probleem wat je beschrijft inderdaad lang van toepassing geweest binnen ZFS. Echter met de sequential scrub and resilver een stuk minder een probleem. Je zal in recente ZFS versies ook zien dat de output van de scrub anders is dan je gewend was.

root@pve:/# zpool status rpool
  pool: rpool
 state: ONLINE
  scan: scrub in progress since Fri Apr 17 20:23:18 2020
        4.93G scanned at 505M/s, 2.70G issued at 276M/s, 4.93G total
        0B repaired, 54.68% done, 0 days 00:00:08 to go

Het verschil is de nu scanned en issued splitsing die er in oudere versies niet was.
Dit is overigens een ZFS mirror van SSD's. De oude output was dit (willekeurig van internet):

# zpool status tank
  pool: tank
 state: ONLINE
 scan: scrub in progress since Sat Dec  8 08:06:36 2012
    32.0M scanned out of 48.5M at 16.0M/s, 0h0m to go
    0 repaired, 65.99% done

Uitleg van de commit in ZoL

[...]

https://github.com/openzf...df6d0ae33196f5b5decbc48fd
https://github.com/openzfs/zfs/pull/6256


[...]


PDF van de oorspronkelijke PoC van dit idee:
https://drive.google.com/...e4cdmVU91cml1N0pKYTQ/view
met een presentatie:
YouTube: Scrub/Resilver Performance by Saso Kiselkov

Presentatie van de OpenZFS Developer Summit:
YouTube: New prefetcher for sequential scrub by Tom Caputi

Het zit dus al in ZoL 0.8 and FreeNAS 11.1
https://www.ixsystems.com...ntial-scrub-and-resilver/

Mijn ervaringen worden gedeeld door andere gebruikers:

[...]

https://arstechnica.com/c....php?p=37591199#p37591199

Niet het hele stuk gelezen, maar een scrub is als het goed is 100% read, een echte resilver (nieuwe schijf in mirror of replace van bestaande) is 100% write op die nieuwe schijf. Dus uit performance perspectief niet te vergelijken. Enige wat gedeeld kan zijn is dat ze i.p.v. de blocks over de hele schijf te schrijven deze veel meer sequentieel schrijven. Maar gezien drive-managed SMR is het natuurlijk ook maar de vraag of steeds bv 10MB aan data schrijven niet alsnog ervoor zorgt dat het schrijven van 10MB nieuwe data ook (een deel van) de vorige 10MB overschrijft. In die zin dus ook: SMR kan werken, maar dan wel met slimme software, en dat kan niet op de HDD (tenzij enorme caches). Als je bv 10GB sequentieel wilt schrijven is het nog steeds de vraag hoe de lagen tegen/over elkaar liggen of die niet continu een deel van de zojuist geschreven data opnieuw moet beschrijven. Een software (/OS) based oplossing zou daar wellicht slimmer in kunnen zijn door de data "andersom" te schrijven waardoor die begint met de data te schrijven vanaf de laag die (gedeeltelijk) overschreven kan worden i.p.v. eerst een laag die daarna weer overschreven wordt en dan weer terug gezet moet worden.

En uit mijn topic over de Seagate SMR schijf: een resilver van ~300GB duurde ettelijke uren. Dat vind ik niet normaal... Een scrub op CMR schijven duurde net geen uur, dan vind ik 8+ uur of zo met die Seagate resilver toch wel dramatisch slechter. En dat ontkracht waarschijnlijk ook de "scrub & resilver zijn hetzelfde". Of de schrijf zou ineens ook een dramatische read performance moeten hebben, als die niet 300GB kon lezen binnen 8 uur.

Edit:
Dit topic dus: Harde schijf (extreem) traag en veroorzaakt lockups
Alhoewel ik niet durf te zeggen of dat toen ook al met de verbeterde scrub was. Maar punt blijft lijkt mij staan dat een 100% write van een resilver niet te vergelijken valt met een (vrijwel) 100% read van een scrub. Al is het maar omdat writes sowieso langzamer zijn dan reads. Dus ook al is het een ideale situatie voor SMR (alles sequentieel en geen rewites nodig) zal de performance van een resilver nog steeds slechter zijn dan een scrub.

[ Voor 6% gewijzigd door RobertMe op 18-04-2020 22:25 ]

[Q]

Nu we het over scrub performance hebben. Ik heb nu 60TB aan data en een scrub duurt iets meer dan 16 uur. Dat is grofweg 3,75 TB per uur --> grofweg gemiddeld 1 GB/s. Dat is met 24 x 7200 RPM schijven en een hoog-bejaarde Linux + ZFS.

[CurlyMo]

RobertMe schreef op zaterdag 18 april 2020 @ 22:20:
[...]

Niet het hele stuk gelezen, maar een scrub is als het goed is 100% read, een echte resilver (nieuwe schijf in mirror of replace van bestaande) is 100% write op die nieuwe schijf. Dus uit performance perspectief niet te vergelijken. Enige wat gedeeld kan zijn is dat ze i.p.v. de blocks over de hele schijf te schrijven deze veel meer sequentieel schrijven.

En dat sequentieel schrijven is juist de kern van de verbetering.

Maar gezien drive-managed SMR is het natuurlijk ook maar de vraag of steeds bv 10MB aan data schrijven niet alsnog ervoor zorgt dat het schrijven van 10MB nieuwe data ook (een deel van) de vorige 10MB overschrijft.

Zo slim is ZFS niet, en dat is in dit geval in je voordeel. Als er nieuwe data geschreven dient te worden, dan pakt ZFS eerst een leeg blok, vult deze, en labelt het oude blok als beschikbaar. Daarom ook een CoW bestandsysteem. Dat is ook de reden dat ZFS pool zo gefragmenteerd raken naarmate je pool voller worden.

Als je bv 10GB sequentieel wilt schrijven is het nog steeds de vraag hoe de lagen tegen/over elkaar liggen of die niet continu een deel van de zojuist geschreven data opnieuw moet beschrijven.

Dit wordt pas een probleem als je daar continue tegenaan loopt. In de meest extreem gefragmenteerde pools. In werkelijkheid zal dat zo nu en dan voorkomen. Dat heb je tijdens de resilver even een lookup en dan weer door.

Een software (/OS) based oplossing zou daar wellicht slimmer in kunnen zijn door de data "andersom" te schrijven waardoor die begint met de data te schrijven vanaf de laag die (gedeeltelijk) overschreven kan worden i.p.v. eerst een laag die daarna weer overschreven wordt en dan weer terug gezet moet worden.

Klopt, daar word binnen ZFS aan gewerkt.

En uit mijn topic over de Seagate SMR schijf: een resilver van ~300GB duurde ettelijke uren. Dat vind ik niet normaal... Een scrub op CMR schijven duurde net geen uur, dan vind ik 8+ uur of zo met die Seagate resilver toch wel dramatisch slechter. En dat ontkracht waarschijnlijk ook de "scrub & resilver zijn hetzelfde". Of de schrijf zou ineens ook een dramatische read performance moeten hebben, als die niet 300GB kon lezen binnen 8 uur.

Dit topic dus: Harde schijf (extreem) traag en veroorzaakt lockups
Alhoewel ik niet durf te zeggen of dat toen ook al met de verbeterde scrub was.

Nee, dat ontkracht het pas als je me kan verzekeren dat dat met de sequential scrub and resilver methode zo lang duurde, wat je zegt niet te kunnen.

Maar punt blijft lijkt mij staan dat een 100% write van een resilver niet te vergelijken valt met een (vrijwel) 100% read van een scrub. Al is het maar omdat writes sowieso langzamer zijn dan reads. Dus ook al is het een ideale situatie voor SMR (alles sequentieel en geen rewites nodig) zal de performance van een resilver nog steeds slechter zijn dan een scrub.

Nee, zo simpel is het alsnog niet. Er zijn twee scenario's:
1. Je pool is tijdelijk degraded omdat een van de schijven kuren heeft. Ze zijn daardoor out-of-sync. Zo'n resilver is dan bij normale workflows voor 90% reads en de laatste 10% writes om de schijven weer in sync te krijgen.
2. Je pool is degraded omdat één van de HDD's vervangen moet worden. Op dat moment is alle data op je SMR schijf nieuw en er dus ook geen sprake van fragmentatie. Die 100% writes zijn dan dus gewoon sequentieel voor de nieuwe schijf. Er is dan geen sprake van overschrijven van oude blokken, want die zijn er op dat moment bij een lege schijf nog niet.

Q schreef op zaterdag 18 april 2020 @ 22:29:
Nu we het over scrub performance hebben. Ik heb nu 60TB aan data en een scrub duurt iets meer dan 16 uur. Dat is grofweg 3,75 TB per uur --> grofweg gemiddeld 1 GB/s. Dat is met 24 x 7200 RPM schijven en een hoog-bejaarde Linux + ZFS.

Dat is wel te verklaren met 24 schijven. Die dragen gezamenlijk wel lekker bij aan een mooie read performance. Waarschijnlijk ook geen USB aangesloten schijven, maar direct op je SATA / SAS controller.

[RobertMe]

CurlyMo schreef op zaterdag 18 april 2020 @ 23:06:
[...]

Nee, dat ontkracht het pas als je me kan verzekeren dat dat met de sequential scrub and resilver methode zo lang duurde, wat je zegt niet te kunnen.

Vanaf welke versie zijn deze verbeteringen doorgevoerd? Want dan kan ik zo in de loga nakijken sinds wanneer ik die versie heb. Draait toch op Arch Linux. Niet altijd even vaak geüpdate, maar zo heel ver zal het ook niet hebben achter gelopen.

[CurlyMo]

Je kan het zien je in scrub output zoals ik in mijn eerste reactie hierover heb beschreven.

[RobertMe]

CurlyMo schreef op zaterdag 18 april 2020 @ 23:33:
Je kan het zien je in scrub output zoals ik in mijn eerste reactie hierover heb beschreven.

Dat snap ik. Maar ten eerste zit de HDD überhaupt niet meer in dat systeem en ten tweede zegt de versie die ik nu draai niks over de versie die ik toentertijd draaide.

In ieder geval zou ik gokken dat deze feature op zijn laatst onderdeel zou zijn geweest van ZoL 0.8, en die draai ik al sinds september (en 0.8.2 sinds november). Terwijl ik de HDD pas sinds december heb. Dus op basis daarvan zou ik zeggen: ja, die 8+ uur resilver van 300GB was met deze nieuwe scrub & resilver code.
En dan ter vergelijking: deze HDD via USB (3) aan een Orange Pi 3 doet nu resilvers van ~50 minuten dus vrijwel identiek aan de 50 tot 60 minuten van de mirror van twee CMR disks. Met dien verschille dat de mirror actief gebruikt wordt (PostgreSQL & InfluxDB databases voor Home Assistant die erop staan bv) en de SMR schijf niet (alleen periodieke send & receive voor backup doeleinden). Waardoor de een niet 100% met scrub bezig kan zijn en de ander wel.

Edit:
Overigens maakt dat het ook meteen zo dat het niet valt te vergelijken. Want het gebruik tijdens de resilver zorgt sowieso voor random writes en sloopt SMR dus. Of een resilver in geval van "puur archieveringsdoeleinden" met SMR dan wel of niet snel is valt daardoor niet meer te zeggen.

[ Voor 11% gewijzigd door RobertMe op 18-04-2020 23:49 ]

[Q]

CurlyMo schreef op zaterdag 18 april 2020 @ 23:06:
Dat is wel te verklaren met 24 schijven. Die dragen gezamenlijk wel lekker bij aan een mooie read performance. Waarschijnlijk ook geen USB aangesloten schijven, maar direct op je SATA / SAS controller.

Eigenlijk vind ik dat heel slecht als je weet dat deze schijven makkelijk over de 200 MB/s 160 MB/s kunnen halen en ik op basis van dit gemiddelde maar ~40 MB/s per schijf haal.

Maar voor wat het waard is, deelde ik (ongevraagd) die stat zodat andere mensen er misschien een referentie aan hebben.

[FireDrunk]

@CurlyMo Thanks voor de goede uitleg!

Heb gelijk maar even geupgradet naar ZFS 0.8. Hiervoor moest ik wel de Debian Backports repo toevoegen, default is nog 0.7 in de Debian (10/Buster) main repo's.
Upgrade ging verder smooth-as-silk,

apt update && apt dist-upgrade && reboot

.

Scrub loopt nu met een keurige ~600MB/s.

[CurlyMo]

@RobertMe Ik ben van plan mijn 5TB mirror t.z.t. om te zetten naar een RAIDZ2. Als ik de nieuwe schijven binnen heb, dan zal ik eerst eens proberen hoe lang het toevoegen van een nieuwe schijf aan mijn mirror duurt.

[dcm360]

Ik zou verwachten dat het meerdere pogingen gaat kosten. Dat heb ik zelf ervaren met met schijven van 8TB, tijdens het kopiëren van een dataset vanaf een andere array 'verloor' ik een van de schijven uit de raid-z, en het kostte meerdere pogingen om de schijf met een resilver er weer bij te krijgen. Dat ligt dus redelijk in lijn met de verhalen die je hier en daar tegenkomt. Met een scrub haal ik overigens wel mooi snelheden van ruim boven de 400MB/s met 3 schijven.
Dat is dan zo lang de schijven er een beetje zin in blijven hebben, 1 heeft af en toe de neiging bad sectors te ontwikkelen. Dan zit ik nu alleen met het issue dat de gammele schijf vervangen meer risicovol lijkt dan m mee laten draaien, en zit ik nu in dezelfde situatie als met de schijven die ik voorheen voorheen in die pool had, die had ook 1 wat gammele schijf.

[FireDrunk]

Nice, de vannacht met ZFS 0.8 gestartte scrub duurde 6 uur ipv de 10 uur die het duurde met ZFS 0.7.
Mooie verbeteringen dus!

[HyperBart]

CurlyMo schreef op zaterdag 18 april 2020 @ 23:06:

Wat ik nog niet begrijp is waarom die disks in het artikel van Blocks and Files er uit worden getrapt. Dat ze trager zijn in performance, prima, maar waar komt het issue vandaan dat ze niet betrouwbaar in een array blijven zitten?

[RobertMe]

HyperBart schreef op zondag 19 april 2020 @ 15:56:
[...]


Wat ik nog niet begrijp is waarom die disks in het artikel van Blocks and Files er uit worden getrapt. Dat ze trager zijn in performance, prima, maar waar komt het issue vandaan dat ze niet betrouwbaar in een array blijven zitten?

Wat ik zelf toentertijd heb ervaren is dat random writes ineens zomaar 1 tot 5 seconden kunnen duren. Ik kan mij best indenken dat dat niet al te leuk gevonden wordt, en afhankelijk van het systeem (hardware raid vs een software update vs ZFS vs ...) zou het kicken van een drive mij dan ook niks verbazen. Want zo'n langzame writes "kan niet goed zijn". Nee, de HDD is niet defect en bij SMR is het "binnen de verwachting". Maar het systeem weet niet dat het een SMR drive is noch dat zo'n langzame writes binnen de marges vallen.

[CurlyMo]

HyperBart schreef op zondag 19 april 2020 @ 15:56:
[...]


Wat ik nog niet begrijp is waarom die disks in het artikel van Blocks and Files er uit worden getrapt. Dat ze trager zijn in performance, prima, maar waar komt het issue vandaan dat ze niet betrouwbaar in een array blijven zitten?

Ik denk dat dat sterk samenhangt met het onderliggende FS en RAID implementatie.

[_JGC_]

Bij de RED staat TLER/SCTERC standaard ingeschakeld, op 7 seconden naar mijn weten. Als jij zo'n disk 2 dagen lang continu laat schrijven zal er ooit een write komen die na 7 seconden wordt afgebroken en heb je de kans dat ZFS de drive afkeurt vanwege I/O fouten.

[dcm360]

_JGC_ schreef op zondag 19 april 2020 @ 16:23:
Bij de RED staat TLER/SCTERC standaard ingeschakeld, op 7 seconden naar mijn weten. Als jij zo'n disk 2 dagen lang continu laat schrijven zal er ooit een write komen die na 7 seconden wordt afgebroken en heb je de kans dat ZFS de drive afkeurt vanwege I/O fouten.

En op het punt dat een write wordt afgebroken omdat die te lang duurt vanwege het herschrijven van een zone, lijkt het mij dat je ook nog een versterkend effect krijgt. Voor de host is de write wellicht afgebroken, maar de schijf kan op de achtergrond niet stoppen met het herschrijven van de zone (want dan verdwijnt er data die ongerelateerd kan zijn aan de betreffende write). Hierdoor raakt een volgende write ook vertraagd en zo verder...

[_JGC_]

dcm360 schreef op zondag 19 april 2020 @ 16:34:
[...]

En op het punt dat een write wordt afgebroken omdat die te lang duurt vanwege het herschrijven van een zone, lijkt het mij dat je ook nog een versterkend effect krijgt. Voor de host is de write wellicht afgebroken, maar de schijf kan op de achtergrond niet stoppen met het herschrijven van de zone (want dan verdwijnt er data die ongerelateerd kan zijn aan de betreffende write). Hierdoor raakt een volgende write ook vertraagd en zo verder...

Wat altijd ook nog kan is dat er een bug in de firmware zit waardoor datacorruptie optreedt. Bij normale RAID setups is dat hooguit een "corrected sector X" melding of helemaal niks, bij ZFS komt het probleem naar voren. Ik ken SHR niet goed genoeg om daar iets over te zeggen.

[FireDrunk]

dcm360 schreef op zondag 19 april 2020 @ 16:34:
[...]

En op het punt dat een write wordt afgebroken omdat die te lang duurt vanwege het herschrijven van een zone, lijkt het mij dat je ook nog een versterkend effect krijgt. Voor de host is de write wellicht afgebroken, maar de schijf kan op de achtergrond niet stoppen met het herschrijven van de zone (want dan verdwijnt er data die ongerelateerd kan zijn aan de betreffende write). Hierdoor raakt een volgende write ook vertraagd en zo verder...

Volgens mij valt dat wel mee, als queues vol zijn krijg je gewoon spin waits die wachten tot er weer een plekje is. Vroeger deden schijven veel minder IO, en was alles veel trager, toen hadden we deze problemen ook niet.
Het simpele feit dat iets traag is, is geen reden om te crashen.

De absolute interne timeout van ZFS wordt uitgevoerd door de SPA deadman switch (https://utcc.utoronto.ca/...aris/ZFSReallySlowIOPanic). In 2017 was die 1000 seconden, oftewel iets meer dan 16 minuten.

De kernel zal veeeeeel eerder ingrijpen en de IO cancelen. Afhankelijk van wat er gebeurt, zal er een device reset gestuurd worden door je kernel om de disk een schop te geven. Als dat ook niet helpt gaat de disk offline.

Bij een canceled IO ziet ZFS dat als een IO error en zal de disk offline gehaald worden.

Er zijn een hoop mechanismes die hiertussen zitten, om te zorgen dat je IO door blijft gaan onder extreme omstandigheden. Denk aan schedulers en IO priority.

Een SMR schijf zal zijn queue gewoon langzamer leeg kunnen maken, en zou altijd netjes moeten melden dat hij het druk heeft.

Als dat dus niet gebeurt (bijvoorbeeld, omdat ze ranzige PMR -> SMR buffering doen), is dat mijns inziens altijd een fout in de firmware.

[CurlyMo]

FireDrunk schreef op zondag 19 april 2020 @ 20:43:
[...]
Bij een canceled IO ziet ZFS dat als een IO error en zal de disk offline geven gehaald worden een write en checksum error geven.

Dat ziet er dus zo uit:

[ 5910.378601] ata4: EH complete
[25282.062323] ata4.00: exception Emask 0x10 SAct 0x800080 SErr 0x40c0000 action 0xe frozen
[25282.062337] ata4.00: irq_stat 0x00000040, connection status changed
[25282.062342] ata4: SError: { CommWake 10B8B DevExch }
[25282.062348] ata4.00: failed command: WRITE FPDMA QUEUED
[25282.062357] ata4.00: cmd 61/28:38:18:f2:fc/00:00:13:00:00/40 tag 7 ncq dma 20480 out
                        res 40/00:3c:18:f2:fc/00:00:13:00:00/40 Emask 0x10 (ATA bus error)
[25282.062365] ata4.00: status: { DRDY }
[25282.062369] ata4.00: failed command: WRITE FPDMA QUEUED
[25282.062377] ata4.00: cmd 61/08:b8:00:ea:9c/00:00:10:00:00/40 tag 23 ncq dma 4096 out
                        res 40/00:3c:18:f2:fc/00:00:13:00:00/40 Emask 0x10 (ATA bus error)
[25282.062385] ata4.00: status: { DRDY }
[25282.062391] ata4: hard resetting link
[25282.778404] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[25282.781558] ata4.00: configured for UDMA/133
[25282.781576] ahci 0000:00:1f.2: port does not support device sleep
[25282.781645] sd 4:0:0:0: [sdc] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[25282.781654] sd 4:0:0:0: [sdc] tag#7 Sense Key : Illegal Request [current]
[25282.781662] sd 4:0:0:0: [sdc] tag#7 Add. Sense: Unaligned write command
[25282.781670] sd 4:0:0:0: [sdc] tag#7 CDB: Write(10) 2a 00 13 fc f2 18 00 00 28 00
[25282.781679] blk_update_request: I/O error, dev sdc, sector 335344152 op 0x1:(WRITE) flags 0x700 phys_seg 1 prio class 0
[25282.781693] zio pool=data vdev=/dev/disk/by-id/wwn-0x5002303100145bfc-part4 error=5 type=2 offset=152367804416 size=20480 flags=180880

[FireDrunk]

Correct, mijn woordkeus is matig.
Waar ik nog niet helemaal over uit ben, is welke foutcodes ZFS als IO errors bestempeld.

In jouw geval geeft de drive zelf de error terug, en de kernel zal hier een specifieke kernel io interface foutcode opgooien en doorgeven aan ZFS. De mapping tussen Linux Kernel ABI en ZFS intern gedrag heb ik nog niet gevonden. Daar kan nog wel eens een verklaring verborgen zitten.

Als de kernel netjes een 'deze io kan niet want de schijf is druk' error geeft, en ZFS leest dat als error, panic, klopt dat natuurlijk niet...

Ik zou verwachten dat er alleen een checksum error komt als er daadwerkelijk data ontvangen is.

---

EDIT: Vandaag nog weer even zitten zoeken in de Git repo van openZFS, maar kan het niet echt vinden.
Er zijn vele communicatie kanalen met de kernel, ik zie een aantal dingen in de BIO laag:

bron

C:

static inline blk_status_t
errno_to_bi_status(int error)
{
    switch (error) {
    case 0:
        return (BLK_STS_OK);
    case EOPNOTSUPP:
        return (BLK_STS_NOTSUPP);
    case ETIMEDOUT:
        return (BLK_STS_TIMEOUT);
    case ENOSPC:
        return (BLK_STS_NOSPC);
    case ENOLINK:
        return (BLK_STS_TRANSPORT);
    case EREMOTEIO:
        return (BLK_STS_TARGET);
    case EBADE:
        return (BLK_STS_NEXUS);
    case ENODATA:
        return (BLK_STS_MEDIUM);
    case EILSEQ:
        return (BLK_STS_PROTECTION);
    case ENOMEM:
        return (BLK_STS_RESOURCE);
    case EAGAIN:
        return (BLK_STS_AGAIN);
    case EIO:
        return (BLK_STS_IOERR);
    default:
        return (BLK_STS_IOERR);
    }
}
#endif /* HAVE_BIO_BI_STATUS */

De search continues... Misschien maar eens een issue openen, maar er loopt al een discussie over SMR schijven:

https://github.com/openzfs/zfs/issues/10214

[ Voor 48% gewijzigd door FireDrunk op 20-04-2020 11:45 ]

[BonJonBovi]

Ik heb 4 4TB schijven in een raidz2 opstelling in mijn NAS zonder ECC. Nu is er bij een van de schijven twee checksum errors gedetecteerd, verder geen read of write errors. Dit is voor het eerst dat deze schijf errors geeft, en heeft pas een uptime van 6600 uur. De pool is nog volledig online, en de SMART status van deze schijf lijkt ook nog OK.

Kan en moet ik wat doen met deze checksum errors, en is het misschien een signaal dat deze schijf waarschijnlijk binnenkort defect raakt?

[CurlyMo]

BonJonBovi schreef op zaterdag 25 april 2020 @ 18:46:
Ik heb 4 4TB schijven in een raidz2 opstelling in mijn NAS zonder ECC. Nu is er bij een van de schijven twee checksum errors gedetecteerd, verder geen read of write errors. Dit is voor het eerst dat deze schijf errors geeft, en heeft pas een uptime van 6600 uur. De pool is nog volledig online, en de SMART status van deze schijf lijkt ook nog OK.

Kan en moet ik wat doen met deze checksum errors, en is het misschien een signaal dat deze schijf waarschijnlijk binnenkort defect raakt?

Altijd eerst een of twee keer scrubben en kijken of ze wegblijven. Voordat je scrubbed even een zpool clear doen.

[Q]

BonJonBovi schreef op zaterdag 25 april 2020 @ 18:46:
Ik heb 4 4TB schijven in een raidz2 opstelling in mijn NAS zonder ECC. Nu is er bij een van de schijven twee checksum errors gedetecteerd, verder geen read of write errors. Dit is voor het eerst dat deze schijf errors geeft, en heeft pas een uptime van 6600 uur. De pool is nog volledig online, en de SMART status van deze schijf lijkt ook nog OK.

Kan en moet ik wat doen met deze checksum errors, en is het misschien een signaal dat deze schijf waarschijnlijk binnenkort defect raakt?

Ik zou naast de scrub ook of misschien eerst een memtest laten lopen een nachtje.

[FireDrunk]

W00t, Persistent L2ARC is gemerged, eens kijken wanneer dat in de release gaat komen

https://github.com/openzfs/zfs/pull/9582

Voor de mensen die niet weten wat het is, normaal gesproken is je L2ARC 'leeg' bij een reboot, en wordt hij bij elke import van een pool, 'vers' weer gevuld waar nodig. Dit zorgt voor een hele hoop writes in het begin, die later weer vervangen worden voor andere data.

Dit scheelt dus een hele hoop writes naar je SSD, omdat je L2ARC gewoon nog intact is na een reboot.
(Uiteraard was dit een veel groter probleem bij grote Enterprises, maar het helpt zeker in thuissituaties).

[Q]

FireDrunk schreef op dinsdag 28 april 2020 @ 14:24:
W00t, Persistent L2ARC is gemerged, eens kijken wanneer dat in de release gaat komen

https://github.com/openzfs/zfs/pull/9582

Voor de mensen die niet weten wat het is, normaal gesproken is je L2ARC 'leeg' bij een reboot, en wordt hij bij elke import van een pool, 'vers' weer gevuld waar nodig. Dit zorgt voor een hele hoop writes in het begin, die later weer vervangen worden voor andere data.

Dit scheelt dus een hele hoop writes naar je SSD, omdat je L2ARC gewoon nog intact is na een reboot.
(Uiteraard was dit een veel groter probleem bij grote Enterprises, maar het helpt zeker in thuissituaties).

Dit is goed nieuws voor wie baat heeft bij L2ARC, maar wie heeft er thuis echt baat bij?

VMs draai je toch al vanaf SSD (die dingen kosten niets meer) en wat voor content heb je op een HDD-based pool dat L2ARC echt uitmaakt? Want een hoop content wordt al gewoon in RAM gecached?

Het enige wat ik zelf kan bedenken is met name video productie/edditing waarbij voldoende RAM waarschijnlijk duurder is dan een L2ARC SSD. Maar misschien mis ik iets?

@BonJonBovi hoe is het afgelopen?

[FireDrunk]

Ik zit al een tijdje te denken om een gecombineerde SLOG / L2ARC cache in te zetten om mijn disks wat rust te geven van alle Downloads die er gebeuren.

Wat erg lastig is, is dat ik sommige torrents erg lang seed. Een losse SSD zou helpen, maar de data wordt uiteindelijk gemigreerd naar mijn pool, waarna de SSD weer geen zin zou hebben.

Vandaar een L2ARC, die voor lange duur, data die veel gebruikt wordt kan cachen. Vandaar dat persistancy handig is.

[BonJonBovi]

Q schreef op dinsdag 28 april 2020 @ 18:40:
@BonJonBovi hoe is het afgelopen?

Inmiddels twee scrubs uitgevoerd, maar schijnbaar heb ik over een belangrijk deel van wat @CurlyMo had geschreven, overheen gelezen. Ik zal de status eerst clearen nu, en opnieuw scrubben. Keep you posted.

[ocaj]

Q schreef op dinsdag 28 april 2020 @ 18:40:
[...]
Dit is goed nieuws voor wie baat heeft bij L2ARC, maar wie heeft er thuis echt baat bij?

Ach, alle beetjes helpen toch?
Hier wat stats met een uptime van momenteel 64 dagen:

code:

ARC size (current):                                   100.1 %   23.0 GiB
        Target size (adaptive):                       100.0 %   23.0 GiB
        Min size (hard limit):                          4.2 %  986.8 MiB
        Max size (high water):                           23:1   23.0 GiB
        Most Frequently Used (MFU) cache size:         95.0 %   20.9 GiB
        Most Recently Used (MRU) cache size:            5.0 %    1.1 GiB
        Metadata cache size (hard limit):              75.0 %   17.2 GiB
        Metadata cache size (current):                 10.2 %    1.8 GiB
        Dnode cache size (hard limit):                 10.0 %    1.7 GiB
        Dnode cache size (current):                    30.7 %  542.6 MiB

ARC total accesses (hits + misses):                                11.0G
        Cache hit ratio:                              100.0 %      11.0G
        Cache miss ratio:                             < 0.1 %       3.7M
        Actual hit ratio (MFU + MRU hits):             99.9 %      11.0G
        Data demand efficiency:                        99.5 %     443.2M
        Data prefetch efficiency:                      87.1 %       6.2M

L2ARC size (adaptive):                                         132.0 GiB
        Compressed:                                    69.4 %   91.6 GiB
        Header size:                                  < 0.1 %   46.9 MiB

L2ARC breakdown:                                                    3.7M
        Hit ratio:                                     38.3 %       1.4M
        Miss ratio:                                    61.7 %       2.3M
        Feeds:                                                      5.4M

Hit ratio van de L2ARC is 38%. Ik heb geen concrete metingen of het nu echt helpt of niet. Systeem voelt lekker vlot aan in gebruik, dus ik vind het prima zo.

Server wordt niet heel zwaar belast, draaien een stuk of 6 lxc-containers op, o.a. een mysql-server en een influx-server voor wat sensor-logging en verder nas om films naar appletv te streamen en muziek naar bluesound.
Daarnaast time-machine backups van 2 computers (ik vermoed dat dat het grootste deel van de data in de cache is, aangezien time machine op een netwerk-schijf uit een enorme berg een 8MB-bestanden bestaat).

[ Voor 6% gewijzigd door ocaj op 28-04-2020 23:00 ]

[Q]

FireDrunk schreef op dinsdag 28 april 2020 @ 18:57:
Ik zit al een tijdje te denken om een gecombineerde SLOG / L2ARC cache in te zetten om mijn disks wat rust te geven van alle Downloads die er gebeuren.

Wat erg lastig is, is dat ik sommige torrents erg lang seed. Een losse SSD zou helpen, maar de data wordt uiteindelijk gemigreerd naar mijn pool, waarna de SSD weer geen zin zou hebben.

Vandaar een L2ARC, die voor lange duur, data die veel gebruikt wordt kan cachen. Vandaar dat persistancy handig is.

Met torrents zie ik inderdaad zo voor me dat uiteindelijk data niet frequent genoeg wordt opgevraagd waardoor het uit de cache wordt gegooid en je disks alsnog aan de slag moeten.

Ik denk dat je beter af bent om die L2ARC ssd (gedeeltelijk) in te zetten voor dit soort zaken om je disks te ontlasten. Of de goedkoopste crappy 'grote' SSD die je kunt vinden.

Misschien helpt L2ARC wel, ik weet het niet (ik gebruik het niet op mijn doos), je kunt het wellicht testen.

[Q]

ocaj schreef op dinsdag 28 april 2020 @ 22:58:
[...]


Ach, alle beetjes helpen toch?
Hier wat stats met een uptime van momenteel 64 dagen:

code:

ARC size (current):                                   100.1 %   23.0 GiB
        Target size (adaptive):                       100.0 %   23.0 GiB
        Min size (hard limit):                          4.2 %  986.8 MiB
        Max size (high water):                           23:1   23.0 GiB
        Most Frequently Used (MFU) cache size:         95.0 %   20.9 GiB
        Most Recently Used (MRU) cache size:            5.0 %    1.1 GiB
        Metadata cache size (hard limit):              75.0 %   17.2 GiB
        Metadata cache size (current):                 10.2 %    1.8 GiB
        Dnode cache size (hard limit):                 10.0 %    1.7 GiB
        Dnode cache size (current):                    30.7 %  542.6 MiB

ARC total accesses (hits + misses):                                11.0G
        Cache hit ratio:                              100.0 %      11.0G
        Cache miss ratio:                             < 0.1 %       3.7M
        Actual hit ratio (MFU + MRU hits):             99.9 %      11.0G
        Data demand efficiency:                        99.5 %     443.2M
        Data prefetch efficiency:                      87.1 %       6.2M

L2ARC size (adaptive):                                         132.0 GiB
        Compressed:                                    69.4 %   91.6 GiB
        Header size:                                  < 0.1 %   46.9 MiB

L2ARC breakdown:                                                    3.7M
        Hit ratio:                                     38.3 %       1.4M
        Miss ratio:                                    61.7 %       2.3M
        Feeds:                                                      5.4M

Hit ratio van de L2ARC is 38%. Ik heb geen concrete metingen of het nu echt helpt of niet. Systeem voelt lekker vlot aan in gebruik, dus ik vind het prima zo.

Server wordt niet heel zwaar belast, draaien een stuk of 6 lxc-containers op, o.a. een mysql-server en een influx-server voor wat sensor-logging en verder nas om films naar appletv te streamen en muziek naar bluesound.
Daarnaast time-machine backups van 2 computers (ik vermoed dat dat het grootste deel van de data in de cache is, aangezien time machine op een netwerk-schijf uit een enorme berg een 8MB-bestanden bestaat).

Leuk die 38% hit rate maar ik ben benieuwd of je er iets van zou merken als je L2ARC uit zou zetten. Ondertussen ben je wel een SSD aan het 'verstoken'. Gelukkig zijn ze niet meer zo duur, maar toch.

Die TimeMachine backups worden misschien iets vlotter gedraaid (snellere response) maar dat vecht misschien nu tegen je VMs (die mogelijk niet zo heel hard hoeven te werken).

Het punt is een beetje dat de metadata voor je L2ARC cache die nu in je RAM zit ook voor je VMs gebruikt had kunnen worden voor extra ARC caching. Dus wat is wijsheid?

Ik bedoel het niet verkeerd, maar ik merk hoe makkelijk mensen (waaronder ikzelf!) zichzelf voor de gek kunnen houden, maar hoe zit het werkelijk? Hoe zit het echt?

Heeft een L2ARC echt zin voor de gemiddelde tweaker hier?

Of kan een Tweaker dat geld voor een (extra) SSD beter aan wat extra RAM besteden *als* caching helpt?

En dan nog: die SSD ruimte die je aan L2ARC besteed had je ook aan de VMs voor storage kunnen geven en dan had je een stuk minder writes op je SSD gehad, voor prima latency.

Als je de juiste storage laag kiest voor de juiste toepassing, ben je niet afhankelijk van caching. En ik durf te wedden dat die caching uiteindelijk voor onvoorspelbare latency (hevige fluctuaties) zorgt. Nu draaien de meeste mensen hier geen bedrijfsworkloads, maar ik denk dat het idee wel duidelijk is.

Ik krijg een beetje het idee dat ik advocaat-van-de-duivel speel als het om ZFS gaat, ook al gebruik ik het zelf ook. Maar ik kan me er niet aan ontrekken dat L2ARC iets is wat mensen by default beter niet kunnen inzetten en alleen inschakelijk als er een hele goede reden is waarom het ze zou helpen (daadwerkelijk testen met iets wat je doet).

[BugBoy]

Kan ik een oude FreeBSD installatie overschrijven met Ubuntu Server 2020.04 en gewoon mijn FreeBSD pool mounten? Ik kan er niet echt wat over vinden.

[player-x]

FireDrunk schreef op dinsdag 28 april 2020 @ 18:57:
Wat erg lastig is, is dat ik sommige torrents erg lang seed.

Daar gebruik ik aparte 2.5'' 1TB (tijdelijk dl) en 2TB (klaar dl) schijven voor, waar ik de dingen op laat staan die ik wil seeden.

Die dingen zijn super zuinig en goedkoop, en heb uiteraard mijn ram cache zo groot mogelijk gemaakt, en de schijven leven nu al +5j of zo, en gaat hij dood, jammer dan.

[ Voor 6% gewijzigd door player-x op 29-04-2020 02:12 ]

[FireDrunk]

Mijn hele pool bestaat al uit 2.5" schijven. Nadeel is dat het SMR schijven zijn. Ze werken prima, maar write performance is zoals verwacht niet erg goed.

Met ontlasten bedoel ik dus ook niet dat ik ze in spindown zou willen doen. Maar meer dat ik ze minder reads en writes zou willen laten doen.

En manueel torrents verplaatsen is echt niet aan mij besteed dat gaat allemaal automatisch met software. Ik seed tot een bepaalde ratio, daarna gaat de torrent offline. Soms is dat praktisch oneindig.

[CurlyMo]

@BugBoy Meestal wel ja, probeer het anders eerst eens met een livecd.

[player-x]

FireDrunk schreef op woensdag 29 april 2020 @ 06:47:
Maar meer dat ik ze minder reads en writes zou willen laten doen.

Dan nog steeds daarvoor werkt aparte tijdelijke schijven prima.

En manueel torrents verplaatsen is echt niet aan mij besteed

Om een beetje orde te houden is dat imho toch echt wel nodig, maar dan nog kan een gedeelte ook nog steeds geautomatiseerd worden.

Ik seed ook tot een bepaalde ratio, daarna ongeveer 1x per 1~2 maanden verplaats ik handmatig, torrents die de ratio hebben gehaald naar een tijdelijke folder in het permanente archief.

Als ze dan daar staan daar draai ik een script die bv series in de juiste folder plaatst, 10x per/j 15min werk.

Ook kijk we meestal toch de nieuwe downloads vanaf de tijdelijke download schijf, daardoor hoeft de array ook weer minder te draaien.

[ocaj]

Q schreef op dinsdag 28 april 2020 @ 23:57:
[...]


Leuk die 38% hit rate maar ik ben benieuwd of je er iets van zou merken als je L2ARC uit zou zetten. Ondertussen ben je wel een SSD aan het 'verstoken'. Gelukkig zijn ze niet meer zo duur, maar toch.

Valt op zich wel mee denk ik. Ik heb wel bewust de Pro-versie van de Samsung Evo 860 er in zitten (256GB), die zou wat meer writes aan moeten kunnen. Systeem draait vanaf de kerstvakantie en de ssd heeft nu ca 3,5TB geschreven. De 860Pro zou 300TB moeten kunnen schrijven, dus dan kan ik nog zo'n 20 jaar vooruit.

Het punt is een beetje dat de metadata voor je L2ARC cache die nu in je RAM zit ook voor je VMs gebruikt had kunnen worden voor extra ARC caching. Dus wat is wijsheid?

Ik bedoel het niet verkeerd, maar ik merk hoe makkelijk mensen (waaronder ikzelf!) zichzelf voor de gek kunnen houden, maar hoe zit het werkelijk? Hoe zit het echt?

Heeft een L2ARC echt zin voor de gemiddelde tweaker hier?

Goede vraag. Ontbreekt me helaas een beetje aan de tijd om een gedegen onderzoek te doen.

Uiteraard is de normale ARC beter. Daarom heb ik ook 32GB in mijn server zitten, waarvan ik 23GB aan ARC toegekend heb. Proxmox + momenteel 6 stuks LXContainers gebruiken ongeveer 6GB, dus dan heb ik nog ca. 3GB vrij.

Voor mij is het vrij simpel: Alles wat uit de SSD komt is winst. Ik heb een paar keer mijn zpool wat vol laten lopen (>95%), dus soms hoor ik de schijven behoorlijk rammelen in de meterkast bij veel random access vanwege fragmentatie. Dan scheelt het een stuk als de L2ARC dat kan ontlasten bij de meest gebruikte data voor zover die niet in de ARC past.

Of kan een Tweaker dat geld voor een (extra) SSD beter aan wat extra RAM besteden *als* caching helpt?

RAM (ARC) s natuurlijk altijd beter dan een SSD-cache (L2ARC). Mijn server kan max 32GB in, "dus" dat zit er in.

En dan nog: die SSD ruimte die je aan L2ARC besteed had je ook aan de VMs voor storage kunnen geven en dan had je een stuk minder writes op je SSD gehad, voor prima latency.

Ik gebruik de SSD eigenlijk helemaal niet voor storage. Ik heb er ook maar een enkele SSD in zitten voor proxmox + slog + cache. Alle storage staat op mijn zraid-pool (3x6TB) waar ik backups van maak. Backups van proxmox + de LXContainers staan ook op de zraid, dus die SSD kan falen zonder dat ik data kwijt raak (alleen wat tijd om alles weer opnieuw in te richten). Maar de containers hebben dus nauwelijks I/O (alleen wat logfiles etc).

Ik krijg een beetje het idee dat ik advocaat-van-de-duivel speel als het om ZFS gaat, ook al gebruik ik het zelf ook. Maar ik kan me er niet aan ontrekken dat L2ARC iets is wat mensen by default beter niet kunnen inzetten en alleen inschakelijk als er een hele goede reden is waarom het ze zou helpen (daadwerkelijk testen met iets wat je doet).

Eens, ik monitor dus wel de hit-ratio's. ARC is perfect, hit ratio >99,9%, dus dat doet echt wel wat. L2ARC is met 38% hit rate denk ik niet onaardig, maar wellicht niet per se nodig. Maar ach, de kleinste 860 Pro was 256GB, terwijl ik die ruimte in de verste verte niet nodig heb, dus als je die ruimte toch hebt....

[Q]

ocaj schreef op woensdag 29 april 2020 @ 22:36:
[...]


Valt op zich wel mee denk ik. Ik heb wel bewust de Pro-versie van de Samsung Evo 860 er in zitten (256GB), die zou wat meer writes aan moeten kunnen. Systeem draait vanaf de kerstvakantie en de ssd heeft nu ca 3,5TB geschreven. De 860Pro zou 300TB moeten kunnen schrijven, dus dan kan ik nog zo'n 20 jaar vooruit.


[...]


Goede vraag. Ontbreekt me helaas een beetje aan de tijd om een gedegen onderzoek te doen.

Uiteraard is de normale ARC beter. Daarom heb ik ook 32GB in mijn server zitten, waarvan ik 23GB aan ARC toegekend heb. Proxmox + momenteel 6 stuks LXContainers gebruiken ongeveer 6GB, dus dan heb ik nog ca. 3GB vrij.

Voor mij is het vrij simpel: Alles wat uit de SSD komt is winst. Ik heb een paar keer mijn zpool wat vol laten lopen (>95%), dus soms hoor ik de schijven behoorlijk rammelen in de meterkast bij veel random access vanwege fragmentatie. Dan scheelt het een stuk als de L2ARC dat kan ontlasten bij de meest gebruikte data voor zover die niet in de ARC past.


[...]

RAM (ARC) s natuurlijk altijd beter dan een SSD-cache (L2ARC). Mijn server kan max 32GB in, "dus" dat zit er in.


[...]

Ik gebruik de SSD eigenlijk helemaal niet voor storage. Ik heb er ook maar een enkele SSD in zitten voor proxmox + slog + cache. Alle storage staat op mijn zraid-pool (3x6TB) waar ik backups van maak. Backups van proxmox + de LXContainers staan ook op de zraid, dus die SSD kan falen zonder dat ik data kwijt raak (alleen wat tijd om alles weer opnieuw in te richten). Maar de containers hebben dus nauwelijks I/O (alleen wat logfiles etc).


[...]


Eens, ik monitor dus wel de hit-ratio's. ARC is perfect, hit ratio >99,9%, dus dat doet echt wel wat. L2ARC is met 38% hit rate denk ik niet onaardig, maar wellicht niet per se nodig. Maar ach, de kleinste 860 Pro was 256GB, terwijl ik die ruimte in de verste verte niet nodig heb, dus als je die ruimte toch hebt....

Ik gebruik jouw situatie een beetje als illustratie, maar het gaat mij vooral om het algemene punt. Je hebt je spulletjes nu al, jij bent gesetteld. Dat is prima.

Mijn punt is een beetje dat het OS ook gewoon cached, dus als je wat extra RAM van je ARC aan je containers geeft (of het OS van de containers) is dat misschien wel effectiever en zijn je apps niet zo afhankelijk van de storage caching. Idealiter past een database geheel in memory, zodat storage alleen nog een punt voor writes is. Je wil het liefst je storage caching gewoon geheel vermijden als het kan.

Een ~40% hit ratio van je L2ARC betekent dat 60% van je read IOPs gewoon naar disk gaan en dat je effectief gewoon de latency van je disk storage 'voelt'. Ik durf te wedden dat dit betekent dat je het voordeel van die 40% benefit van je SSD dus niet ervaart.

Ik heb hier niets gemeten, misschien deugt mijn redenatie niet, maar het gaat mij om de concepten/principes achter het verhaal, en ik pak deze situatie als voorbeeld om er over na te denken. Ik ben benieuwd hoe anderen hier naar kijken (of dat het ze niet zoveel uitmaakt).

Als ik theoretisch nu een ZFS doos op zou zetten met VMs en bulk storage dan zou de configuratie heel simpel zijn.

Twee pools:
1 - 2 x SSD in mirror voor VMs in pool 1
2 - N+1(2) x HDDs in RAIDZ(2) voor bulk storage in pool 2

Super simpel, geen L2ARC, kleine ARC en RAM zoveel mogelijk geven aan VMs.

[ Voor 6% gewijzigd door Q op 30-04-2020 00:32 ]

[CurlyMo]

@Q Jouw redenatie heb ik hier ook toegepast. Een deel van mijn data staat ook op de ssd's zoals software development en download mappen. Vluchtige bestanden gaan dus allemaal daar naartoe. OS logfiles, tijdelijke compilatie bestanden, tijdelijke downloads totdat ik die verplaats. De grote bulk bestanden staan op de hdd's zoals foto's en video's. Dat werkt ook beter met smr schijven.

[FireDrunk]

Q schreef op donderdag 30 april 2020 @ 00:24:
[...]


Ik gebruik jouw situatie een beetje als illustratie, maar het gaat mij vooral om het algemene punt. Je hebt je spulletjes nu al, jij bent gesetteld. Dat is prima.

Mijn punt is een beetje dat het OS ook gewoon cached, dus als je wat extra RAM van je ARC aan je containers geeft (of het OS van de containers) is dat misschien wel effectiever en zijn je apps niet zo afhankelijk van de storage caching. Idealiter past een database geheel in memory, zodat storage alleen nog een punt voor writes is. Je wil het liefst je storage caching gewoon geheel vermijden als het kan.

Een ~40% hit ratio van je L2ARC betekent dat 60% van je read IOPs gewoon naar disk gaan en dat je effectief gewoon de latency van je disk storage 'voelt'. Ik durf te wedden dat dit betekent dat je het voordeel van die 40% benefit van je SSD dus niet ervaart.

Ik heb hier niets gemeten, misschien deugt mijn redenatie niet, maar het gaat mij om de concepten/principes achter het verhaal, en ik pak deze situatie als voorbeeld om er over na te denken. Ik ben benieuwd hoe anderen hier naar kijken (of dat het ze niet zoveel uitmaakt).

Als ik theoretisch nu een ZFS doos op zou zetten met VMs en bulk storage dan zou de configuratie heel simpel zijn.

Twee pools:
1 - 2 x SSD in mirror voor VMs in pool 1
2 - N+1(2) x HDDs in RAIDZ(2) voor bulk storage in pool 2

Super simpel, geen L2ARC, kleine ARC en RAM zoveel mogelijk geven aan VMs.

Hier mis je denk ik een belangrijk punt. Stel ik heb data die normaal van disk positie 0 komen, en ik heb daarnaast een extra lees actie op positie 9 miljoen. Als de data van posititie 0 uit cache kan komen, scheelt het behoorlijk in de latency van de schijf omdat de kop minder ver hoeft te verplaatsen.

Minder concurrency helpt in absolute latency getallen.
Om jouw getallen te gebruiken:
De latency van de resterende 60% zal gemiddeld lager zijn, omdat er waarschijnlijk minder head movement is.

Mooi voorbeeld: Gister deed ik een kopie van 35GB van mijn array naar een USB stick op mijn lokale machine. Dat ging zonder concurrency met ~30MB/s (max van de USB stick). Toen ik tegelijkertijd op de array ging bladeren, en nog wat andere acties ging doen, kakte die snelheid in tot 0 bytes/seconde in sommige gevallen.

De concurrency was zo hoog, dat de data gewoon niet te leveren was.

[Q]

FireDrunk schreef op donderdag 30 april 2020 @ 10:00:
[...]

Hier mis je denk ik een belangrijk punt. Stel ik heb data die normaal van disk positie 0 komen, en ik heb daarnaast een extra lees actie op positie 9 miljoen. Als de data van posititie 0 uit cache kan komen, scheelt het behoorlijk in de latency van de schijf omdat de kop minder ver hoeft te verplaatsen.

Minder concurrency helpt in absolute latency getallen.
Om jouw getallen te gebruiken:
De latency van de resterende 60% zal gemiddeld lager zijn, omdat er waarschijnlijk minder head movement is.

Bij een 60% hit percentage op de disk, zal de disk latency voornamelijk bepalend zijn. Ik ben het er mee eens dat de cache mogelijk wel verbetering geeft, maar het gedrag wordt heel grillig en we blijven gemiddeld in de milliseconden range qua latency.

Stel je SSD read latency is 200 microseconden en je harde schijven doen 12 miliseconden.
Dan is je gemiddelde latency ~6 milliseconden, een verbetering (halvering). Maar je zit qua latency nog steeds in het domein van harde schijven, niet van SSDs. Dat is een verbetering, maar laat je niet misleiden: het latency patroon is heel grillig / onvoorspelbaar / inconsistent.

Een L2ARC vind ik daarom in veruit de meeste gevallen eigenlijk 'zonde' want door gewoon die SSD als opslag voor je VMs te gebruiken (of iets vergelijkbaars) krijg je een orde-van-grote betere latency en die latency is ook nog eens consistent.

Zeker straks met persistente L2ARC is het niet verkeerd om wat flash van je SSD boot drive (als voorbeeld) in te zetten.
Maar als je een Mirror draait voor je boot OS kun je beter gewoon je VMs rechtstreeks op de SSDs zetten.

Heb je dat niet, dan helpt L2ARC wel wat en met de huidige SSDs maak ik me om eerlijk te zijn niet zo druk meer om de wear/tear van SSDs, dat zit wel goed.

Maar je bent altijd beter af met dedicated SSD storage voor je VMs en dat soort toepassingen. Ik zou er zelf dus nooit voor kiezen om op een L2ARC cache te leunen of dat in te zetten.

Mooi voorbeeld: Gister deed ik een kopie van 35GB van mijn array naar een USB stick op mijn lokale machine. Dat ging zonder concurrency met ~30MB/s (max van de USB stick). Toen ik tegelijkertijd op de array ging bladeren, en nog wat andere acties ging doen, kakte die snelheid in tot 0 bytes/seconde in sommige gevallen.

De concurrency was zo hoog, dat de data gewoon niet te leveren was.

Dat komt waarschijnlijk door die bottleneck bij ZFS dat je de random IOPS performance krijgt van 1 disk* in een VDEV, ik weet even niet meer wat jouw setup is. Geen L2ARC gaat je daarbij redden tenzij 100% uit je cache komt.

*Dit is zo'n vuistregel die ik ooit ergens heb opgepikt, maar ik weet niet meer waar.

Zou een L2ARC geholpen hebben? Alleen als de bulk van je data al in de cache zat.

[ Voor 6% gewijzigd door Q op 30-04-2020 12:37 ]

[ph0t0nix]

Ik ben mijn mijn ZFS thuisservertje van een L2ARC afgestapt. Ik had te lage hit ratio's, zeker met 32GB RAM (3/4 voor de ARC). Op mijn PC mount ik mijn homedir via NFS vanaf de server. Inmiddels heb ik daar twee pools, een met 2 SSDs in mirror voor de meestgebruikte (homedir) data, en een RAIDZ1 van 3× 4TB voor minder vaak gebruikte en grote data als foto's en backups.

Heeft iemand al ervaring met 'special devices'? Deze functionaliteit bestaat sinds ZoL 0.8 en betekent in eigenlijk niets anders dan dat je een VDEV met snelle schijven (SSDs) toevoegt aan een (langzame) pool. De metadata en evt. (kleine) files/blocks komen dan op de SSD terecht.

Zie bijvoorbeeld deze algemene beschrijving in de Proxmox VE wiki, deze discussie in het Proxmox VE forum, en deze discussie in het forum van ServerTheHome.

Hopelijk heb ik deze week nog tijd om de special devices uit te proberen op een testmachientje met 3×4TB spinning disks en een SSD.

[FireDrunk]

Q schreef op donderdag 30 april 2020 @ 12:35:
[...]


Bij een 60% hit percentage op de disk, zal de disk latency voornamelijk bepalend zijn. Ik ben het er mee eens dat de cache mogelijk wel verbetering geeft, maar het gedrag wordt heel grillig en we blijven gemiddeld in de milliseconden range qua latency.

Stel je SSD read latency is 200 microseconden en je harde schijven doen 12 miliseconden.
Dan is je gemiddelde latency ~6 milliseconden, een verbetering (halvering). Maar je zit qua latency nog steeds in het domein van harde schijven, niet van SSDs. Dat is een verbetering, maar laat je niet misleiden: het latency patroon is heel grillig / onvoorspelbaar / inconsistent.

Een L2ARC vind ik daarom in veruit de meeste gevallen eigenlijk 'zonde' want door gewoon die SSD als opslag voor je VMs te gebruiken (of iets vergelijkbaars) krijg je een orde-van-grote betere latency en die latency is ook nog eens consistent.

Zeker straks met persistente L2ARC is het niet verkeerd om wat flash van je SSD boot drive (als voorbeeld) in te zetten.
Maar als je een Mirror draait voor je boot OS kun je beter gewoon je VMs rechtstreeks op de SSDs zetten.

Heb je dat niet, dan helpt L2ARC wel wat en met de huidige SSDs maak ik me om eerlijk te zijn niet zo druk meer om de wear/tear van SSDs, dat zit wel goed.

Maar je bent altijd beter af met dedicated SSD storage voor je VMs en dat soort toepassingen. Ik zou er zelf dus nooit voor kiezen om op een L2ARC cache te leunen of dat in te zetten.


[...]


Dat komt waarschijnlijk door die bottleneck bij ZFS dat je de random IOPS performance krijgt van 1 disk* in een VDEV, ik weet even niet meer wat jouw setup is. Geen L2ARC gaat je daarbij redden tenzij 100% uit je cache komt.

*Dit is zo'n vuistregel die ik ooit ergens heb opgepikt, maar ik weet niet meer waar.

Zou een L2ARC geholpen hebben? Alleen als de bulk van je data al in de cache zat.

Je begrijpt mijn punt niet. Wat je zegt is allemaal correct, alleen veranderd de absolute latency van je request soms factoren door concurrency.

Als je pure random IO doet, heb je gelijk, maar dat deed ik niet, ik was sequentieel iets aan het streamen. Daardoor kan ZFS hele hoge bandbreedtes halen, omdat er gewoon track-to-track latencies en readaheads behaald kunnen worden.

Als ik ondertussen wat sporadische random lees IO tussendoor doe, gaat die latency van <1ms track-to-track naar 12ms omdat het full random IO wordt. In plaats van 600MB/s (puur sequentiele performance van mijn pool), wordt het dan < 1MB/s (en misschien zelfs wel <100KB/s), omdat het nu ineens full random IO is.

Als alleen de random io (misschien < 10%) uit L2ARC zou komen, zou de rest van de transfer ineens niet meer random zijn, maar sequentieel, waardoor de snelheid weer omhoog gaat.

[BonJonBovi]

Q schreef op dinsdag 28 april 2020 @ 18:40:

@BonJonBovi hoe is het afgelopen?

BonJonBovi schreef op dinsdag 28 april 2020 @ 20:07:
[...]

Inmiddels twee scrubs uitgevoerd, maar schijnbaar heb ik over een belangrijk deel van wat @CurlyMo had geschreven, overheen gelezen. Ik zal de status eerst clearen nu, en opnieuw scrubben. Keep you posted.

Even de beloofde terugkoppeling: Bij de eerste scrub sinds ik

code:

zfs clear

had gedaan, zijn de checksum errors niet terug gekomen gelukkig.

[CurlyMo]

BonJonBovi schreef op donderdag 30 april 2020 @ 17:55:
[...]
Even de beloofde terugkoppeling: Bij de eerste scrub sinds ik

code:

zfs clear

had gedaan, zijn de checksum errors niet terug gekomen gelukkig.

Zie je dat ZFS met de scrub iets hersteld heeft?

[Q]

FireDrunk schreef op donderdag 30 april 2020 @ 16:12:
[...]


Je begrijpt mijn punt niet. Wat je zegt is allemaal correct, alleen veranderd de absolute latency van je request soms factoren door concurrency.

Als je pure random IO doet, heb je gelijk, maar dat deed ik niet, ik was sequentieel iets aan het streamen. Daardoor kan ZFS hele hoge bandbreedtes halen, omdat er gewoon track-to-track latencies en readaheads behaald kunnen worden.

Als ik ondertussen wat sporadische random lees IO tussendoor doe, gaat die latency van <1ms track-to-track naar 12ms omdat het full random IO wordt. In plaats van 600MB/s (puur sequentiele performance van mijn pool), wordt het dan < 1MB/s (en misschien zelfs wel <100KB/s), omdat het nu ineens full random IO is.

Als alleen de random io (misschien < 10%) uit L2ARC zou komen, zou de rest van de transfer ineens niet meer random zijn, maar sequentieel, waardoor de snelheid weer omhoog gaat.

Ik lees hier niets waarmee ik het oneens ben Ik denk dat ik even niet snap wat ik niet begrijp.

[Q]

BonJonBovi schreef op donderdag 30 april 2020 @ 17:55:
[...]


[...]


Even de beloofde terugkoppeling: Bij de eerste scrub sinds ik

code:

zfs clear

had gedaan, zijn de checksum errors niet terug gekomen gelukkig.

Nog een memtest gedaan?

[rbrt]

ik heb nog weinig ervaring met ZFS, maar ik ben bezig om een linux NAS met hardware raid controller om te bouwen tot NAS met ZFS.

Een van de dingen die ik probeer in te richten (in een virtual box omgeving) is het doorzetten van ZFS foutmeldingen in ElasticSearch. Het is mij echter niet duidelijk waar zfs fouten worden opgeslagen?

Ik zie ze in journalctl niet terug. Als ik een virtuele schijf uit een zpool trek zie ik wel de DEGRADED status in 'zfs status tank' maar deze fout komt volgens mij niet terug in de Linux logs (en dus ook niet via filebeats).

Of is er een andere manier om ZFS fouten in ElasticSearch te krijgen?

[Q]

rbrt schreef op donderdag 14 mei 2020 @ 00:19:
ik heb nog weinig ervaring met ZFS, maar ik ben bezig om een linux NAS met hardware raid controller om te bouwen tot NAS met ZFS.

Een van de dingen die ik probeer in te richten (in een virtual box omgeving) is het doorzetten van ZFS foutmeldingen in ElasticSearch. Het is mij echter niet duidelijk waar zfs fouten worden opgeslagen?

Ik zie ze in journalctl niet terug. Als ik een virtuele schijf uit een zpool trek zie ik wel de DEGRADED status in 'zfs status tank' maar deze fout komt volgens mij niet terug in de Linux logs (en dus ook niet via filebeats).

Of is er een andere manier om ZFS fouten in ElasticSearch te krijgen?

Je zou de ZED daemon kunnen gebruiken om events af te vangen en door te zetten. In plaats van mailen kun je vast een ander commando / script runnen. Of met een script periodiek voor events te pollen (en met logger gewoon alsnog naar syslog te schrijven), niet mooi maar iets.

(oud artikel)

https://louwrentius.com/the-zfs-event-daemon-on-linux.html

Overigens zou ik overwegen om voor een paar tientjes een HBA te scoren en die hardware RAID kaart (welk type?) niet te gebruiken.

[ Voor 11% gewijzigd door Q op 14-05-2020 00:29 ]

[FireDrunk]

Er is een ZED -> Syslog optie, en je kan Syslog weer naar Logstash zetten, en Logstash weer laten outputten naar ElasticSearch, dat is wat 'the big corporations' vaak gebruiken (met voor thuisgebruikers minder belangrijke redenen, dingen als scalabililty enzo).

Als je puur de events in je eigen thuis knutsel ES cluster wil, kan je een plat HTTP POST scriptje schrijven en die zoals Q al aangaf, aan ZED hangen.

[ Voor 12% gewijzigd door FireDrunk op 14-05-2020 07:45 ]

[rbrt]

Bedankt! ik ga me daar eens in verdiepen! Als ik iets werkend heb zal ik dat hier zeker delen (hoewel ZFS en ELK stack voor mij nog redelijk nieuw zijn)

Q schreef op donderdag 14 mei 2020 @ 00:22:
[...]

Overigens zou ik overwegen om voor een paar tientjes een HBA te scoren en die hardware RAID kaart (welk type?) niet te gebruiken.

Het was een Dell PERC H700 met 4x 6TB in RAID5. Kaartje deed het prima maar helaas bleek eerst één schijf slechte sectoren te bevatten en later ook een tweede. Bij grote read/write acties besloot de PERC dan dat twee schijven niet deugde en draaide het virtual volume de nek om.

Alles bij elkaar een hoop problemen dus, vandaar dat ik nu zo graag vroegtijdig zie dat een schijf het loodje gaat leggen.

Overigens gaat de PERC inderdaad op V&A (kon niet geflashed worden) en is de nieuwe HBA al in huis.

[CurlyMo]

@rbrt
V&A aangeboden: Dell PERC H310 SAS/SATA controller in IT-mode (LSI 9211-8i)

[maomanna]

om de een of andere reden krijg ik het probleem niet opgelost.

Het gaat om het volgende:

code:

root@pve:/# zpool status ZFSweb2tb
  pool: ZFSweb2tb
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-4J
  scan: scrub in progress since Tue May 19 09:57:29 2020
        903G scanned at 370M/s, 270G issued at 111M/s, 903G total
        0B repaired, 29.86% done, 0 days 01:37:40 to go
config:

        NAME                     STATE     READ WRITE CKSUM
        ZFSweb2tb                DEGRADED     0     0     0
          mirror-0               DEGRADED     0     0     0
            2961524178593529822  FAULTED      0     0  1009  was /dev/sdf1
            2TB_S2H7J90B600101   ONLINE       0     0     0
            2TB_S2HGJ9EB900901   ONLINE       0     0     0

errors: No known data errors
root@pve:/# zpool replace -f ZFSweb2tb 2961524178593529822 /dev/disk/by-id/ata-SAMSUNG_HD204UI_S2H7J1CB903202
invalid vdev specification
the following errors must be manually repaired:
/dev/disk/by-id/ata-SAMSUNG_HD204UI_S2H7J1CB903202-part1 is part of active pool 'ZFSweb2tb'

De schijf die genoemd wordt "2961524178593529822" is de ata-SAMSUNG_HD204UI_S2H7J1CB903202. Maar hoe kan ik die weer goed in de pool krijgen?

Scrubben, clearen, online, offline, replace hebben niet gewerkt.
De niet -f gaf aan dat ik de -f moest gebruiken..
Hebben jullie een idee?

[ Voor 3% gewijzigd door maomanna op 19-05-2020 12:28 ]

[FireDrunk]

Wat gebeurt er als je hem gewoon een `online` geeft?

[maomanna]

Het is trouwens nu de /dev/sdh

ik krijg dan dit:

code:

root@pve:~# zpool online ZFSweb2tb 2961524178593529822
warning: device '2961524178593529822' onlined, but remains in faulted state
use 'zpool replace' to replace devices that are no longer present

Maar met een fdisk -l lijkt het erop dat hij ineens een heel andere partitie heeft.

code:

root@pve:~# fdisk -l
Disk /dev/sdh: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: SAMSUNG HD204UI
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B816B69A-5C49-4947-809D-B890D2BBC62A

Device     Start        End    Sectors  Size Type
/dev/sdh1   2048 3907028991 3907026944  1.8T Microsoft basic data


Disk /dev/sdi: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: SAMSUNG HD204UI
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5D8366A8-4609-4E90-989D-8F073B69C38F

Device     Start        End    Sectors  Size Type
/dev/sdi1   6144 3907029134 3907022991  1.8T FreeBSD ZFS


Disk /dev/sdj: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: SAMSUNG HD204UI
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 33D5B96B-A6D3-4EE5-A1FA-2E526F3CA10F

Device     Start        End    Sectors  Size Type
/dev/sdj1   6144 3907029134 3907022991  1.8T FreeBSD ZFS

[dcm360]

Aangezien het een mirror is, zou je ook de schijf nog uit de pool kunnen verwijderen, en daarna weer toevoegen.

Is de schijf zelf overigens nog wel in orde (smart-waarden)? Het zijn best oude schijven, van de 4 die ik er zelf heb zijn er onderhand 2 gesneuveld.

[FireDrunk]

/dev/sdh heeft ook niet hetzelfde aantal sectoren, weet je heel zeker dat dat de goede schijf is?
Dat is de partitie, de disk heeft wel hetzelfde aantal sectoren.

Klinkt alsof de data inderdaad gesneuveld is.

[ Voor 37% gewijzigd door FireDrunk op 19-05-2020 16:45 ]

[maomanna]

als ik de disk eruit haal, formatteer (als wat?) en dan opnieuw toevoeg aan de pool, dan kan ik iig bij de data voor een backup

dcm360 schreef op dinsdag 19 mei 2020 @ 16:26:
Is de schijf zelf overigens nog wel in orde (smart-waarden)? Het zijn best oude schijven, van de 4 die ik er zelf heb zijn er onderhand 2 gesneuveld.

De smarttest.
Heb een short test gedaan

code:

root@pve:~# smartctl -a /dev/sdi
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.3.18-3-pve] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     SAMSUNG SpinPoint F4 EG (AF)
Device Model:     SAMSUNG HD204UI
Serial Number:    S2H7J1CB903202
LU WWN Device Id: 5 0024e9 0050ee5bd
Firmware Version: 1AQ10001
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    5400 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 6
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Tue May 19 18:33:13 2020 CEST

==> WARNING: Using smartmontools or hdparm with this
drive may result in data loss due to a firmware bug.
****** THIS DRIVE MAY OR MAY NOT BE AFFECTED! ******
Buggy and fixed firmware report same version number!
See the following web pages for details:
http://knowledge.seagate.com/articles/en_US/FAQ/223571en
https://www.smartmontools.org/wiki/SamsungF4EGBadBlocks

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      ( 121) The previous self-test completed having
                                        the read element of the test failed.
Total time to complete Offline
data collection:                (21120) seconds.
Offline data collection
capabilities:                    (0x5b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 352) minutes.
SCT capabilities:              (0x003f) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   051    Pre-fail  Always       -       24
  2 Throughput_Performance  0x0026   252   252   000    Old_age   Always       -       0
  3 Spin_Up_Time            0x0023   066   064   025    Pre-fail  Always       -       10494
  4 Start_Stop_Count        0x0032   054   054   000    Old_age   Always       -       47182
  5 Reallocated_Sector_Ct   0x0033   252   252   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   252   252   051    Old_age   Always       -       0
  8 Seek_Time_Performance   0x0024   252   252   015    Old_age   Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       61484
 10 Spin_Retry_Count        0x0032   252   252   051    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       5
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       195
181 Program_Fail_Cnt_Total  0x0022   097   097   000    Old_age   Always       -       73407634
191 G-Sense_Error_Rate      0x0022   100   100   000    Old_age   Always       -       102
192 Power-Off_Retract_Count 0x0022   252   252   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0002   064   057   000    Old_age   Always       -       31 (Min/Max 10/43)
195 Hardware_ECC_Recovered  0x003a   100   100   000    Old_age   Always       -       0
196 Reallocated_Event_Count 0x0032   252   252   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0030   252   252   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0036   100   100   000    Old_age   Always       -       1
200 Multi_Zone_Error_Rate   0x002a   100   100   000    Old_age   Always       -       2
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       5
225 Load_Cycle_Count        0x0032   096   096   000    Old_age   Always       -       47190

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       90%     61483         3826240720
# 2  Extended offline    Completed: read failure       10%     60411         3826240720
# 3  Extended offline    Aborted by host               90%     60405         -
# 4  Short offline       Completed: read failure       90%     60404         3826240720
# 5  Short offline       Completed: read failure       90%     60404         3826240720

SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Completed_read_failure [90% left] (0-65535)
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Wel vind ik dit nog: https://www.seagate.com/n...are-patchupdate-223571en/ al vraag ik mij af hoe dat dan werkt

[ Voor 97% gewijzigd door maomanna op 19-05-2020 18:41 ]

[FireDrunk]

De pool is toch gewoon online? Het is een 3-way mirror? Dan kan je gewoon een backup maken? Of snap ik niet wat je bedoeld?

[maomanna]

waarschijnlijk omdat ik geen zin heb om de schijven te vervangen en ik t weer goed werkend wil hebben met dezelfde hardware 😂 #krent

[ Voor 14% gewijzigd door maomanna op 20-05-2020 08:29 ]

[FireDrunk]

Ahzo, je pool werkt gewoon, maar je wil een kapotte schijf terug de pool in rammen.

Tja, #krent

[Thralas]

maomanna schreef op dinsdag 19 mei 2020 @ 12:46:
Maar met een fdisk -l lijkt het erop dat hij ineens een heel andere partitie heeft.

Met een afwijkende grootte en een Microsoft partition type?

Dat gebeurt niet zomaar. Je vergist je of er is iets anders onhandigs gebeurd.

Zou dat toch even verder uitzoeken voor je andere dingen doet. Wat is /dev/sdh* voor filesystem/partlayout volgens file of wipefs /dev/sdh* (niet zo eng als het klinkt als je hem zonder -a aanroept)?

maomanna schreef op dinsdag 19 mei 2020 @ 17:29:
als ik de disk eruit haal, formatteer (als wat?) en dan opnieuw toevoeg aan de pool,

Heb je je SMART output goed bekeken? Je hebt een bad sector. Die zou ik even zeroen en dan een nieuwe extended test doen om je ervan te vergewissen dat de disk verder oké is.

dan kan ik iig bij de data voor een backup

Je kunt nu toch ook bij de data? Je pool is online.

[maomanna]

FireDrunk schreef op woensdag 20 mei 2020 @ 08:35:
Ahzo, je pool werkt gewoon, maar je wil een kapotte schijf terug de pool in rammen.

Tja, #krent

haha ja, alleen dikke pech, want mijn andere 2 pools (heb er 3), zijn er ook disks die piepen. 1x 8tb in raid z1, 2x 4tb in raid z1, 1x 2tb in raid z2. Alles tegelijk hehe

Ik zocht eigenlijk meer een bevestiging van mn gevoel en dat hebben jullie gegeven. dus zal t toch maar echt gaan doen.

Wat doen jullie met die kapotte disks?

Thralas schreef op woensdag 20 mei 2020 @ 08:59:
[...]


Met een afwijkende grootte en een Microsoft partition type?

Dat gebeurt niet zomaar. Je vergist je of er is iets anders onhandigs gebeurd.

Ik heb de disk ooit via een usb dock aangesloten op een windowsmachine, niet geformatteerd. doel was om met hd tune pro de disk te checken. ik denk dat t daar dan fout is gegaan.

Zou dat toch even verder uitzoeken voor je andere dingen doet. Wat is /dev/sdh* voor filesystem/partlayout volgens file of wipefs /dev/sdh* (niet zo eng als het klinkt als je hem zonder -a aanroept)?

eens uitzoeken idd.

Heb je je SMART output goed bekeken? Je hebt een bad sector. Die zou ik even zeroen en dan een nieuwe extended test doen om je ervan te vergewissen dat de disk verder oké is.

ehh.. hoe doe je dat?

[ Voor 58% gewijzigd door maomanna op 20-05-2020 09:09 ]

[Thralas]

maomanna schreef op woensdag 20 mei 2020 @ 09:04:
Wat doen jullie met die kapotte disks?

Ligt eraan hoe kapot hij is.

Voor thuisgebruik zou ik niet perse wakker liggen van een incidentele bad sector. Hamvraag is of het daarbij blijft of er meer opduikt. Als dat het geval is, je onderbuikgevoel gebruiken.

ehh.. hoe doe je dat?

Gewoon met dd

Uitlezen:

dd if=/dev/sdi bs=512 skip=3826240720 count=1 | xxd

Overschrijven:

dd if=/dev/zero of=/dev/sdi bs=512 seek=3826240720 count=1

Het is me nu niet meer duidelijk wat bij welke pool hoort, maar houd er voor de integriteit van je pool wel even rekening mee dat uitlezen waarschijnlijk een I/O timeout oplevert. Als zfs die disk nu ook nog in een pool heeft zitten dan zou hij hem er wel eens uit kunnen gooien.

Zie het als een alternatief voor een (trage) volledige wipe, dan is het ook geen probleem als ik me verreken

Eventueel even tijdelijk offline zetten in de pool. Bad sector wipen, daarna SMART output controleren of de pending sectors weer op 0 staat. Vervolgens een nieuwe test doen om uit te sluiten dat er meer rot is.

Daarna terug in de pool en scribben om de zeroed sector te laten vervangen. Misschien ook handig om vooraf te doen om zeker te zijn dat andere disks niet nu óók bad sectors hebben.

[InflatableMouse]

Ik draai momenteel 2 pools met 3 disks 4TB in raidz1.

Ik wil van die twee pools af en naar een meer redundant systeem, maar ook betere performance. Ik kan alleen niet alle schijven leeg halen dus ik kan dit zelf niet goed testen.

Wat is beter qua performance, 6 disks in raidz2 of 3 disks in stripeset + mirror? Het zou fijn zijn als je je mening ook een beetje kan onderbouwen of eventueel (kon dit zelf niet vinden) er een bron voor hebt.

Voor de 6-disk raidz2, ik zou dan nu alles op 1 pool kunnen zetten en deze uitbreiden met de 3 disks van de andere pool, moet ik nog ergens specifiek rekening mee houden?

Voor de 3-disk stripeset + mirror, ik zou dan een pool leeg kunnen maken, stripeset van maken en alles daarheen zetten, dan de overige 3 disks toevoegen als mirror. Zelfde vraag, specifiek hier nog ergens rekening mee houden?

Uiteraard van alles wat ik perse niet kwijt wil raken heb ik al backups. De rest zou jammer zijn (nog steeds echt liever niet!) maar dat is dan meer gevalletje pech.

[RobertMe]

InflatableMouse schreef op dinsdag 26 mei 2020 @ 18:02:
Ik draai momenteel 2 pools met 3 disks 4TB in raidz1.

Ik wil van die twee pools af en naar een meer redundant systeem, maar ook betere performance. Ik kan alleen niet alle schijven leeg halen dus ik kan dit zelf niet goed testen.

Wat is beter qua performance, 6 disks in raidz2 of 3 disks in stripeset + mirror? Het zou fijn zijn als je je mening ook een beetje kan onderbouwen of eventueel (kon dit zelf niet vinden) er een bron voor hebt.

Voor de 6-disk raidz2, ik zou dan nu alles op 1 pool kunnen zetten en deze uitbreiden met de 3 disks van de andere pool, moet ik nog ergens specifiek rekening mee houden?

Voor de 3-disk stripeset + mirror, ik zou dan een pool leeg kunnen maken, stripeset van maken en alles daarheen zetten, dan de overige 3 disks toevoegen als mirror. Zelfde vraag, specifiek hier nog ergens rekening mee houden?

Uiteraard van alles wat ik perse niet kwijt wil raken heb ik al backups. De rest zou jammer zijn (nog steeds echt liever niet!) maar dat is dan meer gevalletje pech.

Wat beter en sneller/performanter is weet ik niet. Maar qua redundancy: bij RAIDZ2 kunnen er maximaal twee schijven uitvallen zonder dataverlies, omdat je de twee parity disks hebt. Bij de mirror + stripe kunnen er één t/m drie schijven uitvallen zonder dataverlies. Als je immers disk 1 & 2 in een mirror zet, en die striped met 3 & 4 en 5 & 6 dan heb je best een probleem als een mirror uitvalt (dus 1 & 2, of 3 & 4, of 5 & 6 tegelijkertijd uitvallen). Potentieel kunnen er bij een stripe + mirror dus meer schijven uitvallen, maar je loopt ook het risico dat er bij twee falende schijven al dataverlies is.