On Fri, Mar 25, 2011 at 10:14 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> +static int mmc_blk_issue_flush(struct mmc_queue *mq, struct request *req)
>> +{
>> + struct mmc_blk_data *md = mq->data;
>> +
>> + /*
>> + No-op, only service this because we need REQ_FUA
>> + for reliable writes.
>> + */
>> + spin_lock_irq(&md->lock);
>> + __blk_end_request_all(req, 0);
>> + spin_unlock_irq(&md->lock);
>> +
>> + return 1;
>> +}
>
> How does this work when you have a flush that does not directly follow
> a REQ_FUA or REQ_META request? I would assume that we still need to
> flush in some way, which you don't seem to do here.
>
Arnd,
I confirmed with two MMC vendors that there is no "flush". Once the
DAT transfer completes, the data is stored on non-volatile storage as
soon as the busy status is cleared.
Reliable writes are still "more reliable" because if the DAT transfer
is interrupted (power or reset through CMD0/CMD15 or hw pin for eMMC),
you have predictable flash contents. So it makes sense to map REQ_FUA
to it (and REQ_META, I would guess).
What do you think?
A
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
