Knowledge base

Attach an extra NVMe volume and mount it

Finding the new block device, picking a filesystem, mounting it so a missing disk cannot stop the boot, and growing it later without downtime.

The device appears without a reboot

Extra NVMe is an add-on sold per five hundred gigabytes, and it is hot-attached. The volume shows up as a new block device within a few seconds of the order settling. Nothing restarts.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

The root disk is vda; the new one takes the next letter. If it has not appeared, give udev a moment and look again:

udevadm settle
ls /sys/class/block

Skip the partition table

A partition on a virtual disk buys you nothing and adds a step every time the volume grows. Put the filesystem straight on the device:

mkfs.ext4 -L data /dev/vdb

Or, for large files written by many threads at once:

mkfs.xfs -L data /dev/vdb

ext4 shrinks offline, XFS never shrinks at all. XFS is quicker at parallel metadata, ext4 is more forgiving of everything else. For most people that is the entire decision.

Mount it so a missing volume cannot stop the boot

Use the label. Device order is not guaranteed across a rebuild, and vdb today can be vdc tomorrow.

mkdir -p /srv/data
echo "LABEL=data /srv/data ext4 defaults,noatime,nofail,x-systemd.device-timeout=10s 0 2" >> /etc/fstab
systemctl daemon-reload
mount -a
findmnt /srv/data

nofail and the device timeout are the important part of that line. Without them, an instance that boots before the volume is attached sits in the emergency shell waiting for a disk, and you get to read the console article earlier than planned.

Trim on a timer, not on every delete

Do not add the discard mount option. Continuous discard issues a trim on every unlink, and on a busy filesystem it costs more than it returns. Run it periodically instead:

systemctl enable --now fstrim.timer
fstrim -v /srv/data

Growing the volume

Order more capacity, then extend the filesystem in place. No unmount, no reboot.

lsblk -o NAME,SIZE
resize2fs /dev/vdb          # ext4, by device
xfs_growfs /srv/data        # XFS, by mount point

Getting those two the wrong way round produces a confusing error message and no damage whatsoever, which is the correct way for a tool to behave.

If you want it encrypted

cryptsetup luksFormat --type luks2 /dev/vdb
cryptsetup open /dev/vdb data
mkfs.ext4 -L data /dev/mapper/data

Understand the consequence first. A passphrase-protected volume cannot mount unattended, so every reboot needs a person on the console typing it. Putting the key file on the root disk removes that problem and most of the benefit at the same time. Choose deliberately rather than by default.

Sanity check the hardware

fio --name=rw --rw=randwrite --bs=4k --size=2G --numjobs=4 --iodepth=32 --direct=1 --runtime=60 --time_based --group_reporting

Run that on the new volume, never on /, and never on a filesystem holding something you want to keep. If the result is an order of magnitude below what the hardware page describes, open a ticket with the output and we will look at the host rather than at you.

Ready when you are

Pick a city. Pick a size. Pay in coin.

No forms about who you are, no wait for a human to approve you, no phone call to verify anything. The invoice clears and the credentials land in your inbox.