Listing images takes much time

[varuzam]

/kind bug

Ubuntu 20.04.3 LTS
Since I upgraded podman upto 3.3.1-1 the comand 'sudo podman images' became taking too much time

# time sudo podman images
....
real	0m23,583s
user	0m39,768s
sys	0m1,084s

Steps to reproduce the issue:

1. Install podman 3.3.1-1

2. RUn - time sudo podman images

Describe the results you expected:
be instant as 'docker images'

Output of podman version:
Version: 3.3.1
API Version: 3.3.1
Go Version: go1.16.6
Built: Thu Jan 1 03:00:00 1970
OS/Arch: linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.22.3
  cgroupControllers:
  - cpuset
  - cpu
  - cpuacct
  - blkio
  - memory
  - devices
  - freezer
  - net_cls
  - perf_event
  - net_prio
  - hugetlb
  - pids
  - rdma
  cgroupManager: systemd
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 4
  distribution:
    distribution: ubuntu
    version: "20.04"
  eventLogger: journald
  hostname: xps
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.4.0-88-generic
  linkmode: dynamic
  memFree: 2045075456
  memTotal: 8062832640
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.20.1.5-925d-dirty
      commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: true
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.8
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 0
  swapTotal: 0
  uptime: 19h 45m 58.15s (Approximately 0.79 days)
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 8
    paused: 0
    running: 0
    stopped: 8
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 259
  runRoot: /var/run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.3.1
  Built: 0
  BuiltTime: Thu Jan  1 03:00:00 1970
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.3.1

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

podman/unknown,now 100:3.3.1-1 amd64 [installed]

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
No. the guide does not have description for the problem

[rhatdan]

@vrothberg ptal

[vrothberg]

Can you try measuring the time of podman image --all? My theory is that the performance should not change with --all.

[vrothberg]

Here is a fix: containers/common#811

[vrothberg]

Closing, will be implicitly fixed with the next vendor of c/common.

[vrothberg]

@mheon are you cool if I create a backport for this fix to v3.4? Users hit in F35 and since we don't ship 4.0 there, I'd like to give them something.

[mheon]

Hm. Do we want to do a 3.4.5 for F35? I’m not opposed but it would have to be hand selected backports.

…

On Mon, Mar 7, 2022 at 11:27 Valentin Rothberg ***@***.***> wrote: @mheon <https://github.com/mheon> are you cool if I create a backport for this fix to v3.4? Users hit in F35 and since we don't ship 4.0 there, I'd like to give them something. — Reply to this email directly, view it on GitHub <#11997 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCG3H2RVIFDULE2G4ADU6YVAXANCNFSM5GDJXTEQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[baude]

yeah @mheon thats the general idea ...