On Thu, May 24, 2018 at 02:41:28PM -0700, Omar Sandoval wrote: > From: Omar Sandoval <osandov@xxxxxx> > > When a swap file is active, we must make sure that the extents of the > file are not moved and that they don't become shared. That means that > the following are not safe: > > - chattr +c (enable compression) > - reflink > - dedupe > - snapshot > - defrag > - balance > - device remove/replace/resize > > Don't allow those to happen on an active swap file. Balance and device > remove/replace/resize in particular are disallowed entirely; in the > future, we can relax this so that relocation skips/errors out only on > chunks containing an active swap file. Hm, disabling the entire balance is too intrusive. It's clear that the swapfile causes a lot of trouble when it goes against the dynamic capabilities of btrfs (relocation and the functionality that builds on it). Skipping the swapfile extents should be implemented at minimum. We can add some heuristics that will group the swap extents to a small number of chunks so the impact of unmovable chunks is limited. I haven't looked at the implementation, but it might be possible to internally find a different location for the swap extent once it's not used for the actual paged data. In an ideal case, the swap extents could span entire chunks (1G) and not mix with regular data/metadata. > Note that we don't have to worry about chattr -C (disable nocow), which > we ignore for non-empty files, because an active swapfile must be > non-empty and can't be truncated. We also don't have to worry about > autodefrag because it's only done on COW files. Truncate and fallocate > are already taken care of by the generic code. Device add doesn't do > relocation so it's not an issue, either. Ok, fine the remaining easy cases are covered. I don't know if you mentioned that elsewhere (as design questions are in this patch), the allocation profile is single, or is it also possible to have striped or duplicated swap extents?
