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
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
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
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: send
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
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 where
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
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
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
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 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)
This will avoid n*n
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
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
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
14 matches
Mail list logo
