Hi Arnd, On Fri, Mar 25, 2011 at 10:14 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Thursday 24 March 2011, Andrei Warkentin wrote: >> >> Beyond REQ_FUA/REQ_META, this was meant to be used by a following patch that aimed >> to reduce write amplification issues in cards employing a small (usually flash page-sized) >> buffer and a large (usually erase-block sized) buffer, at the expense of performance. > > Looks good to me, but I don't really understand some of the block layer > specifics here. One question: > 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. In much the same way as before - REQ_FLUSH does nothing as it did nothing before. The only reason I'm handing REQ_FLUSH, is because you can't register for REQ_FUA without registering for REQ_FLUSH, which does make sense - after all, if REQ_FUA is used to ensure data is committed immediately, then by default it isn't, and you need a flush operation if you want to commit the data at a particular checkpoint You are correct in stating that it is a likely issue, but it is an issue even without this patch. Unfortunately, there is nothing (that I saw) in the latest JEDEC MMC specification that says how a card's internal buffers might be forced to be flushed to non-volatile storage. Clearly, any recent card which tries to play optimization games in order to reduce write amplification and flash wearing is going to have an internal buffer, so the inability to handle REQ_FLUSH is already a potential issue for these cards. Looking at the 4.41 JEDEC spec, CMD0, CMD15 and hardware reset are all non-ways to ensure flush. In fact they will terminate the programming operation resulting in an unknown state. I'm working with a flash vendor to see if I missed something or if there is some way to flush internal buffers, and if that way is generic enough to apply to all cards. 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
