Re: [PATCH] ide write barrier support

[Jens Axboe <axboe@suse.de>]

On Thu, Oct 23 2003, Daniel Phillips wrote:
> On Tuesday 21 October 2003 07:40, Jens Axboe wrote:
> > On Tue, Oct 21 2003, Daniel Phillips wrote:
> > > Maybe what you're saying is, there are only two ways to deal with IDE
> > > drives with non-disablable writeback cache:
> > >
> > >   1) flush the cache on every write
> > >   2) Implement write barriers, add them to all the journalling
> > > filesystems, and flush only on the write barrier
> > >
> > > and (1) is just too slow.  Correct?
> >
> > Yes, that is exactly what I'm saying. It's not just that, though.
> > Completely disabling write back caching on IDE drives totally kills
> > performance typically, they are just not meant to be driven this way.
> 
> OK, this is still experimental development in the middle of the stability 
> freeze in order to fix a performance bug, but that's a tradition anyway so 
> let me join in.

It's not a performance bug, fer crissakes!! Do you suggest disabling
write back cache on all ide drives? People will scream bloody murder if
we do. So it's a question of data integrity.

> I'm specifically interested in working out the issues related to stacked 
> virtual devices, and there are many.  Let me start with an easy one.
> 
> Consider a multipath virtual device that is doing load balancing and
> wants to handle write barriers efficiently, not just allow the
> downstream queues to drain before allowing new writes.  This device
> wants to send a write barrier to each of the downstream devices,
> however, we have only one write request to carry the barrier bit.  How
> do you recommend handling this situation?

That needs something to hold the state in, and a bio per device. As
they complete, mark them as such. When they all have completed, barrier
is done.

That's just an idea, I'm sure there are other ways. Depending on how
complex it gets, it might not be a bad idea to just let the queues drain
though. I think I'd prefer that approach.

-- 
Jens Axboe