On Mon, Nov 25 2013 at 5:46pm -0500, Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > On Sun, Nov 24, 2013 at 02:25:33AM +0000, Mears, Morgan wrote: > > dmsetup message cache 0 invalidate_cblocks 10-11 > > cblock 11 will still be in the cache. > > I think that should be changed. > > It runs counter to the way LVM handles range specifications and seems > set to create avoidable ambiguity: everyone looking at any ranges in > dm/lvm would now have to check whether the last item in a range is > included or not in each context they encounter one as we would no longer > present a consistent position on this. > > To my mind, 10-11 expands to the list of integer block labels consisting > of 10 and 11, (We are not talking about intervals pulled out of a > continuous number line here: 10-10.9 would have no meaning.) I consider > blocks to be discrete objects and saying "the last numbered block listed > is always excluded" strikes me as counter-intuitive. > > The compromise we reached for dm statistics to reduce the chance of > misinterpretation was to use start+number_of_items: so 10+1 in this case > where only one block was meant to be included. I'm embracing what Joe would like to use. His preference for this syntax isn't his alone, see: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt08ch19s02.html As for targets having different meanings for ranges. People already need to pour over the table syntax of a given target if they'd like to assemble it by hand. Needing to understand the invalidate_cblocks mesaage range is "one past the end" isn't asking too much. The invalidate_cblocks interface is really intended to be used by the cache tools, not humans. I updated cache.txt to properly document the range syntax, see: http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=f0417b93a59e8f2 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
