他是整个
LVM
最小的储存区块，也就是说，其实我们的文件资料都是½由写入
PE
来处理的。
简单的说，
这个
PE
就有点像文件系统里面的
block
大小啦
。
这样说应该就比½好理½了吧？
所以调整
PE
会影响到
LVM
的最大容量喔！不过，在
CentOS 6.x
以后，由于直½使用
lvm2
的
各项格式功能，以及系统转为
64
位，因此这个限制已经不存在了。
o
Logical Volume, LV,
逻辑滚动条
最终的
VG
还会被切成
LV
，这个
LV
就是最后可以被格式化使用的类似分区槽的咚咚了！那么
LV
是否可以随意指定大小呢？
当然不可以！既然
PE
是整个
LVM
的最小储存单位，那么
LV
的大小就与在此
LV
内的
PE
总数有关。
为了方便用户利用
LVM
来管理其系统，因此
LV
的
装置文件名通常指定为『
/dev/vgname/lvname
』的样式！
此外，我们刚刚有谈到
LVM
可弹性的变更
filesystem
的容量，那是如何办到的？其实他就是透
过『½换
PE
』来½行数据转换，
½原本
LV
内的
PE
移转到其他装置中以½低
LV
容量，或
½其他装置的
PE
加到此
LV
中以加大容量！
VG
、
LV
与
PE
的关系有点像下图：
图
14.3.1
、
PE
与
VG
的相关性图示
如上图所示，
VG
内的
PE
会分给虚线部分的
LV
，如果未来这个
VG
要扩充的话，加上其他的
PV
即可。
而最重要的
LV
如果要扩充的话，也是透过加入
VG
内没有使用到的
PE
来扩充的！
.
实作流程
透过
PV, VG, LV
的规划之后，再利用
mkfs
就可以½你的
LV
格式化成为可以利用的文件系统了！
而且这个文件系统的容量在未来还能够½行扩充或减少，
而且里面的数据还不会被影响！实在是很
『福气啦！』那实作方面要如何½行呢？很简单呢！
整个流程由基础到最终的½果可以这样看：