Reco wrote: > Petter Adsen wrote: > > > Resizing just works, as long as you don't forget the correct order for > > > changing the filesystem and the volume. I.e. > > > > > > 1) Enlarge - volume first, filesystem last. > > > 2) Reduce - filesystem first, volume last.
I am compelled to note that resizing for increasing works great. But resizing for shrinking is very, very, very slow. Shrinking isn't a very well used path. It works. If you have ten days to let it complete with out power failure. Avoid every shrinking a file system. If you must shrink it is much better to backup, create new of smaller size, restore from backup. > > I expect the combination of ext4 and LVM is so common that ext4 would > > be a good choice of filesystem if I ever get the need to resize? I pretty much agreed with everything Reco said. I set up my own machines with mdadm RAID1. On top of that is LVM. On top of that is ext4. I always use a separate /boot on mdadm RAID1 without LVM using ext2 simply to avoid the wasted space of a journal on that file system. I RAID1 everything including swap. This may not be an exciting combination but the combination works reliably. You mention wanting to use snapshots so I must suggest spending some time researching blog articles on lvm snapshots. I have heard of issues concerning race conditions in the code path leading to corruption. I have heard some bad things about LVM at that intersection. Sorry I can't recall specifics but it had to do with continuous build systems that were exercising the path all of the time and tripping over problems with it. I wish I had a URL to reference. I would be very happy if someone countered this with information saying the opposite. Bob
signature.asc
Description: Digital signature
