Re: [PATCH v2 0/2] Balance management, kernel side

2011-03-20 Thread Andreas Philipp
-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

Re: [PATCH v2 0/2] Balance management, kernel side

2011-03-20 Thread Hugo Mills
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

[PATCH RFC] btrfs: Simplify locking

2011-03-20 Thread Tejun Heo
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

Re: [PATCH RFC] btrfs: Simplify locking

2011-03-20 Thread Tejun Heo
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

Re: [PATCH RFC] btrfs: Simplify locking

2011-03-20 Thread Tejun Heo
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

Re: [PATCH RFC] btrfs: Simplify locking

2011-03-20 Thread Chris Mason
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

Re: [PATCH V4] btrfs: implement delayed inode items operation

2011-03-20 Thread Chris Mason
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

Re: [PATCH] Btrfs: don't be as aggressive about using bitmaps

2011-03-20 Thread Li Zefan
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

Re: [PATCH] Btrfs: check free space in block group before searching for a cluster

2011-03-20 Thread Li Zefan
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 ---

Re: [PATCH V4] btrfs: implement delayed inode items operation

2011-03-20 Thread Miao Xie
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

Re: [RFC] a couple of i_nlink fixes in btrfs

2011-03-20 Thread Al Viro
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