On 4/8/21 11:43 AM, Nicolas Kovacs wrote:
# yum install cloud-utils-growpart
# lsblk
# growpart -v /dev/sda 3
# resize2fs /dev/sda3
Now here's my question (finally): is there any risk involved in this sort of
operation? Or can it be performed on a production system without having to
worry about data loss?
Risk from a Virtual Machine perspective or just generally? One of the
many operations I do often with VMs is "mess" with disks treating them
as logical devices means I can add storage later, easy, when needed. In
most cases I don't take the system down at all. "It just works".
But there are always risks. If you're doing this manually, typos can
bring down your system. Another part of your risk is using partitions.
Partions, particular the "system" drive where rootfs is, can act oddly
on Linux when it's live. It's not rare that you find the kernel refusing
to do a "partprobe" on /dev/sda - which means you need a reboot for the
kernel to see the new size of a partition. Next, your partition stuff is
very limited - compared to so many other things you have in CentOS you
should really avoid using partitions for anything - well, perhaps but
that's about it.
I use LVM on all my systems. To expand a system I simply add a new
virtual disk, expand the VG, and then expand the filesystem using
"lvexpand -r". It's painless and there are no risks of conflicts. LVM
allows me to remove the disk later if need be - ie. the first disk size
you added was 50GB but you realize a few months later that you
calculated wrong as should have added 500GB. LVM allows you to add a new
disk of 500GB, move everything from the old disk to the new, and then
you can remove the new one - all without taking down the file system!
It also comes with snapshot features for persistent backups. So at a
risk of sounding like a broken record, don't use partitions. If risk is
what you're focused on, there's a lot more risk using plain partitions
vs. volume management.
--
Regards
Peter Larsen
_______________________________________________
CentOS mailing list
[email protected]
https://lists.centos.org/mailman/listinfo/centos
