this post was submitted on 26 Jan 2025
32 points (92.1% liked)

Linux

49418 readers
1821 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
32
What's the best way to add a secondary drive? (lemy.lol)
submitted 5 days ago* (last edited 5 days ago) by [email protected] to c/[email protected]
20 comments fedilink hide all child comments
 

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:

  1. automount it to some location, not sure where I should mount it though, I've seen many questions online that say to avoid /mnt for 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
  2. extending the already existing btrfs /sysroot to 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:

all 21 comments
sorted by: hot top controversial new old
[–] rtxn 14 points 5 days ago* (last edited 5 days ago) (1 children)

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
  • 1 TB SATA SSD mounted at /home
  • 3 TB HDD mounted at /hdd

/mnt and /media are used differently based on the OS. /mnt is supposed to be used for temporary manual mounts, but you can use it (or a subdirectory) as a permanent mount point. /media is meant to contain mount points for dynamically mounted removable devices, but modern systems generally use /run/media/$USER for that purpose; I would personally avoid it nevertheless.

[–] [email protected] 3 points 5 days ago* (last edited 4 days ago) (2 children)

(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/crypyttab and /etc/fstab

[–] that_leaflet 3 points 4 days ago (1 children)

I use Gnome Disks for this, even on Kinoite.

[–] [email protected] 1 points 4 days ago (1 children)

Ah interesting, is the process more automated with it?

[–] that_leaflet 3 points 4 days ago

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.

[–] [email protected] 8 points 5 days ago* (last edited 5 days ago) (1 children)

If you want to just extend storage space, maybe mergerfs?

/media is now for the system to mount stuff automatically. Using /mnt for 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.

[–] [email protected] 3 points 5 days ago (1 children)

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 /mnt thing, I think I'll go with that, at least initially

[–] [email protected] 4 points 5 days ago* (last edited 5 days ago) (1 children)

then 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 on the first drive, for example.

[–] [email protected] 3 points 5 days ago

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!

[–] [email protected] 3 points 5 days ago (1 children)

I have 3 external drive and I just shoved everything to /media, and mount it with fstab for auto mounting and static drive path

[–] [email protected] 1 points 5 days ago (1 children)

So I'm assuming your drives are not encrypted, right?

[–] [email protected] 2 points 5 days ago* (last edited 5 days ago)

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

[–] [email protected] 1 points 5 days ago

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.

[–] [email protected] -1 points 5 days ago (2 children)

Have you considered simply setting btrfs to RAID 0?

[–] [email protected] 4 points 5 days ago (1 children)

Raid level 0 increases risk of data corruption should there be a disk failure... Don't do that.

[–] [email protected] 1 points 4 days ago (1 children)

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.

[–] [email protected] 1 points 4 days ago (1 children)

Raid 0 increases that risk though.

[–] [email protected] 1 points 4 days ago* (last edited 4 days ago) (1 children)

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.

[–] [email protected] 1 points 3 days ago

How does that increase the risk compared to something like JBOD or overlayfs?

It doesn't - they all do. I wouldn't recommend any of them.

[–] [email protected] 1 points 5 days ago

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