Linux + папка контейнера докеров, подключенная к тому ОС + как узнать реальный ограниченный размер

внутри docker-compose.yml мы настроили следующий объем

image: confluentinc/cp-kafka:latest
volumes:
  - /grid/kafka-data:/var/lib/kafka/data

docker-compose ps
               Name                           Command            State                     Ports
-------------------------------------------------------------------------------------------------------------------
kafka-node_kafka_1            /etc/confluent/docker/run   Up      0.0.0.0:9092->9092/tcp

из моего понимания - путь контейнера докеров kafka - /var/lib/kafka/data установлен на /var/kafka-data , когда ( /var/kafka-data , это путь к ОС Linux)

Около - /var/kafka-data эта папка точки монтирования монтируется на диск ОС - /dev/sdb пока диск sdb размер - 1.8T byte

Итак, подведем итоги:

/var/lib/kafka/data это раздел докеров kafka и /var только 100G

/var/kafka-data это раздел, который смонтирован на SDB-диск (в ОС Linux)

Я хочу задать этот вопрос на всякий случай

Допустим, на разделе докеров kafka - /var/lib/kafka/data , размер /var/../data больше, чем 100G

Означает ли это, что раздел контейнера /var/lib/kafka/data ограничен 100G ??

Или /var в контейнере докеров kafka ограничен внешним томом, который 1.8T byte?

Со стороны контейнера kafka у нас есть:

# df -h /var
Filesystem      Size  Used Avail Use% Mounted on
overlay         101G  7.5G   94G   8% /


df -h  /var/lib/kafka/data/
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/os-rhel_root   101G  7.5G   94G   8% /var/lib/kafka/data

Находясь вне контейнера - на реальной ОС Linux у нас есть

df -h

Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/os-rhel_root  50G  5.3G   45G   11% /
devtmpfs                  12G     0  12G    0% /dev
tmpfs                     12G   156K  12G   1% /dev/shm
/dev/sdb                  1.8T   77M  1.8T   1% /grid/kafka-data
/dev/sda1                 492M  158M  335M  32% /boot
/dev/mapper/os-rhel_var   106G   11G   96G  10% /var
tmpfs                      26G     0   26G   0% /run/user/1005
tmpfs                      26G   20K   26G   1% /run/user/0
overlay                   101G  7.5G   94G   8% /var/lib/docker/overlay2/8411835673dfedd5986093eb771582dac7317d99f431b832f3baea8ea1aa3e4d/merged
shm                        64M     0   64M   0% /var/lib/docker/containers/629aefd21b6042ebfbf1a0a08a882b2f1865137edfb4b2b02f5c9a1681d895e4/mounts/shm
overlay                   101G  7.5G   94G   8% /var/lib/docker/overlay2/b4677bed14050337580958bc903bbb733d9464ca8bfc46124c3c506dc064867d/merged
.
.
.

Шаги для решения этого вопроса были следующими (обсуждались в чате):

Проверка вывода docker inspect для рассматриваемого контейнера. Он дает много результатов, ключевыми частями, которые следует учитывать, являются Binds и Mounts разделы.
Увидев крепления на месте, чтобы избежать несовпадающих подключений, скрывающих фактические назначения данных, мы делаем проверку, чтобы увидеть, что файлы, созданные в контейнере, видны на хосте. Простая команда внутри контейнера вроде date > /var/lib/kafka/data/test.txt достаточно для этой цели и становится видимым под /grid/kafka-data на хосте.
Поскольку есть небольшая вероятность, что докер каким-то образом смонтировал что-то над существующим монтированием тома на хосте (я никогда не видел этого, но когда это важно, лучше проверить дважды), мы создаем тестовый файл размером 400 МБ в контейнере следующим образом : dd if=/dev/zero of=/var/lib/kafka/data/test.bin count=400 bs=1M
Проверка df вывод на хосте показывает увеличение используемого размера на ~ 400 МБ для объема, на который отправляются данные. Поскольку это отображается для «правильной» точки монтирования (с размером 1.8T), мы уверены, что фактический предел для записи файлов - 1.8T.
После этого тестовые файлы test.bin и test.txt удаляются, чтобы не загромождать систему ненужными файлами и не использовать пространство.