Posts

Showing posts from April, 2011
Understanding your (Red Hat Enterprise Linux) daemons by Len DiMaggio A Unix daemon is a program that runs in the “background,” enabling you to do other work in the “foreground,” and is independent of control from a terminal. Daemons can either be started by a process, such as a system startup script, where there is no controlling terminal, or by a user at a terminal without “tying up” that terminal as the daemon runs . But which daemons can you safely play with? Which should you leave running? An introduction to daemons The real-world (i.e., non-computer) definition of “daemon” is either a spirit (an evil one) or an inner or private voice. It’s interesting to note that each of the real-world definitions actually does apply to Unix daemon programs. Like mythological daemons, Unix daemon programs skulk around unseen in the background just as a daemon would. And daemons act like an inner voice in that they can run continuously and, like a conscience, can always be accessed. The word “dae

SUN Multiple Path

Solaris 10 does support FB SAN; but not on SCSI. To enable it, edit the /kernel/drv/fp.conf file. mpxio-disable="no"; Below is an example of a host which has two fibre channel controllers (c4 and c5) connected to the sam SAN, and both see the same target LUNs, of which there are four: cfgadm -al -o show_SCSI_LUN So, the aforementioned scsi_vhci driver sees that LUN 6000393000015463,0 is presented by two controllers. It will then make a new disk device using that device’s WWN, LUN, and other information to construct a globally-unique ID (GUID) device name and then create device entries under /dev/dsk and /dev/rdsk to represent a multipathed view: You might notice the new controller, c6. This is a “virtual” controller implemented by scsi_vhci since making such virtual disk devices under a real physical controller would be a broken idea since, technically, there is no such physical device. Remember, this is a meta device.