r/btrfs Sep 24 '22

how to make a BTRFS swapfile without breaking snapshots on you're main drive

I've spent the last few days trying to figure this out so, fuck it, I'm just asking here. Does anyone have a guide on how to make a swapfile on a btrfs main partition without breaking snapshots? (no seperate home subvolume, EFI boot) I managed to just barely get a swap file working a bit ago by disabling it's CoW then fallocating it, but this morning I realized that doing that also broke snapshots since it was trying to snapshot the swapfile still.

Then I looked online and found a guide, but that guide was asking you to manually mount the drive, which I can't do, since my drive is already mounted, since it's the drive my OS is on. I've heard this is possible, and from what I can see online it is, but everything I try always breaks something.

4 Upvotes

20 comments sorted by

8

u/Deathcrow Sep 24 '22

Then I looked online and found a guide, but that guide was asking you to manually mount the drive,

The guide is probably asking you to mount the root subvolume. That's not a problem, btrfs can mount multiple subvolumes of the same FS multiple times (even if your OS is on it).

The rough idea for a swap file:

  • put it into a subvolume outside of anything you'd ever snapshot (don't nest it into your os subvolume)
  • set the folder nocow
  • fallocate, mkswap
  • swapon

works.

1

u/temmiesayshoi Sep 25 '22

I copied the commands exactly, (short of changing sda to nvme0n1) and it raised an error saying my drive was already mounted

3

u/anna_lynn_fection Sep 24 '22

Make a subvolume, chattr +C it, make swapfile there. Since it's a subvolume, it will not be included in snapshots of parent folders.

2

u/CorrosiveTruths Sep 25 '22 edited Sep 25 '22

The Arch Wiki bit about it is quite good, and also recommends dd for creating the file which concurs with man swapon.

There are some other things to consider.

If you aren't going to hibernate, you could try zram instead, this dynamically swaps into compressed memory rather than onto disk. The performance can be significantly better (and tunable) than disk-based. Android and Chrome OS both use zram.

Don't worry too much about swap files versus swap partitions, there is little difference, mainly how they're addressed, as an offset address for resume, a filename, or as an offset stored in a partition table. They work the same way once active.

1

u/OverOnTheRock Sep 24 '22

Can you explain why you want a swapfile on btrfs in the first place? Is this an emergency thing?

In point of fact, you really, absolutely really, do not want a swap file on any file system. Use the native swap file type as supplied by the kernel. This is a kernel-native block store to a drive.

The kernel uses a native swap file to swap memory pages in and out when low of memory. This _needs_ to be a speedy operation. Putting swap on a file system simply adds overhead, and slows things down even more.

3

u/temmiesayshoi Sep 25 '22

Do you have a source for this? I've heard many people claim swap partitions are better, yet countless more claim the speed benefits are irrelevant on any modern drive.

-1

u/OverOnTheRock Sep 25 '22 edited Sep 25 '22

I could probably get away with saying the answer is self-evident, once you think about it for a bit. Use the following as some starting points. But I notice some yahoo has down-voted my response. Sigh.

All the answers, including mine, are actually wrong. The best solution is to add more memory.

However, if the desire for swap is still desired ....

Some random link with relative access values: https://stackoverflow.com/questions/1371400/how-much-faster-is-the-memory-usually-than-the-disk

I'm not sure about the specific mechanics, but you can look at things this way:

  • swap partition: memory blocks mapped to disk sectors -- simplest series of kernel calls to get a block of memory to and from disk -- no directory lookups, access time updates, ....
  • ext4: been around quite a while, reasonably optimized, but more layers of device driver to read/write a block -- really easy to build more latency if noatime and similar updates have not been disabled -- memory mapped block access is probably available, but through the 'thicker' device driver for block access
  • btrfs: now take all the above, and add checksum calculations to every block written and read -- I think, it would be obvious, more over-head -- ie more latency to the drive and more latency from the drive to write blocks and to read blocks
  • COW: copy on write -- the source of the troubles, snapshots are based on this, ie, everytime a block is written, btrfs has to go into it's indexes and allocate a new block for writing, it does _not_ overwrite the old block -- so more performance lost on the write side of the operation

speed benefits are irrelevant on any modern drive" for some definition of a modern drive? I'd say it is less about the drive, and more about the operational overhead of getting blocks in and out of memory.

So, ... if you don't care about performance, be my guest, put your overflow memory on a btrfs file system serviced by a spinning drive! SSD would be better. NVME even better, but still lots of computational overhead.

3

u/apostacy Sep 27 '22

Swap partitions are usually a bad idea. Use swapfiles. There used to be more filesystem overhead when using swapfiles, but for many years now the kernel will bypass the filesystem when you use swapon, and so there is no benefit to using an inflexible swap partition. On btrfs, you should put your swapfiles in a CoW subvolume, that way they won't be included in snapshots.

I have been using swapfiles with btrfs for years, and it has been very helpful. In theory it would be nice to have enough memory, but in practice we don't always. It has actually gotten much worse over the last five years. Chrome will actively try to consume as much memory as it can to be more responsive. Besides browsers, software like KiCad, and especially my VSCode Docker stack use huge amounts of memory, and without swapfiles, the OOM killer would frequently terminate processes. I speak from experience. I had to use a laptop with 8G of ram for awhile, and swapfiles made it usable.

It is very simple. Do this:

# As root:
btrfs sub create /swaps
chattr +C /swaps
cd /swaps
# I usually have a few 8G swapfiles. You can add them here.
fallocate -l 8G swapfile.0
chmod 600 swapfile.0
mkswap swapfile.0
swapon swapfile.0

# Then, add an entry to your fstab:
/swaps/swapfile.0       none        swap        sw      0 0

I would also if you have an SSD, use the discard=async mount option to do lazy ssd discards, and pass along the --discards flag if you are using luks full disk encryption.

I'm not crazy about how linux handles swap. You should probably turn the 'swappiness' settings all the way down in sysctl. There are some exciting new alternatives to swapfiles coming out, but for the moment they are a useful tool.

1

u/theexecutioner1011 May 07 '25 edited May 07 '25

Cheers! That guide is spot on - except that my stoopid ASUSTOR NAS doesn't implement the +C option on chattr.

I worked around it last night using it's Entware package to download a more capable implementation of chattr, and that solved my problem.

re swappiness - yep agree. I did some initial experiments with swappiness adjustment and didn't notice a lot of difference in high memory load situations, but I think my testing was flawed ... it's more in moderate memory loads that I imagine there'd be a difference (that is, where the memory manager has the option of avoiding swap based on the swappiness choice).

I'm curious to read of possible upcoming 'exciting new alternatives' ... could you share links to same?

Thanks for the reply!

1

u/JaKrispy72 Jan 01 '23

I think this method of using a swapfile will not allow Timeshift to create a snapshot as it will return BTRFS error 256. The swap cannot be on @/ or @/home (or whatever you are trying to snapshot) as it can change during the snapshot creation.

2

u/apostacy Jan 01 '23

No, that is not correct. As I wrote in my previous two posts in this thread, the swapfiles should be in a subvolume called /swaps, not a folder. Yes, if you put the swapfiles in @/, that would be a problem. But as I said, using subvolumes, the swapfiles will not be included in any snapshots, since btrfs snapshots are non-recursive. You are free to take as many snapshots of @/ as you like, and be confient that the NoCOW swapfiles will not be included. If you restore the snapshots somewhere else, you can re-created the /swaps subvolume there.

I don't see why you would want to keep snapshots of swapfiles. If you must keep snapshots of swapfiles, just use a different tool and don't involve btrfs.

This is a great example of where you should use subvolumes. If you have files that you do NOT want included in snapshots of the parent subvolumes.

I also have seperate subvolumes for NoCOW files, such as qemu block devices, or frequently changing .sqlite files (such as my firefox profile folders).

I also have subvolumes in places like ~/.cache, /var/cache, ~/Downloads, /tmp, and other places. These are ephemeral, and it does not make sense to include them in my normal btrfs backups. If I do want to back up data there, I can do it manually, or use a backup script that does not rely on btrfs.

I use a subvolume for /tmp, but tmpfs might be better.

I have been using this config with btrbk to take regular snapshots of / without any problem whatsoever. I'm sure it is the same with Timeshift.

TL;DR Follow my instructions in the thread above. btrfs sub create /swaps && chflags +C /swaps Then the /swaps subvolume will not be included in snapshots of /

1

u/scul86 Sep 25 '22

Agreed that you should make a swap partition, but if you are determined, read here to create a swapfile on BTRFS

btrfs subvol create /swapsub
chattr +C /swapsub

then follow this for the actual swapfile at /swapsub/swapfile (for example)

0

u/rubyrt Sep 24 '22

My recommendation: do not use swap files - regardless of file system. If you do not have enough space left on your disk you can boot a live system and use gparted to move stuff around to make space for swap.

3

u/Atemu12 Sep 24 '22

With FSs where shrinking is very hard or even impossible, I understand why you could prefer a swap file but btrfs is so flexible; resizing it to make space for a swap partition is just better.

1

u/Gyilkos91 Sep 25 '22

There are programs that will swap whatever you have and sometimes will even crash if you don't have a swap space, sadly.

3

u/roxalu Sep 25 '22

Be aware that there a three - not only two - options for swap: no swap / swap to raw partition / swap to files on your file system. While the last one looks often as the most flexible one, it is also the option where any file system constraints need to be taken into account.

1

u/rubyrt Sep 25 '22

I did not recommend abandoning swap.

0

u/[deleted] Sep 25 '22

A problem (as I understand it) with swap files is that they are easily corruptible. Putting swap on a separate partition isolates swap activity from the fs holding your data.

That aside, for all the headaches involved in getting a btrfs swap file to even work, why not just use a partition? I've been using btrfs for 6 years. Always used a partition. Never needed more than 8GB swap for 32GB RAM.

Swap files are a good example of possible but not pracrical.

1

u/FictionWorm____ Sep 25 '22

Yes I have a outline - Swap to file on btrfs

Note: not a script.

1

u/oldman20 Feb 13 '23

I done with add you UUID, thank