On 2013年04月22日 22:19, Kent Overstreet wrote: > 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. > > Thanks for reply, Kent, two of my colleagues saw this behaviour, so I think we can reproduce this. If you could give me more detailed guide to narrow it down, I can try it on my side. Regards, Jack > On Mon, Apr 22, 2013 at 12:15 PM, Jack Wang <jinpu.wang@xxxxxxxxxxxxxxxx > <mailto: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 > <mailto: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
