Growing filesystems and disks
You generally only need to grow your filesystems after you've purchased more disk space. In most cases, BitFolk will perform the resize of the underlying block device for you leaving you to do a resize of the filesystem using tools like resize2fs (ext2/3/4 filesystems).
The exact details however depend on the style of disk layout in use by your VPS. Several different styles are in use and which one your VPS is using depends on which was in favour at the time it was provisioned.
If you plan on having many different partitions which will need resizing from time to time then it would be a good idea to consider using LVM from the start.
Disk layout styles
The currently favoured style is for a VPS to be supplied with partitioned block devices, with each disk device having only one partition. The most commonly deployed style is one or more disk devices with filesystems directly placed on them. This style was abandoned because it confused too many operating system installers and support scripts.
If you reinstall your VPS using the self-serve net installer then its disk layout will be converted to the currently favoured style.
Here follows some notes on how to confirm which style of disk layout you have, and how you would go about growing filesystems within it. Commands listed in the "confirmation" sections are safe to run as they only attempt to read from the devices, but if in doubt please verify before running.
Appropriate levels of caution
Generally anything which purely reads from a block device cannot cause any damage.
Using resize2fs for growth has never been observed to cause data loss, though a crash in the middle of its operation could cause disaster. Using it for shrinking filesystems is fraught with danger and not recommended unless you know what you're doing. It's outside the scope of this article.
 Warning: | Anything which alters the partition table of a block device should be done with extreme care. Backups are highly recommended. Asking BitFolk for a disk snapshot would also be wise. Operations which require modifications to a disk's partition table are normally carried out by BitFolk on your behalf due to the high risk of disaster. |
Disk layouts in use at BitFolk
This is currently not a complete list, but does cover almost all cases.
Filesystems on partitioned disk devices
In this style you'll have one or more (by default two) disk devices which will be partitioned with a single partition spanning the whole disk. Typically /dev/xvda will contain your root filesystem on /dev/xvda1 and /dev/xvdb will contain your swap device on /dev/xvdb1.
This is currently the favoured style of disk layout.
Confirmation
$ mount
/dev/xvda1 on / type ext3 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
$ sudo fdisk -lu /dev/xvda
Disk /dev/xvda: 4026 MB, 4026531840 bytes
103 heads, 61 sectors/track, 1251 cylinders, total 7864320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00092cae
Device Boot Start End Blocks Id System
/dev/xvda1 * 2048 7862271 3930112 83 Linux
The above output suggests a single partition spanning all of /dev/xvda on which an ext3 filesystem has been placed.
Growing
Normally BitFolk will alter the partition table of the relevant disk device for you. On modern kernels, the guest will detect that the disk has been grown, like this:
Nov 9 17:45:14 debtest1 kernel: [151835.239252] Setting capacity to 83886080
Nov 9 17:45:14 debtest1 kernel: [151835.239273] xvda: detected capacity change from 32212254720 to 42949672960
…but the xvda1 partition will still appear to be the same size because the partition table has not been re-read yet. Again on modern kernels you can force a reread of the partition table with:
$ sudo partprobe /dev/xvda
If these steps don't work then you will need to reboot.
Once you see a larger disk and partition within it, your filesystem is now ending some way before the end of the partition. Use of resize2fs will then grow the filesystem, online if necessary:
$ sudo resize2fs -p /dev/xvda1
resize2fs is for ext filesystems, e.g. the most common Linux filesystems ext3 and ext4. If you are using some other filesystem such as btrfs or xfs there will be different commands.
If you have for some reason re-partitioned a disk device to have multiple partitions then BitFolk will be unable to grow any of the partitions except the last one. In this case BitFolk will grow only the disk device and you'll be left to re-partition things within it yourself. For this reason it is recommended that you stick to only one partition per disk device. If you require additional disk devices then these can be provided easily; please submit a support ticket.
Filesystems directly on disk devices
In this style, you'll have a block device such as /dev/xvda which you would normally expect to be a disk, but instead it will have a filesystem directly upon it.
This layout is now deprecated though still accounts for the majority of running BitFolk VPSes; despite the fact that it has so far worked fine in the normal operation of a server, many of the operating system installers can't handle an unpartitioned disk device. Since any kind of reinstall will require conversion to partitioned devices, partitioned devices are now favoured to begin with.
Confirmation
You can expect output such as this:
$ mount
/dev/xvda on / type ext3 (rw,noatime,nodiratime)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
$ sudo tune2fs -l /dev/xvda
tune2fs 1.41.3 (12-Oct-2008)
Filesystem volume name: /
Last mounted on: <not available>
Filesystem UUID: d3249498-3e26-42c5-99a8-73fdd7ebcacb
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
.
.
.
The above suggests an ext3 filesystem directly on /dev/xvda.
You can verify that /dev/xvda isn't partitioned by trying to list its partition table:
$ sudo fdisk -lu /dev/xvda
Disk /dev/xvda: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
Disk /dev/xvda doesn't contain a valid partition table
(Though the fact that the above VPS is currently running and has / showing mounted directly on /dev/xvda is a large clue.)
Growing
BitFolk will manipulate the size of your block device for you. If your kernel is new enough then it will immediately see the larger block device (check your kernel log or dmesg). If it doesn't see the change then you will need to reboot. At this point you'll have a filesystem that ends before the end of the block device.
A simple:
$ sudo resize2fs -p /dev/xvda
will kick off an online grow of this filesystem.
Filesystems on devices that look like partitions, but no corresponding disk device
In this style you'll have one or more block devices that look like /dev/xvda1 or even /dev/sda1 but the corresponding disk device (/dev/xvda and /dev/sda respectively, in the previous examples) will not exist.
This layout is now deprecated and there are only a few VPSes still running with it; the lack of a disk device has proven confusing to some operating system support scripts such as those used to install new kernels.
Confirmation
Output of mount and tune2fs will be very similar to above, except that the device in question will be something like /dev/xvda1, and the corresponding /dev/xvda will not exist.
Growing
Tools like resize2fs should work exactly as above.
Growing a disk partition yourself
| Warning: | It cannot be over-emphasised how dangerous this is. If you try this with no backups and no snapshot, and it goes wrong, you have a broken VPS. You get to keep both bits, and a link to the self-serve net installer so that you can reinstall. |
The basic concept of growing a disk partition is as follows:
- Get a disk device with some space after the partition you want to grow. Normally achieved by installing your VPS with disk devices smaller than your disk allowance, or buying more disk from BitFolk while specifying you want to do the resize yourself.
- Delete the partition with a partition editing tool such as fdisk, sfdisk, etc.
- Recreate the partition with the same start sector and a bigger end sector than it had before, so the partition becomes larger.
- Reboot your VPS.
- Grow filesystem with the usual tools (e.g. resize2fs).
Taking a backup of the partition table
sfdisk is handy for getting a human-readable backup of your partition table that can also be fed back in to sfdisk to restore it:
$ sudo sfdisk -L -d /dev/xvdc > /var/tmp/pt
$ cat /var/tmp/pt
# partition table of /dev/xvdc
unit: sectors
/dev/xvdc1 : start= 2048, size=524283904, Id=83
/dev/xvdc2 : start= 0, size= 0, Id= 0
/dev/xvdc3 : start= 0, size= 0, Id= 0
/dev/xvdc4 : start= 0, size= 0, Id= 0
If you ever needed to put that partition table back again, it'd be something like:
$ sudo sfdisk -L /dev/xvdc < /var/tmp/pt
Deleting and recreating a partition
fdisk works well, but take care to use the -u option so that the exact sector start is visible. Otherwise you risk creating a new partition that doesn't start in the same place the old one did, which would make any filesystem present unreadable.
$ sudo fdisk -u /dev/xvdc
The number of cylinders for this disk is set to 37857.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/xvdc: 311.3 GB, 311385128960 bytes
255 heads, 63 sectors/track, 37857 cylinders, total 608174080 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x000cc892
Device Boot Start End Blocks Id System
/dev/xvdc1 2048 524285951 262141952 83 Linux
Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First sector (63-608174079, default 63): 2048
Last sector or +size or +sizeM or +sizeK (2048-608174079, default 608174079):
Using default value 608174079
Command (m for help): p
Disk /dev/xvdc: 311.3 GB, 311385128960 bytes
255 heads, 63 sectors/track, 37857 cylinders, total 608174080 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x000cc892
Device Boot Start End Blocks Id System
/dev/xvdc1 2048 608174079 304086016 83 Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 22: Invalid argument.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
$
If the partition you altered was your root filesystem then the kernel will not be able to reread it, so you'll now need to reboot and hope it worked. If it didn't work then you should be able to go into the rescue environment and put your old partition table back.
LVM?
- Main article: Logical Volume Manager
The Logical Volume Manager is the usual Linux technology for carving a block device into multiple logical volumes which are easy to resize without all this faffing about with partition tables and risking sending all your data to the bitbucket.
If you foresee a need to do a lot of resizing then you should definitely reinstall your VPS from the start to use LVM. It works fine.