-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since balancing takes a long time I liked the idea of having some
progress counter and the ability to run this long lasting task in
background with another option to cancel it if necessary. So I wanted
to give it a try. Unfortunately, all the
On Sun, Mar 20, 2011 at 09:52:26AM +0100, Andreas Philipp wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since balancing takes a long time I liked the idea of having some
progress counter and the ability to run this long lasting task in
background with another option to cancel it
Hello, guys.
I've been looking through btrfs code and found out that the locking
was quite interesting. The distinction between blocking and
non-blocking locking is valid but is essentially attacing the same
problem that CONFIG_MUTEX_SPIN_ON_OWNER addresses in generic manner.
It seemed that
So, here's the patch to implement and use mutex_try_spin(), which
applies the same owner spin logic to try locking. The result looks
pretty good.
I re-ran all three. DFL is the current custom locking. SIMPLE is
with only the previous patch applied. SPIN is both the previous and
this patches
On Sun, Mar 20, 2011 at 08:56:52PM +0100, Tejun Heo wrote:
So, here's the patch to implement and use mutex_try_spin(), which
applies the same owner spin logic to try locking. The result looks
pretty good.
I re-ran all three. DFL is the current custom locking. SIMPLE is
with only the
Excerpts from Tejun Heo's message of 2011-03-20 13:44:33 -0400:
Hello, guys.
I've been looking through btrfs code and found out that the locking
was quite interesting. The distinction between blocking and
non-blocking locking is valid but is essentially attacing the same
problem that
Excerpts from Miao Xie's message of 2011-03-18 05:24:46 -0400:
Changelog V3 - V4:
- Fix nested lock, which is reported by Itaru Kitayama, by updating space
cache
inodes in time.
I ran some tests on this and had trouble with my stress.sh script:
http://oss.oracle.com/~mason/stress.sh
I
04:18, Josef Bacik wrote:
We have been creating bitmaps for small extents unconditionally forever. This
was great when testing to make sure the bitmap stuff was working, but is
overkill normally. So instead of always adding small chunks of free space to
bitmaps, only start doing it if we go
Josef Bacik wrote:
The free space cluster stuff is heavy duty, so there is no sense in going
through the entire song and dance if there isn't enough space in the block
group
to begin with. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
Reviewed-by: Li Zefan l...@cn.fujitsu.com
---
On sun, 20 Mar 2011 20:33:34 -0400, Chris Mason wrote:
Excerpts from Miao Xie's message of 2011-03-18 05:24:46 -0400:
Changelog V3 - V4:
- Fix nested lock, which is reported by Itaru Kitayama, by updating space
cache
inodes in time.
I ran some tests on this and had trouble with my
On Mon, Mar 07, 2011 at 11:58:13AM -0500, Chris Mason wrote:
Thanks, these both look good but I'll test here as well. Are you
planning on pushing for .38?
No, but .39 would be nice ;-) Do you want that to go through btrfs tree
or through vfs one?
--
To unsubscribe from this list: send the
11 matches
Mail list logo