LVM 的危险和注意事项

Question 1

概括

使用 LVM 的风险：

容易受到 SSD 或 VM 虚拟机管理程序的写入缓存问题的影响
由于磁盘结构更复杂，数据恢复更加困难
更难正确调整文件系统大小
快照难以使用、速度慢且存在缺陷
鉴于这些问题，需要一些技能才能正确配置

前两个 LVM 问题结合在一起：如果写入缓存无法正常工作并且断电（例如 PSU 或 UPS 出现故障），则可能必须从备份中恢复，这意味着长时间停机。使用 LVM 的一个关键原因是更高的正常运行时间（添加磁盘、调整文件系统大小等时），但正确设置写入缓存很重要，以避免 LVM 实际上减少正常运行时间。

-- 2019 年 12 月更新：关于 btrfs 和 ZFS 作为 LVM 快照替代方案的小更新

降低风险

如果您执行以下操作，LVM 仍可正常工作：

在虚拟机管理程序、内核和 SSD 中正确设置写入缓存
避免 LVM 快照
使用最新的 LVM 版本调整文件系统大小
做好备份

细节

过去，我曾对此进行过大量研究，并经历过与 LVM 相关的一些数据丢失。我所知道的主要 LVM 风险和问题是：

由于虚拟机管理程序、磁盘缓存或旧的 Linux 内核，容易受到硬盘写入缓存的影响，并且由于磁盘结构更复杂，数据恢复也变得更加困难 - 详情见下文。我曾见过多个磁盘上的完整 LVM 设置被破坏而没有任何恢复的机会，而 LVM 加上硬盘写入缓存是一种危险的组合。

硬盘的写入缓存和写入重新排序对于良好的性能来说很重要，但由于 VM 管理程序、硬盘写入缓存、旧的 Linux 内核等原因，可能无法正确地将块刷新到磁盘。
写入屏障意味着内核保证在“屏障”磁盘写入之前完成某些磁盘写入，以确保文件系统和 RAID 在突然断电或崩溃时能够恢复。此类屏障可以使用FUA（部队接入）行动立即将某些块写入磁盘，这比完全刷新缓存更有效。屏障可以与高效的标签/本国的命令排队（一次发出多个磁盘 I/O 请求）使硬盘能够执行智能写入重新排序，而不会增加数据丢失的风险。
VM 虚拟机管理程序可能会有类似的问题：在 VM 管理程序（如 VMware）上的 Linux 客户机中运行 LVM，西恩、KVM、Hyper-V 或 VirtualBox 可以创建类似问题由于写入缓存和写入重新排序，内核没有写入屏障。请仔细检查虚拟机管理程序文档，了解“刷新到磁盘”或写入直通缓存选项（存在于虚拟机，VMware，西恩，虚拟盒和其他）-并使用您的设置对其进行测试。一些虚拟机管理程序（例如 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，则将 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=ordered或data=journal如上所述。

不幸的是，一些硬盘和固态硬盘谎称自己是否真的清除了缓存到磁盘（特别是较旧的驱动器，但也包括一些 SATA 驱动器和一些企业级 SSD) -更多详细信息请点击此处。有一个来自 XFS 开发人员的精彩总结。
有一个简单的驱动器测试工具（Perl 脚本），或者参阅使用另一个工具制作的背景测试驱动器缓存导致的写入重新排序。这个答案涵盖了类似的测试SATA 驱动器揭示了软件 RAID 中的写屏障问题 - 这些测试实际上锻炼了整个存储堆栈。
较新的 SATA 驱动器支持本机命令队列（NCQ）可能不太可能撒谎- 或者也许由于 NCQ，它们在没有写入缓存的情况下也能表现良好，并且很少有驱动器无法禁用写入缓存。
SCSI/SAS 驱动器通常没问题，因为它们不需要写入缓存即可表现良好（通过 SCSI标记命令队列，类似于SATA的NCQ）。
如果您的硬盘或 SSD 确实谎称将其缓存刷新到磁盘，那么您真的不能依赖写入屏障，必须禁用写入缓存。这是所有文件系统、数据库、卷管理器和软件 RAID，而不只是 LVM。

固态硬盘存在问题，因为写入缓存的使用对 SSD 的使用寿命至关重要。最好使用具有超级电容器的 SSD（以便在断电时启用缓存刷新，从而使缓存能够回写而不是直写）。

大多数企业级 SSD 在写入缓存控制方面应该没问题，有些甚至包含超级电容器。
一些较便宜的固态硬盘存在以下问题无法通过写入缓存配置修复- PostgreSQL 项目的邮件列表和Reliable Writes 维基页面是很好的信息来源。消费级 SSD 可以存在严重的写入缓存问题这会导致数据丢失，并且不包含超级电容器，因此容易受到电源故障的影响而导致损坏。

高级格式驱动器设置 - 写入缓存、对齐、RAID、GPT

随着更新高级格式驱动器使用 4 KiB 物理扇区，保持驱动器写入缓存启用可能很重要，因为大多数此类驱动器当前模拟 512 字节逻辑扇区（“512 仿真”)，有些甚至声称拥有 512 字节物理扇区，但实际上使用的是 4 KiB。
如果应用程序/内核正在执行 512 字节写入，则关闭高级格式驱动器的写入缓存可能会对性能造成很大影响，因为此类驱动器依靠缓存在执行单个 4 KiB 物理写入之前累积 8 x 512 字节写入。建议进行测试以确认禁用缓存后是否会产生任何影响。
将 LV 与 4 KiB 边界对齐对于性能来说很重要，但只要 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 需要更多的停机时间，并且自上次备份以来写入的数据将丢失。
测试磁盘， ext3grep，ext3undel和其他工具可以从非 LVM 磁盘恢复分区和文件，但它们不直接支持 LVM 数据恢复。TestDisk 可以发现丢失的物理分区包含 LVM PV，但这些工具都不了解 LVM 逻辑卷。锉雕工具如相簿许多其他方法可以绕过文件系统，从数据块重新组装文件，但这是处理有价值数据的最后手段、低级方法，对于碎片文件效果较差。
在某些情况下可以进行手动 LVM 恢复，但很复杂且耗时 - 请参阅这个例子和这，这，和这如何恢复。

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

更新：较新版本lvextend支持-r（--resizefs）选项 - 如果可用，则这是一种更安全、更快捷的调整 LV 和文件系统大小的方法，特别是当您缩小 FS 时，您基本上可以跳过此部分。
大多数关于调整基于 LVM 的 FS 大小的指南都没有考虑到 FS 必须比 LV 的大小略小这一事实：这里有详细解释。缩小文件系统时，您需要向 FS 调整大小工具指定新大小，例如resize2fs对于 ext3，以及lvextend或lvreduce。如果不小心，由于 1 GB（10^9）和 1 之间的差异，大小可能会略有不同吉布(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 大小，然后它将为您完成所有工作。在服务器上，您可以parted从 shell 中使用。
通常最好使用Gparted 实时 CD或者Parted Magic，因为它们具有比发行版更新且通常没有错误的 Gparted 和内核 - 我曾经因为发行版的 Gparted 无法在正在运行的内核中正确更新分区而丢失了整个 FS。如果使用发行版的 Gparted，请确保在更改分区后立即重新启动，以便内核的视图正确。

快照难以使用、速度慢且存在缺陷- 如果快照用尽了预先分配的空间，则自动掉落。给定 LV 的每个快照都是相对于该 LV 的增量（而不是相对于以前的快照），当快照文件系统具有大量写入活动时，这可能需要大量空间（每个快照都比前一个大）。创建与原始 LV 大小相同的快照 LV 是安全的，因为快照永远不会用尽可用空间。

快照也可能非常慢（这意味着比没有 LVM 时慢 3 到 6 倍这些 MySQL 测试） - 看这个答案涵盖了各种快照问题。缓慢的部分原因是快照需要多次同步写入。

快照存在一些重大错误，例如在某些情况下它们会使启动非常慢，或者导致启动完全失败（因为内核可能超时当它是 LVM 快照时等待根 FS [已在initramfs-tools2015 年 3 月的 Debian 更新中修复]）。

然而，许多快照竞争条件错误显然固定的到2015年。
没有快照的 LVM 通常看起来调试得很好，可能是因为快照的使用并不像核心功能那么多。

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

VM/云快照：

如果您使用的是 VM 虚拟机管理程序或 IaaS 云提供商（例如 VMware、VirtualBox 或 Amazon EC2/EBS），它们的快照通常是 LVM 快照的更好替代方案。您可以非常轻松地拍摄快照以进行备份（但请考虑在拍摄之前冻结 FS）。

文件系统快照：

如果你使用的是裸机，那么使用 ZFS 或 btrfs 的文件系统级快照很容易使用，而且通常比 LVM 更好（但 ZFS 似乎更加成熟，只是安装起来更麻烦）：
ZFS：现在有一个内核 ZFS 实现，该文件系统已经使用了好几年，而且 ZFS 似乎正在逐渐被接受。Ubuntu 现在将 ZFS 作为“开箱即用”选项，包括根文件系统上的实验性 ZFS在 19.10。
btrfs：仍未准备好投入生产使用（甚至在 openSUSE 上默认情况下会提供它，并且有专门的团队开发 btrfs），而 RHEL 已停止支持它）。btrfs 现在有一个fsck 工具（常见问题解答），但如果您需要 fsck 损坏的文件系统，常见问题解答建议您咨询开发人员。

用于在线备份和 fsck 的快照

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

您还可以使用 LVM 快照执行在线 fsck：对 LV 进行快照，然后对快照进行 fsck，同时仍使用主非快照 FS -描述在这里- 然而，这是并不完全简单所以最好使用e2croncheck作为由 Ted Ts'o 描述，ext3 的维护者。

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

结论

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

由于 VM 虚拟机管理程序、硬盘/SSD 写入缓存等原因，LVM 需要非常小心地设置写入缓存 - 但使用 Linux 作为数据库服务器时也是如此。大多数工具（gparted包括关键大小计算等testdisk）缺乏支持，这使其比应有的更难使用。

如果使用 LVM，请特别小心使用快照：尽可能使用 VM/云快照，或者研究 ZFS/btrfs 以完全避免 LVM - 您可能会发现与带有快照的 LVM 相比，ZFS 或 btrfs 已经足够成熟。

底线：如果您不知道上面列出的问题以及如何解决它们，最好不要使用 LVM。

Answer

概括

使用 LVM 的风险：

容易受到 SSD 或 VM 虚拟机管理程序的写入缓存问题的影响
由于磁盘结构更复杂，数据恢复更加困难
更难正确调整文件系统大小
快照难以使用、速度慢且存在缺陷
鉴于这些问题，需要一些技能才能正确配置

前两个 LVM 问题结合在一起：如果写入缓存无法正常工作并且断电（例如 PSU 或 UPS 出现故障），则可能必须从备份中恢复，这意味着长时间停机。使用 LVM 的一个关键原因是更高的正常运行时间（添加磁盘、调整文件系统大小等时），但正确设置写入缓存很重要，以避免 LVM 实际上减少正常运行时间。

-- 2019 年 12 月更新：关于 btrfs 和 ZFS 作为 LVM 快照替代方案的小更新

降低风险

如果您执行以下操作，LVM 仍可正常工作：

在虚拟机管理程序、内核和 SSD 中正确设置写入缓存
避免 LVM 快照
使用最新的 LVM 版本调整文件系统大小
做好备份

细节

过去，我曾对此进行过大量研究，并经历过与 LVM 相关的一些数据丢失。我所知道的主要 LVM 风险和问题是：

由于虚拟机管理程序、磁盘缓存或旧的 Linux 内核，容易受到硬盘写入缓存的影响，并且由于磁盘结构更复杂，数据恢复也变得更加困难 - 详情见下文。我曾见过多个磁盘上的完整 LVM 设置被破坏而没有任何恢复的机会，而 LVM 加上硬盘写入缓存是一种危险的组合。

硬盘的写入缓存和写入重新排序对于良好的性能来说很重要，但由于 VM 管理程序、硬盘写入缓存、旧的 Linux 内核等原因，可能无法正确地将块刷新到磁盘。
写入屏障意味着内核保证在“屏障”磁盘写入之前完成某些磁盘写入，以确保文件系统和 RAID 在突然断电或崩溃时能够恢复。此类屏障可以使用FUA（部队接入）行动立即将某些块写入磁盘，这比完全刷新缓存更有效。屏障可以与高效的标签/本国的命令排队（一次发出多个磁盘 I/O 请求）使硬盘能够执行智能写入重新排序，而不会增加数据丢失的风险。
VM 虚拟机管理程序可能会有类似的问题：在 VM 管理程序（如 VMware）上的 Linux 客户机中运行 LVM，西恩、KVM、Hyper-V 或 VirtualBox 可以创建类似问题由于写入缓存和写入重新排序，内核没有写入屏障。请仔细检查虚拟机管理程序文档，了解“刷新到磁盘”或写入直通缓存选项（存在于虚拟机，VMware，西恩，虚拟盒和其他）-并使用您的设置对其进行测试。一些虚拟机管理程序（例如 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，则将 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=ordered或data=journal如上所述。

不幸的是，一些硬盘和固态硬盘谎称自己是否真的清除了缓存到磁盘（特别是较旧的驱动器，但也包括一些 SATA 驱动器和一些企业级 SSD) -更多详细信息请点击此处。有一个来自 XFS 开发人员的精彩总结。
有一个简单的驱动器测试工具（Perl 脚本），或者参阅使用另一个工具制作的背景测试驱动器缓存导致的写入重新排序。这个答案涵盖了类似的测试SATA 驱动器揭示了软件 RAID 中的写屏障问题 - 这些测试实际上锻炼了整个存储堆栈。
较新的 SATA 驱动器支持本机命令队列（NCQ）可能不太可能撒谎- 或者也许由于 NCQ，它们在没有写入缓存的情况下也能表现良好，并且很少有驱动器无法禁用写入缓存。
SCSI/SAS 驱动器通常没问题，因为它们不需要写入缓存即可表现良好（通过 SCSI标记命令队列，类似于SATA的NCQ）。
如果您的硬盘或 SSD 确实谎称将其缓存刷新到磁盘，那么您真的不能依赖写入屏障，必须禁用写入缓存。这是所有文件系统、数据库、卷管理器和软件 RAID，而不只是 LVM。

固态硬盘存在问题，因为写入缓存的使用对 SSD 的使用寿命至关重要。最好使用具有超级电容器的 SSD（以便在断电时启用缓存刷新，从而使缓存能够回写而不是直写）。

大多数企业级 SSD 在写入缓存控制方面应该没问题，有些甚至包含超级电容器。
一些较便宜的固态硬盘存在以下问题无法通过写入缓存配置修复- PostgreSQL 项目的邮件列表和Reliable Writes 维基页面是很好的信息来源。消费级 SSD 可以存在严重的写入缓存问题这会导致数据丢失，并且不包含超级电容器，因此容易受到电源故障的影响而导致损坏。

高级格式驱动器设置 - 写入缓存、对齐、RAID、GPT

随着更新高级格式驱动器使用 4 KiB 物理扇区，保持驱动器写入缓存启用可能很重要，因为大多数此类驱动器当前模拟 512 字节逻辑扇区（“512 仿真”)，有些甚至声称拥有 512 字节物理扇区，但实际上使用的是 4 KiB。
如果应用程序/内核正在执行 512 字节写入，则关闭高级格式驱动器的写入缓存可能会对性能造成很大影响，因为此类驱动器依靠缓存在执行单个 4 KiB 物理写入之前累积 8 x 512 字节写入。建议进行测试以确认禁用缓存后是否会产生任何影响。
将 LV 与 4 KiB 边界对齐对于性能来说很重要，但只要 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 需要更多的停机时间，并且自上次备份以来写入的数据将丢失。
测试磁盘， ext3grep，ext3undel和其他工具可以从非 LVM 磁盘恢复分区和文件，但它们不直接支持 LVM 数据恢复。TestDisk 可以发现丢失的物理分区包含 LVM PV，但这些工具都不了解 LVM 逻辑卷。锉雕工具如相簿许多其他方法可以绕过文件系统，从数据块重新组装文件，但这是处理有价值数据的最后手段、低级方法，对于碎片文件效果较差。
在某些情况下可以进行手动 LVM 恢复，但很复杂且耗时 - 请参阅这个例子和这，这，和这如何恢复。

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

更新：较新版本lvextend支持-r（--resizefs）选项 - 如果可用，则这是一种更安全、更快捷的调整 LV 和文件系统大小的方法，特别是当您缩小 FS 时，您基本上可以跳过此部分。
大多数关于调整基于 LVM 的 FS 大小的指南都没有考虑到 FS 必须比 LV 的大小略小这一事实：这里有详细解释。缩小文件系统时，您需要向 FS 调整大小工具指定新大小，例如resize2fs对于 ext3，以及lvextend或lvreduce。如果不小心，由于 1 GB（10^9）和 1 之间的差异，大小可能会略有不同吉布(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 大小，然后它将为您完成所有工作。在服务器上，您可以parted从 shell 中使用。
通常最好使用Gparted 实时 CD或者Parted Magic，因为它们具有比发行版更新且通常没有错误的 Gparted 和内核 - 我曾经因为发行版的 Gparted 无法在正在运行的内核中正确更新分区而丢失了整个 FS。如果使用发行版的 Gparted，请确保在更改分区后立即重新启动，以便内核的视图正确。

快照难以使用、速度慢且存在缺陷- 如果快照用尽了预先分配的空间，则自动掉落。给定 LV 的每个快照都是相对于该 LV 的增量（而不是相对于以前的快照），当快照文件系统具有大量写入活动时，这可能需要大量空间（每个快照都比前一个大）。创建与原始 LV 大小相同的快照 LV 是安全的，因为快照永远不会用尽可用空间。

快照也可能非常慢（这意味着比没有 LVM 时慢 3 到 6 倍这些 MySQL 测试） - 看这个答案涵盖了各种快照问题。缓慢的部分原因是快照需要多次同步写入。

快照存在一些重大错误，例如在某些情况下它们会使启动非常慢，或者导致启动完全失败（因为内核可能超时当它是 LVM 快照时等待根 FS [已在initramfs-tools2015 年 3 月的 Debian 更新中修复]）。

然而，许多快照竞争条件错误显然固定的到2015年。
没有快照的 LVM 通常看起来调试得很好，可能是因为快照的使用并不像核心功能那么多。

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

VM/云快照：

如果您使用的是 VM 虚拟机管理程序或 IaaS 云提供商（例如 VMware、VirtualBox 或 Amazon EC2/EBS），它们的快照通常是 LVM 快照的更好替代方案。您可以非常轻松地拍摄快照以进行备份（但请考虑在拍摄之前冻结 FS）。

文件系统快照：

如果你使用的是裸机，那么使用 ZFS 或 btrfs 的文件系统级快照很容易使用，而且通常比 LVM 更好（但 ZFS 似乎更加成熟，只是安装起来更麻烦）：
ZFS：现在有一个内核 ZFS 实现，该文件系统已经使用了好几年，而且 ZFS 似乎正在逐渐被接受。Ubuntu 现在将 ZFS 作为“开箱即用”选项，包括根文件系统上的实验性 ZFS在 19.10。
btrfs：仍未准备好投入生产使用（甚至在 openSUSE 上默认情况下会提供它，并且有专门的团队开发 btrfs），而 RHEL 已停止支持它）。btrfs 现在有一个fsck 工具（常见问题解答），但如果您需要 fsck 损坏的文件系统，常见问题解答建议您咨询开发人员。

用于在线备份和 fsck 的快照

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

您还可以使用 LVM 快照执行在线 fsck：对 LV 进行快照，然后对快照进行 fsck，同时仍使用主非快照 FS -描述在这里- 然而，这是并不完全简单所以最好使用e2croncheck作为由 Ted Ts'o 描述，ext3 的维护者。

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

结论

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

由于 VM 虚拟机管理程序、硬盘/SSD 写入缓存等原因，LVM 需要非常小心地设置写入缓存 - 但使用 Linux 作为数据库服务器时也是如此。大多数工具（gparted包括关键大小计算等testdisk）缺乏支持，这使其比应有的更难使用。

如果使用 LVM，请特别小心使用快照：尽可能使用 VM/云快照，或者研究 ZFS/btrfs 以完全避免 LVM - 您可能会发现与带有快照的 LVM 相比，ZFS 或 btrfs 已经足够成熟。

底线：如果您不知道上面列出的问题以及如何解决它们，最好不要使用 LVM。

Question 2

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

尊重同步/屏障请求
具有快速可靠的快照功能，形式为lvmthin
拥有稳定的 SSD 缓存lvmcache以及通过 NVMe/NVDIMM/Optane 的快速写回策略dm-writecache
虚拟数据优化器（vdo）支持得益于lvmvdo
得益于集成和每个卷的 RAIDlvmraid
自动对齐到 1MB 或 4MB（取决于版本），完全避免任何 4K 对齐问题（除非在未对齐的分区上使用 LVM）
对音量扩展的出色支持，尤其通过添加其他块设备来执行此操作（当在普通分区上使用传统文件系统如 ext4/xfs 时，这是不可能的）
一个优秀、友好且极其有用的邮件列表[email protected]

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

Answer

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

尊重同步/屏障请求
具有快速可靠的快照功能，形式为lvmthin
拥有稳定的 SSD 缓存lvmcache以及通过 NVMe/NVDIMM/Optane 的快速写回策略dm-writecache
虚拟数据优化器（vdo）支持得益于lvmvdo
得益于集成和每个卷的 RAIDlvmraid
自动对齐到 1MB 或 4MB（取决于版本），完全避免任何 4K 对齐问题（除非在未对齐的分区上使用 LVM）
对音量扩展的出色支持，尤其通过添加其他块设备来执行此操作（当在普通分区上使用传统文件系统如 ext4/xfs 时，这是不可能的）
一个优秀、友好且极其有用的邮件列表[email protected]

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

Question 3

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

嗯，只是有这种分离因为某种原因- 差异表现在 PV 丢失处理和在线重新激活缺少 PV 的 VG 以使其重新发挥作用 - “原始 LVM”（AIX、HP-UX）上的轻而易举的事情在 LVM2 上变成了垃圾，因为状态处理不够好。甚至不要让我谈论 Quorum 丢失检测（哈哈）或状态处理（如果我删除磁盘，它不会被标记为不可用。它甚至不会有该死的状态栏）

回复：稳定性 移动... 为什么是

pvmove 数据丢失

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

回复：快照 CoW 的执行方式并不安全，因为它会将新数据更新到快照 LV 区域，然后在删除快照后再合并回来。这意味着在将新数据最终合并回原始 LV 时，会出现严重的 IO 峰值，更重要的是，当然，数据损坏的风险也会更高，因为一旦遇到瓶颈，损坏的不是快照，而是原始数据。

其优势在于性能，只需执行 1 次写入，而不是 3 次。选择快速但不安全的算法显然是人们期望 VMware 和 MS 等人在“Unix”上做的事情，我宁愿猜测事情会“正确完成”。只要我在快照备份存储在不同的磁盘驱动器比主数据（当然还要备份到另一个）

回复：障碍 我不确定是否可以将此归咎于 LVM。据我所知，这是一个 devmapper 问题。但可以归咎于至少从内核 2.6 到 2.6.33 以来，人们并没有真正关心这个问题。据我所知，Xen 是唯一使用 O_DIRECT 来管理虚拟机的虚拟机管理程序，问题曾经出现在使用“循环”时，因为内核仍会使用它进行缓存。Virtualbox 至少有一些设置可以禁用此类内容，而 Qemu/KVM 通常似乎允许缓存。所有 FUSE FS 也都存在问题（没有 O_DIRECT）

回复：尺寸 我认为 LVM 会对显示的大小进行“四舍五入”。或者它使用 GiB。无论如何，您需要使用 VG Pe 大小并将其乘以 LV 的 LE 编号。这应该会给出正确的净大小，而这个问题始终是一个使用问题。如果文件系统在 fsck/mount 期间没有注意到这样的事情（你好，ext3），或者没有可用的在线“fsck -n”（你好，ext3），情况会变得更糟

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

与原始版本相比，LVM2 是“不懂 UNIX 的人注定要重新发明它，而且做得很差”的典型例子。

几个月后的更新：到目前为止，我已经在测试“完整快照”场景。如果它们满了，快照就会阻塞，而不是原始 LV。我第一次发布这篇文章时就错了。我从一些文档中获得了错误的信息，或者也许我理解了它。在我的设置中，我一直非常偏执，不让它们填满，所以我从来没有得到纠正。还可以扩展/缩小快照，这是一种享受。

我仍然无法解决的是如何确定快照的年龄。至于它们的性能，在“thinp” Fedora 项目页面上有一条注释，其中说快照技术正在修订，以便它们不会随着每次快照而变慢。我不知道他们是如何实现的。

Answer

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

嗯，只是有这种分离因为某种原因- 差异表现在 PV 丢失处理和在线重新激活缺少 PV 的 VG 以使其重新发挥作用 - “原始 LVM”（AIX、HP-UX）上的轻而易举的事情在 LVM2 上变成了垃圾，因为状态处理不够好。甚至不要让我谈论 Quorum 丢失检测（哈哈）或状态处理（如果我删除磁盘，它不会被标记为不可用。它甚至不会有该死的状态栏）

回复：稳定性 移动... 为什么是

pvmove 数据丢失

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

回复：快照 CoW 的执行方式并不安全，因为它会将新数据更新到快照 LV 区域，然后在删除快照后再合并回来。这意味着在将新数据最终合并回原始 LV 时，会出现严重的 IO 峰值，更重要的是，当然，数据损坏的风险也会更高，因为一旦遇到瓶颈，损坏的不是快照，而是原始数据。

其优势在于性能，只需执行 1 次写入，而不是 3 次。选择快速但不安全的算法显然是人们期望 VMware 和 MS 等人在“Unix”上做的事情，我宁愿猜测事情会“正确完成”。只要我在快照备份存储在不同的磁盘驱动器比主数据（当然还要备份到另一个）

回复：障碍 我不确定是否可以将此归咎于 LVM。据我所知，这是一个 devmapper 问题。但可以归咎于至少从内核 2.6 到 2.6.33 以来，人们并没有真正关心这个问题。据我所知，Xen 是唯一使用 O_DIRECT 来管理虚拟机的虚拟机管理程序，问题曾经出现在使用“循环”时，因为内核仍会使用它进行缓存。Virtualbox 至少有一些设置可以禁用此类内容，而 Qemu/KVM 通常似乎允许缓存。所有 FUSE FS 也都存在问题（没有 O_DIRECT）

回复：尺寸 我认为 LVM 会对显示的大小进行“四舍五入”。或者它使用 GiB。无论如何，您需要使用 VG Pe 大小并将其乘以 LV 的 LE 编号。这应该会给出正确的净大小，而这个问题始终是一个使用问题。如果文件系统在 fsck/mount 期间没有注意到这样的事情（你好，ext3），或者没有可用的在线“fsck -n”（你好，ext3），情况会变得更糟

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

与原始版本相比，LVM2 是“不懂 UNIX 的人注定要重新发明它，而且做得很差”的典型例子。

几个月后的更新：到目前为止，我已经在测试“完整快照”场景。如果它们满了，快照就会阻塞，而不是原始 LV。我第一次发布这篇文章时就错了。我从一些文档中获得了错误的信息，或者也许我理解了它。在我的设置中，我一直非常偏执，不让它们填满，所以我从来没有得到纠正。还可以扩展/缩小快照，这是一种享受。

我仍然无法解决的是如何确定快照的年龄。至于它们的性能，在“thinp” Fedora 项目页面上有一条注释，其中说快照技术正在修订，以便它们不会随着每次快照而变慢。我不知道他们是如何实现的。

Question 4

亚当，

另一个优点是：您可以添加新的物理卷 (PV)，将所有数据移至该 PV，然后删除旧 PV，而无需任何服务中断。在过去五年中，我至少使用过四次该功能。

我还没有看到一个缺点被明确指出：LVM2 的学习曲线相当陡峭。主要是因为它在你的文件和底层媒体之间创建了抽象。如果你只和几个人一起工作，他们在一组服务器上分担杂务，你可能会发现额外的复杂性对整个团队来说都是难以承受的。专注于 IT 工作的大型团队通常不会有这样的问题。

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

需要特别指出的是：如果您从 LVM2 逻辑卷启动，则在服务器崩溃时很难找到恢复操作。Knoppix 和朋友并不总是有合适的东西。因此，我们决定将 /boot 目录放在它自己的分区上，并且始终保持小巧和原生。

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

Answer

亚当，

另一个优点是：您可以添加新的物理卷 (PV)，将所有数据移至该 PV，然后删除旧 PV，而无需任何服务中断。在过去五年中，我至少使用过四次该功能。

我还没有看到一个缺点被明确指出：LVM2 的学习曲线相当陡峭。主要是因为它在你的文件和底层媒体之间创建了抽象。如果你只和几个人一起工作，他们在一组服务器上分担杂务，你可能会发现额外的复杂性对整个团队来说都是难以承受的。专注于 IT 工作的大型团队通常不会有这样的问题。

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

需要特别指出的是：如果您从 LVM2 逻辑卷启动，则在服务器崩溃时很难找到恢复操作。Knoppix 和朋友并不总是有合适的东西。因此，我们决定将 /boot 目录放在它自己的分区上，并且始终保持小巧和原生。

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

LVM 的危险和注意事项

答案1

答案2

答案3

答案4

相关内容