Re: Proposal: B_ARRIER (addresses wapbl performance?)

[David Young <dyoung%pobox.com@localhost>]

On Thu, Oct 30, 2008 at 01:28:21PM -0700, Bill Stouder-Studenmund wrote:
> On Wed, Oct 29, 2008 at 05:51:09PM -0400, Thor Lancelot Simon wrote:
> > I'd like to propose a new buffer flag, B_ARRIER.  This flag would be
> > defined to cause a write barrier at whatever I/O request carries it.
> > 
> > In practice, this would mean using an ordered tag with SCSI disks
> > (because ordered tags do not complete until all prior simple-tagged
> > commands complete) and causing a cache flush for IDE disks (at least
> > until we get tagged queueing support for them).  I don't know how FUA
> > works for IDE disks but it's been suggested to me that FUA commands
> > cause all pending I/O to finish before they do -- that would suffice
> > too.
> 
> The problem is that this won't help. Ordered tags will relate the 
> sequencing of commands relative to each other. The journal, however, 
> doesn't care about the relative ordering of operations, it wants to know 
> when the writes to the journal have hit stable storage.

Bill,

That is because the journal writes must hit stable storage before the
corresponding inodes are updated, right?

> The key problem is that, on SCSI disks with the write cache enabled, a
> write command can complete by writing to the cache.
> 
> The journal needs a way to turn the cache off for one operation. That's 
> what FUA is. That's what we need.

Does FUA necessarily turn off the cache for that operation, or does it
tell the SCSI disk to wait to indicate command completion until after
the write is flushed from cache to stable storage?  It seems that letting
the disk flush a write on its own schedule is desirable, unless the host
has a backlog of disk ops that wait for the FUA write to complete.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24