Hodgepodge 3xNAS Part 11 Mergerfs

Published on June 1, 2023 at 5:36 pm by LEW

Introduction

Having discussed RAID arrays in the previous post 9 and post 10, we now need to look at some alternatives. In this post we will be looking at mergerfs.

The mergerfs application is a type of union file system (unionfs) and runs in user space, often referred to as Filesystem in Userspace (FUSE for short). It allows the user (us) to combine multiple partitions (drives) of different sizes into a single logical storage unit. While this is similar to what we did with RAID arrays, this is not RAID, and has some important distinctions, advantages, and disadvantages.

One disadvantage is lack of fault tolerance. This is where a companion application, like snapraid, comes into play. The snapraid application allows us to implement a form of parity that is applicable to the storage pool (array) created with mergerfs. We will be talking about snapraid in the next post.

Installing mergerfs and snapraid

Assuming a Debian 12 Operating System (OS), installation is fairly straight forward. First update the package cache, then upgrade already installed packages (should always do this when installing new software). Then install the specific packages and their dependencies. (root or sudo privileges required).

apt updagte && apt upgrade
apt install mergerfs snapraid

How mergerfs Works

The mergerfs program is a non destructive method of combining drive partitions. Unlike RAID, it does not rewrite drives, but rather uses existing partition and file systems. Technically the file systems do not even have to be the same type (although this would be a bad practice).

mergerfs example graphic

Lets look at a quick example (while not the best, it should make the point). Also note that our example will be slightly different that the illustration above. I will correct this when I have some free time.

Lets assume we have an existing system with a single disk, which has the /home folder on a different partition that the Operating System (OS). Now lets add a second drive for the purpose of expanding the storage capacity available in our home folder.

We setup mergerfs to use our /home partition as our final merger point. So we need to mount sda2 and sdb1 to different mount points. Then we will use mergerfs to combine them both in our home partition.

Then mergerfs will, in the background, combine all folders and files in to the /home directory mount point, and it will take care of deciding which partition each new file goes to, using policies we set for mergerfs. Files will never be split across partitions.

We can run mergerfs on a one time basis from the command line. However, we want to set it up to run every time we boot. We will use the /etc/fstab file to do this.

Setup mergerfs

I am assuming sdb has a single partition spanning the entire drive, and that partition, sdb1, has been formatted with the ext4 file system. This should also be the file system used on the partitions of sda (sda1 and sda2)under a normal Debian install.

The first order of business is to setup mount points for the partitions we want to combine. We want to use the /home partition as our final merger mount pooint. So we will keep our drive partition mount points in the /srv folder.

mkdir /srv/Disk1
mkdir /srv/Disk2

We can get the UUID of our partitions using the blkid command (as sudo or root). Make sure to record them for latter use.

blkid > DriveUUID.txt

Now we need to setup our /etc/fstab file. On a default Debian system our /etc/fstab file should look something like this (minus the comments).

Note that because of the length of lines in fstab, it is problematic to display them on a single line. So I will be inserting line feeds between lines to help visually clarify the entries.

UUID=57359928-99e3-4ad8-9f09-91f3b02a2ae0 / 
  ext4 errors=remount-ro 0 1

UUID=39d4ff0f-487b-4760-8f32-d69736b4943c /home
  ext4 defaults          0 2

UUID=7a5610ac-d234-451d-8357-8b095c08d7f6 none
  swap sw                0 0

We want to add lines between the first and second entries (/, and /home) defining our mount points of our two partitions using UUID for sda2 and sdb1.

UUID=39d4ff0f-487b-4760-8f32-d69736b4943c /srv/Disk1
  ext4 defaults     0 2

UUID=c2e59465-86f0-467a-a00d-82b5c9db51ea /srv/Disk2
  ext4 defaults     0 2

Each entry consists of the UUID of the partition, the mount point, the file system type, options, dump variable, and pass variable. The option default is equivalent to “rw,suid,dev,exec,auto,nouser,async”.

Finally, we need to rewrite the /home line. Using the Debian mergerfs man page recommended options, our line will look like this (one line in fstab, but kind of long).

/srv/Disk1:/srv/Disk2 /home fuse.mergerfs
  use_ino,cache.files=off,dropcacheonclose=true,
  allow_other,category.create=mfs
  0  0

In place of UUID we specify the colon separated partition mount points. The logical combined array mount point is /home. The file system is fuse.mergerfs. And the options are mergerfs options (this is where you can also specify policy on how files are saved between the combined drives).

Finaly we will update the initramfs and grub configurations (my research indicate this will depend on actual usage, but should not be needed for a normal home user, but it can’t hurt).

update-initramfs
update-grub

Now if we reboot, the size of our home directory should have increased by the amount of space on the second drive. This can be checked with the df command. You will see both mounted drives (Disk1 and Disk2). You will also, in this case, see an entry “1:2” attached to /home with the combined size of both drives.

Note that since this storage array was setup in user space, it will not be reflected in other normal ways (like lsblk).

Conclusion

In this post we setup mergerfs (a unionfs) as an alternative to standard RAID. The mergerfs application has the advantage of being able to no destructively combine drives of different size and type, while maintaining access to all storage space. While mergerfs is not fault tolerant (like RAID0), it does use existing file systems without reformatting the drives, meaning that if a drive dies it does not affect the remaining drives.

My anecdotal observations of performance tell me RAID0 is defiantly faster. Using  mergerfs seems equivalent of a RAID5 implementation as far as speed goes.

In the next post in this series we will look at the snapraid application, as a way of adding fault tolerance to file systems by maintaining parity information.

Hodgepodge 3xNAS Part 1 Project Overview

Hodgepodge 3xNAS Part 2 Software Choices

Hodgepodge 3xNAS Part 3 Virtual Install

Hodgepodge 3xNAS Part 4 Initial Configuration

Hodgepodge 3xNAS Part 5 Need a GUI?

Hodgepodge 3xNAS Part 6 Add a Storage Drive

Hodgepodge 3xNAS Part 7 SMB/CIFS

Hodgepodge 3xNAS Part 8 Expanded Storage

Hodgepodge 3xNAS Part 9 Making RAID

Hodgepodge 3xNAS Part 10 Cockpit Web GUI RAID 5

Hodgepodge 3xNAS Part 11 Mergerfs

Hodgepodge 3xNAS Part 12 Snapraid

Hodgepodge 3xNAS Part 13 LVM

Hodgepodge 3xNAS Part 14 The Server Hardware

Hodgepodge 3xNAS Part 15 The Server Operating System

Hodgepodge 3xNAS Part 16 Cockpit Install

Hodgepodge 3xNAS Part 17 SAMBA Setup

Hodgepodge 3xNAS Part 18 PLEX vs Kodi

Add New Comment

Your email address will not be published. Required fields are marked *