Remove Duplicate LVs?

[Justin Willoughby]

A while back we had some problems after upgrading to HP/UX 11.00 where one of our VG was gone after the upgrade. It was recreated twice, once with the correct LV names and once with random lvol# names.

What it looks like is the correct LV names and the incorrect lvol# names seem to be pointing to the same data. Only the correct LV names are being used.

Any ways I did not realize this until a week or two as the correct LV names were being used the application.

My question is, can I simply remove the random lvol#'s without causing any problem to the actaul data that they point to?

# lvremove /dev/vgname/lvol#
Where lvol# is the lvol with it's number.

Thanks,

- Justin

[Justin Willoughby]

Opps, probably should have posted this to the LVM group... I thought about that after I hit the 'SUBMIT' button... Sorry.

- Justin

[Emiel van Grinsven]

Hi,

lvremove will destroy all data on the filesystem.
guess you'd better take a look at lvreduce and see if you can acomplish what you want with it.

grt, E

[James R. Ferguson]

Hi Justin:

Do *not* use 'lvremove' unless you want to destroy the logical volume!

You can simply 'rm' the files 'dev/vgxx/yyy' that represent the erroneous names.

It sounds like you didn't 'vgimport' with a mapfile after your cold installtion.

Regards!

...JRF...

[James Beamish-White]

It sounds like you don't need to remove the lvol#'s, but to rename them the right way. If you need to do this, then you can just change the references in /etc/fstab.

Otherwise, the lvremove command should not work on any device that is currently mounted, so you should be safe. Just make sure that your backus are good ;-)

Cheers,
James

[harry d brown jr]

NO, do not use the lvmremove command!!!!! It could be pointing to a GOOD LV.

Just cd to the /dev/vg## directory and "rm" the BAD LV device files!!!

Do and "ls -l" from the /dev/vg## directory and check the LV's MINOR numbers to see what is pointing to what.

You might also need to rename the lvmtab file and do a vgscan.



live free or die
harry

[pap]

Hi You can do one thing .

first try to check the used data in LV using lvdisplay.
Also try to mount any one of the random lv to a directory. IF it is mounted and you can see the contents that is not required, then you can use "lvremove" to remove the logical volume.
Before doing removal operation it is better to take full backup of the system.

-pap

[Helen French]

Justin,

DONOT remove the LV with 'lvremove' if you have data on that. That will erase the data and the LV. If you just want to get rid of the lvnames, do 'rm' on /dev/vgxx.

Also check 'rmsf' command too.

HTH,
Shiju

[harry d brown jr]

Let's say you have these LV's:

brw-r----- 1 root sys 64 0x00000a Sep 4 2001 lvol1
brw-r----- 1 root sys 64 0x00000a Aug 13 2001 lvol9


and lvol9 is the one you know is bad. THEY BOTH POINT TO THE SAME AREA (64 0x00000a) IN THE VG!!!! So if you do a lvmreduce or lvmremove you will TOAST lvol1 also!!!!

live free or die
harry

[Justin Willoughby]

They are raw LVs so I can???t mount them plus they are being used.

Sounds like I should just be able to rm the duplicate names right? Do I need to do any thing else to let the system know these are gone or is rm'ing them enough?

Thanks for everyone's replies so far!

- Justin

[Darrell Allen]

Hi Justin,

Just want to be sure the LVs are really duplicates. How did you determine that? Does lvdisplay -v /dev/vgname/lvol# show the same extents being used are lvdisplay -v on the correct lv?

Darrell

[Helen French]

Hi Justin,

Just 'rm' will be fine. You don't need to do anything else. Make sure that you are not removing anything which is used now.

HTH,
Shiju

[John Carr_2]

Hi

if you can see the data as you have said I would backup to tape. zap the lv's then rebuild newones and restore from tape.

This way you dont risk loosing the data.

cheers
John.

[Justin Willoughby]

Darrell,

I know they are duplicates because there should not be any LVs named lvol# in this VG. They only showed up after the upgrade when the vendor was trying to fix the problem with the VG being gone. They must have done some thing wrong and then fixed it. This left the wrong named LVs there.

In addition, in GlancePlus I see two LV's with the same IO, so that makes me belive they are pointint to the same extents. The lvol#s should not be in use, but the data they point to is/should.

- Justin

[Justin Willoughby]

Attached is the output from vgdisplay -v venvg

venvg is used in place of the actaul vg name.

I am sure if you add up all the lvol#'s and all the dbname lv's you will see it is twice the about for the vg.

Will just rm's the files get rid of them from showing up with vgdisplay or is more needed?

Can what is needed be done online while the system is running and applicaton(s) are accessing the correct /dev/venvg/dbname.* LVs?

Thanks!

- Justin

[Darrell Allen]

I'd feel better knowing you've followed up on Harry's suggestion to check minor numbers on the device files. Try:
ll | grep ^b | sort -k6,6

If you see duplicates, then you chould be able to delete the dups. And for each block special file you delete, delete the character one also.

I've never had this type problem before. I wonder if the VGRA on the disks in your vg are okay?

Anyone know how to verify the VGRA?

Darrell

[Sandip Ghosh]

I assume you are already having the map file for that Volume Group.

Do a vgexport for that volume group and then again do vgimport with the map file. When you do vgexport all of your entry will go and when you do vgimport with the map file, it will bring back the original name.

Again, you should have the original mapfile before doing this.

Sandip

[Justin Willoughby]

Darrell,

Yes there is duplicates (block numbers), see attached file.

- Justin

[Darrell Allen]

Hi again,

As info, I can't open your attachment.

As others have said, I believe it is okay to simply rm the duplicate special files.

I haven't found how to verify the VGRA on the disks but if vgdisplay -v venvg (which I believe looks at /etc/lvmtab but not the VGRA on your disks) looks good after removing the special files, I'd suggest doing the following to ensure the vg info on the disks is okay:
vgcfgbackup venvg
vgcfgrestore -n venvg /dev/rdsk/c0t4d0
vgcfgrestore -n venvg /dev/rdsk/c1t5d0

As a precaution, make a backup of /etc/lvmtab and the /etc/lvmconf directory.

Darrell

[Justin Willoughby]

I can't open the attachment either... That's odd, I thought I was able to yesterday.. Lets try it again...

I guess I will just rm the files and see if that works. Can I do the vgcfgbackup and
vgcfgrestore while the vg is being used? I assume I can do the vgcfgbackup while the vg is being used but I am wondering about the vgcfgrestore.

Thanks!

- Justin

[Justin Willoughby]

Ignore this I am trying a test attachment. I don't understand what the problem is with the other attachment I have tried to attach twice.

- Justin

[Justin Willoughby]

Ok, lets see if this attachment works. I have no idea what the this one is not working. Maybe it will this time. It's the ll/ls -l listing.

- Justin

[Justin Willoughby]

I just don't get why the attachment is not working... It's just a text/ascii file. Oh well. Part of it looks like this:

brw-r----- 1 root sys 64 0x010001 Sep 16 2001 dbname.bila
brw-r----- 1 root sys 64 0x010001 Sep 16 2001 lvol1
brw-r----- 1 root sys 64 0x010002 Sep 16 2001 dbname.jn2a
brw-r----- 1 root sys 64 0x010002 Sep 16 2001 lvol2
brw-r----- 1 root sys 64 0x010003 Sep 16 2001 dbname.v01a
brw-r----- 1 root sys 64 0x010003 Sep 16 2001 lvol3
brw-r----- 1 root sys 64 0x010004 Sep 16 2001 dbname.v03a
brw-r----- 1 root sys 64 0x010004 Sep 16 2001 lvol4

- Justin

[Darrell Allen · Accepted solution]

Yes, vgcfgbackup and vgcfgrestore are fine to use while the vg is active.

Darrell