mason@suse.com said:
> Ok, I'll try to narrow the barrier usage a bit, I'm waiting on the
> barrier write once it is sent, so I'm not worried about anything done
> after the ordered tag.
> write X log blocks (simple tag) write 1 commit block (ordered tag)
> wait on all of them.
> All I care about is knowing that all of the log blocks hit the disk
> before the commit. So, if one of the log blocks aborts, I want it to
> abort the commit too. Is this a little easier to implement?
Actually, I'm afraid not. The FS has the notion of a transaction to help it
with this. All the SCSI driver sees is a list of IOs with some requests for
ordered tags. If we go into error recovery and have to abort a tag, how do we
know which of the outstanding ordered tags is actually the commit block for
this transaction? (Remember also that a FS sits on a partition, not a physical
SCSI device, so even if you single thread your commits per FS, there could
still be multiple FSs on the same physical device).
That's why I think it's safer to abandon the abort entirely. If our first
line of error recovery is device reset, we know we've just cleared the entire
outstanding tag queue and we can resend all the tags in FIFO order which means
that we still don't need a concept of "transaction" at the SCSI level (which
is a good thing, I think), all we need to know is the order in which the tags
came to us.
Even if some tags were committed but not acknowledged at reset time, it's
still safe to resend them in the correct ordered sequence because of
transaction idempotence of block writes.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:01:08 EST