* 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs)
@ 2018-08-28 9:34 Menion
2018-08-28 11:54 ` Qu Wenruo
2018-08-28 13:47 ` Chris Murphy
0 siblings, 2 replies; 15+ messages in thread
From: Menion @ 2018-08-28 9:34 UTC (permalink / raw)
To: linux-btrfs
Hi all
I have run a distro upgrade on my Ubuntu 16.04 that runs ppa kernel
4.17.2 with btrfsprogs 4.17.0
The root filesystem is BTRFS single created by the Ubuntu Xenial
installer (so on kernel 4.4.0) on an internal mmc, located in
/dev/mmcblk0p3
After the upgrade I have cleaned apt cache and checked the free space,
the results were odd, following some checks (shrinked), followed by
more comments:
root@Menionubuntu:/home/menion# df -h
Filesystem Size Used Avail Use% Mounted on
...............................................................
/dev/mmcblk0p3 28G 24G 2.7G 90% /
root@Menionubuntu:/home/menion# btrfs fi usage /usr
Overall:
Device size: 27.07GiB
Device allocated: 25.28GiB
Device unallocated: 1.79GiB
Device missing: 0.00B
Used: 23.88GiB
Free (estimated): 2.69GiB (min: 2.69GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 72.94MiB (used: 0.00B)
Data,single: Size:24.00GiB, Used:23.10GiB
/dev/mmcblk0p3 24.00GiB
Metadata,single: Size:1.25GiB, Used:801.97MiB
/dev/mmcblk0p3 1.25GiB
System,single: Size:32.00MiB, Used:16.00KiB
/dev/mmcblk0p3 32.00MiB
Unallocated:
/dev/mmcblk0p3 1.79GiB
root@Menionubuntu:/home/menion# btrfs fi df /mnt
Data, single: total=24.00GiB, used=23.10GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.25GiB, used=801.92MiB
GlobalReserve, single: total=72.89MiB, used=0.00B
The different ways to check the free space are coherent, but if I
check the directories usage on root, surprise:
root@Menionubuntu:/home/menion# du -x -s -h /*
17M /bin
189M /boot
36K /dead.letter
0 /dev
18M /etc
6.1G /home
4.0K /initrd.img
4.0K /initrd.img.old
791M /lib
8.3M /lib64
0 /media
4.0K /mnt
0 /opt
du: cannot access '/proc/24660/task/24660/fd/3': No such file or directory
du: cannot access '/proc/24660/task/24660/fdinfo/3': No such file or directory
du: cannot access '/proc/24660/fd/3': No such file or directory
du: cannot access '/proc/24660/fdinfo/3': No such file or directory
0 /proc
2.9M /root
2.9M /run
17M /sbin
4.0K /snap
0 /srv
0 /sys
0 /tmp
6.1G /usr
2.0G /var
4.0K /vmlinuz
4.0K /vmlinuz.old
4.0K /webmin-setup.out
The computed usage is 15Gb which is what I expected, so there are 9Gb
lost somewhere.
I have run scrub and then full balance with:
btrfs scrub start /
btrfs balance start /
The balance freed 100Mb of space, it was running in background so I
have checked dmesg when "btrfs balance status" said that was completed
dmesg of balance:
[47264.250141] BTRFS info (device mmcblk0p3): relocating block group
37154193408 flags system
[47264.592082] BTRFS info (device mmcblk0p3): relocating block group
36046897152 flags data
[47271.499809] BTRFS info (device mmcblk0p3): found 73 extents
[47272.329921] BTRFS info (device mmcblk0p3): found 60 extents
[47272.471059] BTRFS info (device mmcblk0p3): relocating block group
35778461696 flags metadata
[47280.530041] BTRFS info (device mmcblk0p3): found 3199 extents
[47280.735667] BTRFS info (device mmcblk0p3): relocating block group
34704719872 flags data
[47301.460523] BTRFS info (device mmcblk0p3): relocating block group
37221302272 flags data
[47306.038404] BTRFS info (device mmcblk0p3): found 5 extents
[47306.481371] BTRFS info (device mmcblk0p3): found 5 extents
[47306.673135] BTRFS info (device mmcblk0p3): relocating block group
37187747840 flags system
[47306.874874] BTRFS info (device mmcblk0p3): found 1 extents
[47307.073288] BTRFS info (device mmcblk0p3): relocating block group
34704719872 flags data
[47371.059074] BTRFS info (device mmcblk0p3): found 16258 extents
[47388.191208] BTRFS info (device mmcblk0p3): found 16094 extents
[47388.985462] BTRFS info (device mmcblk0p3): relocating block group
31215058944 flags metadata
[47439.164167] BTRFS info (device mmcblk0p3): found 7378 extents
[47440.163793] BTRFS info (device mmcblk0p3): relocating block group
30141317120 flags data
[47593.239048] BTRFS info (device mmcblk0p3): found 15636 extents
[47618.389357] BTRFS info (device mmcblk0p3): found 15634 extents
[47620.020122] BTRFS info (device mmcblk0p3): relocating block group
29012000768 flags data
[47637.708444] BTRFS info (device mmcblk0p3): found 1154 extents
[47639.757342] BTRFS info (device mmcblk0p3): found 1154 extents
[47640.375483] BTRFS info (device mmcblk0p3): relocating block group
27938258944 flags data
[47743.312441] BTRFS info (device mmcblk0p3): found 17009 extents
[47756.928461] BTRFS info (device mmcblk0p3): found 17005 extents
[47757.607346] BTRFS info (device mmcblk0p3): relocating block group
9416212480 flags metadata
[47825.819449] BTRFS info (device mmcblk0p3): found 11503 extents
[47826.465926] BTRFS info (device mmcblk0p3): relocating block group
8342470656 flags data
[47900.754062] BTRFS info (device mmcblk0p3): found 20607 extents
[47928.061348] BTRFS info (device mmcblk0p3): found 20607 extents
[47929.125750] BTRFS info (device mmcblk0p3): relocating block group
4852809728 flags metadata
[47993.308492] BTRFS info (device mmcblk0p3): found 13214 extents
[47994.883308] BTRFS info (device mmcblk0p3): relocating block group
3779067904 flags data
[48108.871895] BTRFS info (device mmcblk0p3): found 13256 extents
[48124.623607] BTRFS info (device mmcblk0p3): found 13255 extents
[48125.156150] BTRFS info (device mmcblk0p3): relocating block group
3510632448 flags metadata
[48191.030178] BTRFS info (device mmcblk0p3): found 12394 extents
[48193.202016] BTRFS info (device mmcblk0p3): relocating block group
2436890624 flags data
[48347.733120] BTRFS info (device mmcblk0p3): found 22889 extents
[48371.149135] BTRFS info (device mmcblk0p3): found 22889 extents
[48373.723037] BTRFS info (device mmcblk0p3): relocating block group
20971520 flags metadata
[48449.367016] BTRFS info (device mmcblk0p3): found 13755 extents
[48451.058818] BTRFS info (device mmcblk0p3): relocating block group
12582912 flags data
[48453.657685] BTRFS info (device mmcblk0p3): found 726 extents
[48461.188484] BTRFS info (device mmcblk0p3): found 726 extents
[48463.496116] BTRFS info (device mmcblk0p3): relocating block group
4194304 flags metadata
[48476.405722] BTRFS info (device mmcblk0p3): found 403 extents
[48479.254106] BTRFS info (device mmcblk0p3): 17 enospc errors during balance
There is this enospc errors, can anyone help me in understanding what
is going on?
Bye
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 9:34 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) Menion @ 2018-08-28 11:54 ` Qu Wenruo 2018-08-28 13:07 ` Menion 2018-08-28 13:47 ` Chris Murphy 1 sibling, 1 reply; 15+ messages in thread From: Qu Wenruo @ 2018-08-28 11:54 UTC (permalink / raw) To: Menion, linux-btrfs [-- Attachment #1.1: Type: text/plain, Size: 7993 bytes --] On 2018/8/28 下午5:34, Menion wrote: > Hi all > I have run a distro upgrade on my Ubuntu 16.04 that runs ppa kernel > 4.17.2 with btrfsprogs 4.17.0 > The root filesystem is BTRFS single created by the Ubuntu Xenial > installer (so on kernel 4.4.0) on an internal mmc, located in > /dev/mmcblk0p3 > After the upgrade I have cleaned apt cache and checked the free space, > the results were odd, following some checks (shrinked), followed by > more comments: > > root@Menionubuntu:/home/menion# df -h > Filesystem Size Used Avail Use% Mounted on > ............................................................... > /dev/mmcblk0p3 28G 24G 2.7G 90% / > > root@Menionubuntu:/home/menion# btrfs fi usage /usr > Overall: > Device size: 27.07GiB > Device allocated: 25.28GiB > Device unallocated: 1.79GiB > Device missing: 0.00B > Used: 23.88GiB > Free (estimated): 2.69GiB (min: 2.69GiB) > Data ratio: 1.00 > Metadata ratio: 1.00 > Global reserve: 72.94MiB (used: 0.00B) > > Data,single: Size:24.00GiB, Used:23.10GiB > /dev/mmcblk0p3 24.00GiB > > Metadata,single: Size:1.25GiB, Used:801.97MiB > /dev/mmcblk0p3 1.25GiB > > System,single: Size:32.00MiB, Used:16.00KiB > /dev/mmcblk0p3 32.00MiB > > Unallocated: > /dev/mmcblk0p3 1.79GiB > > root@Menionubuntu:/home/menion# btrfs fi df /mnt > Data, single: total=24.00GiB, used=23.10GiB > System, single: total=32.00MiB, used=16.00KiB > Metadata, single: total=1.25GiB, used=801.92MiB > GlobalReserve, single: total=72.89MiB, used=0.00B > > The different ways to check the free space are coherent, but if I > check the directories usage on root, surprise: > > root@Menionubuntu:/home/menion# du -x -s -h /* > 17M /bin > 189M /boot > 36K /dead.letter > 0 /dev > 18M /etc > 6.1G /home > 4.0K /initrd.img > 4.0K /initrd.img.old > 791M /lib > 8.3M /lib64 > 0 /media > 4.0K /mnt > 0 /opt > du: cannot access '/proc/24660/task/24660/fd/3': No such file or directory > du: cannot access '/proc/24660/task/24660/fdinfo/3': No such file or directory > du: cannot access '/proc/24660/fd/3': No such file or directory > du: cannot access '/proc/24660/fdinfo/3': No such file or directory > 0 /proc > 2.9M /root > 2.9M /run > 17M /sbin > 4.0K /snap > 0 /srv > 0 /sys > 0 /tmp > 6.1G /usr > 2.0G /var > 4.0K /vmlinuz > 4.0K /vmlinuz.old > 4.0K /webmin-setup.out > > The computed usage is 15Gb which is what I expected, so there are 9Gb > lost somewhere. > I have run scrub and then full balance with: I think this is related to btrfs CoW and extent booking. One simple example would be: xfs_io -f -c "pwrite 0 128k" -c "sync" -c "pwrite 0 64K" \ /mnt/btrfs/file1 The result "/mnt/btrfs/file1" will only be sized 128K in du, but it on-disk usage is 128K + 64K. The first 128K is the data written by the first "pwrite" command, it caused a full 128K extent on disk. Then the 2nd pwrite command also created a new 64K extent, which is the default data CoW behavior. The first half of the original 128K extent is not used by anyone, but it still takes space. Above btrfs extent booking behavior could cause a lot of wasted space even there is only one single subvolume without any snapshot. In that case, instead of balance, defrag should be your friend to free up some space. Thanks, Qu > > btrfs scrub start / > btrfs balance start / > The balance freed 100Mb of space, it was running in background so I > have checked dmesg when "btrfs balance status" said that was completed > > dmesg of balance: > > [47264.250141] BTRFS info (device mmcblk0p3): relocating block group > 37154193408 flags system > [47264.592082] BTRFS info (device mmcblk0p3): relocating block group > 36046897152 flags data > [47271.499809] BTRFS info (device mmcblk0p3): found 73 extents > [47272.329921] BTRFS info (device mmcblk0p3): found 60 extents > [47272.471059] BTRFS info (device mmcblk0p3): relocating block group > 35778461696 flags metadata > [47280.530041] BTRFS info (device mmcblk0p3): found 3199 extents > [47280.735667] BTRFS info (device mmcblk0p3): relocating block group > 34704719872 flags data > [47301.460523] BTRFS info (device mmcblk0p3): relocating block group > 37221302272 flags data > [47306.038404] BTRFS info (device mmcblk0p3): found 5 extents > [47306.481371] BTRFS info (device mmcblk0p3): found 5 extents > [47306.673135] BTRFS info (device mmcblk0p3): relocating block group > 37187747840 flags system > [47306.874874] BTRFS info (device mmcblk0p3): found 1 extents > [47307.073288] BTRFS info (device mmcblk0p3): relocating block group > 34704719872 flags data > [47371.059074] BTRFS info (device mmcblk0p3): found 16258 extents > [47388.191208] BTRFS info (device mmcblk0p3): found 16094 extents > [47388.985462] BTRFS info (device mmcblk0p3): relocating block group > 31215058944 flags metadata > [47439.164167] BTRFS info (device mmcblk0p3): found 7378 extents > [47440.163793] BTRFS info (device mmcblk0p3): relocating block group > 30141317120 flags data > [47593.239048] BTRFS info (device mmcblk0p3): found 15636 extents > [47618.389357] BTRFS info (device mmcblk0p3): found 15634 extents > [47620.020122] BTRFS info (device mmcblk0p3): relocating block group > 29012000768 flags data > [47637.708444] BTRFS info (device mmcblk0p3): found 1154 extents > [47639.757342] BTRFS info (device mmcblk0p3): found 1154 extents > [47640.375483] BTRFS info (device mmcblk0p3): relocating block group > 27938258944 flags data > [47743.312441] BTRFS info (device mmcblk0p3): found 17009 extents > [47756.928461] BTRFS info (device mmcblk0p3): found 17005 extents > [47757.607346] BTRFS info (device mmcblk0p3): relocating block group > 9416212480 flags metadata > [47825.819449] BTRFS info (device mmcblk0p3): found 11503 extents > [47826.465926] BTRFS info (device mmcblk0p3): relocating block group > 8342470656 flags data > [47900.754062] BTRFS info (device mmcblk0p3): found 20607 extents > [47928.061348] BTRFS info (device mmcblk0p3): found 20607 extents > [47929.125750] BTRFS info (device mmcblk0p3): relocating block group > 4852809728 flags metadata > [47993.308492] BTRFS info (device mmcblk0p3): found 13214 extents > [47994.883308] BTRFS info (device mmcblk0p3): relocating block group > 3779067904 flags data > [48108.871895] BTRFS info (device mmcblk0p3): found 13256 extents > [48124.623607] BTRFS info (device mmcblk0p3): found 13255 extents > [48125.156150] BTRFS info (device mmcblk0p3): relocating block group > 3510632448 flags metadata > [48191.030178] BTRFS info (device mmcblk0p3): found 12394 extents > [48193.202016] BTRFS info (device mmcblk0p3): relocating block group > 2436890624 flags data > [48347.733120] BTRFS info (device mmcblk0p3): found 22889 extents > [48371.149135] BTRFS info (device mmcblk0p3): found 22889 extents > [48373.723037] BTRFS info (device mmcblk0p3): relocating block group > 20971520 flags metadata > [48449.367016] BTRFS info (device mmcblk0p3): found 13755 extents > [48451.058818] BTRFS info (device mmcblk0p3): relocating block group > 12582912 flags data > [48453.657685] BTRFS info (device mmcblk0p3): found 726 extents > [48461.188484] BTRFS info (device mmcblk0p3): found 726 extents > [48463.496116] BTRFS info (device mmcblk0p3): relocating block group > 4194304 flags metadata > [48476.405722] BTRFS info (device mmcblk0p3): found 403 extents > [48479.254106] BTRFS info (device mmcblk0p3): 17 enospc errors during balance > > There is this enospc errors, can anyone help me in understanding what > is going on? > Bye > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 11:54 ` Qu Wenruo @ 2018-08-28 13:07 ` Menion 2018-08-28 13:22 ` Qu Wenruo 0 siblings, 1 reply; 15+ messages in thread From: Menion @ 2018-08-28 13:07 UTC (permalink / raw) To: quwenruo.btrfs; +Cc: linux-btrfs Ok, thanks for your replay This is a root FS, how can I defragment it? If I try to launch it I get this output: menion@Menionubuntu:~$ sudo btrfs filesystem defragment -r / ERROR: defrag failed on /bin/bash: Text file busy ERROR: defrag failed on /bin/dash: Text file busy ERROR: defrag failed on /bin/btrfs: Text file busy ERROR: defrag failed on /lib/systemd/systemd: Text file busy ERROR: defrag failed on /lib/systemd/systemd-journald: Text file busy ERROR: defrag failed on /lib/systemd/systemd-logind: Text file busy ERROR: defrag failed on /lib/systemd/systemd-resolved: Text file busy ERROR: defrag failed on /lib/systemd/systemd-timesyncd: Text file busy ERROR: defrag failed on /lib/systemd/systemd-udevd: Text file busy ERROR: defrag failed on /lib/x86_64-linux-gnu/ld-2.27.so: Text file busy Bye Il giorno mar 28 ago 2018 alle ore 13:54 Qu Wenruo <quwenruo.btrfs@gmx.com> ha scritto: > > > > On 2018/8/28 下午5:34, Menion wrote: > > Hi all > > I have run a distro upgrade on my Ubuntu 16.04 that runs ppa kernel > > 4.17.2 with btrfsprogs 4.17.0 > > The root filesystem is BTRFS single created by the Ubuntu Xenial > > installer (so on kernel 4.4.0) on an internal mmc, located in > > /dev/mmcblk0p3 > > After the upgrade I have cleaned apt cache and checked the free space, > > the results were odd, following some checks (shrinked), followed by > > more comments: > > > > root@Menionubuntu:/home/menion# df -h > > Filesystem Size Used Avail Use% Mounted on > > ............................................................... > > /dev/mmcblk0p3 28G 24G 2.7G 90% / > > > > root@Menionubuntu:/home/menion# btrfs fi usage /usr > > Overall: > > Device size: 27.07GiB > > Device allocated: 25.28GiB > > Device unallocated: 1.79GiB > > Device missing: 0.00B > > Used: 23.88GiB > > Free (estimated): 2.69GiB (min: 2.69GiB) > > Data ratio: 1.00 > > Metadata ratio: 1.00 > > Global reserve: 72.94MiB (used: 0.00B) > > > > Data,single: Size:24.00GiB, Used:23.10GiB > > /dev/mmcblk0p3 24.00GiB > > > > Metadata,single: Size:1.25GiB, Used:801.97MiB > > /dev/mmcblk0p3 1.25GiB > > > > System,single: Size:32.00MiB, Used:16.00KiB > > /dev/mmcblk0p3 32.00MiB > > > > Unallocated: > > /dev/mmcblk0p3 1.79GiB > > > > root@Menionubuntu:/home/menion# btrfs fi df /mnt > > Data, single: total=24.00GiB, used=23.10GiB > > System, single: total=32.00MiB, used=16.00KiB > > Metadata, single: total=1.25GiB, used=801.92MiB > > GlobalReserve, single: total=72.89MiB, used=0.00B > > > > The different ways to check the free space are coherent, but if I > > check the directories usage on root, surprise: > > > > root@Menionubuntu:/home/menion# du -x -s -h /* > > 17M /bin > > 189M /boot > > 36K /dead.letter > > 0 /dev > > 18M /etc > > 6.1G /home > > 4.0K /initrd.img > > 4.0K /initrd.img.old > > 791M /lib > > 8.3M /lib64 > > 0 /media > > 4.0K /mnt > > 0 /opt > > du: cannot access '/proc/24660/task/24660/fd/3': No such file or directory > > du: cannot access '/proc/24660/task/24660/fdinfo/3': No such file or directory > > du: cannot access '/proc/24660/fd/3': No such file or directory > > du: cannot access '/proc/24660/fdinfo/3': No such file or directory > > 0 /proc > > 2.9M /root > > 2.9M /run > > 17M /sbin > > 4.0K /snap > > 0 /srv > > 0 /sys > > 0 /tmp > > 6.1G /usr > > 2.0G /var > > 4.0K /vmlinuz > > 4.0K /vmlinuz.old > > 4.0K /webmin-setup.out > > > > The computed usage is 15Gb which is what I expected, so there are 9Gb > > lost somewhere. > > I have run scrub and then full balance with: > > I think this is related to btrfs CoW and extent booking. > > One simple example would be: > > xfs_io -f -c "pwrite 0 128k" -c "sync" -c "pwrite 0 64K" \ > /mnt/btrfs/file1 > > The result "/mnt/btrfs/file1" will only be sized 128K in du, but it > on-disk usage is 128K + 64K. > > The first 128K is the data written by the first "pwrite" command, it > caused a full 128K extent on disk. > Then the 2nd pwrite command also created a new 64K extent, which is the > default data CoW behavior. > The first half of the original 128K extent is not used by anyone, but it > still takes space. > > Above btrfs extent booking behavior could cause a lot of wasted space > even there is only one single subvolume without any snapshot. > > In that case, instead of balance, defrag should be your friend to free > up some space. > > Thanks, > Qu > > > > > btrfs scrub start / > > btrfs balance start / > > The balance freed 100Mb of space, it was running in background so I > > have checked dmesg when "btrfs balance status" said that was completed > > > > dmesg of balance: > > > > [47264.250141] BTRFS info (device mmcblk0p3): relocating block group > > 37154193408 flags system > > [47264.592082] BTRFS info (device mmcblk0p3): relocating block group > > 36046897152 flags data > > [47271.499809] BTRFS info (device mmcblk0p3): found 73 extents > > [47272.329921] BTRFS info (device mmcblk0p3): found 60 extents > > [47272.471059] BTRFS info (device mmcblk0p3): relocating block group > > 35778461696 flags metadata > > [47280.530041] BTRFS info (device mmcblk0p3): found 3199 extents > > [47280.735667] BTRFS info (device mmcblk0p3): relocating block group > > 34704719872 flags data > > [47301.460523] BTRFS info (device mmcblk0p3): relocating block group > > 37221302272 flags data > > [47306.038404] BTRFS info (device mmcblk0p3): found 5 extents > > [47306.481371] BTRFS info (device mmcblk0p3): found 5 extents > > [47306.673135] BTRFS info (device mmcblk0p3): relocating block group > > 37187747840 flags system > > [47306.874874] BTRFS info (device mmcblk0p3): found 1 extents > > [47307.073288] BTRFS info (device mmcblk0p3): relocating block group > > 34704719872 flags data > > [47371.059074] BTRFS info (device mmcblk0p3): found 16258 extents > > [47388.191208] BTRFS info (device mmcblk0p3): found 16094 extents > > [47388.985462] BTRFS info (device mmcblk0p3): relocating block group > > 31215058944 flags metadata > > [47439.164167] BTRFS info (device mmcblk0p3): found 7378 extents > > [47440.163793] BTRFS info (device mmcblk0p3): relocating block group > > 30141317120 flags data > > [47593.239048] BTRFS info (device mmcblk0p3): found 15636 extents > > [47618.389357] BTRFS info (device mmcblk0p3): found 15634 extents > > [47620.020122] BTRFS info (device mmcblk0p3): relocating block group > > 29012000768 flags data > > [47637.708444] BTRFS info (device mmcblk0p3): found 1154 extents > > [47639.757342] BTRFS info (device mmcblk0p3): found 1154 extents > > [47640.375483] BTRFS info (device mmcblk0p3): relocating block group > > 27938258944 flags data > > [47743.312441] BTRFS info (device mmcblk0p3): found 17009 extents > > [47756.928461] BTRFS info (device mmcblk0p3): found 17005 extents > > [47757.607346] BTRFS info (device mmcblk0p3): relocating block group > > 9416212480 flags metadata > > [47825.819449] BTRFS info (device mmcblk0p3): found 11503 extents > > [47826.465926] BTRFS info (device mmcblk0p3): relocating block group > > 8342470656 flags data > > [47900.754062] BTRFS info (device mmcblk0p3): found 20607 extents > > [47928.061348] BTRFS info (device mmcblk0p3): found 20607 extents > > [47929.125750] BTRFS info (device mmcblk0p3): relocating block group > > 4852809728 flags metadata > > [47993.308492] BTRFS info (device mmcblk0p3): found 13214 extents > > [47994.883308] BTRFS info (device mmcblk0p3): relocating block group > > 3779067904 flags data > > [48108.871895] BTRFS info (device mmcblk0p3): found 13256 extents > > [48124.623607] BTRFS info (device mmcblk0p3): found 13255 extents > > [48125.156150] BTRFS info (device mmcblk0p3): relocating block group > > 3510632448 flags metadata > > [48191.030178] BTRFS info (device mmcblk0p3): found 12394 extents > > [48193.202016] BTRFS info (device mmcblk0p3): relocating block group > > 2436890624 flags data > > [48347.733120] BTRFS info (device mmcblk0p3): found 22889 extents > > [48371.149135] BTRFS info (device mmcblk0p3): found 22889 extents > > [48373.723037] BTRFS info (device mmcblk0p3): relocating block group > > 20971520 flags metadata > > [48449.367016] BTRFS info (device mmcblk0p3): found 13755 extents > > [48451.058818] BTRFS info (device mmcblk0p3): relocating block group > > 12582912 flags data > > [48453.657685] BTRFS info (device mmcblk0p3): found 726 extents > > [48461.188484] BTRFS info (device mmcblk0p3): found 726 extents > > [48463.496116] BTRFS info (device mmcblk0p3): relocating block group > > 4194304 flags metadata > > [48476.405722] BTRFS info (device mmcblk0p3): found 403 extents > > [48479.254106] BTRFS info (device mmcblk0p3): 17 enospc errors during balance > > > > There is this enospc errors, can anyone help me in understanding what > > is going on? > > Bye > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 13:07 ` Menion @ 2018-08-28 13:22 ` Qu Wenruo 0 siblings, 0 replies; 15+ messages in thread From: Qu Wenruo @ 2018-08-28 13:22 UTC (permalink / raw) To: Menion; +Cc: linux-btrfs [-- Attachment #1.1: Type: text/plain, Size: 10048 bytes --] On 2018/8/28 下午9:07, Menion wrote: > Ok, thanks for your replay > This is a root FS, how can I defragment it? If it's a rootfs, then it's a little strange. Normally package manager should overwrite the whole file during package update transaction, thus the extent booking doesn't happen as frequent as other workload. One solution is booting from other device, and try defrag. BTW, is there any snapshots in the fs? One way to determine it is by btrfs ins dump-tree: # btrfs ins dump-tree -t root <device> Above command can be executed on mounted device, and above root tree dump doesn't contain confidential info except subvolume names. If there is no extra subvolumes at all, then try to defrag may make sense. Thanks, Qu > If I try to launch it I get this output: > > menion@Menionubuntu:~$ sudo btrfs filesystem defragment -r / > ERROR: defrag failed on /bin/bash: Text file busy > ERROR: defrag failed on /bin/dash: Text file busy > ERROR: defrag failed on /bin/btrfs: Text file busy > ERROR: defrag failed on /lib/systemd/systemd: Text file busy > ERROR: defrag failed on /lib/systemd/systemd-journald: Text file busy > ERROR: defrag failed on /lib/systemd/systemd-logind: Text file busy > ERROR: defrag failed on /lib/systemd/systemd-resolved: Text file busy > ERROR: defrag failed on /lib/systemd/systemd-timesyncd: Text file busy > ERROR: defrag failed on /lib/systemd/systemd-udevd: Text file busy > ERROR: defrag failed on /lib/x86_64-linux-gnu/ld-2.27.so: Text file busy > > Bye > Il giorno mar 28 ago 2018 alle ore 13:54 Qu Wenruo > <quwenruo.btrfs@gmx.com> ha scritto: >> >> >> >> On 2018/8/28 下午5:34, Menion wrote: >>> Hi all >>> I have run a distro upgrade on my Ubuntu 16.04 that runs ppa kernel >>> 4.17.2 with btrfsprogs 4.17.0 >>> The root filesystem is BTRFS single created by the Ubuntu Xenial >>> installer (so on kernel 4.4.0) on an internal mmc, located in >>> /dev/mmcblk0p3 >>> After the upgrade I have cleaned apt cache and checked the free space, >>> the results were odd, following some checks (shrinked), followed by >>> more comments: >>> >>> root@Menionubuntu:/home/menion# df -h >>> Filesystem Size Used Avail Use% Mounted on >>> ............................................................... >>> /dev/mmcblk0p3 28G 24G 2.7G 90% / >>> >>> root@Menionubuntu:/home/menion# btrfs fi usage /usr >>> Overall: >>> Device size: 27.07GiB >>> Device allocated: 25.28GiB >>> Device unallocated: 1.79GiB >>> Device missing: 0.00B >>> Used: 23.88GiB >>> Free (estimated): 2.69GiB (min: 2.69GiB) >>> Data ratio: 1.00 >>> Metadata ratio: 1.00 >>> Global reserve: 72.94MiB (used: 0.00B) >>> >>> Data,single: Size:24.00GiB, Used:23.10GiB >>> /dev/mmcblk0p3 24.00GiB >>> >>> Metadata,single: Size:1.25GiB, Used:801.97MiB >>> /dev/mmcblk0p3 1.25GiB >>> >>> System,single: Size:32.00MiB, Used:16.00KiB >>> /dev/mmcblk0p3 32.00MiB >>> >>> Unallocated: >>> /dev/mmcblk0p3 1.79GiB >>> >>> root@Menionubuntu:/home/menion# btrfs fi df /mnt >>> Data, single: total=24.00GiB, used=23.10GiB >>> System, single: total=32.00MiB, used=16.00KiB >>> Metadata, single: total=1.25GiB, used=801.92MiB >>> GlobalReserve, single: total=72.89MiB, used=0.00B >>> >>> The different ways to check the free space are coherent, but if I >>> check the directories usage on root, surprise: >>> >>> root@Menionubuntu:/home/menion# du -x -s -h /* >>> 17M /bin >>> 189M /boot >>> 36K /dead.letter >>> 0 /dev >>> 18M /etc >>> 6.1G /home >>> 4.0K /initrd.img >>> 4.0K /initrd.img.old >>> 791M /lib >>> 8.3M /lib64 >>> 0 /media >>> 4.0K /mnt >>> 0 /opt >>> du: cannot access '/proc/24660/task/24660/fd/3': No such file or directory >>> du: cannot access '/proc/24660/task/24660/fdinfo/3': No such file or directory >>> du: cannot access '/proc/24660/fd/3': No such file or directory >>> du: cannot access '/proc/24660/fdinfo/3': No such file or directory >>> 0 /proc >>> 2.9M /root >>> 2.9M /run >>> 17M /sbin >>> 4.0K /snap >>> 0 /srv >>> 0 /sys >>> 0 /tmp >>> 6.1G /usr >>> 2.0G /var >>> 4.0K /vmlinuz >>> 4.0K /vmlinuz.old >>> 4.0K /webmin-setup.out >>> >>> The computed usage is 15Gb which is what I expected, so there are 9Gb >>> lost somewhere. >>> I have run scrub and then full balance with: >> >> I think this is related to btrfs CoW and extent booking. >> >> One simple example would be: >> >> xfs_io -f -c "pwrite 0 128k" -c "sync" -c "pwrite 0 64K" \ >> /mnt/btrfs/file1 >> >> The result "/mnt/btrfs/file1" will only be sized 128K in du, but it >> on-disk usage is 128K + 64K. >> >> The first 128K is the data written by the first "pwrite" command, it >> caused a full 128K extent on disk. >> Then the 2nd pwrite command also created a new 64K extent, which is the >> default data CoW behavior. >> The first half of the original 128K extent is not used by anyone, but it >> still takes space. >> >> Above btrfs extent booking behavior could cause a lot of wasted space >> even there is only one single subvolume without any snapshot. >> >> In that case, instead of balance, defrag should be your friend to free >> up some space. >> >> Thanks, >> Qu >> >>> >>> btrfs scrub start / >>> btrfs balance start / >>> The balance freed 100Mb of space, it was running in background so I >>> have checked dmesg when "btrfs balance status" said that was completed >>> >>> dmesg of balance: >>> >>> [47264.250141] BTRFS info (device mmcblk0p3): relocating block group >>> 37154193408 flags system >>> [47264.592082] BTRFS info (device mmcblk0p3): relocating block group >>> 36046897152 flags data >>> [47271.499809] BTRFS info (device mmcblk0p3): found 73 extents >>> [47272.329921] BTRFS info (device mmcblk0p3): found 60 extents >>> [47272.471059] BTRFS info (device mmcblk0p3): relocating block group >>> 35778461696 flags metadata >>> [47280.530041] BTRFS info (device mmcblk0p3): found 3199 extents >>> [47280.735667] BTRFS info (device mmcblk0p3): relocating block group >>> 34704719872 flags data >>> [47301.460523] BTRFS info (device mmcblk0p3): relocating block group >>> 37221302272 flags data >>> [47306.038404] BTRFS info (device mmcblk0p3): found 5 extents >>> [47306.481371] BTRFS info (device mmcblk0p3): found 5 extents >>> [47306.673135] BTRFS info (device mmcblk0p3): relocating block group >>> 37187747840 flags system >>> [47306.874874] BTRFS info (device mmcblk0p3): found 1 extents >>> [47307.073288] BTRFS info (device mmcblk0p3): relocating block group >>> 34704719872 flags data >>> [47371.059074] BTRFS info (device mmcblk0p3): found 16258 extents >>> [47388.191208] BTRFS info (device mmcblk0p3): found 16094 extents >>> [47388.985462] BTRFS info (device mmcblk0p3): relocating block group >>> 31215058944 flags metadata >>> [47439.164167] BTRFS info (device mmcblk0p3): found 7378 extents >>> [47440.163793] BTRFS info (device mmcblk0p3): relocating block group >>> 30141317120 flags data >>> [47593.239048] BTRFS info (device mmcblk0p3): found 15636 extents >>> [47618.389357] BTRFS info (device mmcblk0p3): found 15634 extents >>> [47620.020122] BTRFS info (device mmcblk0p3): relocating block group >>> 29012000768 flags data >>> [47637.708444] BTRFS info (device mmcblk0p3): found 1154 extents >>> [47639.757342] BTRFS info (device mmcblk0p3): found 1154 extents >>> [47640.375483] BTRFS info (device mmcblk0p3): relocating block group >>> 27938258944 flags data >>> [47743.312441] BTRFS info (device mmcblk0p3): found 17009 extents >>> [47756.928461] BTRFS info (device mmcblk0p3): found 17005 extents >>> [47757.607346] BTRFS info (device mmcblk0p3): relocating block group >>> 9416212480 flags metadata >>> [47825.819449] BTRFS info (device mmcblk0p3): found 11503 extents >>> [47826.465926] BTRFS info (device mmcblk0p3): relocating block group >>> 8342470656 flags data >>> [47900.754062] BTRFS info (device mmcblk0p3): found 20607 extents >>> [47928.061348] BTRFS info (device mmcblk0p3): found 20607 extents >>> [47929.125750] BTRFS info (device mmcblk0p3): relocating block group >>> 4852809728 flags metadata >>> [47993.308492] BTRFS info (device mmcblk0p3): found 13214 extents >>> [47994.883308] BTRFS info (device mmcblk0p3): relocating block group >>> 3779067904 flags data >>> [48108.871895] BTRFS info (device mmcblk0p3): found 13256 extents >>> [48124.623607] BTRFS info (device mmcblk0p3): found 13255 extents >>> [48125.156150] BTRFS info (device mmcblk0p3): relocating block group >>> 3510632448 flags metadata >>> [48191.030178] BTRFS info (device mmcblk0p3): found 12394 extents >>> [48193.202016] BTRFS info (device mmcblk0p3): relocating block group >>> 2436890624 flags data >>> [48347.733120] BTRFS info (device mmcblk0p3): found 22889 extents >>> [48371.149135] BTRFS info (device mmcblk0p3): found 22889 extents >>> [48373.723037] BTRFS info (device mmcblk0p3): relocating block group >>> 20971520 flags metadata >>> [48449.367016] BTRFS info (device mmcblk0p3): found 13755 extents >>> [48451.058818] BTRFS info (device mmcblk0p3): relocating block group >>> 12582912 flags data >>> [48453.657685] BTRFS info (device mmcblk0p3): found 726 extents >>> [48461.188484] BTRFS info (device mmcblk0p3): found 726 extents >>> [48463.496116] BTRFS info (device mmcblk0p3): relocating block group >>> 4194304 flags metadata >>> [48476.405722] BTRFS info (device mmcblk0p3): found 403 extents >>> [48479.254106] BTRFS info (device mmcblk0p3): 17 enospc errors during balance >>> >>> There is this enospc errors, can anyone help me in understanding what >>> is going on? >>> Bye >>> >> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 9:34 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) Menion 2018-08-28 11:54 ` Qu Wenruo @ 2018-08-28 13:47 ` Chris Murphy 2018-08-28 14:56 ` Menion 1 sibling, 1 reply; 15+ messages in thread From: Chris Murphy @ 2018-08-28 13:47 UTC (permalink / raw) To: Menion; +Cc: Btrfs BTRFS On Tue, Aug 28, 2018 at 3:34 AM, Menion <menion@gmail.com> wrote: > Hi all > I have run a distro upgrade on my Ubuntu 16.04 that runs ppa kernel > 4.17.2 with btrfsprogs 4.17.0 > The root filesystem is BTRFS single created by the Ubuntu Xenial > installer (so on kernel 4.4.0) on an internal mmc, located in > /dev/mmcblk0p3 > After the upgrade I have cleaned apt cache and checked the free space, > the results were odd, following some checks (shrinked), followed by > more comments: Do you know if you're using Timeshift? I'm not sure if it's enabled by default on Ubuntu when using Btrfs, but you may have snapshots. 'sudo btrfs sub list -at /' That should show all subvolumes (includes snapshots). > [48479.254106] BTRFS info (device mmcblk0p3): 17 enospc errors during balance Probably soft enospc errors it was able to work around. -- Chris Murphy ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 13:47 ` Chris Murphy @ 2018-08-28 14:56 ` Menion 2018-08-28 15:27 ` Noah Massey 2018-08-29 0:10 ` Chris Murphy 0 siblings, 2 replies; 15+ messages in thread From: Menion @ 2018-08-28 14:56 UTC (permalink / raw) To: Chris Murphy; +Cc: linux-btrfs [sudo] password for menion: ID gen top level path -- --- --------- ---- 257 600627 5 <FS_TREE>/@ 258 600626 5 <FS_TREE>/@home 296 599489 5 <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55 297 599489 5 <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08 298 599489 5 <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30 So, there are snapshots, right? The time stamp is when I have launched do-release-upgrade, but it didn't ask anything about snapshot, neither I asked for it. During the do-release-upgrade I got some issues due to the (very) bad behaviour of the script in remote terminal, then I have fixed everything manually and now the filesystem is operational in bionic version If it is confirmed, how can I remove the unwanted snapshot, keeping the current "visible" filesystem contents Sorry, I am still learning BTRFS and I would like to avoid mistakes Bye Il giorno mar 28 ago 2018 alle ore 15:47 Chris Murphy <lists@colorremedies.com> ha scritto: > > On Tue, Aug 28, 2018 at 3:34 AM, Menion <menion@gmail.com> wrote: > > Hi all > > I have run a distro upgrade on my Ubuntu 16.04 that runs ppa kernel > > 4.17.2 with btrfsprogs 4.17.0 > > The root filesystem is BTRFS single created by the Ubuntu Xenial > > installer (so on kernel 4.4.0) on an internal mmc, located in > > /dev/mmcblk0p3 > > After the upgrade I have cleaned apt cache and checked the free space, > > the results were odd, following some checks (shrinked), followed by > > more comments: > > Do you know if you're using Timeshift? I'm not sure if it's enabled by > default on Ubuntu when using Btrfs, but you may have snapshots. > > 'sudo btrfs sub list -at /' > > That should show all subvolumes (includes snapshots). > > > > > [48479.254106] BTRFS info (device mmcblk0p3): 17 enospc errors during balance > > Probably soft enospc errors it was able to work around. > > > -- > Chris Murphy ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 14:56 ` Menion @ 2018-08-28 15:27 ` Noah Massey 2018-08-28 15:47 ` Austin S. Hemmelgarn 2018-08-29 0:10 ` Chris Murphy 1 sibling, 1 reply; 15+ messages in thread From: Noah Massey @ 2018-08-28 15:27 UTC (permalink / raw) To: menion; +Cc: Chris Murphy, linux-btrfs On Tue, Aug 28, 2018 at 10:59 AM Menion <menion@gmail.com> wrote: > > [sudo] password for menion: > ID gen top level path > -- --- --------- ---- > 257 600627 5 <FS_TREE>/@ > 258 600626 5 <FS_TREE>/@home > 296 599489 5 > <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55 > 297 599489 5 > <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08 > 298 599489 5 > <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30 > > So, there are snapshots, right? The time stamp is when I have launched > do-release-upgrade, but it didn't ask anything about snapshot, neither > I asked for it. This is an Ubuntu thing `apt show apt-btrfs-snapshot` which "will create a btrfs snapshot of the root filesystem each time that apt installs/removes/upgrades a software package." > During the do-release-upgrade I got some issues due to the (very) bad > behaviour of the script in remote terminal, then I have fixed > everything manually and now the filesystem is operational in bionic > version > If it is confirmed, how can I remove the unwanted snapshot, keeping > the current "visible" filesystem contents By default, the package runs a weekly cron job to cleanup old snapshots. (Defaults to 90d, but you can configure that in APT::Snapshots::MaxAge) Alternatively, you can cleanup with the command yourself. Run `sudo apt-btrfs-snapshot list`, and then `sudo apt-btrfs-snapshot delete <snapshot to delete>` ~ Noah ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 15:27 ` Noah Massey @ 2018-08-28 15:47 ` Austin S. Hemmelgarn 2018-08-28 16:05 ` Noah Massey 0 siblings, 1 reply; 15+ messages in thread From: Austin S. Hemmelgarn @ 2018-08-28 15:47 UTC (permalink / raw) To: Noah Massey, menion; +Cc: Chris Murphy, linux-btrfs On 2018-08-28 11:27, Noah Massey wrote: > On Tue, Aug 28, 2018 at 10:59 AM Menion <menion@gmail.com> wrote: >> >> [sudo] password for menion: >> ID gen top level path >> -- --- --------- ---- >> 257 600627 5 <FS_TREE>/@ >> 258 600626 5 <FS_TREE>/@home >> 296 599489 5 >> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55 >> 297 599489 5 >> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08 >> 298 599489 5 >> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30 >> >> So, there are snapshots, right? The time stamp is when I have launched >> do-release-upgrade, but it didn't ask anything about snapshot, neither >> I asked for it. > > This is an Ubuntu thing > `apt show apt-btrfs-snapshot` > which "will create a btrfs snapshot of the root filesystem each time > that apt installs/removes/upgrades a software package." Not Ubuntu, Debian. It's just that Ubuntu installs and configures the package by default, while Debian does not. This behavior in general is not specific to Debian either, a lot of distributions are either working on or already have this type of functionality, because it's the only sane and correct way to handle updates short of rebuilding the entire system from scratch. > >> During the do-release-upgrade I got some issues due to the (very) bad >> behaviour of the script in remote terminal, then I have fixed >> everything manually and now the filesystem is operational in bionic >> version >> If it is confirmed, how can I remove the unwanted snapshot, keeping >> the current "visible" filesystem contents > > By default, the package runs a weekly cron job to cleanup old > snapshots. (Defaults to 90d, but you can configure that in > APT::Snapshots::MaxAge) Alternatively, you can cleanup with the > command yourself. Run `sudo apt-btrfs-snapshot list`, and then `sudo > apt-btrfs-snapshot delete <snapshot to delete>` ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 15:47 ` Austin S. Hemmelgarn @ 2018-08-28 16:05 ` Noah Massey 2018-08-28 17:07 ` Austin S. Hemmelgarn 0 siblings, 1 reply; 15+ messages in thread From: Noah Massey @ 2018-08-28 16:05 UTC (permalink / raw) To: Austin S. Hemmelgarn; +Cc: menion, Chris Murphy, linux-btrfs On Tue, Aug 28, 2018 at 11:47 AM Austin S. Hemmelgarn <ahferroin7@gmail.com> wrote: > > On 2018-08-28 11:27, Noah Massey wrote: > > On Tue, Aug 28, 2018 at 10:59 AM Menion <menion@gmail.com> wrote: > >> > >> [sudo] password for menion: > >> ID gen top level path > >> -- --- --------- ---- > >> 257 600627 5 <FS_TREE>/@ > >> 258 600626 5 <FS_TREE>/@home > >> 296 599489 5 > >> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55 > >> 297 599489 5 > >> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08 > >> 298 599489 5 > >> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30 > >> > >> So, there are snapshots, right? The time stamp is when I have launched > >> do-release-upgrade, but it didn't ask anything about snapshot, neither > >> I asked for it. > > > > This is an Ubuntu thing > > `apt show apt-btrfs-snapshot` > > which "will create a btrfs snapshot of the root filesystem each time > > that apt installs/removes/upgrades a software package." > Not Ubuntu, Debian. It's just that Ubuntu installs and configures the > package by default, while Debian does not. Ubuntu also maintains the package, and I did not find it in Debian repositories. I think it's also worth mentioning that these snapshots were created by the do-release-upgrade script using the package directly, not as a result of the apt configuration. Meaning if you do not want a snapshot taken prior to upgrade, you have to remove the apt-btrfs-snapshot package prior to running the upgrade script. You cannot just update /etc/apt/apt.conf.d/80-btrfs-snapshot > > This behavior in general is not specific to Debian either, a lot of > distributions are either working on or already have this type of > functionality, because it's the only sane and correct way to handle > updates short of rebuilding the entire system from scratch. Yup. Everyone in their own way, plus all the home-brews. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 16:05 ` Noah Massey @ 2018-08-28 17:07 ` Austin S. Hemmelgarn 2018-08-28 17:25 ` Menion 0 siblings, 1 reply; 15+ messages in thread From: Austin S. Hemmelgarn @ 2018-08-28 17:07 UTC (permalink / raw) To: Noah Massey; +Cc: menion, Chris Murphy, linux-btrfs On 2018-08-28 12:05, Noah Massey wrote: > On Tue, Aug 28, 2018 at 11:47 AM Austin S. Hemmelgarn > <ahferroin7@gmail.com> wrote: >> >> On 2018-08-28 11:27, Noah Massey wrote: >>> On Tue, Aug 28, 2018 at 10:59 AM Menion <menion@gmail.com> wrote: >>>> >>>> [sudo] password for menion: >>>> ID gen top level path >>>> -- --- --------- ---- >>>> 257 600627 5 <FS_TREE>/@ >>>> 258 600626 5 <FS_TREE>/@home >>>> 296 599489 5 >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55 >>>> 297 599489 5 >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08 >>>> 298 599489 5 >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30 >>>> >>>> So, there are snapshots, right? The time stamp is when I have launched >>>> do-release-upgrade, but it didn't ask anything about snapshot, neither >>>> I asked for it. >>> >>> This is an Ubuntu thing >>> `apt show apt-btrfs-snapshot` >>> which "will create a btrfs snapshot of the root filesystem each time >>> that apt installs/removes/upgrades a software package." >> Not Ubuntu, Debian. It's just that Ubuntu installs and configures the >> package by default, while Debian does not. > > Ubuntu also maintains the package, and I did not find it in Debian repositories. > I think it's also worth mentioning that these snapshots were created > by the do-release-upgrade script using the package directly, not as a > result of the apt configuration. Meaning if you do not want a snapshot > taken prior to upgrade, you have to remove the apt-btrfs-snapshot > package prior to running the upgrade script. You cannot just update > /etc/apt/apt.conf.d/80-btrfs-snapshot Hmm... I could have sworn that it was in the Debian repositories. That said, it's kind of stupid that the snapshot is not trivially optional for a release upgrade. Yes, that's where it's arguably the most important, but it's still kind of stupid to have to remove a package to get rid of that behavior and then reinstall it again afterwards. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 17:07 ` Austin S. Hemmelgarn @ 2018-08-28 17:25 ` Menion 2018-08-28 18:06 ` Noah Massey 0 siblings, 1 reply; 15+ messages in thread From: Menion @ 2018-08-28 17:25 UTC (permalink / raw) To: ahferroin7; +Cc: noah.massey, Chris Murphy, linux-btrfs Ok, I have removed the snapshot and the free expected space is here, thank you! As a side note: apt-btrfs-snapshot was not installed, but it is present in Ubuntu repository and I have used it (and I like the idea of automatic snapshot during upgrade) This means that the do-release-upgrade does it's own job on BTRFS, silently which I believe is not good from the usability perspective, just google it, there is no mention of this behaviour Il giorno mar 28 ago 2018 alle ore 19:07 Austin S. Hemmelgarn <ahferroin7@gmail.com> ha scritto: > > On 2018-08-28 12:05, Noah Massey wrote: > > On Tue, Aug 28, 2018 at 11:47 AM Austin S. Hemmelgarn > > <ahferroin7@gmail.com> wrote: > >> > >> On 2018-08-28 11:27, Noah Massey wrote: > >>> On Tue, Aug 28, 2018 at 10:59 AM Menion <menion@gmail.com> wrote: > >>>> > >>>> [sudo] password for menion: > >>>> ID gen top level path > >>>> -- --- --------- ---- > >>>> 257 600627 5 <FS_TREE>/@ > >>>> 258 600626 5 <FS_TREE>/@home > >>>> 296 599489 5 > >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55 > >>>> 297 599489 5 > >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08 > >>>> 298 599489 5 > >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30 > >>>> > >>>> So, there are snapshots, right? The time stamp is when I have launched > >>>> do-release-upgrade, but it didn't ask anything about snapshot, neither > >>>> I asked for it. > >>> > >>> This is an Ubuntu thing > >>> `apt show apt-btrfs-snapshot` > >>> which "will create a btrfs snapshot of the root filesystem each time > >>> that apt installs/removes/upgrades a software package." > >> Not Ubuntu, Debian. It's just that Ubuntu installs and configures the > >> package by default, while Debian does not. > > > > Ubuntu also maintains the package, and I did not find it in Debian repositories. > > I think it's also worth mentioning that these snapshots were created > > by the do-release-upgrade script using the package directly, not as a > > result of the apt configuration. Meaning if you do not want a snapshot > > taken prior to upgrade, you have to remove the apt-btrfs-snapshot > > package prior to running the upgrade script. You cannot just update > > /etc/apt/apt.conf.d/80-btrfs-snapshot > Hmm... I could have sworn that it was in the Debian repositories. > > That said, it's kind of stupid that the snapshot is not trivially > optional for a release upgrade. Yes, that's where it's arguably the > most important, but it's still kind of stupid to have to remove a > package to get rid of that behavior and then reinstall it again afterwards. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 17:25 ` Menion @ 2018-08-28 18:06 ` Noah Massey [not found] ` <CAJVZm6dpfQghX+cCo=LkqZMAtFfCMKtq+XHpNGb6wH8z8eMcQA@mail.gmail.com> 0 siblings, 1 reply; 15+ messages in thread From: Noah Massey @ 2018-08-28 18:06 UTC (permalink / raw) To: menion; +Cc: Austin S. Hemmelgarn, Chris Murphy, linux-btrfs On Tue, Aug 28, 2018 at 1:25 PM Menion <menion@gmail.com> wrote: > > Ok, I have removed the snapshot and the free expected space is here, thank you! > As a side note: apt-btrfs-snapshot was not installed, but it is > present in Ubuntu repository and I have used it (and I like the idea > of automatic snapshot during upgrade) > This means that the do-release-upgrade does it's own job on BTRFS, > silently which I believe is not good from the usability perspective, You are correct. DistUpgradeController.py from python3-distupgrade imports 'apt_btrfs_snapshot', which I read as coming from /usr/lib/python3/dist-packages/apt_btrfs_snapshot.py, supplied by apt-btrfs-snapshot, but I missed the fact that python3-distupgrade ships its own /usr/lib/python3/dist-packages/DistUpgrade/apt_btrfs_snapshot.py So now it looks like that cannot be easily disabled, and without the apt-btrfs-snapshot package scheduling cleanups it's not ever automatically removed? > just google it, there is no mention of this behaviour > Il giorno mar 28 ago 2018 alle ore 19:07 Austin S. Hemmelgarn > <ahferroin7@gmail.com> ha scritto: > > > > On 2018-08-28 12:05, Noah Massey wrote: > > > On Tue, Aug 28, 2018 at 11:47 AM Austin S. Hemmelgarn > > > <ahferroin7@gmail.com> wrote: > > >> > > >> On 2018-08-28 11:27, Noah Massey wrote: > > >>> On Tue, Aug 28, 2018 at 10:59 AM Menion <menion@gmail.com> wrote: > > >>>> > > >>>> [sudo] password for menion: > > >>>> ID gen top level path > > >>>> -- --- --------- ---- > > >>>> 257 600627 5 <FS_TREE>/@ > > >>>> 258 600626 5 <FS_TREE>/@home > > >>>> 296 599489 5 > > >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55 > > >>>> 297 599489 5 > > >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08 > > >>>> 298 599489 5 > > >>>> <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30 > > >>>> > > >>>> So, there are snapshots, right? The time stamp is when I have launched > > >>>> do-release-upgrade, but it didn't ask anything about snapshot, neither > > >>>> I asked for it. > > >>> > > >>> This is an Ubuntu thing > > >>> `apt show apt-btrfs-snapshot` > > >>> which "will create a btrfs snapshot of the root filesystem each time > > >>> that apt installs/removes/upgrades a software package." > > >> Not Ubuntu, Debian. It's just that Ubuntu installs and configures the > > >> package by default, while Debian does not. > > > > > > Ubuntu also maintains the package, and I did not find it in Debian repositories. > > > I think it's also worth mentioning that these snapshots were created > > > by the do-release-upgrade script using the package directly, not as a > > > result of the apt configuration. Meaning if you do not want a snapshot > > > taken prior to upgrade, you have to remove the apt-btrfs-snapshot > > > package prior to running the upgrade script. You cannot just update > > > /etc/apt/apt.conf.d/80-btrfs-snapshot > > Hmm... I could have sworn that it was in the Debian repositories. > > > > That said, it's kind of stupid that the snapshot is not trivially > > optional for a release upgrade. Yes, that's where it's arguably the > > most important, but it's still kind of stupid to have to remove a > > package to get rid of that behavior and then reinstall it again afterwards. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <CAJVZm6dpfQghX+cCo=LkqZMAtFfCMKtq+XHpNGb6wH8z8eMcQA@mail.gmail.com>]
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) [not found] ` <CAJVZm6dpfQghX+cCo=LkqZMAtFfCMKtq+XHpNGb6wH8z8eMcQA@mail.gmail.com> @ 2018-08-28 19:47 ` Austin S. Hemmelgarn 2018-08-29 0:16 ` Chris Murphy 1 sibling, 0 replies; 15+ messages in thread From: Austin S. Hemmelgarn @ 2018-08-28 19:47 UTC (permalink / raw) To: Menion, Noah Massey; +Cc: Chris Murphy, linux-btrfs On 2018-08-28 15:14, Menion wrote: > You are correct, indeed in order to cleanup you need > > 1) someone realize that snapshots have been created > 2) apt-brtfs-snapshot is manually installed on the system Your second requirement is only needed if you want the nice automated cleanup. There's absolutely nothing preventing you from manually removing the snapshots. > > Assuming also that the snapshots created during do-release-upgrade are > managed for auto cleanup > > Il martedì 28 agosto 2018, Noah Massey <noah.massey@gmail.com > <mailto:noah.massey@gmail.com>> ha scritto: > > On Tue, Aug 28, 2018 at 1:25 PM Menion <menion@gmail.com > <mailto:menion@gmail.com>> wrote: > > > > Ok, I have removed the snapshot and the free expected space is > here, thank you! > > As a side note: apt-btrfs-snapshot was not installed, but it is > > present in Ubuntu repository and I have used it (and I like the idea > > of automatic snapshot during upgrade) > > This means that the do-release-upgrade does it's own job on BTRFS, > > silently which I believe is not good from the usability perspective, > > You are correct. DistUpgradeController.py from python3-distupgrade > imports 'apt_btrfs_snapshot', which I read as coming from > /usr/lib/python3/dist-packages/apt_btrfs_snapshot.py, supplied by > apt-btrfs-snapshot, but I missed the fact that python3-distupgrade > ships its own > /usr/lib/python3/dist-packages/DistUpgrade/apt_btrfs_snapshot.py > > So now it looks like that cannot be easily disabled, and without the > apt-btrfs-snapshot package scheduling cleanups it's not ever > automatically removed? > > > just google it, there is no mention of this behaviour > > Il giorno mar 28 ago 2018 alle ore 19:07 Austin S. Hemmelgarn > > <ahferroin7@gmail.com <mailto:ahferroin7@gmail.com>> ha scritto: > > > > > > On 2018-08-28 12:05, Noah Massey wrote: > > > > On Tue, Aug 28, 2018 at 11:47 AM Austin S. Hemmelgarn > > > > <ahferroin7@gmail.com <mailto:ahferroin7@gmail.com>> wrote: > > > >> > > > >> On 2018-08-28 11:27, Noah Massey wrote: > > > >>> On Tue, Aug 28, 2018 at 10:59 AM Menion <menion@gmail.com > <mailto:menion@gmail.com>> wrote: > > > >>>> > > > >>>> [sudo] password for menion: > > > >>>> ID gen top level path > > > >>>> -- --- --------- ---- > > > >>>> 257 600627 5 <FS_TREE>/@ > > > >>>> 258 600626 5 <FS_TREE>/@home > > > >>>> 296 599489 5 > > > >>>> > <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55 > > > >>>> 297 599489 5 > > > >>>> > <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08 > > > >>>> 298 599489 5 > > > >>>> > <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30 > > > >>>> > > > >>>> So, there are snapshots, right? The time stamp is when I > have launched > > > >>>> do-release-upgrade, but it didn't ask anything about > snapshot, neither > > > >>>> I asked for it. > > > >>> > > > >>> This is an Ubuntu thing > > > >>> `apt show apt-btrfs-snapshot` > > > >>> which "will create a btrfs snapshot of the root filesystem > each time > > > >>> that apt installs/removes/upgrades a software package." > > > >> Not Ubuntu, Debian. It's just that Ubuntu installs and > configures the > > > >> package by default, while Debian does not. > > > > > > > > Ubuntu also maintains the package, and I did not find it in > Debian repositories. > > > > I think it's also worth mentioning that these snapshots were > created > > > > by the do-release-upgrade script using the package directly, > not as a > > > > result of the apt configuration. Meaning if you do not want a > snapshot > > > > taken prior to upgrade, you have to remove the apt-btrfs-snapshot > > > > package prior to running the upgrade script. You cannot just > update > > > > /etc/apt/apt.conf.d/80-btrfs-snapshot > > > Hmm... I could have sworn that it was in the Debian repositories. > > > > > > That said, it's kind of stupid that the snapshot is not trivially > > > optional for a release upgrade. Yes, that's where it's > arguably the > > > most important, but it's still kind of stupid to have to remove a > > > package to get rid of that behavior and then reinstall it again > afterwards. > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) [not found] ` <CAJVZm6dpfQghX+cCo=LkqZMAtFfCMKtq+XHpNGb6wH8z8eMcQA@mail.gmail.com> 2018-08-28 19:47 ` Austin S. Hemmelgarn @ 2018-08-29 0:16 ` Chris Murphy 1 sibling, 0 replies; 15+ messages in thread From: Chris Murphy @ 2018-08-29 0:16 UTC (permalink / raw) To: Menion; +Cc: Noah Massey, Austin S. Hemmelgarn, Chris Murphy, linux-btrfs On Tue, Aug 28, 2018 at 1:14 PM, Menion <menion@gmail.com> wrote: > You are correct, indeed in order to cleanup you need > > 1) someone realize that snapshots have been created > 2) apt-brtfs-snapshot is manually installed on the system > > Assuming also that the snapshots created during do-release-upgrade are > managed for auto cleanup Ha! I should have read all the emails. Anyway, good sleuthing. I think it's a good idea to file a bug report on it, so at the least other people can fix it manually. -- Chris Murphy ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) 2018-08-28 14:56 ` Menion 2018-08-28 15:27 ` Noah Massey @ 2018-08-29 0:10 ` Chris Murphy 1 sibling, 0 replies; 15+ messages in thread From: Chris Murphy @ 2018-08-29 0:10 UTC (permalink / raw) To: Menion; +Cc: Chris Murphy, Btrfs BTRFS On Tue, Aug 28, 2018 at 8:56 AM, Menion <menion@gmail.com> wrote: > [sudo] password for menion: > ID gen top level path > -- --- --------- ---- > 257 600627 5 <FS_TREE>/@ > 258 600626 5 <FS_TREE>/@home > 296 599489 5 > <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55 > 297 599489 5 > <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:30:08 > 298 599489 5 > <FS_TREE>/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:33:30 > > So, there are snapshots, right? Yep. So you can use 'sudo btrfs fi du -s <pathtosnapshot>' to get a report on how much exclusive space is being used by each of those snapshots and I'll bet it all adds up to about 10G or whatever you're missing. >The time stamp is when I have launched > do-release-upgrade, but it didn't ask anything about snapshot, neither > I asked for it. Yep, not sure what's creating them or what the cleanup policy is (if there is one). So it's worth asking in an Ubuntu forum what these snapshots are where they came from and what cleans them up so you don't run out of space, or otherwise how to configure it if you want more space just because. I mean, it's a neat idea. But also it needs to clean up after itself if for no other reason than to avoid user confusion :-) > If it is confirmed, how can I remove the unwanted snapshot, keeping > the current "visible" filesystem contents > Sorry, I am still learning BTRFS and I would like to avoid mistakes > Bye You can definitely use Btrfs specific tools to get rid of the snapshots and not piss off Btrfs at all. However, if you delete them behind the back of the thing that created them in the first place, it might get pissed off if they just suddenly go missing. Sometimes those tools want to do the cleanups because it's tracking the snapshots and what their purpose is. So if they just go away, it's like having the rug pulled out from under them. Anyway: 'sudo btrfs sub del <pathtosubvolume>' will delete it. Also, I can't tell you for sure what sort of write amplification Btrfs contributes in your use case on eMMC compared to F2FS. Btrfs has a "wandering trees" problem that F2FS doesn't have as big a problem. It's not a big deal (probably) on other kinds of SSDs like SATA/SAS and NVMe. But on eMMC? If it were SD Card I'd say you can keep using Btrfs, and maybe mitigate the wandering trees with compression to reduce overall writes. But if your eMMC is soldered onto a board, I might consider F2FS instead. And Btrfs for other things. -- Chris Murphy ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-08-29 4:10 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-28 9:34 14Gb of space lost after distro upgrade on BTFS root partition (long thread with logs) Menion
2018-08-28 11:54 ` Qu Wenruo
2018-08-28 13:07 ` Menion
2018-08-28 13:22 ` Qu Wenruo
2018-08-28 13:47 ` Chris Murphy
2018-08-28 14:56 ` Menion
2018-08-28 15:27 ` Noah Massey
2018-08-28 15:47 ` Austin S. Hemmelgarn
2018-08-28 16:05 ` Noah Massey
2018-08-28 17:07 ` Austin S. Hemmelgarn
2018-08-28 17:25 ` Menion
2018-08-28 18:06 ` Noah Massey
[not found] ` <CAJVZm6dpfQghX+cCo=LkqZMAtFfCMKtq+XHpNGb6wH8z8eMcQA@mail.gmail.com>
2018-08-28 19:47 ` Austin S. Hemmelgarn
2018-08-29 0:16 ` Chris Murphy
2018-08-29 0:10 ` Chris Murphy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.