⑴ 綁定存儲target至客戶端失敗
客戶端不支持。綁定存儲target是一種為客戶端提供存儲的方式。失敗是因為當前客戶端不支持創建存儲池，只需要對客戶端進行升級即可。
⑵ 硬碟變成存儲池怎麼取消
在存儲池頁面，單擊目標存儲池右側的修改或刪除，執行相關操作。
存儲池是 Data Protection Manager (DPM) 伺服器在其中存儲副本、卷影副本和傳輸日誌的一組磁碟。
必須向存儲池添加至少一個磁碟才可開始保護數據。添加到存儲池的磁碟應是空的。為了准備數據保護，DPM重新格式化磁碟並擦除磁碟上的任何數據。DPM伺服器必須安裝至少兩個磁碟，一個專用於啟動、系統和DPM安裝文件，而另一個專用於存儲池。
在DPM環境中，」磁碟「是指在Windows磁碟管理工具中顯示為磁碟的任何磁碟設備。DPM不會將含有啟動文件、系統文件或DPM安裝的任何組件的任何磁碟添加到存儲池。
在刪除存儲池前，要確保：已刪除存儲池中的全部卷，可發出MOVE DATA命令，確保已保存了希望保留的所有可讀數據。 要移動希望保留的全部數據，可能需要發出幾次MOVE DATA命令。
在開始刪除屬於存儲池的全部卷之前，需將存儲池的存取方式更改為不可用，以便不能從存儲池中的卷寫入或讀取任何文件。有關刪除卷的信息，請參閱刪除有數據的存儲池卷。
不將存儲池標識為存儲器層次結構內的下一個存儲池，要確定該存儲池是否作為存儲器層次結構中的下一個存儲池被引用，可查 詢監視存儲池中的可用空間中所述的存儲池信息。
通過執行下列步驟之一，更新任何存儲池的定義已將該存儲池從存儲器層次結構中除去，有關定義和更新存儲池的信息，請參閱定義或更新主存儲池。
1、將另一個存儲池命名為存儲器層次結構中的下一個存儲池。
2、將 NEXTSTGPOOL 參數值用 ""（雙引號）輸入，從存儲器層次結構定義中除去此存儲池。
3、要刪除的存儲池不能被指定為任何域的活動策略集內管理類中任何副本組的目標。要刪除的存儲池也不能為空間管理文件的目標（在任何域的活動策略集內的管理類中指定）。
如果該存儲池為目標，且要加以刪除，則操作會因為沒有保存數據的存儲空間而失敗。
⑶ ZFS問題zpool status pool
第 9 章 ZFS 疑難解答和數據恢復本章介紹如何確定 ZFS 故障模式以及如何從相應故障模式中恢復。還提供了有關預防故障的信息。
本章包含以下各節：
ZFS 故障模式
檢查 ZFS 數據完整性
確定 ZFS 中的問題
修復損壞的 ZFS 配置
修復缺少的設備
修復損壞的設備
修復損壞的數據
修復無法引導的系統
作為組合的文件系統和卷管理器，ZFS 可以呈現許多不同的故障模式。本章首先概述各種故障模式，然後討論如何在正運行的系統上確定各種故障。本章最後討論如何修復問題。ZFS 可能會遇到以下三種基本類型的錯誤：
缺少設備
設備已損壞
數據已損壞
請注意，單個池可能會遇到所有這三種錯誤，因此完整的修復過程依次查找和更正各個錯誤。
ZFS 存儲池中缺少設備如果某設備已從系統中徹底刪除，則 ZFS 會檢測到該設備無法打開，並將其置於 FAULTED 狀態。這可能會導致整個池變得不可用，但也可能不會，具體取決於池的數據復制級別。如果鏡像設備或 RAID-Z 設備中的一個磁碟被刪除，仍可以繼續訪問池。如果刪除了鏡像的所有組件，刪除了 RAID-Z 設備中的多個設備，或刪除了單磁碟頂層設備，則池將變成 FAULTED。在重新連接設備之前，無法訪問任何數據。
ZFS 存儲池中的設備已損壞術語「損壞」包含各種可能出現的錯誤。以下是錯誤示例：
由於損壞的磁碟或控制器而導致的瞬態 I/O 錯誤
磁碟上的數據因宇宙射線而損壞
導致數據傳輸至錯誤目標或從錯誤源位置傳輸的驅動程序錯誤
只是另一個用戶意外地覆寫了物理設備的某些部分
在一些情況下，這些錯誤是瞬態的，如控制器出現問題時的隨機 I/O 錯誤。在另外一些情況下，損壞是永久性的，如磁碟損壞。但是，若損壞是永久性的，則並不一定表明該錯誤很可能會再次出現。例如，如果管理員意外覆寫了磁碟的一部分，且未出現某種硬碟故障，則不需要替換該設備。准確確定設備出現的錯誤不是一項輕松的任務，在稍後的一節中將對此進行更詳細的介紹。
ZFS 數據已損壞一個或多個設備錯誤（指示缺少設備或設備已損壞）影響頂層虛擬設備時，將出現數據損壞。例如，鏡像的一半可能會遇到數千個絕不會導致數據損壞的設備錯誤。如果在鏡像另一面的完全相同位置中遇到錯誤，則會導致數據損壞。
數據損壞始終是永久性的，因此在修復期間需要特別注意。即使修復或替換基礎設備，也將永遠丟失原始數據。這種情況通常要求從備份恢復數據。在遇到數據錯誤時會記錄錯誤，並可以通過常規磁碟清理對錯誤進行控制，如下一節所述。刪除損壞的塊後，下一遍清理會識別出數據損壞已不再存在，並從系統中刪除該錯誤的任何記錄。
檢查 ZFS 數據完整性對於 ZFS，不存在與fsck等效的實用程序。此實用程序一直以來用於兩個目的：數據修復和數據驗證。
數據修復對於傳統的文件系統，寫入數據的方法本身容易出現導致數據不一致的意外故障。由於傳統的文件系統不是事務性的，因此可能會出現未引用的塊、錯誤的鏈接計數或其他不一致的數據結構。添加日誌記錄確實解決了其中的一些問題，但是在無法回滾日誌時可能會帶來其他問題。對於 ZFS，這些問題都不存在。磁碟上存在不一致數據的唯一原因是出現硬碟故障（在這種情況下，應該已復制池）或 ZFS 軟體中存在錯誤。
假定fsck實用程序設計用於修復特定於單獨文件系統的已知異常，為沒有已知反常的文件系統編寫這樣的實用程序就是不可能的。將來的經驗可能證明某些數據損壞問題是足夠常見、足夠簡單的，以致於可以開發修復實用程序，但是使用復制的池始終可以避免這些問題。
如果未復制池，則數據損壞造成無法訪問某些或所有數據的可能性將始終存在。
數據驗證除了數據修復外，fsck實用程序還驗證磁碟上的數據是否沒有問題。過去，此任務是通過取消掛載文件系統再運行fsck實用程序執行的，在該過程中可能會使系統進入單用戶模式。此情況導致的停機時間的長短與所檢查文件系統的大小成比例。ZFS 提供了一種對所有數據執行常規檢查的機制，而不是要求顯式實用程序執行必要的檢查。此功能稱為清理，在內存和其他系統中經常將它用作一種在錯誤導致硬碟或軟體故障之前檢測和防止錯誤的方法。
控制 ZFS 數據清理每當 ZFS 遇到錯誤時（不管是在清理中還是按需訪問文件時），都會在內部記錄該錯誤，以便您可以快速查看池中所有已知錯誤的概覽信息。
顯式 ZFS 數據清理檢查數據完整性的最簡單的方法是，對池中所有數據啟動顯式清理操作。此操作對池中的所有數據遍歷一次，並驗證是否可以讀取所有塊。盡管任何 I/O 的優先順序一直低於常規操作的優先順序，但是清理以設備所允許的最快速度進行
⑷ 求助WIN10如何恢復配置錯誤的存儲池硬碟
創建存儲空間的具體步驟如下：
1、右擊Windows 10開始菜單，選擇「控制面板」命令。以「小圖標」方式查看控制面板選項，在「所有控制面板項」列表中選擇「存儲空間」選項。
2、進入「存儲空間」創建窗口。
3、在「存儲空間」創建窗口中，點擊「創建新的池和存儲空間」。
小提示：如果沒有看到任務鏈接，請單擊「更改設置」進行設置。
4、選擇要用來創建存儲池的驅動器，然後點擊「創建池」。指定驅動器名稱和驅動器號，然後選擇一種布局，指定存儲空間大小，然後單擊「創建存儲空間」。
該方法是通過將內部硬碟與外界存儲設備相互連接，形成一個存儲空間，一旦硬碟數據遭到破壞或是丟失就可以自動備份到其他空間上。
⑸ 求助WIN10如何恢復配置錯誤的存儲池硬碟
因為重裝系統，之前做存儲池的硬碟的磁碟信息丟失了，故而新系統無法重新識別3TB機械硬碟的內容，而且僅用一塊磁碟做存儲池的情況我在網上也沒有找到相似的例子。
⑹ 創建池錯誤057
它的意思是處理ZFS存儲池創建錯誤。
磁碟或其中一分片包含當前掛載的文件系統。要更正此錯誤，請使用 umount 命令。
磁碟包含 /etc/vfstab 文件中列出的文件系統，但當前未掛載該文件系統。要更正此錯誤，請刪除或注釋掉 /etc/vfstab 文件中的相應行。正在將磁碟用作系統的專用轉儲設備。
要更正此錯誤，請使用 mpadm 命令。磁碟或文件是活動ZFS存儲池的一部分。要更正此錯誤，請使用 zpool destroy 命令來銷毀其他池（如果不再需要）。或者，使用 zpool detach 命令將磁碟與其他池分離。您只能將磁碟從鏡像存儲池中分離。
⑺ ceph分布式存儲-常見 PG 故障處理
創建一個新集群後，PG 的狀態一直處於 active ， active + remapped 或 active + degraded 狀態， 而無法達到 active + clean 狀態 ，那很可能是你的配置有問題。
你可能需要檢查下集群中有關 Pool 、 PG 和 CRUSH 的配置項，做以適當的調整。
一般來說，你的集群中需要多於 1 個 OSD，並且存儲池的 size 要大於 1 副本。
有時候，我們需要搭建一個單節點的 Ceph 實驗環境。此時，在開始創建 monitor 和 OSD 之前，你需要把 Ceph 配置文件中的 osd crush chooseleaf type 選項從默認值 1 （表示 host 或 node ）修改為 0 （表示 osd ）。這樣做是告訴 Ceph 允許把數據的不同副本分布到同一 host 的 OSDs 上。
如果你已經啟動了 2 個 OSD，它們都處於 up 和 in 的狀態，但 PG 仍未達到 active + clean 狀態，那可能是給 osd pool default size 設置了一個大於 2 的值。
如果你想要在 active + degraded 狀態（ 2 副本）操作你的集群，可以設置 osd pool default min size 為 2 ，這樣你就可以對處於 active + degraded 的對象寫入數據。然後你還可以把 osd pool default size 的值改為 2 ，這樣集群就可以達到 active + clean 狀態了。
另外，修改參數 osd pool default size/min_size 後，只會對後面新建的 pool 起作用。如果想修改已存在的 pool 的 size/min_size ，可用下面的命令：
注意： 你可以在運行時修改參數值。如果是在 Ceph 配置文件中進行的修改，你可能需要重啟集群。
如果你設置了 osd pool default size 的值為 1 ，那你就僅有對象的單份拷貝。OSD 依賴於其他 OSD 告訴自己應該保存哪些對象。如果第一個 OSD 持有對象的拷貝，並且沒有第二份拷貝，那麼也就沒有第二個 OSD 去告訴第一個 OSD 它應該保管那份拷貝。對於每一個映射到第一個 OSD 上的 PG （參考 ceph pg mp 的輸出），你可以強制第一個 OSD 關注它應該保存的 PGs ：
PG 達不到 clean 狀態的另一個可能的原因就是集群的 CRUSH Map 有錯誤，導致 PG 不能映射到正確的地方。
有失敗發生後，PG 會進入「degraded」（降級）或「peering」（連接建立中）狀態，這種情況時有發生。通常這些狀態意味著正常的失敗恢復正在進行。然而，如果一個 PG 長時間處於這些狀態中的某個，就意味著有更大的問題。因此 monitor 在 PG 卡 （ stuck ） 在非最優狀態時會告警。我們具體檢查：
你可以用下列命令顯式地列出卡住的 PGs：
卡在 stale 狀態的 PG 通過重啟 ceph-osd 進程通常可以修復；卡在 inactive 狀態的 PG 通常是互聯問題（參見 PG 掛了 —— 互聯失敗 ）；卡在 unclean 狀態的 PG 通常是由於某些原因阻止了恢復的完成，像未找到的對象（參見 未找到的對象 ）。
在某些情況下， ceph-osd 互聯 進程會遇到問題，阻值 PG 達到活躍、可用的狀態。例如， ceph health 也許顯示：
可以查詢到 PG 為何被標記為 down ：
recovery_state 段告訴我們互聯過程因 ceph-osd 進程掛了而被阻塞，本例是 osd.1 掛了，啟動這個進程應該就可以恢復。
或者，如果 osd.1 發生了災難性的失敗（如硬碟損壞），我們可以告訴集群它丟失（ lost ）了，讓集群盡力完成副本拷貝。
重要： 集群不能保證其它數據副本是一致且最新的，就會很危險！
讓 Ceph 無論如何都繼續：
恢復將繼續進行。
某幾種失敗相組合，可能導致 Ceph 抱怨有找不到（ unfound ）的對象：
這意味著存儲集群知道一些對象（或者存在對象的較新副本）存在，卻沒有找到它們的副本。下例展示了這種情況是如何發生的，一個 PG 的數據存儲在 ceph-osd 1 和 2 上：
這時， 1 知道這些對象存在，但是活著的 ceph-osd 都沒有這些副本。這種情況下，讀寫這些對象的 IO 就會被阻塞，集群只能指望 down 掉的節點盡早恢復。這樣處理是假設比直接給用戶返回一個 IO 錯誤要好一些。
首先，你應該確認哪些對象找不到了：
如果在一次查詢里列出的對象太多， more 這個欄位將為 true ，你就可以查詢更多。
其次，你可以找出哪些 OSD 上探測到、或可能包含數據：
本例中，集群知道 osd.1 可能有數據，但它掛了（ down ）。所有可能的狀態有：
有時候集群要花一些時間來查詢可能的位置。
還有一種可能性，對象存在於其它位置卻未被列出。例如，集群里的一個 ceph-osd 停止且被剔出集群，然後集群完全恢復了；後來一系列的失敗導致了未找到的對象，它也不會覺得早已死亡的 ceph-osd 上仍可能包含這些對象。（這種情況幾乎不太可能發生）。
如果所有可能的位置都查詢過了但仍有對象丟失，那就得放棄丟失的對象了。這仍可能是罕見的失敗組合導致的，集群在寫操作恢復後，未能得知寫入是否已執行。以下命令把未找到的（ unfound ）對象標記為丟失（ lost ）。
上述最後一個參數告訴集群應如何處理丟失的對象。
擁有 PG 拷貝的 OSD 可能會全部失敗，這種情況下，那一部分的對象存儲不可用， monitor 也就不會收到那些 PG 的狀態更新了。為檢測這種情況，monitor 會把任何主 OSD 失敗的 PG 標記為 stale （不新鮮），例如：
可以找出哪些 PG 是 stale 狀態，和存儲這些歸置組的最新 OSD ，命令如下：
如果想使 PG 2.5 重新上線，例如，上面的輸出告訴我們它最後由 osd.0 和 osd.2 管理，重啟這些 ceph-osd 將恢復之（可以假定還有其它的很多 PG 也會進行恢復 ）。
如果你的集群有很多節點，但只有其中幾個接收數據， 檢查 下存儲池裡的 PG 數量。因為 PG 是映射到多個 OSD 的，較少的 PG 將不能均衡地分布於整個集群。試著創建個新存儲池，設置 PG 數量是 OSD 數量的若干倍。更詳細的信息可以參考 Ceph 官方文檔 —— Placement Groups 。
如果你的集群已啟動，但一些 OSD 沒起來，導致不能寫入數據，確認下運行的 OSD 數量滿足 PG 要求的最低 OSD 數。如果不能滿足， Ceph 就不會允許你寫入數據，因為 Ceph 不能保證復制能如願進行。這個最低 OSD 個數是由參數 osd pool default min size 限定的。
如果收到 active + clean + inconsistent 這樣的狀態，很可能是由於在對 PG 做擦洗（ scrubbing ）時發生了錯誤。如果是由於磁碟錯誤導致的不一致，請檢查磁碟，如果磁碟有損壞，可能需要將這個磁碟對應的 OSD 踢出集群，然後進行更換。生產環境中遇到過不一致的問題，就是由於磁碟壞道導致的。
當集群中出現 PG 不一致的問題時，執行 ceph -s 命令會出現下面的信息：
1、查找處於 inconsistent 狀態的問題 PG ：
這個有問題的 PG 分布在 osd.1 、 osd.2 和 osd.0 上，其中 osd.1 是主 OSD。
2、去主 OSD（ osd.1 ）的日誌中查找不一致的具體對象 。
從日誌中可以知道，是 rbd_data.1349f035c101d9.0000000000000001 這個對象的屬性 _ 丟失了，所以在 scrub 的過程中產生了 error 。
3、執行 ceph pg repair 命令修復問題 PG 。
4、檢查 Ceph 集群是否恢復到 HEALTH_OK 狀態。
osd.1 的日誌里也提示修復成功：
如果經過前面的步驟，Ceph 仍沒有達到 HEALTH_OK 狀態，可以嘗試用下面這種方式進行修復。
1、停掉不一致的 object 所屬的 osd 。
2、刷新該 osd 的日誌。
3、將不一致的 object 移除。
4、重新啟動該 osd 。
5、重新執行修復命令。
6、檢查 Ceph 集群是否恢復到 HEALTH_OK 狀態。
有時候，我們在 ceph -s 的輸出中可以看到如下的告警信息：
這是因為集群 OSD 數量較少，測試過程中建立了多個存儲池，每個存儲池都要建立一些 PGs 。而目前 Ceph 配置的默認值是每 OSD 上最多有 300 個 PGs 。在測試環境中，為了快速解決這個問題，可以調大集群的關於此選項的告警閥值。方法如下：
在 monitor 節點的 ceph.conf 配置文件中添加:
然後重啟 monitor 進程。
或者直接用 tell 命令在運行時更改參數的值而不用重啟服務：
而另一種情況， too few PGs per OSD （16 < min 20） 這樣的告警信息則往往出現在集群剛剛建立起來，除了默認的 rbd 存儲池，還沒建立自己的存儲池，再加上 OSD 個數較多，就會出現這個提示信息。這通常不是什麼問題，也無需修改配置項，在建立了自己的存儲池後，這個告警信息就會消失。
⑻ JDBC調用存儲過程,存儲過程中事務回滾,報錯
ConnCloseThread中關閉連接的時候，不是立刻返回的。Connection.close()會觸發Connection.commit()，而因為調用的存儲過程中，存儲過程起了自己的事務，connection.commit()必須等到存儲過程結束才能完成(這個是microsoft論壇上看到的)。如果所有connection.close()都等到tx commit或rollback完成才執行的話，這個問題就不會出現了
從測試結果來看，凡是close connection耗時比execute statement短的，連接（物理連接）都會報出該問題。分析原因：通過weblogic datasource獲取的connection並不是物理connection，而是由weblogic wrapped的connection。這些conection在被close後，並不會關閉物理連接，而只是將物理連接還池。我們對connection的所有操作，最終都會被delegated到底層物理連接上，即commit()，rollback()最終都是在物理連接上執行。如果上面的connection.close()，底層物理連接沒有等到存儲過程事務結束就返回的話，那麼物理連接上應該還帶有此次操作的事務，而weblogic這邊不會關系物理連接的情況，直接將連接放入connection pool供其它客戶端使用。這時候如果設定了test on reserve的話，下次客戶端從data source獲取連接時，weblogic會檢查這個物理連接，作一個select操作的，這個有問題的連接就會暴露出來，也就是上面的異常。這個問題如果使用driver manager來獲取連接的話（如果每次都關閉的話），則不會出現，因為使用的物理連接每次都是不同的。還好，weblogic會幫忙重新創建有問題的連接。原因大概了解了，但這是誰的問題呢？ 為什麼connection.close()不等存儲過程的事務結束？
結論：一般而言，我們不建議通過JDBC調用存儲過程的時候，在存儲過程中定義事務，應該將tx的管理工作交給jdbc去做。 non-xa如此，xa亦如此，畢竟事務嵌套了以後，管理起來是個問題，完整性更是個問題。
⑼ ds a81016s 添加存儲池 命令執行失敗
ds a81016s 添加存儲池 命令執行失敗如下：
1.CloudStack創建主存儲失敗（SR已經被使用），刪除SR後成功 由於最近工程需要用到這個東西，於是乎，在網上找了些資料解決了CloudStack創建主存儲失敗（SR已經被使用），刪除SR後成功，的問題，這里就記錄下： 創建.
2.SAN方案必須提供自管理能力，尤其在錯誤恢復、數據可用性以及性能管理方面，糾錯和失敗恢復也是企業存儲的關鍵問題，RAID使存儲管理員從由於硬碟失敗而引起的數據丟失的擔心中解脫出來。自動的負載平衡減輕了對存儲。
⑽ windows server 2016 儲存池顯示不存在
用過2012R2和2016，儲存池都是全部硬碟插上後自動識別的。
2012R2的可以被2016識別，但是把儲存池升級到2016版的話就不能再被2012識別了。