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@xxxxxxxxxxxxxxx> 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.
> >
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
