Het grote ZFS topic

[nero355]

Extera schreef op donderdag 30 september 2021 @ 23:54:
Ik heb nu dus de data disk offline gehaald en vervangen. Ik ben benieuwd wat er gebeurd als hij klaar is... volgens mij is de spare dan weer spare

ZFS Rule #1 : You don't remove defect storage devices until the rebuild with the new replacement storage device is done!

Verder vind ik dit echt een zooitje :

code:

gptid/1037cdd6-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
gptid/3fb9a79f-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
gptid/3f209f6e-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
spare-3                                       ONLINE       0     0    54
 gptid/5f6f546b-2238-11ec-a5dc-000c29d1be09  ONLINE       0     0     0  (resilvering)
 gptid/b990b874-3584-11eb-845b-000c29d1be09  ONLINE       3   395     0  (resilvering)
gptid/41ff4144-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
gptid/12568da2-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
gptid/114c6974-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
gptid/151dab3b-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
gptid/0f6dc72a-8095-11e5-b3dc-0060dd47d1cb    ONLINE       0     0     0
gptid/393af75a-818d-11e5-b3dc-0060dd47d1cb    ONLINE       0     0     0
spares
 gptid/b990b874-3584-11eb-845b-000c29d1be09      INUSE     currently in use

Dat kan je echt veel overzichtelijker maken door alles VOORAF goed te labelen!

NOFI, maar het ziet er echt uit als een setup die is gemaakt door iemand die ooit een of andere Tutorial/HowTo heeft gevolgd onder het motto "Als het maar straks werkt en als er wat misgaat dan zie ik tegen die tijd wel hoe ik dat oplos!"

[Extera]

Tja, ik heb me ooit goed ingelezen op ZFS, maar deze setup draait inmiddels al weer een jaar of 6.
als er dan wat stuk gaat is de kennis redelijk weggezakt.

Als ik mij niet vergis is dit hoe de pool is gelabeld door FreeNAS.

ZFS Rule #1 : You don't remove defect storage devices until the rebuild with the new replacement storage device is done!

Makkelijk gezegd, maar al mijn HDD poorten zitten vol

[Brahiewahiewa]

Extera schreef op vrijdag 1 oktober 2021 @ 16:37:
...
Makkelijk gezegd, maar al mijn HDD poorten zitten vol

Hang je er tijdelijk een USB disk aan

[nero355]

Extera schreef op vrijdag 1 oktober 2021 @ 16:37:
Makkelijk gezegd, maar al mijn HDD poorten zitten vol

Dit :

Brahiewahiewa schreef op vrijdag 1 oktober 2021 @ 18:23:
Hang je er tijdelijk een USB disk aan

Alleen effe erop letten dat de desbetreffende USB naar SATA Controller de HDD volledig doorgeeft zonder allerlei rare fratsen, maar dat zit bij de meeste modellen wel goed over het algemeen!

[RobertMe]

nero355 schreef op vrijdag 1 oktober 2021 @ 18:32:
[...]

Dit :

[...]

Alleen effe erop letten dat de desbetreffende USB naar SATA Controller de HDD volledig doorgeeft zonder allerlei rare fratsen, maar dat zit bij de meeste modellen wel goed over het algemeen!

De WD shuckable schijven (/controllers) dus niet. De USB-SATA controller geeft iets minder sectoren door dan de HDD daadwerkelijk bevat. Gevolg is dan ook dat het OS de weg kwijt zal raken als je wisselt. O.a. omdat ik meen dat de partitietabel zowel voor als achteraan op de schijf staat. Formateer je de HDD dus "als extern" en bouw je hem daarna in dan ontbreekt de (backup) partitietabel op het eind / wordt er iets gelezen dat op een corrupte partitietabel lijkt en heb je dus een probleem. En hetzelfde dus als je andersom wisselt.

[nero355]

RobertMe schreef op vrijdag 1 oktober 2021 @ 18:52:
De WD shuckable schijven (/controllers) dus niet.

Ik zat al op je reply te wachten omdat ik weet dat jij daar ervaring mee hebt

De USB-SATA controller geeft iets minder sectoren door dan de HDD daadwerkelijk bevat. Gevolg is dan ook dat het OS de weg kwijt zal raken als je wisselt. O.a. omdat ik meen dat de partitietabel zowel voor als achteraan op de schijf staat. Formateer je de HDD dus "als extern" en bouw je hem daarna in dan ontbreekt de (backup) partitietabel op het eind / wordt er iets gelezen dat op een corrupte partitietabel lijkt en heb je dus een probleem. En hetzelfde dus als je andersom wisselt.

In dit geval zou ik dus een universele externe behuizing aanraden, maar goed om te weten waar het precies fout gaat!

Ik vraag me wel gelijk af of je dat niet met wat DD trucjes zou kunnen fixen als je er echt flink tegenaan zou lopen en geen andere keuze zou hebben

[Thralas]

Volgens mij is het meest precieze antwoord bij WD: hangt ervanaf.

Als een paar sectoren worden overgeslagen is dat niet zo erg, kwestie van een nieuwe GPT schrijven. Tweede probleem: je moet wel genoeg sectoren overhouden zolang de disk in de enclosure zit - als je OpenZFS je disks normaliter laat partitioneren dan neemt hij wat marge achteraan de disk waarmee je dit soort fratsen kunt ondervangen.

Een groter probleem is dat sommige WD enclosures ook de disk versleutelen (zo uit het hoofd waren dat enkel de My Books). In dat geval gaat het niet werken.

[RobertMe]

nero355 schreef op vrijdag 1 oktober 2021 @ 19:09:
Ik vraag me wel gelijk af of je dat niet met wat DD trucjes zou kunnen fixen als je er echt flink tegenaan zou lopen en geen andere keuze zou hebben

Dat ligt waarschijnlijk ook eraan welke kant je op gaat? Als je hem gepartioneerd hebt zonder USB controller dan heb je daarna minder sectoren en dus sowieso "pech". Omdat je dan de partitietabel van "op het eind" een stukje naar voren moet halen en daarmee juist de partitietabel over een stukje van een partitie gaat zetten.

Zelf heb ik op een gegeven moment "just to be sure" een X aantal keren heen en weer gewisseld en "iets" gedaan met ZFS of fdisk (/een van de andere tools) waarna ik de pool kon lezen met en zonder USB controller. Maar ik heb al geen idee meer wat ik toen gedaan heb en of het daadwerkelijk goed gaat weet ik ook niet.
Maar die HDD heb ik uiteindelijk 1x beschreven met een send & receive met als plan om periodiek een offline backup te maken, maar HDD is nooit meer aangesloten geweest

[Extera]

na de replacement van de data disk is de pool er zo uitgekomen

code:

 root@claustofobia:~ # zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Online the device using 'zpool online' or replace the device with
        'zpool replace'.
  scan: resilvered 1.83T in 11:06:29 with 0 errors on Fri Oct  1 10:56:35 2021
config:

        NAME                                              STATE     READ WRITE CKSUM
        tank                                              DEGRADED     0     0     0
          raidz2-0                                        DEGRADED     0     0     0
            gptid/1037cdd6-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/3fb9a79f-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
            gptid/3f209f6e-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
            spare-3                                       DEGRADED     0     0     0
              gptid/5f6f546b-2238-11ec-a5dc-000c29d1be09  ONLINE       0     0     0
              gptid/b990b874-3584-11eb-845b-000c29d1be09  OFFLINE      0     0     0
            gptid/41ff4144-ebb0-11e2-9bc2-00505690dd7d    ONLINE       0     0     0
            gptid/12568da2-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/114c6974-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/151dab3b-5568-11e4-b8aa-0060dd47d1cb    ONLINE       0     0     0
            gptid/0f6dc72a-8095-11e5-b3dc-0060dd47d1cb    ONLINE       0     0     0
            gptid/393af75a-818d-11e5-b3dc-0060dd47d1cb    ONLINE       0     0     0
        spares
          gptid/b990b874-3584-11eb-845b-000c29d1be09      AVAIL

Er staat niet echt belangrijke data op deze pool, maar toch fix ik hem het liefst zonder de boel te slopen.
Ik krijg die spare er echter niet meer uit (via de freenas gui tenminste niet)

Ik heb er van geleerd, zal geen hot spare meer gebruiken in de toekomst, alleen ben wel benieuwd hoe ik de pool nu weer healty krijg Hulp wordt zeer gewaardeerd

[ Voor 13% gewijzigd door Extera op 02-10-2021 00:06 ]

[RudolfR]

@Extera

Misschien staat hier wat tussen:
https://serverfault.com/q...ce-spare-replacement-done

[Thralas]

Kun je 'm niet gewoon detachen:

zpool detach tank gptid/b990b874-3584-11eb-845b-000c29d1be09

Verder zou ik ook onderzoeken waar al die errors nu vandaan kwamen - dwz. bekijk de kernel logs en SMART. Vooral de write errors lijken me vreemd.

[Extera]

Thralas schreef op zaterdag 2 oktober 2021 @ 10:10:
Kun je 'm niet gewoon detachen:

zpool detach tank gptid/b990b874-3584-11eb-845b-000c29d1be09

Verder zou ik ook onderzoeken waar al die errors nu vandaan kwamen - dwz. bekijk de kernel logs en SMART. Vooral de write errors lijken me vreemd.

Thanks!

code:

root@claustofobia:~ # zpool status -v tank
  pool: tank
 state: ONLINE
  scan: resilvered 1.83T in 11:06:29 with 0 errors on Fri Oct  1 10:56:35 2021
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/1037cdd6-5568-11e4-b8aa-0060dd47d1cb  ONLINE       0     0     0
            gptid/3fb9a79f-ebb0-11e2-9bc2-00505690dd7d  ONLINE       0     0     0
            gptid/3f209f6e-ebb0-11e2-9bc2-00505690dd7d  ONLINE       0     0     0
            gptid/5f6f546b-2238-11ec-a5dc-000c29d1be09  ONLINE       0     0     0
            gptid/41ff4144-ebb0-11e2-9bc2-00505690dd7d  ONLINE       0     0     0
            gptid/12568da2-5568-11e4-b8aa-0060dd47d1cb  ONLINE       0     0     0
            gptid/114c6974-5568-11e4-b8aa-0060dd47d1cb  ONLINE       0     0     0
            gptid/151dab3b-5568-11e4-b8aa-0060dd47d1cb  ONLINE       0     0     0
            gptid/0f6dc72a-8095-11e5-b3dc-0060dd47d1cb  ONLINE       0     0     0
            gptid/393af75a-818d-11e5-b3dc-0060dd47d1cb  ONLINE       0     0     0
        spares
          gptid/b990b874-3584-11eb-845b-000c29d1be09    AVAIL

Die spare ga ik dan nog maar uit slopen :-)
Ik zal verder de SMART van alle disks eens goed bekijken

[WeaZuL]

Vanmorgen een stroomstoring, heel het dorp plat. Ik had echter mijn server aan een UPS hangen dus server kon gracefully down worden gebracht. Echter lukte dat niet 100% want er kwam op dat moment vreemde hoogtonige kraak geluiden uit de server en hij wilde niet down gaan. Na 10 minuten heb ik hem middels de powerbutton hard uitgezet. Vervolgens wilde de server niet meer aan. Na onderzoek bleek de LEICKE 10A/12V adapter het had begeven. Nadat ik een monitor had aangesloten en inc. een andere voeding bleek tevens een 5TB schijf niet meer gedetecteerd te worden, echter produceerde die 5TB schijf de eerder omschreven afwijkende geluiden. Na een doorstart staat de ZFS pool als degraded maar omdat de schijf in ZFS mirror stond, was de data gewoon benaderbaar. Ik heb een garantie call uitgezet bij Amazon.de kijken hoe mijn garantie aanvraag voor de powerbrick afgehandeld wordt.
Wat betreft de schijf, ik had geen 5TB spares meer liggen. Kijken of er ergens nog wat aanbiedingen voorbij komen. Ondanks de issues erg blij met ZFS!

[nero355]

WeaZuL schreef op maandag 11 oktober 2021 @ 13:50:
Vanmorgen een stroomstoring, heel het dorp plat. Ik had echter mijn server aan een UPS hangen dus server kon gracefully down worden gebracht. Echter lukte dat niet 100% want er kwam op dat moment vreemde hoogtonige kraak geluiden uit de server en hij wilde niet down gaan.

Die bewaar ik effe als argument voor al die bijdehande

"Hoe durf je mijn dure Samsung NVMe prullaria te noemen alleen omdat die geen elco's heeft ?!!!
Stroomstoringen hebben we toch nooit in Nederland en anders moet je maar een UPS kopen!!!111oneoneone"

opmerkingen van allerlei gamertjes en zogenaamde "workstation/server" eigenaren...

#Datacenter/EnterpriseSSD'sFTW!!!

[GioStyle]

Even een 'theoretische' vraag:

Ik heb op een server een datapool staan die tweewekelijkse snapshots krijgt. Als ik deze datapool inclusief snapshots door middel van zfs and receive via ssh naar een tweede server stuur, dan heb ik toch netjes 1 back-up?

[CurlyMo]

GioStyle schreef op woensdag 20 oktober 2021 @ 22:19:
Even een 'theoretische' vraag:

Ik heb op een server een datapool staan die tweewekelijkse snapshots krijgt. Als ik deze datapool inclusief snapshots door middel van zfs and receive via ssh naar een tweede server stuur, dan heb ik toch netjes 1 back-up?

Wat bedoel je hiermee?

[GioStyle]

CurlyMo schreef op woensdag 20 oktober 2021 @ 22:28:
[...]

Wat bedoel je hiermee?

Ik heb op server A een pool/dataset (X) staan met tweewekelijke snapshots. De data op X is mij heilig en moet goed geback-upt worden.

Ik heb ook een server B met een pool/dataset (Y). In principe wordt deze server alleen maar gebruikt om back-ups weg te schrijven.

Als ik 1 keer per maand door middel van zfs send & receive (via ssh) de pool/dataset X inclusief alle snapshots van server A verstuur naar pool/dataset Y van server B, dan heb ik toch 1 volledige back-up?

En ja, 1 back-up is geen back-up etc....

[ Voor 5% gewijzigd door GioStyle op 20-10-2021 22:57 ]

[CurlyMo]

GioStyle schreef op woensdag 20 oktober 2021 @ 22:38:
[...]
Als ik 1 keer per maand door middel van zfs send & receive (via ssh) de pool/dataset X inclusief alle snapshots van server A verstuur naar pool/dataset Y van server B, dan heb ik toch 1 volledige back-up?

Als je een snapshot stuurt dan stuur je daarmee automatisch de ZFS info mee. Dat is wat jij raar beschrijft in ZFS termen. Dus je eerste snapshot is altijd incl. FS info, de opvolgende incrementeel. Het zijn dus geen losse entiteiten.

[GioStyle]

CurlyMo schreef op woensdag 20 oktober 2021 @ 23:10:
[...]

Als je een snapshot stuurt dan stuur je daarmee automatisch de ZFS info mee. Dat is wat jij raar beschrijft in ZFS termen. Dus je eerste snapshot is altijd incl. FS info, de opvolgende incrementeel. Het zijn dus geen losse entiteiten.

Ik denk dat jij er te technisch naar kijkt. Ik bedoel het echt een stuk simpeler. In het verleden gebruikte ik Windows Server Backup of letterlijk copy paste om back-ups te maken, maar wijsheid komt met de jaren. Ik gebruik pas sindskort zfs icm snapshots

Gebruik nu dus zfs send and receive naar 3 verschillende plekken. Heb dus in totaal 4 kopieën, op 3 verschillende locaties en op 2 verschillende soorten opslagmedia.

In mijn omgeving maakt bijna niemand back-ups. Ik zoek een soort van bevestiging dat ik het enigszins goed doe, zeg maar.

[ Voor 7% gewijzigd door GioStyle op 21-10-2021 16:54 ]

[CurlyMo]

Bevestigd

[CurlyMo]

@GioStyle Let wel, dat is enkel op basis van een beperkte beschrijving van je werkwijze. Wil je zeker weten dat je backups werken, dan zal je de herstel procedure eens moeten testen.

[GioStyle]

CurlyMo schreef op donderdag 21 oktober 2021 @ 15:39:
@GioStyle Let wel, dat is enkel op basis van een beperkte beschrijving van je werkwijze. Wil je zeker weten dat je backups werken, dan zal je de herstel procedure eens moeten testen.

Klopt, ik ben me bewust van het feit dat ik erg weinig informatie geef, maar dat is bewust in verband met privacy. Daarnaast heb ik ook gespeeld met een aparte filesystem met een paar testbestandjes, snapshots en zfs rollback. Ik ben in staat om mijn data bij brand, systeemfalen, ransomware of PEBCAK terug te halen. Bij natuurrampen in Nederland zelf sta ik niet stil, want dan heb ik wel andere dingen aan mijn hoofd.

Laat ik het zo zeggen: ik gebruik sindskort snapshots en zfs send & receive voor back-ups. Dat is nieuw voor mij, maar in mijn ogen is het een hele mooie manier om je data te back-uppen/dupliceren.

[CurlyMo]

Test niet alleen de rollback maar ook het daadwerkelijk terug kopiëren van snapshots uit je backup.

[GioStyle]

CurlyMo schreef op donderdag 21 oktober 2021 @ 17:39:
Test niet alleen de rollback maar ook het daadwerkelijk terug kopiëren van snapshots uit je backup.

Afgelopen tijd wat kennis opgedaan en uitgeprobeerd. Een rollback kan alleen naar de meest recente snapshot. Als je data uit een oudere snapshot wil halen dan zou je de recentere snapshots die daarna komen allemaal moeten verwijderen totdat je bij de desbetreffende snapshot bent. Makkelijker is dan om een bepaalde snapshot te kopiëren naar een andere pool en vanaf daar je data terughalen. Je kan ook 'bladeren' door bepaalde snapshots door naar /pool/filesystem/.zfs/snapshots/etc.. te gaan als je specifieke bestanden wil terughalen.

Ik wil me nu gaan verdiepen in 'auto snapshots'. Ik draai Debian met ZFS. Iemand suggesties voor goed leesvoer?

[DRAFTER86]

GioStyle schreef op zondag 7 november 2021 @ 12:11:
[...]

Ik wil me nu gaan verdiepen in 'auto snapshots'. Ik draai Debian met ZFS. Iemand suggesties voor goed leesvoer?

Ik gebruik znapzend voor mijn snapshots en off site backups, draait over het algemeen goed. Wel is mijn ervaring dat je dit wil monitoren met iets als Zabbix/Graylog/Nagios whatever, zodat je een notificatie krijgt als het stuk gaat (dat gaat over de zfs send naar een remote locatie, het snapshotten zelf werkt altijd wel...)

[GioStyle]

Ik gebruik nu momenteel zfs-auto-snapshot. Heb momenteel voor 2 datasets het volgende: daily snapshot maken (wordt bewaard voor 31 dagen waarna telkens de oudste snapshot wordt verwijderd) en monthly snapshot (wordt 12x bewaard, dus 12 maanden bewaard). Door gebruik te maken van deze manier worden er een aantal attributen aan de datasets toegevoegd:

code:

Pool/Dataset  com.sun:auto-snapshot:daily     true                            local
Pool/Dataset  com.sun:auto-snapshot:hourly    false                           local
Pool/Dataset  com.sun:auto-snapshot:frequent  false                           local
Pool/Dataset  com.sun:auto-snapshot:weekly    false                           local
Pool/Dataset  com.sun:auto-snapshot:monthly   true                            local
Pool/Dataset  com.sun:auto-snapshot           true                            local

Werkt prima en voldoet prima aan mijn eisen. Echter als ik nu zfs send & receive gebruik (ik doe dat nog steeds handmatig), dan worden deze attributen meegestuurd. Op zich niet erg, omdat mijn backup server geen zfs-auto-snapshot heeft. Maar met mijn backuplocatie op dezelfde server gaat ie natuurlijk vrolijk door met snapshotten, terwijl dat niet de bedoeling is. Kan ik deze attributen op de backuplocatie veranderen of verwijderen zonder dat dat gevolgen heeft?

[d3vlin]

Ik zou in plaats van handmatig send / receive eens kijken naar sanoid en syncoid. Sanoid voor het automatisch maken en bewaren van snapshots, syncoid om deze automatisch naar een andere locatie te repliceren. Beiden zijn te installeren via de standaard Debian repositories.

[ Voor 13% gewijzigd door d3vlin op 14-11-2021 20:43 ]

[Kaspers]

d3vlin schreef op zondag 14 november 2021 @ 20:42:
Ik zou in plaats van handmatig send / receive eens kijken naar sanoid en syncoid. Sanoid voor het automatisch maken en bewaren van snapshots, syncoid om deze automatisch naar een andere locatie te repliceren. Beiden zijn te installeren via de standaard Debian repositories.

Juist .

Ik quote mezelf even:

Kaspers schreef op dinsdag 27 april 2021 @ 19:11:
[...]


Ieder z'n eigen natuurlijk!
Ik ben zelf meer fan van simplistische cli tools, configureerbaar middels config files, gescheduled middels systemd-units en timers.

sanoid config (snapshot management framework):

code:

[zfspool/koos/documents]
        use_template = frequent_longterm
[zfspool/koos/kubernetes]
        use_template = frequent_shortterm
[zfspool/koos/photos]
        use_template = nonfrequent_longterm
[zfspool/koos/videos]
        use_template = nonfrequent_longterm
[zfspool/koos/books]
        use_template = nonfrequent_longterm
[zfspool/koos/bookmarks]
        use_template = nonfrequent_longterm

#############################
# templates below this line #
#############################

#het aantal backups behouden per afgelopen <eenheid>
[template_frequent_longterm]
        frequently = 0
        hourly = 0
        daily = 30
        monthly = 12
        yearly = 1
        autosnap = yes
        autoprune = yes

[template_nonfrequent_longterm]
        frequently = 0
        hourly = 0
        daily = 0
        monthly = 12
        yearly = 1
        autosnap = yes
        autoprune = yes

[template_frequent_shortterm]
        frequently = 0
        hourly = 0
        daily = 30
        monthly = 0
        yearly = 0
        autosnap = yes
        autoprune = yes

syncoid shell script ("filesystem-level snapshot replication to move data from one machine to another, fast.")

code:

#!/bin/sh

#target:
USER=admin
HOST=backup.lan

echo "Sending snapshots of koos/configuration"
syncoid --no-sync-snap  zfspool/koos/configuration $USER@$HOST:zfspool2/koos/configuration
echo "Sending snapshots of koos/documents"
syncoid --no-sync-snap  zfspool/koos/documents     $USER@$HOST:zfspool2/koos/documents
echo "Sending snapshots of koos/kubernetes"
syncoid --no-sync-snap  zfspool/koos/kubernetes    $USER@$HOST:zfspool2/koos/kubernetes
echo "Sending snapshots of koos/photos"
syncoid --no-sync-snap  zfspool/koos/photos        $USER@$HOST:zfspool2/koos/photos
echo "Sending snapshots of koos/videos"
syncoid --no-sync-snap  zfspool/koos/videos        $USER@$HOST:zfspool2/koos/videos
echo "Sending snapshots of koos/books"
syncoid --no-sync-snap  zfspool/koos/books        $USER@$HOST:zfspool2/koos/books
echo "Sending snapshots of koos/bookmarks"
syncoid --no-sync-snap  zfspool/koos/bookmarks        $USER@$HOST:zfspool2/koos/bookmarks

.

Zoals ik al zei: ieder z'n eigen. Ik heb met bovenstaande 2 tools geen omkijken meer naar snapshot replication managment op de server op zolder én replicatie naar een tweede host in de kelder. En mocht de systemd-service eruit knallen, dan krijg ik netjes een emailnotificatie:

code:

[Unit]
Description=Run sanoid
OnFailure=email-notification@%i.service

[Service]
Type=simple
ExecStart=sanoid --cron --configdir /zfspool/koos/configuration/storage-server/sanoid/ --verbose

#deze service werkt met een timer.

failture notification service:

code:

[Unit]
Description=%i failure email notification

[Service]
Type=oneshot
ExecStart=/bin/bash -c '/bin/systemctl status %i | /usr/bin/mailx -s "[%i] failure notification" [e-mail]'

Doe er je voordeel mee mocht je 't wat vinden .

[GioStyle]

Automatisering is leuk, maar als je nog niet volledig bij bent qua kennis wat betreft snapshots... 't Lijkt me handig als je eerst helemaal uitvogelt wat snapshots precies met je data doet...

[vanaalten]

Ik overweeg om m'n meterkast-servertje opnieuw in te richten - specifiek, ik wil ZFS gebruiken.

Hardware: Intel i5-10400 met een Asrock H470M-ITX/ac moederbord, 16GB geheugen en een 1TB Samsung 860-EVO SSD
Operating system: Debian 'stable' (Bullseye).

Momenteel heb ik een UEFI partitie, een boot partitie (ext2) en een 'restant' partitie. Binnen die 'restant' partitie: een LUKS encrypted root en LUKS encrypted swap partitie. Tenminste, ik denk dat die swap encrypted is - volgens mij heb ik dat destijds zo aangemaakt, maar weet even niet hoe ik dat kan vaststellen.

Ik wil ZFS, voornamelijk om 1 reden: snapshots. Onlangs per ongeluk een script gewist die in een directory zat die buiten alle backups viel en dat is een beetje jammer. Snapshots had dan geholpen. Plus dat het ook wel eens leuk is om iets nieuws op te zetten.

Research: ik heb dit topic op het internet gevonden, weliswaar voor Debian 'Buster' maar volgens mij ook prima bruikbaar voor de laatste stable release.

Maar, vragen:

• In stap 3, punt 1 worden er twee 'containers' gemaakt, 'rpool/ROOT' en 'bpool/BOOT'. Daarbinnen worden dan (bij de volgende stap) 'rpool/ROOT/debian' en 'bpool/BOOT/debian'. Wat is daar de lol van? Waarom wordt 'bpool/BOOT' en 'rpool/ROOT' niet direct gebruikt als toplevels voor de / en /boot locaties?
• Bij stap 3, punt 2 wordt voor 'rpool/ROOT/debian' de canmount=noauto gebruikt. Waarom wil men de root *niet* automatisch laten mounten?
• Stap 3, punt 3: ik heb sterk mijn twijfels bij de datasets die aangemaakt worden. Bijvoorbeeld "zfs create -o canmount=off rpool/var/lib": er wordt dus een dataset gemaakt voor /var/lib die vervolgens niet gemount wordt? Verderop worden er nog diverse datasets aangemaakt zoals /var/lib/docker en /var/lib/nfs - is het idee van deze HowTo dat voor ELKE directory in /var/lib, je een aparte dataset moet aanmaken?
• Voor ik hier aan begin - is er verder nog iets op de HowTo aan te merken?

[GioStyle]

@vanaalten

Ik ben zelf geen Linux-expert, maar draai al geruime tijd een server met Debian erop. Ik heb letterlijk alles wat ik op die server heb geïnstalleerd of aangepast gedocumenteerd. Gewoon een .txt bestandje met letterlijk alle commando's met op- en aanmerkingen. Als je toch vanaf start gaat beginnen, dat gelijk meenemen? Zo kan je altijd achterhalen hoe en wat je hebt gedaan op je server.

Overigens vind ik je vragen zeer interessant. Ik draai zelf helaas ook nog geen root-on-ZFS, maar zou het graag willen, zeker met dockervolumes lijkt me snapshot een handig middel om dat te backuppen.

[vanaalten]

Net afgelopen weekend de grote stap gewaagd en inderdaad in een textbestand bijgehouden wat ik gedaan heb.

Qua kinderziektes valt het mee.

• Ik heb twee identieke machines waarbij eentje altijd aan staat en de ander uit, enkel aan voor een nachtelijke backupsessie. Dat aan-zetten gebeurd met wake-on-lan en dan is het hebben van een encrypted disk een beetje een uitdaging. Daar zijn prima oplossingen voor d.m.v. dropbear in je initrd opnemen - en dan kan je vervolgens script-based de server wakker maken en unlocken. Alleen lijkt het wake/unlock-script (wakeonlan gevolgd door een expect-script) niet betrouwbaar te werken: soms is de machine wel wakker maar krijgt hij door het expect-script een fout wachtwoord (en wacht vervolgens tot het juiste wachtwoor komt). Wellicht een kwetsie van het expect-script tweaken. Positief: het unlocken van een encrypted-root d.m.v. dropbear wordt al compleet out-of-the-box door Debian Bullseye ondersteund.
• Ik was een tijd geleden overgestapt van Docker naar Podman - weet niet meer precies waarom. En Podman draaide niet onder root maar onder een eigen user. Na overschakelen op ZFS wilde Podman niet starten - iets met dat je de ZFS driver moest gebruiken. Maar, dat kreeg ik niet meteen draaiend onder de eigen user, dus Podman draait nu onder root. Wellicht dat ik binnenkort weer eens terugga naar Docker, want ben nooit echt enthousiast geworden van Podman.

Sommige van mijn vragen heb ik een beetje kunnen beantwoorden:
"worden er twee 'containers' gemaakt, 'rpool/ROOT' en 'bpool/BOOT'. Daarbinnen worden dan (bij de volgende stap) 'rpool/ROOT/debian' en 'bpool/BOOT/debian'. Wat is daar de lol van? Waarom wordt 'bpool/BOOT' en 'rpool/ROOT' niet direct gebruikt als toplevels voor de / en /boot locaties?"
...van wat ik ergens gelezen heb zijn er distributies die, als je deze namen aanhoudt, de boel automatisch kunnen gebruiken. Lijkt voor Debian niet van belang, maar als je je schijf eens in een ander systeem hangt zou het nuttig kunnen zijn. Kan niet zeggen dat ik het helemaal begrijp, maar: kost niets, dus gewoon maar gedaan.

"ik heb sterk mijn twijfels bij de datasets die aangemaakt worden. Bijvoorbeeld "zfs create -o canmount=off rpool/var/lib": er wordt dus een dataset gemaakt voor /var/lib die vervolgens niet gemount wordt? Verderop worden er nog diverse datasets aangemaakt zoals /var/lib/docker en /var/lib/nfs - is het idee van deze HowTo dat voor ELKE directory in /var/lib, je een aparte dataset moet aanmaken?"
Nee, enkel voor de paar directories waar je een aparte set voor wil hebben moet je dat doen. Die dataset 'rpool/var/lib' wordt volgens mij nergens verder gebruikt, alles onder /var/lib komt in principe gewoon in de root-set, *behalve* als er een aparte dataset voor gemaakt wordt.

"is er verder nog iets op de HowTo aan te merken?"
Op zich niet. Er mist wat instructie over hoe je een bestaande installatie overhevelt. Daarbij heb ik dat eerst geprobeerd door met 'rsync' de boel over te zetten, maar dat leverde vreemd genoeg corrupte resultaten op: willekeurig dat sommige bestanden niet overgezet werden. Uiteindelijk in plaats daarvan gewoon met een 'cp -ax' gedaan. Ook was het nog wat puzzelen met wat je dan moet aanpassen aan de bestaande installatie (oude disks uit /etc/fstab en /etc/crypttab bijvoorbeeld), maar ik snap dat het lastig is om dat in een generieke HowTo te beschrijven.

Op de to-do lijst:
Uitzoeken hoe ik met een Linux Live distro de ZFS dingen goed kan mounten voor het geval ik niet meer goed kan opstarten als ik wat verkloot heb. Voorheen was het simpelweg iets als "mount /dev/sda1 /mnt; mount /proc/dev/sys ...; chroot /mnt" en dan met grub de boel repareren, maar dat zal nu wel anders werken.
En daarna een snapshot-systeem opzetten.

[SanderH_]

Hmmm, mijn HP ProLiant Microserver (die al een tijdje "stil" stond) krijgt FreeNAS niet meer geboot en toont het volgende

BIOS 625kB/3961744kB available memory

FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1
(Fri Feb 14 13 :56 :56 UTC 2020 root@tnbui 1d02.th ixsystems.com)
Loading /boot/defaults/loader.conf
read 260 from 13645493 to Oxeffb0d40, error : Ox80
ZFS: i/o error - all block copies unavailable
read 257 from 13124152 to Oxeff21340, error: Ox80
read 257 from 3762381 to Oxefff3d40, error: 0x80
read 257 from 23086606 to Oxeff9bf40, error: Ox80
ZFS: i/o error - all block copies unavailable
can' t open '/boot/menu .4th' input/output error 

read 257 from 13124152 to Oxeff21340, error : 0x80
read 257 from 3762381 to Oxeiff3d40, error: 0x80
read 257 from 23086606 to Oxeff9bf40, error : 0x80
ZFS: i/o error - all block copies unavailable
read 257 from 13124152 to Oxeff21340, error : 0x80
read 257 from 3762381 to Oxefff3d40, error : 0x80
read 25? from 23086606 to Oxeff9bf40, error: 0x80
ZFS: i/o error - all block copies unavailable
can' t load ' kernel'

Type '?' for a list of commands, 'help' for more detailed help. 
OK 

Output van lsdev:

disk devices:
    disk0: BIOS drive C (61341696 X 512):
        disk0p1: FreeBSD boot
        disk0p2: FreeBSD ZFS
    disk1: BIOS drive D (11721045168 X 512):
        disk1pl: FreeBSD swap
        disk1p2: FreeBSD ZFS
    disk2: BIOS drive E (11721045168 X 512):
        disk2p1: FreeBSD swap
        disk2p2: FreeBSD ZFS 
    disk3: BIOS drive F (11721045168 X 512): 
        disk3p1: FreeBSD swap
        disk3p2: FreeBSD ZFS 
    disk4: BIOS drive G (11721045168 X 512): 
        disk4p1: FreeBSD swap
        disk4p2: FreeBSD ZFS 
zfs devices: 
    zfs:freenas-boot 
    zfs:tank
OK

Al even gezocht en lijkt blijkbaar op een corrupte boot drive (USB in mijn geval)? Dus terug installen met een nieuwe boot drive en dan op 1 of andere manier mijn pool terug importeren?

[CurlyMo]

@SanderH_ Probeer eerst eens een LiveCD van een recente FreeBSD of Debian.

[nero355]

SanderH_ schreef op donderdag 9 december 2021 @ 16:38:
Hmmm, mijn HP ProLiant Microserver (die al een tijdje "stil" stond) krijgt FreeNAS niet meer geboot.

Al even gezocht en lijkt blijkbaar op een corrupte boot drive (USB in mijn geval)?

Dat is het probleem met USB Sticks : Raken makkelijk corrupt en moeten eigenlijk om de zoveel tijd effe gebruikt worden om de boel levende te houden!

Dus terug installen met een nieuwe boot drive en dan op 1 of andere manier mijn pool terug importeren?

Dat moet inderdaad gewoon kunnen, maar doe jezelf een lol en overweeg gewoon een cheapass SSD als OS opslag : serie: Green

[SanderH_]

Dank voor de suggesties @CurlyMo @nero355

Net even geboot met een Debian live image. Lijkt er inderdaad op alsof de USB die op het mobo geprikt zit naar de eeuwige USB jachtvelden is aangezien die ik gewoon niet meer zie (sde is de USB waarvan ik de live image draai):

( leve OCR )

user@debian: ls /dev | grep sd
sda1
sda2	
sdb	
sdb1	
sdb2	
sdc	
sdc1	
sdc2	
sdd	
sdd1	
sdd2	
sde	
sde1	
sde2	
user@debian: sudo 1sblk -S	
NAME HCTL	TYPE VENDORR	MODEL	REV SERIAL	TRAN	
sda	0:0:0:0	disk ATA	HDC HD6OEFRX-68LOBN1 OA82 HD-HX11038NJP38 ata	
sdb	0:0:1:0	disk ATA	HDC HD6OEFRX-68LOBN1 OA82 HD-HX11D189VXT4 ata	
sdc	1:0:0:0	disk ATA	HDC HD60EFRX-68LOBN1 OA82 HD-WX11D28K3RX8 ataa	
sdd	1:0:1:0	disk ATA	WDC HD6OEFRX-68LOBN1 OA82 HD-Hx21D1825SPA ata	
sde	4:0:0:0	disk Gener ic STORAGE DEVICE	0250 O000000o0250	usb		

[ Voor 5% gewijzigd door SanderH_ op 09-12-2021 18:01 ]

[CurlyMo]

SanderH_ schreef op donderdag 9 december 2021 @ 17:59:
Dank voor de suggesties @CurlyMo @nero355

Doe eens een zpool import?

[SanderH_]

CurlyMo schreef op donderdag 9 december 2021 @ 18:06:
[...]

Doe eens een zpool import?

De nodige packages staan blijkbaar niet installed op de Debian live image. Ik kan nog eens proberen met een FreeBSD live cd.

[ Voor 9% gewijzigd door SanderH_ op 09-12-2021 18:15 ]

[CurlyMo]

SanderH_ schreef op donderdag 9 december 2021 @ 18:14:
[...]


De nodige packages staan blijkbaar niet installed op de Debian live image. Ik kan nog eens proberen met een FreeBSD live cd.

Dan installeer je die toch even? Dat is misschien sneller dan een FreeBSD Live CD downloaden.

[SanderH_]

@CurlyMo Ziet er goed uit volgens mij

status: The pool was last accessed by another system	action: The pool can be imported using its name or nuner ic identifier and	
the '-f flag.	
conf ig	see: https://openzfs.github.io/openzfs-docs/nsg/ZFS-8888-EY	
freenas-boot	
gptid/28fb528-a52d-11e8-94d6-10674b92aBe4	ONL INE	ONL INE	
pool: tank	
id: 933579996943032657	
state: ONLINE	
status: The pool uas last accessed by another system.	
action: The pool can be imported using its name or numeric identifier and	the '-f flag.	
config:	see: https://openzfs.github. io/openzfs-docs/nsg/ZFS-8888-EY	
tank	
ONL INE	
raidz1-0	
ONL INE	
gptid/b581cb36-a3b5-11eB-aBc9-10684b92a8e4 ONL INE	
gpt id/b5d23542-a3b5-11e8-aBc9-10684b92a8e4 ONLINE	
gptid/b6a23a25-a3b5-11e8-aBc9-10684b92aBe4	ONL INE	
gptid/b777f422-a3b5-11e8-aBc9-18684b92a8e4 ONL INE	
root@:/ #	

EDIT: uiteindelijk toch een happy ending, alles netjes kunnen importeren



kudos @CurlyMo @nero355

[ Voor 14% gewijzigd door SanderH_ op 11-12-2021 12:48 ]

[vanaalten]

Voor het geval iemand hier iets aan heeft:

vanaalten schreef op dinsdag 7 december 2021 @ 16:31:
Op de to-do lijst:
Uitzoeken hoe ik met een Linux Live distro de ZFS dingen goed kan mounten voor het geval ik niet meer goed kan opstarten als ik wat verkloot heb. Voorheen was het simpelweg iets als "mount /dev/sda1 /mnt; mount /proc/dev/sys ...; chroot /mnt" en dan met grub de boel repareren, maar dat zal nu wel anders werken.

Zie ook een vorige post. In basis heb ik m'n meterkast-servertje ingericht volgens deze guide. Dus een eerste partitie met FAT32 voor UEFI boot, een tweede partitie als ZFS pool voor /boot en een derde, grootste, partitie als encrypted ZFS pool voor /. Wat ik dus nog wilde uitzoeken: hoe ik met een live distro kan booten en vervolgens de boel kan mounten en met chroot er in kan om dingen te repareren, indien ooit nodig.

Waar ik op uit ben gekomen:

code:

sudo su
zpool import -f -a -N -R /media/linux
zfs load-key -r -a
zfs mount rpool/ROOT/debian
zfs mount -a
mount /dev/nvme0n1p1 /media/linux/boot/efi

mount -o bind /proc               /media/linux/proc
mount -o bind /dev                /media/linux/dev
mount -o bind /dev/pts            /media/linux/dev/pts
mount -o bind /sys                /media/linux/sys
mount -o bind /run                /media/linux/run
chroot /media/linux

(...doe wat nodig is om te repareren)

exit

umount -l /media/linux
zpool export -a

Ik had gedacht dat die zfs-commando's aan het begin wel met minder zou kunnen (key inladen kan ook bij het importeren van de pool en automatisch mounten zou ook moeten kunnen), maar de volgorde en dingen gescheiden houden bleek toch nodig te zijn om de boel goed gemount te krijgen. Maar goed: dit werkt.

En daarna een snapshot-systeem opzetten.

Dat lijkt een stuk eenvoudiger:

code:

sudo apt install zfs-auto-snapshot

Gewoon in de standaard Debian repository. Out-of-the-box werkt het al, ben er nog niet uit wat ik wil finetunen.

[Borromini]

Die zfs-auto-snapshot daar ga ik ook nog es naar kijken, maar die doet geen pruning lijkt me? Daar ben ik nog zelf ook nog naar op zoek op Linux .

[GioStyle]

Borromini schreef op dinsdag 21 december 2021 @ 13:51:
Die zfs-auto-snapshot daar ga ik ook nog es naar kijken, maar die doet geen pruning lijkt me? Daar ben ik nog zelf ook nog naar op zoek op Linux .

Met pruning bedoel je dat ie automatisch na zoveel snapshots de boel opruimt? Dat doet zfs-auto-snapshot namelijk wel.

https://docs.oracle.com/c...817-2271/gbcxl/index.html

Standaard:

frequent snapshots every 15 mins, keeping 4 snapshots
hourly snapshots every hour, keeping 24 snapshots
daily snapshots every day, keeping 31 snapshots
weekly snapshots every week, keeping 7 snapshots
monthly snapshots every month, keeping 12 snapshots

Heb bovenstaand wel aangepast naar mijn smaak, maar vind het goed werken. Het enige wat ik nog doe is om de x aantal tijd mijn backupserver aanslingeren om de snapshots bij te werken.

[ Voor 10% gewijzigd door GioStyle op 21-12-2021 14:14 ]

[Borromini]

Ik had idd over de 'destroy' in de README gekeken

[RobertMe]

Dit topic nog maar eens uit de mottenballen halen. Maar weinig vragen over een filesystem is natuurlijk ook goed. Betekend dat het zijn werk doet

In any case, mijn vraag:
Ik wil een backup maken van een volledige pool en doe daarvoor zfs snapshot -r tank@backup. Alleen word bij lange na niet van elke dataset een snapshot gemaakt. Hoe kan dit? Want natuurlijk een beetje lullig als ik dadelijk het snapshot inclusief alle descendants over zet maar de helft niet gesnapshot is en dus alsnog niet gebackup wordt. Als ik een heel specifieke zfs snapshot -r tank/foo/bar@backup doe dan wordt het snapshot wel aangemaakt, maar met een -r op het hogere niveau dus niet. En in het voorbeeld met tank/foo/bar, er is ook een tank/foo/baz en die wordt weer wel meegenomen door de -r tank@backup, dus het is ook niet perse zo dat het op een hoger niveau mis lijkt te gaan. Daarnaast heb ik ook al gekeken naar de com.sun:auto-snapshot property, maar die lijkt niet ingesteld te zijn dus daar kan het ook niet aan liggen (naast dat deze property volgens mij alleen door zfs auto snapshot gebruikt wordt en niet door ZFS intern?).

Het enige dat ik mij kan bedenken waarom het niet werkt is dat -r descendants snapshot, en er een disconnect is tussen datasets die op basis van de naam descendent lijken te zijn (dus in dit geval, mijn verwachting is dat alles met tank/* een descendant is), maar toch geen descendant zijn omdat ze verkeerd / anders zijn aangemaakt.

[DRAFTER86]

RobertMe schreef op donderdag 13 januari 2022 @ 08:40:
.....
Alleen word bij lange na niet van elke dataset een snapshot gemaakt. Hoe kan dit? Want natuurlijk een beetje lullig als ik dadelijk het snapshot inclusief alle descendants over zet maar de helft niet gesnapshot is en dus alsnog niet gebackup wordt.
...

Enige wat ik me kan bedenken is dat sommige datasets misschien al een snapshot met die naam hebben?
Liever zou je dan gewoon een foutmelding zien natuurlijk...

[RobertMe]

DRAFTER86 schreef op donderdag 13 januari 2022 @ 09:04:
[...]


Enige wat ik me kan bedenken is dat sommige datasets misschien al een snapshot met die naam hebben?
Liever zou je dan gewoon een foutmelding zien natuurlijk...

Vergeten te vermelden. Als ik commando herhaal spuugt die gewoon error van al bestaande snapshot (s). Maar de datasets waar die geen snapshot op aanmaakt komt geen error van langs. Daar komt dus ook mijn vermoeden vandaan dat ze niet herkent worden als descendant. Anders had ik wel een error verwacht of dat ze wel werden aangemaakt.

[CurlyMo]

Ik zie ook niet direct hoe dit niet zou werken. Kan je eens een zfs list kunnen plaatsen?

[RobertMe]

CurlyMo schreef op donderdag 13 januari 2022 @ 09:34:
Ik zie ook niet direct hoe dit niet zou werken. Kan je eens een zfs list kunnen plaatsen?

Uiteraard

robert@nas:~$ zfs list -r tank
NAME                                             USED  AVAIL     REFER  MOUNTPOINT
tank                                            9.62T  4.80T      149K  /tank
tank/backup                                     56.3G  4.80T      139K  /tank/backup
tank/backup/local                               52.7G  4.80T      128K  /tank/backup/local
tank/backup/local/docker                        13.6G  4.80T      170K  /tank/backup/local/docker
tank/backup/local/docker/data                    982M  4.80T      225M  /tank/backup/local/docker/data
tank/backup/local/docker/development            1.42G  4.80T     1.42G  /tank/backup/local/docker/development
tank/backup/local/docker/domotica               2.32G  4.80T      106M  /tank/backup/local/docker/domotica
tank/backup/local/docker/downloader             1.53G  4.80T      598M  /tank/backup/local/docker/downloader
tank/backup/local/docker/monitor                2.22G  4.80T     2.22G  /tank/backup/local/docker/monitor
tank/backup/local/docker/networking             4.92G  4.80T     4.14G  /tank/backup/local/docker/networking
tank/backup/local/docker/tools                   178M  4.80T     19.1M  /tank/backup/local/docker/tools
tank/backup/local/rpool                         39.2G  4.80T      139K  /tank/backup/local/rpool
tank/backup/local/rpool/ROOT                    9.27G  4.80T      128K  /tank/backup/local/rpool/ROOT
tank/backup/local/rpool/ROOT/pve-1              9.27G  4.80T     7.65G  /tank/backup/local/rpool/ROOT/pve-1
tank/backup/local/rpool/data                    29.9G  4.80T      160K  /tank/backup/local/rpool/data
tank/backup/local/rpool/data/docker              234K  4.80T      139K  /tank/backup/local/rpool/data/docker
tank/backup/local/rpool/data/subvol-101-disk-0  4.95G  4.80T     4.48G  /tank/backup/local/rpool/data/subvol-101-disk-0
tank/backup/local/rpool/data/subvol-102-disk-0  3.84G  4.80T     3.05G  /tank/backup/local/rpool/data/subvol-102-disk-0
tank/backup/local/rpool/data/subvol-103-disk-0  2.00G  4.80T     1.89G  /tank/backup/local/rpool/data/subvol-103-disk-0
tank/backup/local/rpool/data/subvol-104-disk-0  2.94G  4.80T     2.28G  /tank/backup/local/rpool/data/subvol-104-disk-0
tank/backup/local/rpool/data/subvol-105-disk-0  1.93G  4.80T     1.86G  /tank/backup/local/rpool/data/subvol-105-disk-0
tank/backup/local/rpool/data/subvol-106-disk-0  3.31G  4.80T     3.12G  /tank/backup/local/rpool/data/subvol-106-disk-0
tank/backup/local/rpool/data/subvol-107-disk-0  3.42G  4.80T     3.13G  /tank/backup/local/rpool/data/subvol-107-disk-0
tank/backup/local/rpool/data/subvol-108-disk-0   766M  4.80T      746M  /tank/backup/local/rpool/data/subvol-108-disk-0
tank/backup/local/rpool/data/subvol-109-disk-0  1.30G  4.80T     1.28G  /tank/backup/local/rpool/data/subvol-109-disk-0
tank/backup/local/rpool/data/vm-100-disk-0      2.97G  4.80T     1.54G  -
tank/backup/local/rpool/data/vm-110-disk-0      2.51G  4.80T     1.67G  -
tank/backup/vps                                 2.54G  4.80T      139K  /tank/backup/vps
tank/backup/vps/docker                           512M  4.80T      160K  /tank/backup/vps/docker
tank/backup/vps/docker/baikal                   4.66M  4.80T      234K  /tank/backup/vps/docker/baikal
tank/backup/vps/docker/bitwarden                 810K  4.80T      501K  /tank/backup/vps/docker/bitwarden
tank/backup/vps/docker/mail                     54.9M  4.80T     54.9M  /tank/backup/vps/docker/mail
tank/backup/vps/docker/traefik                  2.23M  4.80T      464K  /tank/backup/vps/docker/traefik
tank/backup/vps/docker/unifi                     110M  4.80T     49.6M  /tank/backup/vps/docker/unifi
tank/backup/vps/docker/webmail                   634K  4.80T      634K  /tank/backup/vps/docker/webmail
tank/backup/vps/mail                             471M  4.80T      420M  /tank/backup/vps/mail
tank/backup/vps/tank                            1.58G  4.80T      128K  /tank/backup/vps/tank
tank/backup/vps/tank/docker                      282M  4.80T      281M  /tank/backup/vps/tank/docker
tank/backup/vps/tank/docker/traefik              282K  4.80T      197K  /tank/backup/vps/tank/docker/traefik
tank/backup/vps/tank/lxc                         916M  4.80T      453K  /tank/backup/vps/tank/lxc
tank/backup/vps/tank/lxc/mail                    915M  4.80T      915M  /tank/backup/vps/tank/lxc/mail
tank/backup/vps/tank/mail                        420M  4.80T      420M  /tank/backup/vps/tank/mail
tank/backup/vps4                                 526M  4.80T      139K  /tank/backup/vps4
tank/backup/vps4/docker                          526M  4.80T      139K  /tank/backup/vps4/docker
tank/backup/vps4/docker/docker-proxy             336K  4.80T      144K  /tank/backup/vps4/docker/docker-proxy
tank/backup/vps4/docker/mail                     525M  4.80T      439M  /tank/backup/vps4/docker/mail
tank/backup/vps4/docker/traefik                  613K  4.80T      218K  /tank/backup/vps4/docker/traefik
tank/backup/vps5                                 515M  4.80T      128K  /tank/backup/vps5
tank/backup/vps5/docker                          515M  4.80T      149K  /tank/backup/vps5/docker
tank/backup/vps5/docker/docker-proxy             133K  4.80T      133K  /tank/backup/vps5/docker/docker-proxy
tank/backup/vps5/docker/mail                     514M  4.80T     1018K  /tank/backup/vps5/docker/mail
tank/backup/vps5/docker/mail/vmail               497M  4.80T      442M  /tank/backup/vps5/docker/mail/vmail
tank/backup/vps5/docker/traefik                  453K  4.80T      234K  /tank/backup/vps5/docker/traefik
tank/media                                      7.25T  4.80T      139K  /tank/media
tank/user                                       2.31T  4.80T      234K  /tank/user
tank/user/robert                                1.93T  4.80T      298K  /tank/user/robert
tank/user/robert/data                            349G  4.80T      336G  /tank/user/robert/data

Voor de oplettende lezer, totalen kloppen idd niet Er ontbreken een aantal regels

En met snapshots:

robert@nas:~$ zfs list -r tank -t snapshot | grep backup-1-2
tank@backup-1-2                                                                     74.6K      -      149K  -
tank/backup@backup-1-2                                                                 0B      -      139K  -
tank/backup/local@backup-1-2                                                           0B      -      128K  -
tank/backup/local/rpool/data/docker@backup-1-2                                         0B      -      139K  -
tank/backup/local/rpool/data/subvol-108-disk-0@backup-1-2                              0B      -      746M  -
tank/backup/vps@backup-1-2                                                             0B      -      139K  -
tank/backup/vps/docker@backup-1-2                                                      0B      -      160K  -
tank/backup/vps/docker/mail@backup-1-2                                                 0B      -     54.9M  -
tank/backup/vps/docker/webmail@backup-1-2                                              0B      -      634K  -
tank/backup/vps/mail@backup-1-2                                                        0B      -      420M  -
tank/backup/vps/tank@backup-1-2                                                        0B      -      128K  -
tank/backup/vps/tank/docker@backup-1-2                                                 0B      -      281M  -
tank/backup/vps/tank/docker/traefik@backup-1-2                                         0B      -      197K  -
tank/backup/vps/tank/lxc@backup-1-2                                                    0B      -      453K  -
tank/backup/vps/tank/lxc/mail@backup-1-2                                               0B      -      915M  -
tank/backup/vps/tank/mail@backup-1-2                                                   0B      -      420M  -
tank/backup/vps4@backup-1-2                                                            0B      -      139K  -
tank/backup/vps4/docker@backup-1-2                                                     0B      -      139K  -
tank/backup/vps4/docker/docker-proxy@backup-1-2                                        0B      -      144K  -
tank/backup/vps4/docker/mail@backup-1-2                                                0B      -      439M  -
tank/backup/vps4/docker/traefik@backup-1-2                                             0B      -      218K  -
tank/backup/vps5@backup-1-2                                                            0B      -      128K  -
tank/user@backup-1-2                                                                   0B      -      234K  -
tank/user/robert@backup-1-2                                                            0B      -      298K  -
tank/user/robert/data@backup-1-2                                                     916K      -      336G  -

grep omdat pyznap ook draait en er dus "iets" meer snapshots zijn in totaliteit.

[CurlyMo]

Zie je verschillen tussen de zfs get all parameters van de filesystems die wel meegenomen worden en die niet meegenomen worden?

[RobertMe]

CurlyMo schreef op donderdag 13 januari 2022 @ 13:35:
Zie je verschillen tussen de zfs get all parameters van de filesystems die wel meegenomen worden en die niet meegenomen worden?

Good one, even vergeleken tussen twee filesystems maar lijkt alleen te gaan om logische verschillen: creation, user, mountpoint, createtxg (?), guid, usedbysnapshots, usedbychildren, objsetid, logicalid.

[inSane666]

hallo,
Kan ik wat hulp vragen?

xxx@xxx-ghostbsd-pc /u/h/xxx> zpool status tank
  pool: tank
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can
	still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
	pool will no longer be accessible on software that does not support
	feature flags.
  scan: scrub repaired 0B in 06:58:30 with 0 errors on Fri Dec  3 17:07:19 2021
config:

	NAME              STATE     READ WRITE CKSUM
	tank              ONLINE       0     0     0
	  raidz2-0        ONLINE       0     0     0
	    gpt/seagate1  ONLINE       0     0     0
	    gpt/seagate2  ONLINE       0     0     0
	    ada5          ONLINE       0     0     0
	    gpt/seagate4  ONLINE       0     0     0
	    gpt/seagate5  ONLINE       0     0     0
	    gpt/seagate6  ONLINE       0     0     0

errors: No known data errors

1-Deze zomer heb ik een schijf moeten vervangen, kan iemand mij uitleggen hoe, nu ik 5 nieuwe disks heb om de resterende te vervangen, deze eerst een label kan geven?
2-Ik ga van 3Tb naar 8Tb schijven en 'vergat zpool set autoexpand=on tank', is het nu te laat, of kan dit nog?
3-Dit is een bootable pool (begon FreeBSD en zfs met zfsguru), zal 'zfs destroy tank/zfsguru' zonder problemen alle restanten ivm zfsguru verwijderen, en de ruimte beschikbaar zijn voor tank?

Met vriendelijke groeten,

Christoph

[CurlyMo]

inSane666 schreef op zaterdag 15 januari 2022 @ 16:44:
1-Deze zomer heb ik een schijf moeten vervangen, kan iemand mij uitleggen hoe, nu ik 5 nieuwe disks heb om de resterende te vervangen, deze eerst een label kan geven?

Welk besturingssysteem hebben we het over?

2-Ik ga van 3Tb naar 8Tb schijven en 'vergat zpool set autoexpand=on tank', is het nu te laat, of kan dit nog?

Kan op elk moment.

3-Dit is een bootable pool (begon FreeBSD en zfs met zfsguru), zal 'zfs destroy tank/zfsguru' zonder problemen alle restanten ivm zfsguru verwijderen, en de ruimte beschikbaar zijn voor tank?

Hangt volledig aan welk OS je nu dan gebruikt? Ik neem aan iets anders dan zfsguru.

[inSane666]

Ik gebruik nu GhostBSD op een aparte SSD

[CurlyMo]

inSane666 schreef op zaterdag 15 januari 2022 @ 19:15:
Ik gebruik nu GhostBSD op een aparte SSD

1. https://www.reddit.com/r/...tm_medium=web2x&context=3
3. Ja, dat kan. Je kan voor de zekerheid nog eens rebooten terwijl de pool eerst handmatig geëxporteerd is.

[inSane666]

Hallo,

Die link is voor /dev/disk/by-id niet /gpt/label?

[CurlyMo]

inSane666 schreef op zondag 16 januari 2022 @ 11:29:
Hallo,

Die link is voor /dev/disk/by-id niet /gpt/label?

Maakt dat uit. Je zocht naar een manier om de schrijven beter uit elkaar te houden.

[cyborgium]

Halloo,

Ik probeer de oorzaak van een probleem te traceren en ik heb sterk het vermoeden dat de oorzaak bij mijn ZFS pool ligt. Misschien dat jullie mij inzicht zouden kunnen bieden/ervaringen delen.

Ik haal enorm lage write performance vanuit VMs die ik draaiende heb, in Proxmox. Waar ik toch wel minstens rond de GB/s zou verwachten, haal ik nauwelijks boven de 20 MB/s.

De ZFS pool waar ik het over heb, zijn 2 striped NVMe drives: 2x 1TB Intel 665p. ASHIFT van 13 en een recordsize van 16K.

In eerste instantie dacht ik dat het probleem bij mijn VM configuratie lag, en heb dus eigenlijk al alle mogelijke VM opties geprobeerd, zonder enige positieve impact.

Toen bedacht ik mij dat het ook zo maar eens niet bij het "virtualiseren" zou kunnen liggen, en begon ik te testen vanuit proxmox zelf.

Als test gebruik ik het volgende command:

code:

fio --name=seqwrite --rw=write --direct=1 --ioengine=libaio --bs=1M --numjobs=4 --size=5G --runtime=600 --group_reporting

Vanuit de VM is de schrijf snelheid constant met zo'n 18MB/s. Vanuit Proxmox is de schrijfsnelheid een goeie 2 seconden 1.4GB/s en blijft daarna tussen de 50MB/s en 80MB/s.

Als ik vervolgens dezelfde test uitvoer op een andere ZFS pool (2x MX500 striped), blijft deze constant op 500MB/s (terwijl dit over NFS is, ipv lokaal!).

Wat gaat hier fout? Ligt het eraan dat de betreffende intel SSDs geen DRAM cache hebben? Of omdat het QLC is? Zelfs dan had ik wel flink wat hogere snelheden verwacht dan 80MB/s...

Iemand enig idee?

[ Voor 0% gewijzigd door cyborgium op 21-01-2022 17:31 . Reden: Typo ]

[nero355]

cyborgium schreef op vrijdag 21 januari 2022 @ 17:27:
De ZFS pool waar ik het over heb, zijn 2 striped NVMe drives: 2x 1TB Intel 665p. ASHIFT van 13 en een recordsize van 16K.

Waarom heb je voor 13 gekozen

Meestal is het 9 of 12 en verder blijf je van die waarde af!

Verder ben ik persoonlijk tegen het "RAID-en" van SSD's tenzij je Enterprise modellen gebruikt met fatsoenlijke Garbage Collection omdat je dan vaak de T.R.I.M. functionaliteit verliest!

Wat gaat hier fout?

Een heleboel!

Ligt het eraan dat de betreffende intel SSDs geen DRAM cache hebben?
Of omdat het QLC is?

Beiden + de rest!

Zelfs dan had ik wel flink wat hogere snelheden verwacht dan 80MB/s...

Iemand enig idee?

Al die cheapass SSD's kakken in elkaar qua snelheid op het moment dat je buiten de DRAM Cache waarde komt en laat staan als ze een dergelijke Cache niet eens hebben!

Ik heb bijvoorbeeld dit soort benchmarks vroeger gezien :
- Fancy hipper de hip hip Samsung 850 Pro die iedereen geweldig vond, want oh zo snel!
- Intel S3710 of iets dergelijks uit de Enterprise reeksen van een random merk.

En ja, de Samsung is sneller, maar toen kon de Cache zijn werk niet meer doen en zakte de boel zwaar in elkaar, terwijl de Intel vrolijk door ging op een hogere snelheid!

Om over het gebruik in een "Write Caching" scenario maar te zwijgen, want dan viel de Samsung pas ECHT door de mand!


TL;DR :

Kies de juiste storage hardware voor jouw type gebruik!

[Thralas]

Interessante keus om uberhaupt SSDs te stripen. Hele uitzonderlijke use cases daargelaten heb je daar exact nul profijt van voor thuisgebruik. De rest zou ik zo uit de onderbuik inderdaad aan QLC toeschrijven. Niet gebruiken in combinatie met ZFS, komt alleen maar ellende van.

Theoretisch is het al niet om over naar huis te schrijven (en dat is het average case scenario):



Voor de goede orde zou ik je pool nog eens trimmen:

zpool trim tank
zpool status -t

En als het niet helpt die dingen inruilen voor één goede TLC SSD. Kingston A2000 (budget) of Samsung 980 Pro ofzo.

Verder: ik weet niet hoe je aan ashift=13 komt, maar als je dat zelf hebt gedaan dan zou ik daar vanaf blijven. ZFS kan de juiste getallen zelf wel bepalen, in geval van je SSDs is dat meestal ashift=12 vanwege een page size van 4k.

[Borromini]

Naar wat ik gelezen heb kan een hogere ashift-waarde wel minder kwaad dan een te lage?

[Thralas]

Klopt, het is hoogstens inefficiënter qua ruimte, het gaat het performanceprobleem niet oplossen.

[nero355]

Thralas schreef op vrijdag 21 januari 2022 @ 22:29:
Klopt, het is hoogstens inefficiënter qua ruimte, het gaat het performanceprobleem niet oplossen.

Maar het is toch ook een stukje alignment in feite wat je daarmee doet en zorgt er toch ook voor dat je SSD zo nuttig mogelijk alle Reads en Writes doet

[ Voor 3% gewijzigd door nero355 op 21-01-2022 22:58 ]

[cyborgium]

nero355 schreef op vrijdag 21 januari 2022 @ 19:25:

Waarom heb je voor 13 gekozen

Dit werd aangeraden op een forum ergens, ik kan dat niet meer terug vinden, maar dat heb ik toen met een reden gedaan..

nero355 schreef op vrijdag 21 januari 2022 @ 19:25:

Verder ben ik persoonlijk tegen het "RAID-en" van SSD's tenzij je Enterprise modellen gebruikt met fatsoenlijke Garbage Collection omdat je dan vaak de T.R.I.M. functionaliteit verliest!

Ik begrijp dat je dat zegt, maar zoals ik zei, met de micron mx500 ssds, welke ook zeker niet enterprise modellen zijn, heb ik dus veel betere performance. Uiteraard zou ik liever enterprise gaan, maar mijn portemonnee heeft daar helaas ook wat over te zeggen.

Zou je een alternatief kunnen aanraden voor vervanging van mijn intel ssds? Iets wat nog wel betaalbaar is, maar wat beter gaat performen dan deze...

Thralas schreef op vrijdag 21 januari 2022 @ 19:47:

Interessante keus om uberhaupt SSDs te stripen. Hele uitzonderlijke use cases daargelaten heb je daar exact nul profijt van voor thuisgebruik.

Ik heb zat ruimte op mijn HDD pools en ik maak dus dagelijk snapshots die daarop worden gereplicate. Daarom maak ik mij geen zorgen over dataverlies, en heb ik alleen maar de theoretische extra read performance plus voor mij belangrijker: bruikbare ruimte.

Thralas schreef op vrijdag 21 januari 2022 @ 19:47:

Verder: ik weet niet hoe je aan ashift=13 komt, maar als je dat zelf hebt gedaan dan zou ik daar vanaf blijven. ZFS kan de juiste getallen zelf wel bepalen, in geval van je SSDs is dat meestal ashift=12 vanwege een page size van 4k.

Reden hierboven vermeld, maar als verdere reactie: voor zover ik weet zet ZFS niet zelf waardes, behalve de default die voor alle pools hetzelfde is.
Dat is in ieder geval in Proxmox en in TrueNAS het geval, wat ik gebruik.
Verder misschien goed om erbij te vertellen dat de ASHIFT en recordsize waardes hetzelfde staan op die andere benoemde striped pool, met sata SSDs, waar ik dus wel de verwachte snelheden uit haal. Hier zou het dan dus niet aan moeten liggen.

Maar ik zal inderdaad de pool trimmen en het opnieuw proberen. Eventueel met ASHIFT12, maar ik denk niet dat dat enorme verschillen gaat opleveren.

[nero355]

cyborgium schreef op vrijdag 21 januari 2022 @ 23:01:
Ik begrijp dat je dat zegt, maar zoals ik zei, met de micron mx500 ssds, welke ook zeker niet enterprise modellen zijn, heb ik dus veel betere performance.

Maar dat zijn dan ook de betere SSD's in dit geval

Hoewel ik 500 MB/s niet echt heel snel vind voor een set die 2 x 500 MB/s zou moeten kunnen doen, maar goed...

Als de boel maar niet langzaam wordt zullen we maar zeggen!

Uiteraard zou ik liever enterprise gaan, maar mijn portemonnee heeft daar helaas ook wat over te zeggen.

Je moet gewoon niet het goedkoopste van het goedkoopste kopen en dan zal de boel al veel beter presteren!

Aan de andere kant : Doe het één keer goed en je hebt er geen omkijken meer naar!

Zo heb ik nog steeds het volgende in gebruik :
- 1 x 120 GB Intel 320 Series
- 1 x 300 GB Intel 320 Series
- 1 x 960 GB Crucial M500 Series

Waarbij dus alle drie eigenlijk veel beter zijn dan de hedendaagse SSD's die geen MLC meer zijn en niet eens deels tegen stroomuitval zijn beschermd zoals de Crucial of laat staan volledig zoals de Intels

Zou je een alternatief kunnen aanraden voor vervanging van mijn intel ssds?

Iets wat nog wel betaalbaar is, maar wat beter gaat performen dan deze...

Zou je zoiets interessant vinden : nero355 in "Het grote Proxmox VE topic"

Anders moet je maar eens naar SATA Intel modellen kijken, desnoods tweedehands ?!
Blader eens https://tweakers.net/pric...aF_DFWsG2vs0nhCyG-QP-y-Gw door

[CurlyMo]

@cyborgium ashift wordt wel degelijk automatisch aangepast. Ik had er recent nog mee van doen. Een pool gemaakt met een 512 record size SSD kreeg netjes een ashift van 9. De nieuwe SSD die ik er aan toevoegde gaf een melding want daarvan was de record size 4096. Toen de pool helemaal opnieuw gemaakt met de nieuwe SSD als begin schijf en toen werd de ashift automatisch 12.

[cyborgium]

CurlyMo schreef op vrijdag 21 januari 2022 @ 23:25:
@cyborgium ashift wordt wel degelijk automatisch aangepast. Ik had er recent nog mee van doen. Een pool gemaakt met een 512 record size SSD kreeg netjes een ashift van 9. De nieuwe SSD die ik er aan toevoegde gaf een melding want daarvan was de record size 4096. Toen de pool helemaal opnieuw gemaakt met de nieuwe SSD als begin schijf en toen werd de ashift automatisch 12.

Hmm toch maar eens naar kijken dan, dankje!

nero355 schreef op vrijdag 21 januari 2022 @ 23:19:

Zou je zoiets interessant vinden : nero355 in "Het grote Proxmox VE topic"

Dat is niet verkeerd, vooral omdat ik al een PM983 heb die eigenlijk niets zit te doen. Moet ik alleen een andere PCIe adapter zien te vinden, die ook 110mm ondersteunen. Misschien dat ik nog twee PM893 betaalbaar op ebay kan vinden.

[cyborgium]

nero355 schreef op vrijdag 21 januari 2022 @ 23:19:
Zo heb ik nog steeds het volgende in gebruik :
- 1 x 120 GB Intel 320 Series
- 1 x 300 GB Intel 320 Series
- 1 x 960 GB Crucial M500 Series

Een andere, ongerelateerde vraag maar jij lijkt te weten waar je het over hebt: Ik heb nog een Intel SSD DC S3500 van 128GB liggen. Deze is oud, maar wel enterprise grade. Zou dit het waard zijn als SLOG of L2ARC voor wat spinnend roest?

Ik kan weinig info vinden over die specifieke reek. Ik zou het simpelweg proberen, maar het vraagt nogal wat ombouwen van mijn huidige hardware om dat mogelijk te maken..

[nero355]

cyborgium schreef op vrijdag 21 januari 2022 @ 23:41:
Een andere, ongerelateerde vraag maar jij lijkt te weten waar je het over hebt: Ik heb nog een Intel SSD DC S3500 van 128GB liggen.
Deze is oud, maar wel enterprise grade.

Zou dit het waard zijn als SLOG of L2ARC voor wat spinnend roest?

Prima spul!

Ik kan weinig info vinden over die specifieke reek.

In principe zou dit moeten kloppen : https://tweakers.net/soli...W6hjpKBYnpqcGZValKVqYGtQA

Ik zou het simpelweg proberen, maar het vraagt nogal wat ombouwen van mijn huidige hardware om dat mogelijk te maken..

Hou er wel rekening mee dat dergelijke setups vooral voor de Sync Writes worden gebruikt en je dus misschien weinig ermee opschiet in jouw setup!

Maar voor zover ik weet kan het nooit de situaties slechter maken dus als je het wilt proberen dan kan dat altijd nog, echter moet je wel eraan denken dat het eventueel verwijderen van een dergelijke Cache best wel een heel gedoe kan zijn!
Dus pak effe de Search erbij : Het grote ZFS topic

[cyborgium]

Thralas schreef op vrijdag 21 januari 2022 @ 19:47:

Voor de goede orde zou ik je pool nog eens trimmen:

zpool trim tank
zpool status -t

Dit heeft al wonderen gedaan! Ik haal nu gemiddeld 400MB/s sequential writes, dat is al flink beter. Maar eens verdiepen in wat dat doet en het automatiseren.

[nero355]

cyborgium schreef op zaterdag 22 januari 2022 @ 00:06:
Dit heeft al wonderen gedaan! Ik haal nu gemiddeld 400MB/s sequential writes, dat is al flink beter.

NICE!

Maar eens verdiepen in wat dat doet en het automatiseren.

Daar had ik het dus al eerder over : Wikipedia: Trim (computing)

[Thralas]

cyborgium schreef op zaterdag 22 januari 2022 @ 00:06:
Dit heeft al wonderen gedaan! Ik haal nu gemiddeld 400MB/s sequential writes, dat is al flink beter. Maar eens verdiepen in wat dat doet en het automatiseren.

Meevaller.

Het vertelt de SSD welke blocks niet meer worden gebruikt, zodat hij efficiënt kan blijven wear levelen. Voor iedere SSD ontzettend belangrijk om 'm op snelheid te houden.

Maar voor veel QLCs zou het wel eens nóg belangrijker kunnen zijn, in ieder geval een aantal QLC SSDs heeft een SLC cache die schaalt op basis van ruimtegebruik (meer ruimte vrij = meer SLC). Als je helemaal nooit trimt/discard heb je een schijf die helemaal 'vol' zit, dat lijkt me voor QLC helemaal desastreus.

ZFS heeft een property die automatisch kan discarden/trimmen (dat doen de meeste filesystems eigenlijk), maar de handleiding raadt het af:

quote: https://openzfs.github.io...7.html?highlight=autotrim

Be aware that automatic trimming of recently freed data blocks can put significant stress on the underlying storage devices. This will vary depending of how well the specific device handles these commands. For lower-end devices it is often possible to achieve most of the benefits of automatic trimming by running an on-demand (manual) TRIM periodically using the zpool trim command.

Ik heb een systemd timer die iedere week een trim uitvoert, dat werkt prima.

CurlyMo schreef op vrijdag 21 januari 2022 @ 23:25:
@cyborgium ashift wordt wel degelijk automatisch aangepast. Ik had er recent nog mee van doen. Een pool gemaakt met een 512 record size SSD kreeg netjes een ashift van 9. De nieuwe SSD die ik er aan toevoegde gaf een melding want daarvan was de record size 4096. Toen de pool helemaal opnieuw gemaakt met de nieuwe SSD als begin schijf en toen werd de ashift automatisch 12.

Inderdaad, het was even 'in de mode' toen AF drives net nieuw waren, toen werkte de autodetect ook nog niet altijd goed (met drives die logen over hun physical sector size). Inmiddels zijn grote schijven meestal 4Kn, denk ik?

Zie ook, de broncode:

C:

    /* Based on the minimum sector size set the block size */
    *physical_ashift = highbit64(MAX(physical_block_size,
        SPA_MINBLOCKSIZE)) - 1;

[ Voor 25% gewijzigd door Thralas op 22-01-2022 00:37 ]

[cyborgium]

@nero355
Wat dacht je van https://www.proshop.nl/SS...E-M2-NVMe-SSD-1TB/2970811?

Stuk goedkoper dan wat ik tweedehands kan krijgen voor de PM983.... Ik ben niet zo bang voor dataverlies door stroom storingen, gebeurt vrijwel nooit waar ik woon.

[Thralas]

In ieder geval TLC, maar ook DRAMless.

Helaas geen review van Anandtech. Je kunt de review van de Samsung 980 (non-pro) lezen om te zien wat je ongeveer kunt verwachten.

Het is geen 980 Pro, maar daar is de prijs dan ook naar. Die PM983 is vermoedelijk beter, zou daar een PCIe bracket voor ritselen als je 'm toch al hebt..

[cyborgium]

Thralas schreef op zaterdag 22 januari 2022 @ 01:11:
In ieder geval TLC, maar ook DRAMless.

Helaas geen review van Anandtech. Je kunt de review van de Samsung 980 (non-pro) lezen om te zien wat je ongeveer kunt verwachten.

Het is geen 980 Pro, maar daar is de prijs dan ook naar. Die PM983 is vermoedelijk beter, zou daar een PCIe bracket voor ritselen als je 'm toch al hebt..

Oke, dan ga ik daar niet voor. Dank en ook voor de tip voor anandtech.

In mijn server heb ik geen PCIe sloten meer over, vandaar dat het lastig is om deze te gebruiken. Ik heb nu een goedkope adapter voor 4x pcie 3.0 x4 lanes, maar deze hebben geen schroefgaten op 110mm helaas.

[nero355]

cyborgium schreef op zaterdag 22 januari 2022 @ 00:35:
@nero355
Wat dacht je van https://www.proshop.nl/SS...E-M2-NVMe-SSD-1TB/2970811?

Stuk goedkoper dan wat ik tweedehands kan krijgen voor de PM983.... Ik ben niet zo bang voor dataverlies door stroom storingen, gebeurt vrijwel nooit waar ik woon.

Nog liever een oude WD Raptor ADFD dan dat ding!

Maar effe serieus : Is gewoon Consumer Level meuk dat probeert te leunen op de naam van de oude WD Black Series HDD's maar dat verre van is of ooit zal worden!

[cyborgium]

Hahah ja daar was ik al bang voor.

Ik heb een adapter gevonden die 4 110mm m.2 sloten heeft dus zodra ik weet of die een beetje werkt, bestel ik nog twee PM983 ssds.

[Thralas]

cyborgium schreef op zaterdag 22 januari 2022 @ 17:06:
Ik heb een adapter gevonden die 4 110mm m.2 sloten heeft dus zodra ik weet of die een beetje werkt, bestel ik nog twee PM983 ssds.

Je weet dat dat soort adapters alleen werken als je moederbord PCIe bifurcation ondersteunt (tenzij er een PCIe switch opzit, maar dat is meestal niet)?

Zo nee, dan nu.

[cyborgium]

Thralas schreef op zaterdag 22 januari 2022 @ 18:19:
[...]


Je weet dat dat soort adapters alleen werken als je moederbord PCIe bifurcation ondersteunt (tenzij er een PCIe switch opzit, maar dat is meestal niet)?

Zo nee, dan nu.

Zeker! Mijn dell r630 heeft op alle sloten bifurcation support;)

[jwvdst]

cyborgium schreef op zondag 23 januari 2022 @ 00:24:
[...]


Zeker! Mijn dell r630 heeft op alle sloten bifurcation support;)

moet je dat niet instellen in de bios of gaat dat automatisch? Bij mijn fujitsu moet ik dat handmatig instellen op 8x8 of 8x4x4
ik heb dus een fujitsu moederbord die max 8x4x4 bifurcation ondersteund. dat houdt in dat als je een adapterkaart kaart hebt die 4 nvme sloten heeft er dan 3 werken. In mijn geval slot 1, 3 en 4 op de adapterkaart. als je 4x4x4x4 bifurcation kunt selecteren in de bios werken alle 4 nvme's op de adapterkaart.
Bij 8x8 bifurcation werken er maar 2 van de 4 nvme's op de adapterkaart

[cyborgium]

jwvdst schreef op zondag 23 januari 2022 @ 13:05:
[...]
moet je dat niet instellen in de bios of gaat dat automatisch? Bij mijn fujitsu moet ik dat handmatig instellen op 8x8 of 8x4x4
ik heb dus een fujitsu moederbord die max 8x4x4 bifurcation ondersteund. dat houdt in dat als je een adapterkaart kaart hebt die 4 nvme sloten heeft er dan 3 werken. In mijn geval slot 1, 3 en 4 op de adapterkaart. als je 4x4x4x4 bifurcation kunt selecteren in de bios werken alle 4 nvme's op de adapterkaart.
Bij 8x8 bifurcation werken er maar 2 van de 4 nvme's op de adapterkaart

Ik kan op de 2 PCIe sloten die mijn r630 heeft, het x16 slot instellen op 8x8 en 4x4x4x4, en het 8x slot ook instellen op 4x4.

[RobertMe]

jwvdst schreef op zondag 23 januari 2022 @ 13:05:
[...]
moet je dat niet instellen in de bios of gaat dat automatisch? Bij mijn fujitsu moet ik dat handmatig instellen op 8x8 of 8x4x4
ik heb dus een fujitsu moederbord die max 8x4x4 bifurcation ondersteund. dat houdt in dat als je een adapterkaart kaart hebt die 4 nvme sloten heeft er dan 3 werken. In mijn geval slot 1, 3 en 4 op de adapterkaart. als je 4x4x4x4 bifurcation kunt selecteren in de bios werken alle 4 nvme's op de adapterkaart.
Bij 8x8 bifurcation werken er maar 2 van de 4 nvme's op de adapterkaart

Lichtelijk offtopic, maar welk Fujitsu bord is dat? Toevallig een D3644-B? Die heb ikzelf en komt ook heel vaak langs in het grote zuinige server topic. Kan dan dus wel een interessant "weetje" zijn.
En nog meer offtopic, toevallig zelf vorige week met een no-name AliExpress adapter een tweede NVME drive toegevoegd aan mijn, op Proxmox, gebaseerd systeem. Waarmee de root pool nu redundant is uitgevoerd. Maar kaartje is dan wel maar met één M.2 aansluiting.

[jwvdst]

RobertMe schreef op zondag 23 januari 2022 @ 13:40:
[...]

Lichtelijk offtopic, maar welk Fujitsu bord is dat? Toevallig een D3644-B? Die heb ikzelf en komt ook heel vaak langs in het grote zuinige server topic. Kan dan dus wel een interessant "weetje" zijn.
En nog meer offtopic, toevallig zelf vorige week met een no-name AliExpress adapter een tweede NVME drive toegevoegd aan mijn, op Proxmox, gebaseerd systeem. Waarmee de root pool nu redundant is uitgevoerd. Maar kaartje is dan wel maar met één M.2 aansluiting.

klopt is idd de D3644-B.
Heb zelf 6 nvme's in mijn systeem. 1x onboard, 3x met een 4x nvme adapter kaart op het x16 pcie slot en 1 met een adapter op het x8 pcie slot deze 5 hangen middels passthrough aan m'n nas vm en dan heb ik nog een nvme SSD op een X1 pcie slot voor de datastore van esxi

[GioStyle]

jwvdst schreef op zondag 23 januari 2022 @ 23:11:
[...]
klopt is idd de D3644-B.
Heb zelf 6 nvme's in mijn systeem. 1x onboard, 3x met een 4x nvme adapter kaart op het x16 pcie slot en 1 met een adapter op het x8 pcie slot deze 5 hangen middels passthrough aan m'n nas vm en dan heb ik nog een nvme SSD op een X1 pcie slot voor de datastore van esxi

Nooit geweten dat het kon! Interessant!

Welke 4x nmve adapter heb je gebruikt?

[jwvdst]

GioStyle schreef op maandag 24 januari 2022 @ 09:51:
[...]


Nooit geweten dat het kon! Interessant!

Welke 4x nmve adapter heb je gebruikt?

ik gebruik deze https://www.kortingcamera.nl/pcie_4x_nvme_card
doet het zonder problemen en wordt geleverd met full en low profile bracket
ik heb er geen klagen over

[cyborgium]

jwvdst schreef op maandag 24 januari 2022 @ 20:00:
[...]

ik gebruik deze https://www.kortingcamera.nl/pcie_4x_nvme_card
doet het zonder problemen en wordt geleverd met full en low profile bracket
ik heb er geen klagen over

Dit is ook die ik op het moment gebruik, werkt inderdaad prima. Het enige nadeel van het installeren van de SSDs aan de onderkant, is dat je vaak niet dan nog een heatsink om de SSD heen kan doen, als er een kaart in het slot erboven zit. Of in mijn geval, waar het een 1u chassis is, waar nauwelijks clearance is onder de PCB van de adapter.

Ik heb zelf deze net besteld, voor ivm 110mm SSDs.
Hierdoor ga ik dus die andere overhouden, mocht iemand interesse hebben dan mag je die zo hebben!

[jwvdst]

cyborgium schreef op maandag 24 januari 2022 @ 23:00:
[...]


Dit is ook die ik op het moment gebruik, werkt inderdaad prima. Het enige nadeel van het installeren van de SSDs aan de onderkant, is dat je vaak niet dan nog een heatsink om de SSD heen kan doen, als er een kaart in het slot erboven zit. Of in mijn geval, waar het een 1u chassis is, waar nauwelijks clearance is onder de PCB van de adapter.

Ik heb zelf deze net besteld, voor ivm 110mm SSDs.
Hierdoor ga ik dus die andere overhouden, mocht iemand interesse hebben dan mag je die zo hebben!

Is die jij gesteld hebt niet precies dezelfde met enigste verschil dat ie wat langer is zodat er 110mm nvme ssd's op passen?

[cyborgium]

jwvdst schreef op dinsdag 25 januari 2022 @ 21:20:
[...]
Is die jij gesteld hebt niet precies dezelfde met enigste verschil dat ie wat langer is zodat er 110mm nvme ssd's op passen?

Dat is zeker zo!

[inSane666]

inSane666 schreef op zaterdag 15 januari 2022 @ 16:44:
1-Deze zomer heb ik een schijf moeten vervangen, kan iemand mij uitleggen hoe, nu ik 5 nieuwe disks heb om de resterende te vervangen, deze eerst een label kan geven?

Ik heb zelf nog wat liggen zoeken en kom tot dit resultaat:

gpart add -t freebsd-zfs -a 4k -b 1m -s <10sectoren minder dan totaal harde schijf?> -l Seagate01 ada5

met opties b en s als start positie en 'stop' positie/grootte van de partitie
optie l is het enige waar ik naar op zoek was

[Houbie]

Hey,

Ik heb een machine met een raidz2 met 5 schijven (3x wd green, 2x wd red).
De schijven zijn al wat ouder, maar ik heb er eigenlijk nooit echt problemen mee gehad.

code:

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   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   158   135   021    Pre-fail  Always       -       9075
  4 Start_Stop_Count        0x0032   077   077   000    Old_age   Always       -       23726
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   069   069   000    Old_age   Always       -       22758
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   080   080   000    Old_age   Always       -       20762
192 Power-Off_Retract_Count 0x0032   199   199   000    Old_age   Always       -       870
193 Load_Cycle_Count        0x0032   193   193   000    Old_age   Always       -       22868
194 Temperature_Celsius     0x0022   117   101   000    Old_age   Always       -       35
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       10
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       1

Sinds gisteren geeft smartd een fout aan, Current_Pending_Sector is van 0 naar 2 naar 10 gegaan. Als ik het online opzoek, lijkt dit geen kleine fout te zijn, maar eigenlijk het einde van mijn schijf.

HIer en daar lees ik dat dit aan de SATA kabel zou kunnen liggen. De kabels die ik gebruik zijn oude kabels die ik nog liggen had.

Is het de moeite om eerst de kabel te vervangen, of gaat de schijf sowieso vervangen moeten worden?

[FireDrunk]

Houbie schreef op woensdag 2 februari 2022 @ 10:39:
Hey,

Ik heb een machine met een raidz2 met 5 schijven (3x wd green, 2x wd red).
De schijven zijn al wat ouder, maar ik heb er eigenlijk nooit echt problemen mee gehad.

code:

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   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   158   135   021    Pre-fail  Always       -       9075
  4 Start_Stop_Count        0x0032   077   077   000    Old_age   Always       -       23726
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   069   069   000    Old_age   Always       -       22758
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   080   080   000    Old_age   Always       -       20762
192 Power-Off_Retract_Count 0x0032   199   199   000    Old_age   Always       -       870
193 Load_Cycle_Count        0x0032   193   193   000    Old_age   Always       -       22868
194 Temperature_Celsius     0x0022   117   101   000    Old_age   Always       -       35
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       10
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       1

Sinds gisteren geeft smartd een fout aan, Current_Pending_Sector is van 0 naar 2 naar 10 gegaan. Als ik het online opzoek, lijkt dit geen kleine fout te zijn, maar eigenlijk het einde van mijn schijf.

HIer en daar lees ik dat dit aan de SATA kabel zou kunnen liggen. De kabels die ik gebruik zijn oude kabels die ik nog liggen had.

Is het de moeite om eerst de kabel te vervangen, of gaat de schijf sowieso vervangen moeten worden?

Check je SMART

Op zich zijn pending sectors niet *direct* een probleem, maar kunnen dat op termijn wel worden. Het lastige is dat als een sector kapot is, deze reallocated moet worden, door er een keer naar te schrijven. Als die sector in een gigantisch dataset zit, waar het verloop van je data laag is (denk aan grote media volumes), dan duurt het wel even voordat er naar die sector geschreven wordt.

In theorie kan je de schijf uit je Pool halen, leeg maken (volledig vol schrijven met nullen bijvoorbeeld), dan zou die Current Pending Sector omgezet moeten worden in een Reallocated Sector (er is dan reserve ruimte in gebruik genomen om die sector te vervangen). Als je hem daarna weer toevoegt aan de pool, zou ZFS dmv een resilver de schijf gewoon weer in gebruik moeten kunnen nemen.
Stijgt het aantal hard, en blijft het aantal Pending Sectors, en het aantal Reallocated Sectors stijgen, is je schijf wel aan het overlijden.

Ik heb ooit een schijf gehad met 2 reallocated sectors, welke daarna nog jaren doorgedraaid heeft. Het *hoeft* niet perse een probleem te zijn. Maar het kan wel.

[Tha_Butcha]

ik ben bezig met wat datasets van een verrotte pool over te zetten naar een nieuwe pool, d.m.v. syncoid. de meeste datasets gaan probleemloos, echter bij 1 krijg ik echter de volgende error:

[quote]
cannot hold: operation not supported by zfs kernel module ] 0% ETA 0:00:00
cannot send 'pool0/home': operation not supported by zfs kernel module
624 B 0:00:14 [44.4 B/s] [> ] 0%
cannot receive: failed to read from stream
CRITICAL ERROR: zfs send -I 'pool0/home'@'syncoid_raphael.amk27.voesten.lan_2017-03-13:19:35:28' 'pool0/home'@'syncoid_srv-nas-01_2022-02-01:02:05:24' | mbuffer -q -s 128k -m 16M 2>/dev/null | pv -s 313134630128 | zfs receive -s -F 'pool2/home' failed: 256 at /usr/sbin/syncoid line 500.[/code]

Systeem draait Ubuntu 20.04 LTS kernel, 5.4.0-90-generic.

Google heeft het hoogstens over permissions die niet zouden kloppen, de specifieke error return kan ik niet terug vinden; plus ik gebruik sudo.

Enig idee waar ik moet zoeken?

[FireDrunk]

Tha_Butcha schreef op woensdag 2 februari 2022 @ 13:10:
ik ben bezig met wat datasets van een verrotte pool over te zetten naar een nieuwe pool, d.m.v. syncoid. de meeste datasets gaan probleemloos, echter bij 1 krijg ik echter de volgende error:

[quote]
cannot hold: operation not supported by zfs kernel module ] 0% ETA 0:00:00
cannot send 'pool0/home': operation not supported by zfs kernel module
624 B 0:00:14 [44.4 B/s] [> ] 0%
cannot receive: failed to read from stream
CRITICAL ERROR: zfs send -I 'pool0/home'@'syncoid_raphael.amk27.voesten.lan_2017-03-13:19:35:28' 'pool0/home'@'syncoid_srv-nas-01_2022-02-01:02:05:24' | mbuffer -q -s 128k -m 16M 2>/dev/null | pv -s 313134630128 | zfs receive -s -F 'pool2/home' failed: 256 at /usr/sbin/syncoid line 500.[/code]

Systeem draait Ubuntu 20.04 LTS kernel, 5.4.0-90-generic.

Google heeft het hoogstens over permissions die niet zouden kloppen, de specifieke error return kan ik niet terug vinden; plus ik gebruik sudo.

Enig idee waar ik moet zoeken?

Klinkt alsof er een feature flag mismatch is, heb je die al nagekeken op source en target pools?

[nero355]

Tha_Butcha schreef op woensdag 2 februari 2022 @ 13:10:

code:

cannot hold: operation not supported by zfs kernel module

cannot send 'pool0/home': operation not supported by zfs kernel module

failed: 256 at /usr/sbin/syncoid line 500.

Enig idee waar ik moet zoeken?

Naast dit :

FireDrunk schreef op woensdag 2 februari 2022 @ 13:42:
Klinkt alsof er een feature flag mismatch is, heb je die al nagekeken op source en target pools?

- Ook effe de ZFS versies met elkaar vergelijken!
- Kijk in de broncode van syncoid op line 500 wat daar precies staat : Met een beetje geluk zie je gelijk welke feature of commando voor de error zorgt

Als ik hier op regel 500 kijk : https://github.com/jimsalterjrs/sanoid/blob/master/syncoid
Dan zie ik helaas alleen wat commented text...

[Thralas]

FireDrunk schreef op woensdag 2 februari 2022 @ 11:18:
Op zich zijn pending sectors niet *direct* een probleem, maar kunnen dat op termijn wel worden.

Dit mist wat nuance: het is juist wel direct een probleem, omdat iedere keer als je disk toch die sector probeert te lezen je hele disk onbruikbaar is voor ettelijke seconden.

Wat je zegt klopt wel voor reallocated sectors.

Ik heb ooit een schijf gehad met 2 reallocated sectors, welke daarna nog jaren doorgedraaid heeft. Het *hoeft* niet perse een probleem te zijn. Maar het kan wel.

Dat is wat je volgens mij waar je met de eerdere opmerking op doelt en daarmee ben ik het wel helemaal eens. Te snel wordt er (hier) geroepen dat een disk met een paar bad sectors per definitie onbruikbaar is. Terwijl je een heel redelijke kans hebt dat het bij een paar sectors blijft

Als het je meer geld kost om te klooien met disks (zakelijk), garantie hebt, of je echt heel veel zorgen maakt over je data: absoluut omwisselen, maar voor thuis is er best wat voor te zeggen om het ding een keer te wipen en zien hoe 'ie het doet.

Houbie schreef op woensdag 2 februari 2022 @ 10:39:
Is het de moeite om eerst de kabel te vervangen, of gaat de schijf sowieso vervangen moeten worden?

De kabel vervangen gaat niets uithalen, verder zou ik doen wat @FireDrunk zegt: wipen, SMART nogmaals controleren en dan beslissen of je 'm vervangt of terug in de array stopt.

[Houbie]

Thralas schreef op woensdag 2 februari 2022 @ 17:56:
[...]


Dit mist wat nuance: het is juist wel direct een probleem, omdat iedere keer als je disk toch die sector probeert te lezen je hele disk onbruikbaar is voor ettelijke seconden.

Wat je zegt klopt wel voor reallocated sectors.


[...]


Dat is wat je volgens mij waar je met de eerdere opmerking op doelt en daarmee ben ik het wel helemaal eens. Te snel wordt er (hier) geroepen dat een disk met een paar bad sectors per definitie onbruikbaar is. Terwijl je een heel redelijke kans hebt dat het bij een paar sectors blijft

Als het je meer geld kost om te klooien met disks (zakelijk), garantie hebt, of je echt heel veel zorgen maakt over je data: absoluut omwisselen, maar voor thuis is er best wat voor te zeggen om het ding een keer te wipen en zien hoe 'ie het doet.


[...]


De kabel vervangen gaat niets uithalen, verder zou ik doen wat @FireDrunk zegt: wipen, SMART nogmaals controleren en dan beslissen of je 'm vervangt of terug in de array stopt.

Als ik de schijf eruit zou halen en wipen, dan geef je aan dat met een long smart test, de relocated sector count terug op nul moet komen? Wat zou ik zien als de schijf echt kapot is, dat ook een lege schijf toch reallocated sectors heeft?

[FireDrunk]

Thralas schreef op woensdag 2 februari 2022 @ 17:56:
[...]


Dit mist wat nuance: het is juist wel direct een probleem, omdat iedere keer als je disk toch die sector probeert te lezen je hele disk onbruikbaar is voor ettelijke seconden.

Wat je zegt klopt wel voor reallocated sectors.


[...]


Dat is wat je volgens mij waar je met de eerdere opmerking op doelt en daarmee ben ik het wel helemaal eens. Te snel wordt er (hier) geroepen dat een disk met een paar bad sectors per definitie onbruikbaar is. Terwijl je een heel redelijke kans hebt dat het bij een paar sectors blijft

Als het je meer geld kost om te klooien met disks (zakelijk), garantie hebt, of je echt heel veel zorgen maakt over je data: absoluut omwisselen, maar voor thuis is er best wat voor te zeggen om het ding een keer te wipen en zien hoe 'ie het doet.


[...]


De kabel vervangen gaat niets uithalen, verder zou ik doen wat @FireDrunk zegt: wipen, SMART nogmaals controleren en dan beslissen of je 'm vervangt of terug in de array stopt.

Je hebt helemaal gelijk! De sector in kwestie is wel degelijk 'stuk'. Dat mag inderdaad wel expliciet gezegd worden.
Het is alleen in zijn geval geen probleem omdat hij ZFS met redundancy draait. Dus de data is nog beschikbaar op andere disks.

[Tha_Butcha]

nero355 schreef op woensdag 2 februari 2022 @ 15:29:
[...]

Naast dit :

[...]

- Ook effe de ZFS versies met elkaar vergelijken!
- Kijk in de broncode van syncoid op line 500 wat daar precies staat : Met een beetje geluk zie je gelijk welke feature of commando voor de error zorgt

source pool liep nog achter, maar is nu gelijk getrokken. Syncoid had ik al doorgespit - voor zover mijn roestige perl kennis het nog doet - kom ik altijd bij de standaard try/catch uit, zonder al te veel relevant of informatief commentaar.

Ik heb ook nog geprobeerd gewoon zelf het zfs commando in te voeren, met (uiteraard) het zelfde resultaat:

code:

[user@srv-nas-01:~]$ zfs send  -I 'pool0/home'@'syncoid_raphael.amk27.voesten.lan_2017-03-13:19:35:28' 'pool0/home'@'syncoid_srv-nas-01_2022-02-02:17:17:01' | mbuffer  -q -s 128k -m 16M 2>/dev/null | pv -s 313158995656 |  zfs receive  -s -F 'pool2/home' 2>&1
cannot hold: operation not supported by zfs kernel module                                                                                                                         
cannot send 'pool0/home': operation not supported by zfs kernel module

Nu ben ik geen zfs wizard, maar een send/receive lijkt me niets exotisch. Zeker omdat ie bij andere datasets gewoon wel loopt.

Nu weet ik dat ubuntu lts nogal achterloopt qua versie van openzfs (0.8.3 geloof ik), dus ik ga ff kijken of dat upgraden misschien wat helpt.

[Thralas]

Houbie schreef op woensdag 2 februari 2022 @ 18:01:
Als ik de schijf eruit zou halen en wipen, dan geef je aan dat met een long smart test, de relocated sector count terug op nul moet komen?

Nee. De pending sector count hoort dan op nul te staan.

De reallocated count zou dan wél op kunnen zijn gelopen. Bijvoorbeeld om de 10 pending sector die je nu minstens hebt te heralloceren. Of meer als er toch nog meer bad sectors zijn. Of minder als 'ie ze toch weer te beschrijven.

Met andere woorden: wipe and see.

Wat zou ik zien als de schijf echt kapot is, dat ook een lege schijf toch reallocated sectors heeft?

Dat je de hele disk wipet, een extended test doet (of handmatig helemaal uitlezen) en dan toch wéér tegen errors aanloopt. Dan is een disk echt stuk. Met de meeste disks met een paar bad sectors krijg je een disk terug die gewoon weer zoals vanouds werkt na een wipe.

[Thralas]

Tha_Butcha schreef op woensdag 2 februari 2022 @ 22:19:
Nu ben ik geen zfs wizard, maar een send/receive lijkt me niets exotisch. Zeker omdat ie bij andere datasets gewoon wel loopt.

En de feature flags waar je op gewezen bent?

Hint, en tevens waar ik m'n geld op inzet:

# zpool get all | grep feature
rpool   feature@bookmarks              active                         local

Bij nader inzien: het versturen van holds vereist een expliciete optie, daarnaast lijkt dit van de verzendende kant te komen. Dan gok ik dat je zfs tools out-of-sync zijn geraakt met je kernelmodule.

[ Voor 18% gewijzigd door Thralas op 02-02-2022 22:55 ]