Have cleared out all snapper images (except 0 + 1), even though I really don’t know how snapper works - used: snapper rm x-xx, but still showing 100% usage on /.
Drive is approx 72GB, /usr shows as about 16.6GB, /home is on a separate partition.
Thought it could be exploding log files, but nothing obvious…
First noticed when doing zypper dup, and it failed towards the end.
john@boss:~> sudo btrfs fi du -s /.snapshots
[sudo] password for root:
Total Exclusive Set shared Filename
29.43GiB 944.00KiB 14.72GiB /.snapshots
If I run filelight, I ‘think’ it’s telling me I have a 16.8GB disk, and /usr is consuming 16.6GB of that??
Thanks.
john@BossUbunt:/$ df -h /dev/sda3
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 72G 70G 6.9M 100% /MyMnt
john@BossUbunt:/$ sudo btrfs filesystem usage -T /MyMnt
Overall:
Device size: 71.23GiB
Device allocated: 71.23GiB
Device unallocated: 1.00MiB
Device missing: 0.00B
Used: 68.92GiB
Free (estimated): 6.81MiB (min: 6.81MiB)
Free (statfs, df): 6.81MiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 191.92MiB (used: 0.00B)
Multiple profiles: no
Data Metadata System
Id Path single DUP DUP Unallocated
-- --------- -------- -------- -------- -----------
1 /dev/sda3 61.17GiB 10.00GiB 64.00MiB 1.00MiB
-- --------- -------- -------- -------- -----------
Total 61.17GiB 5.00GiB 32.00MiB 1.00MiB
Used 61.16GiB 3.88GiB 16.00KiB
Currently running Ubuntu from dual-boot…
Tumbleweed / mounted at MyMnt.
btrfs check ends:
[3/7] checking free space tree
[4/7] checking fs roots
checksum verify failed on 897187840 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 897187840 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 897187840 wanted 0x00000000 found 0xb6bde3e4
bad tree block 897187840, bytenr mismatch, want=897187840, have=0
The following tree block(s) is corrupted in tree 457:
tree block bytenr: 898760704, level: 2, node key: (35310, 12, 35305)
ERROR: errors found in fs roots
found 69838114816 bytes used, error(s) found
total csum bytes: 61136716
total tree bytes: 4164894720
total fs tree bytes: 3963502592
total extent tree bytes: 125698048
btree space waste bytes: 905531387
file data blocks allocated: 608793452544
referenced 322315554816
'Bout to try a repair - which apparently you shouldn’t do
Yes, has a bit of a play…
It’s only an OS partition, anyways, have been thinking about reinstalling recently, anyway (probably because it has been slowing down because of corruption!), so will try the repair option, if not reinstall…
Just hope it doesn’t indicate my SSD is on the way out - that could be a bit more distressing!
Thanks.
You may want to make sure your drive is working properly. Check for errors in the output of smartctl -x and search the full journal for errors using journal -g sda3 -p4.