Docker продолжает говорить «на устройстве не осталось места», когда на устройстве есть место - PullRequest
0 голосов
/ 21 апреля 2020

У меня есть два тома, подключенных к моему экземпляру ec2, один - / dev / sda1, который является root томом, и это 8 ГБ, тогда как есть другой том / dev / sdb, который составляет 500 ГБ. Я могу видеть оба тома, когда я запускаю sudo fdisk -l. У меня есть django сервер, работающий в экземпляре docker, работающем на этом экземпляре ec2, и когда я загружаю некоторые данные на сервер docker «Ошибка ввода-вывода, на устройстве не осталось места». Как я могу решить эту проблему?

РЕДАКТИРОВАТЬ

Ниже мой docker -compose.yml

# Copyright (C) 2018-2020 Intel Corporation
#
# SPDX-License-Identifier: MIT
#
version: "2.3"

services:
  cvat_db:
    container_name: cvat_db
    image: postgres:10-alpine
    networks:
      default:
        aliases:
          - db
    restart: always
    environment:
      POSTGRES_USER: root
      POSTGRES_DB: cvat
      POSTGRES_HOST_AUTH_METHOD: trust
    volumes:
      - cvat_db:/var/lib/postgresql/data

  cvat_redis:
    container_name: cvat_redis
    image: redis:4.0-alpine
    networks:
      default:
        aliases:
          - redis
    restart: always

  cvat:
    container_name: cvat
    image: cvat
    restart: always
    depends_on:
      - cvat_redis
      - cvat_db
    build:
      context: .
      args:
        http_proxy:
        https_proxy:
        no_proxy:
        socks_proxy:
        TF_ANNOTATION: "no"
        AUTO_SEGMENTATION: "no"
        USER: "django"
        DJANGO_CONFIGURATION: "production"
        TZ: "Etc/UTC"
        OPENVINO_TOOLKIT: "no"
    environment:
      DJANGO_MODWSGI_EXTRA_ARGS: ""
      ALLOWED_HOSTS: '*'
    volumes:
      - cvat_data:/home/django/data
      - cvat_keys:/home/django/keys
      - cvat_logs:/home/django/logs
      - cvat_models:/home/django/models

  cvat_ui:
    container_name: cvat_ui
    restart: always
    build:
      context: .
      args:
        http_proxy:
        https_proxy:
        no_proxy:
        socks_proxy:
      dockerfile: Dockerfile.ui

    networks:
      default:
        aliases:
          - ui
    depends_on:
      - cvat

  cvat_proxy:
    container_name: cvat_proxy
    image: nginx:stable-alpine
    restart: always
    depends_on:
      - cvat
      - cvat_ui
    environment:
      CVAT_HOST: ""
      ALLOWED_HOSTS: "*"
    ports:
      - "8080:80"
    volumes:
      - ./cvat_proxy/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./cvat_proxy/conf.d/cvat.conf.template:/etc/nginx/conf.d/cvat.conf.template:ro
    command: /bin/sh -c "envsubst '$$CVAT_HOST' < /etc/nginx/conf.d/cvat.conf.template > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"

volumes:
  cvat_db:
  cvat_data:
  cvat_keys:
  cvat_logs:
  cvat_models:

Ответы [ 2 ]

1 голос
/ 21 апреля 2020

Есть несколько возможностей. Прочтите эту статью и посмотрите, поможет ли это: https://www.maketecheasier.com/fix-linux-no-space-left-on-device-error/

В нем говорится что-то вроде

Удаленный файл зарезервирован процессом

Иногда файл удаляется, но процесс все еще использует его. Linux не освободит хранилище, связанное с файлом, пока процесс еще запущен. Вам просто нужно найти процесс и перезапустить его.

Недостаточно инодов

В файловых системах есть набор метаданных, называемых «инодами». Inodes отслеживает информацию о файлах. Многие файловые системы имеют фиксированное количество inode, поэтому очень возможно заполнить максимальное распределение inode без заполнения самой файловой системы. Вы можете использовать df для проверки.

sudo df -i /

Сравните используемые иноды с общим количеством инодов. Если, к сожалению, больше нет, вы не можете получить больше. Удалите некоторые ненужные или устаревшие файлы, чтобы очистить inode.

Плохие блоки

Последняя распространенная проблема - плохие блоки файловой системы. Файловые системы повреждены и на жестких дисках d ie. Ваша операционная система, скорее всего, увидит эти блоки как пригодные для использования, если они не помечены иначе. Лучший способ найти и пометить эти блоки - использовать fsck с флагом - cc. Помните, что вы не можете использовать fsck из той же файловой системы, которую тестируете.

Возможно, вы также захотите опубликовать вопрос в Linux обмене, например https://unix.stackexchange.com/ или https://serverfault.com/

0 голосов
/ 21 апреля 2020

Я думаю, что это не связано с вашей машиной, это связано с вашим ограничением размера тома. Вы можете ограничить их. Можете ли вы проверить свой контейнер с помощью docker container inspect <container-Id> и проверить связанные с ним тома, вы также можете проверить каждый том по его идентификатору с помощью команды docker volume inspect <volume-Id>.

После некоторых исследований я уверен, что это может быть проблемой проверить эту тему, это немного связано https://github.com/moby/moby/issues/5151

...