From: Omar Sandoval <osandov@osandov.com>
To: Filipe David Manana <fdmanana@gmail.com>,
David Sterba <dsterba@suse.cz>,
linux-btrfs@vger.kernel.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Chris Mason <clm@fb.com>, Josef Bacik <jbacik@fb.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-nfs@vger.kernel.org,
Trond Myklebust <trond.myklebust@primarydata.com>,
Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH v2 5/5] btrfs: enable swap file support
Date: Mon, 24 Nov 2014 14:03:02 -0800 [thread overview]
Message-ID: <20141124220302.GA5785@mew.dhcp4.washington.edu> (raw)
In-Reply-To: <20141122200357.GA15189@mew>
On Sat, Nov 22, 2014 at 12:03:57PM -0800, Omar Sandoval wrote:
> On Fri, Nov 21, 2014 at 07:00:45PM +0100, David Sterba wrote:
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> > > + if (test_bit(EXTENT_FLAG_COMPRESSED, &em->flags)) {
> > > + pr_err("BTRFS: swapfile is compresed");
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> >
> > I think the preallocated extents should be refused as well. This means
> > the filesystem has enough space to hold the data but it would still have
> > to go through the allocation and could in turn stress the memory
> > management code that triggered the swapping activity in the first place.
> >
> > Though it's probably still possible to reach such corner case even with
> > fully allocated nodatacow file, this should be reviewed anyway.
> >
> I'll definitely take a closer look at this. In particular,
> btrfs_get_blocks_direct and btrfs_get_extent do allocations in some cases which
> I'll look into.
>
Alright, I took a look at this. My understanding is that a PREALLOC extent
represents a region on disk that has already been allocated but isn't in use
yet, but please correct me if I'm wrong. Judging by this comment in
btrfs_get_blocks_direct, we don't have to worry about PREALLOC extents in
general:
/*
* We don't allocate a new extent in the following cases
*
* 1) The inode is marked as NODATACOW. In this case we'll just use the
* existing extent.
* 2) The extent is marked as PREALLOC. We're good to go here and can
* just use the extent.
*
*/
A couple of other considerations that cropped up:
- btrfs_get_extent does a bunch of extra work if the extent is not cached in
the extent map tree that would be nice to avoid when swapping
- We might still have to do a COW if the swap file is in a snapshot
We can avoid the btrfs_get_extent by pinning the extents in memory one way or
another in btrfs_swap_activate.
The snapshot issue is a little tricker to resolve. I see a few options:
1. Just do the COW and hope for the best
2. As part of btrfs_swap_activate, COW any shared extents. If a snapshot
happens while a swap file is active, we'll fall back to 1.
3. Clobber any swap file extents which are in a snapshot, i.e., always use the
existing extent.
I'm partial to 3, as it's the simplest approach, and I don't think it makes
much sense for a swap file to be in a snapshot anyways. I'd appreciate any
comments that anyone might have.
--
Omar
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-11-24 22:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 10:08 [PATCH v2 0/5] btrfs: implement swap file support Omar Sandoval
2014-11-21 10:08 ` [PATCH v2 1/5] direct-io: don't dirty ITER_BVEC pages on read Omar Sandoval
2014-11-21 15:39 ` Dave Kleikamp
2014-11-21 10:08 ` [PATCH v2 2/5] nfs: don't dirty ITER_BVEC pages read through direct I/O Omar Sandoval
2014-11-21 10:08 ` [PATCH v2 3/5] swap: use direct I/O for SWP_FILE swap_readpage Omar Sandoval
2014-11-21 10:08 ` [PATCH v2 4/5] btrfs: don't allow -C or +c chattrs on a swap file Omar Sandoval
2014-11-21 17:29 ` David Sterba
2014-11-21 10:08 ` [PATCH v2 5/5] btrfs: enable swap file support Omar Sandoval
2014-11-21 18:00 ` David Sterba
2014-11-21 19:07 ` Filipe David Manana
2014-11-22 20:03 ` Omar Sandoval
2014-11-24 22:03 ` Omar Sandoval [this message]
2014-11-25 5:55 ` Brendan Hide
2014-12-01 18:18 ` David Sterba
2014-11-21 10:15 ` [PATCH v2 0/5] btrfs: implement " Omar Sandoval
2014-11-21 10:19 ` Christoph Hellwig
2014-11-24 22:17 ` Omar Sandoval
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=20141124220302.GA5785@mew.dhcp4.washington.edu \
--to=osandov@osandov.com \
--cc=akpm@linux-foundation.org \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--cc=fdmanana@gmail.com \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=trond.myklebust@primarydata.com \
--cc=viro@zeniv.linux.org.uk \
/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).