On Mon, May 18 2015 at 12:17pm -0400, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Mon, May 18, 2015 at 09:32:23AM -0400, Mike Snitzer wrote: > > The proposed blkdev_issue_discard_async interface allows DM (or any > > caller) to not have to concern itself with how discard(s) gets issued. > > > > It leaves all the details of how large a discard can be, etc to block > > core. The entire point of doing things this way is to _not_ pollute DM > > with code that breaks up a discard into N bios based on the discard > > limits of the underlying device. > > > > What you're suggesting sounds a lot like having DM open code > > blkdev_issue_discard() -- blkdev_issue_discard_async() was engineered to > > avoid that completely. > > Parts of it anyway. The splitting logic can still be factored into > helpers to keep the nasty details out of DM. But except for that I > think async discards should be handled exactly like async reads, writes > or flushes. OK. > And besides that generic high level sentiment I think the interface > for blkdev_issue_discard_async is simply wrong. Either you want to keep > the internals private and just expose a completion callback that gets > your private data and an error, or you want to build your own bios as > suggested above. But not one that is mostly opaque except for allowing > the caller to hook into the submission process and thus taking over I/O > completion. I'll see what I can come up with. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
