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;
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 开源Multi-agent AI智能体框架aevatar.ai,欢迎大家贡献代码
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
2013-12-11 bigdata