LVM 的危險和注意事項
我最近開始在某些伺服器上使用 LVM 來處理大於 1 TB 的硬碟驅動器。它們非常有用、可擴展且非常易於安裝。但是，我找不到任何有關 LVM 的危險和警告的數據。
使用 LVM 的缺點是什麼？
概括
使用 LVM 的風險：
- 容易使用 SSD 或 VM 管理程序寫入記憶體問題
- 由於更複雜的磁碟結構，更難恢復數據
- 更難正確調整文件系統的大小
- 快照很難使用，速度慢而且有問題
- 鑑於這些問題，需要一些技能才能正確配置
前兩個 LVM 問題結合在一起：如果寫入記憶體無法正常工作並且您出現斷電（例如 PSU 或 UPS 故障），您可能必須從備份中恢復，這意味著很長的停機時間。使用 LVM 的一個關鍵原因是正常執行時間更長（添加磁碟、調整文件系統大小等時），但重要的是要正確設置寫入記憶體以避免 LVM 實際上減少正常執行時間。
– 2019 年 12 月更新：對 btrfs 和 ZFS 作為 LVM 快照的替代品的小更新
降低風險
如果您滿足以下條件，LVM 仍然可以正常工作：
- 在虛擬機管理程序、核心和 SSD 中正確設置寫入記憶體
- 避免 LVM 快照
- 使用最近的 LVM 版本來調整文件系統的大小
- 有良好的備份
細節
我過去對此進行了相當多的研究，並經歷了與 LVM 相關的一些數據失去。我知道的主要 LVM 風險和問題是：
由於 VM 管理程序、磁碟記憶體或舊的 Linux 核心，容易受到硬碟寫入記憶體的影響，並且由於更複雜的磁碟結構，更難以恢復數據 - 請參閱下文了解詳細資訊。我已經看到幾個磁碟上的完整 LVM 設置被損壞而沒有任何恢復的機會，而 LVM 加上硬碟寫入記憶體是一個危險的組合。
- 硬碟驅動器的寫入記憶體和寫入重新排序對於良好的性能很重要，但由於 VM 管理程序、硬碟驅動器寫入記憶體、舊的 Linux 核心等，可能無法正確地將塊刷新到磁碟。
- 寫屏障意味著核心保證它會在“屏障”磁碟寫入之前完成某些磁碟寫入，以確保文件系統和 RAID 在突然斷電或崩潰的情況下能夠恢復。這樣的屏障可以使用FUA（強制單元訪問）操作將某些塊立即寫入磁碟，這比完全記憶體刷新更有效。屏障可以與高效的標記/本機命令隊列（一次發出多個磁碟 I/O 請求）相結合，使硬碟驅動器能夠執行智能寫入重新排序，而不會增加數據失去的風險。
- VM 虛擬機管理程序可能有類似的問題：由於寫入記憶體和寫入重新寫入，在 VM 虛擬機管理程序（如 VMware、 Xen、KVM、Hyper-V 或 VirtualBox ）之上的 Linux 客戶機中執行 LVM 可能會在沒有寫入障礙的情況下對核心產生類似的問題-訂購。仔細檢查您的虛擬機管理程序文件以了解“刷新到磁碟”或直寫記憶體選項（存在於KVM、VMware、Xen、VirtualBox等中） - 並使用您的設置對其進行測試。一些虛擬機管理程序（例如 VirtualBox）有一個預設設置，它忽略來自來賓的任何磁碟刷新。
- *具有 LVM 的企業伺服器應始終使用電池支持的 RAID 控制器*並禁用硬碟寫入記憶體（控制器具有快速且安全的電池支持寫入記憶體） - 請參閱此 XFS 常見問題解答條目的作者的評論。關閉核心中的寫屏障也可能是安全的，但建議進行測試。
- 如果您沒有電池支持的 RAID 控制器，禁用硬碟寫入記憶體會顯著減慢寫入速度，但會使 LVM 安全。您還應該使用等效於 ext3 的
data=ordered選項（或data=journal為了額外的安全性），並barrier=1確保核心記憶體不會影響完整性。（或使用預設啟用屏障的ext4 。）這是最簡單的選項，並以性能為代價提供良好的數據完整性。（Linux不久前將預設的 ext3 選項更改為更危險data=writeback的選項，因此不要依賴 FS 的預設設置。）- 要禁用硬碟驅動器寫入記憶體：添加（用於 SATA）
hdparm -q -W0 /dev/sdX中的所有驅動器/etc/rc.local或使用 sdparm 用於 SCSI/SAS。但是，根據XFS 常見問題解答中的這個條目（關於這個主題非常好），SATA 驅動器可能會在驅動器錯誤恢復後忘記這個設置 - 所以你應該使用 SCSI/SAS，或者如果你必須使用 SATA 然後把hdparm 命令在每分鐘左右執行的 cron 作業中執行。- 保持啟用 SSD / 硬碟寫入記憶體以獲得更好的性能：這是一個複雜的領域 - 請參閱下面的部分。
- 如果您使用的是高級格式驅動器，即 4 KB 物理扇區，請參見下文 - 禁用寫入記憶體可能還有其他問題。
- UPS對企業和 SOHO 都至關重要，但不足以保證 LVM 的安全：任何導致硬碟崩潰或斷電（例如 UPS 故障、PSU 故障或筆記型電腦電池耗盡）的事情都可能會失去硬碟記憶體中的數據。
- 非常舊的 Linux 核心（2009 年的 2.6.x）：在非常舊的核心版本 2.6.32 和更早版本中沒有不完整的寫屏障支持（2.6.31 有一些支持，而2.6.33 適用於所有類型的設備目標） - RHEL 6 使用帶有許多更新檔的 2.6.32。如果這些舊的 2.6 核心未針對這些問題進行修補，則大量 FS 元數據（包括日誌）可能會因硬碟崩潰而失去，從而將數據留在硬碟驅動器的寫入緩衝區中（例如，普通 SATA 驅動器每個驅動器 32 MB）。失去 32MB 最近寫入的 FS 元數據和日誌數據，核心認為這些數據已經在磁碟上，這通常意味著大量 FS 損壞，從而導致數據失去。
- **摘要：**您必須注意與 LVM 一起使用的文件系統、RAID、VM 管理程序和硬碟驅動器/SSD 設置。如果您使用 LVM，則必須有非常好的備份，並確保專門備份 LVM 元數據、物理分區設置、MBR 和卷引導扇區。還建議使用 SCSI/SAS 驅動器，因為這些驅動器不太可能謊報它們如何進行寫入記憶體 - 使用 SATA 驅動器需要更加小心。
保持啟用寫入記憶體以提高性能（並應對躺著的驅動器）
一個更複雜但性能更高的選項是保持啟用 SSD / 硬碟驅動器寫入記憶體並依賴核心寫入屏障與核心 2.6.33+ 上的 LVM 一起工作（通過在日誌中查找“屏障”消息進行雙重檢查）。
您還應該確保 RAID 設置、VM 管理程序設置和文件系統使用寫屏障（即要求驅動器在關鍵元數據/日誌寫入之前和之後刷新掛起的寫入）。 XFS 預設使用屏障，但 ext3 不使用，因此對於 ext3，您應該
barrier=1在掛載選項中使用，並且仍然使用data=orderedordata=journal如上所述。
- 不幸的是，一些硬碟驅動器和 SSD謊稱它們是否真的將記憶體刷新到磁碟（特別是舊驅動器，但包括一些 SATA 驅動器和一些企業級 SSD） -更多細節在這裡。XFS 開發人員有一個很棒的總結。
- 有一個用於放置驅動器的簡單測試工具（Perl 腳本），或者使用另一個工具測試由於驅動器記憶體而導致的寫入重新排序 ，請參閱此背景。這個答案涵蓋了對 SATA 驅動器的類似測試，這些測試發現了軟體 RAID 中的寫入障礙問題——這些測試實際上是對整個儲存堆棧進行了測試。
- 支持本機命令隊列(NCQ)的最新 SATA 驅動器可能不太可能撒謊- 或者由於 NCQ，它們可能在沒有寫入記憶體的情況下表現良好，並且很少有驅動器無法禁用寫入記憶體。
- SCSI/SAS 驅動器通常是可以的，因為它們不需要寫記憶體就能很好地執行（通過 SCSI Tagged Command Queuing，類似於 SATA 的 NCQ）。
- 如果您的硬碟驅動器或 SSD 確實在將記憶體刷新到磁碟上撒謊，那麼您真的不能依賴寫屏障，必須禁用寫記憶體。這是所有文件系統、數據庫、捲管理器和軟體 RAID的問題，而不僅僅是 LVM。
SSD存在問題，因為寫入記憶體的使用對 SSD 的使用壽命至關重要。最好使用具有超級電容器的 SSD（以在電源故障時啟用記憶體刷新，從而使記憶體能夠回寫而不是直寫）。
- 大多數企業級 SSD 的寫入記憶體控制應該沒問題，有些還包括超級電容器。
- 一些更便宜的 SSD 存在寫入記憶體配置無法解決的問題- PostgreSQL 項目的郵件列表和Reliable Writes wiki 頁面是很好的資訊來源。消費級 SSD 可能存在會導致數據失去的主要寫入記憶體問題，並且不包括超級電容器，因此容易受到電源故障的影響而導致損壞。
高級格式化驅動器設置 - 寫入記憶體、對齊、RAID、GPT
- 對於使用 4 KiB 物理扇區的較新的高級格式驅動器，保持驅動器寫入記憶體啟用可能很重要，因為大多數此類驅動器目前模擬 512 字節邏輯扇區（“512 模擬”），有些甚至聲稱具有 512 字節物理扇區，而真正使用 4 KiB。
- 如果應用程序/核心正在執行 512 字節寫入，則關閉高級格式驅動器的寫入記憶體可能會導致非常大的性能影響，因為此類驅動器在執行單個 4 KiB 物理之前依賴記憶體來累積 8 x 512 字節寫入寫。如果禁用記憶體，建議進行測試以確認任何影響。
- 在 4 KiB 邊界上對齊 LV 對性能很重要，但只要 PV 的底層分區對齊，就應該自動發生，因為 LVM 物理範圍 (PE) 預設為 4 MiB。此處必須考慮 RAID - 此LVM 和軟體 RAID 設置頁面建議將 RAID 超級塊放在卷的末尾，並（如有必要）使用選項
pvcreate來對齊 PV。此 LVM 電子郵件列表執行緒指向 2011 年在核心中完成的工作，以及在單個 LV 中混合具有 512 字節和 4 KiB 扇區的磁碟時部分塊寫入的問題。- 使用高級格式進行 GPT 分區需要小心，尤其是對於引導 + 根磁碟，以確保第一個 LVM 分區 (PV) 從 4 KiB 邊界開始。
由於更複雜的磁碟結構，更難恢復數據：
- 在硬崩潰或斷電（由於不正確的寫入記憶體）之後所需的任何 LVM 數據恢復最多只能是手動過程，因為顯然沒有合適的工具。LVM 擅長在
/etc/lvm.- 因此，可能需要從備份進行完全恢復。在不使用 LVM 時，這比基於日誌的快速 fsck 涉及更多的停機時間，並且自上次備份以來寫入的數據將失去。
- TestDisk、 ext3grep、ext3undel和其他工具 可以從非 LVM 磁碟恢復分區和文件，但它們不直接支持 LVM 數據恢復。TestDisk 可以發現失去的物理分區包含 LVM PV，但這些工具都不能理解 LVM 邏輯卷。文件雕刻工具（如 PhotoRec和許多其他工具）可以繞過文件系統從數據塊中重新組裝文件，但這是用於有價值數據的最後手段、低級方法，並且對碎片文件的效果較差。
- 在某些情況下，手動 LVM 恢復是可能的，但複雜且耗時 - 請參閱此範例以及此、此和此以了解如何恢復。
更難正確調整文件系統的大小 - 輕鬆調整文件系統大小通常是 LVM 的一個好處，但是您需要執行六個 shell 命令來調整基於 LVM 的 FS - 這可以在整個伺服器仍然執行的情況下完成，在某些情況下安裝了 FS，但如果沒有最新的備份和使用在等效伺服器上預先測試的命令（例如生產伺服器的災難恢復複製），我絕不會冒險後者。
- 更新：
lvextend支持-r( ) 選項的最新版本--resizefs- 如果可用，這是調整 LV 和文件系統大小的一種更安全、更快捷的方法，特別是在縮小 FS 時，您可以跳過本節。- 大多數調整基於 LVM 的 FS 大小的指南都沒有考慮到 FS 必須比 LV 的大小稍微小一些這一事實：這裡有詳細說明。縮小文件系統時，您需要為 FS 調整大小工具指定新的大小，例如
resize2fsext3 和 tolvextend或lvreduce. 如果不小心，由於 1 GB (10^9) 和 1 GiB (2^30)之間的差異，或者各種工具向上或向下舍入大小的方式，大小可能會略有不同。- 如果您沒有完全正確地進行計算（或在最明顯的步驟之外使用一些額外的步驟），您最終可能會得到一個對於 LV 來說太大的 FS。幾個月或幾年內一切看起來都很好，直到你完全填滿 FS，此時你會遇到嚴重的損壞 - 除非你知道這個問題，否則很難找出原因，因為到那時你可能還會遇到真正的磁碟錯誤使局勢蒙上陰影。（這個問題可能只影響減小文件系統的大小 - 然而，很明顯，在任一方向調整文件系統的大小確實會增加數據失去的風險，可能是由於使用者錯誤。）
- 似乎 LV 大小應該比 FS 大小大 2 x LVM 物理範圍 (PE) 大小 - 但請查看上面的連結了解詳細資訊，因為此來源不是權威的。通常允許 8 MiB 就足夠了，但為了安全起見，最好允許更多，例如 100 MiB 或 1 GiB。要檢查 PE 大小和邏輯卷+FS 大小，使用 4 KiB = 4096 字節塊：
以 KiB 顯示 PE 大小：
vgdisplay --units k myVGname | grep "PE Size"所有 LV
lvs --units 4096b的大小：(ext3) FS 的大小，假設 4 KiB FS 塊大小：
tune2fs -l /dev/myVGname/myLVname | grep 'Block count'
- 相比之下，非 LVM 設置使調整 FS 的大小變得非常可靠和容易 - 執行Gparted並調整所需的 FS 大小，然後它將為您完成所有工作。在伺服器上，您可以
parted從 shell 使用。- 通常最好使用Gparted Live CD或Parted Magic，因為它們具有最近且通常比發行版更無錯誤的 Gparted 和核心 - 由於發行版的 Gparted 在執行時未正確更新分區，我曾經失去了整個 FS核心。如果使用發行版的 Gparted，請務必在更改分區後立即重新啟動，以便核心的視圖正確。
快照很難使用，速度慢而且有問題——如果快照用完了預先分配的空間，它會自動刪除。給定 LV 的每個快照都是針對該 LV 的增量（而不是針對以前的快照），當對具有大量寫入活動的文件系統進行快照時（每個快照都比前一個快照大），這可能需要大量空間。創建與原始 LV 大小相同的快照 LV 是安全的，因為快照將永遠不會耗盡可用空間。
快照也可能非常慢（對於這些 MySQL 測試而言，這意味著比不使用 LVM 慢 3 到 6 倍） - 請參閱涵蓋各種快照問題的答案。緩慢的部分原因是快照需要許多同步寫入。
快照有一些重大錯誤，例如在某些情況下，它們會使啟動變得非常緩慢，或導致啟動完全失敗（因為 當它是 LVM 快照時，核心可能會在等待根 FS 時超時
initramfs-tools[已在 Debian更新中修復，2015 年 3 月] ）。
- 然而，許多快照競爭條件錯誤顯然在 2015 年得到修復。
- 沒有快照的 LVM 通常看起來調試得很好，可能是因為快照的使用不如核心功能那麼多。
快照替代方案- 文件系統和虛擬機管理程序
虛擬機/雲快照：
- 如果您使用的是 VM 管理程序或 IaaS 雲提供商（例如 VMware、VirtualBox 或 Amazon EC2/EBS），它們的快照通常是 LVM 快照更好的替代方案。您可以很容易地為備份目的拍攝快照（但在您這樣做之前請考慮凍結 FS）。
文件系統快照：
- 如果您在裸機上使用 ZFS 或 btrfs 的文件系統級快照易於使用並且通常比 LVM 更好（但 ZFS 似乎更成熟，安裝起來更麻煩）：
- ZFS：現在有一個核心 ZFS 實現，它已經使用了幾年，而且 ZFS 似乎正在獲得採用。Ubuntu 現在將 ZFS 作為“開箱即用”選項，包括19.10中 root 上的實驗性 ZFS 。
- btrfs：仍然沒有準備好用於生產（即使在 openSUSE上，它預設提供它並且有專門的團隊致力於 btrfs），而 RHEL 已經停止支持它）。btrfs 現在有一個fsck 工具（FAQ），但如果您需要 fsck 損壞的文件系統，FAQ 建議您諮詢開發人員。
線上備份和 fsck 的快照
快照可用於為備份提供一致的源，只要您注意分配的空間（理想情況下，快照與正在備份的 LV 大小相同）。出色的rsnapshot（從 1.3.1 開始）甚至可以為您管理 LVM 快照的創建/刪除 - 請參閱使用 LVM 的 rsnapshot 上的這個 HOWTO。但是，請注意快照的一般問題，並且不應將快照本身視為備份。
您還可以使用 LVM 快照進行線上 fsck：對 LV 進行快照並 fsck 快照，同時仍使用主要的非快照 FS -此處描述- 但是，它並不完全簡單，因此最好使用Ted Ts 描述的e2croncheck ‘o，ext3 的維護者。
您應該在拍攝快照時暫時“凍結”文件系統——某些文件系統（例如 ext3 和 XFS）會在 LVM 創建快照時自動執行此操作。
結論
儘管如此，我仍然在某些系統上使用 LVM，但對於桌面設置，我更喜歡原始分區。我可以從 LVM 中看到的主要好處是，當您必須在伺服器上具有較高的正常執行時間時，可以靈活地移動和調整 FS 的大小- 如果您不需要，gparted 更容易並且數據失去的風險更小。
由於 VM 管理程序、硬碟驅動器/SSD 寫入記憶體等原因，LVM 需要非常小心地設置寫入記憶體 - 但同樣適用於將 Linux 用作數據庫伺服器。大多數工具缺乏支持（
gparted包括臨界尺寸計算testdisk等）使得它比應有的更難使用。如果使用 LVM，請注意快照：盡可能使用 VM/雲快照，或研究 ZFS/btrfs 以完全避免使用 LVM - 您可能會發現 ZFS 或 btrfs 與使用快照的 LVM 相比已經足夠成熟。
底線：如果您不了解上面列出的問題以及如何解決這些問題，最好不要使用 LVM。