On 07/28/2010 10:08 AM, Tejun Heo wrote: > Having writeback cache or not doesn't make any difference > w.r.t. request ordering requirements. If filesystems don't need the > heavy handed ordering provided by barrier, it should just use flush > instead of barrier. If filesystem needs the barrier ordering, whether > the device in question is battery backed and costs more than a house > doesn't make any difference. BTW, if filesystems already have code to order the requests they're issuing, it would be *great* to phase out barrier and replace it with simple in-stream, non-ordering flush request. There have been several different suggestions about how to improve barrier and most revolved around how to transfer more information from filesystem to block layer so that block layer can use more relaxed orderign, but the more I think about it, it becomes clear that it doesn't belong to block layer at all. The only benefit of doing it in the block layer, and probably the reason why it was done this way at all, is making use of advanced ordering features of some devices - ordered tag and linked commands. The latter is deprecated and the former is fundamentally broken in error handling anyway. Furthermore, although they do relax ordering requirements from the device queue side, the level of flexibility is significantly lower compared to what filesystems can do themselves. So, yeah, let's phase it out if it isn't too difficult. Thanks. -- tejun -- 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
