Messages in this thread | | | Date | Thu, 4 Dec 2008 11:45:44 -0500 (EST) | From | Mikulas Patocka <> | Subject | Re: 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
| |