Tejun,
--On 25 May 2011 18:43:14 +0200 Tejun Heo <tj@xxxxxxxxxx> wrote:
b) If I receive a flush command, and prior to completing that flush
Âcommand, I receive subsequent write commands, I may execute
Â(and, if I like, write, to disk) write commands received AFTER that
Âflush command. I presume if the subsequent write commands write to
Âblocks that I am meant to be flushing, I can just forget about
Âthe blocks I am meant to be flushing (because they would be
Âoverwritten) provided *something* overwritten what was there before.
The first half is correct. The latter half may be correct if there's
no intervening write but _please_ don't do that. If there's something
to be optimized there, it should be done in upper layers. It's
playing with fire.
Thanks. My specific interest in playing with this particular fire is
that my driver can only write very large collections of blocks together
to the underlying media, and the write, whilst fast in bandwidth terms,
is high latency. So, if I receive a flush request, I either have
to block handling all writes to any block in the same collection as
anything that has been written to since the last flush (which effectively
means blocking all writes to the disk), or keep processing writes
whilst I deal with the flush. On a small disk with frequent flushes,
the flush might take several tens of milliseconds. On a large disk
with infrequent flushes I might be looking at several seconds, and I
am worried about upper layers timing out.
Hmm... For bio drivers, REQ_FLUSH and REQ_FUA are best explained
together. The followings are legal combinations.
* No write data, REQ_FLUSH - doesn't have any ordering constraint
other than the inherent FLUSH requirement (previously completed WRITEs
should be on the media on FLUSH completion).
* Write data, REQ_FLUSH - FLUSH must be completed before write data is
issued. ie. write data must not be written to the media before all
previous writes are on the media.
* Write data, REQ_FUA - Write should be completed before FLUSH is
issued - ie. the write data should be on platter along with previously
completed writes on bio completion.
* Write data, REQ_FLUSH | REQ_FUA - Write data must not be written to
the media before all previous writes are on the media && the write
data must be on the media on bio completion. This is usually
sequenced as FLUSH write FLUSH.
Request based drivers only see REQ_FLUSH w/o write data and the only
rule it has to follow is that all writes it completed prior to
receiving FLUSH must be on the media on completion of FLUSH and being
smart about it might not be a good idea.
Thanks once again. My driver is currently request-based. Is there any
significant advantage converting it to be bio based?
--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
