On 2011-09-30 07:33, Christoph Hellwig wrote:

On Fri, Sep 09, 2011 at 10:58:01AM +0200, Jens Axboe wrote:

quoted

quoted

 - handling of REQ_FUA / REQ_FLUSH requests is completely broken.
   There is a weird barrier flag to mtip_hw_submit_io which set the
   hwardware FUA bit if the FLUSH bit is set on a request.
   Please take a look at how this should be handled, the
   Documentation/block/writeback_cache_control.txt file is the canonical
   resource.  Implementing your driver at the make_request layer
   unfortunately means you will have to do all the hard work yourself.

I noticed both of these flush/fua problems too and have fixed them up.

I sitll can't find anything doing that in your tree while all kinds of
other patches are in.  In fact I can't find a place that sends
ATA_CMD_FLUSH/ATA_CMD_FLUSH_EXT commands, not the required queue
draining for it.

And this stuff really makes me nervous - we get a driver for a new,
expensive high end device and there seems absolutely no concern for
data integrity, or testing of it.

I'm away from home, so changes have been coming in through the laptop.
But don't worry about the driver, it's sort-of in a staging position at
the moment. Before Micron has resolved the issues around queueing etc,
it's not going to be merged into mainline.

Or does the device not even have a volatile cache at all, and we could
just remove the FUA code?  In this case it should be clearly documented
in the driver.

See reply from Micron folks, there's no write back cache currently.

-- 
Jens Axboe