On Fri, 2008-08-08 at 12:30 +0200, Jens Axboe wrote: > Not at all, please re-read that part. I objected to adding a strategy > hook just for setting cmd type and flags for discard. Ah, now I understand what you were saying. And I vacillated about that too -- I actually suggested to Gilad that we didn't want it, but then went ahead and did it anyway. Adding the ->discard_fn hook provides two features: Firstly, it allows an early 'abort' of discard requests where the device doesn't support them -- there's no point in allocating the request and passing it down to the device to be discarded there, when we can just notice that there's no ->discard_fn and return immediately from blkdev_issue_discard(). Secondly, it allows drivers to insert the appropriate command onto their queue -- I expect that SCSI and ATA drives won't use REQ_TYPE_DISCARD, just as they don't use REQ_TYPE_FLUSH. They'll use REQ_TYPE_BLOCK_PC with whatever opcode is allocated for trim/punch. We _could_ address those two differently -- maybe we could add a QUEUE_FLAG_DISCARDS in q->queue_flags to indicate that discard requests are supported, and we could make the driver 'translate' from REQ_TYPE_DISCARD to whatever it actually wants to do. But that seems strangely different to how we handle flushes, which is what I was basing my implementation on. -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
