Hi Mike, (08/27/10 13:08), Mike Snitzer wrote: >> the above mentioned 'special casing' is not a hard part. >> See the attached patch. > > Yes, Tejun suggested something like this in one of the threads. Thanks > for implementing it. > > But do you agree that the request-based barrier code (added in commit > d0bcb8786) could be reverted given the new FLUSH work? No, it's a separate thing. If we don't need to care about the case where multiple clones of flush request are necessary, the special casing of flush request can be removed regardless of the new FLUSH work. > We no longer need waiting now that ordering isn't a concern. Especially The waiting is not for ordering, but for multiple clones. > so given rq-based doesn't support multiple targets. As you know, from > dm_table_set_type: > > /* > * Request-based dm supports only tables that have a single target now. > * To support multiple targets, request splitting support is needed, > * and that needs lots of changes in the block-layer. > * (e.g. request completion process for partial completion.) > */ This comment is about multiple targets. The special code for barrier is for single target whose num_flush_requests > 1. Different thing. > I think we need to at least benchmark the performance of dm-mpath > without any of this extra, soon to be unnecessary, code. If there will be no need for supporting a request-based target with num_flush_requests > 1, the special handling of flush can be removed. And since there is no such target in the current tree, I don't object if you remove that part of code for good reason. Thanks, -- Jun'ichi Nomura, NEC Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
