On Thu, Aug 19, 2010 at 11:57:53AM +0200, Tejun Heo wrote: > On 08/18/2010 11:46 AM, Christoph Hellwig wrote: > > FYI: One issue with this series is that make_request based drivers > > not have to access all REQ_FLUSH and REQ_FUA requests. We'll either > > need to add handling to empty REQ_FLUSH requests to all of them or > > figure out a way to prevent them getting sent. That is assuming they'll > > simply ignore REQ_FLUSH/REQ_FUA on normal writes. > > Can you be a bit more specific? In most cases, request based drivers > should be fine. They sit behind the front most request_queue which > would discompose REQ_FLUSH/FUAs into appropriate command sequence. I said make_request based drivers, that is drivers taking bios. These get bios directly from __generic_make_request and need to deal with REQ_FLUSH/FUA themselves. We have quite a few more than just dm/md of this kind: arch/powerpc/sysdev/axonram.c: blk_queue_make_request(bank->disk->queue, axon_ram_make_request); drivers/block/aoe/aoeblk.c: blk_queue_make_request(d->blkq, aoeblk_make_request); drivers/block/brd.c: blk_queue_make_request(brd->brd_queue, brd_make_request); drivers/block/drbd/drbd_main.c: blk_queue_make_request(q, drbd_make_request_26); drivers/block/loop.c: blk_queue_make_request(lo->lo_queue, loop_make_request); drivers/block/pktcdvd.c: blk_queue_make_request(q, pkt_make_request); drivers/block/ps3vram.c: blk_queue_make_request(queue, ps3vram_make_request); drivers/block/umem.c: blk_queue_make_request(card->queue, mm_make_request); drivers/s390/block/dcssblk.c: blk_queue_make_request(dev_info->dcssblk_queue, dcssblk_make_request); drivers/s390/block/xpram.c: blk_queue_make_request(xpram_queues[i], xpram_make_request); drivers/staging/zram/zram_drv.c:blk_queue_make_request(zram->queue, zram_make_request); -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
