Update text fix openshift-labs#1254 openshift-labs#1255

subsystems/container-internals-lab-2-0-part-3/03-analyzing-storage.md

@@ -1,16 +1,9 @@
 In this lab, we are going to focus on how [Container Enginers](https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction/#h.6yt1ex5wfo3l) cache [Repositories](https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction/#h.20722ydfjdj8) on the container host. There is a little known or understood fact - whenever you pull a container image, each layer is cached locally, mapped into a shared filesystem - typically overlay2 or devicemapper. This has a few implications. First, this means that caching a container image locally has historically been a root operation. Second, if you pull an image, or commit a new layer with a password in it, anybody on the system can see it, even if you never push it to a registry server.
 
-Let's start with a quick look at Docker and Podman, to show the difference in storage: 
 
-``docker info 2>&1 | grep -E 'Storage | Root'``{{execute}}
+Now, let's take a look at Podman container engine. It pulls OCI compliant, docker compatible images:
 
-Notice what driver it's using and that it's storing container images in /var/lib/docker:
-
-``tree /var/lib/docker/``{{execute}}
-
-Now, let's take a look at a different container engine called podman. It pulls the same OCI compliant, docker compatible images, but uses a different drivers and storage on the system:
-
-``podman info | grep -A3 Graph``{{execute}}
+``podman info  | grep -A4 graphRoot``{{execute}}
 
 First, you might be asking yourself, [what the heck is d_type?](https://linuxer.pro/2017/03/what-is-d_type-and-why-docker-overlayfs-need-it/). Long story short, it's filesystem option that must be supported for overlay2 to work properly as a backing store for container images and running containers. Now, take a look at the actuall storage being used by Podman: