Excerpts from Miao Xie's message of 2011-02-18 08:09:28 -0500:

On fri, 18 Feb 2011 07:19:42 -0500, Chris Mason wrote:

quoted

Excerpts from Miao Xie's message of 2011-02-18 04:08:12 -0500:

quoted

Hi, Chris
CC Tsutomu Itoh

On Thu, 17 Feb 2011 20:09:00 -0500, Chris Mason wrote:

quoted

Excerpts from Miao Xie's message of 2011-02-17 00:48:40 -0500:

quoted

Compare with Ext3/4, the performance of file creation and deletion on btrfs
is very poor. the reason is that btrfs must do a lot of b+ tree insertions,
such as inode item, directory name item, directory name index and so on.

If we can do some delayed b+ tree insertion or deletion, we can improve the
performance, so we made this patch which implemented delayed directory name
index insertion/deletion and delayed inode update.

This work is really cool, thanks for doing it.  I'm starting a run on
this tonight and if all goes well I'll review in detail and try to queue
it along with the per-subvolume storage bits for .39.

There is a hang-up problem in this patch, that is the task which does delayed item
balance and the task which commits the transaction will wait for each other, and
the filesystem will hang up. This is reported by Tsutomu Itoh.

I have made the third version of this patch, will post it later.

BUG: spinlock cpu recursion on CPU#2, btrfs-delayed-m/2762
  lock: ffff88004f47bfb0, .magic: dead4ead, .owner: btrfs-delayed-m/2763, .owner_cpu: 2
Pid: 2762, comm: btrfs-delayed-m Not tainted 2.6.38-rc4-josef+ #209
Call Trace:
  [<ffffffff812621f1>] ? spin_bug+0x9c/0xa3
  [<ffffffff8126225b>] ? do_raw_spin_lock+0x63/0x13c
  [<ffffffff815c31c5>] ? _raw_spin_lock+0xe/0x10
  [<ffffffffa004e5e3>] ? btrfs_try_spin_lock+0x2a/0x86 [btrfs]
  [<ffffffffa000ddc1>] ? btrfs_search_slot+0x5dd/0x73d [btrfs]
  [<ffffffffa001e77e>] ? btrfs_lookup_inode+0x2f/0x91 [btrfs]
  [<ffffffff815c21b2>] ? mutex_lock+0x31/0x48
  [<ffffffffa0061ac8>] ? btrfs_update_delayed_inode+0x73/0x11e [btrfs]
  [<ffffffffa0025454>] ? start_transaction+0x19f/0x1e3 [btrfs]
  [<ffffffffa0062026>] ? btrfs_async_run_delayed_node_done+0xd6/0x180 [btrfs]
  [<ffffffff8107c0e9>] ? process_timeout+0x0/0x10
  [<ffffffffa004a44f>] ? worker_loop+0x17e/0x49f [btrfs]
  [<ffffffffa004a2d1>] ? worker_loop+0x0/0x49f [btrfs]
  [<ffffffffa004a2d1>] ? worker_loop+0x0/0x49f [btrfs]
  [<ffffffff81089d9c>] ? kthread+0x82/0x8a
  [<ffffffff810347d4>] ? kernel_thread_helper+0x4/0x10
  [<ffffffff81089d1a>] ? kthread+0x0/0x8a
  [<ffffffff810347d0>] ? kernel_thread_helper+0x0/0x10


I hit this one overnight with spinlock debugging on.  Is it the same
problem you've fixed?

I haven't hit this bug, could you tell me the reproduce steps?

I just ran dbench 50.  But I have spinlock debugging turned on
(CONFIG_DEBUG_SPINLOCK).  Looks like the patch probably forgot to unlock
or release a path, I'll take a quick look.

-chris