Matty wrote: > I think it depends on who you ask. Facebook and Netflix are using it > extensively in production: > > https://www.linux.com/news/learn/intro-to-linux/how-facebook-uses-linux-and-btrfs-interview-chris-mason > > Though they have the in-house kernel engineering resources to > troubleshoot problems. When I see quotes like this [1] on the > product's WIKI: > > "The parity RAID code has multiple serious data-loss bugs in it. It > should not be used for anything other than testing purposes." It´s RAID1, not 5/6. It´s only 2 SSDs. I do not /need/ to put the mail spool there, but it makes sense because the data that benefits from the low latency fills about only 5% of them, and the spool is mostly read, resulting in not so much wear of the SSDs. I can probably do a test with that data on the hardware RAID, and if performance is comparable, I rather put it there than on the SSDs. > I'm reluctant to store anything of value on it. Have you considered > using ZoL? I've been using it for quite some time and haven't lost > data. Yes, and I´m moving away from ZFS because it remains alien, and the performance is poor. ZFS wasn´t designed with performance in mind, and that shows. It is amazing that SSDs with Linux are still so pointless and that there is no file system available actually suited for production use providing features ZFS and btrfs are valued for. It´s even frustrating that disk access still continues to defeat performance so much. Maybe it´s crazy wanting to put data onto SSDs with btrfs because the hardware RAID is also RAID1, for performance and better resistance against failures than RAID5 has. I guess I really shouldn´t do that. Now I´m looking forward to the test with the hardware RAID. A RAID1 of 8 disks may yield even better performance than 2 SSDs in software RAID1 with btrfs.