I doubt that CacheFS will be non-experimental within six months, considering the brand new design and all the previous issues, but we’ll see. It took Btrfs four years to get there and another 5–6 years to become stable enough to be trusted by major distros.
Btrfs is probably stable enough if you avoid RAID 5/6, but may still slow down over time due to metadata fragmentation. Scrubbing and recovery might not always work if metadata corruption occurs during heavy workloads. As for free space requirements, I’ve seen recommendations that you typically need at least 10% free space for stable Copy-on-Write (CoW) operations to prevent nasty filesystem crashes.
But if you ever run into trouble with Btrfs, you’re kind of screwed anyway since even the repair tools are still unreliable (check what they say about the “–rapair” option). According to the Mikrotik docs (Disks > ROSE-storage > Creating Btrfs-RAID check) “It’s extremely important for you to monitor the Btrfs-RAID array’s health. One way you can do this is by using the script below as a working example” but there’s not a single word on how to handle actual failures.
So, a highly relevant question remains: is it even possible to repair a filesystem on a ROSE Data Server (RDS2216) at all?
Bottom Line:
-
As always, have an up-to-date offline backup regardless of the filesystem you’re using, but it’s especially important when using Btrfs! But can you actually create a complete system backup on a ROSE Data Server (RDS2216)?
-
Btrfs is a good choice for your Linux desktop, non-mission-critical operations where snapshotting and compression is useful, and NAS for personal storage. But IMO, it’s not suited for a business-critical enterprise or high-reliability storage, where XFS or ZFS might be a better choice.
-
Besides ZFS, XFS is the most reliable for high-performance server workloads like databases and large files, and EXT4 for general-purpose server use.