[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [PATCH 6/6] dm cache: add cache block invalidation support

On Mon, Nov 11, 2013 at 12:20:48PM -0500, Mike Snitzer wrote:
> From: Joe Thornber <ejt redhat com>
> 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

> +++ 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!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]