摘要
使用LVM的风险：
- 容易写入SSD或VM虚拟机管理程序的缓存问题
- 由于磁盘结构更为复杂，因此难以恢复数据
- 难以正确调整文件系统的大小
- 快照难以使用，速度慢且容易出错
- 鉴于这些问题，需要一些技巧来正确配置
前两个LVM问题结合在一起：如果写缓存无法正常工作并且断电（例如PSU或UPS故障），则您可能必须从备份中恢复，这意味着大量的停机时间。使用LVM的一个关键原因是正常运行时间较长（添加磁盘，调整文件系统大小等），但是正确设置写入缓存设置对避免LVM实际减少正常运行时间很重要。
-2018年12月更新：更新了快照材料，包括ZFS和btrfs的稳定性作为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 guest虚拟机中运行LVM会由于写入缓存和重新写入而在没有写入障碍的情况下与内核产生类似的问题。 -订购。仔细检查系统管理程序文档中的“刷新到磁盘”或直写式高速缓存选项（存在于KVM，VMware，Xen，VirtualBox等）中-并使用您的设置进行测试。一些虚拟机管理程序（例如VirtualBox）具有默认设置，该默认设置会忽略来自来宾的所有磁盘刷新。
- 具有LVM的企业服务器应始终使用电池供电的RAID控制器并禁用硬盘写缓存（该控制器具有电池供电的写缓存，这是快速且安全的）-请参阅此XFS FAQ条目作者的评论。关闭内核中的写屏障可能也是安全的，但建议进行测试。
- 如果您没有电池供电的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 /硬盘驱动器写缓存保持启用状态，以获得更好的性能：这是一个复杂的区域-请参阅以下部分。
- 如果您使用的是Advanced Format驱动器，即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不会使用bar3，因此对于ext3，您应该barrier=1在mount选项中使用，并且仍然使用data=ordered或data=journal如上所述。
SSD存在问题，因为使用写入缓存对于SSD的生命周期至关重要。最好使用具有超级电容器的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扇区的磁盘时的部分块写入问题。
- 需要特别注意具有Advanced Format的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的大小-这可以在整个服务器仍然运行的情况下完成。在安装了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。要使用4 KiB = 4096字节块检查PE大小以及逻辑卷+ FS大小：
在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从外壳使用。
- 通常最好使用Gparted Live CD或Parted Magic，因为它们的Gparted＆内核比发行版更新，而且经常没有错误-我曾经丢失了整个FS，因为发行版的Gparted在运行中未正确更新分区核心。如果使用发行版的Gparted，请确保在更改分区后立即重新启动，以使内核视图正确。
快照难于使用，速度慢且容易出错 -如果快照用尽了预分配的空间，则会自动将其删除。给定LV的每个快照都是相对于该LV的增量（而不是先前的快照），在对具有大量写入活动的文件系统进行快照（每个快照都大于前一个快照）时，该快照可能需要大量空间。创建与原始LV大小相同的快照LV是安全的，因为快照将永远不会耗尽可用空间。
快照也可能非常慢（对于这些MySQL测试，快照速度比没有LVM慢3到6倍）-请参阅此答案，其中涵盖了各种快照问题。之所以缓慢，部分原因是快照需要许多同步写入。
快照存在一些重大错误，例如，在某些情况下，快照会使启动速度非常慢，或者导致引导完全失败（因为内核 是LVM快照时，内核可能会等待根FS 超时 [已在Debian initramfs-tools更新中修复，2015年3月] ）。
- 但是，许多快照竞态条件错误已在2015年修复。
- 通常，没有快照的LVM似乎调试得很好，可能是因为快照的使用不如核心功能那么多。
快照替代方案 -文件系统和VM虚拟机管理程序
虚拟机/云快照：
- 如果您使用的是VM虚拟机管理程序或IaaS云提供商（例如VMware，VirtualBox或Amazon EC2 / EBS），则它们的快照通常是LVM快照的更好替代方案。您可以很轻松地拍摄快照以用于备份（但请考虑先冻结FS）。
文件系统快照：
用于在线备份和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-与带有快照的LVM相比，您可能会发现ZFS或btrs已经足够成熟。
底线：如果您不知道上面列出的问题以及如何解决这些问题，最好不要使用LVM。