[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0812041139200.2434@hs20-bc2-1.build.redhat.com>
Date: Thu, 4 Dec 2008 11:45:44 -0500 (EST)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Andi Kleen <andi@...stfloor.org>
cc: linux-kernel@...r.kernel.org, xfs@....sgi.com,
Alasdair G Kergon <agk@...hat.com>,
Andi Kleen <andi-suse@...stfloor.org>,
Milan Broz <mbroz@...hat.com>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists