On Jan 9, 2014, at 4:13 PM, Mike Snitzer wrote: > On Thu, Jan 09 2014 at 4:28pm -0500, > Brassow Jonathan <jbrassow@xxxxxxxxxx> wrote: > >> Yes, that'd be nice if we could have this. >> >> It would be great if chunk_size (i.e. cache block size) was also >> included somehow. If I had that, I could calculate the size of the >> cache using the status output alone. I won't complain much if it >> isn't there though, because I can get that from the mapping table. >> >> The reason I like adding the total number of cache blocks is because I >> /can't/ get that information from either type of status (_INFO or >> _TABLE) for the cache target. Instead, I would have to get the cache >> device from the mapping table and query that device for its size - >> possible, but the level of indirection is a pain. As it sits in the >> kernel today, it seems strange to provide some information, but not >> enough to fill in the whole picture. > > So ideally you want both the cache blocksize and the metadata blocksize. > We can easily add them, wouldn't be the end of the world. What format > seems best? > > <#used metadata blocks>/<#total metadata blocks> <metadata block size> > <#used cache blocks>/<#total cache blocks> <cache block size> > ... > > or: > > <metadata block size> <#used metadata blocks>/<#total metadata blocks> > <cache block size> <#used cache blocks>/<#total cache blocks> > ... Either is good (you posted the 2nd). Still, I don't give a crap about how much metadata is used; but if you think it's useful to others, then great. The check you mentioned to warn/error/prevent the user when providing an insufficiently sized metadata area might be nice. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
