/swap.img w/fallocate has holes

Bug #1781781 reported by Ebbex
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

The /swap.img file on an XFS root filesystem is not being used. The dmesg says it "has holes".

From the swapon manpage;

The swap file implementation in the kernel expects to be able to write to the file directly, without the assistance of the filesystem. This is a problem on preallocated files (e.g. fallocate(1)) on filesystems like XFS or ext4, and on copy-on-write filesystems like btrfs.

It is recommended to use dd(1) and /dev/zero to avoid holes on XFS and ext4.

I've tracked down this commit which seems to be a step in the right direction;


Related branches

Revision history for this message
Ebbex (eb4x) wrote :

So I've checked it out, and ext4 seems to work fine with fallocate. It could perhaps be considered a filesystem-bug as it seems that some xfs-developers are aware of the issue; https://www.spinics.net/lists/linux-mm/msg147100.html But it would be beneficial to have a work-around until that gets sorted.

Revision history for this message
Ryan Harper (raharper) wrote :

Yes, from my reading, this is an xfs (btrfs) specific issue w.r.t how they don't handle converting a fallocated file into swap space.

I think we'll likely do the following:

1) add a integration test which does swapfile enablment via fallocate for each fs and confirms that the target system can use it as swap; we expect this to fail when rootfs is either btrfs or xfs.

2) update curtin swap creation code to check the target filesystem format and for btrfs or xfs filesystems, skip fallocate and use dd instead.

Alternatively, one can use a swap partition instead of a file on the filesystem which avoids this path; that may be preferred to avoid dd'ing gigabytes of data.

Changed in curtin:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Scott Moser (smoser) wrote :

The same basic issue is in cloud-init
and had a MP proposed at

Changed in cloud-init:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Chad Smith (chad.smith) wrote :

A fix landed inin cloud-init upstream for this issue @ https://github.com/canonical/cloud-init/commit/6603706eec1c39d9d591c8ffa0ef7171b74d84d6

If this is still a problem, please re-open this bug task for cloud-init.

Changed in cloud-init:
status: Confirmed → Fix Committed
Revision history for this message
Dan Watkins (oddbloke) wrote : Fixed in cloud-init version 20.1.

This bug is believed to be fixed in cloud-init in version 20.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.