Zfs

ZFS：編輯 ubuntu 上失敗池的 zpool 驅動器順序

  • April 7, 2020

我對到底發生了什麼以及如何在 Ubuntu 18.04 上進行最近擴展的 zfs 配置有點迷茫。

我有一台使用 ZFS 執行多年的儲存伺服器，其中有 2 個池，每個池包含 10 多個驅動器。一切都很好，直到……我們決定通過添加一個包含 10 個磁碟的新 vdev 來擴展一個池。插上後一切正常。這就是我添加設備所做的（我現在知道我應該在磁碟上按 id 完成 :-( ）：

~$ sudo modprobe zfs
~$ dmesg|grep ZFS
[   17.948569] ZFS: Loaded module v0.6.5.6-0ubuntu26, ZFS pool version 5000, ZFS filesystem version 5
~$ lsscsi
[0:0:0:0]    disk    HGST     HUS724020ALS640  A1C4  /dev/sda
[0:0:1:0]    disk    HGST     HUS724020ALS640  A1C4  /dev/sdb
[0:0:2:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdc
[0:0:3:0]    enclosu LSI      SAS2X28          0e12  -
[1:0:0:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdd
[1:0:1:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sde
[1:0:2:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdf
[1:0:3:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdg
[1:0:4:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdh
[1:0:5:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdi
[1:0:6:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdj
[1:0:7:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdk
[1:0:8:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdl
[1:0:9:0]    disk    HGST     HUS726040AL5210  A7J0  /dev/sdm
[1:0:10:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdn
[1:0:11:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdo
[1:0:12:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdp
[1:0:13:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdq
[1:0:14:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdr
[1:0:15:0]   disk    HGST     HUS726060AL5210  A519  /dev/sds
[1:0:16:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdt
[1:0:17:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdu
[1:0:18:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdv
[1:0:19:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdw
[1:0:20:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdx
[1:0:21:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdy
[1:0:22:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdz
[1:0:23:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdaa
[1:0:24:0]   enclosu LSI CORP SAS2X36          0717  -
[1:0:25:0]   disk    HGST     HUS726040AL5210  A7J0  /dev/sdab
[1:0:26:0]   enclosu LSI CORP SAS2X36          0717  -
[1:0:27:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdac      ===>from here below the new plugged disks
[1:0:28:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdad
[1:0:30:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdae
[1:0:31:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdaf
[1:0:32:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdag
[1:0:33:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdah
[1:0:34:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdai
[1:0:35:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdaj
[1:0:36:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdak
[1:0:37:0]   disk    HGST     HUH721010AL4200  A384  /dev/sdal

接下來，我將驅動器作為新的 raidz2 vdev 添加到現有的存檔池中。之後似乎執行順利：

~$ sudo zpool add -f archive raidz2 sdac sdad sdae sdaf sdag sdah sdai sdaj sdak sdal
~$ sudo zpool status
 pool: archive
state: ONLINE
 scan: scrub repaired 0 in 17h18m with 0 errors on Sun Dec  8 17:42:17 2019
config:
       NAME                        STATE     READ WRITE CKSUM
       archive                     ONLINE       0     0     0
         raidz2-0                  ONLINE       0     0     0
           scsi-35000cca24311c340  ONLINE       0     0     0
           scsi-35000cca24311ecbc  ONLINE       0     0     0
           scsi-35000cca24d019248  ONLINE       0     0     0
           scsi-35000cca24311e30c  ONLINE       0     0     0
           scsi-35000cca243113ab0  ONLINE       0     0     0
           scsi-35000cca24311c188  ONLINE       0     0     0
           scsi-35000cca24311e7c8  ONLINE       0     0     0
           scsi-35000cca24311e3f0  ONLINE       0     0     0
           scsi-35000cca24311e7bc  ONLINE       0     0     0
           scsi-35000cca24311e40c  ONLINE       0     0     0
           scsi-35000cca243118054  ONLINE       0     0     0
           scsi-35000cca243115cb8  ONLINE       0     0     0
         raidz2-1                  ONLINE       0     0     0
           sdac                    ONLINE       0     0     0
           sdad                    ONLINE       0     0     0
           sdae                    ONLINE       0     0     0
           sdaf                    ONLINE       0     0     0
           sdag                    ONLINE       0     0     0
           sdah                    ONLINE       0     0     0
           sdai                    ONLINE       0     0     0
           sdaj                    ONLINE       0     0     0
           sdak                    ONLINE       0     0     0
           sdal                    ONLINE       0     0     0

errors: No known data errors

 pool: scratch
state: ONLINE
 scan: scrub repaired 0 in 9h8m with 0 errors on Sun Dec  8 09:32:15 2019
config:
       NAME                        STATE     READ WRITE CKSUM
       scratch                     ONLINE       0     0     0
         raidz2-0                  ONLINE       0     0     0
           scsi-35000cca24311e2e8  ONLINE       0     0     0
           scsi-35000cca24311e858  ONLINE       0     0     0
           scsi-35000cca24311ea5c  ONLINE       0     0     0
           scsi-35000cca24311c344  ONLINE       0     0     0
           scsi-35000cca24311e7ec  ONLINE       0     0     0
           scsi-35000cca24311bcb8  ONLINE       0     0     0
           scsi-35000cca24311e8a8  ONLINE       0     0     0
           scsi-35000cca2440b4f98  ONLINE       0     0     0
           scsi-35000cca24311e8f0  ONLINE       0     0     0
           scsi-35000cca2440b4ff0  ONLINE       0     0     0
           scsi-35000cca243113e30  ONLINE       0     0     0
           scsi-35000cca24311e9b4  ONLINE       0     0     0
           scsi-35000cca243137e80  ONLINE       0     0     0

errors: No known data errors

但是，重新啟動很可能會打亂磁碟驅動器的順序（設備分配；不確定是否很難，但似乎很可能）。至少這是我在閱讀了許多文件和問題後所能理解的。目前的狀態如下。暫存池工作正常。存檔池不是：

~$ sudo zpool status -v
 pool: archive
state: UNAVAIL
status: One or more devices could not be used because the label is missing
or invalid.  There are insufficient replicas for the pool to continue
functioning.
action: Destroy and re-create the pool from
a backup source.
 see: http://zfsonlinux.org/msg/ZFS-8000-5E
 scan: none requested
config:

NAME                        STATE    READ WRITE CKSUM
archive                    UNAVAIL      0    0    0  insufficient replicas
 raidz2-0                  ONLINE      0    0    0
   scsi-35000cca24311c340  ONLINE      0    0    0
   scsi-35000cca24311ecbc  ONLINE      0    0    0
   scsi-35000cca24d019248  ONLINE      0    0    0
   scsi-35000cca24311e30c  ONLINE      0    0    0
   scsi-35000cca243113ab0  ONLINE      0    0    0
   scsi-35000cca24311c188  ONLINE      0    0    0
   scsi-35000cca24311e7c8  ONLINE      0    0    0
   scsi-35000cca24311e3f0  ONLINE      0    0    0
   scsi-35000cca24311e7bc  ONLINE      0    0    0
   scsi-35000cca24311e40c  ONLINE      0    0    0
   scsi-35000cca243118054  ONLINE      0    0    0
   scsi-35000cca243115cb8  ONLINE      0    0    0
 raidz2-1                  UNAVAIL      0    0    0  insufficient replicas
   sdac                    FAULTED      0    0    0  corrupted data
   sdad                    FAULTED      0    0    0  corrupted data
   sdae                    FAULTED      0    0    0  corrupted data
   sdaf                    FAULTED      0    0    0  corrupted data
   sdag                    FAULTED      0    0    0  corrupted data
   sdah                    FAULTED      0    0    0  corrupted data
   sdai                    FAULTED      0    0    0  corrupted data
   sdaj                    FAULTED      0    0    0  corrupted data
   sdak                    FAULTED      0    0    0  corrupted data
   sdal                    FAULTED      0    0    0  corrupted data

 pool: scratch
state: ONLINE
 scan: scrub repaired 0 in 16h36m with 0 errors on Sun Feb  9 17:00:25 2020
config:

NAME                        STATE    READ WRITE CKSUM
scratch                    ONLINE      0    0    0
 raidz2-0                  ONLINE      0    0    0
   scsi-35000cca24311e2e8  ONLINE      0    0    0
   scsi-35000cca24311e858  ONLINE      0    0    0
   scsi-35000cca24311ea5c  ONLINE      0    0    0
   scsi-35000cca24311c344  ONLINE      0    0    0
   scsi-35000cca24311e7ec  ONLINE      0    0    0
   scsi-35000cca24311bcb8  ONLINE      0    0    0
   scsi-35000cca24311e8a8  ONLINE      0    0    0
   scsi-35000cca2440b4f98  ONLINE      0    0    0
   scsi-35000cca24311e8f0  ONLINE      0    0    0
   scsi-35000cca2440b4ff0  ONLINE      0    0    0
   scsi-35000cca243113e30  ONLINE      0    0    0
   scsi-35000cca24311e9b4  ONLINE      0    0    0
   scsi-35000cca243137e80  ONLINE      0    0    0

errors: No known data errors

我嘗試了 zpool 導出存檔（也使用 -f），但它抱怨缺少設備。

~$ sudo zpool export -f archive
cannot export 'archive': one or more devices is currently unavailable

顯然導入也失敗了……

還有什麼可以嘗試的？我簡直不敢相信“簡單”的磁碟重新排序會弄亂存檔池上的所有數據。

編輯 3 月 23 日

問題確實是驅動順序發生了變化。

如果我在池上執行 zdb，它會顯示儲存在標籤中的所有資訊，並且大型新磁碟被錯誤的 /dev/sdxx 設備引用。我通過列出驅動器的 guid 以及實際分配的 /dev/sdxx 設備及其 ID 來確定這一點。它給了我下面的映射：

老開發者和目前開發者的映射表

但是如何解決這個問題。理論上，將更正的 zdb 數據重寫到磁碟應該可以解決這個問題。

好吧，我又開心了。我能夠解決/修復重新洗牌的磁碟問題！發布此答案作為同一條船上某人的參考。

請注意，這是高風險的工作，僅適用於膽小的人！遵循這些說明，風險自負，並為系統的完全故障做好準備！

簡而言之，我是如何針對我們的情況進行修復的；

  1. 檢索故障池的 ORIGINAL 驅動器路徑佈局 ( zdb)

  2. 將原始和目前磁碟/分區ID 映射到路徑映射，即fdisk列出所有分區和設備。

3a) mv/dev/sdxx 設備和分區到原始範圍之外的臨時範圍（在 1 處）

3b)mv從 TEMPORARY 範圍到 ORIGINAL 佈局的設備

  1. 池被辨識（直到重新啟動！），您可以移動/複製您的數據。

5）在拯救數據後，我從池中刪除了所有磁碟並銷毀了該池。僅在重新啟動後重建池（注意移動的設備名稱）。

我將在下面每點發布一些細節（全部使用 sudo 或 as su）；

1)zdb 這將返回每個池的 zdb 驅動器和分區標籤的長轉儲。為受影響的故障池中的孩子找到這對引導和路徑。在我的例子中：

guid: 16862548186473937209
path: '/dev/sdac1'

  1. 創建一個 CURRENT 和 ORIGINAL ID 到路徑的映射列表。這允許將目前設備/分區路徑重命名為原始佈局（非其他原始設備目前由故障池中不存在的另一個新驅動器使用！）請參閱上面我的問題更新中的映射！關聯

  2. 移動/重命名設備；範例首先 CURRENT 名稱到高 TEMPORARY 範圍，然後從 TEMPORARY 範圍到 ORIGINAL 佈局。我製作了一個 bash 腳本來快速處理它，並允許雙重檢查和半自動生成“腳本”。例子;

#!/bin/bash

# move CURRENT TO TEMPORARY
mv /dev/sdac /dev/sdap
mv /dev/sdad /dev/sdaq
mv /dev/sdae /dev/sdar
mv /dev/sdaf /dev/sdas
mv /dev/sdag /dev/sdat
mv /dev/sdah /dev/sdau
mv /dev/sdai /dev/sdav
mv /dev/sdaj /dev/sdaw
mv /dev/sdak /dev/sdax
mv /dev/sdal /dev/sday
mv /dev/sdac1 /dev/sdap1
mv /dev/sdad1 /dev/sdaq1
mv /dev/sdae1 /dev/sdar1
mv /dev/sdaf1 /dev/sdas1
mv /dev/sdag1 /dev/sdat1
mv /dev/sdah1 /dev/sdau1
mv /dev/sdai1 /dev/sdav1
mv /dev/sdaj1 /dev/sdaw1
mv /dev/sdak1 /dev/sdax1
mv /dev/sdal1 /dev/sday1
mv /dev/sdac9 /dev/sdap9
mv /dev/sdad9 /dev/sdaq9
mv /dev/sdae9 /dev/sdar9
mv /dev/sdaf9 /dev/sdas9
mv /dev/sdag9 /dev/sdat9
mv /dev/sdah9 /dev/sdau9
mv /dev/sdai9 /dev/sdav9
mv /dev/sdaj9 /dev/sdaw9
mv /dev/sdak9 /dev/sdax9
mv /dev/sdal9 /dev/sday9

#final move TEMPORARY to ORIGINAL = new CURRENT
mv /dev/sdap /dev/sdai
mv /dev/sdaq /dev/sdaj
mv /dev/sdar /dev/sdak
mv /dev/sdas /dev/sdal
mv /dev/sdat /dev/sdah
mv /dev/sdau /dev/sdag
mv /dev/sdav /dev/sdaf
mv /dev/sdaw /dev/sdae
mv /dev/sdax /dev/sdad
mv /dev/sday /dev/sdac
mv /dev/sdap1 /dev/sdai1
mv /dev/sdaq1 /dev/sdaj1
mv /dev/sdar1 /dev/sdak1
mv /dev/sdas1 /dev/sdal1
mv /dev/sdat1 /dev/sdah1
mv /dev/sdau1 /dev/sdag1
mv /dev/sdav1 /dev/sdaf1
mv /dev/sdaw1 /dev/sdae1
mv /dev/sdax1 /dev/sdad1
mv /dev/sday1 /dev/sdac1
mv /dev/sdap9 /dev/sdai9
mv /dev/sdaq9 /dev/sdaj9
mv /dev/sdar9 /dev/sdak9
mv /dev/sdas9 /dev/sdal9
mv /dev/sdat9 /dev/sdah9
mv /dev/sdau9 /dev/sdag9
mv /dev/sdav9 /dev/sdaf9
mv /dev/sdaw9 /dev/sdae9
mv /dev/sdax9 /dev/sdad9
mv /dev/sday9 /dev/sdac9

4 和 5) 搶救數據後繼續重建。有很多工具和優秀的教程展示了導出池以及銷毀和重建它的最佳實踐（確保使用標識符而不是路徑的磁碟來重建它 :-D ）。

引用自：https://serverfault.com/questions/1007160

相關問答

Zfs

使用“autoreplace=on”時 ZFS 自動備件大小感知嗎？

  • July 15, 2021
檢視問答
Storage

ZFS 池不斷 DEGRADED 或 FAULTED

  • June 2, 2021
檢視問答
Freebsd

我能夠用不同大小的硬碟創建 raidz。我在哪裡失踪？

  • February 9, 2021
檢視問答
Zfs

殘廢 zpool 的創造性解決方案（也就是幫助垂死的突襲生存 1-2 週）

  • January 27, 2021
檢視問答
Solaris

ZFS：為未來的驅動器添加做準備

  • December 4, 2020
檢視問答
Zfs

ZFS - 在重新同步/重建期間刪除 ZFS 提供的文件是否安全？

  • October 19, 2020
檢視問答