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;