Hi,
Well, assume that the customer has /dev/xvda with a
filesystem
directly on it, no partition table, and they want to grow that. The
process is as follows:
1. We enlarge their volume on the host.
2. Some time later the customer shuts down and boot their VPS again
to see the larger /dev/xvda.
3. Customer then does resize2fs /dev/xvda to online grow their root
filesystem into the new space.
You have to admire the simplicity of this; it's pretty hard to get a
shut down / boot wrong, and then you just type "resize2fs" with no
parameters and it's done.
Assume instead that the customer has a partitioned
/dev/xvda with
xvda1 as / and xvda2 as a swap partition. Now the process is more
like:
1. We enlarge their volume on the host
2. Some time later the customer shuts down and boot their VPS again
to see the larger /dev/xvda.
3. Customer can't just enlarge xvda1 because the swap partition
xvda2 is in the middle. So, delete that.
4. Edit partition table to delete xvda1 and recreate it again
larger. Note that it fails to tell the OS about the new partition
layout because it's in use.
5. Reboot again to see the larger xvda1 device.
6. Online resize of xvda1 with resize2fs.
7. Recreate swap (or use swapfile).
You can see that the second process is much more complicated than
the first. Not only that but it contains a number of terrifying
steps such as step 4 where the partition for the root filesystem is
deleted. I shudder at the thought of inexperienced sysadmins doing
things like this. I don't like doing it myself.
Without concocting a solution that is the worst of both worlds, might I
propose something along the lines of:
Assumptions:
+ Most customers will want 1 Linux partition and 1 swap partition.
+ The customers that want more than that will know what they are doing:
+ How to apportion the space.
+ How to (work out how to) use LVM.
Therefore:
+ Allocate one block device for the root partition.
+ Allocate one block device for the swap partition.
+ Have a policy of only one partition on the first block device.
+ To appease RedHat, have a partition table on the first block that
only contains one partition.
Then, when a customer wants to grow the root partition, bitfolk can have
a tool that grows the partition and edits the partition table so it's
just a matter of "resize2fs" for the customer. Of course, it is possible
to write this tool defensively: in the single partition case it knows
how to edit the table and if it finds more than one partition then you
don't have a situation that's any worse than the status quo (and they
were a good band, anyway).
Having installed a RedHat system it is subsequently much easier to
create file systems on entire block devices so things can be copied
around and reconfigured after the installation where necessary.
Of course, all I've done is moved the complexity around: now it's all up
front. This means that the bullet can be bitten and, hopefully, the
customers need not end up with a particularly complicated workflow:
1. We enlarge their volume on the host.
1.5: We enlarge their partition table on the host.
2. Some time later the customer shuts down and boot
their VPS again
to see the larger /dev/xvda.
3. Customer then does resize2fs /dev/xvda to online grow their root
filesystem into the new space.
Regards,
@ndy
--
andyjpb(a)ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF