Re: free space inode generation (0) did not match free space cache generation

[Hendrik Friedel <hendrik@friedels.name>]

Hello,

after merely 5 days, I have the same Problem:

root@homeserver:~# ./btrfs/integration/devel/btrfs fi df /mnt/test1/
Disk size:                29.50GiB
Disk allocated:           29.30GiB
Disk unallocated:        202.00MiB
Used:                     13.84GiB
Free (Estimated):        929.95MiB      (Max: 1.01GiB, min: 929.95MiB)
Data to disk ratio:           50 %
root@homeserver:~# ./btrfs/integration/devel/btrfs fi show /mnt/test1/
Label: 'ROOT_BTRFS_RAID'  uuid: a2d5f2db-04ca-413a-aee1-cb754aa8fba5
         Total devices 2 FS bytes used 13.84GiB
         devid    1 size 14.85GiB used 14.65GiB path /dev/sde2
         devid    2 size 14.65GiB used 14.65GiB path /dev/sdd2


         root@homeserver:~# ./btrfs/integration/devel/btrfs fi df 
/mnt/test1/
Disk size:                29.50GiB
Disk allocated:           29.30GiB
Disk unallocated:        202.00MiB
Used:                     13.84GiB
Free (Estimated):        929.95MiB      (Max: 1.01GiB, min: 929.95MiB)
Data to disk ratio:           50 %
root@homeserver:~# ./btrfs/integration/devel/btrfs fi show /mnt/test1/
Label: 'ROOT_BTRFS_RAID'  uuid: a2d5f2db-04ca-413a-aee1-cb754aa8fba5
         Total devices 2 FS bytes used 13.84GiB
         devid    1 size 14.85GiB used 14.65GiB path /dev/sde2
         devid    2 size 14.65GiB used 14.65GiB path /dev/sdd2

Btrfs this-will-become-v3.13-48-g57c3600
root@homeserver:~# time ./btrfs/integration/devel/btrfs balance start 
-dusage=0 /mnt/test1
Done, had to relocate 0 out of 22 chunks

real    0m2.734s
user    0m0.000s
sys     0m0.022s


I increased dusage until I got:
root@homeserver:~# time ./btrfs/integration/devel/btrfs balance start 
-dusage=90 /mnt/test1
ERROR: error during balancing '/mnt/test1' - No space left on device
There may be more info in syslog - try dmesg | tail


Before I could do a full balance I had to delete all Snapshots:
~20 on my root subvolume
~40 on my /home and /root subvolume

I do not find this a extraordinary high number of snapshots. Also others 
should have higher numbers, when they use snapper.

Any Idea of what could be the reason here?

Regards,
Hendrik



Am 25.03.2014 21:10, schrieb Hugo Mills:
> On Tue, Mar 25, 2014 at 09:03:26PM +0100, Hendrik Friedel wrote:
>> Hi,
>>
>>> Well, given the relative immaturity of btrfs as a filesystem at this
>>> point in its lifetime, I think it's acceptable/tolerable.  However, for a
>>> filesystem feted[1] to ultimately replace the ext* series as an assumed
>>> Linux default, I'd definitely argue that the current situation should be
>>> changed such that btrfs can automatically manage its own de-allocation at
>>> some point, yes, and that said "some point" really needs to come before
>>> that point at which btrfs can be considered an appropriate replacement
>>> for ext2/3/4 as the assumed default Linux filesystem of the day.
>>
>> Agreed! I hope, this is on the ToDo List?!
>
> https://btrfs.wiki.kernel.org/index.php/Project_ideas#Block_group_reclaim
>
>     Yes. :)
>
>>> [1] feted: celebrated, honored.  I had to look it up to be sure my
>>> intuition on usage was correct, and indeed I had spelled it wrong
>>
>> :-)
>
>     Did you mean "fated": intended, destined?
>
>     Hugo.
>


-- 
Hendrik Friedel
Auf dem Brink 12
28844 Weyhe
Mobil 0178 1874363