Thank you very much for the fast responses. I'll try out the suggested tips starting with the fastest/easiest ones. The kernel is surely outdated, blame on me, I'll upgrade it as soon as possible. Things I already tested, but forgot to mention in my first e-mail: memtest86+ I had it running for 2 pases and no errors where found, I'll be running it for longer to see if there is some temperature related error or any other kind. I runned a SMART automatic health test, again no errors. I runned btrfs check --repair, I didn't think it would be dangerous, also no errors. I mounted the fs in ro mode and copied everything to an external backup hdd. So now I'm going to try out your suggestions to see what extra information I get. Thanks to all of you, Falk El dom., 19 jul. 2020 a las 23:42, A L (<mail@xxxxxxxxxxxxxx>) escribió: > > > > ---- From: Falk Bay <falkartis@xxxxxxxxx> -- Sent: 2020-07-19 - 22:24 ---- > > > Hi, > > > > First of all I want to thank you for this great piece of software, > > I've been using it for a long time and it perfectly suits my needs. > > > > After a unclean shutdown, with a balancing in progress and very little > > free space in my RAID1 filesystem I ended up with a btrfs filesystem > > that only works in ro mode. > > If I try to mount it as normal, any read or write operation will hang > > forever, not even "umount" will return. > > As a side note, if I mount it as normally I have to force my machine > > to power off since the normal shutdown will wait until any filesystem > > is unmounted. > > > > Here are my technical details: > > > > uname -a > > Linux poloni 4.15.0-111-generic #112-Ubuntu SMP Thu Jul 9 20:32:34 UTC > > 2020 x86_64 x86_64 x86_64 GNU/Linux > > > > btrfs --version > > btrfs-progs v4.15.1 > > > > sudo btrfs fi show > > Label: none uuid: aa1f67a3-8cd3-4d1b-87de-a04b48efbcfd > > Total devices 2 FS bytes used 27.58GiB > > devid 1 size 32.00GiB used 31.00GiB path /dev/sda7 > > devid 2 size 32.00GiB used 31.00GiB path /dev/sdb7 > > > > Label: 'my-btrfs' uuid: 5ea692ab-c7b1-4618-be39-d82eaf5c6b34 > > Total devices 2 FS bytes used 888.89GiB > > devid 3 size 891.51GiB used 891.51GiB path /dev/sda5 > > devid 5 size 891.51GiB used 891.51GiB path /dev/sdb5 > > > > this aa1f67a3-8cd3-4d1b-87de-a04b48efbcfd works fine. > > this 5ea692ab-c7b1-4618-be39-d82eaf5c6b34, my-btrfs is the one that > > causes problems > > > > btrfs fi df /mnt/ > > Data, RAID1: total=888.48GiB, used=886.92GiB > > System, RAID1: total=32.00MiB, used=208.00KiB > > Metadata, RAID1: total=3.00GiB, used=1.97GiB > > GlobalReserve, single: total=512.00MiB, used=0.00B > > > > I was willing, but unable, to remove some large files to have enough > > free space to operate normally. > > > > I add the dmesg.log file in the attachment. > > > > I wonder if I should try to fix it or if I should format the partition > > and recover a backup. > > > > Thanks in advance, > > Falk > > The dmesg suggest a balance in running. The skip_balance is a good option here. > > I'd to see the output of `btrfs fi us /mnt/` as it will show the allocations better. You may have a situation with not enough space to allocate a new data or metadata block and the balance is not very good at handling this. > > A note is that deleting files actually can increase metadata usage. > > To solve that youd have to do very specific balancing options. But the suggested memtest is good! Do you have earlier kernel outputs with errors to share? > > https://wiki.tnonline.net/w/Btrfs/ENOSPC shows a high level on how block allocation work.. > Official FAQ is here: https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_I_ran_out_of_disk_space.21 > > I suggest you do look for those earlier logs and do the testing suggested by Chris Murphy. > > Good luck! > > /Anders > >
