Puncte:1

zfs nu își recunoaște propriile discuri fizice

drapel us

Am o problemă care se repetă cu pool-ul zfs, unde zfs încetează să-și recunoască propriile dispozitive fizice etichetate corect (sau așa se pare).

Ubuntu 20.04.2 LTS
5.11.0-44-generic #48~20.04.2-Ubuntu SMP Mar 14 Dec 15:36:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
libzfs2linux/now 0.8.3-1ubuntu12.11 amd64 [instalat, upgradabil la: 0.8.3-1ubuntu12.13]
zfs-zed/now 0.8.3-1ubuntu12.11 amd64 [instalat, upgradabil la: 0.8.3-1ubuntu12.13]
zfsutils-linux/now 0.8.3-1ubuntu12.11 amd64 [instalat, upgradabil la: 0.8.3-1ubuntu12.13]

Exemple model.

  1. Pot crea un pool, pot conecta un disc complet fără legătură (de ex.usb, extern) și la repornire (cu discul USB în interior) zfs raportează că unul dintre discurile din pool-ul său lipsește.
  2. Același lucru pare să se întâmple și cu schimbarea controlerului pentru una (sau poate mai multe) dintre unități. Toate discurile fizice sunt acolo, toate etichetele/uuid-urile par să fie acolo, ceea ce se schimbă este atribuirea literei dispozitivului.

Este greu de crezut că zfs asambla pool-ul pe baza ordinii de alocare a dispozitivelor sistemului ignorând etichetele/uuid-urile sale, dar așa arată pur și simplu.

    agatek@mmstorage:~$ stare zpool
          pool: mmdata
         stare: DEGRADAT
        stare: unul sau mai multe dispozitive nu au putut fi utilizate deoarece eticheta lipsește sau
            invalid. Există suficiente replici pentru ca pool-ul să continue
            functionand intr-o stare degradata.
        acțiune: Înlocuiți dispozitivul folosind „zpool replace”.
           vezi: http://zfsonlinux.org/msg/ZFS-8000-4J
          scanare: spălare în desfășurare din duminica 9 ianuarie 13:03:23 2022
            650G scanat la 1,58G/s, 188G emis la 468M/s, 22,7T total
            0B reparat, 0,81% gata, 0 zile 14:00:27 mai departe
        config:

        NUME STAT CITEȘTE SCRIE CKSUM
        mmdata DEGRADATE 0 0 0
          raidz1-0 DEGRADAT 0 0 0
            ata-HGST_HDN726040ALE614_K7HJG8HL ONLINE 0 0 0
            6348126275544519230 FAULTED 0 0 0 was /dev/sdb1
            ata-HGST_HDN726040ALE614_K3H14ZAL ONLINE 0 0 0
            ata-HGST_HDN726040ALE614_K4K721RB ONLINE 0 0 0
            ata-WDC_WD40EZAZ-00SF3B0_WD-WX12D514858P ONLINE 0 0 0
            ata-ST4000DM004-2CV104_ZTT24X5R ONLINE 0 0 0
            ata-WDC_WD40EZAZ-00SF3B0_WD-WX62D711SHF4 ONLINE 0 0 0
            sdi ONLINE 0 0 0
    
    erori: nu există erori de date cunoscute

agatek@mmstorage:~$ blkid 
/dev/sda1: UUID="E0FD-8D4F" TYPE="vfat" PARTUUID="7600a192-967b-417f-b726-7f5524be71a5"
/dev/sda2: UUID="9d8774ec-051f-4c60-aaa7-82f37dbaa4a4" TYPE="ext4" PARTUUID="425f31b2-f289-496a-911b-a2f8a9bb5c25"
/dev/sda3: UUID="e0b8852d-f781-4891-8e77-d8651f39a55b" TYPE="ext4" PARTUUID="a750bae3-c6ea-40a0-bdfa-0523e358018b"
/dev/sdb1: LABEL="mmdata" UUID="16683979255455566941" UUID_SUB="13253481390530831214" TYPE="zfs_member" PARTLABEL="zfs-5360ecc2669a2000000000000000000000000000000000000000000000000000001
/dev/sdd1: LABEL="mmdata" UUID="16683979255455566941" UUID_SUB="17929921080902463088" TYPE="zfs_member" PARTLABEL="zfs-f6ef14dfs-f6ef14df83c9bdf04df86f14dfdf86f14df83c9bdf0df83c9bdf0df83c9bd0bdf83c9bd0df83c9bdb
/dev/sde1: LABEL="mmdata" UUID="16683979255455566941" UUID_SUB="505855664557329830" TYPE="zfs_member" PARTLABEL="zfs-6326993c1426993c1426993c1426993c1426993c1426993c1426993c14266993c
/dev/sdg1: LABEL="mmdata" UUID="16683979255455566941" UUID_SUB="1905592300789522892" TYPE="zfs_member" PARTLABEL="zfs-9d379d5bs-9d379d5bd="9d379d5bd="2fs-9d379d5bd="2fs-9d379d5bd59d379d5bd59d379d5bd59d379d5bd59d379d5bd59d379d5bd59d379d5
/dev/sdi1: LABEL="mmdata" UUID="16683979255455566941" UUID_SUB="15862525770363300383" TYPE="zfs_member" PARTLABEL="zfs-3c99addc0ID="zfs-3c99addc0968-0038300383"
/dev/sdh1: LABEL="mmdata" UUID="16683979255455566941" UUID_SUB="15292769945216849639" TYPE="zfs_member" PARTLABEL="zfs-ee9e9e1c92769945216849639" TYPE="zfs_member" PARTLABEL="zfs-ee9e9e1c92769945216849639"
/dev/sdf1: LABEL="mmdata" UUID="16683979255455566941" UUID_SUB="5773484836304595337" TYPE="zfs_member" PARTLABEL="zfs-ee40cfd2140484836304595337" TYPE="zfs_member" PARTLABEL="zfs-ee40cf2140484836304595337"
/dev/sdc1: LABEL="mmdata" UUID="16683979255455566941" UUID_SUB="6348126275544519230" TYPE="zfs_member" PARTLABEL="zfs-0d28f0d23-26275544519230" TYPE="zfs_member" PARTLABEL="zfs-0d28f0d23-28f0d23-0d28f0d23-0d28f0d23-0d28f0d23-0d28f0d23-0d28f0d230d28f0d20d28f

Pentru piscina de mai sus, ceea ce s-a întâmplat, unul dintre dispozitivele de mai devreme a eșuat. Am conectat un disc de înlocuire la al doilea controler și am efectuat înlocuirea. A avut succes. Piscina a fost ok. Apoi, dispozitivul eșuat a fost eliminat din pool și înlocuit fizic cu discul de înlocuire (schimbarea controlerului). După repornire, l-am primit în stare degradată cu unul dintre dispozitivele raportate ca lipsă. Curățarea a fost declanșată de comanda zpool clear.

Deci, după cum arată de la blkid, există 8 discuri, toate partiționate și etichetate (cred) corect, dar unul dintre dispozitive nu este recunoscut ca parte a pool-ului. Ce să faci în astfel de situații? Este extrem de enervant. Reargintirea piscinei durează zile.

Puncte:3
drapel us

Dacă adăugați orice dispozitiv la piscină folosind /dev/sdX calea, este supusă modificării, deoarece nucleul Linux nu garantează nicio ordine pentru acele intrări de unitate.

În rezultatul dvs., aveți /dev/sdi ca membru al bazinului. Acest lucru se poate schimba în orice moment.

Ar trebui sa incerci zpool export mmdata pentru a pune matricea offline și apoi zpool import mmdata -d /dev/disk/by-id pentru a-l importa din nou folosind ID-urile persistente pentru unități.

agatek avatar
drapel us
Mulțumiri. O sa incerc asta. Deci, de ce etichetează/uuid toate discurile/partițiile și se bazează în continuare pe /dev/disk/by-id? Încerc să înțeleg logica.
drapel us
ZFS etichetează discurile/partițiile. Cu toate acestea, folosește identificatorii de dispozitiv care i-au fost furnizați în timpul „zpool create”.
agatek avatar
drapel us
Acesta este exact punctul meu de vedere, de ce le etichetează dacă se bazează pe maparea /dev/disk/by-id? De ce nu scanează uuid-urile și etichetele și le asamblează pe baza acestui lucru? În plus, ceea ce se spune în mesajul de eroare este în cel mai bun caz înșelător: unul sau mai multe dispozitive nu au putut fi utilizate deoarece **eticheta lipsește sau este invalidă**. Ei bine, eticheta nu lipsește nici nu este valabilă. Poate că acesta este un fel de eroare și ar trebui raportat?
agatek avatar
drapel us
Tero, exportul/importul pool-ului așa cum ați sugerat a funcționat bine. Vă mulțumesc din nou, dar înainte de a face acest lucru am exportat pool-ul și tocmai am emis zpool import (nu -d). Acesta a enumerat corect toate dispozitivele, astfel încât cel marcat mai sus ca defect era cu id-ul fizic corect și nu mai lipsea. Interesant, acest dispozitiv nu a fost introdus niciodată în pool de către id-ul (era /dev/sdX). Acum, s-ar fi putut presupune o scanare adecvată, dar ultimul dispozitiv (sdi) a rămas totuși sdi. Doar metoda dvs., care indică directorul, a permis să listeze toate dispozitivele din pool folosind ID-urile fizice. Ciudat.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.