I’m on a Fedora Kinoite system that is entirely on one LUKS encrypted drive, I recently added a second drive to have more space and I’m wondering how I should make use of it.
For now I formatted it completely with a new btrfs partition encrypted with LUKS and to actually add I thought I could:
- automount it to some location, not sure where I should mount it though, I’ve seen many questions online that say to avoid
/mntfor permanent drives and also/media(there are contrasting opinions on that, though), so I thought I could maybe sidestep this question by going with the second option which is the following - extending the already existing btrfs
/sysrootto span across the 2 partitions on the separate drives, but I didn’t find good information on this process when LUKS is involved. It seems like that kind of operation is heavily discouraged due to risking data loss
So I wonder, what is the best approach and the one that will give me fewer headaches? If it is the second, how do I do it?
Edit: going with the first option I had an issue where the drive wouldn’t be mounted automatically at boot, I then read through my /etc/crypttab more carefully and saw that the UUID was wrong, I had used the partition UUID (PARTUUID as seen with the blkid command) instead of the actual device UUID, after correcting that it works and mounts correctly. Just a small oversight, the hardest to notice sometimes.
References:
If you have a specific purpose in mind for the drive, then mounting it statically is probably the easiest solution.
My setup is:
- 2 TB NVMe
- 200 GB partition at
/ - The rest (~1.8 TB) mounted at
/games
- 200 GB partition at
- 1 TB SATA SSD mounted at
/home - 3 TB HDD mounted at
/hdd
/mntand/mediaare used differently based on the OS./mntis supposed to be used for temporary manual mounts, but you can use it (or a subdirectory) as a permanent mount point./mediais meant to contain mount points for dynamically mounted removable devices, but modern systems generally use/run/media/$USERfor that purpose; I would personally avoid it nevertheless.(Solved, explained in the post)
I’m trying that right now, but I can’t figure out how to decrypt and mount my drive at boot, I’ve read that simply giving the drive the same passphrase as that of the first drive would enable unlocking both at boot (reference), but it didn’t work for me, the drive remains encrypted and also not mounted despite me adding the entry to
/etc/crypyttaband/etc/fstabI use Gnome Disks for this, even on Kinoite.
Ah interesting, is the process more automated with it?
The UI is not too complicated, which is why I like it. I use it to automatically unlock and mount my drives in /run/media/drive_name on boot.
deleted by creator
- 2 TB NVMe
If you want to just extend storage space, maybe mergerfs?
/mediais now for the system to mount stuff automatically. Using/mntfor something you’re configuring personally is fine.You could mergerfs the new drive with some folder you’re already storing a bunch of stuff, and it will pool the storage capacity of the drives for that folder.
Looked up this mergerfs, I have to say that it goes over my head quite a bit, if the point is to pool the drive capacity then what’s the advantage of using that over the native capabilities of btrfs?
pool the storage capacity of the drives for that folder.
So I could do that for the root folder as well I imagine?
Good point about the
/mntthing, I think I’ll go with that, at least initiallythen what’s the advantage of using that over the native capabilities of btrfs?
btrfs multi device file systems have some limitations. Adding a drive is instant, but if you want to stripe the data using raid0, that requires a lengthy balancing operation. The alternative is “single” mode, which does not concern itself with striping, and just pools the storage available. The disadvantage, is that in single mode you get the risk of raid0, with no performance benefit. btrfs does not actually make sure that the different blocks that constitute a single file end up on the same drive, which means that if one fails, you still likely lose everything.
MergerFS does not mess with any of the filesystems being combined. It can be configured to work in different ways, but each drive will remain its own, consistent, functioning file system. Drives can be browsed individually, removed, added etc. Instantly. To “empty” a drive, you just move the files on it to the rest by using the non merged folders. By default, “writing” a new file will always go to the drive with the most free space, and individual files cannot be stored “across” several drives even though the contents of a folder can be. This way, whatever is on each drive, can never be damaged by the failure of another drive.
So the benefits are isolation, and convenience. The downside is a definite performance hit, which may not be significant depending on your system or what you’re storing in the merged filesystem.
So I could do that for the root folder as well I imagine?
No. And you wouldn’t want to. First for the performance hit. Second, because mergerfs merges folders (drives have to be mounted, first), and uses a third as a mountpoint. As an example, to “expand” your home folder, you’d move your homefolder somewhere else, then merge that moved folder with the new drive (which you still have to mount somewhere), and then you’d mount the resulting file system where your old home folder was before.
You could even have two folders on the second drive. Use one to merge somewhere you want to pool all your storage, and the other to put stuff on the second drive in a way where losing the first won’t make half the files go missing. You might use that to store a copy of the OS install from the first drive, for example.
That sounds promising, but I feel like it is quite complex for me, maybe I’ll look into it again another time, thanks for the suggestion and explaining to me though!
I have 3 external drive and I just shoved everything to /media, and mount it with fstab for auto mounting and static drive path
So I’m assuming your drives are not encrypted, right?
No it’s not, I don’t have any reason to encrypt my drives, but you can try it for yourself it’s only require a few basic commands to setup and no risk involved
Since you’re already on btrfs it’s probably better to actually use the features it has to expand your existing filesystem to cover both drives.
But if you just want to mount it somewhere and not worry about figuring out anything complicated, what I did is mount my big new cheap disk at /home/bigdisk and then have symlinks pointing to it such as
~/Videos -> /home/bigdisk/Videos.Have you considered simply setting btrfs to RAID 0?
Raid level 0 increases risk of data corruption should there be a disk failure… Don’t do that.
A disk failure will cause you to lose data, yes. But that’s also the case in all the other solutions discussed here. Backups should be handled separately and are not part of the original question.
Raid 0 increases that risk though.
How does that increase the risk compared to something like JBOD or overlayfs? In both cases you will lose data if a drive fails. Keep in mind that this is btrfs raid0, not regular raid. If anything that decreases the chance of corruption because the metadata is redundantly stored on both drives.
I’ve never done that so I didn’t know you could, anyways I think I’ll stay away from these pooling solutions for now since I risk corrupting my data too much
