[PATCH 2/5] Btrfs: count the chunks which will be relocated at first

2012-05-17 Thread Miao Xie 
the balance function should count the chunks which will be relocated at first,
and then relocate those chunks one by one.

Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
 fs/btrfs/volumes.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 759d024..91da8a2 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2580,7 +2580,7 @@ again:
 
chunk = btrfs_item_ptr(leaf, slot, struct btrfs_chunk);
 
-   if (!counting) {
+   if (counting) {
spin_lock(fs_info-balance_lock);
bctl-stat.considered++;
spin_unlock(fs_info-balance_lock);
-- 
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] Btrfs: count the chunks which will be relocated at first

2012-05-17 Thread Ilya Dryomov 
On Thu, May 17, 2012 at 07:56:53PM +0800, Miao Xie wrote:
 the balance function should count the chunks which will be relocated at first,
 and then relocate those chunks one by one.
 
 Signed-off-by: Miao Xie mi...@cn.fujitsu.com
 ---
  fs/btrfs/volumes.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
 index 759d024..91da8a2 100644
 --- a/fs/btrfs/volumes.c
 +++ b/fs/btrfs/volumes.c
 @@ -2580,7 +2580,7 @@ again:
  
   chunk = btrfs_item_ptr(leaf, slot, struct btrfs_chunk);
  
 - if (!counting) {
 + if (counting) {
   spin_lock(fs_info-balance_lock);
   bctl-stat.considered++;
   spin_unlock(fs_info-balance_lock);

__btrfs_balance() already calculates the approximate number of chunks
that will be relocated and stores that value in bctl-stat.expected.
The stat.considered counter OTOH is supposed to reflect the number of
chunks processed through balance filters and it is meant to be updated
at relocation pass, so AFAICS if (!counting) is the right test.

What exactly are you trying to fix here ?

Thanks,

Ilya
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] Btrfs: count the chunks which will be relocated at first

2012-05-17 Thread Miao Xie 
On Thu, 17 May 2012 17:58:56 +0300, Ilya Dryomov wrote:
 On Thu, May 17, 2012 at 07:56:53PM +0800, Miao Xie wrote:
 the balance function should count the chunks which will be relocated at 
 first,
 and then relocate those chunks one by one.

 Signed-off-by: Miao Xie mi...@cn.fujitsu.com
 ---
  fs/btrfs/volumes.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
 index 759d024..91da8a2 100644
 --- a/fs/btrfs/volumes.c
 +++ b/fs/btrfs/volumes.c
 @@ -2580,7 +2580,7 @@ again:
  
  chunk = btrfs_item_ptr(leaf, slot, struct btrfs_chunk);
  
 -if (!counting) {
 +if (counting) {
  spin_lock(fs_info-balance_lock);
  bctl-stat.considered++;
  spin_unlock(fs_info-balance_lock);
 
 __btrfs_balance() already calculates the approximate number of chunks
 that will be relocated and stores that value in bctl-stat.expected.
 The stat.considered counter OTOH is supposed to reflect the number of
 chunks processed through balance filters and it is meant to be updated
 at relocation pass, so AFAICS if (!counting) is the right test.
 
 What exactly are you trying to fix here ?

In fact this number reflect the number of all the chunks that may be relocated.
So since we can know the approximate number of chunks that will be relocated
before the relocation start, why can not we know it at the beginning?

And beside that, as a user, I am very strange that this counter is changed
every time I get the status of the balance, it should be the fixed number
since it reflect the number of all the chunks that may be relocated.

Thanks
Miao
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html