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).
Hi Alex, Wang.
Thanks for comment
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 f
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 wa
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 eno
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).
But what'r the challenge(s) to have ref count in the
btrfs_file_extent_item ? any thoughts
Hello David, Anand,
> On Mon, Oct 07, 2013 at 10:47:56AM +0800, Anand Jain wrote:
>> I was also thinking if this should be inside kernel
>> facilitated by a new ioctl? so that we avoid number
>> of search ioctl thats required.
>
> I think so. And for the feature itself, it can be handy in case
On 10/09/2013 04:03 PM, Anand Jain wrote:
> Wang,
>
>
>> 1. First to search inline extent_data
>> 2. Secondly search in extent tree to calculate (extent refs=1)
> but these extents will be of entire fs, how do you filter it for a subvol ?
Sorry, this could not be true as i have expected,(we have to
Wang,
> 1. First to search inline extent_data
> 2. Secondly search in extent tree to calculate (extent refs=1)
but these extents will be of entire fs, how do you filter it for a subvol ?
Thanks, Anand
> This will avoid n*n rather than n+n which is better…
--
To unsubscribe from this list: se
On Mon, Oct 07, 2013 at 10:47:56AM +0800, Anand Jain wrote:
> I was also thinking if this should be inside kernel
> facilitated by a new ioctl? so that we avoid number
> of search ioctl thats required.
I think so. And for the feature itself, it can be handy in case where
qgroups are not esta
On 10/07/2013 11:01 AM, Wang Shilong wrote:
> On 10/07/2013 10:47 AM, Anand Jain wrote:
>>
>>
>>> If we want to speed up this progress, i think we can split it into two
>>> parts:
>>>
>>> 1. First to search inline extent_data
>>> 2. Secondly search in extent tree to calculate (extent refs=1)
>>>
On 10/07/2013 10:47 AM, Anand Jain wrote:
>
>
>> If we want to speed up this progress, i think we can split it into two parts:
>>
>> 1. First to search inline extent_data
>> 2. Secondly search in extent tree to calculate (extent refs=1)
>>
>> This will avoid n*n rather than n+n which is better…
>
> If we want to speed up this progress, i think we can split it into two parts:
>
> 1. First to search inline extent_data
> 2. Secondly search in extent tree to calculate (extent refs=1)
>
> This will avoid n*n rather than n+n which is better…
(sorry for delay in reply, I was on vacation).
> On Sun, Sep 29, 2013 at 11:25:36PM +0800, Anand Jain wrote:
>> It needs a lot more information about the snapshots if
>> snapshot's life cycle has to be all auto managed by
>> scripts _some day_. this patch is a step towards that.
>>
>> This patch provides the size which would be freed
>> if
On Sun, Sep 29, 2013 at 11:25:36PM +0800, Anand Jain wrote:
> It needs a lot more information about the snapshots if
> snapshot's life cycle has to be all auto managed by
> scripts _some day_. this patch is a step towards that.
>
> This patch provides the size which would be freed
> if the subvol
It needs a lot more information about the snapshots if
snapshot's life cycle has to be all auto managed by
scripts _some day_. this patch is a step towards that.
This patch provides the size which would be freed
if the subvol/snapshot is deleted.
preview:
-
btrfs su show /btrf
15 matches
Mail list logo
