調整文件系統大小後令人驚訝的損壞和永無止境的 fsck
有問題的系統安裝了 Debian Lenny，執行 2.6.27.38 核心。系統有 16Gb 記憶體和 8x1Tb 驅動器在 3Ware RAID 卡後面執行。
儲存通過 LVM 管理，並且完全由 ext3 文件系統組成。
簡潔版本：
- 執行分配有 1.7Tb 儲存空間的 KVM 來賓。
- 來賓正在達到一個完整的磁碟。
- 所以我們決定調整它正在執行的磁碟的大小
我們非常熟悉 LVM 和 KVM，所以我們認為這將是一個輕鬆的操作：
- 停止 KVM 來賓。
- 擴展 LVM 分區的大小：“lvextend -L+500Gb …”
- 檢查文件系統：“e2fsck -f /dev/mapper/…”
- 調整文件系統大小：“resize2fs /dev/mapper/”
- 啟動客人。
來賓成功啟動，執行“df”顯示額外空間，但不久後系統決定以只讀方式重新掛載文件系統，沒有任何明確的錯誤指示。
由於偏執，我們關閉了客戶機並再次執行文件系統檢查，考慮到文件系統的新大小，我們預計這需要一段時間，但是它現在已經執行了超過 24 小時，並且沒有跡象表明需要多長時間.
使用 strace 我可以看到 fsck 正在“做事”，類似地執行“vmstat 1”我可以看到有很多塊輸入/輸出操作正在發生。
所以現在我的問題有三個：
- 有沒有人遇到過類似的情況？一般來說，我們過去做過這種調整大小，問題為零。
- 最可能的原因是什麼？（3Ware 卡顯示備份儲存的 RAID 陣列為 A-OK，主機系統尚未重新啟動，並且 dmesg 中沒有任何內容看起來很重要/不尋常）
- 忽略 btrfs + ext3（還不夠成熟，無法信任），我們將來是否應該在不同的文件系統中創建更大的分區以避免這種損壞（無論原因如何）或減少 fsck 時間？xfs 似乎是顯而易見的候選人？
似乎大於 1Tb 的捲與 virtio 有問題：
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/574665
http://kerneltrap.org/mailarchive/linux-kvm/2010/4/23/6261185/thread
http://sourceforge.net/tracker/index.php?func=detail&aid=2933400&group_id=180599&atid=893831
在這種情況下，它可能是 virtio 和 1TB 問題。
但是對我來說，我在交替訪問虛擬機外部的設備（包括關閉這台機器）和虛擬機內部時遇到了類似的問題。如果您通過直接訪問（例如在 kvm 配置中）訪問虛擬機內部的塊設備，這意味著沒有記憶體/緩衝區而外部有緩衝區，您可能會遇到以下問題：
- 在 vm 之外調整設備大小，記憶體/緩衝區會在 kvm 主機上填充。
- 啟動虛擬機，辨識（其他！）問題並關閉。
- fsck 設備。
如果一切都變得非常糟糕，您從記憶體中讀取日期，但是在之前執行的虛擬機中更改了該日期，該虛擬機在沒有緩衝區/記憶體的情況下訪問了設備！
我也做了很多 ext3 調整大小（從 2.6.18 開始），而且我一直在網上這樣做！AFAIK 這使用核心函式來調整大小，而離線調整大小使用使用者態程式碼。