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

Mikulas Patocka
2008-12-04T16:46:32Z

> > > > 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
> if (EOPNOTSUPP) {
> 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
barrier?

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

Mikulas