Instead of doing whatever I was planning to do today, I ended up putting my new (bought 3 weeks ago, installed 2 weeks ago... I'm busy, okay?) NVME SSD into operation.

Now it is running BTRFS for the added security of a CoW filesysrem, has systemd-homed for home directory management, and systemd-boot for bootloader.

I decided to not use home directory encryption, because having a large image file on a CoW filesystem seemed like a silly idea.

#linux #systemd #encryption

@nicemicro Hi. I am only a semi-nerd. Why do you think encryption was silly in your instance? I am under the impression that encryption was for general security.

@alistair #BTRFS is a copy-on-write file system by default, which means that if you modify a file, it doesn't get overwritten and there are means to get back to earlier versions via snapshots. Having home directory encryption via #systemd homed, your whole home directory becomes a single large file (like a zip file) that is then mounted on log-in.
You could probably simply turn off CoW for that file and use BTRFS inside the encrypted volume, but I didn't bother with that.

#linux #Encryption

@nicemicro CoW doesn't ~directly~ have anything to do with snapshots and it also works on the block level, not the file level. I could be missing something, but I don't see an issue with using CoW for large files. It may become fragmented over time, but that shouldn't really be an issue for home directory type data.
@geoscum I see what you mean. I guess I should have thought about it a bit more I guess. I just didn't want to do something I felt I am not understanding sufficiently.
@nicemicro @alistair I don't have any experience with homed, but it also sounds much easier to use fscrypt, rather than luks... maybe. I assume you were talking luks on homed with the single large file?
@geoscum yes, systemd-homed uses luks encryption.
As far as I know, fscrypt is not supported on BTRFS.