From: Chris Mason <chris.mason@oracle.com>
To: Anthony Roberts <btrfs-devel@arbitraryconstant.com>
Cc: Dmitri Nikulin <dnikulin@gmail.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs and swap files on SSD's ?
Date: Tue, 20 Jan 2009 11:41:50 -0500 [thread overview]
Message-ID: <1232469710.15042.52.camel@think.oraclecorp.com> (raw)
In-Reply-To: <f45c907a12e473689f0061d68c4e0749@smtp.arbitraryconstant.com>
On Tue, 2009-01-20 at 09:35 -0700, Anthony Roberts wrote:
> > The second is an implementation detail of the linux swap file code. It
> > expects filesystems don't move blocks around, and takes a mapping of the
> > blocks in the FS once.
> >
> > This doesn't work with btrfs because we do move blocks around all the
> > time.
>
> That's interesting. I have a few questions:
>
> -Is creating a loopback device from the file any different, or does that
> lead to the same problems?
The loopback device would probably work. At least it would cover blocks
that move around.
>
> -Would mounting a filesystem image via loopback device cause similar
> problems?
loopback goes through safer APIs.
>
> -Would this be viable if using a dedicated nodatacow subvolume, or is that
> still too risky because of the odd case where you do cow?
nodatacow is allowed to COW when there are snapshots or clones. I
wouldn't recommend swapfiles on it just because people can easily forget
about the swapfile restriction.
I plan on sending a patch to at least disable swapfiles for btrfs in
this kernel cycle. Later on we can work out the swap bmapping apis with
the VM maintainers.
>
> -Does online defragmentation hurt this as well?
>
Yes. Online defrag in XFS may have problems with this too, I'm asking
the xfs people if they have worked around this.
-chris
next prev parent reply other threads:[~2009-01-20 16:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-17 0:10 btrfs and swap files on SSD's ? Chris Samuel
2009-01-19 16:22 ` Chris Mason
2009-01-20 10:41 ` Kaspar Schleiser
2009-01-20 13:02 ` Chris Mason
2009-01-20 13:51 ` Dmitri Nikulin
2009-01-20 14:31 ` Chris Mason
2009-01-20 16:35 ` Anthony Roberts
2009-01-20 16:41 ` Chris Mason [this message]
2009-01-21 6:15 ` Andi Kleen
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=1232469710.15042.52.camel@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=btrfs-devel@arbitraryconstant.com \
--cc=dnikulin@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.