Skip to contentSkip to conversation

NOCOW and Swap Files?

DISCUSSION Robert White 4 participants 7 messages Oct 22, 2014 – Oct 23, 2014 Btrfs file system

lore
Share & tools
lore
#0 lore raw

So the documentation is clear that you can't mount a swap file through BTRFS (unless you use a loop device).

Why isn't a NOCOW file that has been fully pre-allocated -- as with fallocate(1) -- not suitable for swapping?

I found one reference to an unimplemented feature necessary for swap, but wouldn't it be reasonable for that feature to exist for NOCOW files? (or does this relate to my previous questions about the COW operation that happens after a snapshot?)

#1 lore raw
Quoted 10 lines · Robert White

So the documentation is clear that you can't mount a swap file through BTRFS (unless you use a loop device).

Why isn't a NOCOW file that has been fully pre-allocated -- as with fallocate(1) -- not suitable for swapping?

I found one reference to an unimplemented feature necessary for swap, but wouldn't it be reasonable for that feature to exist for NOCOW files? (or does this relate to my previous questions about the COW operation that happens after a snapshot?)

The original swap implementation worked by determining a list of
blocks (well, I guess extents) using fiemap, and passing that to the swap code for it to use. This is fine, as long as (a) nobody else writes to the file, and (b) the blocks comprising the file don't move elsewhere.

Part (a) can be done with normal permissions, so that's not a
problem.

Part (b) is more tricky -- not because of CoW (because the writes
from the swap code go directly to the device, ignoring the FS), but because the FS's idea of where the file lives on the device can move -- balance will do this, for example. So you can't balance a filesystem with any active swapfiles on it. This is the main reason that swapfiles aren't allowed on btrfs, as far as I know.

The new code is the swap-on-NFS infrastructure, which indirects
swapfile accesses through the filesystem code. The reason you have to do that with NFS is because NFS doesn't expose a block device at all, so you can't get a list of blocks on an underlying device because there isn't one. Indirecting the accesses through the filesystem, however, allows us to side-step btrfs's problems with part (b) above, and in theory gives us swapfile capability.

Hugo.

Signature · 3 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
      --- Great oxymorons of the world, no. 7: The Simple Truth ---      
#2 lore raw
Quoted 7 lines · Hugo Mills

The new code is the swap-on-NFS infrastructure, which indirects
swapfile accesses through the filesystem code. The reason you have to do that with NFS is because NFS doesn't expose a block device at all, so you can't get a list of blocks on an underlying device because there isn't one. Indirecting the accesses through the filesystem, however, allows us to side-step btrfs's problems with part (b) above, and in theory gives us swapfile capability.

I was not even aware there was "new code" on the matter.

Is there a guide or whatever to doing this? I didn't see any mention of it in the places Google led me.

--Rob

#3 lore raw
Quoted 9 lines · Robert White
Quoted 7 lines · Hugo Mills

The new code is the swap-on-NFS infrastructure, which indirects
swapfile accesses through the filesystem code. The reason you have to do that with NFS is because NFS doesn't expose a block device at all, so you can't get a list of blocks on an underlying device because there isn't one. Indirecting the accesses through the filesystem, however, allows us to side-step btrfs's problems with part (b) above, and in theory gives us swapfile capability.

Quoted 4 lines

I was not even aware there was "new code" on the matter.

Is there a guide or whatever to doing this? I didn't see any mention of it in the places Google led me.

swap-on-NFS is still, I think, in a set of out of tree patches, and
it's not gone anywhere near btrfs yet. It's just that once it does land in mainline, it would form the appropriate infrastructure to develop swapfile capability for btrfs.

Hugo.

Signature · 3 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
      --- Great oxymorons of the world, no. 7: The Simple Truth ---      
#4 lore raw
Quoted 4 lines · Hugo Mills

swap-on-NFS is still, I think, in a set of out of tree patches, and
it's not gone anywhere near btrfs yet. It's just that once it does land in mainline, it would form the appropriate infrastructure to develop swapfile capability for btrfs.

I just looked at my 3.16.6 kernel tree and there is a check-box for swap over NFS in the network file systems menu. For whatever that's worth.

But as of now only the loopdev method is workable if I understand you correctly.

Thanks.

--Rob.

#5 lore raw
In reply to Hugo Mills

Also it would be nice to have checksums on the swap data. It's a bit of a waste to pay for ECC RAM and then lose the ECC benefits as soon as data is paged out.

Signature · 1 line
Sent from my Samsung Galaxy Note 3 with K-9 Mail.
#6 lore raw
In reply to Robert White
Quoted 10 lines · Robert White

So the documentation is clear that you can't mount a swap file through BTRFS (unless you use a loop device).

Why isn't a NOCOW file that has been fully pre-allocated -- as with fallocate(1) -- not suitable for swapping?

I found one reference to an unimplemented feature necessary for swap, but wouldn't it be reasonable for that feature to exist for NOCOW files? (or does this relate to my previous questions about the COW operation that happens after a snapshot?)

I actually use a swapfile on BTRFS on a regular basis on my laptop (trying to keep the number of partitions to a minimum, cause I dual boot Windows), and here's what the init script I use for it does:
1. Remove any old swap file (the fs is on an SSD, so I do this mostly to get the discard operation).
2. Use touch to create a new file.
3. Use chattr to mark the file NOCOW.
4. Use fallocate to pre-allocate the space for the file.
5. Bind the file to a loop device.
6. Format as swap and add as swapspace.

This works very reliably for me, and the overhead of the loop device is relatively insignificant (because my disk is actually faster than my RAM) for my use case, and I can safely balance/defrag/fstrim the filesystem without causing issues with the swap file.

If you can avoid using a swapfile though, I would suggest doing so, regardless of which FS you are using. I actually use a 4-disk RAID-0 LVM volume on my desktop, and it gets noticeably better performance than using a swap file.