lkml.org 
[lkml]   [2008]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Device loses barrier support (was: Fixed patch for simple barriers.)
> > > > 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


\
 
 \ /
  Last update: 2008-12-04 17:49    [W:0.070 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site