Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 174700 - pvcreate should warn before destroying filesystem metadata
pvcreate should warn before destroying filesystem metadata
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Petr Rockai
: FutureFeature
: 112082 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-12-01 10:43 EST by Alasdair Kergon
Modified: 2013-05-15 22:29 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-08-26 08:40:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alasdair Kergon 2005-12-01 10:43:58 EST
LVM2 pvcreate needs changing to look for the various filesystem types and
display a warning if found.

[split off from bugzilla 168330]
Comment 1 Alasdair Kergon 2006-03-15 10:32:17 EST
Possibly lvm2 should wipe/detect swap partition signature.

Comment 2 Alasdair Kergon 2006-03-15 10:32:21 EST
*** Bug 112082 has been marked as a duplicate of this bug. ***
Comment 6 RHEL Product and Program Management 2007-03-09 20:11:28 EST
This bugzilla had previously been approved for engineering
consideration but Red Hat Product Management is currently reevaluating
this issue for inclusion in RHEL4.6.
Comment 7 Rob Kenna 2007-05-22 11:52:40 EDT
Is this meant to avoid overwriting?
Comment 8 Alasdair Kergon 2007-05-22 13:00:44 EDT
unintentional overwriting
Comment 9 Petr Rockai 2007-05-23 12:30:22 EDT
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.
Comment 10 RHEL Product and Program Management 2007-09-07 15:46:38 EDT
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.
Comment 11 Petr Rockai 2007-11-10 06:27:51 EST
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).
Comment 13 Alasdair Kergon 2007-11-10 11:17:25 EST
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.
Comment 14 Petr Rockai 2007-11-27 09:51:54 EST
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 
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.

Comment 16 RHEL Product and Program Management 2008-08-26 08:40:03 EDT
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.