[opensuse-support] delete snapshots from btrfs subvolume
Hi, I'm trying to delete snapshots in /.snapshots from my HDD using the rescue disk. mount shows me the partition mounted as rw but if I try to delete a file by hand it says: rm: cannot remove '<path-to-file>': Read-only file system I also tried snapper --no-dbus -r /mnt rm 44 I tried mounting the partition in the following ways: mount /dev/sda6 /mnt mount -o subvol=.snapshots /dev/sda6 /mnt mount -o recovery,nospace_cache,clear_cache /dev/sda6 /mnt But nothing helps. How can I get rid of the snapshots or any other files? Regards, Matthias
Op woensdag 28 augustus 2019 16:30:21 CEST schreef Matthias Brugger:
Hi,
I'm trying to delete snapshots in /.snapshots from my HDD using the rescue disk. mount shows me the partition mounted as rw but if I try to delete a file by hand it says:
rm: cannot remove '<path-to-file>': Read-only file system
I also tried snapper --no-dbus -r /mnt rm 44
I tried mounting the partition in the following ways: mount /dev/sda6 /mnt mount -o subvol=.snapshots /dev/sda6 /mnt mount -o recovery,nospace_cache,clear_cache /dev/sda6 /mnt
But nothing helps. How can I get rid of the snapshots or any other files?
Regards, Matthias You need to do that from the running system, using snapper. sudo snapper list sudo remove ####-#### where #### reprents snapshot index numbers.
And re mounting: Rather create a chroot into the install mount /dev/sda6 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt mount -a snapper list snapper remove #### (-####) -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
28.08.2019 17:30, Matthias Brugger пишет:
Hi,
I'm trying to delete snapshots in /.snapshots from my HDD using the rescue disk. mount shows me the partition mounted as rw but if I try to delete a file by hand it says:
rm: cannot remove '<path-to-file>': Read-only file system
We do not even know what you are trying to delete and where <path-to-file> is located. The most simple answer is that <path-to-file> is on read-only rescue disk. Besides, I do not understand what "rm" has to do with "removing snapshots". You do not remove btrfs subvolume using "rm". If you are trying to remove files from within read-only snapshot, then it is obviously not possible.
I also tried snapper --no-dbus -r /mnt rm 44
I tried mounting the partition in the following ways: mount /dev/sda6 /mnt mount -o subvol=.snapshots /dev/sda6 /mnt mount -o recovery,nospace_cache,clear_cache /dev/sda6 /mnt
But nothing helps. How can I get rid of the snapshots or any other files?
You do not show mount table, you do not show commands you use, you do not show their output, you do not show any kernel messages (if filesystem goes read-only, you should have kernel messages in dmesg) ... do you seriously expect useful replies? You remove btrfs subvolume using btrfs subvolume delete /path/to/subvolume snapshot is just another btrfs subvolume. To use snapper from rescue environment you at least need to make sure that subvolume with snapshots is mounted on <path-to-root>/.snapshots directory. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 28/08/2019 18:42, Andrei Borzenkov wrote:
28.08.2019 17:30, Matthias Brugger пишет:
Hi,
I'm trying to delete snapshots in /.snapshots from my HDD using the rescue disk. mount shows me the partition mounted as rw but if I try to delete a file by hand it says:
rm: cannot remove '<path-to-file>': Read-only file system
We do not even know what you are trying to delete and where <path-to-file> is located. The most simple answer is that <path-to-file> is on read-only rescue disk.
Besides, I do not understand what "rm" has to do with "removing snapshots". You do not remove btrfs subvolume using "rm". If you are trying to remove files from within read-only snapshot, then it is obviously not possible.
Thing is snapshot 44 occupies 23GB on the disk, but does not show up with 'snapper ls'
I also tried snapper --no-dbus -r /mnt rm 44
I tried mounting the partition in the following ways: mount /dev/sda6 /mnt mount -o subvol=.snapshots /dev/sda6 /mnt mount -o recovery,nospace_cache,clear_cache /dev/sda6 /mnt
But nothing helps. How can I get rid of the snapshots or any other files?
You do not show mount table, you do not show commands you use, you do not show their output, you do not show any kernel messages (if filesystem goes read-only, you should have kernel messages in dmesg) ... do you seriously expect useful replies?
The root cause is, that the btrfs filesystem is broken. You can find some information here: https://bugzilla.suse.com/show_bug.cgi?id=1138548 If you have any idea how to fix this, please let me know. The partition is still around and it would help me to recover all my settings. But that's a different story, which should be discussed in the bug and not on this mail thread. Regards, Matthias
You remove btrfs subvolume using
btrfs subvolume delete /path/to/subvolume
snapshot is just another btrfs subvolume.
To use snapper from rescue environment you at least need to make sure that subvolume with snapshots is mounted on <path-to-root>/.snapshots directory.
Am Freitag, 30. August 2019, 11:04:58 CEST schrieb Matthias Brugger: ...
Besides, I do not understand what "rm" has to do with "removing snapshots". You do not remove btrfs subvolume using "rm". If you are trying to remove files from within read-only snapshot, then it is obviously not possible.
Thing is snapshot 44 occupies 23GB on the disk, but does not show up with 'snapper ls'
same issue here....Snapshot 549 is shown as the currently mounted snapshot, but in .snapshots is another snapshot 444 with some 10 GB - no I know why I always struggle with large upgrades (TW system) Is it safe just to delete it the hard way?
The root cause is, that the btrfs filesystem is broken. You can find some information here: https://bugzilla.suse.com/show_bug.cgi?id=1138548
I could not really find an explanation what is broken in this message.... Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Le 30/08/2019 à 19:24, Axel Braun a écrit :
Is it safe just to delete it the hard way?
did you get the size by btrfs command or linux command? chance is the snapshots are the same files jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Op vrijdag 30 augustus 2019 19:24:19 CEST schreef Axel Braun:
Am Freitag, 30. August 2019, 11:04:58 CEST schrieb Matthias Brugger:
...
Besides, I do not understand what "rm" has to do with "removing snapshots". You do not remove btrfs subvolume using "rm". If you are trying to remove files from within read-only snapshot, then it is obviously not possible.
Thing is snapshot 44 occupies 23GB on the disk, but does not show up with 'snapper ls'
same issue here....Snapshot 549 is shown as the currently mounted snapshot, but in .snapshots is another snapshot 444 with some 10 GB - no I know why I always struggle with large upgrades (TW system)
Is it safe just to delete it the hard way?
The root cause is, that the btrfs filesystem is broken. You can find some information here: https://bugzilla.suse.com/show_bug.cgi?id=1138548
I could not really find an explanation what is broken in this message....
Cheers Axel That would be simply snapper remove 444
But mind to use the proper tools to get it's size. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am Freitag, 30. August 2019, 19:28:58 CEST schrieb Knurpht-openSUSE:
That would be simply snapper remove 444
The problem is: T520:/home/docb # snapper list # | Typ | Vorher # | Datum | Benutzer | Verwendeter Platz | Bereinigen | Beschreibung | Benutzerdaten -----+--------+----------+------------------------------+---------- +-------------------+------------+--------------+-------------- 0 | single | | | root | | | current | 549* | single | | Sa 30 Mär 2019 21:17:16 CET | root | 186,43 MiB | | | 666 | pre | | Mo 26 Aug 2019 18:29:02 CEST | root | 4,13 GiB | number | zypp(zypper) | important=yes 667 | post | 666 | Mo 26 Aug 2019 18:38:06 CEST | root | 22,27 MiB | number | | important=yes T520:/home/docb # snapper rm 444 Snapshot '444' not found -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am Freitag, 30. August 2019, 19:27:05 CEST schrieb jdd@dodin.org:
Is it safe just to delete it the hard way?
did you get the size by btrfs command or linux command?
Dolphin -> right click (yes, I know it might not be accurate)
chance is the snapshots are the same files
Thats why I ask before I delete. Otherwise I have to repartition sooner or later.... Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
30.08.2019 20:34, Axel Braun пишет:
Am Freitag, 30. August 2019, 19:28:58 CEST schrieb Knurpht-openSUSE:
That would be simply snapper remove 444
The problem is: T520:/home/docb # snapper list # | Typ | Vorher # | Datum | Benutzer | Verwendeter Platz | Bereinigen | Beschreibung | Benutzerdaten -----+--------+----------+------------------------------+---------- +-------------------+------------+--------------+-------------- 0 | single | | | root | | | current | 549* | single | | Sa 30 Mär 2019 21:17:16 CET | root | 186,43 MiB | | | 666 | pre | | Mo 26 Aug 2019 18:29:02 CEST | root | 4,13 GiB | number | zypp(zypper) | important=yes 667 | post | 666 | Mo 26 Aug 2019 18:38:06 CEST | root | 22,27 MiB | number | | important=yes
T520:/home/docb # snapper rm 444
Snapshot '444' not found
and what makes you believe there is snapshot #444 in the first place? -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
30.08.2019 20:35, Axel Braun пишет:
Am Freitag, 30. August 2019, 19:27:05 CEST schrieb jdd@dodin.org:
Is it safe just to delete it the hard way?
did you get the size by btrfs command or linux command?
Dolphin -> right click
Are you sure you understand what snapshot is?
(yes, I know it might not be accurate)
"Might" is very weak way to express it.
chance is the snapshots are the same files
Thats why I ask before I delete. Otherwise I have to repartition sooner or later....
Cheers Axel
-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Op vrijdag 30 augustus 2019 19:34:06 CEST schreef Axel Braun:
Am Freitag, 30. August 2019, 19:28:58 CEST schrieb Knurpht-openSUSE:
That would be simply snapper remove 444
The problem is: T520:/home/docb # snapper list # | Typ | Vorher # | Datum | Benutzer | Verwendeter Platz | Bereinigen | Beschreibung | Benutzerdaten -----+--------+----------+------------------------------+---------- +-------------------+------------+--------------+-------------- 0 | single | | | root |
| | current |
549* | single | | Sa 30 Mär 2019 21:17:16 CET | root | 186,43 MiB | | | 666 | pre | | Mo 26 Aug 2019 18:29:02 CEST | root | 4,13 GiB | number | zypp(zypper) | important=yes 667 | post | 666 | Mo 26 Aug 2019 18:38:06 CEST | root | 22,27 MiB | number | | important=yes
T520:/home/docb # snapper rm 444
Snapshot '444' not found So you only have 3 snapshots. Please show sudo btrfs fi df /
If your rootfs looks full to you, also look at what is in /var/ -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am Freitag, 30. August 2019, 19:39:10 CEST schrieb Andrei Borzenkov:
and what makes you believe there is snapshot #444 in the first place?
T520:/home/docb # dir /.snapshots/ insgesamt 4 drwxr-xr-x 1 root root 66 13. Sep 2018 444 drwxr-xr-x 1 root root 32 30. Mär 21:17 549 drwxr-xr-x 1 root root 66 26. Aug 18:38 666 drwxr-xr-x 1 root root 98 27. Aug 07:40 667 -rw-r----- 1 root root 520 27. Aug 07:38 grub-snapshot.cfg First entry maybe?
Snapshot '444' not found
So you only have 3 snapshots. Please show sudo btrfs fi df /
T520:/home/docb # btrfs fi df / Data, single: total=38.24GiB, used=35.15GiB System, single: total=32.00MiB, used=16.00KiB Metadata, single: total=1.50GiB, used=830.12MiB GlobalReserve, single: total=94.39MiB, used=0.00B
If your rootfs looks full to you, also look at what is in /var/
Not much. I cleaned it before the last upgrade Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
31.08.2019 14:33, Axel Braun пишет:
Am Freitag, 30. August 2019, 19:39:10 CEST schrieb Andrei Borzenkov:
and what makes you believe there is snapshot #444 in the first place?
T520:/home/docb # dir /.snapshots/ insgesamt 4 drwxr-xr-x 1 root root 66 13. Sep 2018 444
Show cat /.snapshots/549/info.xml btrfs subvolume get-default / btrfs subvolume list -pqu / btrfs qgroup show -c / grep -w btrfs /proc/mounts -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
31.08.2019 16:03, Andrei Borzenkov пишет:
31.08.2019 14:33, Axel Braun пишет:
Am Freitag, 30. August 2019, 19:39:10 CEST schrieb Andrei Borzenkov:
and what makes you believe there is snapshot #444 in the first place?
T520:/home/docb # dir /.snapshots/ insgesamt 4 drwxr-xr-x 1 root root 66 13. Sep 2018 444
Show
cat /.snapshots/549/info.xml
s/549/444/ of course. Sorry.
btrfs subvolume get-default / btrfs subvolume list -pqu / btrfs qgroup show -c / grep -w btrfs /proc/mounts
-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am Samstag, 31. August 2019, 15:03:18 CEST schrieb Andrei Borzenkov:
31.08.2019 14:33, Axel Braun пишет:
Am Freitag, 30. August 2019, 19:39:10 CEST schrieb Andrei Borzenkov:
and what makes you believe there is snapshot #444 in the first place?
T520:/home/docb # dir /.snapshots/ insgesamt 4 drwxr-xr-x 1 root root 66 13. Sep 2018 444
Show
cat /.snapshots/549/info.xml btrfs subvolume get-default / btrfs subvolume list -pqu / btrfs qgroup show -c / grep -w btrfs /proc/mounts
T520:/home/docb # cat /.snapshots/444/info.xml T520:/home/docb # btrfs subvolume get-default / ID 1064 gen 437061 top level 258 path @/.snapshots/549/snapshot T520:/home/docb # btrfs subvolume list -pqu / ID 257 gen 420790 parent 5 top level 5 parent_uuid - uuid a6f7b202-3642-734a-b8e6-1d11a8624564 path @ ID 258 gen 437053 parent 257 top level 257 parent_uuid - uuid a5a8261a-62f4-1c40-8106-1eea3c8b6e89 path @/.snapshots ID 260 gen 437046 parent 257 top level 257 parent_uuid - uuid f4955930-90ab-d04f-8b73-a6391927cce3 path @/boot/grub2/i386-pc ID 261 gen 437046 parent 257 top level 257 parent_uuid - uuid 33e48318-709d-5c49-b2f8-33ffc78ab7f8 path @/boot/grub2/x86_64-efi ID 262 gen 436719 parent 257 top level 257 parent_uuid - uuid 79e69b04-353d-4a45-9d39-b2bf0d7e2d76 path @/opt ID 263 gen 436719 parent 257 top level 257 parent_uuid - uuid 81ac7586-2742-fd4c-bc05-db8b51934453 path @/srv ID 264 gen 437061 parent 257 top level 257 parent_uuid - uuid 961354e7-6bf5-4440-ae76-3d490a5ed87e path @/tmp ID 265 gen 436999 parent 257 top level 257 parent_uuid - uuid 8588e9c5-b406-274d-a508-00ec2ff1182f path @/usr/local ID 266 gen 437053 parent 257 top level 257 parent_uuid - uuid 03da2743-1495-aa43-ad05-f8d5f3220b3a path @/var/cache ID 267 gen 431329 parent 257 top level 257 parent_uuid - uuid c196b6b3-48c3-9942-b07a-99cf4a46f7dd path @/var/crash ID 268 gen 420790 parent 257 top level 257 parent_uuid - uuid b6f6a72f-40d5-4a48-b6f7-149a23132816 path @/var/lib/libvirt/images ID 269 gen 420790 parent 257 top level 257 parent_uuid - uuid 317ab96d-90d8-8f41-8563-2eeb074b7321 path @/var/lib/machines ID 270 gen 430675 parent 257 top level 257 parent_uuid - uuid a5677d71-1dd6-1348-af59-349fa901a2dd path @/var/lib/mailman ID 271 gen 430676 parent 257 top level 257 parent_uuid - uuid d50e471e-a6ed-bd40-97cb-8c173f12f842 path @/var/lib/mariadb ID 272 gen 430676 parent 257 top level 257 parent_uuid - uuid 241be768-8d26-324f-ae4b-8919e0b56f80 path @/var/lib/mysql ID 273 gen 430677 parent 257 top level 257 parent_uuid - uuid 6655a12d-aaf8-564c-8b2f-a9daf649ffa9 path @/var/lib/named ID 274 gen 421561 parent 257 top level 257 parent_uuid - uuid 4ed8f7d4-cad1-504d-91f8-c7d431eb09c3 path @/var/lib/pgsql ID 275 gen 437061 parent 257 top level 257 parent_uuid - uuid 596f781e-b1f3-b345-8abc-4d21cb599881 path @/var/log ID 276 gen 431329 parent 257 top level 257 parent_uuid - uuid d2fe9183-6eda-4148-ac76-31a8ff4392fa path @/var/opt ID 277 gen 437061 parent 257 top level 257 parent_uuid - uuid a47529cf-752f-d145-acab-d1c3366d6baa path @/var/spool ID 278 gen 437061 parent 257 top level 257 parent_uuid - uuid 297ca24f-7d84-cc48-9470-3702328fcda9 path @/var/tmp ID 889 gen 420790 parent 258 top level 258 parent_uuid 44619f06-a4be-5847- a3dd-e8cc59fa7c27 uuid a5a43e4f-513b-654e-9fb3-b3c52d91bb41 path @/.snapshots/ 444/snapshot ID 1064 gen 437061 parent 258 top level 258 parent_uuid 6ff4b321-1c1e-4e43-93d4-1fe734952198 uuid 8abc72b9-5c78-6547-aa05-2330e29aac0d path @/.snapshots/549/snapshot ID 1256 gen 435872 parent 258 top level 258 parent_uuid 8abc72b9-5c78-6547- aa05-2330e29aac0d uuid 741b4046-e4b5-a745-96e9-b890ddc24e9d path @/.snapshots/ 666/snapshot ID 1257 gen 435893 parent 258 top level 258 parent_uuid 8abc72b9-5c78-6547- aa05-2330e29aac0d uuid 02c190b7-686e-1a45-9212-287a9a51e0dd path @/.snapshots/ 667/snapshot ID 1259 gen 437014 parent 258 top level 258 parent_uuid 8abc72b9-5c78-6547- aa05-2330e29aac0d uuid 18cf597c-fa7d-8f42-9c30-b973a430611e path @/.snapshots/ 668/snapshot ID 1260 gen 437052 parent 258 top level 258 parent_uuid 8abc72b9-5c78-6547- aa05-2330e29aac0d uuid c66b5c43-d80f-4d46-849a-bcd15a20fc21 path @/.snapshots/ 669/snapshot T520:/home/docb # btrfs qgroup show -c / qgroupid rfer excl child -------- ---- ---- ----- 0/5 16.00KiB 16.00KiB --- 0/257 16.00KiB 16.00KiB --- 0/258 1.06MiB 1.06MiB --- 0/260 2.36MiB 2.36MiB --- 0/261 16.00KiB 16.00KiB --- 0/262 147.74MiB 147.74MiB --- 0/263 1.21MiB 1.21MiB --- 0/264 1.19MiB 1.19MiB --- 0/265 18.83MiB 18.83MiB --- 0/266 285.43MiB 285.43MiB --- 0/267 16.00KiB 16.00KiB --- 0/268 16.00KiB 16.00KiB --- 0/269 16.00KiB 16.00KiB --- 0/270 16.00KiB 16.00KiB --- 0/271 16.00KiB 16.00KiB --- 0/272 16.00KiB 16.00KiB --- 0/273 16.00KiB 16.00KiB --- 0/274 16.00KiB 16.00KiB --- 0/275 1.92GiB 1.92GiB --- 0/276 16.00KiB 16.00KiB --- 0/277 5.14MiB 5.14MiB --- 0/278 20.94MiB 20.94MiB --- 0/889 9.71GiB 9.33GiB --- 0/1064 19.83GiB 3.16MiB --- 0/1256 19.56GiB 4.13GiB --- 0/1257 19.83GiB 22.97MiB --- 0/1259 19.83GiB 8.88MiB --- 0/1260 19.83GiB 1.30MiB --- 1/0 33.28GiB 13.65GiB 0/889,0/1256,0/1257,0/1259,0/1260 255/269 16.00KiB 16.00KiB 0/269 T520:/home/docb # grep -w btrfs /proc/mounts /dev/sda2 / btrfs rw,relatime,ssd,space_cache,subvolid=1064,subvol=/ @/.snapshots/549/snapshot 0 0 /dev/sda2 /opt btrfs rw,relatime,ssd,space_cache,subvolid=262,subvol=/@/opt 0 0 /dev/sda2 /boot/grub2/i386-pc btrfs rw,relatime,ssd,space_cache,subvolid=260,subvol=/@/boot/grub2/i386-pc 0 0 /dev/sda2 /var/lib/mariadb btrfs rw,relatime,ssd,space_cache,subvolid=271,subvol=/@/var/lib/mariadb 0 0 /dev/sda2 /var/crash btrfs rw,relatime,ssd,space_cache,subvolid=267,subvol=/@/ var/crash 0 0 /dev/sda2 /srv btrfs rw,relatime,ssd,space_cache,subvolid=263,subvol=/@/srv 0 0 /dev/sda2 /var/lib/named btrfs rw,relatime,ssd,space_cache,subvolid=273,subvol=/@/var/lib/named 0 0 /dev/sda2 /var/spool btrfs rw,relatime,ssd,space_cache,subvolid=277,subvol=/@/ var/spool 0 0 /dev/sda2 /var/cache btrfs rw,relatime,ssd,space_cache,subvolid=266,subvol=/@/ var/cache 0 0 /dev/sda2 /var/opt btrfs rw,relatime,ssd,space_cache,subvolid=276,subvol=/@/ var/opt 0 0 /dev/sda2 /var/lib/pgsql btrfs rw,relatime,ssd,space_cache,subvolid=274,subvol=/@/var/lib/pgsql 0 0 /dev/sda2 /.snapshots btrfs rw,relatime,ssd,space_cache,subvolid=258,subvol=/ @/.snapshots 0 0 /dev/sda2 /boot/grub2/x86_64-efi btrfs rw,relatime,ssd,space_cache,subvolid=261,subvol=/@/boot/grub2/x86_64-efi 0 0 /dev/sda2 /var/tmp btrfs rw,relatime,ssd,space_cache,subvolid=278,subvol=/@/ var/tmp 0 0 /dev/sda2 /var/lib/machines btrfs rw,relatime,ssd,space_cache,subvolid=269,subvol=/@/var/lib/machines 0 0 /dev/sda2 /var/lib/libvirt/images btrfs rw,relatime,ssd,space_cache,subvolid=268,subvol=/@/var/lib/libvirt/images 0 0 /dev/sda2 /tmp btrfs rw,relatime,ssd,space_cache,subvolid=264,subvol=/@/tmp 0 0 /dev/sda2 /var/lib/mailman btrfs rw,relatime,ssd,space_cache,subvolid=270,subvol=/@/var/lib/mailman 0 0 /dev/sda2 /var/lib/mysql btrfs rw,relatime,ssd,space_cache,subvolid=272,subvol=/@/var/lib/mysql 0 0 /dev/sda2 /usr/local btrfs rw,relatime,ssd,space_cache,subvolid=265,subvol=/@/ usr/local 0 0 /dev/sda2 /var/log btrfs rw,relatime,ssd,space_cache,subvolid=275,subvol=/@/ var/log 0 0 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
31.08.2019 16:35, Axel Braun пишет:
Am Samstag, 31. August 2019, 15:03:18 CEST schrieb Andrei Borzenkov:
31.08.2019 14:33, Axel Braun пишет:
Am Freitag, 30. August 2019, 19:39:10 CEST schrieb Andrei Borzenkov:
and what makes you believe there is snapshot #444 in the first place?
T520:/home/docb # dir /.snapshots/ insgesamt 4 drwxr-xr-x 1 root root 66 13. Sep 2018 444
Show
cat /.snapshots/549/info.xml btrfs subvolume get-default / btrfs subvolume list -pqu / btrfs qgroup show -c / grep -w btrfs /proc/mounts
T520:/home/docb # cat /.snapshots/444/info.xml
Which is the reason snapper does not see this snapshot/
T520:/home/docb # btrfs subvolume get-default / ID 1064 gen 437061 top level 258 path @/.snapshots/549/snapshot
T520:/home/docb # btrfs subvolume list -pqu / ... ID 889 gen 420790 parent 258 top level 258 parent_uuid 44619f06-a4be-5847- a3dd-e8cc59fa7c27 uuid a5a43e4f-513b-654e-9fb3-b3c52d91bb41 path @/.snapshots/ 444/snapshot ...
T520:/home/docb # btrfs qgroup show -c / qgroupid rfer excl child -------- ---- ---- ----- 0/889 9.71GiB 9.33GiB --- Yes, it consumes over 9GiB of space
/dev/sda2 /.snapshots btrfs rw,relatime,ssd,space_cache,subvolid=258,subvol=/@/.snapshots 0 0
As snapper metadata is lost anyway, just remove it btrfs subvolume delete /.snapshots/444/snapshot rm -r /.snapshots/444 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am Samstag, 31. August 2019, 16:35:59 CEST schrieb Andrei Borzenkov:
As snapper metadata is lost anyway, just remove it
btrfs subvolume delete /.snapshots/444/snapshot rm -r /.snapshots/444
That worked well, so side-effects up to now. Thanks. Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
participants (5)
-
Andrei Borzenkov -
Axel Braun -
jdd＠dodin.org -
Knurpht-openSUSE -
Matthias Brugger