Revert to category.create=mfs mergerfs option

Why mfs wins for my use-case:

1. Even disk fill rate - each new file lands on whichever drive has the most free space, so all 4 drives fill roughly in parallel. This matters for SnapRAID: parity sync time is bounded by the fullest data disk, so imbalance = wasted time.
2. Concurrent streaming throughput - files naturally spread across physical disks, so multiple Jellyfin streams read from different spindles simultaneously instead of all hammering one drive.
3. No path-locality trap - the epmfs problem is that once /mnt/storage/Videos/ exists on data1, all new files under Videos/ go to data1 until it's 100% full. With mfs, the second movie might go to data3, the third to data2, etc.

One thing one might worry about: "won't scattering files from the same directory across drives hurt something?" No. mergerfs presents the union transparently - 'ls /mnt/storage/Videos/' shows all movies regardless of which underlying drive they're on. NFS clients and Jellyfin never know the difference.

Hard links are not a concern in my setup because the *arr suite's working directories (downloads, library hardlinks) all live on the Ceph RWO data volume, not on the NFS share. If that ever changes, mfs can break cross-directory hardlinks (source and target must be on the same physical drive), but that's a bridge to cross if/when we restructure.

Beyond the media, with general file storage (Nextcloud, Paperless, documents, photos), the workload shifts toward many small files and frequent writes. Under epmfs, a user's entire Nextcloud data directory lands on one drive because the path exists there first. One active user could fill a single 18TB drive while the other three sit empty. With mfs, those files spread across all 4 drives naturally.

The one concern people raise with mfs for file storage is directory listing performance - if files in /mnt/storage/Documents/ are scattered across 4 drives, mergerfs has to query all 4 to assemble the listing. On 4 drives this is negligible. It becomes a real consideration at 15-20+ drives, not at 4. So again, "future Sergio" problem...

mfs stays optimal. Mixed workloads (streaming + file storage) actually strengthen the case for it, because the variety of write patterns makes uneven fill from epmfs even worse.

Author: serpro69

metal/roles/storage/tasks/mergerfs.yml

@@ -7,7 +7,7 @@
 - name: Build mergerfs fstab options
   set_fact:
     mergerfs_options: >-
-      defaults,allow_other,use_ino,cache.files=off,category.create=epmfs,{{
+      defaults,allow_other,use_ino,cache.files=off,category.create=mfs,{{
         mergerfs_systemd_requires | map('regex_replace', '^', 'x-systemd.requires=') | join(',')
       }}