phillxnet
commented
2 months ago From the upstream docker link (btrfs-driver) above we have, in subsection: https://docs.docker.com/storage/storagedriver/btrfs-driver/#image-and-container-layers-on-disk
Only the base layer of an image is stored as a true subvolume. All the other layers are stored as snapshots, which only contain the differences introduced in that layer.
Or the possibly better overview of:
Docker's btrfs storage driver stores every image layer and container in its own Btrfs subvolume or snapshot. The base layer of an image is stored as a subvolume whereas child image layers and containers are stored as snapshots.
We should also add, by way of this issues resolution, a note on how we configure docker's btrfs driver to use the Rock-ons-root designated Share (btrfs subvolume). I.e. a mention of our config override for docker.
Thanks to knucklehead101, mrseth1, glenngould, MvL, and anborn in the following forum threads for highlighting this issue. Since docker (Rockons) use snapshots to manage image layers their deletion will break installed Rock-ons. An explanation of their purpose and use will help to clarify their appearance in the Rock-ons-root share.
This explanation could be placed in the following doc section: http://rockstor.com/docs/docker-based-rock-ons/overview.html#rockons-root
Referenced forum threads: https://forum.rockstor.com/t/rock-ons-snapshot-removal/637 https://forum.rockstor.com/t/deleting-snapshots-breaks-rock-ons/2431 https://forum.rockstor.com/t/what-is-the-logic-of-rockstor-if-there-are-no-scheduled-snapshots/2928 https://forum.rockstor.com/t/solved-headphones-rock-on/3034 https://forum.rockstor.com/t/some-rock-ons-not-reachable-after-creating-new-rock-on-share-and-new-installation-of-rock-ons/8029
Possible background docker reference: https://docs.docker.com/engine/userguide/storagedriver/btrfs-driver/