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

Linux

49418 readers
2362 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:

you are viewing a single comment's thread
view the rest of the comments
[–] [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!