/swap.img w/fallocate has holes

[Ebbex]

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;

https://github.com/CanonicalLtd/curtin/commit/a909966f9c235282267024e86adf404dab83ccfe

[Ebbex (eb4x)]

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.

[Ryan Harper (raharper)]

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.

[Scott Moser (smoser)]

The same basic issue is in cloud-init
and had a MP proposed at
 https://code.launchpad.net/~adobrawy/cloud-init/+git/cloud-init/+merge/354680

[Chad Smith (chad.smith)]

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.

[Dan Watkins (oddbloke)]

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.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3211