我在 RHEL9 上使用 LVM。我的分区（/dev/sda4）上有一个逻辑卷，需要给它更多的空间。我进入 VMWare 并增大了驱动器。然后我使用parted扩展分区并运行“resizepart 4 100%”。然后我运行“pvresize /dev/sda4”。这增加了物理体积。现在我需要增加卷组，但我不知道该怎么做。当我运行“vgdisplay”时，它显示额外的空间存在但未分配（见下文）。有人可以帮忙吗？
分配 PE / 大小 6862 / 26.80 GiB
免费 PE / 大小 56420 / 220.39 GiB
我正在玩我的 LVM 精简安装。创建多个快照，并将它们多次与原点合并。在命令输出中的某个时刻，lvs -a最旧的快照丢失了其起源。在更详细命令的输出中，lvs -a -o time,name,origin,lv_role此快照现在具有lv_role（public而快照具有 Roles public,snapshot,thinsnapshot）。merge现在不可能出现错误is not a mergeable logical volume。现在我有多个问题：
更新。测试脚本。
带有 VG 名称和应该存在的池的初始配置：
VG=vg
Pool="${VG}"/pool0
Test_volume="test"
创建测试 LV 并使其随机
lvcreate -V10M -T "${Pool}" -n "${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}"
dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_0" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_0"
dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_1" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_1"
dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_2" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_2"
dd if=/dev/urandom of="/dev/${VG}/${Test_volume}"
lvcreate -n "${Test_volume}_snap_3" --snapshot "${VG}"/"${Test_volume}"
lvchange -ay -Ky "${VG}"/"${Test_volume}_snap_3"
sha256sum "/dev/${VG}/${Test_volume}_snap"*
lvs -a -o name,origin,lv_role| grep "${Test_volume}"
lvs输出：
test public,origin,thinorigin,multithinorigin
test_snap_0 test public,snapshot,thinsnapshot
test_snap_1 test public,snapshot,thinsnapshot
test_snap_2 test public,snapshot,thinsnapshot
test_snap_3 test public,snapshot,thinsnapshot
现在合并一个快照：
lvconvert --merge "${VG}/${Test_volume}_snap_2"
lvs -a -o name,origin,lv_role| grep "${Test_volume}"
输出：
test public
test_snap_0 public
test_snap_1 public
test_snap_3 public
该快照现在只是卷，它们可能彼此共享一些块，sha256sum表明数据完好无损，覆盖其中一个不会影响其他快照。
很奇怪为什么它们失去了起源但仍然有共同的数据块。
我有一个程序可以使用随机密钥手动创建一个普通的 dm-crypt 交换卷，这似乎可以工作。这是一个 QEMU/Ubuntu 22.04 系统。然而，重新启动后没有交换，所以我可能得到了我的/etc/crypttab和/或/etc/fstab，或其他东西，不正确。任何意见表示赞赏。
工作手册设置是：
# swapoff -a
# cryptsetup --type plain open /dev/mapper/vg0-swap encswap
# mkswap /dev/mapper/encswap
# /etc/init.d/cryptdisks start
# swapon /dev/mapper/encswap
# swapon -s
Filename Type Size Used Priority
/dev/dm-3 partition 2097148 0 -2
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1G 0 part /boot
├─sda3 8:3 0 13G 0 part
│ ├─vg0-swap 253:0 0 2G 0 lvm
│ │ └─encswap 253:3 0 2G 0 crypt [SWAP]
│ ├─vg0-data 253:1 0 36.1G 0 lvm /data
│ └─vg0-root 253:2 0 10.9G 0 lvm /
└─sda4 8:4 0 36G 0 part
└─vg0-data 253:1 0 36.1G 0 lvm /data
sr0 11:0 1 4M 0 rom
# cryptsetup status /dev/mapper/encswap
/dev/mapper/encswap is active and is in use.
type: PLAIN
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
key location: dm-crypt
device: /dev/mapper/vg0-swap
sector size: 512
offset: 0 sectors
size: 4194304 sectors
mode: read/write
因此，为了使其持久，/etc/crypttab包含：
swap /dev/mapper/encswap /dev/urandom plain,cipher=aes-xts-plain64,size=256,hash=sha256,swap,noearly
并/etc/fstab包含：
/dev/mapper/swap none swap sw 0 0
当系统启动dm-crypt或systemd运行默认的 90 秒超时时，似乎正在等待一个永远不会到达的密钥。系统日志也说了同样的事情——超时等待/dev/mapper/encswap。启动完成后，swapon -s不显示任何内容，并且lsblk不显示encswap设备（或任何交换设备）。有任何想法吗？
最初我有两个 PV /dev/nvme0n1p2，并/dev/nvme1n1p1包含各种镜像 LV。
我最近添加了两个新的更大容量的 PV/dev/nvme2n1p1和/dev/nvme3n1p1，并扩展了 LV ( home/windows-persistent) 以利用新空间。
然而，我注意到 LV 现在分布在所有 4 个 PV 上，而我更喜欢它只分布在 2 个 PV 上，因此我尝试将 LV 移动到新的 PV pvmove：
lvm> pvmove /dev/nvme0n1p2 -n home/windows-persistent /dev/nvme2n1p1
Insufficient free space: 57793 extents needed, but only 0 available
Unable to allocate mirror extents for home/pvmove0.
Failed to convert pvmove LV to mirrored.
lvm> pvmove /dev/nvme1n1p1 -n home/windows-persistent /dev/nvme3n1p1
Insufficient free space: 57793 extents needed, but only 0 available
Unable to allocate mirror extents for home/pvmove0.
Failed to convert pvmove LV to mirrored.
LVM 为什么会抱怨可用空间不足？如何正确移动 LV？
pvdisplay//vgdisplay输出lvdisplay：
lvm> pvdisplay -m
--- Physical volume ---
PV Name /dev/nvme0n1p2
VG Name home
PV Size 476.74 GiB / not usable 0
Allocatable yes
PE Size 4.00 MiB
Total PE 122046
Free PE 2812
Allocated PE 119234
PV UUID n6vD1c-pF3t-mqlg-g4Ge-HPT7-FwOC-p7t6wK
--- Physical Segments ---
Physical extent 0 to 51199:
Logical volume /dev/home/dom0
Logical extents 0 to 51199
Physical extent 51200 to 51200:
Logical volume /dev/home/windows-persistent_rmeta_0
Logical extents 0 to 0
Physical extent 51201 to 89600:
Logical volume /dev/home/windows-persistent_rimage_0
Logical extents 0 to 38399
Physical extent 89601 to 89601:
Logical volume /dev/home/windows_rmeta_0
Logical extents 0 to 0
Physical extent 89602 to 99841:
Logical volume /dev/home/windows_rimage_0
Logical extents 0 to 10239
Physical extent 99842 to 119233:
Logical volume /dev/home/windows-persistent_rimage_0
Logical extents 38400 to 57791
Physical extent 119234 to 122045:
FREE
--- Physical volume ---
PV Name /dev/nvme1n1p1
VG Name home
PV Size 465.76 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 119234
Free PE 0
Allocated PE 119234
PV UUID 1dmaeN-j0D3-EU60-kQg2-a5t7-CNdP-qpBYyp
--- Physical Segments ---
Physical extent 0 to 51199:
Logical volume /dev/home/dom0-mirror
Logical extents 0 to 51199
Physical extent 51200 to 51200:
Logical volume /dev/home/windows-persistent_rmeta_1
Logical extents 0 to 0
Physical extent 51201 to 81920:
Logical volume /dev/home/windows-persistent_rimage_1
Logical extents 0 to 30719
Physical extent 81921 to 92161:
Logical volume /dev/home/windows-persistent_rimage_1
Logical extents 38400 to 48640
Physical extent 92162 to 99841:
Logical volume /dev/home/windows-persistent_rimage_1
Logical extents 30720 to 38399
Physical extent 99842 to 99842:
Logical volume /dev/home/windows_rmeta_1
Logical extents 0 to 0
Physical extent 99843 to 110082:
Logical volume /dev/home/windows_rimage_1
Logical extents 0 to 10239
Physical extent 110083 to 119233:
Logical volume /dev/home/windows-persistent_rimage_1
Logical extents 48641 to 57791
--- Physical volume ---
PV Name /dev/nvme2n1p1
VG Name home
PV Size <1.82 TiB / not usable 4.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 476931
Free PE 457923
Allocated PE 19008
PV UUID UzD83f-tnya-9wbR-TRrf-qkxe-2lf7-ewF3M7
--- Physical Segments ---
Physical extent 0 to 19007:
Logical volume /dev/home/windows-persistent_rimage_0
Logical extents 57792 to 76799
Physical extent 19008 to 476930:
FREE
--- Physical volume ---
PV Name /dev/nvme3n1p1
VG Name home
PV Size <1.82 TiB / not usable 4.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 476931
Free PE 457923
Allocated PE 19008
PV UUID Rf7CoD-NxTs-ohO3-pqJx-dMZ8-6SCh-SXXhAf
--- Physical Segments ---
Physical extent 0 to 19007:
Logical volume /dev/home/windows-persistent_rimage_1
Logical extents 57792 to 76799
Physical extent 19008 to 476930:
FREE
lvm> vgdisplay
--- Volume group ---
VG Name home
System ID
Format lvm2
Metadata Areas 4
Metadata Sequence No 209
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 2
Max PV 0
Cur PV 4
Act PV 4
VG Size <4.56 TiB
PE Size 4.00 MiB
Total PE 1195142
Alloc PE / Size 276484 / 1.05 TiB
Free PE / Size 918658 / 3.50 TiB
VG UUID 1QhLGQ-ljr2-p0or-yAiD-530e-17n4-y8VN0d
lvm> lvdisplay
--- Logical volume ---
LV Path /dev/home/dom0
LV Name dom0
VG Name home
LV UUID XKpxWe-g8Rh-faKQ-s8Ht-KPC0-oLHc-tLneqN
LV Write Access read/write
LV Creation host, time home, 2016-07-02 18:55:56 +1000
LV Status available
# open 1
LV Size 200.00 GiB
Current LE 51200
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0
--- Logical volume ---
LV Path /dev/home/windows-persistent
LV Name windows-persistent
VG Name home
LV UUID 4g6nXt-h6LL-YaHc-wfcU-Iote-rFJd-rpzgeF
LV Write Access read/write
LV Creation host, time home, 2018-01-08 22:18:42 +1100
LV Status available
# open 0
LV Size 300.00 GiB
Current LE 76800
Mirrored volumes 2
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:5
--- Logical volume ---
LV Path /dev/home/dom0-mirror
LV Name dom0-mirror
VG Name home
LV UUID WtfyuY-LRxR-nQBk-ft8C-T1gn-2hvE-TIQLgm
LV Write Access read/write
LV Creation host, time home, 2018-12-06 19:02:41 +1100
LV Status available
# open 1
LV Size 200.00 GiB
Current LE 51200
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:6
--- Logical volume ---
LV Path /dev/home/windows
LV Name windows
VG Name home
LV UUID JKQjjn-4vUO-bwTD-eCl3-eZiM-mato-1R09It
LV Write Access read/write
LV Creation host, time home, 2023-07-06 17:10:07 +1000
LV Status available
# open 0
LV Size 40.00 GiB
Current LE 10240
Mirrored volumes 2
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:11
pvs//vgs输出lvs：
lvm> pvs
PV VG Fmt Attr PSize PFree
/dev/nvme0n1p2 home lvm2 a-- 476.74g 10.98g
/dev/nvme1n1p1 home lvm2 a-- <465.76g 0
/dev/nvme2n1p1 home lvm2 a-- <1.82t <1.75t
/dev/nvme3n1p1 home lvm2 a-- <1.82t <1.75t
lvm> vgs
VG #PV #LV #SN Attr VSize VFree
home 4 4 0 wz--n- <4.56t 3.50t
lvm> lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
dom0 home -wi-ao---- 200.00g
dom0-mirror home -wi-ao---- 200.00g
windows home rwi-aor--- 40.00g 100.00
windows-persistent home rwi-aor--- 300.00g 100.00
我们有一个用于 GIS 数据库的系统（以 Postgres 作为底层引擎），该系统使用 4x2TB Samsung EVO870 SATA SSD 的软件 RAID 5 阵列作为其数据库驱动器。有一个夜间备份脚本，可将表转储到本地临时目录，对它们进行 GZip 压缩，然后将它们传输到单独的计算机（使用mv）。一般备份从1830开始一直运行到0500；是的，这是一个很大的备份。一个月左右前，外部系统掉线了，所以mv步骤停止工作，临时存储区域被未移动的文件填满。修复外部系统后，我们注意到临时区域已满，并删除了其中的所有内容 - 大约 3.5TB 的文件。大约两周前，我们注意到每日备份直到 1000 才完成。我怀疑事情已经变慢，因为临时目录虽然被删除，但没有被清除，所以当我们必须编写一个新的临时文件作为一部分时对于备份，我们必须先清理 SSD 块，然后才能重写它们。
fstrim -av不打印任何内容，这表明没有文件系统表示它们支持 DISCARD。
该系统在 RAID 阵列之上确实有 LVM。数据库和临时目录位于 ext4 文件系统中（是 ext2，但发生了一些事情），位于其自己的 LV 中，安装在/db；fstrim -v /db报道File system does not support DISCARD。
操作系统版本：Debian Linux 8 (jessie)、Linux 3.16.0-4-amd64 x86_64
RAID 信息：
root@local-database:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda1[7] sdd1[4] sdc1[5] sdb1[6]
5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 1/2 pages [4KB], 524288KB chunk
root@local-database:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Dec 27 17:55:35 2015
Raid Level : raid5
Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Aug 8 14:07:27 2023
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : local-database:0 (local to host local-database)
UUID : 18d38d9a:daaa0652:8e43a020:133e5a4f
Events : 53431
Number Major Minor RaidDevice State
7 8 1 0 active sync /dev/sda1
6 8 17 1 active sync /dev/sdb1
5 8 33 2 active sync /dev/sdc1
4 8 49 3 active sync /dev/sdd1
有关用于数据库和临时区域的特定 LV 的信息：
--- Logical volume ---
LV Path /dev/MainDisk/postgres
LV Name postgres
VG Name MainDisk
LV UUID TpKgGe-oHKS-Y341-029v-jkir-lJn8-jo8xmZ
LV Write Access read/write
LV Creation host, time local-database, 2015-12-27 18:04:04 -0800
LV Status available
# open 1
LV Size 4.78 TiB
Current LE 1251942
Segments 4
Allocation inherit
Read ahead sectors auto
- currently set to 6144
Block device 253:2
光伏信息：
root@local-database:~# pvdisplay
--- Physical volume ---
PV Name /dev/md0
VG Name MainDisk
PV Size 5.46 TiB / not usable 2.50 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 1430699
Free PE 121538
Allocated PE 1309161
PV UUID N3tcTa-LBw2-D8gI-6Jg4-9v3T-KWn2-5CDVzK
我真的很希望将备份时间缩短至 11 小时，这样我们就不会再与实际工作时间冲突。TRIM 选项中是否有我可以在此处执行的操作，或者还有其他我错过的操作吗？我检查过数据库没有突然增加任何新表，或者一夜之间增加了 50%；没有网络连接问题，据我所知，在我们开始花费 16 小时进行备份之前，网络或外部服务器没有发生任何奇怪的情况。我还缺少什么吗？
根据评论进行编辑：实际的 SSD 仅使用了一年半，于 2022 年 4 月取代了原来的 250GB SSD。（空间不足，RAID 阵列、LV 和文件系统已就位扩展。）使用软件 RAID、骨标准 Linux 和mdadm.
编辑回应评论：
root@local-database:~# lsblk -d
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
sdb 8:16 0 1.8T 0 disk
sdc 8:32 0 1.8T 0 disk
sdd 8:48 0 1.8T 0 disk
root@local-database:~# cat /sys/module/raid456/parameters/devices_handle_discard_safely
N
root@local-database:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 21
Model: 2
Model name: AMD FX(tm)-8320 Eight-Core Processor
Stepping: 0
CPU MHz: 1400.000
CPU max MHz: 3500.0000
CPU min MHz: 1400.0000
BogoMIPS: 7023.19
Virtualization: AMD-V
L1d cache: 16K
L1i cache: 64K
L2 cache: 2048K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
根据 Nikita Kyprianov 在下面的评论中链接的一篇文章，三星 EVO 870s 在 AMD 硬件上存在严重问题，这显然是事实。看来就是这样。我想我们只能忍受它......
SSD 进入只读模式，因此您需要将分区移动到工作的 SSD，但我遇到了 LVM 大小不同的情况：
#lvm pvscan
PV /dev/sdc3 VG pve lvm2 [<111.29 GiB / 13.87 GiB 免费]
PV /dev/sdb3 VG pve lvm2 [<118.74 GiB / 14.75 GiB 免费]
由于体积的差异，将无法通过 DD 进行传输。
sudo dd if=/dev/sdb3 of=/dev/sdc3 status=progress
还有哪些方法？也许有软件可以从 BIOS 下克隆分区？
UPD：两个 SSD 都通过 NVME-usb 适配器连接。我正在 iODD-2531 上通过 live linux 工作。反过来，我通过 ssh 连接到系统。
从 128GB 驱动器复制到 120GB 驱动器。如果第一个驱动器没有写保护，我可以尝试减小分区的大小，然后使用 DD 进行复制。
更新：
我连接了一个 500GB 的驱动器进行测试，并开始使用 DD 进行复制。结果我得到一个错误：
ubuntu@ubuntu:~$ sudo dd if=/dev/sdd of=/dev/sdc status=progress
456839680 bytes (457 MB, 436 MiB) copied, 53 s, 8.6 MB/s
459821568 bytes (460 MB, 439 MiB) copied, 57 s, 8.1 MB/s
461292032 bytes (461 MB, 440 MiB) copied, 59 s, 7.8 MB/s
569393664 bytes (569 MB, 543 MiB) copied, 72 s, 7.9 MB/s
709820928 bytes (710 MB, 677 MiB) copied, 85 s, 8.4 MB/s
dd: error reading '/dev/sdd': Input/output error
1388520+0 records in
1388520+0 records out
710922240 bytes (711 MB, 678 MiB) copied, 93.8062 s, 7.6 MB/s
这是复制错误。SSD 爱国者 p300，它持续退化，坏道超过 50%。该主题可以关闭。驱动器已死。谢谢。
情况：
lvcreate -L5G -n bkp_lvroot -s /dev/mainvg/lvroot现在我用apt更新了系统，安装了一个新内核，但是grub-probe失败了。输出：
[...]
Setting up linux-image-5.10.0-21-amd64 (5.10.162-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.10.0-20-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.10.0-20-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.10.0-21-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.10.0-21-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-21-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-21-amd64
Found initrd image: /boot/initrd.img-5.10.0-21-amd64
Found linux image: /boot/vmlinuz-5.10.0-20-amd64
Found initrd image: /boot/initrd.img-5.10.0-20-amd64
Found linux image: /boot/vmlinuz-5.10.0-13-amd64
Found initrd image: /boot/initrd.img-5.10.0-13-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
grub-probe: error: unknown filesystem.
/usr/sbin/grub-probe: error: unknown filesystem.
Found Debian GNU/Linux 11 (bullseye) on /dev/mapper/mainvg-bkp_lvroot
done
Setting up linux-image-amd64 (5.10.162-1) ...
user:~$
这与launchpad 上描述的问题完全相同。
重新启动解决了问题。
但我不敢重新启动，因为新内核已经符号链接并生成了 grub 配置，正如我上面的输出所述。
伙计们，我需要建议：
我可以安全地重新启动吗？或者当我重新启动时我的系统会损坏吗？？？
或者我应该先以某种方式“恢复”到旧内核吗？（那将如何完成？）
（顺便说一句：我无法删除快照，因为它正在“使用中”并且处于活动状态，lvremove 和 lvchange 不起作用）
非常感谢这里的任何帮助
我正在使用 LVM 运行 Debian 11。
根分区是 /dev/mainvg/lvroot。
我通过执行创建了根分区的快照lvcreate -L5G -n bkp_lvroot -s /dev/mainvg/lvroot。
我的系统处于这种状态几天。
现在我想删除快照，如下所示：
lvremove /dev/mainvg/bkp_lvroot
Logical volume mainvg/bkp_lvroot in use.
看起来快照处于“活动”状态，所以我尝试停用它：
lvchange -an -v /dev/mainvg/bkp_lvroot
Change of snapshot mainvg/bkp_lvroot will also change its origin mainvg/lvroot. Proceed? [y/n]: n
Accepted input: [n]
Logical volume mainvg/bkp_lvroot not changed.
我无法将根分区设置为停用，可以吗？？？
另外：快照没有挂载，
没有lsof | grep /dev/mainvg/bkp_lvroot结果
我的实际问题是：如何安全地删除快照？（我不知道怎么做，我不想破坏我的系统）
我有一个卷组：
$ vgdisplay
--- Volume group ---
VG Name Ethan-PC
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 19
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size <3.86 TiB
PE Size 4.00 MiB
Total PE 1010969
Alloc PE / Size 1004569 / 3.83 TiB
Free PE / Size 6400 / 25.00 GiB
VG UUID ixrl2q-Alsc-UvxQ-q55x-7M3G-S2vq-fNr1wC
两个逻辑卷：
$ sudo lvdisplay
--- Logical volume ---
LV Path /dev/Ethan-PC/root
LV Name root
VG Name Ethan-PC
LV UUID Mde88v-pIYX-ubVw-dYgY-IuaJ-K59r-xHEtXP
LV Write Access read/write
LV Creation host, time archiso, 2018-12-15 10:04:22 -0600
LV Status available
# open 1
LV Size 200.00 GiB
Current LE 51200
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0
--- Logical volume ---
LV Path /dev/Ethan-PC/home
LV Name home
VG Name Ethan-PC
LV UUID Q4m5VI-QH2q-J0oK-XT3z-Ip7c-dk4f-KLCGAs
LV Write Access read/write
LV Creation host, time Ethan-PC, 2018-12-15 17:50:50 -0600
LV Status available
# open 0
LV Size <3.64 TiB
Current LE 953369
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:1
和两个物理卷：
pvdisplay
--- Physical volume ---
PV Name /dev/nvme0n1p2
VG Name Ethan-PC
PV Size 223.08 GiB / not usable <3.57 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 57108
Free PE 5908
Allocated PE 51200
PV UUID XeW7X2-OKDy-D4aG-clfq-db7N-1g3X-5cJLXP
--- Physical volume ---
PV Name /dev/sda1
VG Name Ethan-PC
PV Size <3.64 TiB / not usable <2.82 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 953861
Free PE 492
Allocated PE 953369
PV UUID g0OSPs-AXTd-6YuE-tEAM-fkmy-O2Ke-ieFXnN
homeLV 上的所有数据都打开/dev/sda1，所有数据root都打开/dev/nvme0n1p2。
# note: irrelevant entries have been removed
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 3.6T 0 disk
└─sda1 8:1 0 3.6T 0 part
└─Ethan--PC-home 254:1 0 3.6T 0 lvm
nvme0n1 259:2 0 476.9G 0 disk
└─nvme0n1p2 259:4 0 223.1G 0 part
└─Ethan--PC-root 254:0 0 200G 0 lvm /
我想/dev/sda1从卷组中删除。我可以很容易地做到这一点，但该过程涉及丢失存储在homeLV 上的数据。我想将数据保留在驱动器上，以备日后需要参考。如何/dev/sda1在不删除数据的情况下从 VG 中删除？
谢谢！
我有一个 CentOS 7 服务器，它配置了一个跨越 5 个外部硬盘驱动器的卷组。我将操作系统升级到 Rocky 9，现在 Rocky 9 看不到物理卷、卷组或逻辑卷。
我的物理卷（外部驱动器）是/dev/sda、/dev/sdb、/dev/sdc、/dev/sdd和/dev/sde。
当我跑步时pvscan -vvv &| grep "/dev/sd[abcde]"，我得到了这个：
Found dev 8:0 /dev/sda - new alias.
Found dev 8:16 /dev/sdb - new alias.
Found dev 8:32 /dev/sdc - new alias.
Found dev 8:48 /dev/sdd - new alias.
Found dev 8:64 /dev/sde - new alias.
/dev/sda: Skipping (deviceid)
/dev/sdb: Skipping (deviceid)
/dev/sdc: Skipping (deviceid)
/dev/sdd: Skipping (deviceid)
/dev/sde: Skipping (deviceid)
为什么 pvscan 会跳过我的设备？
我可以扫描我的物理设备的唯一方法是如果我这样做：sudo pvscan --devices /dev/sda,/dev/sdb,/dev/sdc,/dev/sdd,/dev/sde，这给了我：
PV /dev/sda VG WD_VG lvm2 [<5.46 TiB / 0 free]
PV /dev/sdc VG WD_VG lvm2 [232.88 GiB / 0 free]
PV /dev/sdb VG WD_VG lvm2 [<5.46 TiB / 0 free]
PV /dev/sdd VG WD_VG lvm2 [<5.46 TiB / 0 free]
PV /dev/sde VG WD_VG lvm2 [<5.46 TiB / 0 free]
Total: 5 [<22.06 TiB] / in use: 5 [<22.06 TiB] / in no VG: 0 [0 ]
但在那之后，这些设备仍然没有出现在输出中pvdisplay
更新：似乎运行这些命令修复了它：
sudo lvmdevices --adddev /dev/sda
sudo lvmdevices --adddev /dev/sdb
sudo lvmdevices --adddev /dev/sdc
sudo lvmdevices --adddev /dev/sdd
sudo lvmdevices --adddev /dev/sde
为什么这是必要的？我以为 lvm 每次都扫描所有块设备？为什么它会保留要扫描的设备列表？