From: CACook@quantum-sci.com
To: ecryptfs@vger.kernel.org
Subject: Re: Encrypting BTRFS Volume
Date: Thu, 6 Dec 2012 14:34:58 -0800 [thread overview]
Message-ID: <201212061434.58476.CACook@quantum-sci.com> (raw)
In-Reply-To: <CAHcyQ+7UeWtYmfNFOMp6zuqVN=K2o=ebyhGuOAPDF5-oEBFU+w@mail.gmail.com>
Not too worried about the workload because this is just a backups server.
But I don't understand the structure you're suggesting. Can you explain?
On Thursday, December 06, 2012 02:18:45 PM you wrote:
> If you haven't changed the data before encryption, eCryptFS won't
> change the backing file.
>
> Deduping will probably be less efficient because a small change in a
> large file could cause a larger part (maybe the whole) file to change,
> but on a per-file basis you shouldn't see that much difference.
>
> It'll depend on your exact workload, though.
>
> On Thu, Dec 6, 2012 at 4:28 PM, <CACook@quantum-sci.com> wrote:
> >
> > On Wednesday, December 05, 2012 03:39:03 PM you wrote:
> >> If the only use of subvolumes is for snapshotting, it seems to me that
> >> you could make one subvolume contain the encrypted directory, and then
> >> take snapshots of the encrypted directory/subvolume instead of taking
> >> snapshots of the unencrypted volume.
> >
> > So the array is /media/backups and subvolumes are /media/backups/droog, droog-snap-{date}, /media/backups/hex, hex-snap-{date}, etc. The subvolumes and snaps have a special BTRFS relationship which eliminates dupes, and what I don't know is if ecryptfs would interfere with that. Seems like it would.
> >
>
>
>
>
prev parent reply other threads:[~2012-12-06 22:41 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
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 [this message]
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=201212061434.58476.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox