On Fri, Sep 09, 2011 at 10:58:01AM +0200, Jens Axboe wrote: > > - 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. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html