Professor Andersen is talking about dumping the phone’s RAM to file on an Android device to access your LUKS partition . . this is not the same as a LUKS partition in LVM on linux please see here for further information.
tl;dr if someone can dump your ram to file/ read your key in ram they can access everything already.
On the Btrfs note Parrot uses it by default (which it self is not encrypted) but the entire fs (ext4) sits as a LUKS encrypted partition with LVM.
on Parrot if you encrypt with LVM at install it is an LUKS partition running the ext4 filesystem, inside that parrot runs unencrypted btrfs so you have the best of both (btrfs and LUKS full-disk encryption)
you have no way to protect yourself from unencrypted headers leak from memory dumps, but do you really believe to be subject to such complex and expensive threat model? wouldn’t it be way easier to kidnap your wife or son and force you to give the password? wouldn’t it be way cheaper to put you in prison until you decrypt the disk for them?
who are you?
who is your enemy?
who do you need to be defended from?
how much money can your opponents invest in cracking your data?
how valuable is your data to justify complex attack operations against you?
these are the questions you have to find an answer to if you have to protect yourself properly.
OPSEC (operational security) is quite a complex art designed to protect yourself from the ground up, and you have to find the best practices for your particular case.
personally speaking i believe that full disk encryption is a must and anyone should have it on its computer as a good starting point for the system security, as it makes impossible to boot the computer in live mode and bypass authentication systems.
yes, memory forensics can give an attacker access to the unencrypted key, and then read the whole disk in clear, but it is a very complex operation that can be performed only by having your computer turned on in the hands and being able to extract the memory units and reading them without destroying its content, which is a very hard thing to do.
cryptsetup, veracrypt and other cryptographic systems should have various countermeasures in place to mitigate such attacks, like trying to load the unencrypted headers in an as low memory region as possible to keep them in the processor cache instead of ram. i am not sure of this statement as i remembered someone mentioning it at some conference some years ago.
what about laptops with soldered and undetachable memory units?
btrfs does not protect you from memory leaks. it is just an awesome CoW filesystem with very advanced features, but everything in linux (and in the IT world) is organized in stacks, and filesystems exist on a higher layer, while cryptsetup cryptography happens on a lower level, then a “virtual” unencrypted disk is shown to the system and a filesystem is created into it, with cryptsetup translating data from the virtual unencrypted device to the real encrypted one
if you use a swap partition, make sure to encrypt it, or stop using it, otherwise a lot of useful information from memory pages would be exposed unencrypted on swap, including very sensible information meant to be stored in a volatile memory, but storage partitions are not volatile at all.