Re: [PATCH v2] btrfs-progs: calculate disk space that a subvol could free

[Wang Shilong <wangsl.fnst@cn.fujitsu.com>]

Hi Alex,

On 11/29/2013 01:39 AM, Alex Lyakas wrote:
> Hello Anand,
> I have sent a similar comment to your email thread in
> http://www.spinics.net/lists/linux-btrfs/msg27547.html
>
> I believe this approach of calculating freeable space is incorrect.
> Try this:
> - create a fresh btrfs
> - create a regular file
> - write some data into it in such a way, that it was, say 4000
> EXTENT_DATA items, so that file tree and extent tree get deep enough
> - run btrfs-debug-tree and verify that all EXTENT_ITEMs of this file
> (in the extent tree) have refcnt=1
> - create a snapshot of the subvolume
> - run btrfs-debug-tree again
>
> You will see that most (in my case - all) of EXTENT_ITEMs still have
> refcnt=1. Reason for this is as I mentioned in
> http://www.spinics.net/lists/linux-btrfs/msg27547.html
>
> But if you delete the subvolume, no space will be freed, because all
> these extents are also shared by the snapshot. Although it seems that
> your tool will report that all subvolume's space is freeable (based on
> refcnt=1).
>
> Can you pls try that experiment and comment on it? Perhaps I am
> missing something here?
I think you are right here, the only way we can make sure whether
a extent_item is shared by many roots is to walk backref to find
all roots, and if number of roots is 1, we know it's sole space.

If so, i don't think this should be implemented in user space, Btrfs quota
implement such function in kernel space, but it also face a problem that
deleting a subvolume will break space accounting(because subvolume deletion
won't iterate the whole fs tree).

Thanks,
Wang
>
> Thanks!
> Alex.
>
>
>
> On Thu, Oct 10, 2013 at 6:33 AM, Wang Shilong
> <wangsl.fnst@cn.fujitsu.com> wrote:
>> On 10/10/2013 11:35 AM, Anand Jain wrote:
>>>
>>>   If 'btrfs_file_extent_item' can contain the ref count it would
>>>   solve the current problem quite easily.  (problem is that, its
>>>   of n * n searches to know data extents with its ref for a given
>>>   subvol).
>> Just considering btrfs_file_extent_item is not enough, because
>> we should consider metadata(as i have said before).
>>
>>>   But what'r the challenge(s) to have ref count in the
>>>   btrfs_file_extent_item ? any thoughts ?
>> Haven't thought a better idea yet.
>>
>>
>>> Thanks, Anand
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>