Let systemd Initialise and Grow Filesystems Safely from fstab

By the end, an /etc/fstab entry can ask systemd to initialise an empty filesystem, create swap, or grow a mounted filesystem to the size of its block device. The settings are deliberately persistent: systemd checks the current state at boot and does nothing when the requested work is already complete.

Allow about 15 minutes for a reviewed change and its verification. You need systemd 236 or newer for these fstab options, an entry backed by the intended block device, and root access to edit fstab and inspect boot units. The commands below use a fictional device and mountpoint. Replace them only after checking the device identity.

1. Check the device and filesystem first

Initialising a device is destructive. x-systemd.makefs is designed to skip a device that already has a filesystem signature or other recognised content, but that safeguard is not a substitute for identifying the right device. A typo in a device path can still make a different disk part of your boot configuration.

$ findmnt --target /srv/data
$ lsblk --fs
$ sudo blkid /dev/EXAMPLE_DATA

Use the output to confirm the device, filesystem type, UUID and current mountpoint. If the device is already mounted, do not add a makefs request until you understand why it is being used. Keep a copy of the existing fstab before editing it:

$ sudo cp --preserve=mode,ownership,timestamps /etc/fstab /etc/fstab.before-systemd-makefs

2. Ask systemd to initialise an empty filesystem

Add x-systemd.makefs to the options field of the fstab entry. This option belongs in /etc/fstab; systemd ignores it when it appears in a unit file's Options= setting. The filesystem type in the third field tells systemd which mkfs.type helper to run.

/dev/EXAMPLE_DATA  /srv/data  ext4  defaults,x-systemd.makefs  0  2

On boot, the generated [email protected] instance checks the block device before invoking the filesystem-specific helper. The installed systemd 255 build supplies reasonable defaults for ext2, ext3, ext4, btrfs, XFS, f2fs, vfat and swap, and can set a label and UUID based on the device name for supported types. Do not rely on those defaults when you need a particular label, UUID or feature set; create the filesystem deliberately with the relevant filesystem tool instead.

Reload the generated units after changing fstab:

$ sudo systemctl daemon-reload
$ findmnt --verify --verbose

A successful fstab verification checks syntax and references. It does not initialise the device. Do not reboot a production host just to test a new entry if a maintenance window or an isolated test device is unavailable.

3. Verify a makefs attempt

The makefs service runs immediately before the mount or swap device is used. Start the mount explicitly if that is the intended change:

$ sudo systemctl start srv-data.mount
$ systemctl status srv-data.mount --no-pager
$ findmnt --target /srv/data
$ lsblk --fs /dev/EXAMPLE_DATA

The unit name is derived from the mountpoint, so /srv/data becomes srv-data.mount. If the filesystem creation fails, the mount or swap operation fails too. Inspect both the mount unit and its related makefs service when diagnosing a failure:

$ systemctl list-units 'systemd-makefs@*.service' --all
$ journalctl -b -u 'systemd-makefs@*.service' --no-pager

Once creation succeeds, leave x-systemd.makefs in fstab. On later boots the device is no longer empty, so the request is skipped rather than recreating the filesystem.

4. Create swap with the matching service

For a swap device, use the same persistent option on a swap-style fstab entry. This selects [email protected] rather than a mount unit:

/dev/EXAMPLE_SWAP  none  swap  defaults,x-systemd.makefs  0  0

Before activating this entry, confirm that the device is not holding data. Swap creation writes swap metadata and can make an existing filesystem unusable. After a controlled activation, verify the result:

$ sudo systemctl daemon-reload
$ sudo swapon /dev/EXAMPLE_SWAP
$ swapon --show

To undo the runtime activation, disable it first:

$ sudo swapoff /dev/EXAMPLE_SWAP

Then remove or comment out the fstab line if the swap should not return at boot. Do not run mkswap or a makefs service against an active swap device.

5. Grow a mounted filesystem after its device grows

x-systemd.growfs asks systemd to grow the filesystem to fill the underlying block device. It does not enlarge a partition, logical volume, virtual disk or encrypted container. Expand that lower layer first, then keep the option in fstab:

/dev/EXAMPLE_DATA  /srv/data  ext4  defaults,x-systemd.growfs  0  2

For non-root mountpoints, systemd creates a [email protected] instance. For the root filesystem it uses systemd-growfs-root.service. The installed manpage lists ext4, btrfs, XFS and dm-crypt partitions as supported cases. If the filesystem is already at maximum size, no change is needed.

The helper also has a read-only dry-run mode. Use it to see whether the command can resolve the mountpoint without changing anything:

$ sudo /usr/lib/systemd/systemd-growfs --dry-run /srv/data

For the service-managed path, inspect the result after boot or after starting the generated unit:

$ systemctl status [email protected] --no-pager
$ journalctl -b -u [email protected] --no-pager
$ findmnt --target /srv/data

Unlike creation, a failed grow operation emits a warning rather than failing the mount. Treat that warning as a storage incident: check the filesystem type, the size of the backing device and the relevant kernel or service journal. There is no shrink or undo operation supplied by this systemd feature. A rollback means restoring the lower-layer storage layout from its own backup or snapshot, not removing the fstab option.

6. Keep the two options separate

Makefs and growfs solve different problems. Makefs creates metadata on an empty device and may destroy its previous contents. Growfs expands an existing mounted filesystem and expects the block device to have already grown. Do not add both options to an entry unless you have a specific lifecycle that creates the filesystem first and later expands it, and have tested that lifecycle on disposable storage.

Common distractions are using a unit-file Options= value, assuming a larger virtual disk automatically grows its partition, and checking only that a service was started rather than checking the filesystem size. For a scripted check, compare the filesystem and block-device sizes after the lower layer has changed:

$ findmnt --target /srv/data -o SOURCE,FSTYPE,SIZE,AVAIL,TARGET
$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS /dev/EXAMPLE_DATA