LVM的危险和警告

#1 楼

总结
使用LVM的风险：

由于磁盘结构更复杂，更容易编写SSD或VM虚拟机管理程序的缓存问题
更难恢复数据
正确调整文件系统大小
鉴于这些问题，快照难于使用，速度慢且有错误
需要一些技能来正确配置

前两个LVM问题结合在一起：如果写缓存不是正常工作，并且断电（例如PSU或UPS故障），则很可能必须从备份中恢复，这意味着大量的停机时间。使用LVM的主要原因是正常运行时间较长（添加磁盘，调整文件系统大小等），但是正确设置写缓存设置以避免LVM实际减少正常运行时间很重要。
-更新于2019年12月：对LVM进行了小幅更新btrfs和ZFS可以替代LVM快照
减轻风险
如果满足以下条件，LVM仍然可以正常工作：

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

详细信息
我过去已经对此进行了很多研究，与LVM相关的数据丢失。我知道的主要LVM风险和问题是：
由于VM虚拟机管理程序，磁盘缓存或旧的Linux内核而易受硬盘写入缓存的影响，并且由于磁盘结构更加复杂，使得恢复数据更加困难-有关详情，请参见下文。我已经看到几个磁盘上的完整LVM设置被破坏，没有恢复的机会，并且LVM和硬盘写缓存是一种危险的组合。


写缓存并通过写重新排序硬盘驱动器对提高性能很重要，但由于VM虚拟机管理程序，硬盘驱动器写缓存，旧的Linux内核等原因，可能无法正确将块刷新到磁盘。

写屏障是指内核保证在“屏障”磁盘写入之前完成某些磁盘写操作，以确保在突然断电或崩溃时文件系统和RAID可以恢复。这样的屏障可以使用FUA（强制单元访问）操作立即将某些块写入磁盘，这比完全缓存刷新效率更高。可以将障碍与有效的标记/本机命令排队（一次发出多个磁盘I / O请求）结合使用，以使硬盘驱动器能够执行智能的写重新排序，而不会增加数据丢失的风险。

VM虚拟机管理程序可能会遇到类似的问题：在Linux虚拟机管理程序（例如VMware，Xen，KVM，Hyper-V或VirtualBox）上运行Linux虚拟机中的LVM会由于写入缓存和重新写入而在没有写入障碍的情况下与内核产生类似的问题。订购。仔细检查系统管理程序文档中的“刷新到磁盘”或直写式缓存选项（在KVM，VMware，Xen，VirtualBox和其他版本中提供）-并使用您的设置对其进行测试。某些虚拟机管理程序（例如VirtualBox）具有默认设置，该默认设置会忽略来自来宾的所有磁盘刷新。控制器具有电池备份的写缓存，该缓存是快速且安全的）-请参阅此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故障，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配合使用的内核写障碍（通过在Linux中查找“障碍”消息来进行双重检查）
，还应确保RAID设置，VM虚拟机管理程序设置和文件系统使用写屏障（即要求驱动器在关键元数据/日志写之前和之后刷新挂起的写操作）。 XFS默认情况下确实使用屏障，但是ext3则不使用，因此，对于ext3，您应该在安装选项中使用barrier=1，并且仍然如上所述使用data=ordered或data=journal。

不幸的是，一些硬盘驱动器和SSD取决于它们是否确实将其缓存刷新到磁盘上（特别是较旧的驱动器，但包括一些SATA驱动器和一些企业级SSD）-在此处有更多详细信息。 XFS开发人员提供了一个很棒的摘要。该答案涵盖了类似的SATA驱动器测试，该测试发现了软件RAID中的写障碍问题-这些测试实际上覆盖了整个存储堆栈。也许由于NCQ而没有写缓存，它们的性能很好，而且很少有驱动器无法禁用写缓存。
SCSI / SAS驱动器通常还可以，因为它们不需要写缓存就能很好地运行（通过SCSI标记命令队列，类似SATA的NCQ）。
如果您的硬盘驱动器或SSD确实是要将其缓存刷新到磁盘上，那么您真的不能依靠写障碍，而必须禁用写缓存。这是所有文件系统，数据库，卷管理器和软件RAID的问题，而不仅仅是LVM。

SSD是有问题的，因为使用写缓存对于SSD的生命周期至关重要。最好使用具有超级电容器的SSD（以在电源故障时启用缓存刷新，从而使缓存能够回写而不是直写）。

大多数企业SSD在写入时都应该可以缓存控制，其中一些包含超级电容器。
一些便宜的SSD存在无法通过写入缓存配置解决的问题-PostgreSQL项目的邮件列表和“可靠写入” Wiki页面是很好的信息来源。消费类SSD可能存在严重的写缓存问题，这将导致数据丢失，并且不包含超级电容器，因此容易出现电源故障而导致损坏的情况。高级格式驱动器设置-写入缓存，对齐，RAID，GPT

对于使用4个KiB物理扇区的较新的高级格式驱动器，保持驱动器写缓存处于启用状态可能很重要，因为当前大多数此类驱动器都在仿真512字节的逻辑扇区（“ 512仿真”），甚至有人声称实际上使用4 KiB时具有512字节的物理扇区。
如果出现以下情况，关闭高级格式驱动器的写缓存可能会对性能造成很大影响应用程序/内核正在执行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扇区的磁盘时出现部分块写入的问题。请特别注意引导+根磁盘，以确保第一个LVM分区（PV）在4 KiB边界上启动。

由于磁盘结构更加复杂，更难于恢复数据：

在硬崩溃或断电（由于不正确的写缓存）之后恢复LVM数据所需的任何操作充其量都是最好的，因为显然没有合适的工具。 LVM擅长在/etc/lvm下备份其元数据，这可以帮助恢复LV，VG和PV的基本结构，但不会帮助丢失文件系统元数据。
因此，可能需要从备份中完全还原。与不使用LVM时基于快速日志的fsck相比，这涉及更多的停机时间，并且自上次备份以来写入的数据将丢失。

TestDisk，ext3grep，ext3undel和其他工具可以恢复分区和文件从非LVM磁盘中提取数据，但它们不直接支持LVM数据恢复。 TestDisk可以发现丢失的物理分区包含LVM PV，但是这些工具都无法理解LVM逻辑卷。文件雕刻工具（例如PhotoRec等）可以绕过文件系统从数据块中重新组装文件，因此它们可以工作，但这是对有价值的数据的最后一种低级方法，对碎片文件的效果不佳。 br />在某些情况下，可以进行手动LVM恢复，但是它很复杂且耗时-请参见此示例，此，此内容以及有关如何恢复的信息。

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


更新：lvextend的最新版本支持-r（--resizefs）选项-如果可用，这是一种更安全，更快捷的方式调整LV和文件系统的大小，尤其是在缩小FS的情况下，通常可以跳过本节。


调整基于LVM的FS大小的大多数指南都没有考虑到FS必须比LV的大小小一点的事实：此处有详细说明。缩小文件系统时，您需要为FS调整大小工具指定新的大小，例如ext3的resize2fs以及lvextend或lvreduce。如果不小心，大小可能会因1 GB（10 ^ 9）和1 GiB（2 ^ 30）之间的差异或各种工具向上或向下舍入大小的方式而略有不同。


如果您不完全正确地进行计算（或者使用了一些最不明显的步骤之外的其他步骤），则最终可能会得到对于LV而言太大的FS。几个月或几年之后，一切似乎都会好起来，直到完全填满FS，这时您将遭到严重破坏-除非您知道此问题，否则很难找出原因，因为届时您可能还会遇到实际的磁盘错误那使情况蒙上阴影。 （此问题可能仅影响减小文件系统的大小-但是，很明显，在两个方向上调整文件系统的大小都会增加数据丢失的风险，这可能是由于用户错误引起的。）


看来LV大小应该比FS大小大2倍于LVM物理范围（PE）大小-但请查看上面的链接以获取详细信息，因为这样做的来源并不权威。通常允许8 MiB就足够了，但最好允许更多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是安全的，因为快照将永远不会耗尽可用空间。
快照也可能非常慢（这意味着与没有LVM相比，快照速度要慢3到6倍）这些MySQL测试）-请参阅有关各种快照问题的答案。之所以变慢，部分原因是快照需要大量同步写入。
快照存在一些重大错误，例如在某些情况下，它们会使启动速度非常慢，或导致启动完全失败（因为当内核为LVM快照时内核可能会等待根FS超时[已在Debian initramfs-tools更新，2015年3月修复]。）

但是，许多快照争用条件的错误显然已在2015年修复。
没有快照的LVM似乎调试得很好，也许是因为快照的使用不如核心功能。

快照替代方案-文件系统和VM虚拟机管理程序
VM /云快照：

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

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


ZFS：现在已经有一个内核ZFS实现，该实现已经使用了很多年，并且ZFS似乎正在被采用。 Ubuntu现在将ZFS作为“开箱即用”的选项，包括在19.10根目录上的实验性ZFS。默认值，并有专门负责btrfs的团队），而RHEL已停止支持它）。 btrfs现在具有fsck工具（FAQ），但是如果您需要fsck损坏的文件系统，则FAQ建议您咨询开发人员。


用于在线备份和fsck的快照
快照可用于提供一致的备份源，只要您小心分配的空间即可（理想情况下，快照的大小与要备份的LV的大小相同）。出色的rsnapshot（自1.3.1版本开始）甚至可以为您管理LVM快照的创建/删除-有关使用LVM的rsnapshot的信息，请参见本HOWTO。但是，请注意快照的一般性问题，并且快照本身不应被视为备份。
您还可以使用LVM快照进行联机fsck：在仍使用主快照的同时，对LV和fsck快照进行快照。非快照FS-在此进行说明-但是，它并不完全简单，因此最好使用ext3的维护者Ted Ts'o所述的e2croncheck。 LVM创建快照时，诸如ext3和XFS之类的文件系统将自动执行此操作。
结论
尽管如此，我仍然在某些系统上使用LVM，但是对于桌面安装程序，我更喜欢原始分区。我可以从LVM中看到的主要好处是，当必须在服务器上具有较高的正常运行时间时，可以灵活地移动和调整FS的大小-如果不需要，gparted会更容易并且数据丢失的风险也较小。由于VM虚拟机管理程序，硬盘驱动器/ SSD写入缓存等原因，在写入缓存设置方面需要格外小心-但是将Linux用作数据库服务器时也是如此。大多数工具缺乏支持（包括临界大小计算的gparted和testdisk等），使其难以使用。
如果使用LVM，请特别注意快照：如果可能，请使用VM /云快照或研究ZFS / btrfs以完全避免LVM-与带快照的LVM相比，您可能会发现ZFS或btrfs已经足够成熟。
底线：如果您不了解上述问题以及如何解决这些问题，最好不要使用LVM。

#2 楼

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

出现这种分离是有原因的-差异体现在PV损失处理上，以及在线重新激活带有丢失的PV的VG以使它们重新发挥作用-“原始LVM”轻而易举（AIX，HP-UX ）由于状态处理不够好而在LVM2上变成废话。
甚至不要让我谈论仲裁丢失检测（haha）或状态处理（如果删除磁盘，则不会被标记甚至没有该死的状态列）

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


pvmove数据丢失


我的博客上最热门的文章hmmm？
现在，我看一个磁盘，从pvmove中期开始，physscal lvm数据仍挂在该磁盘上。
我想有些记忆，而基因真正的想法是，从用户空间复制活动块数据是一件好事。
lvm列表中的引号很好，“好像vgreduce --missing无法处理pvmove”
实际上是指磁盘在pvmove期间分离，然后lvm管理工具从lvm更改为vi。
哦，还有一个bug，pvmove在块读取/写入错误后继续运行，实际上不再将数据写入目标设备。 WTF？

回复：快照
通过将新数据更新到快照lv区域中，然后在删除快照后合并回去，即可安全地完成CoW。这意味着在将新数据最终合并回原始LV的过程中，您会有大量的IO尖峰，更重要的是，您当然也有更高的数据损坏风险，因为一旦您击中了快照，快照就不会被破坏

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

关于：障碍
我不确定是否可以将其归咎于LVM。据我所知，这是一个开发人员问题。
但至少从内核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”（您好，ext3）

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

与原始LVM2相比，LVM2是一个典型的例子，“那些不了解UNIX的人应该被谴责，这很糟糕。”现在进行测试的方案。如果已满，快照将阻塞，而不是原始LV。当我第一次发布此消息时，我错了。我从某些文档中获取了错误的信息，或者我已经理解了。在我的设置中，我总是非常偏执，不让它们填满，所以我从未纠正过。还可以扩展/缩小快照，这是一种享受。

我仍然无法解决的是如何确定快照的年龄。
关于它们的性能，有在“ thinp” fedora项目页面上的一条注释，其中指出正在对快照技术进行修改，以使每次快照都不会变得太慢。
我不知道他们如何实现它。

#3 楼

如果计划使用快照进行备份-准备好存在快照时的主要性能。否则一切都很好。我已经在数十台服务器上的生产环境中使用了lvm几年了，尽管我使用它的主要原因是原子快照无法轻松扩展卷。
顺便说一句，如果您要使用1TB驱动器，请记住有关分区对齐的信息-该驱动器很可能具有4kB的物理扇区。

#4 楼

尽管在10年前就提供了有关LVM状态的有趣窗口，但现在公认的答案已经完全过时了。现代版本（即：2012年后的LVM）：

可以同步/屏蔽请求
具有lvmthin形式的快速可靠的快照功能

具有稳定的SSD缓存通过lvmcache以及通过dm-writecache为NVMe / NVDIMM / Optane提供的快速写回策略

虚拟数据优化器（vdo）支持lvmvdo

自动对齐到1MB或4MB（取决于版本），完全避免了任何4K对齐问题（除非在未对齐的分区上使用LVM）
出色的支持来扩展卷，尤其是在执行卷操作时它添加了其他块设备（在普通分区顶部使用经典文件系统作为ext4 / xfs时根本不可能实现）
lvmraid上的一个出色，友好且非常有用的邮件列表


显然，这并不意味着您总是必须使用LVM-存储的黄金法则是避免不必要的层。例如，对于简单的虚拟机，您肯定可以仅使用经典分区。但是，如果您重视上述任何功能，那么LVM是一个非常有用的工具，应该在任何认真的Linux sysadmin的工具箱中都可以使用。

#5 楼

亚当，

的另一个优点：您可以添加一个新的物理卷（PV），将所有数据移至该PV，然后删除旧的PV，而不会造成服务中断。在过去的五年中，我至少使用了四次该功能。

我还没有清楚指出一个缺点：LVM2的学习曲线有些陡峭。通常在抽象中，它在文件和基础媒体之间创建。如果只与几个人共享一组服务器上的琐事，则可能会发现整个团队难以承受的额外复杂性。专门从事IT工作的大型团队通常不会遇到这样的问题。例如，在我们的工作中，我们在这里广泛使用它，并花了一些时间向整个团队教授基础知识，语言和技巧。有关恢复无法正常启动的系统的基本知识。 Knoppix和朋友并不总是拥有合适的东西。因此，我们决定将/ boot目录放在其自己的分区上，并且始终很小且本机。

总体而言，我是LVM2的粉丝。

#6 楼

几件事情：

跨多个PV跨LV

我看到人们提倡（StackExchange等）横向扩展虚拟机空间：通过向VG添加其他PV来增加空间与增加单个PV。这很丑陋，并将您的文件系统分布在多个PV上，从而对越来越长的PV链产生了依赖性。如果横向扩展VM的存储，则文件系统将如下所示：



如果PV丢失了一部分LV的一部分，PV丢失了数据

对此我感到很多困惑。如果线性LV和其中的文件系统跨多个PV，会发生FULL或PARTAL数据丢失的情况？答案如下：



从逻辑上讲，这是我们应该期望的。如果保存我们LV数据的范围分散到多个PV中，并且其中一个PV消失了，则该LV中的文件系统将遭受灾难性的破坏。

希望这些小涂鸦使复杂的主题更容易理解使用LVM时的风险