On Mon, Jan 06, 2014 at 03:19:43PM -0800, Kent Overstreet wrote: > On Mon, Jan 06, 2014 at 02:25:35PM -0800, Greg KH wrote: > > On Mon, Jan 06, 2014 at 02:18:53PM -0800, Kent Overstreet wrote: > > > Upstream SHA1 d24a6e1087030b6da286df9433add5fa2f21b83b > > > > > > This patch is bigger than the original, because some of the fixes in 3.12 ended > > > up in the wrong patches. > > > > What do you mean by this? > > In the upstream patch, some of the necessary fixes had been done as part of > other refactoring patches that we don't want to backport. I'd really like to take the original patches from upstream, things work better that way. Also, you shouldn't mix fixes and refactoring in the same patch, this is one good example of why :) > > > Dirty data accounting wasn't quite right - firstly, we were adding the key we're > > > inserting after it could have merged with another dirty key already in the > > > btree, and secondly we could sometimes pass the wrong offset to > > > bcache_dev_sectors_dirty_add() for dirty data we were overwriting - which is > > > important when tracking dirty data by stripe. > > > > > > Signed-off-by: Kent Overstreet <kmo@xxxxxxxxxxxxx> > > > Cc: linux-stable <stable@xxxxxxxxxxxxxxx> # >= v3.10 > > > > > > Conflicts: > > > drivers/md/bcache/btree.c > > > > What is this for? > > > > > > > > Signed-off-by: Kent Overstreet <kmo@xxxxxxxxxxxxx> > > > --- > > > drivers/md/bcache/btree.c | 14 +++++++++----- > > > 1 file changed, 9 insertions(+), 5 deletions(-) > > > > This fails to apply to the latest 3.10-stable queue: > > checking file drivers/md/bcache/btree.c > > Hunk #1 succeeded at 1719 (offset 25 lines). > > Hunk #2 succeeded at 1780 (offset 25 lines). > > Hunk #3 succeeded at 1844 (offset 25 lines). > > Hunk #4 FAILED at 1851. > > 1 out of 4 hunks FAILED > > > > What did you make this patch against? > > *swears* > > Sorry, I mailed that out quickly without looking/remembering what was going on. > This patch depends on two other upstream patches that I initially didn't think > were important enough to backport, but changed my mind on because of user > feedback and other bugs. > > Could you instead pull from my writeback fixes branch? It's got fixes that I've > backported and those specific backports have seen actual outside testing: the > fixes aren't as minimal as would be ideal but making it more minimal would mean > rewriting too much stuff. > > The commit messages have all been marked with the upstream SHA1, and it merges > cleanly with the latest 3.10 stable. For 3.11 I'll need to redo the backports, > it looks like. > > The following changes since commit 4e77f7f1261f65cff06918bc5e66d02a418fc842: > > Linux 3.10.18 (2013-11-04 04:31:29 -0800) > > are available in the git repository at: > > git://evilpiepirate.org/~kent/linux-bcache.git bcache-3.10-writeback-fixes Can you just give me the 5 git commit ids that I should use, and in what order to pull them in? That works better than a random git tree from a random server that I don't know anything about... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html