pvcreate -f /dev/dsk/cXtYdZ of an existing live PV !

[Stuart Abramson]

I did a pvcreate -f /dev/dsk/c187t0d0 on the Alternate path of a PV already in a VG on my system. Both primary and alternate paths are recorded in /etc/lvmtab.

To my great surprise no problem has occurred. No error messages. No messages in dmesg or syslog.log. No user complaints. if you cd /directory and ll -R all files are visible. pvdisplay -v /dev/dsk/c187t0d0 looks completely good.

I ran the pvcreate -f in a script and didn't see the output. I only noticed that my new PV didn't get added to the VG (because I had pvcreated the WRONG VG.).

I immediately called my colleague over. He speculated that "pvcreate -f" will NOT write on a PV that is already recorded in the /etc/lvmtab. The man page doesn't say that.

What do you think? Are we okay or will some error occur in two weeks?

[James R. Ferguson · Accepted solution]

Hi Stuart:

Your colleague is correct. You cannot annihilate a physical volume with the force (-f) flag if it is recorded in /etc/lvmtab.

Regards!

...JRF...

[Florian Heigl (new acc)]

You should better verify that everything is ok... do a vgcfgrestore /dev/.

Also I'd be curious if really something changed, but one can hardly tell without knowing the old PV ID (gathered from disk with `oc`)

[Thomas J. Harrold]

Don't be so sure that nothing has happened. I've had *active* VG's where someone has over-written the PV headers. Initially there are no symptoms, but you'll see problems when you de-activate/re-activate the VG.

Use vgcfgrestore to restore the proper header to the PV.

-tjh

[Stuart Abramson]

I believe that you're all three right.

I did an "xd" to get the VGID and it looks good.

I also have had trouble crop up months later when you do something different, such as vgexport/vgimport; so I'm going to be a little nervous for some months yet...