tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal: B_ARRIER (addresses wapbl performance?)



On Tue, Dec 09, 2008 at 01:30:10PM -0800, Jason Thorpe wrote:
> >But to enforce that using FUA, you have to set FUA on *every* write.
> 
> The only thing you have to ensure is that journal is consistent and on- 
> disk before the other metadata blobs.

I don't think it's so simple. I think there's also metadata writes that
needs to happen *before* journal writes.

> So use FUA and wait for the  
> journal writes to complete BEFORE ISSUING the other writes.

OK, so you use software barrier, not the ones provided by disks
(this is what was not clear).
But I think with this we'll end up issuing mostly FUA writes, because
ordering constraint are both way. So it won't be any better than
running simple queue tags with the write cache disabled (what we're
doing now).

> 
> >And I do not understand the "only way" in your remark above.  Under
> >the constraint "if WCE is set in the cache control page" I agree that
> >it is correct.  But as far as I can tell, if WCE is *not* set, it is
> >not in fact the case that using FUA is the "only way" to ensure that
> >writes are committed to stable storage in order -- because the tag
> >ordering rules require ordered tags to complete, um, well, in-order,
> >and if WCE is not set, commands are not supposed to complete until
> >the bits are on oxide.
> >
> >I am sure I am misunderstanding something.  What?
> 
> Turning off the write cache makes things too bloody slow.

With tagged queuing and simple queue tag it's not my experience.

> You can get  
> consistency and good performance if you manage the cache on a per- 
> command basis.

But if you end up issuing most write commands FUA, you're in the same case
as with the write cache disabled.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index