===========系統詳情===========
作業系統：Solaris 10，更新 11
CPU_ARCH：SPARC (sparcv9)
硬體：Sun Fire V490（是的，寶貝老派）
KERNEL_REV：150400-40
程式：bpbkar32（Symantec 的 Netbackup） TL;DR：即使由於暫停，
也無法終止進程kill -9zpool 由於可能沒有兩條好的路徑。
問題：
我們的系統上有一堆（16）個不可殺死的進程；備份團隊通知我們，他們無法從 NB 主伺服器終止這些作業，也無法產生新的備份，因此我們跳上嘗試./bp.kill_all並收到：
bash-3.2#./bp.kill_all
尋找需要終止的 NetBackup 進程。
殺死 bpbkar 進程...以下進程仍處於活動狀態
root 20346 1 0 02:02:33 ？ 0:00 bpbkar32 -r 2678400 -ru root -dt 1047868 -to 0 -bpstart_time 1481767648 -clnt n
root 18689 1 0 12 月 9 日？ 0:00 bpbkar32 -r 8035200 -ru root -dt 0 -to 0 -bpstart_time 1481325879 -clnt nerp323
root 12618 1 0 12 月 7 日？ 0:00 bpbkar32 -r 2678400 -ru root -dt 357484 -to 0 -bpstart_time 1481077264 -clnt ne
root 29693 1 0 12 月 9 日？ 0:00 bpbkar32 -r 2678400 -ru root -dt 529430 -to 0 -bpstart_time 1481249210 -clnt ne
root 10168 1 0 12 月 9 日？ 0:00 bpbkar32 -r 2678400 -ru root -dt 530349 -to 0 -bpstart_time 1481250129 -clnt ne
root 1950 1 0 12 月 14 日？ 0:00 bpbkar32 -r 2678400 -ru root -dt 962300 -to 0 -bpstart_time 1481682080 -clnt ne
您希望此腳本嘗試殺死它們嗎？ [y,n] (y) y
終止剩餘進程...
正在等待進程終止...
正在等待進程終止...
正在等待進程終止...
正在等待進程終止...
正在等待進程終止...
還有進程仍在運作。
……為了可讀性而截斷輸出。
導致我們繼續嘗試以極端的偏見殺死這些進程，通過kill -9，也無濟於事。我看過如何殺死一個無法被殺死的任務（不可中斷？）和如果「kill -9」不起作用怎麼辦？以及搜尋“Solaris uninterruptable process”並獲得部分結果。重新啟動似乎是常見主題，也是我們的「頭撞桌子」解決方案。
話雖這麼說，我想：
- 驗證我的邏輯和根本原因的推理
- 看看是否有更好的方法來確定進程停止的位置/它嘗試執行的系統調用
- 解決 I/O如果可能的話，無需重新啟動，以及隨後無法終止的進程。
幾乎只是根本原因分析和某種「將來在備份運行時或如果沒有兩條工作路徑時不要進行切換工作」的緩解措施。
這是我得到的/我在想的：
1）進入 /proc/1950/ 目錄並查看狀態。沒有骰子可以理解該輸出，即使使用strings.噴出隨機字元。值得注意的是，“cwd”顯示了一個沒有任何內容的鏈接，並且嘗試通過以下方式解決它ls -alL /proc/1950/cwd將會掛起終端並創建擊鼓另一個不間斷的過程。
2）運行 apstack 1950將產生一些有用的信息，但沒有什麼是我從 a 看不到ps -eaf或我能理解的。不過，全為零看起來很糟糕，因為我們看不到地址或系統調用，就像我對工作 pid 所做的那樣。
bash-3.2#pstack 1950
1950：bpbkar32 -r 2678400 -ru root -dt 962300 -to 0 -bpstart_time 1481682080 0000000000000000 ????????? (0, 0, 0, 0, 0, 0)
3)truss如果嘗試在正在運行的進程上執行 a 將掛起，同樣會pfiles產生「pfiles：無法控制進程 1950」的錯誤。有趣，但令人期待。
4）運行 astrace只是告訴我“跟踪器已經存在”
5) 運行 apwdx列印 cwd 返回：
bash-3.2#pwdx 1950
1950: /桶
這很有趣，因為我們的 df 確實包含它......
df -h /bucket
已使用檔案系統大小 可用容量 安裝在
儲存桶上 1.9T 31K 1.9T 1% /bucket
……但是嘗試 cd 到 /bucket 並執行操作ls會產生相同的懸掛效果。
bash-3.2#zpool list
名稱大小分配免費上限健康 ALTROOT
儲存桶 1.94T 308K 1.94T 0% 暫停 -
rpool 136G 58.0G 78.0G 42% 線上 -
bash-3.2#umount /bucket
無法開啟「儲存桶」：池 I/O 目前已暫停
bash-3.2#zpool export bucket
無法卸載“/bucket”：設備繁忙
bash-3.2#zpool status -x
池：儲存桶
狀態：暫停
狀態：一個或多個裝置因 IO 故障而故障。
操作：確保受影響的裝置已連接，然後執行“zpoolclear”。
看：http://www.sun.com/msg/ZFS-8000-HC
掃描：沒有請求
設定：
名稱狀態讀寫 CKSUM
儲存桶暫停 0 0 0 遇到 I/O 故障 c3t50060E80102B1F5Ad78 故障 2 0 0 錯誤太多
所以...我感覺我們已經死在水中了，實際上，當「切換工作」發生時，沒有兩條通往 SAN 的活躍/健康路徑，所以我們最終從下面拉了地毯vdev 碰巧備份在死機時在那裡工作，但任何進程（例如我的ls）都會有相同的行為。
任何人都有任何最後的保存想法“運行這個未知的命令，這將幫助您重新啟動”？
答案1
正如 Jeff 所建議的，如果路徑已返回，zpool clear 應該有助於解決問題。因為聽起來好像不是，所以伺服器可能看不到 LUN。
Azpool clear -F -n bucket也會告訴您是否可以透過丟棄最後一組事務（-F 選項）來匯入池。
您提到了切換工作，因此您可能需要檢查完成了哪些工作，以及其中一項變更是否刪除了該路徑或任何路徑。您是否查看過“luxadm display /dev/rdsk/c<____>s2 輸出”？或嘗試使用 cfgadm 重新配置路徑？或沿著路徑發送一個forcelip事件？
a 的完整輸出zpool status bucket也可能有助於確定池的類型（mirror、cat、stripe，...）。根據這個問題，我假設不是鏡子。
我意識到這對我來說很容易說，因為我不參與其中，但不要驚慌，因為數據應該仍然全部存在於數組中，假設這不是問題。但您最終可能必須重新導入並回滾一些事務。
祝你好運！
答案2
您可以透過以下內容查看 SAN 狀態（假設是 FC SAN）：
for port in `fcinfo hba-port | grep Port | awk '{ print $4 }'`; do
> fcinfo remote-port -ls -p $port
> done
另外，請閱讀手冊頁mpathadm。您可以用來mpathadm show lu LUN顯示 LUN 的狀態。