Change:
${optionalString (sw.size != null) '' currentSize=$(( $(stat -c "%s" "${sw.device}" 2>/dev/null || echo 0) / 1024 / 1024 )) if [ "${toString sw.size}" != "$currentSize" ]; then <del> fallocate -l ${toString sw.size}M "${sw.device}" || dd if=/dev/zero of="${sw.device}" bs=1M count=${toString sw.size} if [ "${toString sw.size}" -lt "$currentSize" ]; then truncate --size "${toString sw.size}M" "${sw.device}" fi </del> <ins> dd if=/dev/zero of="${sw.device}" bs=1M count=${toString sw.size} </ins> chmod 0600 ${sw.device} ${optionalString (!sw.randomEncryption.enable) "mkswap ${sw.realDevice}"} fi

Discussion:
Describe the bug I have the following in my : but the service fails with: Apparently this is because the swapfile is created by : which kernel does not like. See the and the . Running nixos-unstable @ .
As a walkaround, I ran the code path manually: The size you use for the dd command needs to exactly match the size set in the module, otherwise the module will , ruining your work.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Any update here?
The fix should be rather straightforward: the branch. out how to detect files with holes in them. that as another condition that will trigger when not fulfilled. it thoroughly.
To clarify: these files does not have holes. It's a bug in the kernel causing the kernel to think it has holes when using it as swap.
Tagging this for 20.09 since it will likely break swap for people upgrading. cc
There is now a patch that's likely to be merged:
Just as a reminder, the 20.09 release is scheduled to happen this monday, the 28th. If this is still relevant to blocking the release, then there should be some forward movement. A blocker meeting has still yet to be scheduled. But, if you consider this item to still warrant blocking the entirety of the nixos-20.09 release, then please post on the . A template for proposing an item can be found
Looks like → bump so people using swap created by the module and running already encountered the bug. People using regular will not be affected in 20.09 since it still points to . Moving this to 21.03 Blockers.
Since this is a good first bug, I'd like to help with this. I'm a bit confused with the approach to this though. says that a patch was applied for the problem, but I don't see it in the . Can we use an overlay to add the patch to the package?
I would expect would be the right place to add a patch to, plus listing it in (search for ). For testing, you can use NixOS option.
I made a PR .

I'll tag you in there, you can take a look whenever you can find the time :)
I don't think this is only a linux 5.7 bug, I have the same issue on 5.4 with /swapfile on f2fs. I think it is dependent on how the file system implements whatever calls fallocate uses, so I think the dd fallback is a better general solution than the ext4 patch.
Maybe we should support more file system specific behavior at runtime of the creation script using something like for example to create nocow files on btrfs. If not I think we should always use dd since it is the most portable option, as noted below. From man page SWAPON(8)
NixOS 20.09 Linux Kernel 5.11.1 For those of you who are still having this problem, the following has worked well for me: The proper way to create a Swap file on BTRFS is , so I set up a systemd service to create this file for me that is wanted by the NixOS defined in my file. This will create the non-compressed, CoW disabled file in my subvolume. Then I leave the allocation and enabling of the swap file to NixOS in hardware- As you can see, my succeeds and upon verification the file is enabled and allocated according to my definition. <img width="398" alt="image" src="https://user-"
I marked this as stale due to inactivity. &rarr;
adding logic for btrfs should be pretty simple but we need to figure out if the target location will be a file or a partition

We could also only on filesystems where it's sure to work. (Just on this topic, we should probably too if possible) CC as the person behind the most changed lines in
Related
Ah, theres even a comment there with the same man page text! Closing in favor of that one.