Tomasz Torcz | 1 Oct 11:01 2009
Picon

Re: yum upgrade on btrfs very slow

On Wed, Sep 30, 2009 at 09:43:51PM +0200, Tomasz Torcz wrote:
> > 
> > If you're comparing w/ext3 and wondering why btrfs is sooooooo much
> > slower it might be because btrfs has barriers on by default and ext3
> > doesn't.  You could mount -o nobarrier for btrfs or mount -o barrier=1
> > for ext3 for a proper comparison.
> > 
> > (Assuming your dmesg doesn't have messages from btrfs about disabling
> > barriers).
> 
>   I wouldn't expect barriers to work here (reminder, this is PATA drive
> on ICH7 sata controller), but I will test tomorrow with nobarrier.
> Then I probably check his "yum upgrade" under seekwatcher on friday.

  Nobarrier result are here:
http://pipebreaker.pl/dump/sysrq_w-nobarrier.txt.bz2
http://pipebreaker.pl/dump/vmstat-nobarrier.txt.bz2

  My observation: still slow. Just a note on my unscientific methodology:
I've got two very similar machines with Rawhide, one on ext4, second
on btrfs. Every day I do "yum upgrade" on both. Ext4 one finishes much
faster thatn btrfs. This is especially visible while yum is in "cleanup phase".
On ext4 most packages are cleaned'up in under one second time. On btrfs
this takes few seconds.
  Whole transaction ends in couple of minutes on ext4. On btrfs it takes 5x
longer.

--

-- 
Tomasz Torcz               RIP is irrevelant. Spoofing is futile.
xmpp: zdzichubg <at> chrome.pl     Your routes will be aggreggated. -- Alex Yuriev
(Continue reading)

Jens Axboe | 1 Oct 11:04 2009
Picon

Re: yum upgrade on btrfs very slow

On Wed, Sep 30 2009, Tomasz Torcz wrote:
>   I wouldn't expect barriers to work here (reminder, this is PATA drive
> on ICH7 sata controller), but I will test tomorrow with nobarrier.
> Then I probably check his "yum upgrade" under seekwatcher on friday.

Barriers should work fine on that setup. In fact, barriers were first
implemented for PATA back in the day :-)

--

-- 
Jens Axboe

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

Josef Bacik | 1 Oct 23:18 2009
Picon

[PATCH] Btrfs: fix data space leak fix

There is a problem where page_mkwrite can be called on a dirtied page that
already has a delalloc range associated with it.  The fix is to clear any
delalloc bits for the range we are dirtying so the space accounting gets handled
properly.  This is the same thing we do in the normal write case, so we are
consistent across the board.  With this patch we no longer leak reserved space.

Signed-off-by: Josef Bacik <jbacik <at> redhat.com>
---
 fs/btrfs/inode.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index c22075d..1010979 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
 <at>  <at>  -4666,10 +4666,21  <at>  <at>  again:
 		goto again;
 	}

+	/*
+	 * XXX - page_mkwrite gets called every time the page is dirtied, even
+	 * if it was already dirty, so for space accounting reasons we need to
+	 * clear any delalloc bits for the range we are fixing to save.  There
+	 * is probably a better way to do this, but for now keep consistent with
+	 * prepare_pages in the normal write path.
+	 */
+	clear_extent_bits(&BTRFS_I(inode)->io_tree, page_start, page_end,
+			  EXTENT_DIRTY | EXTENT_DELALLOC, GFP_NOFS);
+
 	ret = btrfs_set_extent_delalloc(inode, page_start, page_end);
(Continue reading)

Chris Mason | 2 Oct 02:30 2009
Picon

[GIT PULL] Btrfs updates for 2.6.32-rc

Hello everyone,

I've prepared the for-linus branch of the btrfs-unstable tree for
pulling:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus

The master branch has the same changes against 2.6.31, minus a cleanup
from Christoph that is 2.6.32-rc specific.

The big part of this pull request is Josef Bacik's ENOSPC support.  He
has added enough tracking to reserve room ahead of time for the metadata
required to meet all the delayed allocations we do, and gotten rid of
the half solutions that were in place before.

We already have small updates planned, and the code doesn't yet make
sure that btrfs-vol -b or device shrinking do the proper reservation to
avoid oopsen.  But, it is working nicely and I'd like to get it out for
broader use.

Another change that may get noticed is that Btrfs now uses
CONFIG_BTRFS_POSIX_ACL for testing to see if it should do acls.  There
has been some confusion around this and it is more consistent with the
other filesystems.  So, if you had acls please make sure you've got the
btrfs posix acl config on.

Chris Ball (2) commits (+7/-5):
    Btrfs: Fix setting umask when POSIX ACLs are not enabled (+2/-0)
    Btrfs: Use CONFIG_BTRFS_POSIX_ACL to enable ACL code (+5/-5)

(Continue reading)

TARUISI Hiroaki | 2 Oct 07:35 2009

[PATCH] btrfs-progs: bug fixes

Hi,

I have tested btrfsck in some error case, such as item missing
case or CRC error case or so. In this test session I found some
bugs in btrfsck.c and disk-io.c in btrfs-progs.
  1. The last pair of ptrs and items are not checked at 2 place
     of check_node/leaf.
  2. Csum printed CRC error message is not correct.
  3. In CRC error, btrfsck fails in segmentation fault.

I'll post three tiny patches to fix these bugs.

--

-- 
taruisi

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

TARUISI Hiroaki | 2 Oct 07:39 2009

[PATCH] btrfsck: Fix Check limit in check_node/leaf.


In btrfsck.c( check_node/leaf ), it seems that last pair of
ptrs and items are not checked at 2 place.

Signed-off-by: TARUISI Hiroaki <taruishi.hiroak <at> jp.fujitsu.com>
---
 btrfsck.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/btrfsck.c b/btrfsck.c
index 73f1836..ecc7b19 100644
--- a/btrfsck.c
+++ b/btrfsck.c
 <at>  <at>  -1720,7 +1720,7  <at>  <at>  static int check_node(struct btrfs_root *root,
 		if (memcmp(parent_key, &key, sizeof(key)))
 			return 1;
 	}
-	for (i = 0; nritems > 1 && i < nritems - 2; i++) {
+	for (i = 0; nritems > 1 && i < nritems - 1; i++) {
 		btrfs_node_key(buf, &key, i);
 		btrfs_node_key_to_cpu(buf, &cpukey, i + 1);
 		if (btrfs_comp_keys(&key, &cpukey) >= 0)
 <at>  <at>  -1759,7 +1759,7  <at>  <at>  static int check_leaf(struct btrfs_root *root,
 		       (unsigned long long)btrfs_header_bytenr(buf));
 		return 1;
 	}
-	for (i = 0; nritems > 1 && i < nritems - 2; i++) {
+	for (i = 0; nritems > 1 && i < nritems - 1; i++) {
 		btrfs_item_key(buf, &key, i);
 		btrfs_item_key_to_cpu(buf, &cpukey, i + 1);
(Continue reading)

TARUISI Hiroaki | 2 Oct 07:52 2009

[PATCH] btrfs-progs: CRC on disk printed correctly in CRC error message


I've tested btrfsck in CRC error case. However CRC on disk printed
in error message is not correct (extent_buffer itsself is printed).

Signed-off-by: TARUISI Hiroaki <taruishi.hiroak <at> jp.fujitsu.com>
---
 disk-io.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/disk-io.c b/disk-io.c
index addebe1..190301f 100644
--- a/disk-io.c
+++ b/disk-io.c
 <at>  <at>  -86,7 +86,7  <at>  <at>  int csum_tree_block_size(struct extent_buffer *buf, u16 csum_size,
 		if (memcmp_extent_buffer(buf, result, 0, csum_size)) {
 			printk("checksum verify failed on %llu wanted %X "
 			       "found %X\n", (unsigned long long)buf->start,
-			       *((int *)result), *((int *)buf));
+			       *((int *)result), *((int *)buf->data));
 			free(result);
 			return 1;
 		}
--

-- 
1.6.2.1

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

(Continue reading)

TARUISI Hiroaki | 2 Oct 07:52 2009

[PATCH] btrfsck: CRC error case handling.


In tree block CRC error case, btrfsck fails in segmentation fault.
In CRC error case, read_tree_block returns NULL as extent_buffer
like other(ex. ENOMEM) case, and btrfsck refers it without check.

If CRC error tree block is tree root, btrfsck aborts in previous
stage.
Like this, as for CRC error handling, BUG() is often used such as
in find_and_setup_root(disk-io.c), but CRC error is not a bug, so,
btrfsck should not abort but report, I think.

Because read_tree_block puts error message in CRC error case,
patch logic is simply return to caller with error.

Signed-off-by: TARUISI Hiroaki <taruishi.hiroak <at> jp.fujitsu.com>
---
 btrfsck.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/btrfsck.c b/btrfsck.c
index ecc7b19..cc00e28 100644
--- a/btrfsck.c
+++ b/btrfsck.c
 <at>  <at>  -2504,6 +2504,9  <at>  <at>  static int run_next_block(struct btrfs_root *root,

 	/* fixme, get the real parent transid */
 	buf = read_tree_block(root, bytenr, size, 0);
+	if (buf == NULL)
+		return -1;
+
(Continue reading)

Alexander Beregalov | 2 Oct 13:18 2009
Picon

2.6.32-rc1: btrfs hugs

Hi
The kernel is  2.6.32-rc2-00196-g0efe5e3
SMP, 4cpus

I tested dbench with 150 threads on 120G partition.

device fsid b467c30bdb79768-7e6f9a05192ee4b5 devid 1 transid 7 /dev/sda3
thread pool is 6
INFO: task btrfs-transacti:28788 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
btrfs-transac D 39a378f5  5476 28788      2 0x00000000
 f600fe30 00000046 00000001 39a378f5 c161aea0 39a378f5 f6b5da90 00023662
 00000000 0000025a 00007ca0 00000000 f6b5df9c f6b5da90 39a378f5 00000001
 f6b5da90 c161a984 c175e240 f6b5dd20 c175e240 c175e240 f6b5dd20 c175e240
Call Trace:
 [<c12284aa>] ? blk_backing_dev_unplug+0x1a/0x40
 [<c140ac8f>] io_schedule+0x3f/0x70
 [<c1082dcd>] sync_page+0x4d/0x70
 [<c140b38d>] __wait_on_bit+0x5d/0xa0
 [<c1082d80>] ? sync_page+0x0/0x70
 [<c1083013>] wait_on_page_bit+0x93/0xb0
 [<c1052a80>] ? wake_bit_function+0x0/0x70
 [<c11d3bdb>] btrfs_write_and_wait_marked_extents+0x20b/0x310
 [<c11d3d09>] btrfs_write_and_wait_transaction+0x29/0x60
 [<c11d41ac>] btrfs_commit_transaction+0x46c/0x6b0
 [<c1052a20>] ? autoremove_wake_function+0x0/0x60
 [<c11ce8db>] transaction_kthread+0x1bb/0x1f0
 [<c11ce720>] ? transaction_kthread+0x0/0x1f0
 [<c105271c>] kthread+0x7c/0x90
 [<c10526a0>] ? kthread+0x0/0x90
(Continue reading)

Johannes Hirte | 2 Oct 15:02 2009
Picon
Picon

crash with linux-2.6.31.1

I got the following crash today:

Oct  2 10:30:04 datengrab kernel: ------------[ cut here ]------------
Oct  2 10:30:04 datengrab kernel: WARNING: at fs/btrfs/free-space-cache.c:90 
tree_insert_offset+0x74/0xbb [btrfs]()
Oct  2 10:30:04 datengrab kernel: Hardware name: To Be Filled By O.E.M.
Oct  2 10:30:04 datengrab kernel: Modules linked in: snd_seq_midi 
snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_seq_oss 
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss btrfs zlib_deflate crc32c 
libcrc32c aes_x86_64 aes_generic xts gf128mul dm_crypt snd_emu10k1 snd_rawmidi 
snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc 
snd_util_mem snd_hwdep snd sg sr_mod ohci_hcd ehci_hcd uhci_hcd fglrx(P)
Oct  2 10:30:04 datengrab kernel: Pid: 258, comm: pdflush Tainted: P           
2.6.31.1 #1
Oct  2 10:30:04 datengrab kernel: Call Trace:
Oct  2 10:30:04 datengrab kernel: [<ffffffff8102b511>] ? 
warn_slowpath_common+0x76/0x8c
Oct  2 10:30:04 datengrab kernel: [<ffffffffa0369c42>] ? 
tree_insert_offset+0x74/0xbb [btrfs]
Oct  2 10:30:04 datengrab kernel: [<ffffffffa036a0c2>] ? link_free_space+0x3b/0x51 
[btrfs]
Oct  2 10:30:04 datengrab kernel: [<ffffffffa036a3c4>] ? 
btrfs_find_space_for_alloc+0x142/0x157 [btrfs]
Oct  2 10:30:04 datengrab kernel: [<ffffffffa0335692>] ? 
find_free_extent+0x48a/0x705 [btrfs]
Oct  2 10:30:04 datengrab kernel: [<ffffffff81183071>] ? 
radix_tree_gang_lookup_slot+0x6b/0x8f
Oct  2 10:30:04 datengrab kernel: [<ffffffffa0335d27>] ? 
__btrfs_reserve_extent+0x114/0x283 [btrfs]
Oct  2 10:30:04 datengrab kernel: [<ffffffffa0335ec3>] ? 
(Continue reading)


Gmane