From 57501a0075948840c4eb6cbfaca9fee4acb3f6f0ef4ddf1e94d283dcc75f0899 Mon Sep 17 00:00:00 2001 From: Petr Uzel Date: Fri, 25 Jun 2010 07:42:28 +0000 Subject: [PATCH] Accepting request 42022 from home:jeff_mahoney:branches:Base:System Copy from home:jeff_mahoney:branches:Base:System/util-linux via accept of submit request 42022 revision 2. Request was accepted with message: Thanks! OBS-URL: https://build.opensuse.org/request/show/42022 OBS-URL: https://build.opensuse.org/package/show/Base:System/util-linux?expand=0&rev=44 --- util-linux-swapon-btrfs-limitations | 42 +++++++++++++++++++++++++++++ util-linux.changes | 5 ++++ util-linux.spec | 2 ++ 3 files changed, 49 insertions(+) create mode 100644 util-linux-swapon-btrfs-limitations diff --git a/util-linux-swapon-btrfs-limitations b/util-linux-swapon-btrfs-limitations new file mode 100644 index 0000000..59722da --- /dev/null +++ b/util-linux-swapon-btrfs-limitations @@ -0,0 +1,42 @@ +From: Jeff Mahoney +Subject: swapon: Document btrfs limitation with swapfiles +References: bnc#616617 + + Btrfs, as of 2.6.35, is unable to allow swapfiles to be used on its + filesystems. This is due to the swapfile implementation wanting to build + an extent map of each block in the file and expecting it to be static + for the life of the swapfile. + + Btrfs can't guarantee this and refuses to return the mapping. The swapfile + implementation just makes a comment about there being holes in the file - + but that's how btrfs denies the mapping. + + This patch adds a section to the swapon manpage to document it. + +Signed-off-by: Jeff Mahoney + +--- + mount/swapon.8 | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/mount/swapon.8 ++++ b/mount/swapon.8 +@@ -167,6 +167,18 @@ automatically detects and rewrites swap + suspend data (e.g S1SUSPEND, S2SUSPEND, ...). The problem is that if we don't + do it, then we get data corruption the next time an attempt at unsuspending is + made. ++.PP ++.B swapon ++may not work correctly when using a swap file with some versions of btrfs. ++This is due to the swap file implementation in the kernel expecting to be able ++to write to the file directly, without the assistance of the file system. ++Since btrfs is a copy-on-write file system, the file location may not be ++static and corruption can result. Btrfs actively disallows the use of files ++on its file systems by refusing to map the file. This can be seen in the system ++log as "swapon: swapfile has holes." One possible workaround is to map the ++file to a loopback device. This will allow the file system to determine the ++mapping properly but may come with a performance impact. ++ + .SH SEE ALSO + .BR swapon (2), + .BR swapoff (2), diff --git a/util-linux.changes b/util-linux.changes index 68ad9e9..d84ec7b 100644 --- a/util-linux.changes +++ b/util-linux.changes @@ -1,3 +1,8 @@ +------------------------------------------------------------------- +Thu Jun 24 23:24:41 CEST 2010 - jeffm@suse.de + +- document btrfs limitation with swapfiles (bnc#616617) + ------------------------------------------------------------------- Tue Jun 22 16:48:29 UTC 2010 - bg@novell.com diff --git a/util-linux.spec b/util-linux.spec index 965d7b4..2b717aa 100644 --- a/util-linux.spec +++ b/util-linux.spec @@ -75,6 +75,7 @@ Patch4: util-linux-2.17.1-losetup-honor-documented-c-option Patch5: util-linux-addpart-use-atoll.patch # bnc#481123 Patch6: util-linux-mount-detect-ro-mount.patch +Patch7: util-linux-swapon-btrfs-limitations ## ## adjtimex ## @@ -165,6 +166,7 @@ unique IDs (UUIDs). %patch4 -p1 %patch5 -p1 %patch6 -p1 +%patch7 -p1 # cd adjtimex-* %patch50 -p1