I don't think that's accurate.  The elevator code has a dispatch function which takes a "force" argument, and in that code path, i.e. CFQ has this:

/*
 * Drain our current requests. Used for barriers and when switching
 * io schedulers on-the-fly.
 */
static int cfq_forced_dispatch(struct cfq_data *cfqd)
{
        struct cfq_queue *cfqq; 
        int dispatched = 0;

        /* Expire the timeslice of the current active queue first */
        cfq_slice_expired(cfqd, 0);
        while ((cfqq = cfq_get_next_queue_forced(cfqd)) != NULL) {
                __cfq_set_active_queue(cfqd, cfqq);
                dispatched += __cfq_forced_dispatch_cfqq(cfqq);
        }

CFQ knows how to handle barriers, as far as I know.

Sorry, the original question was about running *without* barriers.
Let me re-think this.

As Jeff Moyer says:

> The file system will manually order dependent I/O.
> What I mean by that is the file system will send down any I/O for the
> transaction log, wait for that to complete, issue a barrier (which will
> be a noop in the case of a battery-backed write cache), and then send
> down the commit block along with another barrier.  As such, you cannot
> have the I/O scheduler reorder the commit block and the log entry with
> which it is associated.