|
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; (责任编辑：IT) |