Looking for advice re: LUKS-encrypted /home drive

General
1

I’m planning on switching from Fedora 43 Desktop to CachyOS because of some issues I’ve had with Fedora that I’ve been unable to solve. There are some DVD-drive and video-card hardware-encoding incompatibilities that I hope CachyOS will not have.

Anyway, I have two hard drives – a 2TB NVMe SSD (boot, root and everything else except for /home) and a 4TB SATA SSD (/home). The /home drive is LUKS-encrypted. It does not automatically unlock with the TPM. GRUB asks me for the password upon bootup. (It is formatted using btrfs, in case that matters. One 4TB partition with no LVM stuff – just a plain whole-drive partition.)

When I install CachyOS, my goal is NOT to erase that drive, and just have the installer recognize it as the /home folder. But since it’s LUKS-encrypted, I’m not really sure how to get CachyOS to read the drive at all, since it’s GRUB that asks for the password to unlock it, and booting from the CachyOS Live-USB stick bypasses GRUB entirely…

So… My question is – how do I get CachyOS to use that encrypted drive as the /home folder without erasing it?

2

Well, simply accessing it from the LiveUSB shouldn’t be a problem. Like any encrypted volume that isn’t already unlocked, you can just use Dolphin to navigate to it and you will be prompted for the password to unlock it when you try to mount it. You could also use sudo cryptsetup luksOpen in a terminal to just decrypt it without mounting it anywhere.

However, the safest way to preserve it, and ensure the installer doesn’t do something unwanted with it during install, is probably to just:

  1. Leave your home drive encrypted initially
  2. Install to your system drive normally, which will create its own /home subvolume (assuming btrfs for system)
  3. Before rebooting, mount the new system drive somewhere
  4. Modify /etc/fstab and /etc/crypttab
    • Comment out the freshly created /home subvolume
    • Add your existing /home partition in its place
  5. Later, see about deleting the unwanted /home subvolume… or keep it around as a clean backup /home for emergencies

I think that should work. Haven’t tried this though. Might be overlooking something. Would be prudent to test in a VM with dummy partitions first.

All that said, I would NOT recommend reusing an old /home partition.

It’s always better to start fresh, and keep just your old data / transfer configs selectively.

Distros like to put their own custom config in home directories. If you reuse an old one, you’re not getting the intended config for the new distro, inheriting any old config problems you had, and potentially causing new problems due to differences between old distro and new one.

The old trope of “reinstall system, keep separate home partition” just doesn’t work well in practice. Inherently, /home is part of the system, because it contains configs and other things specific to the system.

You may find this comment (and the whole thread) relevant as well: Are there any traps to be mindful of when transfering a Fedora home folder to a CachyOS install? - #6 by zymotek

Also: Do note that btrfs is slow. It’s a worthwhile sacrifice, for the system partition, to have access to instant snapshots. But, if you take my advice on starting with a fresh /home, and using the second drive as data partition(s), consider also switching it to ext4 or XFS, or just about anything other than btrfs.

3

Ok, that is a good point that I hadn’t thought of – there are definitely config files in there that shouldn’t be copied over… Hmmmm…

That bit about btrfs vs. ext4 vs. XFS, though – if I do have to erase my drive and restore it, I might not be able to change the filesystem, because my backup was done to my NAS via Restic, and (to my knowledge) a Restic repository of a btrfs filesystem cannot be restored to anything other than a btrfs filesystem, due to the way it used btrfs’s snapshots during the backup… But I could be wrong…

Another speed-related question: it’s a 4TB SATA SSD, which isn’t exactly the fastest drive anyway. I think the SATA-3 interface maxes out at a theoretical 600MB/s, and in the real world it’s probably closer to 550 or even 500MB/s. Will ext4 or XFS make that much of a difference on a drive that’s pretty slow to begin with? Or does that make a faster filesystem even more important, because the interface itself is so slow? :thinking:

4

As far as I understand it, that’s not actually the case. Restic operates at the file level and isn’t tied to a specific filesystem like Btrfs. Even if the backup was taken from a btrfs snapshot, Restic just sees regular files and directories and stores their contents and metadata.
I’ve actually tested this in practice: restoring from ext4 → Restic → Btrfs, as well as Btrfs → Restic → F2FS, and Btrfs → Restic → ext4 — all without any issues.

5

A bit of both. The final speed of FS operations is a function of many factors, but they can be roughly grouped into:

  1. IO-bound: FS A requires more/slower actual IO operations than FS B → FS A is slower
  2. CPU/RAM-bound: FS A uses fewer CPU cycles / less RAM than FS B → FS A is faster

The IO-bound portion of the equation will scale roughly linearly with hardware IO speed. While the CPU/RAM portion will have greater impact with faster hardware IO speed, likely with some threshold levels above which the difference becomes more and more pronounced.

You’d have to run benchmarks against different filesystems on your actual hardware, to really know how much of an impact it will have for your specific configuration.

6

#btrfs benchmark for daily used desktop OS

7

That’s a really interesting set of benchmarks. Very favorable for btrfs, with compression turned on, particularly on slower drives with fast CPU. Great counter to the prevailing btrfs is slow narrative.

Might actually be the best option for OPs scenario, provided compression is on.

8

Interesting… So how do I tell CachyOS to enable compressed btrfs on this drive when I install?

9

It defaults to compress=zstd for SSD drives in CachyOS.

Which in turn defaults to compression level 3.

You can change it to compress=zstd:1 or compress=lzo for faster compression (for newly written data) in /etc/fstab, if you want.

10

To be explicit, “lower CPU Usage” compression. This isn’t necessarily faster compression!

Indeed in the benchmarks you posted zstd3 was faster than lzo or zstd1 on the slower SSD tested.

11

Well, ahem, akshually… :index_pointing_up::nerd_face:

It is faster compression, which is why it uses less CPU over time, due to not being the bottleneck and having to wait for IO. It’s not that zstd3 compressed faster, but rather the slower but stronger compression resulted in less blocking on IO.

But, yes, fair point: The way I worded it could have been misunderstood as implying that using zstd:1 always results in faster overall IO throughput, which is not necessarily true. It can be, on fast nvme drives, but not on slower drives.