2011/1/16 Tejun Heo <tj@xxxxxxxxxx>: > Hello, > > On Fri, Jan 14, 2011 at 09:00:22AM +0800, Shaohua Li wrote: >> it appears we can easily implement this in blk_do_flush, I had >> something at my hand too, passed test but no data yet. > >> Task1: ...FS.....C >> Task2: ....F......S...C >> Task3: ......F.........S..C >> F means a flush is queued, S means a flush is dispatched, C means the flush >> is completed. In above, when Task2's flush is completed, we actually can >> make Task3 flush complete, as Task2's flush is dispatched after Task3's flush >> is queued. With the same reason, we can't merge Task2 and Task3's flush with >> Task1's. > > I think this is the correct direction but we can take it further. The > only thing block layer has to guarantee is (ignoring FUA support), > > * If the flush request is empty, at least one flush is executed upon > its completion. > > * If the flush request is not empty, the payload is written only after > a preceding flush and follwed by another flush if requested. > > So, if we can combine N flushes with or without data, > > PREFLUSH -> N flush data payloads -> POSTFLUSH This makes sense. would it possible N flush data payloads delay the first request? > The following is something I hacked past few hours. I just made it > compile so it's definitely horridly broken. Please don't try to even > test it, but it should still give an idea about the direction. I'll > try to finish this early next week. I'm looking forward to seeing it. Thanks, Shaohua -- 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
