问题[lvm](server)

我们在几台 ProLiant DL360p Gen8 上运行 Proxmox VE 8.3。每台都通过两个连接连接到 1/2 MSA 2040 存储阵列。对于第一个连接，该阵列可作为 /dev/sdb 访问；对于后备连接，该阵列可作为 /dev/sdc 访问。

我们想将阵列用作 lvm-thin。为此，我在阵列上创建了一个分区，创建了一个物理卷和一个卷组。

sgdisk -N 1 /dev/sdb
pvcreate /dev/sdb1
vgcreate vg-proxmox1-array /dev/sdb1

到目前为止，一切正常。在创建精简池之前，我运行pveupgrade并重新启动了服务器。重新启动后，运行或 时卷组vg-proxmoxN-array不再显示。运行或时物理卷也不再显示。但是，当明确命名设备时，PV 和 VG 会显示：vgsvgscanpvspvscan

root@proxmox1:~# pvscan --devices /dev/sdb1
  PV /dev/sdb1   VG vg-proxmox1-array   lvm2 [<4.91 TiB / <4.91 TiB free]
  Total: 1 [<4.91 TiB] / in use: 1 [<4.91 TiB] / in no VG: 0 [0   ]

根据一些互联网资源，lvm 配置中的过滤器可能是原因 - 但我找不到任何匹配的/dev/sdb

grep -v "#" /etc/lvm/lvm.conf | grep filter
     global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]

一些资源指向10.1.2。将设备添加到 system.devices 文件，但提到的工具lvmdevices --adddev <device_name>似乎在 Proxmox VE 8.3 上不可用。

• 我将非常感谢任何关于如何让物理卷在运行时可靠地显示pvs以及pvscan卷组在运行时可靠地显示的提示vgs。vgscan
• 我可能做错了什么导致他们没有出现？在目前的情况下我能信任硬件吗？
• 从这里开始的最佳方法是什么，将 99% 的 vg-proxmox1-array 用于 lvm-thin 池，将剩余的 1% 用于元数据？

提前谢谢您！

我在 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。现在我有多个问题：

1. 这个孤立的快照是正确的卷还是已损坏？
2. 为什么会发生这种情况？（我将创建时间快照的一些中间部分与其起源合并，然后重新创建它们）
3. 我可以手动从快照中删除源以使其成为单独的卷吗？
4. 有没有办法让这些卷成为快照，并将相同的数据块再次链接到原点以保留空间？

更新。测试脚本。

带有 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%。该主题可以关闭。驱动器已死。谢谢。

情况：

• debian 11 与 LVM 和 / 是一个逻辑卷：/dev/mainvg/lv-root
• 通过执行创建根分区的快照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 中删除？

谢谢！