Re: [RFC] relaxed barrier semantics

[Christoph Hellwig <hch@lst.de>]

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.