I'm thankful for this change making it explicit that this parameter is not a max IO length but something else. I've been confused by the name more than once when trying to figure out why IOs weren't coming in as large as I expected. I wish there were a way for targets to say "I can accept IO of up to $len" without saying "I want my IO split if it crosses a multiple of $len, no matter what size it is", and I'm thankful for this step making it easier if I ever act on that wish... Boundary doesn't quite strike me as the clearest word, but the words that come to mind, alignment and granularity, seem to describe other concepts, at least when it comes to discards. Perhaps zone_granularity or zone_boundary might be clearer, since all the targets that use it have a concept of a 'zone' or a 'block' and don't want an IO to need work in multiple blocks/zones. >+ /* If non-zero, I/O submitted to a target must not cross this boundary. */ Sounds like the I/O sender is responsible for making sure the I/Os don't cross the boundary, at least to me. Perhaps this wording might be clearer? /* If non-zero, I/O submitted to a target will be split so as to not straddle any multiple of this length (in bytes) */ Thanks! John -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel