Что произойдет, если я удалю файлы в снимке BtrFS?

Что произойдет, если я удалю файлы в снимке BtrFS?

У меня есть компьютер openSUSE, который изначально запускался с BtrFS (вроде Leap 42.2). В какой-то момент в прошлом подтом /tmp заполнился (один большой файл), и я не мог восстановить пространство до перезагрузки ( rmвызвал No space left on device). Затем все выглядело нормально по крайней мере в течение года.

Но недавно (в то же время в Leap 15.1) BtrFS снова заполнилась, и я задался вопросом, что делать: у меня было много снимков, подобных этому:

# ls -l /.snapshots/
total 4
drwxr-xr-x 1 root root  32 Dec 18  2015 1
drwxr-xr-x 1 root root  32 May 14 09:45 1820
drwxr-xr-x 1 root root  66 May 14 09:46 1821

...

drwxr-xr-x 1 root root  32 Aug  8 08:08 1926
drwxr-xr-x 1 root root  38 Aug  8 08:09 1927
drwxr-xr-x 1 root root  38 Aug  8 08:12 1928

После успешной проверки контрольных сумм всех блоков (без проблем) я запустил «балансировку», надеясь, что появится немного свободного места. Но балансировка, похоже, так и не завершилась, поэтому я попытался ее прервать. Подождав не менее 15 минут, пока балансировка прервется, я перезагрузил компьютер, чтобы попробовать что-то еще. В то время файловая система была заполнена на 99%.

Я думал, что очистлю самый старый снимок ( 1) с помощью rm -rf /.snapshots/1. К сожалению, после завершения важные программы из /usrисчезли, и моя система перестала загружаться!

Итак, мой вопрос: это ожидаемое поведение, или я что-то сделал не так? Если я что-то сделал не так, какова правильная процедура удаления старых снимков?

решение1

Похоже, проблемы, обнаруженные после удаления, /.snapshots/1являются не столько особенностью BtrFS как таковой, сколько (ошибочной?) особенностью SUSE Linux:

Я не помню, какая была корневая файловая система, но на сопоставимой системе SLES 15.0 я заметил, что снимок 1был смонтирован как корневая файловая система (по какой-то причине):

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=16329060k,nr_inodes=4082265,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,size=24506344k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
#...
/dev/sda2 on / type btrfs (rw,relatime,space_cache,subvolid=267,subvol=/@/.snapshots/1/snapshot)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=38,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14427)
#...
/dev/sda2 on /.snapshots type btrfs (rw,relatime,space_cache,subvolid=266,subvol=/@/.snapshots)
/dev/sda2 on /opt type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@/opt)
/dev/sda2 on /usr/local type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/usr/local)
/dev/sda2 on /var type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@/var)
#...
/dev/sda2 on /root type btrfs (rw,relatime,space_cache,subvolid=262,subvol=/@/root)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=3267512k,mode=700)

Похоже , вот subvol=/@/.snapshots/1/snapshot)в чем корень причины.

Связанный контент