From: CACook@quantum-sci.com
To: ecryptfs@vger.kernel.org
Subject: Re: Encrypting BTRFS Volume
Date: Mon, 3 Dec 2012 08:39:12 -0800 [thread overview]
Message-ID: <201212030839.12613.CACook@quantum-sci.com> (raw)
In-Reply-To: <CACDOv81k0-jji9Jkz=pSQt9kc7GmPx7dLDoYSMzDxgCdf=J5kQ@mail.gmail.com>
On Monday, December 03, 2012 07:41:09 AM B. J. Potter wrote:
> Ecryptfs is not made for volumes. You make a folder that holds your
> encrypted files. Then you mount it at another location that's in the
> clear. Perhaps your looking for full-disk encryption instead of
> filesystem-level encryption. Here's a note from the btrfs wikipedia
> page:
>
> The current recommendation for encryption with btrfs is to use a
> full-disk encryption mechanism such as dm-crypt or LUKS on the
> underlying devices, and to create the btrfs filesystem on top of that
> layer (and that if a RAID is to be used with encryption, encrypting a
> dm-raid device or a hardware-RAID device gives much faster disk
> performance than dm-crypt overlaid by btrfs's own filesystem-level
> RAID features)
That may be on the Wikipedia page, but here's what's in the BTRFS FAQ:
https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_encryption.3F
--------------------------------------------------------------------
Does btrfs support encryption?
No. This is a hard task and easy to do wrong (on a filesystem level). There's nobody actively working on it, although you may have heard it's planned (year 2009), try to understand it like not impossible. Instead, you should use available whole-disk encryption solutions such as dm-crypt or LUKS.
This pretty much forbids you to use btrfs' cool RAID features if you need encryption. Using a RAID implementation on top of several encrypted disks is much slower than using encryption on top of a RAID device. So the RAID implementation must be on a lower layer than the encryption, which is not possible using btrfs' RAID support.
Note: there is an option to use a btrfs internal raid1 for data and metadata: create the filesystem with --mixed option (and DUP profiles), but this may impact performace for volume sizes > 15G (or so).
Another solution is to use stacked encrypting layer like ecryptfs. This does not have the disadvantage mentioned in the paragraph above.
Last but not least it the fuse-based filesystem encfs working as a encrypting layer on top of normal filesystem. Note that the performance may be impacted (dive into fuse details for more). --------------------------------------------------------------------
And this is why I'm here.
next prev parent reply other threads:[~2012-12-03 16:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-01 21:06 Encrypting BTRFS Volume CACook
2012-12-03 15:01 ` CACook
2012-12-03 15:41 ` B. J. Potter
2012-12-03 16:39 ` CACook [this message]
2012-12-03 17:04 ` B. J. Potter
2012-12-03 17:56 ` CACook
2012-12-04 18:05 ` CACook
2012-12-05 2:46 ` B. J. Potter
2012-12-05 15:48 ` CACook
2012-12-05 23:39 ` Michael Chang
[not found] ` <201212041004.18477.CACook@quantum-sci.com>
2012-12-10 22:23 ` CACook
2012-12-11 1:51 ` Michael Chang
[not found] ` <201212061328.15342.CACook@quantum-sci.com>
[not found] ` <CAHcyQ+7UeWtYmfNFOMp6zuqVN=K2o=ebyhGuOAPDF5-oEBFU+w@mail.gmail.com>
2012-12-06 22:34 ` CACook
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=201212030839.12613.CACook@quantum-sci.com \
--to=cacook@quantum-sci.com \
--cc=ecryptfs@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.