Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Hugo Mills <hugo-lkml@carfax.org.uk>
To: chris.mason@oracle.com, dave@jikos.cz, lizf@cn.fujitsu.com,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v5 1/8] btrfs: Balance progress monitoring
Date: Tue, 12 Apr 2011 19:42:07 +0100	[thread overview]
Message-ID: <20110412184207.GH5301@carfax.org.uk> (raw)
In-Reply-To: <20110412171232.GJ31675@twin.jikos.cz>

[-- Attachment #1: Type: text/plain, Size: 3958 bytes --]

On Tue, Apr 12, 2011 at 07:12:32PM +0200, David Sterba wrote:
> Hi,
> 
> I've noticed that Arne's scrub patches add scrub variables directly
> into the fs_info structure, while you have a separate struct.

   Chris (I think -- might have been Josef) suggested the use of a
struct, back when I was first writing this code.

> I was wondering whether it would be better to put items of
> btrfs_balance_info to fs_info too, balance state is a global info.
> 
> Although fs_info is a huge structure now, 9402 bytes on 86_64, there is
> no space saving in this case.

   There will be savings in the future, however -- when I add Li's
suggestion for tracking the number of bytes (in the block groups as a
whole, and in terms of useful data stored), plus the vaddr of the
last-moved block group, the size of the btrfs_balance_info struct will
go up from its current 8 bytes to 48. I've just not quite finished
that patch yet, and wanted to get the rest of the patches settled
while I work on the new one...

   Hugo.

> On Sun, Apr 10, 2011 at 10:06:04PM +0100, Hugo Mills wrote:
> > diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> > index 7f78cc7..17c7ecc 100644
> > --- a/fs/btrfs/ctree.h
> > +++ b/fs/btrfs/ctree.h
> > @@ -865,6 +865,11 @@ struct btrfs_block_group_cache {
> >  	struct list_head cluster_list;
> >  };
> >  
> > +struct btrfs_balance_info {
> > +	u32 expected;
> > +	u32 completed;
> 
> two u32 make one u64
> 
> > +};
> > +
> >  struct reloc_control;
> >  struct btrfs_device;
> >  struct btrfs_fs_devices;
> > @@ -1078,6 +1083,10 @@ struct btrfs_fs_info {
> >  
> >  	/* filesystem state */
> >  	u64 fs_state;
> > +
> > +	/* Keep track of any rebalance operations on this FS */
> > +	spinlock_t balance_info_lock;
> > +	struct btrfs_balance_info *balance_info;
> 
> a pointer is a u64 too
> 
> >  };
> >  
> >  /*
> > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> > index dd13eb8..bb2ffed 100644
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -2051,6 +2052,20 @@ int btrfs_balance(struct btrfs_root *dev_root)
> >  	mutex_lock(&dev_root->fs_info->volume_mutex);
> >  	dev_root = dev_root->fs_info->dev_root;
> >  
> > +	bal_info = kmalloc(
> > +		sizeof(struct btrfs_balance_info),
> > +		GFP_NOFS);
> 
> ... drop
> 
> > +	if (!bal_info) {
> > +		ret = -ENOMEM;
> > +		goto error_no_status;
> > +	}
> > +	spin_lock(&dev_root->fs_info->balance_info_lock);
> > +	dev_root->fs_info->balance_info = bal_info;
> > +	bal_info->expected = -1; /* One less than actually counted,
> > +				    because chunk 0 is special */
> > +	bal_info->completed = 0;
> > +	spin_unlock(&dev_root->fs_info->balance_info_lock);
> > +
> >  	/* step one make some room on all the devices */
> >  	list_for_each_entry(device, devices, dev_list) {
> >  		old_size = device->total_bytes;
> > @@ -2115,10 +2157,20 @@ int btrfs_balance(struct btrfs_root *dev_root)
> >  					   found_key.offset);
> >  		BUG_ON(ret && ret != -ENOSPC);
> >  		key.offset = found_key.offset - 1;
> > +		spin_lock(&dev_root->fs_info->balance_info_lock);
> > +		bal_info->completed++;
> > +		spin_unlock(&dev_root->fs_info->balance_info_lock);
> > +		printk(KERN_INFO "btrfs: balance: %llu/%llu block groups completed\n",
> > +		       bal_info->completed, bal_info->expected);
> >  	}
> >  	ret = 0;
> >  error:
> >  	btrfs_free_path(path);
> > +	spin_lock(&dev_root->fs_info->balance_info_lock);
> > +	kfree(dev_root->fs_info->balance_info);
> 
> ... drop
> 
> > +	dev_root->fs_info->balance_info = NULL;
> > +	spin_unlock(&dev_root->fs_info->balance_info_lock);
> > +error_no_status:
> >  	mutex_unlock(&dev_root->fs_info->volume_mutex);
> >  	return ret;
> >  }

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
       --- Never underestimate the bandwidth of a Volvo filled ---       
                           with backup tapes.                            

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

  reply	other threads:[~2011-04-12 18:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-10 21:06 [PATCH v5 0/8] Balance mangement Hugo Mills
2011-04-10 21:06 ` [PATCH v5 1/8] btrfs: Balance progress monitoring Hugo Mills
2011-04-11  5:34   ` Helmut Hullen
2011-04-11  8:48     ` Hugo Mills
2011-04-12 17:12   ` David Sterba
2011-04-12 18:42     ` Hugo Mills [this message]
2011-04-13 13:34       ` David Sterba
2011-04-10 21:06 ` [PATCH v5 2/8] btrfs: Cancel filesystem balance Hugo Mills
2011-04-10 21:06 ` [PATCH v5 3/8] btrfs: Factor out enumeration of chunks to a separate function Hugo Mills
2011-04-10 22:11   ` David Sterba
2011-04-10 21:06 ` [PATCH v5 4/8] btrfs: Implement filtered balance ioctl Hugo Mills
2011-04-10 21:06 ` [PATCH v5 5/8] btrfs: Balance filter for device ID Hugo Mills
2011-04-10 21:06 ` [PATCH v5 6/8] btrfs: Balance filter for virtual address ranges Hugo Mills
2011-04-10 21:06 ` [PATCH v5 7/8] btrfs: Replication-type information Hugo Mills
2011-04-10 21:06 ` [PATCH v5 8/8] btrfs: Balance filter for physical device address Hugo Mills

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110412184207.GH5301@carfax.org.uk \
    --to=hugo-lkml@carfax.org.uk \
    --cc=chris.mason@oracle.com \
    --cc=dave@jikos.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox