linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergei Trofimovich <slyich@gmail.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: liubo <liubo2009@cn.fujitsu.com>,
	linux-btrfs@vger.kernel.org, Josef Bacik <josef@redhat.com>,
	Arne Jansen <sensille@gmx.net>
Subject: Re: [PATCH] Btrfs: fix easily get into ENOSPC in mixed case
Date: Thu, 5 May 2011 17:44:36 +0300	[thread overview]
Message-ID: <20110505174436.63e9e2cf@sf> (raw)
In-Reply-To: <4D9ECAF5.50108@cn.fujitsu.com>

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

On Fri, 08 Apr 2011 16:44:37 +0800
liubo <liubo2009@cn.fujitsu.com> wrote:

> 
> When a btrfs disk is created by mixed data & metadata option, it will have no
> pure data or pure metadata space info.
> 
> In btrfs's for-linus branch, commit 78b1ea13838039cd88afdd62519b40b344d6c920
> (Btrfs: fix OOPS of empty filesystem after balance) initializes space infos at
> the very beginning.  The problem is this initialization does not take the mixed
> case into account, which will cause btrfs will easily get into ENOSPC in mixed
> case.
> 
> Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>

Hi Chris!

I confirm it fixes OOpses for me.
Some clarification of what happened down the thread with me in order to convince
this patch actually makes things better.

1. The initial OOps reported by me was a result of using bad mkfs (not interesting,
    but generated a lot of noise here)

2. Then I've patched mkfs properly (used tmp branch), reformatted my partitions and
    caught -ENOSPC on 'rm -rf /var/tmp/' (vanilla kernel), added debugging info and have come to the
    conclusion: this patch helps in this situation, as free space was completely miscomputed
    (it's a regression since 2.6.38). I've applied it and things _mostly_ (see 3.) solved (--mixed
    ~4G lzo filesystem) for me

3. Then I've caught more -ENOSPC oopses, which occured to be a bug in mkfs for which Arne posted
    a fix today, see his email:
        [PATCH] btrfs progs: fix extra metadata chunk allocation in --mixed case

    Arne's mkfs patch (or btrfs fi balance workaround) fixed rest of OOpses for me.

So, my thoughts:
    - this patch is quite critical for --mixed filesystems
    - it (or it's equivalent) should be considered for pulling-in to .39 kernel (ideally), as it's a regression since 2.6.38

Thanks!

> ---
>  fs/btrfs/extent-tree.c |   37 ++++++++++++++++++++++++++-----------
>  1 files changed, 26 insertions(+), 11 deletions(-)
> 
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index f619c3c..1b47ae4 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -8781,23 +8781,38 @@ out:
>  int btrfs_init_space_info(struct btrfs_fs_info *fs_info)
>  {
>  	struct btrfs_space_info *space_info;
> +	struct btrfs_super_block *disk_super;
> +	u64 features;
> +	u64 flags;
> +	int mixed = 0;
>  	int ret;
>  
> -	ret = update_space_info(fs_info, BTRFS_BLOCK_GROUP_SYSTEM, 0, 0,
> -								 &space_info);
> -	if (ret)
> -		return ret;
> +	disk_super = &fs_info->super_copy;
> +	if (!btrfs_super_root(disk_super))
> +		return 1;
>  
> -	ret = update_space_info(fs_info, BTRFS_BLOCK_GROUP_METADATA, 0, 0,
> -								 &space_info);
> -	if (ret)
> -		return ret;
> +	features = btrfs_super_incompat_flags(disk_super);
> +	if (features & BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS)
> +		mixed = 1;
>  
> -	ret = update_space_info(fs_info, BTRFS_BLOCK_GROUP_DATA, 0, 0,
> -								 &space_info);
> +	flags = BTRFS_BLOCK_GROUP_SYSTEM;
> +	ret = update_space_info(fs_info, flags, 0, 0, &space_info);
>  	if (ret)
> -		return ret;
> +		goto out;
>  
> +	if (mixed) {
> +		flags = BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_DATA;
> +		ret = update_space_info(fs_info, flags, 0, 0, &space_info);
> +	} else {
> +		flags = BTRFS_BLOCK_GROUP_METADATA;
> +		ret = update_space_info(fs_info, flags, 0, 0, &space_info);
> +		if (ret)
> +			goto out;
> +
> +		flags = BTRFS_BLOCK_GROUP_DATA;
> +		ret = update_space_info(fs_info, flags, 0, 0, &space_info);
> +	}
> +out:
>  	return ret;
>  }
>  
> -- 
> 1.6.5.2
> --
> 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


-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

      parent reply	other threads:[~2011-05-05 14:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-02  9:19 2.6.39-rc1: kernel BUG at fs/btrfs/extent-tree.c:5479! Sergei Trofimovich
2011-04-02  9:37 ` liubo
2011-04-02 10:41   ` Sergei Trofimovich
2011-04-02 11:30     ` liubo
2011-04-02 12:55       ` Sergei Trofimovich
2011-04-08  8:44         ` [PATCH] Btrfs: fix easily get into ENOSPC in mixed case liubo
2011-04-08 21:09           ` Sergei Trofimovich
2011-04-08 21:19             ` Sergei Trofimovich
2011-04-08 21:55               ` Sergei Trofimovich
2011-04-11  6:29                 ` liubo
2011-04-11 20:27                   ` Sergei Trofimovich
2011-04-19 21:55                   ` Sergei Trofimovich
2011-04-21 15:19                     ` Sergei Trofimovich
2011-04-22 19:43           ` Sergei Trofimovich
2011-05-05 14:44           ` Sergei Trofimovich [this message]

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=20110505174436.63e9e2cf@sf \
    --to=slyich@gmail.com \
    --cc=chris.mason@oracle.com \
    --cc=josef@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=liubo2009@cn.fujitsu.com \
    --cc=sensille@gmx.net \
    /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;
as well as URLs for NNTP newsgroup(s).