În primul rând, ZFS are nevoie ca toate vdev-urile de nivel superior să fie funcționale pentru ca pool-ul să funcționeze. Dacă un vdev este offline, veți pierde accesul la toate datele din pool. Utilizați discuri individuale ca vdev, așa că dacă acel disc eșuează (spre deosebire de starea sa actuală de „multe erori de citire”), va trebui să recreați întregul pool de la zero.
Dacă sunteți pe Solaris sau dacă utilizați OpenZFS 0.8 sau o versiune ulterioară, ar trebui să puteți rula:
zpool elimina rezervorul ata-ST2000DM001-1ER164_Z4Z0xxxx
S-ar putea să nu funcționeze! Și dacă o face, ar putea duce la o degradare permanentă a performanței piscinei.
Îndepărtarea vdev necesită să existe suficient spațiu pe discurile rămase pentru datele deplasate. Se pare că probabil că aveți suficient spațiu în acest caz, dar menționez problema pentru a fi completă.
Pe OpenZFS, cel puțin, există o serie de restricții cu privire la momentul în care puteți elimina vdevs. Puteți elimina un vdev numai dacă grupul dvs. este format numai din vdev-uri cu un singur disc și/sau vdev-uri în oglindă. Pool-ul dvs. se califică, deoarece utilizați exclusiv vdev-uri cu un singur disc. Dar dacă ați avea vreun raidz, draid sau vdev-uri cu alocare specială pe OpenZFS, nu ați putea face acest lucru.
O ultimă avertizare este că eliminarea unui vdev implică o penalizare permanentă de performanță în OpenZFS. OpenZFS va înregistra un tabel intern pentru toate blocurile care au fost anterior pe discul eliminat. Atâta timp cât acele blocuri există în pool din acel moment, orice acces la ele va necesita o căutare indirectă prin tabelul de remapare. Acest lucru poate încetini semnificativ accesul aleatoriu. Nu știu suficient despre elementele interne Solaris ZFS pentru a putea spune dacă face ceva similar.
Și, desigur, ZFS va trebui să citească toate datele de pe discul defect pentru a-l elimina. Este absolut posibil ca acesta să întâmpine suficiente erori în timpul procesului, încât pur și simplu să eșueze discul. Dacă se întâmplă acest lucru, așa cum s-a discutat mai devreme, întregul pool va fi offline și va fi probabil irecuperabil.
Dacă aveți un slot disponibil pentru a adăuga un disc, ar fi mai bine să puneți un disc de rezervă și să îl utilizați zpool înlocuiți pentru a înlocui noul disc cu cel defect. Aceasta va implica aceeași încărcare de citire pentru a copia datele (și va suporta aceleași riscuri ca un singur disc să eșueze în timpul procesului), dar dacă reușește, nu va trebui să vă faceți griji cu privire la potențialele dezavantaje care vin odată cu eliminarea vdev.
În general, ZFS poate fi foarte fragil atunci când este utilizat așa cum sunteți – cu vdev-uri neredundante pe un singur disc. Există o glumă veche că zero în RAID0 este cât de mult trebuie să-ți pese de datele tale. Un pool ZFS de vdev-uri pe un singur disc este în esență același cu RAID0 din punct de vedere al securității datelor. O defecțiune a unui singur disc vă va face probabil să pierdeți toate datele. Chiar dacă vă puteți permite să înlocuiți datele, asigurați-vă că țineți cont de timpul necesar pentru a face acea înlocuire. Dacă vă puteți permite o penalizare de performanță compensată cu securitatea datelor, luați în considerare să puneți discurile viitoarelor pool-uri în raidz2 vdevs. Dacă vă puteți permite să tranzacționați spațiu pe disc utilizabil pentru securitatea datelor (și, eventual, o performanță crescută de citire), luați în considerare să puneți discurile viitoarelor pool-uri în vdev-uri oglindă.
