Re: [PATCH] 2.4.x write barriers (updated for ext3)

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

On Mon, Mar 04, 2002 at 09:03:31AM -0600, James Bottomley wrote:
> phillips@bonn-fries.net said:
> > But chances are, almost all the IOs ahead of the journal commit belong
> > to your same filesystem anyway, so you may be worrying too much about
> > possibly waiting for something on another partition. 
> 
> My impression is that most modern JFS can work on multiple transactions 
> simultaneously.  All you really care about, I believe, is I/O ordering within 
> the transaction.  However, separate transactions have no I/O ordering 
> requirements with respect to each other (unless they actually overlap).

Generally, that may be true but it's irrelevant.  Internally, the fs
may keep transactions as independent, but as soon as IO is scheduled,
those transactions become serialised.  Given that pure sequential IO
is so much more efficient than random IO, we usually expect
performance to be improved, not degraded, by such serialisation.

I don't know of any filesystems which will be able to recover a
transaction X+1 if transaction X is not complete in the log.  Once you
start writing, the transactions lose their independence.

> Using 
> ordered tags imposes a global ordering, not just a local transaction ordering, 
Actually, ordered tags are in many cases not global enough.  LVM, for
example.

Basically, as far as journal writes are concerned, you just want
things sequential for performance, so serialisation isn't a problem
(and it typically happens anyway).  After the journal write, the
eventual proper writeback of the dirty data to disk has no internal
ordering requirement at all --- it just needs to start strictly after
the commit, and end before the journal records get reused.  Beyond
that, the write order for the writeback data is irrelevant.

Cheers,
 Stephen