Are you sure? I believe that dm handles bi_endio because it waits for
all in progress bio to complete before switching tables.
I'm not quite sure I understand this correctly, but the purpose of a
barrier request is to prevent the elevator from reordering requests
around a barrier. Previous requests must be completed before the
barrier, and latter requests must be executed after. That is a
sufficiently strong guarantee for careful write or journal filesystems
to ensure that a log block hits the disk before the actual transaction
blocks, and then the log block is marked as complete only after the
actual transaction. This is a weaker guarantee than a flush, and allows
for some reordering to improve performance.
Right, the barrier doesn't need to be flushed right away, so the
elevator could complete writes after the barrier if it wishes, then
complete the ones before, and finally the barrier itself. Not setting
the FUA bit allows the disk to cache the barrier write so it can be
completed sooner, but before the queue sends any more requests to the
disk, it must be flushed to ensure that the barrier has hit the media
before the new requests.
Again I am not sure I quite understand what you mean here, but only
writes issued after the barrier can complete before the barrier. Those
issued before the barrier can not overtake it in the queue.
This all seems unnecessary work.
-
