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的存储)
into topic or theme:
实测如上第三项描述的vg中的一个挂载点空间不足(即挂载点的lv空间不足,但却仍有bigData写入数据需求,而另外一个 or 多个lv剩余空间很大却几乎无bigdata写入需求)
1,查看OS中的所有pv 及各个pv 总空间及剩余存储空间
pvs
echo "- - -" > /sys/class/scsi_host/host2/scan
添加一块硬盘,并使用其创建pv,pvcreate
/dev/mapper/vg_ruiy-lv_vm_rui002 /ruiy_lv002 ext4 defaults 1 1 (vg中lvOS启动自动,语句写入到/etc/fstab)
最终,最成功的测试结果就是:
将/dev/mapper/vg_ruiy-lv_vm_rui001 （/ruiy_lv001）由当前的可用14G改为4G
/dev/mapper/vg_ruiy-lv_vm_rui002 （/ruiy_lv002） 由可用2.8G增加10G
亲,我们开始吧;
问题出来了
e2fsck -f /dev/mapper/vg_ruiy-lv_vm_rui001
e2fsck == fsck
出现上面的问题是由于缩减lv空间的顺序不对,请以此为鉴!
ruiy未完待续......
adjuncts,/dev/mapper/ /dev/volumeGroup/目录中的lv文件overView;
