linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: miaox <miaox@cn.fujitsu.com>
Cc: Linux Btrfs <linux-btrfs@vger.kernel.org>,
	"Yan, Zheng" <yanzheng@21cn.com>
Subject: Re: [BUG] can not allocate space for caching data
Date: Mon, 20 Dec 2010 10:41:17 -0500	[thread overview]
Message-ID: <1292859261-sup-570@think> (raw)
In-Reply-To: <4D0F566A.2020103@cn.fujitsu.com>

Excerpts from Miao Xie's message of 2010-12-20 08:13:14 -0500:
> On Mon, 20 Dec 2010 07:44:06 -0500, Chris Mason wrote:
> > Excerpts from Miao Xie's message of 2010-12-20 07:25:10 -0500:
> >> Hi, Chris
> >>
> >> There is something wrong with this patch:
> >>
> >> commit 83a50de97fe96aca82389e061862ed760ece2283
> >> Author: Chris Mason<chris.mason@oracle.com>
> >> Date:   Mon Dec 13 15:06:46 2010 -0500
> >>
> >>      Btrfs: prevent RAID level downgrades when space is low
> >>
> >>      The extent allocator has code that allows us to fill
> >>      allocations from any available block group, even if it doesn't
> >>      match the raid level we've requested.
> >>
> >> Btrfs has added the space of single chunks and raid0 chunks into the space
> >> information, so when we use btrfs_check_data_free_space() to check if there
> >> is some space for storing file data, this function may return true. So we
> >> write the data into the cache successfully. But, the extent allocator can
> >> not allocate any space to store that cached data, and then the file system
> >> panic.
> >>
> >> I think we subtract that space from the space information, or split the space
> >> information into two types, one is used to manage the chunks with duplication,
> >> the other manages the other chunks.
> >
> > Ok, do you have a test case that triggers this?  I'll work out a patch.
> > Yan Zheng's original idea of 'the chunks should be readonly' should help
> > us deduct them from the total.
> 
> # mkfs.btrfs -d raid1 /dev/sda9 /dev/sda10
> # mount /dev/sda9 /mnt
> # dd if=/dev/zero of=/mnt/tmpfile0 bs=4K count=999999999999999999
>    (fill the file system)
> # umount /mnt
> # mount /dev/sda9 /mnt
> # dd if=/dev/zero of=/mnt/tmpfile1 bs=4K count=1000
> # sync

Looks like we've got an off by one bug in set_block_group_ro, which is
why our block group isn't getting set to ro.  With this patch, we're
properly setting the block group ro, and the enospc accounting is done
correctly.

It should also be able to replace my commit above.  Please take a look,
Zheng does this look correct to you?

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 227e581..6f7d758 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -7970,13 +7970,14 @@ static int set_block_group_ro(struct btrfs_block_group_cache *cache)
 
 	if (sinfo->bytes_used + sinfo->bytes_reserved + sinfo->bytes_pinned +
 	    sinfo->bytes_may_use + sinfo->bytes_readonly +
-	    cache->reserved_pinned + num_bytes < sinfo->total_bytes) {
+	    cache->reserved_pinned + num_bytes <= sinfo->total_bytes) {
 		sinfo->bytes_readonly += num_bytes;
 		sinfo->bytes_reserved += cache->reserved_pinned;
 		cache->reserved_pinned = 0;
 		cache->ro = 1;
 		ret = 0;
 	}
+
 	spin_unlock(&cache->lock);
 	spin_unlock(&sinfo->lock);
 	return ret;

  reply	other threads:[~2010-12-20 15:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-20 12:25 [BUG] can not allocate space for caching data Miao Xie
2010-12-20 12:44 ` Chris Mason
2010-12-20 13:13   ` Miao Xie
2010-12-20 15:41     ` Chris Mason [this message]
2010-12-21  0:33       ` Yan, Zheng 

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=1292859261-sup-570@think \
    --to=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=miaox@cn.fujitsu.com \
    --cc=yanzheng@21cn.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;
as well as URLs for NNTP newsgroup(s).