linux – LVM的危险和警告

摘要

使用LVM的风险：

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

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

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

降低风险

如果您：LVM仍然可以正常工作：

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

细节

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

由于VM虚拟机管理程序,磁盘缓存或旧的Linux内核而导致硬盘写入缓存容易受到攻击,并且由于更复杂的磁盘结构而使得恢复数据变得更加困难 – 详见下文.我已经看到几个磁盘上的完整LVM设置被破坏而没有任何恢复机会,LVM加上硬盘写缓存是一个危险的组合.

>通过硬盘驱动器写入缓存和写入重新排序对于良好的性能非常重要,但由于VM管理程序,硬盘驱动器写入缓存,旧Linux内核等原因,无法正确地将块刷新到磁盘.

> Write barriers意味着内核保证在“屏障”磁盘写入之前完成某些磁盘写入,以确保文件系统和RAID可以在突然断电或崩溃时恢复.这样的障碍可以使用FUA (Force Unit Access) operation立即将某些块写入磁盘,这比完全缓存刷新更有效.可以将障碍与高效的tagged/native命令排队(一次发出多个磁盘I / O请求)结合使用,以使硬盘驱动器能够执行智能写入重新排序,而不会增加数据丢失的风险.

> VM虚拟机管理程序可能会遇到类似的问题：在VM虚拟机管理程序(如VMware,Xen,KVM,Hyper-V或VirtualBox)之上运行LVM,可以创建similar problems到内核而没有写入障碍,因为写入缓存和写入-ordering.仔细检查您的虚拟机管理程序文档以获取“刷新到磁盘”或直写缓存选项(出现在KVM,VMware,Xen,VirtualBox和其他文件中) – 并使用您的设置进行测试.某些虚拟机管理程序(如VirtualBox)具有a default setting,它忽略来自guest虚拟机的任何磁盘刷新.
>具有LVM的企业服务器应始终使用battery backed RAID controller并禁用硬盘写入缓存(控制器具有快速且安全的电池备份写入缓存) – 请参阅this XFS FAQ entry的作者this comment.内核中的turn off write barriers也可能是安全的,但建议进行测试.
>如果您没有电池供电的RAID控制器,禁用硬盘写入缓存会显着减慢写入速度,但会使LVM安全.您还应该使用相当于ext3的data = ordered选项(或data = journal以获得额外的安全性),以及barrier = 1来确保内核缓存不会影响完整性. (或者使用ext4,即enables barriers by default.)这是最简单的选项,以性能为代价提供良好的数据完整性. (Linux changed the default ext3 option更危险的数据=写回一段时间,所以不要依赖FS的默认设置.)
>要禁用硬盘写入缓存：为/etc/rc.local(对于SATA)中的所有驱动器添加hdparm -q -W0 / dev / sdX或对SCSI / SAS使用sdparm.但是,根据XFS FAQ中的this entry(这个主题非常好),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 has some support,所有类型的设备目标为2.6.33 works)中都有不完整的写屏障支持 – RHEL 6 uses 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虚拟机管理程序设置和文件系统uses write barriers(即要求驱动器在关键元数据/日志写入之前和之后刷新挂起的写入). XFS does use barriers by default,but ext3 does not,所以对于ext3,你应该在mount选项中使用barrier = 1,并且仍然使用data = ordered或data = journal,如上所述.

>不幸的是,一些硬盘驱动器和SSD是否真的将其缓存刷新到磁盘(特别是旧驱动器,但包括一些SATA驱动器和some enterprise SSDs) – more details here.有一个great summary from an XFS developer.
>有一个simple test tool for lying drives(Perl脚本),或者看到this background with another tool测试由于驱动器缓存而导致写入重新排序. This answer covered similar testing SATA驱动器在软件RAID中发现了写屏障问题 – 这些测试实际上运行整个存储堆栈.
>支持Native Command Queuing(NCQ)的最新SATA驱动器可能是less likely to lie – 或者由于NCQ而没有写入缓存,它们可能表现良好,并且很少有驱动器无法禁用写入缓存.
> SCSI / SAS驱动器通常都可以,因为它们不需要写缓存来表现良好(通过SCSI Tagged Command Queuing,类似于SATA的NCQ).
>如果您的硬盘驱动器或SSD确实将缓存刷新到磁盘上,那么您实际上不能依赖写入障碍并且必须禁用写入缓存.这是所有文件系统,数据库,卷管理器和software RAID的问题,而不仅仅是LVM.

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

>大多数企业级SSD在写入缓存控制方面应该没问题,有些还包括超级电容器.
>一些更便宜的固态硬盘有问题can’t be fixed with write-cache configuration – PostgreSQL项目的邮件列表和Reliable Writes wiki page是很好的信息来源.消费者SSD可能会导致数据丢失have major write caching problems,并且不包括超级电容器,因此易受电源故障导致损坏的影响.

高级格式化驱动器设置 – 写入缓存,对齐,GPT

>对于使用4 KiB物理扇区的较新Advanced Format drives,启用驱动器写缓存可能很重要,因为大多数此类驱动器当前模拟512字节逻辑扇区(“512 emulation”),有些甚至声称具有512字节物理扇区,而实际使用4 KiB.
>如果应用程序/内核正在执行512字节写入,则关闭高级格式化驱动器的写入高速缓存可能会对性能产生非常大的影响,因为此类驱动器依赖于高速缓存来累积8 x 512字节写入,然后再执行单个4 KiB实体写作.如果禁用缓存,建议进行测试以确认是否有任何影响.
> Aligning the LVs on a 4 KiB boundary对性能很重要,但只要PV的底层分区对齐,就应该自动发生,因为LVM物理范围(PE)默认为4 MiB.这里必须考虑RAID – 这个LVM and software RAID setup page建议将RAID超级块放在卷的末尾,并且(如果需要)使用pvcreate上的选项来对齐PV. This LVM email list thread指向2011年内核中完成的工作以及在单个LV中混合具有512字节和4 KiB扇区的磁盘时的部分块写入问题.
> GPT partitioning with Advanced Format需要注意,特别是对于启动根磁盘,以确保第一个LVM分区(PV)在4 KiB边界上启动.

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

>在硬崩溃或断电(由于不正确的写入缓存)之后所需的LVM数据的恢复是最好的手动过程,因为显然没有合适的工具. LVM擅长在/ etc / lvm下备份其元数据,这有助于恢复LV,VG和PV的基本结构,但无法帮助丢失文件系统元数据.
>因此可能需要从备份完全恢复.与不使用LVM的快速基于日志的fsck相比,这涉及更多的停机时间,并且自上次备份以来写入的数据将丢失.
> TestDisk,ext3grep,ext3undel和other tools可以从非LVM磁盘恢复分区和文件,但它们不直接支持LVM数据恢复. TestDisk可以发现丢失的物理分区包含LVM PV,但这些工具都不了解LVM逻辑卷.诸如PhotoRec之类的File carving工具以及许多其他工具可以绕过文件系统从数据块重新组装文件,但这是有价值数据的最后手段,低级方法,并且对于碎片文件效果较差.
>在某些情况下可以进行手动LVM恢复,但是复杂且耗时 – 有关如何恢复的信息,请参阅this example和this,this和this.

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

>更新：更新版本的lvextend支持-r(–resizefs)选项 – 如果可用,它是一种更安全,更快速的方法来调整LV和文件系统的大小,特别是如果你缩小FS,你可以跳过这一节.
>大多数调整基于LVM的FS大小的指南都没有考虑到FS必须比LV的大小小一些的事实：detailed explanation here.缩小文件系统时,你需要指定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 – 单独k myVGname | grep“PE Size”
所有LV的大小：
lvs – 单独4096b
(ext3)FS的大小假设4 KiB FS块大小：
tune2fs -l / dev / myVGname / myLVname | grep’块计数’
>相比之下,非LVM设置使得调整FS的大小非常可靠和简单 – 运行Gparted并调整所需的FS,然后它将为您完成所有操作.在服务器上,您可以使用shell中的parted.

>通常最好使用Gparted Live CD或Parted Magic,因为它们最近有一个通常更无错误的Gparted&内核比发行版本 – 由于发行版的Gparted在正在运行的内核中没有正确更新分区,我曾经丢失了整个FS.如果使用发行版的Gparted,请确保在更改分区后立即重新启动,以便内核的视图正确.

快照很难使用,速度慢且有问题 – 如果快照耗尽预先分配的空间,则为automatically dropped.给定LV的每个快照都是针对该LV的增量(不是以前的快照),这在快照时可能需要大量空间具有重要写入活动的文件系统.创建与原始LV大小相同的快照LV是安全的,因为快照将永远不会耗尽可用空间.

快照也可能非常慢(比没有these MySQL tests的LVM慢3到6倍) – 见this answer covering various snapshot problems.缓慢部分是因为snapshots require many synchronous writes.

快照有一些重大错误,例如in some cases他们可以使启动速度非常慢,或导致启动完全失败(因为kernel can time out在它是LVM快照时等待根FS [在Debian initramfs-tools update,2015年3月修复]).

>一个指标是有许多Debian错误matching “lvm snapshot 2015”,其中一些非常严重 – 但是,许多快照竞争条件错误显然是been fixed.没有快照的LVM通常看起来很好调试,可能是因为快照没有像核心一样使用特征.

快照替代方案 – 文件系统和VM虚拟机管理程序

VM /云快照：

>如果您使用的是VM虚拟机管理程序或IaaS云提供程序,则它们的快照(例如VMware,VirtualBox或Amazon EC2的EBS快照)通常是LVM快照的更好替代方案.您可以非常轻松地拍摄快照以进行备份(但请考虑在执行此操作之前冻结FS).

文件系统快照：

>使用ZFS或btrfs的文件系统级快照易于使用,并且通常比LVM更好,虽然Linux上的文件系统都不是很成熟,但对于真正需要快照但没有使用VM /云路由的人来说,它们可能是更好的选择：

> ZFS：现在有一个kernel ZFS implementation,已经使用了几年,应该比FUSE上的ZFS快很多.
> btrfs尚未准备好用于生产,其fsck and repair tools仍处于开发阶段.

在线备份和fsck的快照

快照可用于为备份提供一致的源,只要您注意分配的空间(理想情况下,快照与正在备份的LV的大小相同).优秀的rsnapshot(自1.3.1开始)甚至为您管理LVM快照创建/删除 – 请参阅此HOWTO on rsnapshot using LVM.但是,请注意快照的一般问题以及快照不应被视为备份本身.

您还可以使用LVM快照执行在线fsck：快照LV和fsck快照,同时仍然使用主非快照FS – described here – 但是,它是not entirely straightforward所以最好使用e2croncheck作为described by Ted Ts’o,ext3的维护者.

在拍摄快照时你应该暂时“freeze” the filesystem – 当LVM创建快照时,一些文件系统如ext3和XFS将在do this automatically.

结论

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

由于VM虚拟机管理程序,硬盘驱动器/ SSD写入缓存等原因,LVM需要非常小心写入缓存设置 – 但这同样适用于将Linux用作数据库服务器.大多数工具(包括临界尺寸计算和测试磁盘等)缺乏支持使得它比应该更难使用.

如果使用LVM,请特别注意快照：尽可能使用VM /云快照,或者调查ZFS / btrfs以完全避免LVM – 与具有快照的LVM相比,您可能会发现ZFS或btrs已经足够成熟.

结论：如果您不了解上面列出的问题以及如何解决这些问题,最好不要使用LVM.