On Wed, 18 Aug 2010 20:57:43 -0400, Chris Mason wrote:
Since the files are empty, and we aren't doing enough files to trigger
IO, it is really benchmarking the cost of the btree insertions/removals
in comparison with ext4.  I do expect this to be higher because btrfs is
indexing the directories twice (once by name and once by sequence number
for faster backups).

On my machine:

Btrfs defaults:

Create files:
        Total files: 50000
        Total time: 0.916680
        Average time: 0.000018
Delete files:
        Total files: 50000
        Total time: 1.329892
        Average time: 0.000027

Ext4:

creat_unlink 50000
Create files:
        Total files: 50000
        Total time: 0.718190
        Average time: 0.000014
Delete files:
        Total files: 50000
        Total time: 0.308815
        Average time: 0.000006

We're definitely slower than ext4, but as Ric's benchmarks show things
tend to tilt in our favor once IO is actually done.

There are two big things that would help fix this performance gap:
Switching the extent buffer rbtree into a radix tree (esp a lockless
radix tree), and delaying insertion of the inode so that we can do more
in btree operations in bulk.

The radix tree is a much easier and more contained project.

The type of the radix tree's key is "unsigned long", but the type of the
extent buffer's key is "u64". That is we can't use the radix tree instead of
rbtree on the 32-bits boxs. So we can't switching the extent buffer rbtree
into a radix tree.

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

Reply via email to