题 LVM的危险和警告


我最近开始在某些服务器上使用LVM来处理大于1 TB的硬盘。它们非常有用,可扩展且易于安装。但是,我找不到任何关于LVM的危险和警告的数据。

使用LVM的缺点是什么?


177
2018-06-12 07:34




在阅读这个问题的答案时,请记住他们发布的日期(年份)。这个行业在3年内发生了很多事情。 - MattBianco
我最近做了一些更新(2015年4月),扫描过来看看是否有任何变化。 2.6内核现在已经过时,SSD更常见,但除了一些小的LVM修复之外,没有太多真正改变。我确实写了一些关于使用VM /云服务器快照而不是LVM快照的新内容。就我所见,写缓存,文件系统大小调整和LVM快照的状态并没有真正改变。 - RichVel
关于“记住日期”的评论 - 足够真实,但也考虑到许多“企业”仍在使用RHEL 5和RHEL 6,这两者都是最先进的或比日期更早的的答案 - JDS


答案:


摘要

使用LVM的风险:

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

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

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

降低风险

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

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

细节

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

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

  • 写入缓存并通过硬盘写入重新排序 对于良好的性能很重要,但由于VM虚拟机管理程序,硬盘驱动器写入缓存,旧Linux内核等原因,无法正确地将块刷新到磁盘。
    • 写障碍 意味着内核保证在“屏障”磁盘写入之前完成某些磁盘写入,以确保文件系统和RAID可以在突然断电或崩溃时恢复。这样的障碍可以使用 FUA(强制单位访问)操作 立即将某些块写入磁盘,这比完全缓存刷新更有效。障碍可以与高效率相结合 标记/本地人 命令排队(一次发出多个磁盘I / O请求)以使硬盘驱动器能够执行智能写入重新排序,而不会增加数据丢失的风险。
  • VM管理程序 可能有类似的问题:在VM虚拟机管理程序(如VMware)上运行Linux客户机中的LVM, Xen的,KVM,Hyper-V或VirtualBox都可以创建 类似的问题由于写入缓存和写入重新排序,没有写入障碍的内核。仔细检查您的虚拟机管理程序文档,了解“刷新到磁盘”或直写缓存选项(显示在 KVMVMware的Xen的VirtualBox的 和其他人) - 并使用您的设置进行测试。 一些虚拟机管理程序,如VirtualBox 默认设置 忽略来自guest虚拟机的任何磁盘刷新。
  • 带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,则将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 在mount选项中,仍然使用 data=ordered 要么 data=journal 如上。

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

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

  • 随着新的 高级格式化驱动器 使用4 KiB物理扇区,保持驱动器写缓存可能很重要,因为大多数此类驱动器当前模拟512字节逻辑扇区(“512仿真”),有些甚至声称拥有512字节的物理扇区,而真正使用4 KiB。
  • 如果应用程序/内核正在执行512字节写入,则关闭高级格式驱动器的写入缓存可能会对性能产生非常大的影响,因为此类驱动器依赖缓存来累积8 x 512字节写入,然后再执行单个4 KiB物理写入写。如果禁用缓存,建议进行测试以确认是否有任何影响。
  • 在4 KiB边界上对齐LV 对于性能很重要,但只要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相比,这涉及更多的停机时间,并且自上次备份以来写入的数据将丢失。
  • TestDiskext3grepext3undel 和 其他工具  可以从非LVM磁盘恢复分区和文件,但它们不直接支持LVM数据恢复。 TestDisk可以发现丢失的物理分区包含LVM PV,但这些工具都不了解LVM逻辑卷。 文件雕刻 工具如 PhotoRec 还有许多人可以绕过文件系统来重新组装数据块中的文件,但这是有价值数据的最后一种低级方法,对于碎片文件效果不佳。
  • 在某些情况下,手动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的大小非常可靠且易于运行 的gparted 并调整所需的FS,然后它会为你做一切。在服务器上,您可以使用 parted 从壳。

    • 通常最好使用 Gparted Live CD 要么 分手魔术,因为这些版本有一个最近的,通常比版本更多的无错误的Gparted和内核版本 - 由于发行版的Gparted在正在运行的内核中没有正确更新分区,我曾经丢失了整个FS。如果使用发行版的Gparted,请确保在更改分区后立即重新启动,以便内核的视图正确。

快照很难使用,速度慢且有缺陷 - 如果快照用完了预先分配的空间,那就是 自动掉线。给定LV的每个快照是针对该LV的增量(不是针对先前的快照),当快照具有显着写入活动的文件系统时,这可能需要大量空间。创建与原始LV大小相同的快照LV是安全的,因为快照将永远不会耗尽可用空间。

快照也可能非常慢(意味着没有LVM的速度慢3到6倍) 这些MySQL测试) - 见 这个答案涵盖各种快照问题。缓慢部分是因为 快照需要许多同步写入

快照有一些重大错误,例如 在某些情况下 他们可以使启动非常慢,或导致启动完全失败(因为 内核可以超时  当它是LVM快照时,等待根FS [在Debian中修复 initramfs-tools 更新,2015年3月])。

  • 一个指标是Debian有很多bug 匹配“lvm snapshot 2015”,其中一些非常严重 - 然而,许多快照竞争条件错误显然 已修好。没有快照的LVM通常看起来调试得很好,可能是因为快照的使用不像核心功能那么多。

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

VM /云快照:

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

文件系统快照:

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

    • ZFS:现在有一个 内核ZFS实现已经使用了几年,应该比FUSE上的ZFS快很多。
    • btrfs还没有为生产使用做好准备 fsck和修复工具 仍在开发中。

在线备份和fsck的快照

快照可用于提供一致性 资源 对于备份,只要您注意分配的空间(理想情况下,快照与正在备份的LV的大小相同)。优秀 rsnapshot (自1.3.1开始)甚至为您管理LVM快照创建/删除 - 请参阅此内容 关于使用LVM的rsnapshot的HOWTO。但是,请注意快照的一般问题,并且不应将快照本身视为备份。

您还可以使用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或btrs已经足够成熟。

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


238
2018-06-12 08:19



使用xfs进行在线调整大小非常有效,您甚至无需指定大小。它将在xfs_grow(5)中增长到LV读取的大小。 OTOH我在写入障碍的摘要中命中了+1。 - cstamas
DUDE!你一生都在哪里!? - songei2f
@TREE:使用电池供电的RAID控制器的想法是它的缓存在电源故障期间是持久的,并且通常可以信任按照文档记录工作,而一些硬盘缓存是关于他们是否实际上已经将块写入磁盘,以及当然这些缓存并不是持久的。如果启用硬盘缓存,则很容易发生突然断电(例如PSU或UPS故障),这会受到RAID控制器备用电池的影响。 - RichVel
任何话题都是我见过的最好的答案之一。只有改变我会做,对于那些有注意力缺陷障碍或者没有很多时间的人,总结问题的TOP。 :-) - Prof. Falken
看到所有评论和答案的最后更新是一年前,我想知道是否可以更新答案以反映可靠性,性能和易用性方面的任何新变化。 - Luis Alvarado


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

好吧,只是这种分离就在那里 因为某种原因  - 差异显示PV损失处理,以及VG的在线重新激活,即缺少PV以使它们重新发挥作用 - “原始LVM”(AIX,HP-UX)变得轻而易举就变成了LVM2上的废话国家处理不够好。 甚至不让我谈论Quorum丢失检测(哈哈)或状态处理(如果我删除磁盘,不会被标记为不可用。它甚至不会  该死的状态栏)

回复:稳定 pvmove的... 为什么是

pvmove数据丢失

在我的博客上这样一个排名靠前的文章,嗯? 刚才我看到一个磁盘,其中phyiscal lvm数据仍然挂在pvmove中间的状态。 我认为有一些回忆,并且从用户空间复制实时块数据是一件好事,这简直令人难过。 来自lvm列表的好引用“看起来像vgreduce - 不能处理pvmove” 实际上意味着如果磁盘在pvmove期间分离,那么lvm管理工具会从lvm更改为vi。 哦,还有一个错误,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”(hello,ext3)会变得更糟

当然,它告诉你找不到这些信息的好消息来源。 “VRA有多少LE?” “PVRA,VGDA等的物质抵消是多少”

与原来的LVM2相比,LVM2是“不懂UNIX的人被谴责重新发明它的人”的主要例子。

几个月后更新:到目前为止,我一直在进行测试的“完整快照”方案。如果它们已满,则快照会阻止,而不是原始LV。当我第一次发布这个时,我错了。我从某些文档中选择了错误信息,或者我理解了它。在我的设置中,我总是非常偏执,不让他们填满,所以我从来没有纠正过。它也可以扩展/缩小快照,这是一种享受。

我仍然无法解决的是如何识别快照的年龄。 关于它们的性能,有一个关于“thinp”fedora项目页面的说明,该页面说明正在修改快照技术,以便它们不会因每个快照而变慢。 我不知道他们是如何实施的。


15
2017-12-11 14:03



好点,特别是在pvmove数据丢失(没有意识到这可能会在低内存下崩溃)和快照设计。写入障碍/缓存:我将LVM和内核设备映射器混为一谈,从用户的角度来看,它们协同工作以提供LVM提供的功能。 Upvoted。也喜欢你的pvmove数据丢失博客: deranfangvomende.wordpress.com/2009/12/28/... - RichVel
在快照上:它们在LVM中出了名的慢,所以很明显,在可靠性方面追求性能并不是一个好的设计决策。通过“撞墙”,你的意思是快照填满,这真的会导致原始LV数据的损坏吗? LVM HOWTO表示在这种情况下删除了快照: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
“通过将新数据更新到快照lv区域,然后在删除快照后再合并,”CoW完成得不安全。“这只是假的。当新数据写入原始设备时, 旧 版本写入快照COW区域。没有数据被合并(除非您愿意)。看到 kernel.org/doc/Documentation/device-mapper/snapshot.txt 所有血腥的技术细节。 - Damien Tournoud
嗨Damien,下次刚读到我纠正帖子的地方? - Florian Heigl


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

顺便说一句,如果你要使用1TB驱动器,请记住分区对齐 - 这个驱动器很可能有4kB的物理扇区。


12
2018-06-12 09:44



+1用于打开快照的性能警告。 - Prof. Falken
我的经验是1TB驱动器通常使用512字节扇区,但大多数2TB驱动器使用4Kb。 - Dan Pritts
@DanPritts假设扇区大小为4kB甚至128kB是没有坏处的 - 以防万一之间有突袭。你失去了这么少 - 也许是128kB,你可以获得很多。当从旧磁盘成像到新磁盘时也是如此。 - pQd
使文件系统块大小“太大”有一些小的伤害;每个文件包含在不少于一个块中。如果你有很多小文件和128KB块,它会加起来。我同意4K是非常合理的,如果你将文件系统移动到新的硬件,你最终将最终得到4k扇区。 - Dan Pritts
(不会让我编辑我以前的评论)...浪费空间可能无关紧要,但最终会增加你在旋转磁盘上的平均寻道时间。它可能会变成SSD上的写入放大(用空值填充扇区)。 - Dan Pritts


亚当,

另一个优点是:您可以添加新的物理卷(PV),将所有数据移动到该PV,然后在不中断任何服务的情况下删除旧的PV。在过去的五年里,我至少使用过四次这种能力。

我没有看到的一个缺点是:LVM2的学习曲线有点陡峭。主要是在文件和底层媒体之间创建的抽象。如果您只与几个在一组服务器上分享家务的人一起工作,您可能会发现整个团队的额外复杂性太大了。致力于IT工作的大型团队通常不会遇到这样的问题。

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

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

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


5
2018-06-22 21:03



保持 /boot 分开总是一个好主意 - Hubert Kario
GRUB2确实支持从LVM逻辑卷启动(请参阅 wiki.archlinux.org/index.php/GRUB2#LVM)但GRUB1没有。我总是会使用单独的非LVM / boot来确保它很容易恢复。如今,大多数救援磁盘都支持LVM - 有些需要手册 vgchange -ay找到LVM卷。 - RichVel
关于pvmove:看看有关Florian Heigl回答的pvmove数据丢失的观点。 - RichVel