QA (public) » openQA Project (public) » openQA Tests (public) » Containers and images

docker already make use of btrfs storage in our sle image

❯ docker info --format '{{.Driver}}'
btrfs

That means that for each docker image that we run, docker creates a subvolume under /var/lib/docker/btrfs/subvolumes

# ls -lt /var/lib/docker/btrfs/subvolumes/ |head
total 0
drwxr-xr-x 1 root root 148 Oct 23 08:06 4e7f80fafabb369f538bad5411e0599181156bb3c8fb885ca85403a3fc905aec
drwxr-xr-x 1 root root 148 Oct 23 08:06 4e7f80fafabb369f538bad5411e0599181156bb3c8fb885ca85403a3fc905aec-init
# ls /var/lib/docker/btrfs/subvolumes/4e7f80fafabb369f538bad5411e0599181156bb3c8fb885ca85403a3fc905aec/
.dockerenv  dev  etc  proc  sys  tmp  root  run  sbin  bin  lib64  lib  srv  usr  var  selinux  home  mnt  opt

/var/lib/docker/btrfs/ is mounted and when docker service is fired up and we can issue and control it via btrfs

# btrfs fi df /var/lib/docker/btrfs 
Data, single: total=140.01GiB, used=130.66GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=3.00GiB, used=2.05GiB
GlobalReserve, single: total=121.45MiB, used=0.00B

Suggestion for test scenario¶

Run a container and fill up its disk space.
When this happens we should not be able to run another container because the btrfs volume (/var/lib/docker/btrfs) is obviously full.
Use btrfs to extend and balance the data across the disks and try to pull another image

Other findings¶

• docker logs prints stdout of the container's bash
• lsblk displays the following different output between root and regular user(when docker service is running) ❯ lsblk NAME                                         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT sda                                            8:0    0   1.8T  0 disk   ├─sda1                                         8:1    0   128M  0 part   ├─sda2                                         8:2    0   500M  0 part  /boot/efi ├─sda3                                         8:3    0   1.8T  0 part   │ └─cr_ata-ST2000LM007-1R8174_WDZDN368-part3 254:1    0   1.8T  0 crypt  │   ├─system-root                            254:2    0 620.4G  0 lvm   /var/lib/docker/btrfs │   ├─system-swap                            254:3    0  31.3G  0 lvm   [SWAP] │   └─system-home                            254:4    0   1.2T  0 lvm   /home └─sda4                                         8:4    0    37G  0 part     └─cr_ata-ST2000LM007-1R8174_WDZDN368-part4 254:0    0    37G  0 crypt      └─system-root                            254:2    0 620.4G  0 lvm   /var/lib/docker/btrfs # lsblk NAME                                         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT sda                                            8:0    0   1.8T  0 disk   ├─sda1                                         8:1    0   128M  0 part   ├─sda2                                         8:2    0   500M  0 part  /boot/efi ├─sda3                                         8:3    0   1.8T  0 part   │ └─cr_ata-ST2000LM007-1R8174_WDZDN368-part3 254:1    0   1.8T  0 crypt  │   ├─system-root                            254:2    0 620.4G  0 lvm   / │   ├─system-swap                            254:3    0  31.3G  0 lvm   [SWAP] │   └─system-home                            254:4    0   1.2T  0 lvm   /home └─sda4                                         8:4    0    37G  0 part     └─cr_ata-ST2000LM007-1R8174_WDZDN368-part4 254:0    0    37G  0 crypt      └─system-root                            254:2    0 620.4G  0 lvm   / i found that interesting but i guess is expected.

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/11307

Good job!
Will you add it to https://gitlab.suse.de/qac/qac-openqa-yaml/-/blob/master/sle15/containers.yaml ?

The btrfs module is scheduled only for containers_sle_image_on_sle_host, so it needs to have NUMDISKs=2. The rest should remain as it was before.
https://gitlab.suse.de/qac/qac-openqa-yaml/-/merge_requests/71

I am unscheduling the validate_btrfs for arm, s390x and ppc as it will not work there for now.
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/11494
and i am working on the follow up to reenable it.

I created https://progress.opensuse.org/issues/80462 for the rest of the archs

ybonatakis wrote:

I created https://progress.opensuse.org/issues/80462 for the rest of the archs

Ok, thanks.