Red Hat Bugzilla – Bug 174700
pvcreate should warn before destroying filesystem metadata
Last modified: 2013-05-15 22:29:13 EDT
LVM2 pvcreate needs changing to look for the various filesystem types and
display a warning if found.
[split off from bugzilla 168330]
Possibly lvm2 should wipe/detect swap partition signature.
*** Bug 112082 has been marked as a duplicate of this bug. ***
This bugzilla had previously been approved for engineering
consideration but Red Hat Product Management is currently reevaluating
this issue for inclusion in RHEL4.6.
Is this meant to avoid overwriting?
Is this necessary in the light of pvcreate undo facility that is to be
introduced as well (#174701)? I can see the benefit of having both, question
is whether this is worth the effort.
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time. This request will be
reviewed for a future Red Hat Enterprise Linux release.
I have thought a bit about this, it could be achieved by either using
the "file" utility, which can identify most (all?) filesystems, either
externally, or taking the relevant bits of code and "magic" data for
filesystems and maintain this separately. Thoughts? Alasdair? Could go into
4.7 i suppose. Another option is libparted or so, but this is an external
dependency (or we could link statically? i think this is frowned upon) or the
redhat-cluster's libiddev, but i have absolutely no idea what is the status of
that lib (i just noticed its existence).
External dependencies have to be optional at 'configure' time. Our static
binaries should have gone by RHEL6 and this is not critical initrd functionality
The pros and cons of the various options as to which library to use need to be
determined - something actively-maintained with low-maintenance on our part, and
something that will fit into the new udev model and not become redundant.
We probably should also detect partition tables the same way we want to detect
filesystems. Also, I have noticed, that if you put a partition table on a PV,
the label stays intact and the device is still seen as a pv. How much is that
a problem? Eg. file(1) can be instructed to print all types it detects
(with -k) and therefore can say:
/dev/loop0: LVM2 (Linux Logical Volume Manager) , UUID:
- x86 boot sector
- , extended partition table (last)
The problem is more general than this of course, but we can still detect the
partition table this way and print the warning.
As for external dependencies... From looking at file(1) source, we need the
filesystem magic file (not that big, easy to update too) and the softmagic
test code. However, I tend to think, that it may be more trouble than worth,
ripping out the parts of the code we are going to use. It may be actually
easier to turn file into a library and link it in. The interesting entry point
const char *magic_file(struct magic_set *ms, const char *inname)
which returns the above information formatted in a text buffer. We can then
examine this buffer and decide if there is anything interesting in there.
However, it may still be easier and more convenient, to fork & exec the file
utility installed on the system (and dependencies can ensure it is really
present, so we can probably make the "no file(1) found" problem equivalent
to "filesystem or partition table detected" (with a different warning of
course). Overridable by -f or such. And making this a configure-time option
should be easy enough as well.
Product Management has reviewed and declined this request. You may appeal this
decision by reopening this request.