after a fresh install I’m trying to create a swapfile on a btrfs subvolume which is on a luks-partition.
Creating the 0-sized swapfile with truncate is simple, but chattr +C swapfile keeps failing as soon as I place the swapfile on a subvolume other than ‘@’ (‘/’) in my case.
truncate -s 0 swapfile
chattr +C swapfile
chattr: Invalid argument while setting flags on swapfile
I also tried this directly via the mounted mapper-device on /@swap without any success.
The devices and subvolumes in question look like this:
No, I don’t think so.
IOW, a btrfs subvolume with a swapfile on it (which must have CoW disabled) can’t have snapshots. So it’s explicitly recommended (read that on various places here and on the Net) to have it on a dedicated subvolume. And this can’t be root.
But actually, I’m not getting this far.
All I’m doing (by the book) is creating an empty file on a subvolume and trying to switch off Copy-On-Write.
[joe@joe-virtualbox ~]$ sudo btrfs subvolume list -p /
ID 256 gen 32 parent 5 top level 5 path @
ID 257 gen 32 parent 5 top level 5 path @home
ID 258 gen 31 parent 5 top level 5 path @cache
ID 259 gen 32 parent 5 top level 5 path @log
ID 260 gen 26 parent 5 top level 5 path @swap
[joe@joe-virtualbox ~]$ cat /etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=C52E-5A07 /boot/efi vfat defaults,noatime 0 2
/dev/mapper/luks-46d62a8f-ed37-4ce4-b4fc-dd0b162ac4c8 / btrfs subvol=/@,defaults,noatime,compress=zstd 0 0
/dev/mapper/luks-46d62a8f-ed37-4ce4-b4fc-dd0b162ac4c8 /home btrfs subvol=/@home,defaults,noatime,compress=zstd 0 0
/dev/mapper/luks-46d62a8f-ed37-4ce4-b4fc-dd0b162ac4c8 /var/cache btrfs subvol=/@cache,defaults,noatime,compress=zstd 0 0
/dev/mapper/luks-46d62a8f-ed37-4ce4-b4fc-dd0b162ac4c8 /var/log btrfs subvol=/@log,defaults,noatime,compress=zstd 0 0
/dev/mapper/luks-46d62a8f-ed37-4ce4-b4fc-dd0b162ac4c8 /swap btrfs subvol=/@swap,defaults,noatime 0 0
/swap/swapfile swap swap defaults 0
so a regular subvol mounted … mounted at /swap but the swapfile does not need to be directly under / path as you can see it can be a subfolder…
[joe@joe-virtualbox ~]$ sudo file /swap/swapfile
/swap/swapfile: Linux swap file, 4k page size, little endian, version 1, size 131071 pages, 0 bad pages, no label, UUID=0d9c1583-7e35-4585-8a34-0a0985b891aa
The wiki say also to chattr the directory and not the file only…
Swap files in Btrfs are supported since Linux kernel 5.0. The proper way to initialize a swap file is to first create a non-snapshotted subvolume to host the file and then set the No_COW attribute on the whole directory with chattr.
# chattr +C */path/to/swapsubvolume*
From now on any new file created inside the swap subvolume will have the No_COW attribute set.
could be it is not needed anymore ( i am not the best expert on BTRFS
Archwiki say chattr +C on the swap subvol and after this create the swapfile as of the wiki…
the error looks like something is wrong with the used mount options or filesystem … like in the post i linked where user tried to set +C on a swapfile inside ext4 filesystem
If CoW is active on a file, mkswap for this file won’t work and leaves a complaint in dmesg.
Somewhere here I read there was a change in the btrfs kernel module resulting that compression and CoW are mutually exclusive (?, not sure, have yet to find the posting).
So I tried this:
btrfs docs say nodatacow, nodatasum and compress are silently ignored (resp. not implemented), but I gave it a try and removed it from the mount options anyway.
And ‘surprise’ chattr worked! But: To be sure I did a crosscheck and I changed the lines again.
Unexpectedly any chattr - command works this time!
So … now I got a working swapfile (after applying all other commands) but I don’t know why!
Actually, I don’t know.
The entire system is on a LUKS partition, on an NVMe.
IMHO a swapfile is the easiest way to have swap encrypted, that goes in one swoop. *)
From this storage’s point of view it wouldn’t matter where the swap data is being put, any block can be reached in similar time.
Except, if BTRFS has to jump a lot of hoops to get a swapfile working on a subvolume.
*) I just realised the irony in this sentence, given this threads topic.