-

Thu, 10 Oct 2024 14:58:30 +0200 zuletzt bearbeitet: Fri, 25 Oct 2024 14:42:54 +0200

erua@hub.hubzilla.de

Не смог #TimeShift удалить один из снапшотов на #btrfs
«Could not destroy subvolume/snapshot: Directory not empty»
Самая обычная «точка восстановления», коих всегда много.
Что на самом деле на файловой системе:

$ sudo btrfs subvolume list -a .
...
ID ... gen ... top level 5 path <FS_TREE>/timeshift-btrfs/snapshots/2024-09-11_22-00-00/@
ID ... gen ... top level 5 path <FS_TREE>/timeshift-btrfs/snapshots/2024-09-15_07-55-31/@
...
ID 5533 gen ... top level 5 path <FS_TREE>/timeshift-btrfs/snapshots/2024-01-11_21-43-58/@
ID ... gen ... top level 5533 path <FS_TREE>/timeshift-btrfs/snapshots/2024-01-11_21-43-58/@/var/lib/docker/btrfs/subvolumes/какой-то-sha1
ID ... gen ... top level 5533 path <FS_TREE>/timeshift-btrfs/snapshots/2024-01-11_21-43-58/@/var/lib/docker/btrfs/subvolumes/длинный-sha1-init
ID ... gen ... top level 5533 path <FS_TREE>/timeshift-btrfs/snapshots/2024-01-11_21-43-58/@/var/lib/docker/btrfs/subvolumes/длинный-sha1

Оказывается #Docker виноват — отчебучил что-то когда-то, поскольку не удаляется именно "2024-01-11_21-43-58".
Пришлось вручную удалить три дочерних и потом уже сам «проблемный»:

sudo btrfs subvolume delete -i ... /run/timeshift/100500/backup/timeshift-btrfs/snapshots/2024-01-11_21-43-58/@/var/lib/docker/btrfs/subvolumes/длинный-sha1-init-init
...
sudo btrfs subvolume delete -i 5533 /run/timeshift/100500/backup/timeshift-btrfs/snapshots/2024-02-18_20-23-38/@

Конечно через жопу т.к.:
‘/run/timeshift/100500/backup/@’ is part of the same file system loop as ‘/’.
Но порой делаешь не задумываясь :)

#linux #BTRFS #timeshift #lang_ru

linux

show all 6 comments

Thu, 10 Oct 2024 15:25:05 +0200

Max

max@lor.sh

@erua
Docker тоже любит btrfs использовать - приходится в конфиге указывать overlay2 какой-нибудь как драйвер хранилища.

Thu, 10 Oct 2024 15:33:15 +0200

🅴🆁🆄🅰 🇷🇺

erua@hub.hubzilla.de

@Max у меня docker используется лишь в rootless-варианте и довольно давно так.

Thu, 10 Oct 2024 15:56:49 +0200

Max

max@lor.sh

@erua
И он btrfs не использует?

Если docker не использует btrfs - то и проблем не должно было возникнуть.

Я же встречал проблемы, когда TimeShift и docker использовали под-тома btrfs параллельно.

Thu, 10 Oct 2024 18:39:32 +0200

🅴🆁🆄🅰 🇷🇺

erua@hub.hubzilla.de

@Max возможно что-то менялось/переустанавливалось в системе тогда, когда этот снапшот случился.

сейчас в rootless-режиме с контекстом пользовательским и точно overlay2, при этом с btrfs как backing filesystem:

$ docker info
...
Storage Driver: overlay2
  Backing Filesystem: btrfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: true
...
Docker Root Dir: /home/имяпользователя/.local/share/docker
...

В моём случае /home находится изначально в отдельном subvolume, который не подвергается снапшотам timeshift. В аналогичных выделенных subvolume, отдельно от /, находятся /var/log и /var/cache
Соответственно, все контейнеры и выведены из под наблюдения timeshift'ом.

В официальной документации расписано как докер работает с btrfs, если storage driver был переключен на btrfs. Для своих сценариев использования ничего особо примечательного не наблюдаю, чтобы имело смысл уходить с overlay2

Fri, 11 Oct 2024 07:49:39 +0200 zuletzt bearbeitet: Fri, 11 Oct 2024 07:50:01 +0200

Max

max@lor.sh

@erua
Так я наоборот, на overlay2 предлагаю переходить.

Но ты точно уверен, что виноват именно rootless docker? Он в /var/lib/docker/ не должен же лезть.

Fri, 11 Oct 2024 11:03:00 +0200

🅴🆁🆄🅰 🇷🇺

erua@hub.hubzilla.de

@Max не помню, что за перетрубации были с установкой и сносом систем контейнеризации на конкретно той машине.
вполне могла быть произойти замена Podman на Docker с последующим переводом в rootless-вариант.

в целом, слабо погружён в контейнеризацию как таковую, но иногда приходится вариться во всём что вокруг LXC/LXD и runC да CRI-O и приколы CRIU и уже давно так если оглядываться на даты знакомых публикаций.

так что хрен его знает, чё тогда происходило на той машине.