结论跟您恰恰相反,,, 在Mission Critical (7*24 99.99% uptime)的实际投产环境中,不能做到Online expand - shrink FS 恰恰是绝对不可以接受的. 这种环境中, 连更换CPU/Memory 这种硬伤都是Online 来做的, 我不可以想象加减的文件系统却要求shutdown application.
直接在partition 上建文件系统本来就是古老的思路, 有相当大的局限性. Logical Volume 这个概念的产生就是为了让OS 摆脱对physical partition的依赖, 除了可以实现soft RAID (当然现在都可以在Hard Ware level 实现)以外, 最大的用处就是动态分配存储资源给文件系统. 这也是为什么每个版本的UNIX , 包括LINUX 都有这么一个类似的Logical Volume Manager . 而有经验的SA一般都不会在Physical Patition上直接创建文件系统(系统盘除外).
您说的某些公司直接在Partition 上跑, 这一定是基于文件系统大小几年之内绝不更改,而且能提供足够的Downtime Window for service.
想象一下, 如果一个公司有几百台Servers,一旦某天都要求增加文件系统大小, 可不可以要求公司把所有机器都停了, 通知成千上万的计算机用户, 今天放大假了, 然后再让您来摆布? :))))
言语中如有冒犯, 敬请体谅. 希望以后多多交流, 共同提高 !
直接在partition 上建文件系统本来就是古老的思路, 有相当大的局限性. Logical Volume 这个概念的产生就是为了让OS 摆脱对physical partition的依赖, 除了可以实现soft RAID (当然现在都可以在Hard Ware level 实现)以外, 最大的用处就是动态分配存储资源给文件系统. 这也是为什么每个版本的UNIX , 包括LINUX 都有这么一个类似的Logical Volume Manager . 而有经验的SA一般都不会在Physical Patition上直接创建文件系统(系统盘除外).
您说的某些公司直接在Partition 上跑, 这一定是基于文件系统大小几年之内绝不更改,而且能提供足够的Downtime Window for service.
想象一下, 如果一个公司有几百台Servers,一旦某天都要求增加文件系统大小, 可不可以要求公司把所有机器都停了, 通知成千上万的计算机用户, 今天放大假了, 然后再让您来摆布? :))))
言语中如有冒犯, 敬请体谅. 希望以后多多交流, 共同提高 !