preFace
APP scenario description:
当你未能合理的规划存储时,在后期的维护工作中可能会涉及的存储的 再规划(eg,某一个 or 数个App 对某一个lv 即挂载点写BigData,你的那个lv的挂载点便会很快就没空间了,但是值得注意的是,你的另外的一个lv的挂载点的存储空间却很大?基本没应用对这个lv的挂载点上写数据?) 根据前面的描述,我们知道我们可能可以选择的问题解决方案是
1,改变应用的写数据位置(难搞?方案分析,加入前期你ins一个Oracle初始化时设定数据保存目录,而恰巧这个oracle的应用数据又很大?一个云计算平台软件配置设定deploy vm Disk保存路径?.....)
2,在vg中心添加pv,直接扩展BigData保存数据的挂载点所在的lv or vg 上有PVfree （这个我们在之前已经讲过具体的操作了）posts见以下Url
http://www.cnblogs.com/ruiy/p/4156426.html
3,你的一个挂载点的lv空间没了(有BigData的App对这个lv挂载点上写bigData),而恰巧另外的一个或N多个挂载点的lv剩余空间很大,且几乎没什么应用对上写数据 or 写很少的数据,则你就可以选择reduce 这个lv的存储空间到vg,再用这些缩减出来的空间扩到不够的lv上!
linux系统中默认 使用数个PV or 单个独立Pv的某个partition 创建vg,再在vg中建立lv,最后使用LVM来维护真个环境(达到动态维护OS的存储)
linux 磁盘空间扩容 vg(+pv) lv(+空间) lv(缩减磁盘空间)
原文：http://www.cnblogs.com/ruiy/p/4158419.html