Skip to content

Quiz: mergerfs

← Back to quiz index

9 questions

L1 (2 questions)

1. What are the three branch modes in mergerfs?

Show answer RW (Read-Write) -- default, eligible for all operations. RO (Read-Only) -- excluded from create and action policies. NC (No-Create) -- excluded from create policies but allows modifications and deletions. NC is used to gracefully drain a drive before removal.

2. Why is dropcacheonclose=true important for Plex/Jellyfin on mergerfs?

Show answer Without it, streaming large media files (20-50 GB) fills the Linux page cache with data that will never be re-read. This evicts useful cached data and causes system sluggishness. dropcacheonclose calls posix_fadvise(DONTNEED) on file close, telling the kernel to release the page cache for that file.

L2 (7 questions)

1. What is the default create policy in mergerfs and how does it distribute files?

Show answer pfrd (Probabilistic Free-space Random Distribution). It selects a branch randomly with probability proportional to available free space. A branch with 2 TB free is twice as likely to receive a file as one with 1 TB free. This naturally balances data across drives over time. *Common mistake:* Many confuse pfrd with mfs (most free space). pfrd is probabilistic/random; mfs always picks the single branch with the most free space deterministically.

2. What does moveonenospc do, and what is its critical limitation?

Show answer When a write fails with ENOSPC on a branch, mergerfs moves the file to another branch and retries the write. Critical limitation: it only affects writes to already-open files, NOT creates. If the create policy selects a full branch, the create fails and moveonenospc does not intervene. *Common mistake:* A common mistake is assuming moveonenospc fully protects against full drives. It does not -- minfreespace is the create-time protection; moveonenospc is only a write-time safety net.

3. Why must SnapRAID parity drives NEVER be included in the mergerfs pool?

Show answer mergerfs will write user data to any branch in the pool. If the parity drive is a branch, user files overwrite parity data, silently destroying SnapRAID protection. Fix: use naming conventions like /mnt/disk* for data and /mnt/parity* for parity, and only glob /mnt/disk* in the mergerfs mount.

4. How do you add a new drive to a running mergerfs pool without unmounting?

Show answer Use xattr on the .mergerfs pseudo-file: setfattr -n user.mergerfs.srcmounts -v '+>/mnt/disk5' /storage/.mergerfs. The +> prefix appends a new branch. Changes are NOT persisted -- update /etc/fstab to make them survive reboot. *Common mistake:* Some try to remount or restart the mergerfs daemon. The xattr interface allows zero-downtime branch management without interrupting active services.

5. What is EXDEV error 18 and how does mergerfs handle cross-branch renames?

Show answer EXDEV means "Invalid cross-device link" -- returned when rename() crosses filesystem boundaries. Since each mergerfs branch is a separate filesystem, cross-branch renames trigger EXDEV. The rename-exdev option can be set to passthrough (default, returns error), rel-symlink, or abs-symlink to create symlinks as workarounds. *Common mistake:* Some applications check file type after rename and reject symlinks, so enabling symlink modes requires testing with your specific applications.

6. What is the difference between epmfs and mspmfs create policies?

Show answer Both select the branch with the most free space among branches with an existing path. epmfs only considers branches where the exact parent directory exists -- if no branch has it, the create fails. mspmfs falls back to the parent directory, then grandparent, etc. mspmfs is more resilient but less strict about path preservation. *Common mistake:* The msp* prefix stands for "Most Specific Path" -- it tries the exact path first, then walks up the directory tree. The ep* prefix ("Existing Path") only tries the exact path.

7. After a drive failure in a mergerfs + SnapRAID setup, what must you do BEFORE running snapraid sync?

Show answer Run snapraid fix -d dN to restore data from parity to the replacement drive. If you run snapraid sync before fix, SnapRAID recalculates parity without the missing data, permanently destroying the parity information needed for recovery. The correct order is always fix first, verify, then sync.