On Thu, Aug 3, 2017 at 1:44 AM, Chris Mason <[email protected]> wrote: > > On 08/02/2017 04:38 AM, Brendan Hide wrote: >> >> The title seems alarmist to me - and I suspect it is going to be >> misconstrued. :-/ > > > Supporting any filesystem is a huge amount of work. I don't have a problem > with Redhat or any distro picking and choosing the projects they want to > support. >
It'd help a lot of people if things like https://btrfs.wiki.kernel.org/index.php/Status is kept up-to-date and 'promoted', so at least users are more informed about what they're getting into and can choose which features (stable/still in dev/likely to destroy your data) that they want to use. For example, https://btrfs.wiki.kernel.org/index.php/Status says compression is 'mostly OK' ('auto-repair and compression may crash' looks pretty scary, as from newcomers-perspective it might be interpretted as 'potential data loss'), while https://en.opensuse.org/SDB:BTRFS#Compressed_btrfs_filesystems says they support compression on newer opensuse versions. > > At least inside of FB, our own internal btrfs usage is continuing to grow. > Btrfs is becoming a big part of how we ship containers and other workloads > where snapshots improve performance. > Ubuntu also support btrfs as part their container implementation (lxd), and (reading lxd mailing list) some people use lxd+btrfs on their production environment. IIRC the last problem posted on lxd list about btrfs was about how 'btrfs send/receive (used by lxd copy) is slower than rsync for full/initial copy'. -- Fajar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
