Bdtyktl

I'd like to use BTRFS RAID1 with dm_crypt on a microserver. The hard part that I don't understand many things about how filesystems and LUKS work. Let's say we have 2 partitions on a drive and we do a whole drive encryption. Does that mean that both partitions will be encrypted and without knowing the key I won't be able to tell what filesystems they have? If so, then I don't understand how it is possible to have an unencrypted boot partition (necessary to load dm_crypt) on such drives or how btrfs raid1 will work if I encrypt both drives and they don't know from each other until both of them are decrypted? On the other hand if dm_crypt uses the btrfs partitions to store the data encrypted for example in a huge file, then wouldn't the btrfs scrub work on this huge file only and wouldn't a single uncorrectable error kill the whole content of the disks?

Does that mean that both partitions will be encrypted and without
knowing the key I won't be able to tell what filesystems they have?

Yes, both partitions will be encrypted as LUKS partitions. You will be able to tell they are LUKS encrypted partitions. Without the key (and/or passphrase), you will not be able to tell what is inside the partition.

If so, then I don't understand how it is possible to have an
unencrypted boot partition ...

Either (a) the boot partition is a separate [and unencrypted] partition, or (b) the boot loader [GRUB?] asks for the passphrase and knows how to decrypt and mount the boot parition. (I typically use an unencrypted boot partition with Ubuntu. I once saw an encrypted boot partition on an installation of Manjaro Linux.)

The main problem with this setup that since raid1 will be on the upper
level, both hdds/ssds will be encrypted differently, which means
performance penalty and a lot of unnecessary encryption.

I've heard the overhead of disk encryption is negligible. I have never had a problem with it. But then I have never measured the performance impact, and I do not need high speed disk IO on my system.

In any case, you will only pay the cost for multiple encryption when writing data. When reading, only one copy of the data will need to be read.

I use LUKS + ZFS + RAID1, but only for /home. I use ext4 for /, and ext2 for /boot.

(Note that if you have N>2 disks, BTRFS's "RAID1" mode is not really RAID1, as BTRFS will only create 2 copies of your data, not N copies as required by RAID1. In other words, BTRFS "RAID1" with N>2 disks gives you more storage space, not more redundancy.)

I read some texts in the topic. According to them the partitioning and formatting are separate processes, so I don't have to give the file system type by partitioning a block device (ssd/hdd/virtual?). The dm-crypt can convert an unencrypted block device to an encrypted one by encrypting each block (or sector?) individually and the btrfs can live on that encrypted block device.

Note: dmcrypt + btrfs needs 4+ kernel to work properly; 3.2- kernels have compatibility and security issues, 4.0- kernels have performance issues.

The main problem with this setup that since raid1 will be on the upper level, both hdds/ssds will be encrypted differently, which means performance penalty and a lot of unnecessary encryption. According to other texts/answers I read there is no way to do this now. People are working on btrfs encryption, but there is nothing stable yet. Currently the stacked approach with ecryptfs - the btrfs FAQ mentions - is a lot slower than dm-crypt, so that wouldn't be a good solution either. Another option is using zfs, which has encryption support, but afaik. it consumes a lot of memory compared to btrfs.

update (Jan, 2019):

I checked zfs too, it has a nice native encryption and you can encrypt the swap partition too, so I think that is the way to go. It has some drawbacks too, it uses more memory and it isn't as straightforward to add a new disk as with btrfs.