Thank for your response and interest.
Let me tray to clarify.
I have changed the launcher script to include btrfs as one of the aceppted formats.
In the check_prereqs function I have changed:
if ! $docker_path info 2> /dev/null | egrep -q 'Storage Driver: (btrfs|aufs|zfs|overlay2)$'; then
When I tried first to make a launcher rebuild app, I received a message saying that launcher had been locally modified, and whether I wanted to continue downloading files from origin.
So I had to let it as it was, make the rebuild and change it afterwards to start the app.
But I have tried today to make a rebuild again, and it seems it detects the change but does not complain and the change is preserved.
I don’t know it something has been changed recently in launcher and I could have originally an old launcher that dit not make the reconstruct and now it does (after updating it yesterday).
I am testing it with btrfs and all seems to work OK, you can start and astop application, make the backups, everything works OK for now.
Docker seems to create btrfs subvolumes for the containers storage data when it detects it is running on a btrfs filesystem and uses btrfs storage driver.
So it seems that it makes some optimizations when it clones containers or takes snapshots via docker commands.
But I don’t know if the driver may be faulty in some way (it does not seem an experimental driver in docker, there are no advises about using it in btrfs or I could not find them) and whether it would be better (if possible) to change docker info in order to run it using overlay2 driver as if were running in a standard filesystem.
In theory it would be possible for docker to write its file and make operations on a btrfs filesystem without taking into account its capabilities (as btrfs is not different from other filesystem at the user level, for file i/o).
Any opinions or experiences using btrfs docker storage driver or configuring overlay2 driver to be used when using docker on a btrfs filesystem would be wellcome.