[gcr]

Have you tried btrfs? It also has support for super-cheap copy-on-write operations which should make container images and the like a snap.

Not sure if your container tool supports btrfs snapshots of course, but it's conceptually simple, right?

[cmurf]

I think the main issue here is Btrfs is still developing. Its kernel doc file still says it's for benchmarking and review. [1] CoreOS devs decided to switch from Btrfs to overlay(fs) about 17 months ago. That's a long, long time in Btrfs development "years" that's how much development happens on Btrfs. But I can't say if CoreOS would, had today's Btrfs been what they were using in 2014, would have changed their decision.

RH/Fedora are very dm/LVM thinp snapshots with XFS centric for backing their containers. I think what you're seeing is distros are doing something different with their container backing approach in order to differentiate from other distros. Maybe it's a stab in the dark or spaghetti on the wall approach but in the end all of these storage backends are going to mature a lot in the interim, so ultimately it'll be good for everyone.

[1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st...

[Annatar]

Btrfs has been in beta for how many years now?

ZFS is protecting data in enterprise production environments since 2006 (Solaris 10 update 2).

[krondor]

Btrfs is not beta, see the discussion re: maturity below.

ZFS is an excellent filesystem, btrfs is an excellent filesystem. There is room for both excellent options for users.

[aorth]

For development containers, systemd-nspawn has had support for btrfs snapshots since 2014 or 2015. Simple to get going if you're on a Linux box with systemd, no other daemons or tools required.

[takeda]

Isn't this issue inherent to all COW systems (ZFS, WAFL, btrfs)?