[linux-lvm] Possible bug in thin metadata size with Linux MDRAID
zkabelac at redhat.com
Thu Mar 9 11:53:57 UTC 2017
Dne 9.3.2017 v 12:24 Gionatan Danti napsal(a):
> On 08/03/2017 19:55, Zdenek Kabelac wrote:
>> If you do NOT specify any setting - lvm2 targets 128M metadata size.
>> If you specify '--chunksize' lvm2 tries to find better fit and it happens
>> to be slightly better with 256M metadata size.
>> Basically - you could specify anything to the last bit - and if you
>> don't lvm2 does a little 'magic' and tries to come with 'reasonable'
>> defaults for given kernel and time.
>> That said - I've in my git tree some rework of this code - mainly for
>> better support of metadata profiles.
>> (And my git calculation gives me 256K chunksize + 128M metadata size -
>> so there was possibly something not completely right in version 166)
> 256 KB chunksize would be perfectly reasonable
>>> Why I saw two very different metadata volume sizes? Chunksize was 128
>>> KB in
>>> both cases; the only difference is that I explicitly specified it on the
>>> command line...
>> You should NOT forget - that using 'thin-pool' without any monitoring
>> and automatic resize is somewhat 'dangerous'.
> True, but I should have no problem if not using snapshot or overprovisioning -
> ie when all data chunks are allocated (filesystem full) but no
> overprovisioned. This time, however, the created metadata pool was
> *insufficient* to even address the provisioned data chunks.
Hmm - it would be interesting to see your 'metadata' - it should be still
quite good fit 128M of metadata for 512G when you are not using snapshots.
What's been your actual test scenario ?? (Lots of LVs??)
But as said - there is no guarantee of the size to fit for any possible use
case - user is supposed to understand what kind of technology he is using,
and when he 'opt-out' from automatic resize - he needs to deploy his own
Otherwise you would have to simply always create 16G metadata LV if you do not
want to run out of metadata space.
> I am under impression that 128 KB size was chosen because this was MD chunk
> size. Indeed further tests seem to confirm this.
Ahh yeah - there was small issue - when the 'hint' for device geometry was
used it has started from 'default' 64K size - instead of already counted 256K
More information about the linux-lvm