<div dir="ltr"><div><div><div>Hi,<br><br></div>Apparently, nailgun assumes that lvm metadata size is always set to 64M [1]<br><br></div>It seems that it was defined here since the early beginning of nailgun as a project, therefore it's impossible to figure out for what purposes that was done as early commit messages are not so informative.<br><br></div><div>According to the documentation (man lvm.conf):<br></div><div><br>              pvmetadatasize — Approximate number of sectors to set aside for each copy of the metadata. Volume groups with large numbers  of physical  or  logical  volumes,  or  volumes groups containing complex logical volume structures will need additional space for their metadata.  The metadata areas are treated as circular buffers, so unused space becomes filled with an archive of the most recent previous versions of the metadata.<br><br><br><div>The default value is set to 255 sectors. (128KiB)<br></div><div><br>Quotation from particular lvm.conf sample:<br>    # Approximate default size of on-disk metadata areas in sectors.<br>    # You should increase this if you have large volume groups or<br>    # you want to retain a large on-disk history of your metadata changes.<br><br>    # pvmetadatasize = 255<br><br><br></div><div>nailgun's volume manager calculates sizes of logical volumes within one physical volume group and takes into account the size of lvm metadata [2].<br><br></div><div>However, due to logical volumes size gets rounded to the nearest multiple of PE size (which is 4M usually), fuel-agent always ends up with the lack of free space when creating logical volumes exactly in accordance with partitioning scheme is generated by volume manager.<br></div><div>Thus, tricky logic was added into fuel-agent [3] to bypass that flaw. Since 64M is way too big value when compared with typical one, fuel-agent silently reduces the size of lvm metadata by 8M and then partitioning always goes smooth.<br><br></div><div>Consequently, almost each physical volume group remains only 4M of free space. It worked fine on old good HDDs.<br><br></div><div>But when the time comes to use any FC/HBA/HW RAID block storage device which is occasionally reporting relatively huge values for minimal io size and optimal io size exposed in sysfs, then fuel-agent might end up with the lack of free space once again due to logical volume alignments within physical volume group [4]. Those alignments have been done by LVM automatically with respect to those values [5]<br><br></div><div>As I'm going to trade off some portion of reserved amount of disk space for storing lvm metadata for the sake of logical volume alignments, here're the questions:<br><br></div><div>* why was lvm metadata set to 64M?<br></div><div>* could someone shed more light on any obvious reasons/needs hidden behind that?<br></div><div>* what is the minimal size of lvm metadata we'll be happy with?<br></div><div>* the same question for the optimal size.<br></div><div><br><br>[1] <a href="https://github.com/openstack/fuel-web/blob/6bd08607c6064e99ad2ed277b1c17d7b23b13c8a/nailgun/nailgun/extensions/volume_manager/manager.py#L824">https://github.com/openstack/fuel-web/blob/6bd08607c6064e99ad2ed277b1c17d7b23b13c8a/nailgun/nailgun/extensions/volume_manager/manager.py#L824</a><br>[2] <a href="https://github.com/openstack/fuel-web/blob/6bd08607c6064e99ad2ed277b1c17d7b23b13c8a/nailgun/nailgun/extensions/volume_manager/manager.py#L867-L875">https://github.com/openstack/fuel-web/blob/6bd08607c6064e99ad2ed277b1c17d7b23b13c8a/nailgun/nailgun/extensions/volume_manager/manager.py#L867-L875</a><br>[3] <a href="https://github.com/openstack/fuel-agent/commit/c473202d4db774b0075b8d9c25f217068f7c1727">https://github.com/openstack/fuel-agent/commit/c473202d4db774b0075b8d9c25f217068f7c1727</a><br>[4] <a href="https://bugs.launchpad.net/fuel/+bug/1546049">https://bugs.launchpad.net/fuel/+bug/1546049</a> <br>[5] <a href="http://people.redhat.com/msnitzer/docs/io-limits.txt">http://people.redhat.com/msnitzer/docs/io-limits.txt</a><br><br><br></div><div>Thanks,<br></div></div></div>