On Thu, Jul 29, 2010 at 04:02:17PM -0400, Vivek Goyal wrote: > Looks like you still want to go with option 2 where you will scan the file > system code for requirement of DRAIN semantics and everything is fine then for > devices no supporting volatile caches, you will mark request queue as NONE. The filesystem can't simply change the request queue settings. A request queue is often shared by multiple filesystems that can have very different requirements. > This solves the problem on devices with WCE=0 but what about devices with > WCE=1. If file systems anyway don't require DRAIN semantics, then we > should not require it on devices with WCE=1 also? Yes. > If yes, then why not go with another variant of barriers which don't > perform DRAIN and just do PREFLUSH + FUA (or post flush for devices not > supporting FUA). I've been trying to prototype it, but it's in fact rather hard to get this right. Tejun has done a really good job at the current barrier implementation and coming up with something just half as clever for the relaxed barriers has been driving me mad. > And then file systems can slowly move to using this non > draining barrier usage wherever appropriate. Actually supporting different kind of barriers at the same time is even harder. We'll need two different state machines for them, including the actual state in the request_queue. And then make sure when different filesystems on the same queue use different types work well together. If at all possible switching the semantics on a flag day would make life a lot simpler. -- 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
