linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Elsayed <eternaleye@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Swapfile on btrfs
Date: Wed, 27 Feb 2013 12:52:50 -0800	[thread overview]
Message-ID: <kglrn1$cdu$1@ger.gmane.org> (raw)
In-Reply-To: 20130227175226.GM27541@twin.jikos.cz

David Sterba wrote:

> On Tue, Feb 26, 2013 at 01:45:12PM -0800, Alex Elsayed wrote:
>> Hey, I was looking at the wiki 'unclaimed projects' list and I thought
>> I'd take a look at what might be needed to use the swap-over-n{fs,bd}
>> functionality in order to implement swapfile support. It *looks* like
>> it's surprisingly uncomplicated - to the point where I suspect I'm
>> missing something, and would like some sanity checking.
>> 
>> My primary references for this are the patch[1] implementing
>> swap-over-NFS and HEAD of cmason's for-linus branch.
> 
> The patch [1] is not enough to cook swap support for btrfs, have look at
> the rest of the series. There's some explanation how the interfaces look
> like. The read/write mechanism is done via direct_IO, but the filesystem
> has to add the swap_activate and swap_deactivate operations and take
> care of preallocating the swap file extents.
> 
> Details:
> 
> Analogy of these patches has to be done in btrfs as well:
> 
> d56b4ddf7781e	nfs: teach the NFS client how to treat PG_swapcache 
pages
> 29418aa4bd487	nfs: disable data cache revalidation for swapfiles
> 
> The patch you've analyzed in detail adds some nfs-specific bits, not the
> core work (and thus I don't disagree that it looks surprisingly
> uncomplicated :)
> 
> The generic swap support is demonstrated in
> 
> a509bc1a9e48	mm: swap: implement generic handler for 
swap_activate
> 
> and in case of btrfs it has to avoid using bmap.
> 
> Thanks for tackling this project, I think it's not an easy one. There
> are implications and API requirements that need to be taken into account
> wrt snapshots and stable block ranges during the file lifetime.  I have
> a few commetns about that from Mel and can share them if you still want
> to proceed with this project.
> 
> david

Thanks for the information! I probably will keep going on this, since at 
this point my disk basically boils down to an EFI system partition and a 
LUKS volume containing swap and btrfs over LVM. Being able to dwap the swap 
partition would let me drop LVM, and simplify my setup a little (along with 
letting me omit the LVM module from dracut).

It will, however, likely take a while - I'm not particularly skilled with C, 
and the kernel is still slightly magic in places, but I'm stubborn and pick 
up on patterns reasonably well so hopefully it'll get done eventually.

Also, in talking on IRC with Hugo Mills he helped me realize another issue - 
specifically, that a.) DIO to compressed data falls back to buffered IO, and 
b.) (at least according to the wiki) the compress_force mount option takes 
precedence over the NOCOMPRESS file flag.

Thinking about it further, I realized that individual extents could be 
compressed, at which point this could get rather onerous on swapon since we 
might well need to check each and every extent to make sure it isn't 
compressed.

Any suggestions?



  reply	other threads:[~2013-02-27 20:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-26 21:45 Swapfile on btrfs Alex Elsayed
2013-02-27 17:52 ` David Sterba
2013-02-27 20:52   ` Alex Elsayed [this message]
2013-03-15 15:22     ` David Sterba

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='kglrn1$cdu$1@ger.gmane.org' \
    --to=eternaleye@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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).