我用整个设备作为LVM物理分区，就这样
sudo pvcreate /dev/xvdg
不幸的是，当这个被使用的时候，我不小心覆盖了一些数据（我想），写一个新的分区表：
sudo fdisk /dev/xvdg ，添加新分区，写分区表，删除分区，写空分区表
这是我目前在哪里。 一切似乎仍然有效，但我担心重启，卸载等。
谢谢！
假设您将整个磁盘用作lvm pv，而不是其中的一个单独分区，那么通常应该没问题，因为LVM标头不在分区表的第一个扇区中，尤其是在使用512字节的扇区。
分区表位于第一个扇区中：例如，请参阅此处 ： 硬盘可以分为一个或多个称为分区的逻辑磁盘。 该分区logging在分区表中，该分区表位于磁盘的扇区0中。
第二个扇区默认使用LVM标题：例如，请参阅： 默认情况下，LVM标签位于第二个512字节的扇区中。 您可以通过将标签放置在前4个扇区中的任何一个上来覆盖此默认值。 如果需要，这允许LVM卷与这些扇区的其他用户共存。
请注意：如果扇区大小fdisk使用较大（比如说1024字节），我不确定会发生什么情况 – LVM可能仍在第二个512字节扇区中，fdisk可能会覆盖整个1024字节扇区？
顺便说一句：如果您不确定并有权访问额外的空间（例如，在Amazon EC2上），则可以始终创build一个相同大小的卷，在其上创build一个pvcreate，将其添加到卷组，使用pvmove移动数据到新的卷，然后一个vgreduce删除受影响的卷。
是的，在99.99％的情况下，它被打破了。 原因是你已经覆盖了分区表。 lvm的元数据驻留在PV的第二个512字节扇区中。 因此，在新的分区创build过程中，如果您已经触及了这些分区，那么您的元数据已经被清除。 基本上重新启动，卸载将搞砸了。
有两种可能（但可能不可行）的黑客入侵。
1）如果您知道最后一个已知好文件系统的确切分区表，则可以运行fdisk并尝试按照相同的顺序创build它。 你必须知道老fs在哪个领域开始和结束。 像以前一样创build分区，它可能会工作。
2）如果事情不这样做，那么有另一种解决方法pvcreate。 您最后一次已知的lvm备份将存储在/etc/lvm/archive/volume_group_name_XXXX.vg文件中。 您需要从那里获取PV的UUID。 那么，如果事情是你的青睐，你可以做到这一点。
pvcreate --uuid <put_uuid_here> /etc/lvm/archive/volume_group_name_XXXX.vg <physical-volume name>
但是，如果可以，请先备份您的数据。 pvcreate不会触及用户数据，它只处理元数据，但如果在启动时，fsck发现任何不一致，它可能会抛出你的fs错误和潜在的不可恢复的磁盘。