Dne 18.12.2016 v 01:34 Ian Pilcher napsal(a):
On 12/08/2016 08:53 AM, Ian Pilcher wrote:
Running cache_repair against the metadata device gives me this error:
transaction_manager::new_block() couldn't allocate new block
I strongly suspect that my metadata device is too small. It was sized
with the algorithm that I posted to this list about a year ago:
https://www.redhat.com/archives/dm-devel/2015-November/msg00221.html
Looking at the source code for cache_metadata_size, I see that it adds
additional space for "hints", which the old algorithm didn't account
for.
I finally got around to testing my hypothesis, and I can confirm that
the size of the metadata device is indeed the problem. With a larger
metadata device, cache_repair succeeds, and I am able to assemble the
cache device.
So I obviously need to change the formula that I'm using to calculate
the size of the metadata device, which begs the question ... what is the
CANONICAL formula for doing this?
lvmcache(7) says, "The size of this LV should be 1000 times smaller
than the cache data LV, with a minimum size of 8MiB." But this is
definitely *not* the formula used by cache_metadata_size, and
cache_metadata_size seems to assume that hints will never be larger
than 4 bytes.
Hi
I'm not exactly sure what are you doing, are you maintaining your own dm cache
volumes ? (Writing your own volume manager and not using lvm2 - what is lvm2
missing/doing wrong ?)
Are you going to write also your own recovery support ?
Otherwise it's normally a business of lvm2 to maintain proper size of
cached LVs (and even resize them when needed via monitoring)
This will be necessary once we will support online resize of cache pools &
cached volumes.
From the source code of lvm2 it seems it uses about 44 bytes per cache chunk
and with some transaction overhead for metadata (this could be possible
lowered for 'smq' policy...)
Regards
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
