Re: btrfs thinks fs is full, though 11GB should be still free

[Goffredo Baroncelli <kreijack@libero.it>]

On 18/12/2023 20.18, Goffredo Baroncelli wrote:
> On 18/12/2023 17.24, Christoph Anton Mitterer wrote:
>> Hey again.
>>
>> Seems that even the manual defrag doesn't help at all:
>>
>> After:
>> btrfs filesystem defragment -v -r -t 100000M
>
> Being only 309 files, I suggest to find one file as test case and start to inspect what is happening

I don't know if this would help, however I tried to reproduce this situation and what I found is

$ python3 mktestfile.py

$ sudo /usr/sbin/compsize test.bin
Processed 1 file, 3 regular extents (3 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL      100%      3.0M         3.0M         2.0M
none       100%      3.0M         3.0M         2.0M

$ btrfs fi defra -v test.bin

test.bin

$ sudo /usr/sbin/compsize test.bin
Processed 1 file, 3 regular extents (3 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL      100%      3.0M         3.0M         2.0M <------------- 3M
none       100%      3.0M         3.0M         2.0M

$ sync

$ sudo /usr/sbin/compsize test.bin
Processed 1 file, 2 regular extents (2 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL      100%      2.0M         2.0M         2.0M <------------- 2M after a sync
none       100%      2.0M         2.0M         2.0M


So until a sync, the file are not updated.


#------------------------------------------

$ cat mktestfile.py

import os

f = open("test.bin", "w")
p = 0
s = 1024 * 1024
for i in range(3):
         f.write("x" * s)
         p += s

         os.fsync(f)

         p -= s/2
         f.seek(p, 0)

os.fsync(f)
f.close()

#------------------------------------------


>>
>> there's still:
>> # compsize .
>> Processed 309 files, 324 regular extents (324 refs), 146 inline.
>> Type       Perc     Disk Usage   Uncompressed Referenced
>> TOTAL      100%       22G          22G          13G
>> none       100%       22G          22G          13G
>>
>>
>> Any other ideas how this could be solved?
>>
>> Cheers,
>> Chris.
>>
>

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5