The most complex encrypted disk I have, was designed to lose data rather then let it be compromised. This is not what most people want. Most desire a laptop where when they close the lid "they will be safe" but don't want to type in a password when they raise the lid.One last thought on OP's question: Everyone probably has different thoughts on how to use a large fast NVME disk, but here's some food for thought.
I'm not a big fan of using a fixed disk such as an NVME for the boot disk unless the running workload actually requires that the operating system itself load programs as fast as possible (and I'd be interested in hearing about such workloads!). By this I mean that the OS and associated programs would need to be hitting on that NVME drive constantly, such as running a very large program over and over with requirements for super-fast program startup. But one typically runs such programs once rather than run/exit/run/exit/run/exit/etc.
The reason should be obvious from my response above on how to encrypt such a large system disk: Should it become necessary to rebuild that system disk, it's a more complex multi-step PITA process.
I've found for my workloads that using an SSD or even a high-quality fast SD card (e.g., SanDisk Extreme Pro comparable) makes OS reloads much simpler (with encryption or without), and I use the NVME for a data disk, which is where I want to have the access be as fast as possible.
I think, for resilience, some file system (FS) using LVM or BTRFS or ZFS is the way to go in conjunction with judicious tmpfs (eg: for /tmp/) . I've no experience in the latter two FS but assume you can move a FS from one physical device to another. You can't get away from M$ FAT for booting (just like a PC can't for UEFI) so methinks a GPT device: FAT partition one for booting (rsync that for backup), OS on partition two using whatever FS. Partition three for data.
Statistics: Posted by swampdog — Thu Jul 11, 2024 4:51 pm