linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Roman Mamedov <rm@romanrm.net>
Cc: Timofey Titovets <nefelim4ag@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: swapfile on btrfs, temporary solution for wiki
Date: Fri, 25 Oct 2013 11:44:14 +0100	[thread overview]
Message-ID: <20131025104414.GD31029@carfax.org.uk> (raw)
In-Reply-To: <20131025163546.4cf3291a@natsu>

[-- Attachment #1: Type: text/plain, Size: 2768 bytes --]

On Fri, Oct 25, 2013 at 04:35:46PM +0600, Roman Mamedov wrote:
> On Thu, 24 Oct 2013 23:52:01 +0300
> Timofey Titovets <nefelim4ag@gmail.com> wrote:
> 
> > Hello, i suggest temporary solution to use swap file under btrfs.
> > I test it, and it work good.
> > 
> > I invent simple the way, how create and using swap file, just see
> > following sh code:
> > 
> > swapfile=$(losetup -f) #free loop device
> > truncate -s 8G /swap   #create 8G sparse swap file
> > losetup $swapfile /swap #mount file to loop
> > mkswap  $swapfile
> > swapon  $swapfile
> > 
> > i just adding this to rc.local and this work good.
> > May be, add it to btrfs Wiki as temporary solution to using swap file?
> 
> I always thought Btrfs does not allow swap files on purpose, because it is not
> deadlock-proof when used in the swapping context.

   It's more that the current swap interface is based on device+block
list, and if you balance a filesystem, the blocks for a file move --
but there's no way of telling the swap code to cope with that.

> Imagine you try swapping out pages to free up some memory, and in the process
> Btrfs needs to allocate some memory to actually perform the write, the kernel
> says "Sure, but for that we need to swap out some more pages..." You see where
> that goes.
> 
> Same issue is possible with swap on other complex filesystems an example
> being networked ones like NFS and SMB/CIFS.

   The network filesystems have a similar problem as btrfs -- they
don't export devices, and you don't get direct access to the low-level
blocks under the FS, so the swap code can't deal with it.

   That said, there's been a lot of work recently on getting
swap-over-NFS to work properly -- effectively giving a new interface
for the swap code that doesn't rely on direct mapping to device
blocks. That new interface gives us the minimal external
infrastructure necessary to consider doing swapfiles on btrfs.

> It might work for some time (or even work 99% of time), but you still may be
> endangering your system to a possibility of a lock-up, and certainly adding
> that to any Wiki/FAQ/website as "the solution" might not be the best choice.

   The deadlock situation is dealt with by adding a flag to the memory
allocator in the swap-critical paths, which says you're not allowed to
swap anything when you make the allocation. That at least allows the
memory allocation to fail (hopefully gracefully) without deadlocking.
I suspect that this is also part of the swap-on-NFS work -- adding
that flag everywhere necessary.

   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
       --- He's playing Schubert.  I think Schubert is losing. ---       

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2013-10-25 10:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-21 20:37 swapfile on btrfs, temporary solution for wiki Тимофей Титовец
2013-10-24 20:52 ` Timofey Titovets
2013-10-25  9:36   ` dima
2013-10-25 10:35   ` Roman Mamedov
2013-10-25 10:44     ` Hugo Mills [this message]
2013-10-26  9:28       ` karim.allah.ahmed
2013-10-26  9:30       ` karim.allah.ahmed
2013-10-26 11:50         ` Hugo Mills
2013-10-26 14:11         ` Duncan
2013-10-30 15:54   ` David Sterba
2013-10-30 20:11     ` Timofey Titovets
2013-10-30 20:12       ` Timofey Titovets

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131025104414.GD31029@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nefelim4ag@gmail.com \
    --cc=rm@romanrm.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).