Bug 174700

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?

unintentional 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
anyway.

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: 
UtAGe7REE92hzsn97EydhWZldO6E0AJ
- 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 
would be:
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.

Thoughts?

Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request.