Hi all!

 

I’m trying to optimize my current server and need some advice on how to use everything.

 

My current config:

1x Parity Disk (18TB)
5x Array Disks (18, 18, 14, 14, 18 - xfs)

2x 1TB NVME (pooled, btrfs)
2x 2TB NVME (pooled, btrfs)

 

I primarily use my server for the following:

• FileRun: self-hosted cloud storage. Multiple users uploading/downloading files regularly
• BackBlaze: Offsite backup of all files
• qbittorrent + Plex: Media server (typically remuxes with no transcoding)
• mylar3 + Kavita: Comic book server
• homebridge: all things smart home

 

Right now, I use the 1TB NVME pool for my AppData and as a cache for any/all new files across all of the above applications with a Mover scheduled based on % used.

 

I use the full Array (82TB) as one storage for all of the above files.

 

I currently don’t use the 2TB NVME pool for anything.

 

I tried having my Array drives spin down automatically when not in use, but it broke FileRun as when I or someone else would access it, the files that are on the spun down drives would disappear. I had hoped the drive would just spin back up when trying to access a file on it. As a result, I don’t have any drives spinning down anymore (although I did consider trying to assign FileRun storage to a specific Disk rather than the entire array, but that doesn’t really future-proof me).

 

I’m also wondering what I should store on the 2TB pool vs the 1TB pool. Should I move AppData to the 2TB and strictly use the 1TB as a cache? Should I put my docker image on the 2TB? How about keeping everything homebridge related on there? Will that speed homebridge up?

 

Basically, I’m hoping someone can help provide guidance on the best way to optimize my setup. I understand it’s subjective, but I’m a bit in the dark right now, so any advice helps!

since your on beta while it be a big migration with the # of disk, i would ditach the array and go zfs.

 

General Recommendations:

 

Parity Drive and Array Usage:

Keep your 18TB parity disk and array setup as is for now, unless you're ready to transition to ZFS (more on that below). The array provides excellent storage flexibility for media and backups.

 

Cache Pool (1TB NVMe):

Continue using the 1TB NVMe pool for AppData, Docker/VM images, and write cache for the array. These tasks benefit significantly from high-speed NVMe storage.

 

2TB NVMe Pool:

Use the 2TB NVMe pool for applications with high I/O requirements that don’t need redundancy, such as:

Storing temporary/transcoding files for Plex.

Caching high-activity data from FileRun.

Hosting Homebridge data if it benefits from faster storage (although Homebridge typically doesn’t require much I/O speed).

 

Drive Spindown:

For FileRun issues, consider assigning a specific disk for its storage if performance isn't acceptable with spindown. Alternatively:

Use the 2TB NVMe pool for high-access files and sync it periodically with the array.

Check if FileRun has settings to retry access or delay file requests, so the spun-down drives have time to spin back up.

 

Optimized Use of the 2TB NVMe Pool:

 

AppData Move:

Moving AppData to the 2TB pool would free space on the 1TB pool, leaving it dedicated for caching and transient data. This makes sense if the 2TB pool is not highly utilized.

 

FileRun Storage Cache:

Store commonly accessed or new files from FileRun here, syncing periodically to the array.

 

Plex Transcoding:

Use the 2TB pool for temporary transcoding files if you plan to start transcoding.

 

Docker and VM Images:

Moving Docker images and any VMs (if any) to the 2TB pool can improve responsiveness.

 

Transitioning to ZFS:

I'd recommend moving to ZFS. If you're ready to shift:

ZFS allows for faster access, better data integrity, and scaling over time.

Replace your current array with ZFS pools:

Pool the 18TB drives into a ZFS RAID-Z2 or RAID-Z3 configuration for redundancy.

Pool your NVMe drives into ZFS mirrors for high-speed caching and metadata operations.

*Note: ZFS requires careful planning, as expanding the pool later is not as flexible as Unraid's array system.

 

Otherwise, Suggested Config Updates:

Cache Setup:

1TB NVMe Pool: Cache for high-write applications.

2TB NVMe Pool: AppData, Docker images, and temporary/transient data for apps.

Plex Optimization:

Directly store metadata-heavy or transcoded media on the 2TB pool.

Backup Strategy:

Continue syncing critical files to Backblaze.

Consider moving your FileRun data to the 2TB NVMe as a tiered storage approach if you can back it up frequently.

Review:

 

 

In the end its what you want it to do and how you wnat to interact with it.

Thank you so much, @bmartino1, this is exactly the guidance I was looking for! If I hold off on moving to zfs for now, what negatives aside from speed come with sticking with xfs + btrfs?

the original array and use of random weird disk sizes. ZFS is better is you start with 3 of the same sizes.

once a poll is made say 3x 2 TB in a raidz1 you can pull a disk and "resliver" faster easier and not lose any data.

If you do that to all 3 disk in 2TB and replace with 3x 4TB you gain a easier way to upgrade space with out any data loss.

Parity didn't work in the array that i wanted it to and how I read it in the unraid docs.
My original understanding was d1, d2 and parity were all combined.

So d1 500 GB, d2 1TB and parity 2TB to hold both disk. Parity is only for D1.
The array lever gas mdadm and software raid. See in docs:
https://docs.unraid.net/unraid-os/manual/storage-management/

 

When zfs was being implemented for ME it was a Welcomed jump skip and hop to due to issues with recovery and ease of management with disk for data retention and protection.
With beta7 due to the disk limit # and with the abilty to not have the array I was able to reclaim some disk to use and can make a new pool.

xfs / btrfs /zfs are all file systems, you would need to do research into file OS systems types and difference. Before zfs my got Linux format was xfs for many reasons...
 

 

Summary

The main negatives of sticking with XFS + BTRFS are:

Missing out on ZFS’s advanced features (deduplication, snapshots, checksumming, RAID-Z).

Increased complexity in managing multiple filesystems.

Potential scalability and integrity limitations compared to ZFS.

If your current setup works well for your use case and you don't need the advanced features of ZFS yet, there's no immediate need to switch. However, consider whether future scalability or advanced features like snapshots and data integrity will become important, as that might justify moving to ZFS sooner.

 

Sticking with XFS and BTRFS in an Unraid setup, while holding off on ZFS, has both advantages and drawbacks. Here's an analysis of the negatives (aside from speed) and considerations:

 

1. Lack of Native Deduplication

What it means: ZFS offers native deduplication, which reduces storage needs for duplicate data. This can be beneficial for environments with repetitive files, such as virtual machine images or backups.

Impact: With XFS and BTRFS, you'll consume more storage for duplicate files unless you rely on external deduplication tools or workflows.

 

2. Snapshots and Backup Features

What it means: BTRFS supports snapshots natively, but XFS does not. ZFS excels in this area by providing consistent, efficient, and reliable snapshots.

Impact: If your array primarily uses XFS, you'll miss out on native snapshot capabilities, which are useful for quick rollbacks, backups, and testing environments.

 

3. RAID-Like Features (Beyond Unraid’s Parity)

What it means: ZFS integrates RAID functionality (e.g., RAID-Z) with data integrity and redundancy features. While Unraid uses parity for redundancy, ZFS offers more robust and flexible RAID-like setups.

Impact: Sticking with XFS and BTRFS means relying on Unraid’s parity system alone, which may not be as versatile as ZFS’s built-in RAID features for specific workloads.

 

4. Data Integrity Features

What it means: ZFS is renowned for end-to-end checksumming and data self-healing, ensuring data integrity and reducing the risk of silent data corruption.

Impact:

XFS: Lacks native checksumming for metadata and data. It's reliable but doesn't guard against bitrot.

BTRFS: Offers checksumming but may not be as mature or stable as ZFS for large-scale, write-heavy environments.

 

5. Scalability and Efficiency

What it means: ZFS is designed to scale efficiently with large pools of storage, making it ideal for arrays with high-capacity drives or diverse workloads.

Impact: XFS and BTRFS may struggle with scalability in some cases:

XFS handles large volumes well but lacks advanced pool-level optimizations.

BTRFS can face stability issues with many drives or mixed workloads.

 

6. Mixed Filesystem Management

What it means: In Unraid, using both XFS and BTRFS can lead to complexity in managing multiple filesystems, especially with different feature sets (e.g., snapshots on some drives, none on others).

Impact: This could complicate workflows, backups, or recovery in multi-filesystem setups.

 

7. Ecosystem Features

What it means: ZFS has a mature ecosystem with tools for monitoring, backup, and recovery, such as zfs send/receive for efficient replication.

Impact: XFS and BTRFS don’t offer as rich an ecosystem for advanced storage management tasks.

 

8. Future Migration Complexity

What it means: Migrating from XFS or BTRFS to ZFS later could involve downtime, complexity, and potential data movement.

Impact: If you anticipate eventually switching to ZFS, starting with ZFS now might save you from a cumbersome transition later.

When to Stick with XFS + BTRFS

Sticking with XFS and BTRFS is a valid choice if:

You’re content with Unraid’s parity-based redundancy and don’t need advanced RAID setups.

Your workload doesn’t involve duplicate files or heavy snapshot usage.

You prioritize simplicity and don’t want to deal with ZFS’s steeper learning curve and memory requirements (ZFS is RAM-intensive).