EcryptFS development
 help / color / mirror / Atom feed
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.
> >
> 
> 
> 
> 

      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