mirror of
git://sourceware.org/git/lvm2.git
synced 2025-01-18 10:04:20 +03:00
fcfca57e2e
When using lvm shell, some structures which are cached in memory may be reused. This happens for the struct label (a part of lvmcache_info structure) when lvmetad is used in which case the PV scan is not done that would normally overwrite these label structures in memory and making them up-to-date. This is all consequence of the fact that struct lvmcache_info and struct label are not always assigned in the same part of the code. For example, if lvmetad *is not* used, parts of the struct label are reassigned in label_read fn while struct lvmcache_info is created elsewhere. No part of the code reused struct label (and its "dev" field) before calling label_read fn. That's why the real bug is hidden when using lvm shell without lvmetad. However, with lvmetad and lvm shell, the situation is a bit different. The label_read fn is not called if lvmetad *is* used, hence the struct label may have ended up not initialized properly. There was missing assignment for the dev field in struct label in _text_pv_write fn which caused this problem to appear in lvm shell with lvmetad, for example: Before this patch: lvm> pvcreate /dev/sda Physical volume "/dev/sda" successfully created lvm> pvs /dev/sda PV VG Fmt Attr PSize PFree unknown device lvm2 --- 128.00m 128.00m With this patch applied: lvm> pvcreate /dev/sda Physical volume "/dev/sda" successfully created lvm> pvs /dev/sda PV VG Fmt Attr PSize PFree /dev/sda lvm2 --- 128.00m 128.00m Also, this problem had not appeared before changes introduced by commits e1a63905d14cc73352b905c70cb4084b7e521e33 through 3a6f91d7139119bea664050a957cbc21490398bc which, among other things, added proper label field type reporting. Before, label reporting was the same as using struct physical_volume which has its own dev field assigned and so this problem was not exposed.