主页 / unix / 问题 / 780471
Accepted
Harv
Asked: 2024-07-20 08:55:12 +0800 CST

减少使用的空间；回收物理磁盘

  • 772

我正在运行 Proxmox 8.2.2。最近我的 lvg 损坏了（“卷组 pve 可用空间不足！”）

首先，我尝试修复 vg：

$ sudo lvconvert --repair pve/data
Volume group "pve" has insufficient free space (2017 extents): 2077 required.

因此我插入了一个额外的磁盘并将其添加到组中：

$ sudo pvcreate /dev/sdj
$ sudo vgextend pve /dev/sdj

并重新运行修复：

$ sudo lvconvert --repair pve/data
WARNING: You have not turned on protection against thin pools running out of space.
WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.
WARNING: Sum of all thin volume sizes (<884.02 GiB) exceeds the size of thin pools (<794.79 GiB).
WARNING: You have not turned on protection against thin pools running out of space.
WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.
WARNING: LV pve/data_meta2 holds a backup of the unrepaired metadata. Use lvremove when no longer required.
WARNING: New metadata LV pve/data_tmeta might use different PVs.  Move it with pvmove if required.

现在，我的数据可以访问了。我删除了一些我不需要的数据。以下是我想要做的：

  1. 理解上述有关精简池的警告并设置限制，以防止这种情况再次发生。

  2. 减少逻辑卷跨度，这样我就不需要刚刚插入的额外物理磁盘。

  3. 移除物理磁盘，而不会损坏或危及 lv 中的任何东西。

我对此感到力不从心——我真的很感激任何见解或文档链接，这样我就能理解我是如何陷入这种困境的，我如何强制限制以免再次陷入这种困境，以及如何让自己回到 lvg 不包含新驱动器的状态。

编辑：

$ sudo pvdisplay
--- Physical volume ---
PV Name               /dev/sdk3
VG Name               pve
PV Size               931.01 GiB / not usable 4.69 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              238338
Free PE               2017
Allocated PE          236321
PV UUID               Msq2HF-K0f1-5spf-hWis-irni-vrLM-fiyq1N
--- Physical volume ---
PV Name               /dev/sdj
VG Name               pve
PV Size               <1.82 TiB / not usable <1.09 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              476932
Free PE               474855
Allocated PE          2077
PV UUID               Jl1Jkd-4PJs-uAu9-bOUb-2yEQ-dnFb-YS5RVf

$ sudo vgdisplay
--- Volume group ---
VG Name               pve
System ID
Format                lvm2
Metadata Areas        2
Metadata Sequence No  746
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                12
Open LV               5
Max PV                0
Cur PV                2
Act PV                2
VG Size               <2.73 TiB
PE Size               4.00 MiB
Total PE              715270
Alloc PE / Size       238398 / 931.24 GiB
Free  PE / Size       476872 / <1.82 TiB
VG UUID               cmDgdu-22V6-Tx4j-pwNG-42ZZ-vRiG-SA850C

$ sudo lvs
LV            VG  Attr       LSize    Pool Origin Data%  Meta%      Move Log Cpy%Sync Convert
data          pve twi-aotz-- <794.79g             61.00  3.20
data_meta0    pve -wi-a-----    8.11g
data_meta1    pve -wi-a-----    8.11g
root          pve -wi-ao----   96.00g
swap          pve -wi-ao----    8.00g
vm-100-disk-0 pve Vwi-aotz--   32.00g data        20.35
vm-100-disk-1 pve Vwi-aotz--    4.00m data        14.06
vm-102-disk-0 pve Vwi-aotz--   10.00g data        35.51
vm-104-disk-0 pve Vwi-a-tz--    8.00g data        57.03
vm-110-disk-0 pve Vwi-a-tz--    4.00m data        14.06
vm-110-disk-1 pve Vwi-a-tz--  650.00g data        72.34
vm-110-disk-2 pve Vwi-a-tz--    4.00m data        1.56

$ sudo pvdisplay -m
--- Physical volume ---
PV Name               /dev/sdk3
VG Name               pve
PV Size               931.01 GiB / not usable 4.69 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              238338
Free PE               2017
Allocated PE          236321
PV UUID               Msq2HF-K0f1-5spf-hWis-irni-vrLM-fiyq1N
--- Physical Segments ---
Physical extent 0 to 2047:
  Logical volume      /dev/pve/swap
  Logical extents     0 to 2047
Physical extent 2048 to 26623:
  Logical volume      /dev/pve/root
  Logical extents     0 to 24575
Physical extent 26624 to 230089:
  Logical volume      /dev/pve/data_tdata
  Logical extents     0 to 203465
Physical extent 230090 to 232166:
  Logical volume      /dev/pve/data_meta0
  Logical extents     0 to 2076
Physical extent 232167 to 234243:
  Logical volume      /dev/pve/data_meta1
  Logical extents     0 to 2076
Physical extent 234244 to 236320:
  Logical volume      /dev/pve/data_tmeta
  Logical extents     0 to 2076
Physical extent 236321 to 238337:
  FREE
--- Physical volume ---
PV Name               /dev/sdj
VG Name               pve
PV Size               <1.82 TiB / not usable <1.09 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              476932
Free PE               474855
Allocated PE          2077
PV UUID               Jl1Jkd-4PJs-uAu9-bOUb-2yEQ-dnFb-YS5RVf
--- Physical Segments ---
Physical extent 0 to 2076:
  FREE
Physical extent 2077 to 4153:
  Logical volume      /dev/pve/lvol1_pmspare
  Logical extents     0 to 2076
Physical extent 4154 to 476931:
  FREE
lvm

1 个回答

  1. Best Answer

    我的 lvg 损坏了（“卷组 pve 没有足够的可用空间！”）

    这听起来不像是“损坏”，而只是精简卷的映射大小达到了 VG 的大小

    我不知道您对精简池/配置了解多少，但本质上它在 VG 之上添加了另一个“层”，以便您可以创建总大小大于 VG 的 LV。然后，LV（在本例中为精简卷）将在向精简池中写入数据时“获取”块（即，将其块映射到精简池中的块）。

    随着时间的推移，尽管精简卷的用户可能已经删除了卷中文件系统中不需要的文件，但这并不意味着为这些不需要的文件“获取”的块会“返回”到精简池。因此，即使仍然存在的文件所占的总大小小于 VG，也无法从精简池中获取更多块来在精简卷中创建新文件。

    要“回收”这些“已使用但未使用”的块用于精简池，您需要“丢弃”精简卷上相应的映射块。如果精简卷用作虚拟机中的虚拟磁盘，则应在每个虚拟机的磁盘设置中允许丢弃，并fstrim在虚拟机中相应地运行（假设客户操作系统是 Linux）。对于由 proxmox 主机直接使用的卷（即直接格式化并挂载在那里），显然您应该fstrim在 proxmox 中运行。（请注意，fstrim通过挂载点工作，因此不要指望fstrim -a对未挂载的分区/精简卷产生影响。）

    显然，自动执行此类操作的方法是启用fstrim.timer（或非 systemd 发行版上的任何等效操作）或使用该discard选项挂载文件系统。（如果操作系统不是 Linux，只需确保通过任何等效方式“启用”“TRIM”。）

    而且我认为，只要精简池（即精简卷的总使用空间）的已用空间（您可以尝试通过丢弃来减少）小于 VG 的当前大小减去新 PV 的大小（sdj），you should be able to get myself back to a state where the lvg doesn't contain the new drive就可以使用vgreduce。 （您可能需要先手动缩小精简池。我真的不知道当您拥有lvconvert --repair“满”的精简池时会发生什么。也许它会自动扩展它。无论哪种方式，先尝试运行并查看应该是安全的vgreduce。）

    您可以使用lvs来查找Data%精简池的当前使用情况（）。

    PS，也许您从未想要过精简池/配置，但这只是 proxmox 的默认方法；我不知道是否有一种简单的方法可以将精简卷移出精简池，即使它们“厚配置”，同时保持其数据的完整性。

    • 2

相关问题