On Thu, 2006-02-09 at 13:12 +0900, Tejun Heo wrote: > Maybe I have misunderstood, but, AFAICS, linked task doesn't assure any > ordering relation with respect to other tasks unlike ordered tag. So, > it doesn't make much difference compared to simple & stupid ordering by > draining. For a barrier to work, the following order should be kept. It's a different paradigm from barriers. With a barrier, it's an impassable object in the I/O stream (nothing overtakes it or falls behind it). With a link, there's a set of commands (the linked set, and there may be more than one linked set of commands) that have to be ordered within the link. The point is that most of our problems with barriers are figuring out how to prevent leaks. The linked command paradigm is much more forgiving in this regard. > pre-barrier writes -> cache flush -> barrier write (FUA) -> other writes > > Issuing cache flush and barrier write with ordered tags accomplishes all > the ordering requirements (if it works, that is.). I can see linked > task can be used for 'cache flush -> barrier write (FUA)' segment but > that leaves us with two unhandled ordering requirements. Right, that's why I said we'd have to change the block layer API to use linked commands. > Another thing I'm curious about linked task is what advantages linked > task has over simply issuing and completing the commands sequentially. > Commands in a linked task has to be issued and completed sequentially > anyway, so I don't really see the difference. The fact that tasks can proceed in parallel, only the command components individual linked tasks must be serialised. so it supports the TCQ paradigm. Really, also, linked tasks is exactly what a JFS wants because most of the updates that would be linked are something like update log entry; modify metadata (or data); remove log entry. James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
