On Wed 16-12-15 00:12:23, Mike Snitzer wrote: > On Tue, Dec 15 2015 at 9:38pm -0500, > Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > > > >>>>> "Bart" == Bart Van Assche <bart.vanassche@xxxxxxxxxxx> writes: > > > > Bart> Should the caller of blkdev_issue_discard() implement this or > > Bart> should this functionality be added in blkdev_issue_discard() > > Bart> itself ? > > > > I'm very much against dropping information in the ioctl/filesystem > > submission path. But I am not against having a helper function of some > > sort that DM and target could use to handle heads and tails. > > > > Right now DM does not handle this and I think it would be worthwhile to > > have. Mike, what are your requirements? > > If the discard doesn't conform to the device's stacked discard limits > then yes the head and/or tail will get dropped on the floor. > > Not sure why DM is being made the focal point on this. Are you thinking > specifically about DM-thinp and its discard_granularity? DM thinp > doesn't support partial thinp block discards -- so misaligned/partial > discards are dropped by DM thinp. There isn't a compelling case for > fixing this (by adding a bitset for each thinp block to support finer > grained discards) -- at least not that I'm aware of. > > But I'm missing exactly what it is your helper function would do... and > yet you're asking me what my requirements are.. sorry ;) I agree that just dropping head & tail from misaligned discard request looks reasonable. However I think the original motivation for this thread was actually blkdev_issue_zeroout(). That ends up being implemented using blkdev_issue_discard() and in that case silently dropping head and tail is not an option. Supporting non-aligned blkdev_issue_zeroout() via submitting properly aligned blkdev_issue_discard() and then just submitting writes with zeros for head & tail would look useful to me. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
