On Wed 05 Oct 2016 05:35:20 PM CEST, Max Reitz <mre...@redhat.com> wrote:
>>> Apart from that, I have to say I think it would be a bit more useful >>> if one would specify the area covered by the metadata caches as an >>> absolute number instead of a relative one (I guess it's generally >>> easier to know what area your applications will perform random >>> accesses on than the relative size, but maybe that's just me). >> >> I'm not sure if I'm following you, can you give an example of what >> the area covered by the cache exactly means? > > Let's take the L2 table cache. Every eight bytes of that cache point > to one cluster in the image, so if it's 8 MB in size, for instance, > then you can cover 1M clusters. With the default 64 kB clusters, you > would cover 64 GB of any image (although you have some constraints on > that range, of course; an 8 MB cache would contain not just 1M cluster > pointers but actually 128 L2 tables (8 MB / 64 kB), so it would > actually cover 128 continuous 512 MB ranges). Ah! You mean that instead of saying l2-cache-size=1M, you would say l2-cache-coverage=8G, so the user doesn't need to do the numbers. I thought you were talking about something different, that's why it didn't make any sense to me :-) Well, I don't know, if we had to design the interface again from the beginning I guess it could make sense, but I don't think it's a good idea to have two ways to specify exactly the same thing, when one can be converted to the other with a very simple operation. I admit the formula is not directly obvious (that's why I documented it in docs/qcow2-cache.txt), but it's very simple. I guess it wouldn't be so bad if we restricted it only to the command line (for humans), since any program that communicates using QMP can do the numbers itself. I don't know... how about a helper script that checks the cluster size and tells you how much cache you need? Berto