1753475 Members
4851 Online
108794 Solutions
New Discussion юеВ

Re: device files

 
SOLVED
Go to solution
Waugh
Frequent Advisor

device files

Hi ,

What is the difference between these device files. Which i can use for clustering purpose. how to check the no of lun assigned to server.

/dev/cciss/c0d0p1
/dev/sdb
/dev/md5

Thanks,
Rkumar
7 REPLIES 7
Matti_Kurkela
Honored Contributor

Re: device files

/dev/cciss/c0d0p1 = HP SmartArray disk: controller 0, disk 0, partition 1.

/dev/sdb = generic SCSI/FC/SATA/USB/Firewire/whatever disk: b = 2nd disk in detection order, whole disk.

/dev/md5 = 5th Linux software RAID device. With Linux 2.4 kernel series this might also be a multipath device; in 2.6 kernel series, multipath devices are handled differently. Run "cat /proc/mdstat" to get more information about this device.

> Which I can use for clustering purposes?

Not enough information about your hardware and software configuration to answer that with any certainty.

> How to check the no of lun assigned to server?

"cat /proc/scsi/scsi" may provide this information.

If you use RedHat Enterprise Linux 5, the "lsscsi" command (optional, installable from RHEL5 RPMs) gives this information in a more useful format.

MK
MK
Waugh
Frequent Advisor

Re: device files

Hi Matti Kurkela ,

Thanks for valuable help. how to map the lun to device file like xpinfo -i gives mapping between cu:ldev no to device path . server model is DL38-339 ,storage MSA1000.
cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: COMPAQ Model: MSA1000 Rev: 5.20
Type: RAID ANSI SCSI revision: 04
Host: scsi0 Channel: 00 Id: 00 Lun: 01
Vendor: COMPAQ Model: MSA1000 VOLUME Rev: 5.20
---------------------------------------------
# uname -r
2.6.9-27.ELsmp
# cat /proc/mdstat
Personalities :
unused devices:
#

Regards,
Rkumar
Ivan Ferreira
Honored Contributor

Re: device files

Is extrange that you have /dev/md5 and no software RAID on this server.

>>> Which i can use for clustering purpose

What do you mean with "clustering purpose"? A shared LUN?

Also, see this thread:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1365890
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Waugh
Frequent Advisor

Re: device files

Hi Ivan,

Yes i m trying to form the 2 node cluster and packages. yes share LUN.

Regards,
Rkumar
James Brand
Frequent Advisor

Re: device files

You can use GFS for clustering but there is a licensing cost if you are running RHEL4. With release 5 it's free. Since you appear to be running RHEL4 you might want to upgrade.
skt_skt
Honored Contributor

Re: device files

with ext3 the cluster can be configured, but in active/passive mode( not concurrent from both nodes).

what i recollect is , Red Hat cluster suit comes free with RHEL 5
Matti_Kurkela
Honored Contributor
Solution

Re: device files

Based on your service model (DL380, unknown generation) and /proc/scsi/scsi output, the likely configuration is as follows:

- the internal disks are all controlled by the integrated SmartArray at /dev/cciss/c0*
- the internal CD-ROM does not interfere with disk naming
- the /dev/sd* devices are all from the MSA1000 storage.

If the MSA configuration has not been changed since the system was booted, /dev/sda is Lun 0 of the MSA and /dev/sdb is Lun 1.

Lun 0 may be a storage control interface which can be used to remotely configure the MSA if you have the proper configuration utilities and passwords. If so, it isn't really useable as a disk, although it may be detected as such. "fdisk -l /dev/sda" could be used to verify this: if the size of the "disk" is too small to be of practical use, it is most likely the control interface.

(Some systems require that any SCSI/FC device must always have Lun 0, therefore it's logical to put the control interface there.)

/dev/sdb is most likely the LUN you've allocated from the MSA to this server.

The lack of a proper tool to map between Lun numbers and /dev/sd* devices is a known problem in RHEL 3 and 4. HP has a "fibreutils" RPM package which contains some tools to remedy this. Despite the package name, the commands "lssd" and "lssg" in the package are not restricted to FibreChannel disks only: they can be used to get some information on any /dev/sd* and /dev/sg* devices, respectively.

MK
MK