SLES Zypper HTTP 500:尋找故障儲存庫
將 Zypper 刷新錯誤追溯到 SUSE、RMT 或第三方端點,然後應用正確的伺服器端或快取修復程序,同時不停用必要的更新。
Data%當 SUSE Linux Enterprise Server 的精簡設定磁碟區報告「裝置上沒有剩餘空間」時,請先檢查精簡池Meta%。如果資料區已滿,而磁碟區組有可用區段,則應使用更大的容量擴展精簡池,而lvextend不僅僅是擴展其精簡邏輯磁碟區的虛擬大小。元資料區完全填滿的情況有所不同:可能需要離線修復才能恢復正常寫入。
以下步驟使用針對 Linux 系統編寫的 LVM2 指令,以及SUSE Linux Enterprise Server 15 SP7 儲存管理指南中所述的儲存模型。在其他 SLES 服務包或叢集安裝中,命令可用性和服務配置可能有所不同。在修改生產儲存之前,請務必進行應用程式一致性備份並限制大量寫入作業。
在擁有活動精簡池的主機上執行以下命令,並將 ` vgdata<volume-group name>` 替換為您的磁碟區組名稱:
sudo lvs -a -o lv_name,lv_size,segtype,data_percent,metadata_percent,pool_lv vgdata
thin-pool尋找包含下列值的行SegType:Data%`<value>` 表示已指派的資料區塊數;Meta%`<value>` 表示池的對應元資料。這些是不同的容量限制。如果 ` Data%<value>` 接近 100 但Meta%遠低於 100,則新增額外的資料區是最直接的解決方法。如果 ` Meta%<value>` 等於 100,請使用第 4 節中的復原措施。

舉個例子,假設vgdata/pool0一個 100 GiB 的儲存池,資料使用率為 98.12%,元資料使用率為 40.26%。即使掛載的精簡卷顯示空間充足,該儲存池也面臨立即被佔滿的風險。如同SUSE 的 Expert Partitioner 文件所述,df -h精簡磁碟區的虛擬大小可能超過儲存池的實體容量。
同時檢查最近的錯誤:
sudo journalctl -k --since "-30 min" | grep -Ei 'thin|no space|I/O error'
不要將空的 grep 結果解讀為沒有寫入失敗的證據。也要檢查應用程式的日誌,尤其是在儲存池滿時資料庫或虛擬機器正在寫入資料的情況下。
在更改資金池規模之前,請先了解交易量組是否能為擴容提供資金:
sudo vgs -o vg_name,vg_size,vg_free vgdata

在假設的範例中,200 GiB 的捲組有 40 GiB 的可用空間。因此,原則上可以擴展 20 GiB 的池,但需滿足分配限制並預留元資料增長的空間。建議保留一些卷組空間作為儲備,而不是將所有可用空間分配給池。
如果VG_FREE值為零,lvextend則無法建立物理容量。請將已正確識別並準備好的實體磁碟區新增至磁碟區組 (VG),根據需要擴展底層儲存及其 LVM PV,或在重試之前回收資料區塊。 SUSE 文件介紹了在調整磁碟區組大小時新增實體磁碟區的方法。切勿pvcreate對未經驗證的磁碟執行此操作:這可能會破壞現有的儲存元資料。
當Data%限制因素是元資料未耗盡且有足夠的 VG 擴充空間可用時,應擴展池本身:
sudo lvextend -L +20G vgdata/pool0

此+20G語法會將目前池大小增加 20 GiB,但不會將最終大小設為 20 GiB。在本例中,後端池從 100 GiB 成長到 120 GiB。在已分配資料未變更的情況下,已使用的 98.12 GiB 約佔擴充後池大小的 81.8%。如果在操作期間繼續寫入,實際百分比可能會有所不同。
請勿進行替換lvextend -L +20G vgdata/thin1。擴大精簡磁碟區的虛擬位址空間不一定會增加其池的實體資料容量。由於此命令擴展的是後端池而非檔案系統的虛擬區塊設備,因此通常不需要為此特定操作調整檔案系統大小。權威的LVM 精簡配置手冊詳細記錄了精簡池擴展機制及其限制。
如果檔案已從精簡檔案系統中刪除,且整個堆疊都支援丟棄操作,則考慮回收已丟棄的資料區塊:
sudo fstrim -v /srv/data
使用精簡磁碟區的實際掛載點,而不是精簡池設備。成功的 TRIM 操作可能會降低儲存池Data%容量,但單獨刪除檔案通常不會將資料區塊返回儲存池。精簡快照可以保留共用資料塊,而設定為忽略丟棄資料的儲存池不會從中受益。不要將 TRIM 操作視為物理容量的可靠緊急替代方案,尤其是在寫入作業開始失敗的情況下。僅在檢查舊快照的所有權、依賴關係和保留要求後才能刪除它們;快照刪除操作是不可逆的。
如果Meta%已達到 100%,請停止應用程式寫入並規劃受控停機。 LVM 警告稱,元資料耗盡會導致精簡池元資料和檔案系統不一致。僅僅增加池資料大小、重試寫入或強制啟動並不能解決此風險。
已記錄的復原順序是:離線停用受影響的儲存池,使用 `merge_metadata_callback` 修復其精簡元數據lvconvert --repair VG/ThinPool,使用 `merge_metadata_callback` 擴大元資料容量lvextend --poolmetadatasize,然後使用相應的離線工具檢查每個受影響的檔案系統。例如,元資料邏輯磁碟區小於 2 GiB 的儲存池可能需要進行下列審查:
sudo lvextend --poolmetadatasize 2G vgdata/pool0
請勿在已損壞的活動儲存池上盲目執行此命令。其大小僅為示例,並非普遍要求。請先確認目前元資料大小、可用擴充區、正確的停用設定、還原媒體和備份。lvconvert --repair必須具備停機時間和復原方面的專業知識才能進行規劃;LVM 手冊指出,即使執行此操作,資料仍可能無法復原。在驗證儲存池和檔案系統之前,請保留舊的元資料邏輯磁碟區 (LV)。從 LVM 配置備份vgcfgbackup不會備份精簡儲存池元資料。對於業務關鍵型數據,請在嘗試修復之前聯絡 SUSE 支援或您的儲存恢復團隊。
系統穩定後,在配置activation部分配置主動成長策略/etc/lvm/lvm.conf。此範例在磁碟使用率達到 70% 時開始擴展,並要求 20% 的成長;請根據寫入速率和可用 VG 容量調整這些值:
activation {
thin_pool_autoextend_threshold = 70
thin_pool_autoextend_percent = 20
}
確保將設定應用於正確的配置範圍,並對池進行監控:
sudo lvchange --monitor y vgdata/pool0

自動精簡池成長依賴 LVM 事件監控(dmeventd)和足夠的空閒擴展區。檢查 SLES 安裝提供的監控服務(例如,systemctl status lvm2-monitor該單元是否存在),並查看其日誌。如果寫入操作超過擴充限製或磁碟區組已滿,則閾值無法保證保護。請參閱LVM 手冊中的自動擴充指南和lvchange 監控選項。
讀取池利用率和VG剩餘容量:
sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vgdata/pool0
sudo vgs -o vg_name,vg_free vgdata
Data%資料池擴展後,容量應該會下降,Meta%必須保持在耗盡狀態以下,且資料池應處於活動狀態,沒有新的 I/O 錯誤。檢查檔案系統狀態和應用程式日誌,然後在釋放已暫停的工作負載之前,執行一個小型的、適合應用程式的讀寫測試。如果空間可用後錯誤仍然存在,請將受影響的工作負載保持離線狀態,直到評估其檔案系統和應用程式的完整性;增加容量無法恢復已失敗或遺失的寫入操作。
將 Zypper 刷新錯誤追溯到 SUSE、RMT 或第三方端點,然後應用正確的伺服器端或快取修復程序,同時不停用必要的更新。
透過檢查資料和元資料使用情況、安全地擴展池以及防止重複中斷來解決 SUSE LVM 精簡池空間錯誤。
確定 Btrfs 是否故意設定為唯讀、空間不足或在發生錯誤後保護數據,然後選擇適合該原因的恢復路徑。
準備鏡像通道,建立啟動金鑰,並在沒有直接網路存取的情況下引導 SLES 15 用戶端,同時保持管理員簽到所需的連線。
修復 YaST 透過 SSH 啟動 XIO 時出現的錯誤,驗證 X11 轉送和 xauth,並在不需要遠端視窗時切換到 ncurses 介面。
找到更新前的 Btrfs 快照,以唯讀方式測試它,並使用 Snapper 實現永久恢復,同時了解哪些資料保留在根回滾之外。
Send SLES system logs to a remote rsyslog collector over authenticated TLS, with certificate checks, outage buffering, and delivery tests.
使用 RAM、交換空間、核心和 Zypper 日誌來識別真實的記憶體壓力,保護軟體包狀態,並選擇更安全的 SLES 升級重試。
啟用 Debian 透過 SSH 進行的無人值守安全性更新,保留預設軟體套件來源,並透過 systemd 和 APT 日誌驗證計畫運作。
比較郵件投遞選項,在 Ubuntu 上配置 smartd,並驗證磁碟健康警告是否到達您的收件匣。