So you can easily reproduce this? If so, that's _awesome_ news - would you be willing to try out a debug kernel with some tracing stuff added? Maybe we can finally nail this. On Mon, Apr 22, 2013 at 12:15 PM, Jack Wang <jinpu.wang@xxxxxxxxxxxxxxxx> wrote: > Hi all, > > We've seen strange behaviour in bcache mode in current bcache-testing > branch with Possible allocator fix: > > Once I start writing data with "dd if=/dev/zero of=/dev/bcache0 bs=4k > count=10000 oflag=sync", all SSDs in the Pool go close to 100% util and > I see about 3600 writes/second in iostat for each disk in the pool, BUT > no data written in means of throughput. > > Then after some seconds (the flush interval of bcache) I see the flush > of the writeback and also data written to the pool SSDs which looks > pretty much like reordering and merging happened for that data. > > bcache-3.2 does not have such problem. > only bcache(master) and bcache-testing have such problem. > > What's the possible reason? > > Regards, > Jack > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html