On Thu, Jan 20, 2011 at 08:13:41PM +0100, Tejun Heo wrote: > On Thu, Jan 20, 2011 at 07:50:57PM +0100, Tejun Heo wrote: > > Hello, > > > > On Tue, Jan 18, 2011 at 09:12:55AM +0800, Shaohua Li wrote: > > > This makes sense. would it possible N flush data payloads delay the > > > first request? > > > > I ended up with a different design. Still buggy. It triggers a weird > > oops under stress test but other than that things generally seem to > > work as expected. Please read the comment at the top of blk-flush.c > > for more info. I'll post properly after more testing and debugging. > > The oops was caused by debugging code I put in (not posted together). > It runs fine without it, so if you have some time, please give it a > spin. Seems to run without incident on my storage test arrays. The fsync-happy performance numbers are comparable to previous iterations of flush patches. Looks good, thank you! --D -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
