How to remove the major/minor number?

[Senthilkumaran.T]

Hi,
I deleted the group file from /dev/tz_vg02 and trying to recreate it. The mknod command gives me the following error message.

/dev/tz_vg02> mknod group -c 64 0x020000
usage: mknod name b|c major minor
mknod name p

It looks like major number is already exist. Could you help me to remove the major/minor number from the system, so that I can use the mknod command.

Thanks for your help in advance.

[Denver Osborn · Accepted solution]

The message from mknod being returned is stating the syntax usage. Use this syntax:

mknod group c 64 0x020000

Just omit the - from the c.

[Varghese Mathew]

Hi Senthil,

Use the command in this way of syntax...

#mknod group c 64 0x020000

Check out the man pages too of mknod.., its very clear.

Cheers !!!
Mathew

[Senthilkumaran.T]

Hi,

Thanks for your point on my syntax error. I got the following error message when I did the vgimport.

/dev/tz_vg02> vgimport -p -v -m /tmp/tz_vg02.map /dev/tz_vg02 /dev/dsk/c12t0d1 /dev/dsk/c9t0d1
Beginning the import process on Volume Group "/dev/tz_vg02".
vgimport: Warning: Volume Group belongs to different CPU ID.
Can not determine if Volume Group is in use on another system. Continuing.
vgimport: Warning: Volume Group contains "1" PVs, "2" specified. Continuing.
Volume group "/dev/tz_vg02" has been successfully created.
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating the volume group.

Vgdisplay
=========
vgdisplay -v /dev/tz_vg02
vgdisplay: Volume group "/dev/tz_vg02" does not exist in the "/etc/lvmtab" file.
vgdisplay: Cannot display volume group "/dev/tz_vg02".

Lvmtab
======
ijmsia02:[root] /> strings /etc/lvmtab
/dev/vg00
/dev/dsk/c1t6d0
/dev/dsk/c2t6d0
/dev/tz_vg01
/dev/dsk/c9t0d0
/dev/dsk/c12t0d0
/dev/cl_vg03
/dev/dsk/c9t15d7
/dev/dsk/c12t15d7

Thanks you in advance

Senthil

[Sridhar Bhaskarla]

Senthil,

If you check your command you used the option "p". So whatever you got was only a preview of the command.

Now run the same command without p, it will import the volume group.

You would have used the vgexport with -s option so that you don't have to specify the device files. I assume the other disk is the alternate.

You got the error "belongs to different cpu id" because the volume group may be already active on the other node of the Service Guard cluster. So, you can safely ignore this message if this is part of Service Guard.

Also once the vgimport is run, do not run vgchange -a y on this system as this volume group is already active on the other node.
Let's know if this is part of MC/Service Guard.

-Sri

[Senthilkumaran.T]

Hi Sri,
It works. Thanks for your reply.

I am using MC/Service Guard with 2 N-Class servers connected to XP512 via 2 FC cards. When vgexport is used with "-s" option it identify the devices but alternate and primary is not according to the orignal server vgimport. There are two FC cards and it has to be used more effective way. t seems to be, the system scan the devices according to some order. Could you advise on this issue.

Below is the pvdisplay -v output.

PV Name /dev/dsk/c9t0d1
PV Name /dev/dsk/c12t0d1 Alternate Link
PV Status available
Total PE 1760
Free PE 1760
Autoswitch On

Thanks

Senthil

[Satish Y]

Hi Senthil,

In MC/SG, on alternate node links are automaticlly interchanged.... as in ur case it seems c12t#d# is ur primary PV(and c9t#d# is alternate link) for primary server and c9t#d# is primary PV(and c12t#d# is alternate link) for ur alternate server.

Hope it is clear for u.........

Cheers...
Satish.

[Senthilkumaran.T]

Hi Satish,
No , it is not that.

In my primary server c16tod1 (= to c12t0d1) is the primary link and c13t0d1 ( = to c9t0d1) is the alternate link. I hope it helps you to answer my question.

Thanks
senthil

[Sridhar Bhaskarla]

Hi Senthil,

If your maps file were generated using the s option,I think, import process will start scanning the disks from lower instances and then import. That's why you won't get similar order.

However, it is not a problem. Here anyway, you can't really loadshare the links. So, I won't bother much about the order in which the disks are imported.

You can very well use pvchange to change the behaviour, but won't last if the server is rebooted.

-Sri

[Senthilkumaran.T]

Hi Sri,
When we use two Fibre channel card data traffic could be shared by two FC card. In this case both disk access by one FC. So what is your recomendation?

Thanks
senthil

[Varghese Mathew]

Hi Senthil,

When you import a volume group with the option "-s" then the vgimport command searches for the hard disks which contains the specific VGID as specified for each vg in the primary node (as per the specified map file). Once it finds the disks with the same vgid then the vg information then the actual import takes place..

It is not unusual that you are getting different device name in this kind of setup, its very normal.

Cheers !!!
Mathew

[Sridhar Bhaskarla]

Senthil,

If I want to make use of both the fiber channels, I will create two LUNs on the XP256 and then create logical volumes across these two by either strinping with larger stripes or
by extent level striping depending on the application. For ex if I have the following LUNs

Pri Alt
/dev/dsk/c3t0d1 /dev/dsk/c5t0d1
/dev/dsk/c5t0d2 /dev/dsk/c3t0d2

Now I will distribute a logical volume across
both the disks and make c5t0d2 as the primary link. This way both the disks will be accessed all the times through both the channels.

Here you have no choice as there is only one disk and you can put it only on either of the paths.

A point of discussion - Theoritically we may think that it would improve the performance. But I have been seeing no much improvement. So as long as your I/O bandwidth is within the limit (which is the case most of the times), you will not see any throughput gain.

-Sri

[Tim D Fulford]

To answer the question a few boxes above. If you want your disks in a particular order you have a couple of choices.

1 ) # vgimport -m disk1 disk2 disk3....
do this such that disk1, 2 3 ... is the order of your disks. If you exported your map file with the -s option (VGIDs) the above may not work! make sure you do the vgexport with out -s (or, if you feel brave delete the VGID from the first line of the map file!!! I do not know if this works)

2) If you did use the -s option on vgexport the belt & braces way of doing 1 is
This will incorrectly create your vg
# vgimport -s -m
create a new mapfile without the -s option
# vgexport -m
Re-import your disks in correctly
# mkdir /dev/
# mknod /dev//group c 64 0x??0000
# vgimport -m disk1 disk2 disk3 disk4 ....

3) vgimport -s -m
if you do a strings on /etc/lvmtab youll see the the disks ordered numerically. you probably want to alternate them. You can vgreduce & vgextend the disks e.g

# strings /etc/lvmtab
/dev/vg01
/dev/dsk/c1t1d0
/dev/dsk/c1t2d0
/dev/dsk/c3t1d0
/dev/dsk/c3t2d0

# vgreduce vg02 /dev/dsk/c1t2d0
# vgextend vg02 /dev/dsk/c1t2d0

# strings /etc/lvmtab
/dev/vg01
/dev/dsk/c1t1d0
/dev/dsk/c3t1d0
/dev/dsk/c3t2d0
/dev/dsk/c1t2d0

If you have more disks this will take some time but you can juggle them about


I would do 1 or 2. But if the VG is established you can do 3 on-line (carefully)

Tim