man swapon:

   Files with holes
       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 files with holes or on copy-on-write files on filesystems like Btrfs.

       Commands like cp(1) or truncate(1) create files with holes.  These files will be rejected by swapon.

       Preallocated files created by fallocate(1) may be interpreted as files with holes  too  depending  of  the  filesystem.
       Preallocated swap files are supported on XFS since Linux 4.18.

       The most portable solution to create a swap file is to use dd(1) and /dev/zero.


Anyway, it does not seem like swapon(8) command problem. Reassigning.

Note, this BZ is reported against Fedora, but you use RHEL-8 packages in the bug description, is it intended?

I can reproduce this issue in my system after installed 5.7.0-0.rc2.2.elrdy.x86_64 and found a closed similar bug1129205.

The command failed as swapfile has holes.
[root@ip-10-116-2-81 mnt]# swapon test
swapon: /mnt/test: swapon failed: Invalid argument
[root@ip-10-116-2-81 mnt]# dmesg|tail -1
[  913.896809] swapon: swapfile has holes

I also tried use dd instead of fallocate to create file. No such issue when 'swapon test'. It should be not a swapon problem at least.
It is interesting there is no such issue in 5.6.0-1.elrdy.x86_64 or xfs file system.

I copied comment#3 in below.
<snip>

> How else does one create a swapfile?

dd if=/dev/zero of=swapfile count=8000 bs=1MiB

the problem with fallocate(1) or truncate(1) is that it uses filesystem ioctls to make the allocation fast and effective, the disadvantage is that it does not physically allocate the space -- but swapon(2) syscall requires a real space.

It seems we need a note about it to fallocate(1) man page.

</snip>

(In reply to Karel Zak from comment #1)
> Note, this BZ is reported against Fedora, but you use RHEL-8 packages in the
> bug description, is it intended?

Yes. I'm using upstream kernel so I think it's not proper for RHEL-8 project. Thank you for reassigning it to kernel component!

(In reply to Xiao, Liang from comment #2)
...
> the problem with fallocate(1) or truncate(1) is that it uses filesystem
> ioctls to make the allocation fast and effective, the disadvantage is that
> it does not physically allocate the space -- but swapon(2) syscall requires
> a real space.
> 
> It seems we need a note about it to fallocate(1) man page.

mkswap(8) says: 

"Note that a swap file must not contain any holes.  Using cp(1) to create the file is not acceptable.  Neither is use of fallocate(1) on file systems that support preallocated files, such as XFS or ext4, or on copy-on-write filesystems like btrfs. It is recommended to use dd(1) and /dev/zero in these cases."

After reading that, I would change this bug to an RFE: "[RFE] fallocate should provide an option to create files that do not have holes".

No one should be using a low-level command like "dd" to create files.

As for fallocate(1), it should explicitly mention swap files and recommend how to create them without holes.

Whether this is an RFE bug or a documentation bug, the component should be changed back to util-linux:

$ rpm -qf /usr/bin/fallocate 
util-linux-2.34-4.fc31.x86_64

$ rpm -qf /usr/sbin/mkswap
util-linux-2.34-4.fc31.x86_64

(In reply to Xiao, Liang from comment #2)
> It seems we need a note about it to fallocate(1) man page.

The fallocate command has a "--zero-range" option that sounds like it might work for creating files without holes.

Whether or not it works, fallocate(1) should be more explicit about what it actually does -- does the file have holes or does it not have holes?

> # fallocate -l 1g test
> # chmod 600 test
> # mkswap test
> # swapon test

> Actual results:
> swapon: /mnt/resource/test: swapon failed: Invalid argument

I can't reproduce that with:

kernel 5.5.16-100.fc30.x86_64
util-linux-2.33.2-2.fc30.x86_64

# findmnt /mnt/spare2
TARGET      SOURCE    FSTYPE OPTIONS
/mnt/spare2 /dev/sda4 ext4   rw,relatime,seclabel

# fallocate -l 1GiB swap-1.img
# chmod 0600 swap-1.img

# mkswap swap-1.img 
Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
no label, UUID=ad4b80d9-43d2-4401-ad37-75c489fad196

# swapon swap-1.img

# swapon -s
Filename				Type		Size	Used	Priority
/mnt/spare2/swap-1.img                 	file    	1048572	0	-2

> Actual results:
> swapon: /mnt/resource/test: swapon failed: Invalid argument

It's not a problem with holes, because that produces a different error message:

# swapoff swap-1.img
# rm -i swap-1.img
# fallocate -l 1GiB swap-1.img
# chmod 0600 swap-1.img
# mkswap swap-1.img

# fallocate -v -d swap-1.img
swap-1.img: 3.6 MiB (3727360 bytes) converted to sparse holes.

# swapon swap-1.img
swapon: /mnt/spare2/swap-1.img: skipping - it appears to have holes.

# swapoff swap-1.img
swapoff: swap-1.img: swapoff failed: Invalid argument

I ran strace on swapoff and got this uninformative result:

# strace -o strace-1.txt swapoff swap-1.img
swapoff: swap-1.img: swapoff failed: Invalid argument

# fgrep 'swapoff(' strace-1.txt 
swapoff("/mnt/spare2/swap-1.img")       = -1 EINVAL (Invalid argument)

So the "swapoff" system call is failing.

However, swapon(2)/swapoff(2) gives several possible reasons for EINVAL being returned:

       EINVAL The file path exists, but refers neither to a regular file nor to a block device;

       EINVAL (swapon()) The indicated path does not contain a valid swap signature or resides on an in-memory filesystem such as tmpfs(5).

       EINVAL (since Linux 3.4)
              (swapon()) An invalid flag value was specified in flags.

       EINVAL (swapoff()) path is not currently a swap area.

(In reply to Steve from comment #7)
...
> # swapon swap-1.img
> swapon: /mnt/spare2/swap-1.img: skipping - it appears to have holes.
...

That is a user-space message (per swapon source code), so based on the log file result in Comment 2:

> [root@ip-10-116-2-81 mnt]# swapon test
> swapon: /mnt/test: swapon failed: Invalid argument
> [root@ip-10-116-2-81 mnt]# dmesg|tail -1
> [  913.896809] swapon: swapfile has holes

It seems that the hole detection in swapon isn't working, so the kernel is detecting holes instead.

(In reply to Yuxin Sun from comment #0)
> util-linux-2.32.1-22.el8.x86_64

That's quite an old version of util-linux. Can you update it?

v2.32.1 Jul 16, 2018
https://github.com/karelzak/util-linux/releases/tag/v2.32.1

"Filling" the holes with "-z" works, although there is a quirk in that mkswap needs to be run before holes can be created for the test:

# fallocate -v -l 1G swap-1.img
# chmod 0600 swap-1.img

# fallocate -v -l 1G -d swap-1.img 
swap-1.img: 0 B (0 bytes) converted to sparse holes.

Create some holes after running mkswap:

# mkswap swap-1.img

# fallocate -v -l 1G -d swap-1.img 
swap-1.img: 3.6 MiB (3727360 bytes) converted to sparse holes.

# swapon swap-1.img
swapon: /mnt/spare2/swap-1.img: skipping - it appears to have holes.

Now "fill" the holes with the "-z" option:

# fallocate -v -l 1G -z swap-1.img

"Filling" the holes appears to zap the swap signature:

# swapon swap-1.img
swapon: /mnt/spare2/swap-1.img: read swap header failed

# mkswap swap-1.img

Now, this completes without error:

# swapon swap-1.img

# swapon -s
Filename				Type		Size	Used	Priority
/mnt/spare2/swap-1.img                 	file    	1048572	0	-2

I still get this error in RHEL-9 so I move it to RHEL-9 product.

Thanks Steve!

I tried with the steps in comment 11 but still got "swapon: /mnt/resource/swap-1.img: swapon failed: Invalid argument".
# rpm -q util-linux
util-linux-2.36-3.el9.x86_64

Find a KB: https://access.redhat.com/solutions/4570081

As described in the KB https://access.redhat.com/solutions/4570081
Preallocated files created by fallocate on ext4 is interpreted as files with holes, which is expected to be rejected by swapon, so I don't think it's a bug.

(In reply to Yuxin Sun from comment #12)
> I still get this error in RHEL-9 so I move it to RHEL-9 product.
> 
> Thanks Steve!
> 
> I tried with the steps in comment 11 but still got "swapon:
> /mnt/resource/swap-1.img: swapon failed: Invalid argument".
> # rpm -q util-linux
> util-linux-2.36-3.el9.x86_64

I can reproduce the "swapon failed: Invalid argument" on ext4 on RHEL-9.0.0-20201112.1, but xfs works fine.

ext4
```
[root@ibm-x3550m4-2 home]# fallocate -v -l 1G swap-1.img                                                                                                                                                            
[root@ibm-x3550m4-2 home]# fallocate -v -l 1G -z swap-1.img
[root@ibm-x3550m4-2 home]# mkswap swap-1.img 
mkswap: swap-1.img: insecure permissions 0644, 0600 suggested.
Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
no label, UUID=9288b4a9-0fba-41ab-ad94-74d0bba3a6a6
[root@ibm-x3550m4-2 home]# swapon swap-1.img 
swapon: /home/swap-1.img: insecure permissions 0644, 0600 suggested.
swapon: /home/swap-1.img: swapon failed: Invalid argument
```

xfs
```
[root@ibm-x3550m4-2 ~]# fallocate -v -l 1G swap-1.img
[root@ibm-x3550m4-2 ~]# fallocate -v -l 1G -z swap-1.img
[root@ibm-x3550m4-2 ~]# mkswap swap-1.img 
mkswap: swap-1.img: insecure permissions 0644, 0600 suggested.
Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
no label, UUID=a3a346b4-30c8-4ce6-883e-f295ea1142cc
[root@ibm-x3550m4-2 ~]# swapon swap-1.img 
swapon: /root/swap-1.img: insecure permissions 0644, 0600 suggested.
[root@ibm-x3550m4-2 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:          32131         704       30584           4         842       31043
Swap:          1023           0        1023
```

env
```
[root@ibm-x3550m4-2 ~]# uname -a
Linux ibm-x3550m4-2.gsslab.rdu2.redhat.com 5.9.0-38.el9.x86_64 #1 SMP Mon Nov 9 17:27:11 EST 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@ibm-x3550m4-2 ~]# rpm -q util-linux
util-linux-2.36-3.el9.x86_64
```

On ext4, since we use "fallocate -z", I think the resulting file should no longer contains holes, so I expect the swapon should work, just as we use "dd" to create the file.

Lukas,

Could you please suggest is it a problem here?

Thanks,
Boyang

Tested in RHEL-9.0.0-20210206.6 and this issue has gone. Close as current release.

[root@wala9l16sv202080631-vm1 mnt]# rpm -q util-linux
util-linux-2.36.1-4.el9.x86_64
[root@wala9l16sv202080631-vm1 mnt]# rpm -q kernel
kernel-5.11.0-0.rc6.143.el9.x86_64

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days