Re: [PATCH] btrfs: fix node balancing condition in balance_level()

[Sun YangKai <sunk67188@gmail.com>]

> This is interesting, good catch.
> 
> However, we don't really have any evidence one way or the other which is
> better. For better or worse, this logic has been around since ~2007, so
> to change it I think requires more justification than the reasoning on a
> 
> faulty patch from 2009. Do you have any evidence for your #3:
>   > Improve btree performance by more frequent node compaction
> 
> I would advise that you run:
> - fsperf for generic benchmarking.
> - a targeted workload that would get compacted more now that you removed
>   the surprising check.
> 
> Thanks,
> Boris

Hi Boris.

The performance might get better because we will have less nodes and even 
lower trees, if we compact nodes when they are 50% full instead of 25% full. 
But I've not benched yet and there's some problem in it.

I come up with a drawback. This patch will make it more frequently to 
split a nearly full node into two and merge them back later again and again if 
item count changes slightly and its neighbors cannot help balance some items, 
which happens when:

1. left node is full or null and we are always operating the left-half part of 
the mid node
2. right node is null

The leaf merge related code choose (cap/3) instead of (cap/2) to prevent 
similar cases. I have no idea how often this could be triggered in real world 
workload. But if it really hurts, we should try some other method to merge/
split the nodes to get better performance.

Anyway, thank you for your advice. And I'm working on fsperf.

Thanks,
Sun YangKai