С другой стороны, я читал, что BTRFS оптимальна для docker.

Если используешь OverlayFS, то лучше не рисковать здоровьем данных и держать их на ext4. А /var/lib/docker/ можно просто скопировать.

Да, в общем то, в самих контейнерах данных нет (они stateless). Вся ценная информация все-равно подмаплена из /opt. Так что, если и рухнет система - пересоздать контейнеры по Dockerfile не долго.

Ну, ты хорошо живёшь :)

Просто при всех плюшках Btrfs её применимость в боевых условиях - вопрос дискуссионный.

Если они stateless, то

пересоздать контейнеры по Dockerfile

было бы разумнее всего

Да, но я не уверен, что если основная файловая система ext4 и даже /var смонтирован на ext4 docker пойдет, что ссылка ведет на btrfs. Но если других стандартных вариантов нет — попробую этот

Эм.

Какое отношение имеет ФС если ты полностью с ноля разворачиваешь контейнеры?

Данные docker (образы и контейнеры) стали занимать много места и я задумался перенести их на отдельный диск

Вот, снова концептуальная ошибка в использовании, про которую я много раз предупреждал, привела к таким последствиям.

Если возникает желание возиться с Docker «изнутри» (и, как следствие, сохранять потом образы/данные), то это задача не для Docker, а, например, для LXC.

Все задачи Docker должны решаться на уровне Dockerfile и внешних монтируемых каталогов. Тогда вопрос переноса превращается в перенос крошечного Dockerfile и каталога с данными.

Вся ценная информация все-равно подмаплена из /opt. Так что, если и рухнет система - пересоздать контейнеры по Dockerfile не долго.

Э... Тогда в чём проблема?

а как же использование data-only контейнера с -v /foo, который будет лежать «где-то» /var/lib/docker, и абстрагироваться от файловой структуры хоста (того же /opt и т.д.)?

Я у себя не нашел применения data-only контейнерам и просто монтирую внешние папки, как volumes.

а как же использование data-only контейнера

Я считаю это непонятным злом :) В смысле порождения трудностей переноса. Нафига монтировать в персистентный контейнер (который к тому же легко нечаянно грохнуть при чистке инфраструктуры Docker при работе по ID), когда можно монтировать в каталог?

и абстрагироваться от файловой структуры хоста (того же /opt и т.д.)?

С точки зрения рабочих контейнеров и монтируемый каталог — тоже абстрагирован от хоста. А с точки зрения менеджмента этих контейнеров такое абстрагирование легко будет приводить к потерям. Я бы не рисковал хранить данные в контейнерах, которые легко грохнуть по ошибке, промахнувшись с копипастом id и даже не понять этого сразу.

Чтобы грохнуть volume надо rm с ключом -v

if you remove containers that mount volumes, including the initial dbdata container, or the subsequent containers db1 and db2, the volumes will not be deleted. To delete the volume from disk, you must explicitly call docker rm -v against the last container with a reference to the volume. This allows you to upgrade, or effectively migrate data volumes between containers.

а сам контейнер да, грохнуть можно.