Re: FAQ / encryption / error handling?

On 2017-11-27 05:06, Dmitrii Tcvetkov wrote: On Mon, 27 Nov 2017 09:06:12 +0100 Daniel Pocock <dan...@pocock.pro> wrote: Hi all, The FAQ has a couple of sections on encryption (general and dm-crypt) One thing that isn't explained there: if you create multiple encrypted volumes (e.g. us

Re: FAQ / encryption / error handling?

On Mon, 27 Nov 2017 09:06:12 +0100 Daniel Pocock <dan...@pocock.pro> wrote: > Hi all, > > The FAQ has a couple of sections on encryption (general and dm-crypt) > > One thing that isn't explained there: if you create multiple encrypted > volumes (e.g. using dm-crypt)

FAQ / encryption / error handling?

Hi all, The FAQ has a couple of sections on encryption (general and dm-crypt) One thing that isn't explained there: if you create multiple encrypted volumes (e.g. using dm-crypt) and use Btrfs to combine them into RAID1, how does error recovery work when a read operation returns corrupted data

Re: btrfs native encryption

On Mon, Jun 12, 2017 at 02:40:38PM +0200, David Sterba wrote: > On Fri, Jun 09, 2017 at 08:50:12AM -0700, Filip Bystricky wrote: > > Dear btrfs maintainers, > > Google is evaluating btrfs for its potential use in android, but > > currently the lack of native file-based enc

Re: btrfs native encryption

On Fri, Jun 09, 2017 at 08:50:12AM -0700, Filip Bystricky wrote: > Dear btrfs maintainers, > Google is evaluating btrfs for its potential use in android, but > currently the lack of native file-based encryption unfortunately makes > it a nonstarter. The file-based encryptio

Re: btrfs native encryption

dealing with inheritance of encryption when making snapshots, and dealing with reflinks. Right. To address this, there is a proposal to bring encryption down to the extent level, it solves these limitations. Thanks, Anand -- To unsubscribe from this list: send the line "unsubs

Re: btrfs native encryption

For phase-1 the idea was to make btrfs encryption inline with fs/crytpo which wasn't available when it started, so certainly there are things which could straight away filter out after its known what went into fs/crypto from ext4, especially the cryptography part. Now, 4.10 kernel based

Re: btrfs native encryption

On Fri, Jun 9, 2017 at 9:50 AM, Filip Bystricky <filipbystri...@google.com> wrote: > Dear btrfs maintainers, > Google is evaluating btrfs for its potential use in android, but > currently the lack of native file-based encryption unfortunately makes > it a nonstarter. Ac

Re: btrfs native encryption

On Fri, Jun 09, 2017 at 08:50:12AM -0700, Filip Bystricky wrote: > Dear btrfs maintainers, > Google is evaluating btrfs for its potential use in android, but > currently the lack of native file-based encryption unfortunately makes > it a nonstarter. According to the FAQ (specificall

btrfs native encryption

Dear btrfs maintainers, Google is evaluating btrfs for its potential use in android, but currently the lack of native file-based encryption unfortunately makes it a nonstarter. According to the FAQ (specifically the answer to "Does btrfs support encryption"), nobody is current

[LSF/MM TOPIC] [LSF/MM ATTEND] BTRFS Encryption

I am working on BTRFS Encryption stage 2 design [1], which circles around the data center solution requisites. I shall be presenting an overview of the proposed design, so to obtain the constructive feedback and comments. And, I hope this will help to finalize on the design before

Re: [RFC] Preliminary BTRFS Encryption

re was enough filesystem left to salvage). > For an AEAD that lacks nonce-misuse-resistance, it's "merely" downgrading > security from AEAD to simple encryption (GCM, for instance, becomes > exactly CTR). This would be almost okay (it's a fsck tool, after all), >

Re: Experimental btrfs encryption

gt; Hi Anand, > > After reading this thread on the web archives, and seeing that some > folks seem to be a bit confused about "vfs level crypto", fs/crypto, > and ext4/f2fs encryption, I thought I would give a few comments. > > First of all, these are all the same thing. Ini

Re: [RFC] Preliminary BTRFS Encryption

On Mon, 19 Sep 2016 14:08:06 -0400, Zygo Blaxell wrote: > On Sat, Sep 17, 2016 at 06:37:16AM +, Alex Elsayed wrote: >> > Encryption in ext4 is a per-directory-tree affair. One starts by >> > setting an encryption policy (using an ioctl() call) for a given >> >

Re: [RFC] Preliminary BTRFS Encryption

y suspect it motivated >> choosing XTS in the first place - something I feel is an _error_ in the >> long run, and a dangerous one. (IMO, anything _but_ AEAD should be >> forbidden in FS-level encryption.) >> >> In a nonce-misuse-resistent AEAD, there _is_ no auth

Re: [RFC] Preliminary BTRFS Encryption

rror_ in the > long run, and a dangerous one. (IMO, anything _but_ AEAD should be > forbidden in FS-level encryption.) > > In a nonce-misuse-resistent AEAD, there _is_ no auth tag: There's some > amount of inherent ciphertext expansion, and the ciphertext _cannot be > decrypted at al

Re: [RFC] Preliminary BTRFS Encryption

On Sat, Sep 17, 2016 at 06:37:16AM +, Alex Elsayed wrote: > > Encryption in ext4 is a per-directory-tree affair. One starts by > > setting an encryption policy (using an ioctl() call) for a given > > directory, which must be empty at the time; that policy includes a > >

Re: Experimental btrfs encryption

fs/crypto, and ext4/f2fs encryption, I thought I would give a few comments. First of all, these are all the same thing. Initially ext4 encryption was implemented targetting ChromeOS as the initial customer, and as a replacement for ecryptfs. Folks have already pointed you at the design document

Re: [RFC] Preliminary BTRFS Encryption

is due, which is important and I believe those review comments can be accommodated without major changes from here. I disagree. Others commented on the crypto stuff, I see enough points to address that would lead to major changes. Also yes, thanks for the emails, I hear, per file encryption

Re: [RFC] Preliminary BTRFS Encryption

ty experts is due, > >> which is important and I believe those review comments can be accommodated > >> without major changes from here. > > > > I disagree. Others commented on the crypto stuff, I see enough points to > > address that would lead to major

Re: [RFC] Preliminary BTRFS Encryption

On Sat, Sep 17, 2016 at 10:12 AM, Anand Jain wrote: > btrfs keeps it only in-memory and key hash goes to the disk. > Further in the long we need an integration with key management > system as well. Maybe LUKS2 is usable for this part, and still adaptable since it's

Re: [RFC] Preliminary BTRFS Encryption

On Sat, Sep 17, 2016 at 12:38:30AM -0400, Zygo Blaxell wrote: > There's also a nasty problem with the extent tree--there's only one per > filesystem, it's shared between all subvols and block groups, and every > extent in that tree has back references to the (possibly encrypted) subvol > trees.

Re: [RFC] Preliminary BTRFS Encryption

Hi Eric, Thanks for the constructive feedback, pls see inline below. On 09/17/2016 02:58 PM, Eric Biggers wrote: On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: This patchset adds btrfs encryption support. Hi Anand, I'm part of a team that will be maintaining

Re: [RFC] Preliminary BTRFS Encryption

On Fri, 16 Sep 2016 23:58:31 -0700, Eric Biggers wrote: > On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: >> >> This patchset adds btrfs encryption support. >> >> > Hi Anand, > Note: even better would be an authenticated encryption mode. That isn't

Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: > > This patchset adds btrfs encryption support. > Hi Anand, I'm part of a team that will be maintaining and improving ext4 encryption. Because f2fs now shares much of the code, it will benefit from the ext4 encryption

Re: [RFC] Preliminary BTRFS Encryption

he nested > subvols weren't created with their own separate keys. For snapshots, > we wouldn't even ask--the snapshot and its origin subvol would share a > key unconditionally. (*) I'll quote the LWN article on the way EXT4 (and VFS) encryption works (https://lwn.net/Articles/639427/): >

Re: [RFC] Preliminary BTRFS Encryption

could ask, but if the answer was "no, please do not use the origin subvol's key", then btrfs would return EINVAL and not create the snapshot, since there would be no way to read any data contained within it without the key. > > Indeed, with the generic file encryption, btrfs may not ev

Re: [RFC] Preliminary BTRFS Encryption

On Thu, Sep 15, 2016 at 10:24:02AM -0400, Austin S. Hemmelgarn wrote: > On 2016-09-15 10:06, Anand Jain wrote: > >>How does this handle cloning of extents? Can extents be cloned across > >>subvolume boundaries when one of the subvolumes is encrypted? > > > > Yes only if both the subvol keys

Re: [RFC] Preliminary BTRFS Encryption

here. I disagree. Others commented on the crypto stuff, I see enough points to address that would lead to major changes. Also yes, thanks for the emails, I hear, per file encryption and inline with vfs layer is also important, which is wip among other things in the list. Implementing the recent

Re: [RFC] Preliminary BTRFS Encryption

On 09/16/2016 09:12 AM, Dave Chinner wrote: On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests to confirm that there is no regression

Re: [RFC] Preliminary BTRFS Encryption

On 09/15/2016 07:47 PM, Alex Elsayed wrote: On Thu, 15 Sep 2016 19:33:48 +0800, Anand Jain wrote: Thanks for commenting. pls see inline below. On 09/15/2016 12:53 PM, Alex Elsayed wrote: On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote: This patchset adds btrfs encryption support

Re: [RFC] Preliminary BTRFS Encryption

For the most part, I agree with you, especially about the strategy being backward - and file encryption being a viable more-easily-implementable direction. However, you are doing yourself a disservice to compare btrfs' features as a "re-implementation" of existing tools. The exis

Re: [RFC] Preliminary BTRFS Encryption

On Thu, Sep 15, 2016 at 10:24:02AM -0400, Austin S. Hemmelgarn wrote: > >> What happens when you try to > >> clone them in either case if it isn't supported? > > > > Gets -EOPNOTSUPP. > That actually makes more sense than what my first thought for a return > code was (-EINVAL). Should be

Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: > This patchset adds btrfs encryption support. > > The main objective of this series is to have bugs fixed and stability. > I have verified with fstests to confirm that there is no regression. > > A design write

Re: [RFC] Preliminary BTRFS Encryption

On Fri, 16 Sep 2016 11:12:13 +1000, Dave Chinner wrote: > On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: >> >> This patchset adds btrfs encryption support. >> >> The main objective of this series is to have bugs fixed and stability. >> I have

Re: [RFC] Preliminary BTRFS Encryption

On Fri, 16 Sep 2016 11:12:13 +1000 Dave Chinner <da...@fromorbit.com> wrote: > > As of now these patch set supports encryption on per subvolume, as > > managing properties on per subvolume is a kind of core to btrfs, which is > > easier for data center solution-ing, seamle

Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: > > This patchset adds btrfs encryption support. > > The main objective of this series is to have bugs fixed and stability. > I have verified with fstests to confirm that there is no regression. > > A design wr

Re: [RFC] Preliminary BTRFS Encryption

On 2016-09-15 10:06, Anand Jain wrote: Thanks for comments. Pls see inline as below. On 09/15/2016 07:37 PM, Austin S. Hemmelgarn wrote: On 2016-09-13 09:39, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability

Re: [RFC] Preliminary BTRFS Encryption

Thanks for comments. Pls see inline as below. On 09/15/2016 07:37 PM, Austin S. Hemmelgarn wrote: On 2016-09-13 09:39, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests

Re: [RFC] Preliminary BTRFS Encryption

On Thu, 15 Sep 2016 19:33:48 +0800, Anand Jain wrote: > Thanks for commenting. pls see inline below. > > On 09/15/2016 12:53 PM, Alex Elsayed wrote: >> On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote: >> >>> This patchset adds btrfs encryption suppo

Re: [RFC] Preliminary BTRFS Encryption

On 2016-09-13 09:39, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests to confirm that there is no regression. A design write-up is coming next, however here below is the quick

Re: [RFC] Preliminary BTRFS Encryption

Thanks for commenting. pls see inline below. On 09/15/2016 12:53 PM, Alex Elsayed wrote: On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests

Re: [RFC] Preliminary BTRFS Encryption

Thanks for the comments. Pls see inline below.. On 09/15/2016 01:38 PM, Chris Murphy wrote: On Tue, Sep 13, 2016 at 7:39 AM, Anand Jain <anand.j...@oracle.com> wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability.

Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 7:39 AM, Anand Jain <anand.j...@oracle.com> wrote: > > This patchset adds btrfs encryption support. > > The main objective of this series is to have bugs fixed and stability. > I have verified with fstests to confirm that there is no regression.

Re: [RFC] Preliminary BTRFS Encryption

On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote: > This patchset adds btrfs encryption support. > > The main objective of this series is to have bugs fixed and stability. > I have verified with fstests to confirm that there is no regression. > > A design write-up is co

Re: [RFC] Preliminary BTRFS Encryption

news! Thanks for yor work. I'm looking forward to use the >> encryption. >> >> I would like to ask a few question regarding the feature set. >> >> 1. is encryption of an existing, filled and unencrypted subvolume without >> manually moving the data possible? > > Encryp

Re: [RFC] Preliminary BTRFS Encryption

Wilson, Thanks for commenting. Pls see inline below.. On 09/14/2016 12:42 AM, Wilson Meier wrote: Hi Anand, these are great news! Thanks for yor work. I'm looking forward to use the encryption. I would like to ask a few question regarding the feature set. 1. is encryption of an existing

Re: [RFC] Preliminary BTRFS Encryption

Hi Anand, these are great news! Thanks for yor work. I'm looking forward to use the encryption. I would like to ask a few question regarding the feature set. 1. is encryption of an existing, filled and unencrypted subvolume without manually moving the data possible? 2. What about encrypting

Re: [PATCH] btrfs: Encryption: Add btrfs encryption support

lic, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Anand-Jain/btrfs-Encryption-Add-btrfs-encryption-support/20160913-214237 base: https://git.kernel.org/pub/scm/linux/ker

Re: [PATCH] btrfs: Encryption: Add btrfs encryption support

lic, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Anand-Jain/btrfs-Encryption-Add-btrfs-encryption-support/20160913-214237 base: https://git.kernel.org/pub/scm/linux/ker

Re: [PATCH] btrfs: Encryption: Add btrfs encryption support

lic, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Anand-Jain/btrfs-Encryption-Add-btrfs-encryption-support/20160913-214237 base: https://git.kernel.org/pub/scm/linux/ker

[PATCH 2/2] btrfs-progs: add encryption support

sage[] = { - "btrfs subvolume create [-i ] [/]", + "btrfs subvolume create [-i ] [-e ] [/]", "Create a subvolume", "Create a subvolume in . If is not given", "subvolume will be created in the current directory."

[PATCH] fstests: btrfs: support encryption

This will help to test kernel encryption patch, and when compiled with the below defines. So to use the existing fstests test-cases on top of encryption. diff --git a/fs/btrfs/encrypt.h b/fs/btrfs/encrypt.h index 8e794da9d8f5..1ae6840d0742 100644 --- a/fs/btrfs/encrypt.h +++ b/fs/btrfs/encrypt.h

[RFC] Preliminary BTRFS Encryption

This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests to confirm that there is no regression. A design write-up is coming next, however here below is the quick example on the cli usage. Please try out

[PATCH] btrfs: Encryption: Add btrfs encryption support

Adds encryption support. Based on v4.7-rc3. Signed-off-by: Anand Jain <anand.j...@oracle.com> --- fs/btrfs/Makefile | 4 +- fs/btrfs/btrfs_inode.h | 6 + fs/btrfs/compression.c | 30 +- fs/btrfs/compression.h | 10 +- fs/btrfs/c

Re: Pointers to mirroring partitions (w/ encryption?) help?

04.06.2016 20:31, B. S. пишет: >>> >>> Yeah, when it comes to FDE, you either have to make your peace with >>> trusting the manufacturer, or you can't. If you are going to boot >>> your system with a traditional boot loader, an unencrypted partition >>> is mandatory. >> >> No, it is not with grub2

Re: Pointers to mirroring partitions (w/ encryption?) help?

secure boot support). > The ESP can't be encrypted. > It should be possible if you use hardware encryption (SED). > http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/ > > It's vaguely possible for the SED variety of drive to support fully > encrypted ev

Re: Pointers to mirroring partitions (w/ encryption?) help?

at 4096 bytes each requires a 260MiB minimum volume. > >> The additional problem is most articles reference FDE (Full Disk Encryption) >> - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having >> problems finding concise links on the topics, -FDE -"Full Disk En

Re: Pointers to mirroring partitions (w/ encryption?) help?

should be whatever max size FAT32 has. ... The additional problem is most articles reference FDE (Full Disk Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted /boot. So having problems finding concise links on the topics, -FDE -"Full Disk Encryption". Yeah, when it co

Re: Pointers to mirroring partitions (w/ encryption?) help?

as. ... > >> The additional problem is most articles reference FDE (Full Disk >> Encryption) - but that doesn't seem to be prudent. e.g. Unencrypted >> /boot. So having problems finding concise links on the topics, -FDE >> -"Full Disk Encryption". > > Yeah, wh

Re: Pointers to mirroring partitions (w/ encryption?) help?

Confusing, however, is having those (both) partitions encrypted. Seems some work is needed beforehand. But I've never done encryption. (This is moot if you go with `dup`.) It's actually quite easy with every major distro. If we're talking about a fresh install, the distro installer probably h

Re: Pointers to mirroring partitions (w/ encryption?) help?

ity benefits with `dup`. One of the best features and initally confusing things about Btrfs is how much is done "within" a file system. (There is a certain "the Btrfs way" to it.) > Confusing, however, is having those (both) partitions encrypted. Seems some > work is needed befo

Pointers to mirroring partitions (w/ encryption?) help?

Hallo. I'm continuing on sinking in to btrfs, so pointers to concise help articles appreciated. I've got a couple new home systems, so perhaps it's time to investigate encryption, and given the bit rot I've seen here, perhaps time to mirror volumes so the wonderful btrfs self-healing

Re: [RFC PATCH 1/1] btrfs: Encryption: Add btrfs encryption support

Thanks for the review comments Liu bo. I am looking into the comments. Anand On 03/10/2016 10:19 AM, Liu Bo wrote: On Wed, Mar 02, 2016 at 12:08:10AM +0800, Anand Jain wrote: *** *** Warning: Experimental code. *** Adds encryption support. The branch is based on v4.5-rc6. Signed-off

Re: [RFC] Experimental btrfs encryption

On Thu, Mar 03, 2016 at 09:58:53AM +0800, Anand Jain wrote: > . (I received couple of private emails on this, so looks like > I confused you and I'm writing again to clear the air on this). > > > - Uses btrfs compression framework, so compression and then > >encry

Re: [RFC] Experimental btrfs encryption

thing, > but I hope we can encrypt the subvolume tree blocks too, if using > per-subvolume policy. > To provide a feature near block-level encryption. I´d really love an approach to at least optionally be able to hide the metadata structure completely except for which blocks on the blo

Re: [RFC PATCH 1/1] btrfs: Encryption: Add btrfs encryption support

On Wed, Mar 02, 2016 at 12:08:10AM +0800, Anand Jain wrote: > *** > *** Warning: Experimental code. > *** > > Adds encryption support. The branch is based on v4.5-rc6. > > Signed-off-by: Anand Jain <anand.j...@oracle.com> > --- > fs/btrfs/Makefile | 2 +

Re: [RFC] Experimental btrfs encryption

encryption in f2fs and ext4, and both have a compatible userspace API and ABI. It would be a pitty to deviate from that intead of reusing it, and if needed extending it. I wasn't very clear here sorry. per-subvolume is my favorite way, but we'll go with the existing ABIs as well. There's no reason

Re: [RFC] Experimental btrfs encryption

The way btrfs encryption interacts with the keyring APIs is important, and "reconsidering later" will potentially represent an API/ABI break. Please keep it in mind. Yep. We would take considerable time to get the API frozen and integrated, as once its in, its there f

Re: [RFC] Experimental btrfs encryption

ook some time to figure out in my implementation. The way btrfs encryption interacts with the keyring APIs is important, and "reconsidering later" will potentially represent an API/ABI break. Please keep it in mind. -- To unsubscribe from this list: send the line "unsubscribe linux-b

Re: [RFC] Experimental btrfs encryption

. (I received couple of private emails on this, so looks like I confused you and I'm writing again to clear the air on this). - Uses btrfs compression framework, so compression and then encryption is not possible. However yet evaluate if there are encryption algorithm which can

Re: [RFC] Experimental btrfs encryption

compression and encryption can be done at the same time. (We are already testing the patch to allow dedup to cooperate with compression) So no need to find a encryption with can compress. (Never mix 2 different work together) I am not too sure about this. But logically if one encoding engine can do

Re: [RFC] Experimental btrfs encryption

Anand Jain wrote on 2016/03/02 16:50 +0800: Thanks! for commenting Qu. As you are working near these codes appreciate any code review comments. +1 here, but in fact, it's easy to deal with. As long as not implement encryption as a compression method. Just like inband dedup, we use

Re: [RFC] Experimental btrfs encryption

Hi Qu, Not only move, but also reflink/inband dedup. oh yes thanks. I shall add those. Yes, but in fact, you can use another method, just like in-band de-dup, by adding new hook into async_cow_start() and async_cow_end(), allowing compression and encryption can be done at the same time

Re: [RFC] Experimental btrfs encryption

Thanks! for commenting Qu. As you are working near these codes appreciate any code review comments. +1 here, but in fact, it's easy to deal with. As long as not implement encryption as a compression method. Just like inband dedup, we use the following method to support dedup

Re: [RFC] Experimental btrfs encryption

Thanks Austin for commenting. Yes to most of it. And probably I should have titled known-issues to known-bugs, which I meant to fix before final integration. In general: Its good to explore options of both compression+encryption OR an algorithm engine which can automatically do both

Re: [RFC] Experimental btrfs encryption

it per-subvolume for now, just because subvolumes are so cheap and because it seems like a better collection point for general use. But as the other filesystems add features we'll make sure and keep parity with what users expect. We already have per-file encryption in f2fs and ext4, and both have

Re: [RFC] Experimental btrfs encryption

Austin S. Hemmelgarn wrote on 2016/03/01 11:41 -0500: On 2016-03-01 11:08, Anand Jain wrote: This patchset adds btrfs encryption support. While I think this is a great feature to have, I personally think we're better off waiting for the ext4/F2FS encryption API's to get pushed up to the VFS

Re: [RFC] Experimental btrfs encryption

Anand Jain wrote on 2016/03/02 00:08 +0800: This patchset adds btrfs encryption support. Warning: The code is in prototype/experimental stage and is not suitable for the production data yet. Example usage: Create an encrypted subvolume: btrfs subvol create -e /btrfs/sv1 Paraphrase

Re: [RFC] Experimental btrfs encryption

per-subvolume for now, just because > > subvolumes are so cheap and because it seems like a better collection > > point for general use. But as the other filesystems add features we'll > > make sure and keep parity with what users expect. > > We already have per-file encryp

Re: [RFC] Experimental btrfs encryption

tter collection > point for general use. But as the other filesystems add features we'll > make sure and keep parity with what users expect. We already have per-file encryption in f2fs and ext4, and both have a compatible userspace API and ABI. It would be a pitty to deviate from t

Re: [RFC] Experimental btrfs encryption

On 2016-03-01 11:46, Chris Mason wrote: On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote: On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote: This patchset adds btrfs encryption support. Warning: The code is in prototype/experimental stage and is not suitable

Re: [RFC] Experimental btrfs encryption

On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote: > On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote: > > This patchset adds btrfs encryption support. > > > > Warning: > > The code is in prototype/experimental stage and is not suitable >

Re: [RFC] Experimental btrfs encryption

On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote: > This patchset adds btrfs encryption support. > > Warning: > The code is in prototype/experimental stage and is not suitable > for the production data yet. Can you share some design documents? Will it be compatibl

[RFC PATCH 1/1] btrfs: Encryption: Add btrfs encryption support

*** *** Warning: Experimental code. *** Adds encryption support. The branch is based on v4.5-rc6. Signed-off-by: Anand Jain <anand.j...@oracle.com> --- fs/btrfs/Makefile | 2 +- fs/btrfs/btrfs_inode.h | 2 + fs/btrfs/compression.c | 53 - fs/btrfs/compression.h | 1 + fs

[RFC PATCH 2/2] btrfs-progs: Encryption: add encrypt sub cli

*** Warning: Experimental cli and codes *** This is the btrfs-progs part of btrfs encryption. The branch is based on btrfs-progs v4.4.1. Depends on keyctl-utils and libscrypt packages. Signed-off-by: Anand Jain <anand.j...@oracle.com> --- Makefile.in | 5 +- btrfs-list.c

[RFC] Experimental btrfs encryption

This patchset adds btrfs encryption support. Warning: The code is in prototype/experimental stage and is not suitable for the production data yet. Example usage: Create an encrypted subvolume: btrfs subvol create -e /btrfs/sv1 Paraphrase: <- Review encryption status btrfs subvol s

BtrFS and encryption

Hello, it seems that ext4 is getting encryption-support http://thread.gmane.org/gmane.comp.file-systems.ext4/48206 rumors say because of performance-problems with eCryptFS in Android. f2fs should get a compatible interface too. I would like to see this in BtrFS as well… MfG

Moving over to use BTRFS - first time, needs encryption

Hi, I would be pleased to get some help after I have looked and not figured out how this should work: Summary === btrfs device add LUKS encrypted container path Returns - Inappropriate ioctl for device Details = // I have an existing btrfs file system // built from one ~650G partition

Re: Moving over to use BTRFS - first time, needs encryption (btrfs: message 1 of 20)

Update: I found this: .. by upgrading kernel ...according to the BTRFS wiki, changing raid levels after the filesystem has been created isn't supported for 3.2 series and older kernels. Need to move from stable stock., Ubuntu 12.04LTS and Debian 7.2.

Re: Moving over to use BTRFS - first time, needs encryption

--version Btrfs Btrfs v0.19 # uname -a Linux 874-deb 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux [I've no particular personal knowledge on encrypted filesystem usage, but this is a general reply...] First, are you aware of the btrfs wiki and have you read its encryption discussion (among

Re: Encryption

need encryption. Forbids? That is just plain wrong. I have one btrfs filesystem on top of two encrypted devices. Works just fine. Sander -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: Encryption

On Thu, Dec 13, 2012, at 1:17, Sander wrote: Forbids? That is just plain wrong. I have one btrfs filesystem on top of two encrypted devices. Works just fine. That's dynamite Sander. But I am not going to contravene the instructions, then have problems, only to come back here and have fingers

Re: Encryption

the instructions, then have problems, only to come back here and have fingers wagged in my face telling me this is all EXPERIMENTAL! Well, I'm afraid that applies to the information on the wiki, too -- that's also experimental, to a degree. The notes on the wiki about behaviour of encryption layers

Re: Encryption

So there is no way to have filesystem encryption, while keeping snapshots? On Fri, Dec 7, 2012, at 8:16, [2]merc1...@f-m.fm wrote: We're using a backups server to back up all machines in a LAN. Four 2TB disks are assembled in a BTRFS RAID array and mounted as /media/backups. Under

Re: Encryption

On Wed, Dec 12, 2012 at 11:12 AM, merc1...@f-m.fm wrote: So there is no way to have filesystem encryption, while keeping snapshots? I run btrfs on top of LUKS encryption on my laptop. You should be able to do the same. You could then run rsync through ssh. However, rsync will have

Re: Encryption

On Wed, Dec 12, 2012, at 10:31, Mitch Harder wrote: I run btrfs on top of LUKS encryption on my laptop. You should be able to do the same. You could then run rsync through ssh. However, rsync will have no knowledge of any blocks shared under subvolume snapshots. Btrfs does not yet have

Re: Encryption

On Wed, Dec 12, 2012 at 12:38 PM, merc1...@f-m.fm wrote: On Wed, Dec 12, 2012, at 10:31, Mitch Harder wrote: I run btrfs on top of LUKS encryption on my laptop. You should be able to do the same. You could then run rsync through ssh. However, rsync will have no knowledge of any blocks

Re: Encryption

' 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

Re: Encryption

: --- 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

  1   2   >