LVM+LUKS across different drive types

I am about to do a reinstall (due to distro hopping). I am using this a time to actually encrypt my stuff. I am using a machine that has both HDDs and SSDs. I would like to know if anyone has had any experience in spanning LVM across different drive types. Also will LUKs mess up the TRIM and/or garbage collection on SSDs?
My current setup has each of the drives acting independently and getting mounted using the fstab. I would consider using ZFS, but I don’t know how that wil work with Manjaro. Sadly BTRFS does not have encryption at this time.

This will work. That’s actually what LVM is designed for. Keep in mind, though, that if one drive dies, all your data is gone.

This is my recommendation. ZFS will be way more beneficial from a reliability standpoint. Only downside is that ZFS does not support TRIM.

You could also LUKS encrypt your drive, then install btrfs on top of the LUKS volume.

But can the LUKS container be made to spread across multiple drives?
As far as the data itself, I do have syncthing replicating the data that I care about between the computers that need it and a NAS that I built. A loss of data from one machine would be annoying, but not catastrophic.
I was thinking about setting up the LVM, then encrypting with LUKS, and finally have BTRFS as the partition inside that container.
The main issue is that I was self taught in the ways of Linux, so never learned LVM.

Nope. Just encrypt the drives with the same key. Then use one passphrase to unlock the key.

That’s really going to eliminate all the benefit of using btrfs in the first place.

I would still get the copy on write, the checksum verification, and the compression.
Right now I am using BTRFS as a replacement for EXT4, but with compression turned on. I am currently not using any partition management. I have my stuff as actual partitions on the the disk, but formatted as BTRFS.

Kinda had the same problem two weeks ago.
The Arch Wiki helped me a lot.

Lvm is redundant with btrfs and zfs, you’re better off letting them handle volume management than having an extra layer on there.

As for luks, the best way to do it is to encrypt each physical disk and then create your array (whatever you decide to use) using the luks volumes.

As far as I know luks does not support trim as I believe this works at the file system level, luks shouldn’t know what is current data and what is old data, everything should look the same for obvious reasons.

If you really need trim then maybe use a file level encryption method like ecryptfs or encfs.

In the Arch Wiki I read that, it is possible to use trim if you really want it. But it is not recommended for the reason you already mentioned.

These are all good points. I did do a large scale experiment where I indepentantly encrypted each of the drives using Veracrypt. While it worked, I had too many passwords to manage. The AES(TwoFish) scheme was too computationally expensive. I am looking for something that is a little easier to deal with, and would not shred the flash being used. I may even post a writeup of the whole experiment in a different thread.

AES 128 is probably going to be the fastest, especially if your CPU supports aes-ni. AES 256 should also be pretty quick with aes-ni but it’s debatable whether it’s worth the extra computational power as it may not be any more secure. Twofish and blowfish were competing ciphers for aes, Twofish is a good cipher, comparable to aes but there’s no CPU acceleration for it so it will be slower.

You really want your encryption at the disk level and not on top of a raid or lvm or whatever. You can use a script to make it simpler to unlock the disks or use key files stored on a thumb drive and have the disks auto decrypt if the thumb drive is present.