Re: Proposal: B_ARRIER (addresses wapbl performance?)

[Thor Lancelot Simon <tls%rek.tjls.com@localhost>]

On Mon, Dec 22, 2008 at 05:44:20PM -0800, Bill Stouder-Studenmund wrote:
> 
> As to why tagging is way to painful, the problem is that tagged queuing 
> only permits one ordering. This isn't too bad with a single process 
> generating metadata. But it becomes VERY painful if you have concurrent 
> allocations going on in different files & parts of the file system.

I think it came up earlier in this thread that if you look closely at
the SCSI standard, some very curious properties of the tag ordering rules
become evident.  In particular, the whole specification seems to be
written is if the original intent was to support _multiple_ simultaneously
active sets of commands per LUN -- but, of course, the way it got
standardised, you get only one.

Do you happen to know the history of this?

> To be honest, we still haven't won much w/ FUA vs tagged queuing.
> 
> So now let's make it twenty processes each adding blocks to 20 files.
> 
> Now we have 20 FUA journal writes (many of which will get burst out in the 
> same update), then 60 FUA writes all over the disk, then 20 more FUA 
> journal writes (for the next batch of writes) and 60 more FUA metadata 
> writes.

I'm missing the reason why the intervening 60 writes must be FUA (or
ordered).  If they can use simple tags, the disk is free to reorder them
however it likes, assuming the reordering poicy is set appropriately in
the relevant mode page.  But I take your basic point: because there is
only _one_ active set of tagged commands, you cannot tell the disk that
you want _this_ ordered tag to complete after _those_ simple ones, _that_
ordered tag to complete after _those_ simple ones, and so forth -- and
that problem removes much of the potential benefit from any attempt to
use tagged queueing to implement write barriers.

Sigh.

Thor