Re: Device loses barrier support (was: Fixed patch for simplebarriers.)

From: Mikulas Patocka
Date: Thu Dec 04 2008 - 11:46:33 EST

> > > > finished after the 2nd write) and you are in an interrupt context, where
> > > > you can't reissue -EOPNOTSUPP request. So what do you want to do?
> > >
> > > The barrier aware file systems I know of just resubmit synchronously when
> > > a barrier fails.
> >
> > ... and produce structure corruption for certain period in time, because
> > the writes meant to be ordered are submitted unordered.
> No there is nothing unordered. The file system path typically looks like
> commit of a transaction
> if (i have never seen a barrier failing)
> write block with barrier
> record failure
> submit synchronously
> }
> } else
> submit synchronously

If you view this as a "right" way of using barriers, then you can drop
barrier support at all and replace this code sequence with:

flush disk cache
submit write synchronously
flush disk cache

--- because synchronous barriers bring you no performance advantage over
the above sequence.

> So if a pvmove barrier fails it will just submit synchronously.
> The write block with barrier bit varies, jbd/gfs2 do it synchronously
> too and xfs does it asynchronously (with io done callbacks), but

And how does xfs preserve write ordering, if the barrier asynchronously
fails with -EOPNOTSUPP and there are other writes submitted after the

> in both cases they handle an EOPNOTSUPP comming out in the final
> io done.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at