automatically use btrfs driver if on btrfs

[cmurf]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Fedora 32, podman-1.9.3-1.fc32.x86_64
/etc/containers/storage.conf contains
driver = "overlay"

To use the btrfs driver, it's necessary to modify that, or create ~/.config/containers/storage.conf with the driver set to btrfs. Feature request is to use the btrfs driver if the file system is btrfs; and fallback to overlayfs otherwise.

Describe the results you received:

podman uses overlayfs driver by default when ~/ is on btrfs

Describe the results you expected:

podman uses btrfs driver by default when ~/ is on btrfs

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

$ podman version
Version:            1.9.3
RemoteAPI Version:  1
Go Version:         go1.14.2
OS/Arch:            linux/amd64
$ 

Package info (e.g. output of rpm -q podman or apt list podman):

podman-1.9.3-1.fc32.x86_64

[mheon]

@nalind @rhatdan How comfortable are we with using the btrfs driver?

[Conan-Kudo]

As a long-time btrfs user, I'd love to see this happen. I've been using Podman (and previously Docker) with Btrfs for several years now with no issues. I was introduced to it by @vrothberg way back in 2017 and it's worked solidly for me ever since. It's annoying having to manually configure it, and I'd much rather it do the right thing automatically.

[cmurf]

Posted a question about overlayfs+btrfs to the btrfs list a few years ago, and this was one of the replies. That is a lot of containers. They were using Docker in that case, but the btrfs driver podman uses is the same driver, right?
https://lore.kernel.org/linux-btrfs/CAMp4zn8YUdVShFibUKCXtwZTZpicCbmm7zSYMn7+K5CNt-cxGA@mail.gmail.com/

[vrothberg]

@Conan-Kudo, thanks, glad that it's working for you.

They were using Docker in that case, but the btrfs driver podman uses is the same driver, right?

Initially the code has been forked from Docker but the code may have diverged in the meantime.

It would be good to have @giuseppe 's eyes on the request as well. Defaulting to overlay has the great benefit of easily running rootless. btrfs doesn't support rootless.

[giuseppe]

I agree with @vrothberg. I think we should still default to overlay for rootless.

But should be fine to do it for root?

[vrothberg]

SGTM 👍

[Conan-Kudo]

Why do you think Btrfs wouldn't support rootless? You can create and delete subvolumes/snapshots without root privileges if the base location is owned by the user...

[rhatdan]

Podman is going to read the driver listed in storage.conf, If this states BTRFS then it will use it. I don't think Podman should change it's default, and should support whatever the default is set by the distribution.

I have no idea how well BTRFS storage back end works. I am sure some people use it, but have not seen much bug reports/issues with it.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[cmurf]

Fedora is working on Btrfs by default for Fedora 33. There's no plan to change the podman driver from the current default. This still means new default installs get the added benefit of overlayfs+reflinks.

The difficulty with just changing the driver in storage.conf to btrfs, is that folks who do custom installs opting for a different file system, wouldn't have working podman out of the box. I don't think that's a good option. So ideally there'd be a conditioning default or fallback mechanism.

Something fairytale magical, would be a way of estimating the workloads' page cache share-ability. If it's above some threshold, use overlayfs. If not, use btrfs snapshots.

[bam80]

So how one could decide what FS driver is better for him?

[cmurf]

Testing. Some of it could be synthetic benchmarks as described in this comment in #6862. But ultimately benchmarks are only as good as they mimic the actual workload in an actual configuration.

[PavelSosin-320]

There is the packaging problem too: Fedora 34 Desktop repositories contain podman out-of-the-box and conflicting storage.conf. Podman detects the native OS btrfs as backing FS and uses the default overlay storage driver. And it is not the only issue: attempts to create bind volume for source directory in the home subvolume seem doesn't work because source FS and storage driver FS are managed by different types of "drivers". But the "storage" and the user data at HOME are located at the same btrfs subvolume. What is the benefit?