LVM 的危险和警告

Question

我最近开始在某些服务器上对大于 1 TB 的硬盘驱动器使用 LVM。它们很有用、可扩展且非常易于安装。但是，我找不到任何关于 LVM 的危险和警告的数据。

使用 LVM 的缺点是什么？

Answer 1

概括

使用 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（强制单元访问）操作将某些块立即写入磁盘，这比完全缓存刷新更有效。Barriers 可以与高效的标记/本地命令队列（一次发出多个磁盘 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 的默认设置。）
• 要禁用硬盘驱动器写入缓存：hdparm -q -W0 /dev/sdX为所有驱动器添加/etc/rc.local（对于 SATA）或使用 sdparm 用于 SCSI/SAS。但是，根据XFS FAQ 中的这个条目（这对这个主题非常好），在驱动器错误恢复后，SATA 驱动器可能会忘记此设置 - 因此您应该使用 SCSI/SAS，或者如果您必须使用 SATA，则将每分钟左右运行一次的 cron 作业中的 hdparm 命令。
• 保持 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=ordered或data=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 存在无法通过写入缓存配置修复的问题- 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，可以帮助恢复 LV、VG 和 PV 的基本结构，但对丢失的文件系统元数据无济于事。
• 因此，可能需要从备份中完全恢复。与不使用 LVM 时基于日志的快速 fsck 相比，这涉及更多的停机时间，并且自上次备份以来写入的数据将丢失。
• TestDisk， ext3grep，ext3undel和其他工具 可以恢复从非LVM磁盘分区和文件，但他们不直接支持LVM数据恢复。TestDisk 可以发现丢失的物理分区包含 LVM PV，但这些工具都无法理解 LVM 逻辑卷。文件雕刻工具（例如PhotoRec和许多其他工具） 可以绕过文件系统从数据块中重新组装文件，但这是用于有价值数据的最后手段，低级方法，并且在处理碎片文件时效果不佳。
• 在某些情况下，手动 LVM 恢复是可能的，但既复杂又耗时 -有关如何恢复的信息，请参阅此示例和this、this和this。

更难正确调整文件系统大小 - 轻松调整文件系统大小通常是 LVM 的一个好处，但您需要运行六个 shell 命令来调整基于 LVM 的文件系统的大小 - 这可以在整个服务器仍然运行的情况下完成，并且在某些情况下安装了 FS，但如果没有最新的备份和使用在等效服务器上预先测试的命令（例如生产服务器的灾难恢复克隆），我绝不会冒险使用后者。

• 更新：更新的版本lvextend支持-r( --resizefs) 选项 - 如果可用，这是调整 LV 和文件系统大小的一种更安全、更快捷的方法，尤其是在缩小 FS 时，您通常可以跳过此部分。

• 大多数调整基于 LVM 的 FS 大小的指南都没有考虑到 FS 必须比 LV 的大小小一点的事实：这里有详细解释。缩小文件系统时，您需要为 FS 调整大小工具指定新的大小，例如resize2fsext3 和lvextend或lvreduce。如果不小心，由于 1 GB (10^9) 和 1 GiB (2^30)之间的差异，或者各种工具向上或向下舍入大小的方式，大小可能会略有不同。

• 如果您没有完全正确地进行计算（或使用一些超出最明显步骤的额外步骤），您最终可能会得到一个对于 LV 来说太大的 FS。几个月或几年内一切似乎都很好，直到您完全填满 FS，此时您会严重损坏 - 除非您意识到这个问题，否则很难找出原因，因为到那时您可能还会遇到真正的磁盘错误那云的情况。（这个问题可能只影响减小文件系统的大小——但是，很明显，在任一方向调整文件系统大小确实会增加数据丢失的风险，这可能是由于用户错误。）

• LV 大小似乎应该比 FS 大小大 2 倍 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 [已在 Debianinitramfs-tools更新中修复，2015 年 3 月] ）。

• 然而，许多快照竞争条件错误显然在 2015 年得到修复。
• 没有快照的 LVM 通常看起来很好调试，也许是因为快照没有像核心功能那样使用。

快照替代方案- 文件系统和 VM 管理程序

虚拟机/云快照：

• 如果您使用的是 VM 管理程序或 IaaS 云提供商（例如 VMware、VirtualBox 或 Amazon EC2/EBS），它们的快照通常是 LVM 快照的更好替代方案。您可以很容易地为备份目的拍摄快照（但请考虑在您这样做之前冻结 FS）。

文件系统快照：

• 如果您在裸机上，使用 ZFS 或 btrfs 的文件系统级快照易于使用并且通常比 LVM 更好（但 ZFS 似乎更成熟，只是安装起来更麻烦）：

• ZFS：现在有一个内核 ZFS 实现，它已经使用了几年，而且 ZFS 似乎正在获得采用。Ubuntu 现在将 ZFS 作为“开箱即用”选项，包括19.10 中root 上的实验性 ZFS 。

• btrfs：仍未准备好用于生产（即使在默认情况下提供它并有专门用于 btrfs 的团队的openSUSE 上也是如此），而 RHEL 已停止支持它）。btrfs 现在有一个fsck 工具 (FAQ)，但是如果您需要 fsck 损坏的文件系统，FAQ 建议您咨询开发人员。

在线备份和 fsck 的快照

快照可用于为备份提供一致的源，只要您小心分配的空间（理想情况下快照与正在备份的 LV 大小相同）。出色的rsnapshot（自 1.3.1 起）甚至可以为您管理 LVM 快照的创建/删除 - 请参阅使用 LVM 的 rsnapshot 上的此HOWTO。但是，请注意快照的一般问题，并且不应将快照本身视为备份。

您还可以使用LVM快照做一个在线的fsck：快照LV和fsck的快照，而仍然使用的主要非快照FS -这里描述的-但是，这并不简单，所以最好使用e2croncheck为泰德TS描述'o，ext3 的维护者。

您应该在拍摄快照时暂时“冻结”文件系统- 某些文件系统（例如 ext3 和 XFS）会在 LVM 创建快照时自动执行此操作。

结论

尽管如此，我仍然在某些系统上使用 LVM，但对于桌面设置，我更喜欢原始分区。我从 LVM 中看到的主要好处是，当您必须在服务器上具有很高的正常运行时间时，可以灵活地移动和调整 FS 的大小——如果您不需要它，gparted 更容易并且数据丢失的风险更小。

由于 VM 管理程序、硬盘驱动器 / SSD 写入缓存等，LVM 需要非常小心地设置写入缓存 - 但同样适用于使用 Linux 作为数据库服务器。大多数工具（gparted包括临界尺寸计算testdisk等）缺乏支持使得它比应有的更难使用。

如果使用 LVM，请注意快照：如果可能，请使用 VM/云快照，或者调查 ZFS/btrfs 以完全避免 LVM - 您可能会发现 ZFS 或 btrfs 与带快照的 LVM 相比已经足够成熟。

底线：如果您不了解上面列出的问题以及如何解决这些问题，最好不要使用 LVM。

Answer 2

我 [+1] 那个帖子，至少对我来说，我认为大多数问题确实存在。在运行 100 台服务器和 100TB 数据时看到了它们。对我来说，Linux 中的 LVM2 感觉就像是某人的“聪明主意”。像其中一些人一样，他们有时会“不聪明”。即没有严格分离的内核和用户空间 (lvmtab) 状态可能会感觉非常聪明，因为可能存在损坏问题（如果您没有正确获取代码）

好吧，只是这种分离是有原因的- 差异显示在 PV 丢失处理上，以及在线重新激活缺少 PV 的 VG 以使其重新发挥作用 - “原始 LVM”（AIX）有什么轻而易举的, HP-UX) 在 LVM2 上变成垃圾，因为状态处理不够好。甚至不要让我谈论仲裁丢失检测（哈哈）或状态处理（如果我删除一个磁盘，它不会被标记为不可用。它甚至没有该死的状态列）

回复：稳定性 pvmove ... 为什么是

pvmove 数据丢失

我的博客上有这么一篇排名靠前的文章，嗯？刚才我查看了一个磁盘，其中物理lvm数据仍然挂在pvmove中的状态上。我认为存在一些内存泄漏，从用户空间复制实时块数据是一件好事的总体想法令人难过。来自 lvm 列表的不错引用“似乎 vgreduce --missing 不处理 pvmove”实际上意味着如果磁盘在 pvmove 期间分离，那么 lvm 管理工具将从 lvm 更改为 vi。哦，还有一个错误，pvmove 在块读/写错误后继续，实际上不再将数据写入目标设备。跆拳道？

回复：快照 CoW 是不安全的，通过将新数据更新到快照 lv 区域，然后在删除快照后合并回来。这意味着在将新数据最终合并回原始 LV 期间，您会遇到严重的 IO 峰值，更重要的是，您当然也有更高的数据损坏风险，因为一旦您点击墙，可是原来的。

优势在于性能，执行 1 次写入而不是 3 次写入。选择快速但不安全的算法显然是 VMware 和 MS 等人所期望的，在“Unix”上，我宁愿猜测事情会“做得对”。只要我在与主数据不同的磁盘驱动器上拥有快照后备存储（当然还有备份到另一个磁盘驱动器），我就没有看到太多的性能问题

回复：障碍 我不确定是否可以将其归咎于 LVM。据我所知，这是一个 devmapper 问题。但是至少从内核 2.6 到 2.6.33 AFAIK Xen 是唯一一个使用 O_DIRECT 用于虚拟机的管理程序，问题曾经是使用“循环”时，因为内核仍然会缓存使用它。Virtualbox 至少有一些设置可以禁用这样的东西，而 Qemu/KVM 通常似乎允许缓存。所有 FUSE FS 也有问题（没有 O_DIRECT）

回复：大小 我认为 LVM 对显示的大小进行“四舍五入”。或者它使用 GiB。无论如何，您需要使用VG Pe大小并将其乘以LV的LE编号。这应该给出正确的净尺寸，并且该问题始终是使用问题。更糟糕的是文件系统在 fsck/mount (hello, ext3) 期间没有注意到这样的事情，或者没有在线工作的 "fsck -n" (hello, ext3)

当然，这说明您找不到此类信息的良好来源。“VRA 有多少 LE？” “PVRA、VGDA 等的物理偏移是多少”

与最初的 LVM2 相比，LVM2 是“那些不了解 UNIX 的人注定要重新发明它，很糟糕”的主要例子。

几个月后更新：到目前为止，我一直在使用“完整快照”场景进行测试。如果它们已满，则快照会阻塞，而不是原始 LV。当我第一次发布这个时，我错了。我从某个文档中获取了错误的信息，或者我可能已经理解了。在我的设置中，我一直很偏执，不让它们填满，所以我最终没有得到纠正。也可以扩展/收缩快照，这是一种享受。

我仍然无法解决的是如何识别快照的年龄。至于它们的性能，在“thinp”fedora 项目页面上有一个注释，它说快照技术正在被修改，以便它们不会随着每个快照而变慢。我不知道他们是如何实施的。

Answer 3

如果您计划使用快照进行备份 - 准备好在出现快照时对性能造成重大影响。否则一切都很好。我已经在几十台服务器上在生产中使用 lvm 几年了，尽管我使用它的主要原因是原子快照不能轻松扩展卷。

顺便说一句，如果您打算使用 1TB 驱动器，请记住分区对齐 - 该驱动器很可能具有 4kB 物理扇区。

Answer 4

虽然提供了一个关于 10 多年前 LVM 状态的有趣窗口，但公认的答案现在已经完全过时了。现代（即：2012 年后的 LVM）：

• 尊重同步/屏障请求
• 具有快速可靠的快照功能 lvmthin
• 具有稳定的 SSD 缓存通过lvmcache和 NVMe/NVDIMM/Optane 的快速写回策略通过dm-writecache
• 虚拟数据优化器 ( vdo) 支持归功于lvmvdo
• 集成和每卷 RAID 归功于 lvmraid
• 自动对齐到 1MB 或 4MB（取决于版本），完全避免任何 4K 对齐问题（除非在未对齐的分区上使用 LVM）
• 对扩展卷的出色支持，尤其是在添加其他块设备时（在普通分区之上使用经典文件系统作为 ext4/xfs 时，这是根本不可能的）
• 一个优秀、友好和非常有用的邮件列表，位于 linux-lvm@redhat.com

显然，这并不意味着你总是有使用LVM -存储的黄金法则是为了避免不必要的层。例如，对于简单的虚拟机，您当然可以只使用经典分区。但是，如果您重视上述任何功能，LVM 是一个非常有用的工具，任何认真的 Linux 系统管理员都应该拥有它。

Answer 5

亚当，

另一个优势：您可以添加新的物理卷 (PV)，将所有数据移动到该 PV，然后在不中断任何服务的情况下删除旧 PV。在过去的五年里，我至少使用了四次这种能力。

我还没有清楚地指出一个缺点：LVM2 的学习曲线有些陡峭。主要是在您的文件和底层媒体之间创建的抽象。如果您只与几个在一组服务器上分担家务的人一起工作，您可能会发现额外的复杂性对整个团队来说是压倒性的。专注于 IT 工作的较大团队通常不会有这样的问题。

例如，我们在我的工作中广泛使用它，并花时间向整个团队传授有关恢复无法正确启动的系统的基础知识、语言和基本要素。

特别要指出的一个警告：如果从 LVM2 逻辑卷启动，当服务器崩溃时，您会发现恢复操作很困难。Knoppix 和朋友们并不总是有合适的东西。所以，我们决定我们的 /boot 目录将在它自己的分区上，并且总是小而原生的。

总的来说，我是 LVM2 的粉丝。