Hide Forgot
In "pool" (GFS pool) formatted VGs, the metadata is distributed across multiple PVs in a non-redundant fashion. We can't currently cope with this in pvscan --cache, marking such PVs orphans and getting into all sort of trouble when we try to do something with them (while lvmetad is active). The options are, either extend pvscan --cache to open multiple devices when we encounter a pool signature, or flat out refuse to deal with the pool-format VG.
(This currently trips the pool-labels.sh upstream test in a fairly nasty way -- pvcreate is sent into an infinite loop when PVs are unexpectedly juggled between lists during a traversal.)
If format pool metadata is encountered and lvmetad is in use, issue a WARNING: Ignoring old GFS pool metadata on device %s when using lvmetad Ideally pvcreate/vgcreate/vgextend should still warn about the metadata and prompt rather than silently overwriting it, so lvmetad might still need to record that the PV contains an unsupported metadata format.
Well, I made pvscan --cache ignore pool labels as a stopgap. However, it doesn't seem to be particularly easier to add "unsupported PV type" code than to properly load up pool metadata in pvscan --cache. The only bit that really interferes is that format_pool peeks directly into lvmcache. I think I can fix that though. It will be slightly inefficient, but the hit will only happen when udev events come in for pool-formatted PVs, which wouldn't be often, and would run asynchronously in the background anyway.
So I think we might still need to add WARNINGs to some code paths if pool (or format1) metadata is detected. (Treat it the same way as we treat non-lvm metadata like md perhaps?) In other words, we should not overwrite such metadata silently.
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.
The comment above is incorrect. The correct version is bellow. I'm sorry for any inconvenience. --------------------------------------------------------------- This request was NOT resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you need to escalate this bug.
We currently test this by writing out a hand-crafted pool label on a device. I don't know how hypothetical or real the use-case is, or whether there are any pool-formatted PVs out in the wild. As Alasdair points out, the only use-case here might be that we want to avoid overwriting the metadata/labels in this format accidentally (without a confirmation). Nonetheless, we could also ignore the pool format completely and probably never hit an issue.
We cleanly ignore pool metadata in pvscan --cache since bd3edb2566189e1e3e016933e397a58a90bc81ea (december 2013); we have decided that this level of treatment is sufficient for pool-format metadata for lvmetad-enabled systems.