On Mon, Nov 11, 2013 at 12:20:48PM -0500, Mike Snitzer wrote: > From: Joe Thornber <ejt@xxxxxxxxxx> > Cache block invalidation is removing an entry from the cache without > writing it back. Cache blocks can be invalidated via the > 'invalidate_cblocks' message, which takes an arbitrary number of cblock > ranges: > invalidate_cblocks [<cblock>|<cblock begin>-<cblock end>]* If we're expecting to need to invalidate a large number of ranges, should we switch this over to hexadecimal like we did for dm-switch? Should we consider changing this to <cblock>+<length> as the dm interfaces tend to work with a start offset and a length? Or will it be that the userspace interface will not be the bottleneck in this code so it really doesn't matter about attempting to optimise that part? > +++ b/Documentation/device-mapper/cache.txt > The test suite can be found here: > -https://github.com/jthornber/thinp-test-suite > +https://github.com/jthornber/device-mapper-test-suite It's really not good if URLs in existing documentation become invalid like this: Could an obvious pointer be placed at the old location to direct people to the new location? Can we document whether or not all the ranges will have been invalidated before the message returns? > + if (!passthrough_mode(&cache->features)) { > + DMERR("cache has to be in passthrough mode for invalidation"); Can we document this too? > @@ -2841,6 +3054,12 @@ static int cache_message(struct dm_target *ti, unsigned argc, char **argv) > + if (!strcmp(argv[0], "invalidate_cblocks")) strcasecmp please! Alasdair -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
