On Wed, Oct 22, 2014 at 01:08:48PM -0700, Robert White wrote: > 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. -- === 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 ---
signature.asc
Description: Digital signature
