LVM的危险和警告

概要

使用LVM的风险：

• 很难用SSD或VMpipe理程序编写caching问题
• 由于更复杂的磁盘结构，难以恢复数据
• 难以正确调整文件系统的大小
• 快照很难使用，缓慢和越野车
• 考虑到这些问题，需要一些技巧才能正确configuration

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

– 2017年9月更新：使旧的内核材料不那么突出

减轻风险

如果您：

• 在虚拟机pipe理程序，内核和SSD中正确使用写入caching设置
• 避免LVM快照
• 使用最近的LVM版本来调整文件系统的大小
• 有好的备份

细节

在过去，我经历了一些与LVM相关的数据丢失的研究。 我所知道的主要LVM风险和问题是：

由于虚拟机pipe理程序，磁盘caching或旧的Linux内核 ， 易受硬盘写入caching的影响 ，并且由于更复杂的磁盘结构而使恢复数据变得更加困难 – 详情请参阅下文。 我已经看到几个磁盘上的完整LVM设置被破坏，没有任何恢复的机会，LVM加硬盘写入caching是一个危险的组合。

• 由于虚拟机pipe理程序，硬盘驱动器写入caching，旧的Linux内核等，硬盘写入caching和写入重新sorting对于良好的性能非常重要，但是可能无法正确地将块刷新到磁盘。
  • 写入障碍意味着内核保证它会在“屏障”磁盘写入之前完成某些磁盘写入操作，以确保文件系统和RAID能够在突然断电或崩溃的情况下恢复。 这些障碍可以使用FUA操作立即将某些块写入磁盘，这比完全caching刷新更有效。 障碍可以与有效的标记 / 本地命令排队（一次发出多个磁盘I / O请求）相结合，使硬盘驱动器能够执行智能写入重新sorting而不会增加数据丢失的风险。
• VMpipe理程序可能会遇到类似的问题：由于写入caching和写入操作，在VM虚拟机pipe理程序（如VMware， Xen ，KVM，Hyper-V或VirtualBox）之上的Linux客户机上运行LVM可能会给内核创build类似的问题 -ordering。 请仔细检查您的虚拟机pipe理程序文档，以获取“刷新到磁盘”或直写式高速caching选项（存在于KVM ， VMware ， Xen ， VirtualBox等中），然后使用您的设置对其进行testing。 一些虚拟机pipe理程序（如VirtualBox） 的默认设置会忽略来宾的任何磁盘刷新。
• 具有LVM的企业服务器应始终使用电池支持的RAID控制器并禁用硬盘写入caching（控制器具有电池支持的写入caching，该caching是快速且安全的） – 请参阅此XFS FAQ条目作者的评论 。 在内核中closures写入屏障也是安全的，但build议进行testing。
• 如果您没有电池支持的RAID控制器，禁用硬盘写入caching将显着减慢写入速度，但会使LVM安全。 您还应该使用ext3的data=ordered选项（或data=journal以获得额外的安全性），以及barrier=1以确保内核caching不会影响完整性。 （或者使用默认启用屏障的 ext4）。这是最简单的select，并且以性能为代价提供了良好的数据完整性。 （Linux 将默认的ext3选项更改为更危险的data=writeback ，因此不要依赖于FS的默认设置。）
• 要禁用硬盘写入caching ：为/etc/rc.local （对于SATA）中的所有驱动器添加hdparm -q -W0 /dev/sdX sdX，或使用SCSI / SAS的sdparm。 但是，根据XFS常见问题解答中的这个条目 （这个问题非常好），在驱动器出错恢复后，SATA驱动器可能会忘记这个设置 – 所以您应该使用SCSI / SAS，或者如果您必须使用SATA， hdparm命令在每分钟左右运行一个cron作业。
• 为了保持SSD /硬盘驱动器写入caching以获得更好的性能：这是一个复杂的领域 – 请参阅下面的部分。
• 如果您正在使用高级格式化驱动器，即4 KB物理扇区，请参阅下文 – 禁用写入caching可能有其他问题。
• UPS对企业和SOHO都至关重要，但不足以使LVM安全：任何导致硬件崩溃或电力损失的事件（例如，UPS故障，PSU故障或笔记本电脑电池耗尽）都可能会丢失硬盘caching中的数据。
• 非常古老的Linux内核（从2009年的2.6.x） ：在很早的内核版本2.6.32和更早的版本中（ 2.6.31有一些支持 ，而2.6.33适用于所有types的设备目标） RHEL 6使用2.6.32和许多补丁。 如果这些旧版本的2.6内核没有针对这些问题进行修补，那么硬盘崩溃会导致大量的FS元数据（包括日志）丢失，导致硬盘的写入缓冲区（比如普通SATA驱动器每个驱动器需要32 MB）。 丢失最近写入的FS元数据和日志数据（内核认为已经在磁盘上）的32MB通常意味着大量的FS损坏，从而导致数据丢失。
• 简介：您必须注意LVM使用的文件系统，RAID，VMpipe理程序和硬盘驱动器/ SSD设置。 如果您使用的是LVM，则必须具有非常好的备份，并且确保专门备份LVM元数据，物理分区设置，MBR和卷引导扇区。 使用SCSI / SAS驱动器也是明智之举，因为这些驱动器不太可能存在写入caching的方式 – 使用SATA驱动器需要更多的关注。

保持写caching启用性能（和处理撒谎的驱动器）

一个更复杂但性能最好的select是保持SSD /硬盘驱动器写入caching启用，并依靠内核2.6.33+上的内核写入障碍与LVM一起工作（通过在日志中查找“barrier”消息进行检查）。

您还应该确保RAID设置，虚拟机pipe理程序设置和文件系统使用写入屏障 （即要求驱动器在关键元数据/日志写入之前和之后刷新挂起写入）。 XFS在默认情况下会使用屏障，但是ext3不会 ，所以在ext3中，您应该在挂载选项中使用barrier=1 ，并仍然使用data=ordered或data=journal 。

• 不幸的是，一些硬盘和固态盘的谎言是否真的把自己的caching刷到了磁盘上（特别是老式的硬盘，但包括一些SATA硬盘和一些企业SSD ） – 更多细节在这里 。 XFS开发者有一个很好的总结 。
• 有一个简单的testing工具，用于说谎驱动器 （Perl脚本），或者通过另一个testing驱动器caching的写入重新sorting的工具来查看这个背景 。 这个答案涵盖了SATA驱动器的类似testing ，它揭示了软件RAID中的写入障碍问题 – 这些testing实际上是对整个存储堆栈进行的。
• 支持本地命令队列 （NCQ）的更新的SATA驱动器可能不太可能存在 – 或者由于NCQ的原因，没有写入caching可能会执行得很好，而且很less有驱动器不能禁用写入caching。
• SCSI / SAS驱动器通常是可以的，因为它们不需要写caching就可以很好地执行（通过SCSI 标记命令排队 ，类似于SATA的NCQ）。
• 如果你的硬盘或者固态硬盘确实把自己的高速caching清理到磁盘上了，那么你真的不能依赖写入的障碍，并且必须禁止写入高速caching。 这对于所有文件系统，数据库，卷pipe理器和软件RAID来说都是一个问题，而不仅仅是LVM。

固态硬盘是有问题的，因为使用写入高速caching对固态硬盘的使用寿命至关重要。 最好使用具有超级电容器的SSD（在电源故障时启用高速caching刷新，从而使高速caching不被写回）。

• 写入caching控制大多数企业SSD应该是可以的，其中一些包括超级电容器。
• 一些更便宜的固态硬盘有写入cachingconfiguration无法修复的问题 – PostgreSQL项目的邮件列表和Reliable Writes维基页面是很好的信息来源。 消费类固态硬盘可能会有重大的写入caching问题 ，这将导致数据丢失，并且不包括超级电容器，因此易受电源故障导致腐败。

高级格式驱动器设置 – 写入caching，alignment，RAID，GPT

• 对于使用4 KiB物理扇区的更新的高级格式化驱动器 ，启用驱动器写入caching可能很重要，因为大多数此类驱动器当前模拟512字节的逻辑扇区（ “512仿真” ），有些甚至声称具有512字节的物理而真正使用4 KiB。
• 如果应用程序/内核正在执行512字节的写操作，则closures高级格式化驱动器的写caching可能会造成非常大的性能影响，因为这样的驱动器在执行单个4 KiB物理之前依靠caching来累积8 x 512字节的写入写。 如果禁用caching，则build议进行testing以确认是否有任何影响。
• alignment4 KiB边界上的LV对于性能很重要，但是只要PV的底层分区alignment，就会自动发生，因为默认情况下，LVM Physical Extents（PE）是4 MiB。 此处必须考虑RAID – 此LVM和软件RAID设置页面build议将RAID超级块放在卷的末尾，（如有必要）使用pvcreate上的选项来alignmentPV。 此LVM电子邮件列表线程指向2011年在内核中完成的工作，以及在单个LV中混合具有512字节和4个KiB扇区的磁盘时发生的部分块写入问题。
• 使用高级格式的GPT分区需要注意，特别是对于引导+根磁盘，以确保第一个LVM分区（PV）在4个KiB边界上启动。

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

• 在发生硬件崩溃或断电（由于不正确的写入caching）之后，所需的任何LVM数据恢复都是手动过程，因为显然没有合适的工具。 LVM善于在/etc/lvm下备份元数据，这有助于恢复LV，VG和PV的基本结构，但不会帮助丢失文件系统元数据。
• 因此可能需要从备份中完全恢复。 与不使用LVM时快速logging的fsck相比，这会导致更多的停机时间，而自上次备份以来写入的数据将会丢失。
• TestDisk ， ext3grep ， ext3undel和其他工具可以从非LVM磁盘恢复分区和文件，但不直接支持LVM数据恢复。 TestDisk可以发现丢失的物理分区包含LVM PV，但这些工具都不了解LVM逻辑卷。 PhotoRec等文件雕刻工具可以绕过文件系统重新汇编数据块中的文件，但是这对于有价值的数据来说是最后的一种低级别的方法，并且对碎片文件的处理效果不佳。
• 手动LVM恢复在某些情况下是可行的，但是复杂且耗时 – 请参阅此示例和这个 ，以及这个如何恢复。

很难正确调整文件系统的大小 – 简单的文件系统resize通常是LVM的一个好处，但是您需要运行6个shell命令来调整基于LVM的FS的大小 – 这可以在整个服务器仍然运行的情况下完成，在某些情况下与FS安装，但我永远不会冒险后者没有最新的备份和使用命令预先testing在一个等效的服务器（例如生产服务器的灾难恢复克隆）。

• 更新： lvextend 更新版本支持-r （– --resizefs ）选项 – 如果这是可用的，那么调整LV和文件系统的大小更安全，更快捷，特别是在缩小FS时，本节。
• 调整基于LVM的FS的大多数指南都没有考虑到FS必须小于LV的大小： 这里有详细的解释 。 缩小文件系统时，您需要为FS大小调整工具指定新的大小，例如resize2fs用于ext3，以及用于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所需的大小，然后它将为您做所有事情。 在服务器上，您可以使用从shell parted 。

  • 通常最好使用Gparted Live CD或Parted Magic ，因为这些版本比发行版有更近的缺陷，更多的缺陷Gparted和内核 – 由于发行版的Gparted在运行中没有正确更新分区，我曾经丢失了整个FS核心。 如果使用发行版的Gparted，请务必在更改分区后重新启动，以便内核视图正确。

快照难以使用，速度慢，错误 – 如果快照耗尽预分配的空间，它将自动丢弃 。 给定LV的每个快照是针对该LV的增量（而不是针对之前的快照），这在快照具有显着写入活动的文件系统时可能需要大量空间。 创build与原始LV大小相同的快照LV是安全的，因为快照永远不会耗尽可用空间。

快照也可能非常慢（意味着这些MySQLtesting比无LVM的速度慢3到6倍） – 请参阅此答案，其中包含各种快照问题 。 速度的缓慢部分是因为快照需要许多同步写入 。

快照有一些重大的错误，例如， 在某些情况下，它们可能会导致启动速度非常慢，或导致启动失败（因为内核可以超时等待根FS是LVM快照[在Debian initramfs-tools update， 2015]）。

• 一个指标是有很多与“lvm snapshot 2015”匹配的 Debian bug，其中一些非常严重 – 但是，很多快照竞争条件bug显然已经被修复了 。 没有快照的LVM一般似乎debugging得相当好，可能是因为快照的使用不如核心function。

快照备选scheme – 文件系统和虚拟机pipe理程序

VM /云快照：

• 如果您正在使用VMpipe理程序或IaaS云提供程序，则其快照（例如，VMware，VirtualBox或Amazon EC2的EBS快照）通常是LVM快照的更好select。 你可以很容易地将快照用于备份目的（但是在你做之前考虑冻结FS）。

文件系统快照：

• 使用ZFS或btrfs的文件系统级快照易于使用，并且通常比LVM更好，尽pipeLinux上的文件系统都不是非常成熟，但对于真正需要快照而不需要VM /云路由的用户来说，它们可能是更好的select：

  • ZFS：现在有一个内核的ZFS实现 ，已经使用了好几年了，而且要比FUSE上的ZFS快很多。
  • btrfs还没有准备好用于生产，其fsck和修复工具仍在开发中。

在线备份和fsck的快照

只要您仔细分配空间（理想情况下快照与备份的LV大小相同），快照可用于为备份提供一致的源 。 优秀的rsnapshot （自1.3.1以来）甚至为您pipe理LVM快照创build/删除 – 请参阅使用LVM的rsnapshot上的此HOWTO 。 但是，请注意快照的一般问题，并且快照本身不应被视为备份。

您还可以使用LVM快照来执行在线fsck：快照LV和fsck快照，同时仍然使用此处描述的主要非快照FS – 但是，这并不是完全简单，因此最好使用Ted Ts所述的 e2croncheck 'o ，ext3的维护者。

在拍摄快照时，您应该临时“冻结”文件系统 – 当LVM创build快照时，一些文件系统（如ext3和XFS）会自动执行此操作 。

结论

尽pipe如此，我仍然在一些系统上使用LVM，但是对于桌面设置，我更喜欢裸分区。 我可以从LVM中看到的主要好处是， 当您必须在服务器上具有较高的正常运行时间时，可以灵活地移动和调整FS的大小 – 如果您不需要，可以更轻松地减less数据丢失的风险。

由于虚拟机pipe理程序，硬盘驱动器/ SSD写入caching等因素，LVM需要非常小心地进行写入caching设置，但是同样适用于将Linux用作数据库服务器。 缺乏大多数工具（包括临界尺寸计算和testdisk等）的支持使得使用比应该更难。

如果使用LVM，则需要格外小心：如果可能，请使用VM /云快照，或者调查ZFS / btrfs以完全避免LVM – 您可能会发现ZFS或btrs与具有快照的LVM相比已经足够成熟。

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

我[+1]这个post，至less对我来说，我认为大多数问题确实存在。 在运行几百台服务器和几百个100TB的数据的时候看到它们。 对我来说，Linux中的LVM2就像是某个人的“聪明主意”。 就像其中的一些，他们有时会变得“不聪明”。 即没有严格分离内核和用户空间（lvmtab）状态可能感觉真的很聪明，因为可能存在腐败问题（如果你没有得到正确的代码）

那么，这种分离是出于某种原因 – 差异performance为光伏损失处理，以及在线重新激活VG（即缺lessPV）以使其重新起作用 – “原始LVM”（AIX ，HP-UX）在LVM2上变成垃圾，因为状态处理不够好。 甚至没有让我谈论法定人数损失检测（哈哈）或状态处理（如果我删除一个磁盘，不会被标记为不可用，它甚至没有该死的状态栏）

回复：稳定 pvmove …为什么

pvmove数据丢失

这样的博客上的排名最高的文章，嗯？ 刚才我看了一个磁盘，在这个磁盘里，phymotion lvm的数据还是从中间挂在了状态。 我觉得有一些memleaks，一般的想法是从用户空间复制活动块数据是一件好事，只是伤心。 从lvm列表的好引用“似乎vgreduce – 发射不处理pvmove”实际上，如果在pvmove期间磁盘分离，则lvmpipe理工具从lvm更改为vi。 哦，还有一个错误，在块读取/写入错误后，pvmove会继续执行，并且实际上不再将数据写入目标设备。 WTF？

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

优点是在性能上，做1写，而不是3。select快速但不安全的algorithm是一个明显期望像VMware和MS这样的人，在“Unix”上，我宁愿猜测事情会“做对”。 只要将快照备份存储在与主数据不同的磁盘驱动器上，我就没有看到太多的性能问题（当然还有另一个备份）

回复：障碍我不确定是否可以指责LVM。 就我所知，这是一个devmapper问题。 但是至less从内核2.6直到2.6.33，可能会有一些责任没有真正关心这个问题。AFAIK Xen是唯一使用O_DIRECT作为虚拟机的pipe理程序，问题在于使用“loop”时，因为内核仍然会使用该caching。 Virtualbox至less有一些设置来禁用像这样的东西，Qemu / KVM通常似乎允许caching。 所有的FUSE FS也有问题（没有O_DIRECT）

Re：大小我认为LVM会对显示的大小进行“四舍五入”。 或者它使用GiB。 无论如何，您需要使用VG Pe尺寸，并将其乘以LV的LE编号。 这应该给正确的networking大小，这个问题总是一个使用问题。 在fsck / mount（hello，ext3）或没有在线工作的fsck -n（hello，ext3）文件系统中，

当然，这是说，你不能find这样的信息的好来源。 “VRA有多lessLE？” “什么是PVRA，VGDA，等等的金额抵消”

与原来的LVM2相比，“那些不懂UNIX的人被谴责重塑它，糟糕透顶”。

几个月后更新：到目前为止，我一直在进行“完整快照”场景的testing。 如果他们满了，快照块，而不是原来的LV。 当我第一次发布这个时，我错了。 我从一些文件中find了错误的信息，或者我已经理解了它。 在我的设置中，我总是非常偏执，不让他们填满，所以我从来没有结束纠正。 也可以扩展/缩小快照，这是一种享受。

我仍然无法解决的是如何确定快照的年龄。 至于他们的performance，有一个关于“thinp”fedora项目页面的说明，说快照技术正在被修改，以便每个快照都不会变慢。 我不知道他们是如何实施的。

如果您计划使用快照进行备份，请在快照存在时做好主要性能的准备。 在这里阅读更多。 否则这一切都很好。 我已经在几十台服务器上使用lvm进行了几年的生产，虽然我使用它的主要原因是primefaces快照不能轻松扩展卷。

顺便说一句，如果你要使用1TB的驱动器，记住分区alignment – 这个驱动器最有可能有4kB物理扇区。

亚当，

另一个优点是：您可以添加新的物理卷（PV），将所有数据移动到该PV，然后在没有任何服务中断的情况下移除旧的PV。 我在过去的五年里至less使用了四次这个function。

我还没有明确指出的一个缺点：LVM2的学习曲线有些陡峭。 大多数情况下，它会在文件和底层媒体之间创build抽象。 如果你只与一些在一组服务器上分担家务的人一起工作，那么你可能会发现整个团队的额外复杂性。 致力于IT工作的大型团队通常不会有这样的问题。

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

要特别注意的一点是：如果从LVM2逻辑卷启动，则发现服务器崩溃时，恢复操作很困难。 Knoppix和朋友并不总是有正确的东西。 所以，我们决定我们的/ boot目录是在自己的分区上，并且总是很小而且是原生的。

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