PVE基于raid0创建LVM-thin并添加固态磁盘作为缓存池

关键词：PVE | Proxmox VE | RAID | RAID0 | LVM | LVM-thin | 缓存 | cache | HDD | SSD

前言

最近在查阅资料各种资料，看看PVE单服务器系统中，能用什么样的方式，提升LVM-thin存储的IO性能。有多服务器条件的当然是上CEPH了，没有多服务器的条件而内存又比较充足的情况下使用ZFS也不错。但我两种条件都不具备。

作为垃圾佬，怎么舍得再额外购置硬件多花钱呢。垃圾佬当然不愿意再购买新硬盘了，掏出多年前给台式机装系统的两块SATA接口的固态硬盘，以及以前台式机用的两块机械硬盘，准备将两块SSD组raid0后作为缓存池，为两块HDD以raid0组后创建的LVM-thin提供读写缓存服务。

硬盘类型	型号	硬盘大小	通电时长	出厂时间
SSD	Samsung 840 EVO	120G	28744h	2014年3月
SSD	Samsung 850 EVO	120G	22981h	2015年5月
HDD	WD20EZRX	2T	55700h	2013年2月
HDD	HGST HUA723020ALA640	2T	19267h	2013年12月

和我的使用场景、硬件条件一模一样几乎是不可能的，也就几乎不可能有人能够完全照搬我的操作过程，所以本文也仅是提供一种思路，LVM依靠它已经提供的各种功能，可以实现各种你想得到想不到的玩法。这里举三个例子：

2块2T的HDD、1块3T的HDD，3块HDD分别创建一个2T的分区，共3个2TiB的分区组建6T大小3个PV的raid0的LVM或LVM-thin；再将3T盘没有用到的1T空间单独再创建个dir存储，用于保存备份文件、镜像文件等。
1块256G的nvme磁盘，安装系统已经占用了50G，余下的空间大又不大，小又不小，单独用好像也干不了什么太多的事。系统已经默认创建了local-lvm，但是可以将local-lvm删除，然后将产生的约200G空间作为其他HDD磁盘的缓存池，提升IO性能。
4块4T的HDD组raid5后再转换为LVM，然后一块256G的nvme磁盘作为其缓存池。

有关概念

PV(physical volume)：物理卷，在逻辑卷管理系统最底层，可为整个物理硬盘或实际物理硬盘上的分区。

VG(volume group)：卷组，建立在物理卷上，一卷组中至少要包括一物理卷，卷组建立后可动态的添加卷到卷组中，一个逻辑卷管理系统工程中可有多个卷组。

LV(logical volume)：逻辑卷，建立在卷组基础上，卷组中未分配空间可用于建立新的逻辑卷，逻辑卷建立后可以动态扩展和缩小空间。

PE(physical extent)：物理区域，是物理卷中可用于分配的最小存储单元（本文采用默认值4MiB），物理区域大小在建立卷组时指定，一旦确定不能更改，同一卷组所有物理卷的物理区域大小需一致，新的PV加入到VG后，PE的大小自动更改为VG中定义的PE大小。

LE(logical extent)：逻辑区域，是逻辑卷中可用于分配的最小存储单元，逻辑区域的大小取决于逻辑卷所在卷组中的物理区域的大小。

网上有很多有关概念的详细介绍，这里不再多说。

创建具有缓存池的LVM-thin存储

这里需要大致先说明一下我的思路，我打算将HDD全部空间组raid0，然后用作数据LV；将SSD全部空间组raid0，然后用作元数据LV和缓存池LV，最终的存储类型是LVM-thin。分别如下：

数据LV：也就是存储LVM-thin原始数据的LV，所有数据最终需要写入的地方，我将在HDD上创建它。
元数据LV：LVM-thin的特色，相比LVM直接按卷大小预先分配所需空间，LVM-thin则是需要向卷内写入数据时才按实际写入数据量大小分配所需空间。LVM-thin需要用来索引实际数据的元数据metadata空间，就是元数据LV。为了提升数据索引速度，我将在SSD上创建它。
缓存池LV：为了提升访问数据LV中数据的IO速度，使用SSD为它创建缓存池，这样可以将经常读取的数据加载到缓存池中，后续再读取这些数据会提升IO；同时要写入数据时也先写入缓存池，写入也可以更快。缓存池LV也分为数据LV和元数据LV两部分。
- 缓存池数据LV：临时存储缓存数据的地方，我将在SSD上创建它。
- 缓存池元数据LV：索引缓存数据的元数据存储的地方，我也将在SSD上创建它。
还有额外的备用池元数据LV，后文遇到时再作介绍。

如果直接在PVE的WEBUI中来创建，无法实现我所设想的思路，所以只能通过命令行来创建，然后再经过多次转换，来转换为我所需要的LVM-thin。

先看看磁盘的识别情况

1

lsblk

从输出可见，/dev/sdb和/dev/sdc是两块HDD，/dev/sdd和/dev/sde是两块SSD：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


sda            8:0    0    32G  0 disk 
├─sda1         8:1    0  1007K  0 part 
├─sda2         8:2    0   512M  0 part 
└─sda3         8:3    0  31.5G  0 part 
  ├─pve-swap 253:0    0     2G  0 lvm  [SWAP]
  └─pve-root 253:1    0  29.5G  0 lvm  /
sdb            8:16   0   1.8T  0 disk 
sdc            8:32   0   1.8T  0 disk 
sdd            8:48   0 111.8G  0 disk 
sde            8:64   0 111.8G  0 disk

对磁盘初始化

给2块SSD、2块HDD磁盘全部以GPT进行初始化，每个磁盘只分一个区，以下以/dev/sdb为例（不分区直接创建整盘PV也可以）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


## 进入fdisk命令行
fdisk /dev/sdb

## 分别按g、n，sector采用默认的值直接回车，最后 wq 保存并退出
Command (m for help): g
Created a new GPT disklabel (GUID: 798FC3B9-A99E-B245-9A2E-C02B9A2D0836).

Command (m for help): n
Partition number (1-128, default 1): 
First sector (2048-41943006, default 2048): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-41943006, default 41943006): 

Created a new partition 1 of type 'Linux filesystem' and of size 20 GiB.

Command (m for help): wq
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

全部分好区再输入`lsblk`检查一下：

1

lsblk

输出：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    0    32G  0 disk 
├─sda1         8:1    0  1007K  0 part 
├─sda2         8:2    0   512M  0 part 
└─sda3         8:3    0  31.5G  0 part 
  ├─pve-swap 253:0    0     2G  0 lvm  [SWAP]
  └─pve-root 253:1    0  29.5G  0 lvm  /
sdb            8:16   0   1.8T  0 disk 
└─sdb1         8:17   0   1.8T  0 part 
sdc            8:32   0   1.8T  0 disk 
└─sdc1         8:33   0   1.8T  0 part 
sdd            8:48   0 111.8G  0 disk 
└─sdd1         8:49   0 111.8G  0 part 
sde            8:64   0 111.8G  0 disk 
└─sde1         8:65   0 111.8G  0 part

创建PV

1

pvcreate /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

输出：

1
2
3
4


  Physical volume "/dev/sdb1" successfully created.
  Physical volume "/dev/sdc1" successfully created.
  Physical volume "/dev/sdd1" successfully created.
  Physical volume "/dev/sde1" successfully created.

创建VG

采用默认的4M大小的PE，创建名叫hybrid的VG：

1

vgcreate hybrid /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

输出：

1

  Volume group "hybrid" successfully created

创建数据LV

给两块HDD组raid0，用完它们的全部空间创建名叫data的数据LV：

1

lvcreate --type raid0 --name data --extents 100%FREE --stripesize 256k hybrid /dev/sdb1 /dev/sdc1

输出：

1

  Logical volume "data" created.

RAID的Stripe Size大小可以设置为8KiB、16KiB、32KiB、64KiB、128KiB和256KiB，如不设置此参数则默认采用64KiB。

对于数据库应用，Stripe Size在4-16KiB之间被证明效果比较好；对于Web服务器以及文件打印服务器，建议Stripe Size设置为16-64KiB；对于大文件环境，比如流媒体，建议Stripe Size设置为128KiB以上。

我的主要是大文件，所以我设置Stripe Size为256KiB。并且我的使用场景下，主要目的是提升IO，反而对数据损坏这个情况不关心，坏了就坏了，所以我采用的是raid0，和我使用场景不一致的不要采用raid0以及256KiB的Stripe Size。

创建元数据LV和缓存池元数据LV

我最终要创建的存储类型是LVM-thin，这种薄存储类型需要另外的空间存储元数据metadata，如果直接在HDD上创建LVM-thin，系统会自动在HDD上创建其对应的元数据LV。但我们现在创建的是raid0类型的LVM，默认不带元数据LV，并且另一方面，我希望能在SSD上创建元数据所需要的LV，这样还可以提升数据索引速度，所以我需要手动在SSD上创建最终的LVM-thin存储所需要的元数据LV。
并且，我们后面将SSD作为缓存池cachepool时，缓存池它本身也需要存储元数据，所以这里也需要为缓存池创建缓存池元数据LV。
另外，我有两块SSD，我希望能最大化的提升IO，所以这两块SSD之间也需要组raid0。

首先为最终要创建的LVM-thin存储创建名叫meta_thinpool的元数据LV，创建时它默认是数据LV大小的0.1%，我取约0.3%，创建11.5GiB的元数据LV（不能超过15.81GiB）。

存储元数据的raid0组Stripe Size我就保持默认的64KiB吧（不添加–stripesize即使用默认值）。

1

lvcreate --type raid0 --name meta_thinpool --size 11.5G hybrid /dev/sdd1 /dev/sde1

输出

1
2


  Using default stripesize 64.00 KiB.
  Logical volume "meta_thinpool" created.

再为后面马上要创建的的缓存池LV创建名叫meta_cachepool的缓存池元数据LV，raid0组也使用默认的Stripe Size，大小就取528M（大约也是缓存池LV的0.3%）吧。

1

lvcreate --type raid0 --name meta_cachepool --size 528M hybrid /dev/sdd1 /dev/sde1

有关元数据LV大小应该设置多大，可以查看官方建议：lvmthin.7.en#Size_of_pool_metadata_LV

输出

1
2


  Using default stripesize 64.00 KiB.
  Logical volume "meta_cachepool" created.

创建缓存池数据LV

在SSD上已经创建好了两个metadata的LV，占了一点空间，为了最大化利用磁盘空间，先把两块SSD余下的空间全部分配给缓存池数据LV。不过如果后续进行lvconvert转换存储类型操作时，如未设置关闭自动创建备用池元数据LV（即命令中添加--poolmetadataspare n，在PVE的WEBUI中创建LVM-thin，系统也会默认创建备用池元数据LV），在进行转换操作时就需要额外的等同于hybrid/meta_thinpool大小（我这里就是11.5GiB）的空间。我打算让其自动创建备用池元数据LV，所以我需要预留11.5GiB（即2944个PE）。

如果已经在LVM-thin创建了虚拟磁盘，没有任何剩余空间的话，后续再调整就不太好调整了，所以如果不太放心的话，你多保留一些空间不完全创建LV也是可以的。

为了最大化的提升IO性能，缓存池也采用raid0。同样采用默认的Stripe Size。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


## 先检查一下hybrid这个VG还剩下多少个PE
vgdisplay hybrid

## 从输出可以看出还剩下54144个PE
  --- Volume group ---
  VG Name               hybrid
  System ID             
  Format                lvm2
  Metadata Areas        4
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               0
  Max PV                0
  Cur PV                4
  Act PV                4
  VG Size               <3.86 TiB
  PE Size               4.00 MiB
  Total PE              1010894
  Alloc PE / Size       956750 / <3.65 TiB
  Free  PE / Size       54144 / 211.50 GiB
  VG UUID               13c6EC-n2E4-nQvh-hD5J-q8F1-Hl73-77pkji

## 为后面的转换预留2944个PE即11.5GiB用作备用池元数据LV，其他的共51200个PE创建缓存池数据LV
lvcreate --type raid0 --name cache --extents 51200 hybrid /dev/sdd1 /dev/sde1

## 输出
  Using default stripesize 64.00 KiB.
  Logical volume "cache" created.

转换存储类型

转换hybrid/cache这个LV的类型为缓存池cache-pool，设置chunksize为256KiB，指定缓存池元数据LV为之前已经在SSD上以raid0创建的hybrid/meta_cachepool：

1

lvconvert --type cache-pool --poolmetadata hybrid/meta_cachepool --chunksize 256 hybrid/cache

这一步操作中chunksize的值应该参考下方说明中lvmcache有关的说明进行设置。输出如下，这样，缓存池元数据LVhybrid/meta_cachepool和缓存池数据LVhybrid/cache就合并成新的缓存池LV了。

1
2
3
4


  WARNING: Converting hybrid/cache and hybrid/meta_cachepool to cache pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert hybrid/cache and hybrid/meta_cachepool? [y/n]: y
  Converted hybrid/cache and hybrid/meta_cachepool to cache pool.

有关chunksize的说明

The size of chunks in a snapshot, cache pool or thin pool. For snapshots, the value must be a power of 2 between 4KiB and 512KiB and the default value is 4. For a cache pool the value must be between 32KiB and 1GiB and the default value is 64. For a thin pool the value must be between 64KiB and 1GiB and the default value starts with 64 and scales up to fit the pool metadata size within 128MiB, if the pool metadata size is not specified. The value must be a multiple of 64KiB. See lvmthin(7) and lvmcache(7) for more information. 机翻：快照、缓存池或精简池中的块大小。对于快照，该值必须是2的幂，介于4KB和512KB之间，默认值为4。对于缓存池，该值须介于32KiB和1GiB之间，并且默认值为64。对于精简池，该数值必须介于64KiB和1GiB之间，如果未指定池元数据大小，则默认值从64开始，并按比例放大以适应128MiB内的池元数据大小。该值必须是64KiB的倍数。有关更多信息，请参见lvmthin和lvmcache。

lvmthin：

When a thin pool is used primarily for the thin provisioning feature, a larger value is optimal. To optimize for many snapshots, a smaller value reduces copying time and consumes less space. 机翻：当精简池主要用于精简资源调配功能时，最好使用较大的值。要优化多个快照，较小的值可以减少复制时间并消耗更少的空间。

lvmcache：

Using a chunk size that is too large can result in wasteful use of the cache, in which small reads and writes cause large sections of an LV to be stored in the cache. It can also require increasing migration threshold which defaults to 2048 sectors (1 MiB). Lvm2 ensures migration threshold is at least 8 chunks in size. This may in some cases result in very high bandwidth load of transfering data between the cache LV and its cache origin LV. However, choosing a chunk size that is too small can result in more overhead trying to manage the numerous chunks that become mapped into the cache. Overhead can include both excessive CPU time searching for chunks, and excessive memory tracking chunks. 机翻：使用过大的块大小可能会导致缓存的浪费使用，在这种情况下，较小的读取和写入会导致LV的较大部分存储在缓存中。它还可能需要增加迁移阈值，默认为2048个扇区（1个MiB）。Lvm2确保迁移阈值的大小至少为8个块。在某些情况下，这可能导致在高速缓存LV与其高速缓存源LV之间传输数据的非常高的带宽负载。然而，选择太小的块大小可能会导致管理映射到缓存中的大量块的更多开销。开销可能包括过多的CPU时间搜索块，以及过多的内存跟踪块。

把之前在HDD上创建的hybrid/data这个LV的类型转换为带缓存池LV（hybrid/cache）的存储类型，指定缓存池为刚刚合并后的缓存池LVhybrid/cache，设置缓存模式为writeback：

1

lvconvert --type cache --cachepool hybrid/cache --cachemode writeback hybrid/data

输出如下，这样，数据LVhybrid/data就和缓存池LVhybrid/cache合并成新的带缓存池的LVM存储hybrid/data了，这个时候它还不是LVM-thin存储。

1
2
3


Do you want wipe existing metadata of cache pool hybrid/cache? [y/n]: y
  WARNING: Data redundancy could be lost with writeback caching of raid logical volume!
  Logical volume hybrid/data is now cached.

缓存模式可选择如下，我都raid0了，已经无所畏惧了，所以我选择writeback，数据丢了就丢了吧：

writeback: writeback considers a write complete as soon as it is stored in the cache pool.

writethough: writethough considers a write complete only when it has been stored in both the cache pool and on the origin LV. While writethrough may be slower for writes, it is more resilient if something should happen to a device associated with the cache pool LV.

passthrough: With passthrough, all reads are served from the origin LV (all reads miss the cache) and all writes are forwarded to the origin LV; additionally, write hits cause cache block invalidates. See lvmcache(7) for more information.

再把刚刚合并的带缓存池的LVM存储hybrid/data与之前创建的元数据LVhybrid/meta_thinpool合并转换为最终需要的LVM-thin存储：

1

lvconvert --type thin-pool --poolmetadata hybrid/meta_thinpool hybrid/data

有关chunksize的具体说明见上方，这一步操作中chunksize的值应该参考上方说明中lvmthin有关的说明进行设置。如采用默认64KiB的chunksize，最大可支持15.81TiB的LVM-thin。我的输出如下：

1
2
3
4
5


  Thin pool volume with chunk size 64.00 KiB can address at most 15.81 TiB of data.
  WARNING: Converting hybrid/data and hybrid/meta_thinpool to thin pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert hybrid/data and hybrid/meta_thinpool? [y/n]: y
  Converted hybrid/data and hybrid/meta_thinpool to thin pool.

检查

最后，我们来看看LV和物理磁盘的情况

1

lvs -a -o lv_full_name,parent,lv_size,modules,devices

输出如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


LV                                Parent              LSize   Modules              Devices                                                    
hybrid/cache_cpool                                    200.00g cache,raid           cache_cpool_cdata(0)                                       
hybrid/cache_cpool_cdata          [cache_cpool]       200.00g raid                 cache_cpool_cdata_rimage_0(0),cache_cpool_cdata_rimage_1(0)
hybrid/cache_cpool_cdata_rimage_0 [cache_cpool_cdata] 100.00g                      /dev/sdd1(1538)                                            
hybrid/cache_cpool_cdata_rimage_1 [cache_cpool_cdata] 100.00g                      /dev/sde1(1538)                                            
hybrid/cache_cpool_cmeta          [cache_cpool]       528.00m raid                 cache_cpool_cmeta_rimage_0(0),cache_cpool_cmeta_rimage_1(0)
hybrid/cache_cpool_cmeta_rimage_0 [cache_cpool_cmeta] 264.00m                      /dev/sdd1(0)                                               
hybrid/cache_cpool_cmeta_rimage_1 [cache_cpool_cmeta] 264.00m                      /dev/sde1(0)                                               
hybrid/data                                            <3.64t cache,raid,thin-pool data_tdata(0)                                              
hybrid/data_tdata                 data                 <3.64t cache,raid           data_tdata_corig(0)                                        
hybrid/data_tdata_corig                                <3.64t raid                 data_tdata_corig_rimage_0(0),data_tdata_corig_rimage_1(0)  
hybrid/data_tdata_corig_rimage_0  [data_tdata_corig]   <1.82t                      /dev/sdb1(0)                                               
hybrid/data_tdata_corig_rimage_1  [data_tdata_corig]   <1.82t                      /dev/sdc1(0)                                               
hybrid/data_tmeta                 data                 11.50g raid                 data_tmeta_rimage_0(0),data_tmeta_rimage_1(0)              
hybrid/data_tmeta_rimage_0        [data_tmeta]          5.75g                      /dev/sdd1(66)                                              
hybrid/data_tmeta_rimage_1        [data_tmeta]          5.75g                      /dev/sde1(66)                                              
hybrid/lvol0_pmspare                                   11.50g                      /dev/sdd1(27138)                                           
hybrid/lvol0_pmspare                                   11.50g                      /dev/sde1(27138)                                           
pve/root                                              <29.50g                      /dev/sda3(512)                                             
pve/swap                                                2.00g                      /dev/sda3(0) 

从输出中的Layout和Devices字段可以看出，hybrid/data这个综合了raid0、缓存池和具有thin功能的LVM-thin，内部的各个下级LV：

它的数据LVdata_tdata大小是3.64TiB，其实就是两块HDD大小之和（2T盘的实际大小是1.82TiB），它的原始（orig）数据LV是data_tdata_corig，而data_tdata_corig是由两块HDD的/dev/sdb1和/dev/sdc1分区组的raid0（data_tdata_corig_rimage_0和data_tdata_corig_rimage_1）；
它所需要的元数据LV（即data_tmeta）大小是11.5GiB，也是raid0组，这个raid0组位于两块SSD上，即data_tmeta_rimage_0和data_tmeta_rimage_1；
它有一个缓存池LVcache_cpool，而缓存池LVcache_cpool本身又分为数据和元数据两部分：

缓存池数据LV是cache_cpool_cdata，总大小200GiB，是位于两块SSD上的cache_cpool_cdata_rimage_0和cache_cpool_cdata_rimage_1组成的raid0；
缓存池元数据LV是cache_cpool_cmeta，总大小528MiB，也是由位于两块SSD上的cache_cpool_cmeta_rimage_0和cache_cpool_cmeta_rimage_1组成的raid0。

转换存储类型还生成了lvol0_pmspare，这个是自动创建的备用池元数据LV，备用池元数据LV是在修复池时可以使用的保留空间。它的大小等同于最大的元数据LV大小（我创建的两个元数据LV中较大的是11.5GiB）。如想关闭自动创建这种类型的LV，需要在与元数据LV有关的两次转换命令lvconvert中添加--poolmetadataspare n。如果设置了不自动创建，那么前面的存储类型转换时也就不需要提前预留空间。虽然看起来有两个（因为我进行了两次与元数据有关的转换lvconvert），但实际上是在两块SSD上总共占用11.5GiB，每块SSD各5.75GiB。

每块SSD上的LV有：缓存池数据LV（cache_cpool_cdata）100GiB，缓存池元数据LV（cache_cpool_cmeta）264MiB，元数据LV（data_tmeta）5.75GiB，备用池元数据LV（lvol0_pmspare）5.75GiB。以上总计111.76GiB，这就是120G的SSD的真实大小。

这样，将元数据LV、缓存池数据LV、缓存池元数据LV全部放在SSD上以提升IO性能，两块HDD组成数据LV以保存原始数据，那么HDD大小之和3.64TiB就是这个LVM-thin存储的最终大小。

再以另外一个角度来看：

1

lsblk

从输出也可以看到HDD上只有data，两个metadata和cache全部位于SSD：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


NAME                                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                                     8:0    0    32G  0 disk 
├─sda1                                  8:1    0  1007K  0 part 
├─sda2                                  8:2    0   512M  0 part 
└─sda3                                  8:3    0  31.5G  0 part 
  ├─pve-swap                          253:0    0     2G  0 lvm  [SWAP]
  └─pve-root                          253:1    0  29.5G  0 lvm  /
sdb                                     8:16   0   1.8T  0 disk 
└─sdb1                                  8:17   0   1.8T  0 part 
  └─hybrid-data_tdata_corig_rimage_0  253:11   0   1.8T  0 lvm  
    └─hybrid-data_tdata_corig         253:13   0   3.6T  0 lvm  
      └─hybrid-data_tdata             253:14   0   3.6T  0 lvm  
        └─hybrid-data                 253:15   0   3.6T  0 lvm  
sdc                                     8:32   0   1.8T  0 disk 
└─sdc1                                  8:33   0   1.8T  0 part 
  └─hybrid-data_tdata_corig_rimage_1  253:12   0   1.8T  0 lvm  
    └─hybrid-data_tdata_corig         253:13   0   3.6T  0 lvm  
      └─hybrid-data_tdata             253:14   0   3.6T  0 lvm  
        └─hybrid-data                 253:15   0   3.6T  0 lvm  
sdd                                     8:48   0 111.8G  0 disk 
└─sdd1                                  8:49   0 111.8G  0 part 
  ├─hybrid-data_tmeta_rimage_0        253:2    0   5.8G  0 lvm  
  │ └─hybrid-data_tmeta               253:4    0  11.5G  0 lvm  
  │   └─hybrid-data                   253:15   0   3.6T  0 lvm  
  ├─hybrid-cache_cpool_cdata_rimage_0 253:5    0   100G  0 lvm  
  │ └─hybrid-cache_cpool_cdata        253:7    0   200G  0 lvm  
  │   └─hybrid-data_tdata             253:14   0   3.6T  0 lvm  
  │     └─hybrid-data                 253:15   0   3.6T  0 lvm  
  └─hybrid-cache_cpool_cmeta_rimage_0 253:8    0   264M  0 lvm  
    └─hybrid-cache_cpool_cmeta        253:10   0   528M  0 lvm  
      └─hybrid-data_tdata             253:14   0   3.6T  0 lvm  
        └─hybrid-data                 253:15   0   3.6T  0 lvm  
sde                                     8:64   0 111.8G  0 disk 
└─sde1                                  8:65   0 111.8G  0 part 
  ├─hybrid-data_tmeta_rimage_1        253:3    0   5.8G  0 lvm  
  │ └─hybrid-data_tmeta               253:4    0  11.5G  0 lvm  
  │   └─hybrid-data                   253:15   0   3.6T  0 lvm  
  ├─hybrid-cache_cpool_cdata_rimage_1 253:6    0   100G  0 lvm  
  │ └─hybrid-cache_cpool_cdata        253:7    0   200G  0 lvm  
  │   └─hybrid-data_tdata             253:14   0   3.6T  0 lvm  
  │     └─hybrid-data                 253:15   0   3.6T  0 lvm  
  └─hybrid-cache_cpool_cmeta_rimage_1 253:9    0   264M  0 lvm  
    └─hybrid-cache_cpool_cmeta        253:10   0   528M  0 lvm  
      └─hybrid-data_tdata             253:14   0   3.6T  0 lvm  
        └─hybrid-data                 253:15   0   3.6T  0 lvm

添加存储

把创建好的LVM-thin存储添加到PVE，就大功告成了：

添加LVM-thin存储，ID自己取

1000进制看起来就是4T

顺便再看看磁盘空间有没有100%利用完全：

4块磁盘都100%利用了

参考资料

lvm, pvcreate, vgcreate, lvcreate, lvconvert, lvreduce, lvremove, lvs, lvmraid, lvmthin, lvmcache

在上述参考资料链接下方可以看见全部命令的帮助文档，同时也可以直接在PVE命令行中输入man <cmd>来查阅上述文档。

前言