[announce] scsi_id 0.1 - generate unique scsi id

[announce] scsi_id 0.1 - generate unique scsi id

[Patrick Mansfield]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

Attached is version 0.1 of scsi_id, a program to generate a SCSI unique
identifier for a given SCSI device.

It is primarily for use with udev callout config entries. It could also be
used for automatic multi-path configuration.

It generates and uses a temporary dev entry based on the values found in
sysfs dev attributes. This means it does not support SCSI drivers that do
are not currently creating dev entries (st or sg). In addition, for this
to function with st (assuming you have a tape drive that supports page 0x80
or page 0x83) st would have to support SG_IO.

It uses the SG_IO ioctl to send SCSI INQUIRY page 0x80 or page 0x83
commands to the SCSI device.

Requires:

- Linux kernel 2.6

- libsysfs 

No man page yet.

libsysfs 0_2_0 was not installing libsysfs.h or dlist.h, manually copy
those files to /usr/include/sys before compiling.

Build via make and make install.

To use with udev, in short:

Run scsi_id to dump a value, for example, for sda, run:

	scsi_id  -s /block/sda

Take the resulting value (including white space) and use it as the ID in a
udev CALLOUT entry, an exmample /etc/udev/namedev.config entry for one of
my disk drives:

CALLOUT, PROGRAM="/sbin/scsi_id" BUS="scsi", ID="SIBM OEM DCHS09X 68078621" NAME="disk-1"

I have not tried using scsi_id (or udev) via initramfs or initrd.

Please send me any questions, comments or patches.

Thanks!

-- Patrick Mansfield

[-- Attachment #2: scsi_id-0.1.tar.gz --]
[-- Type: application/x-gzip, Size: 19559 bytes --]

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Christoph Hellwig]

On Tue, Oct 21, 2003 at 04:58:57PM -0700, Patrick Mansfield wrote:
> libsysfs 0_2_0 was not installing libsysfs.h or dlist.h, manually copy
> those files to /usr/include/sys before compiling.

Umm, libsysfs isn't installing headers into /usr/include/sys, is it?
Especially with something like dlist.h that sounds like yet another
linked list implementation..

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Daniel Stekloff]

On Wed, 2003-10-22 at 07:31, Christoph Hellwig wrote:
> On Tue, Oct 21, 2003 at 04:58:57PM -0700, Patrick Mansfield wrote:
> > libsysfs 0_2_0 was not installing libsysfs.h or dlist.h, manually copy
> > those files to /usr/include/sys before compiling.
> 
> Umm, libsysfs isn't installing headers into /usr/include/sys, is it?
> Especially with something like dlist.h that sounds like yet another
> linked list implementation..



Patrick told me about this, we will change libsysfs to install headers
there. Is there another linked list implementation that you'd recommend?
We couldn't include list.h like Greg did in udev because we are keeping
libsysfs LGPL and we didn't want the overhead of glibc.

Thanks,

Dan


> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Daniel Stekloff <dsteklof@us.ibm.com>

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Christoph Hellwig]

On Wed, Oct 22, 2003 at 12:42:16AM -0700, Daniel Stekloff wrote:
> > Umm, libsysfs isn't installing headers into /usr/include/sys, is it?
> > Especially with something like dlist.h that sounds like yet another
> > linked list implementation..
> 
> 
> 
> Patrick told me about this, we will change libsysfs to install headers
> there.

??

s/there/not there/

> Is there another linked list implementation that you'd recommend?

I'd recommend not to expose your linked list implementation to
libsysfs users.  If you really need it might be best to use <sys/queue.h>
although it's quite ugly.  But if dlist.h is the one from evms is certainly
much much better than that one 8)

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Daniel Stekloff]

On Wed, 2003-10-22 at 07:46, Christoph Hellwig wrote:
> On Wed, Oct 22, 2003 at 12:42:16AM -0700, Daniel Stekloff wrote:
> > > Umm, libsysfs isn't installing headers into /usr/include/sys, is it?
> > > Especially with something like dlist.h that sounds like yet another
> > > linked list implementation..
> > 
> > 
> > 
> > Patrick told me about this, we will change libsysfs to install headers
> > there.
> 
> ??
> 
> s/there/not there/


The headers are being installed into /usr/local/include, I believe this
can be configured differently using autoconf tools. If they should be
installed elsewhere by default, please let us know.

Patrick told us that we weren't even installing headers. Don't mind me,
need more tea. 


> > Is there another linked list implementation that you'd recommend?
> 
> I'd recommend not to expose your linked list implementation to
> libsysfs users.  If you really need it might be best to use <sys/queue.h>
> although it's quite ugly.  But if dlist.h is the one from evms is certainly
> much much better than that one 8)

Dlist was written and submitted to us by Eric Bohm. I looked at a couple
implementations, including some from IBM, but liked Eric's more. I will
take a look at queue.h, I didn't even know it was there.


Thanks,

Dan


-- 
Daniel Stekloff <dsteklof@us.ibm.com>

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Matthew Wilcox]

On Wed, Oct 22, 2003 at 01:05:21AM -0700, Daniel Stekloff wrote:
> The headers are being installed into /usr/local/include, I believe this
> can be configured differently using autoconf tools. If they should be
> installed elsewhere by default, please let us know.
> 
> Patrick told us that we weren't even installing headers. Don't mind me,
> need more tea. 

You shouldn't be installing them into the <sys/> namespace, that's
basically owned by POSIX.  How about <sysfs/> instead?

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Patrick Mansfield]

On Wed, Oct 22, 2003 at 04:52:31PM +0100, Matthew Wilcox wrote:
> On Wed, Oct 22, 2003 at 01:05:21AM -0700, Daniel Stekloff wrote:
> > The headers are being installed into /usr/local/include, I believe this
> > can be configured differently using autoconf tools. If they should be
> > installed elsewhere by default, please let us know.
> > 
> > Patrick told us that we weren't even installing headers. Don't mind me,
> > need more tea. 
> 
> You shouldn't be installing them into the <sys/> namespace, that's
> basically owned by POSIX.  How about <sysfs/> instead?

I incorrectly suggested we should use <sys/>. 

Should we use <linux/>, rather than another new directory?

And sorry for getting the hogplug list address wrong.

-- Patrick Mansfield
wrong.

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Christoph Hellwig]

On Wed, Oct 22, 2003 at 09:15:19AM -0700, Patrick Mansfield wrote:
> Should we use <linux/>, rather than another new directory?

No.  <linux/> is reserved for kernel headers.

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Jes Sorensen]

>>>>> "Patrick" == Patrick Mansfield <patmans@us.ibm.com> writes:

Patrick> On Wed, Oct 22, 2003 at 04:52:31PM +0100, Matthew Wilcox
Patrick> wrote:
>> You shouldn't be installing them into the <sys/> namespace, that's
>> basically owned by POSIX.  How about <sysfs/> instead?

Patrick> I incorrectly suggested we should use <sys/>.

Patrick> Should we use <linux/>, rather than another new directory?

Rule of thumb: any existing hierachy is reserved, either you want to
drop it in header root, ie. /usr/include or /usr/loca/include or you
want to create your own hierachy, <sysfs/> as Matthew suggested looks
like a good candidate to me.

Cheers,
Jes

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Steven Dake]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]


On Tue, 2003-10-21 at 16:58, Patrick Mansfield wrote:
> Attached is version 0.1 of scsi_id, a program to generate a SCSI unique
> identifier for a given SCSI device.
> 
> It is primarily for use with udev callout config entries. It could also be
> used for automatic multi-path configuration.
> 
Patrick,
Here is a quick hack I wrote to do automatic multipath configuration
some time ago.  It works with devfs only but could be modified by
someone interested to work with other device names.

It also uses the extended inquiry page 83 to retrieve a IEEE id.

Cheers
-steve

> It generates and uses a temporary dev entry based on the values found in
> sysfs dev attributes. This means it does not support SCSI drivers that do
> are not currently creating dev entries (st or sg). In addition, for this
> to function with st (assuming you have a tape drive that supports page 0x80
> or page 0x83) st would have to support SG_IO.
> 
> It uses the SG_IO ioctl to send SCSI INQUIRY page 0x80 or page 0x83
> commands to the SCSI device.
> 
> Requires:
> 
> - Linux kernel 2.6
> 
> - libsysfs 
> 
> No man page yet.
> 
> libsysfs 0_2_0 was not installing libsysfs.h or dlist.h, manually copy
> those files to /usr/include/sys before compiling.
> 
> Build via make and make install.
> 
> To use with udev, in short:
> 
> Run scsi_id to dump a value, for example, for sda, run:
> 
> 	scsi_id  -s /block/sda
> 
> Take the resulting value (including white space) and use it as the ID in a
> udev CALLOUT entry, an exmample /etc/udev/namedev.config entry for one of
> my disk drives:
> 
> CALLOUT, PROGRAM="/sbin/scsi_id" BUS="scsi", ID="SIBM OEM DCHS09X 68078621" NAME="disk-1"
> 
> I have not tried using scsi_id (or udev) via initramfs or initrd.
> 
> Please send me any questions, comments or patches.
> 
> Thanks!
> 
> -- Patrick Mansfield

[-- Attachment #2: automp.c --]
[-- Type: text/x-c, Size: 10322 bytes --]

/*
 * Copyright (C) 2003 MontaVista Software, Inc.
 *
 *	Author: Steven Dake (sdake@mvista.com)
 *
 * GPL v2 License
 */
#include <sys/sysmacros.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <linux/major.h>
#include <string.h>
#include <linux/list.h>
#include <scsi/scsi.h>
#include <scsi/scsi_ioctl.h>
#include <dirent.h>
#include <stdio.h>
#include <errno.h>

#include <linux/fs.h>
#include <linux/raid/md_u.h>


struct scsi_device_strings {
	char vendor[9];
	char model[17];
	char rev[5];
	char serial[9];
};

union ieee_id_map {
	unsigned long long ieee_id;
	unsigned char ieee_id_u8[8];
};

struct scsi_device {
	struct scsi_device_strings scsi_device_strings;
	unsigned long long ieee_id;
	unsigned char lun;
	unsigned char host;
	unsigned char bus;
	unsigned char id;
	unsigned int partmap;
};

struct scsi_get_idlun {
	unsigned char id;
	unsigned char lun;
	unsigned char bus;
	unsigned char host;
	unsigned int host_unique_id;
};

struct device_number {
	int number;
	struct device_number *next;
};

struct multipath {
	struct device_number *device_number_head;
	struct scsi_device *scsi_device;
	int paths;
};

struct inquiry_command {
	unsigned int input_size;
	unsigned int output_size;
	char cmd[6];
};

struct inquiry_result {
	unsigned int input_size;
	unsigned int output_size;
	unsigned char device_type;
	unsigned char device_modifier;
	unsigned char version;
	unsigned char data_format;
	unsigned char length;
	unsigned char reserved1;
	unsigned char reserved2;
	unsigned char state;
	unsigned char vendor[8];
	unsigned char model[16];
	unsigned char rev[4];
	unsigned char serial[12];
	unsigned char reserved[39];
};

struct extended_inquiry_result {
	unsigned int input_size;
	unsigned int output_size;
	unsigned char junk[8];
	unsigned char ieee_id[8];
};


int get_scsi_device (int minor, struct scsi_device *device)
{
unsigned char ioctl_data[256];
struct inquiry_command *inquiry_command;
struct inquiry_result *inquiry_result;
struct extended_inquiry_result *extended_inquiry_result;
int fd;
int i, j;
int result;
unsigned char *p;
struct scsi_get_idlun scsi_get_idlun;
union ieee_id_map ieee_id_map;

	result = mknod ("this", 0600 | S_IFCHR, makedev (SCSI_GENERIC_MAJOR, minor));
	if (result) {
		return (-1);
	}

	fd = open ("this", O_RDWR);
	if (fd == -1) {
		unlink ("this");
		return (-1);
	}

	memset (ioctl_data, 0, sizeof (ioctl_data));
	
	/*
	 * Execute inquiry command to get SCSI serial number
	 */
	inquiry_command = ioctl_data;
	inquiry_command->input_size = 0;
	inquiry_command->output_size = sizeof (struct inquiry_result);
	inquiry_command->cmd[0] = 0x12;
	inquiry_command->cmd[1] = 0x00;
	inquiry_command->cmd[2] = 0x00;
	inquiry_command->cmd[3] = 0x00;
	inquiry_command->cmd[4] = 96;
	inquiry_command->cmd[5] = 0x00;

	result = ioctl (fd, 1, inquiry_command);

printf ("errno and result %d %d\n", errno, result);
	inquiry_result = ioctl_data;
	strncpy (device->scsi_device_strings.vendor, inquiry_result->vendor, 8);
	strncpy (device->scsi_device_strings.model, inquiry_result->model, 16);
	strncpy (device->scsi_device_strings.rev, inquiry_result->rev, 4);
	strncpy (device->scsi_device_strings.serial, inquiry_result->serial, 12);

	/*
	 * Get IEEE unique ID (FibreChannel WWN) from EVPD page 0x83
	 */
	inquiry_command->input_size = 0;
	inquiry_command->output_size = sizeof (struct extended_inquiry_result);
	inquiry_command->cmd[0] = 0x12;
	inquiry_command->cmd[1] = 0x01;
	inquiry_command->cmd[2] = 0x83;
	inquiry_command->cmd[3] = 0x00;
	inquiry_command->cmd[4] = 96;
	inquiry_command->cmd[5] = 0x00;

	extended_inquiry_result = ioctl_data;

	result = ioctl (fd, 1, inquiry_command);

	for (i = 0, j = 7; i < 8; i++, j--) {
		ieee_id_map.ieee_id_u8[j] = extended_inquiry_result->ieee_id[i];
	}

	device->ieee_id = ieee_id_map.ieee_id;

for (i = 0; i < 30; i++) {
	printf ("%02x,", extended_inquiry_result->ieee_id[i]);
}
printf ("\n\n");

	
	/*
	 * Get path to device
	 */
	result = ioctl (fd, SCSI_IOCTL_GET_IDLUN, &scsi_get_idlun);
	device->host = scsi_get_idlun.host;
	device->bus = scsi_get_idlun.bus;
	device->id = scsi_get_idlun.id;
	device->lun = scsi_get_idlun.lun;

	close (fd);

	unlink ("this");

	return (0);
}

int sd_major (int devno) {
	return (8);
}
int sd_minor (int devno) {
	return (16 * devno);
}

int g_md_minor = 255;

int get_md_minor (void) {
	return (g_md_minor--);
}

int configure_path (struct multipath *path)
{
	mdu_param_t mdu_p;
	mdu_version_t mdu_v;
	mdu_array_info_t mdu_a;
	mdu_disk_info_t mdu_d;
	int fd;
	int disk_fd;
	int result;
	char path_to_md[256];
	char path_to_disk[256];
	struct device_number *device_number;
	int i;
	int part;
	int disk_size;
	int md_minor;

	for (part = 0; part < 16; part++) {
		/*
		 * Skip when partition map bit not set
		 */
		if (part > 0 && ((path->scsi_device->partmap & (1 << part - 1)) == 0)) {
			continue;
		}
		md_minor = get_md_minor ();

		sprintf (path_to_md, "/dev/md/%d", md_minor);
		fd = open (path_to_md, O_RDONLY);

		result = ioctl (fd, RAID_VERSION, &mdu_v);

		if (part == 0) {
		sprintf (path_to_disk, "/dev/scsi/host%d/bus%d/target%d/lun%d/disc",
			path->scsi_device->host,
			path->scsi_device->bus,
			path->scsi_device->id,
			path->scsi_device->lun);
		} else {
		sprintf (path_to_disk, "/dev/scsi/host%d/bus%d/target%d/lun%d/part%d",
			path->scsi_device->host,
			path->scsi_device->bus,
			path->scsi_device->id,
			path->scsi_device->lun,
			part);
		}

		disk_fd = open (path_to_disk, O_RDONLY);
		result = ioctl (disk_fd, BLKGETSIZE, &disk_size);
		disk_size = disk_size / 2;
		close (disk_fd);
		
		mdu_a.active_disks = path->paths;
		mdu_a.working_disks = path->paths;
		mdu_a.level = -4;
		mdu_a.size = disk_size;
		mdu_a.raid_disks = path->paths;
		mdu_a.md_minor = md_minor;
		mdu_a.not_persistent = 1;
		mdu_a.state = 0;
		mdu_a.spare_disks = 0;
		mdu_a.failed_disks = path->paths;
		mdu_a.nr_disks = 2;
		mdu_a.layout = 0;
		mdu_a.chunk_size = 0;
		result = ioctl (fd, SET_ARRAY_INFO, &mdu_a);

		device_number = path->device_number_head;
		for (i = 0; i < path->paths; i++) {
			mdu_d.number = i;
			mdu_d.raid_disk = i;
			mdu_d.state = 6;
		mdu_d.major = sd_major (device_number->number);
		mdu_d.minor = sd_minor (device_number->number) + part;

		result = ioctl (fd, ADD_NEW_DISK, &mdu_d);
		device_number = device_number->next;
		}

		memset (&mdu_p, 0, sizeof (mdu_param_t));
		mdu_p.personality = -4;
		mdu_p.chunk_size = 0;

		result = ioctl (fd, RUN_ARRAY, &mdu_p);
		printf ("Multipath created: /dev/md/%d.\n", md_minor);
	}
}

int main (void)
{
struct scsi_device scsi_device_array[256];
struct multipath mp_table[256];
int i, j, next_loc, new_entry;
int result;
int scsi_device_count;
struct device_number *devno;
int print_device_list = 0;
int print_mp_list = 1;
DIR *dir;
off_t basep;
unsigned char buffer[1024];
char path_to_device[128];
struct dirent *dirent;
int part;
int part_count;
int fd;

	for (i = 0; i < 256; i++) {
		result = get_scsi_device (i, &scsi_device_array[j]);
		if (result == 0) {
			j++;
		}
	}

print_device_list = 1;
	if (print_device_list) {
		for (i = 0; i < j; i++) {
			printf ("device [%d] vendor [%s] model [%s] rev [%s] serial [%s]",
				i,
				scsi_device_array[i].scsi_device_strings.vendor,
				scsi_device_array[i].scsi_device_strings.model,
				scsi_device_array[i].scsi_device_strings.rev,
				scsi_device_array[i].scsi_device_strings.serial
			);
			if (scsi_device_array[i].ieee_id) {
				printf (" IEEE ID [%llx]\n", scsi_device_array[i].ieee_id);
			} else {
				printf ("\n");
			}
		}
	}

	scsi_device_count = j;

	/*
	 * Build multipath information
	 */
	for (next_loc = 0, i = 0; i < scsi_device_count; i++) {
		mp_table[next_loc].scsi_device = &scsi_device_array[i];
		mp_table[next_loc].device_number_head = 0;
		mp_table[next_loc].paths = 0;

		for (j = i; j < scsi_device_count; j++) {
			if (i == j) {
				continue;
			}
			if (memcmp (&scsi_device_array[i].scsi_device_strings, &scsi_device_array[j].scsi_device_strings, sizeof (struct scsi_device_strings)) == 0) {
				/*
				 * If this is the first found multiple path, create first link
				 */
				if (mp_table[next_loc].device_number_head == 0) {
					devno = (struct device_number *)malloc (sizeof (struct device_number));
					devno->next = 0;
					devno->number = i;
					mp_table[next_loc].device_number_head = devno;
					mp_table[next_loc].paths = 1;
				}

				/* * Create link for this new path
				 */
				devno = (struct device_number *)malloc (sizeof (struct device_number));
				devno->next = mp_table[next_loc].device_number_head;
				mp_table[next_loc].device_number_head = devno;
				devno->number = j;
				new_entry = 1;

				mp_table[next_loc].paths++;
			}
		}
		if (new_entry) {
			new_entry = 0;
			next_loc += 1;
		}
	}

	if (print_mp_list) {
		printf ("Multiple paths found:\n");
	}
	for (i = 0; i < next_loc; i++) {
		if (print_mp_list) {
			printf ("vendor [%s] model [%s] rev [%s] serial [%s]\n",
				scsi_device_array[i].scsi_device_strings.vendor,
				scsi_device_array[i].scsi_device_strings.model,
				scsi_device_array[i].scsi_device_strings.rev,
				scsi_device_array[i].scsi_device_strings.serial);
		}

		for (devno = mp_table[i].device_number_head; devno; devno = devno->next) {
			if (print_mp_list) {
				printf ("\tdevice no %d: /dev/scsi/host%d/bus%d/target%d/lun%d\t",
					devno->number,
					scsi_device_array[devno->number].host,
					scsi_device_array[devno->number].bus,
					scsi_device_array[devno->number].id,
					scsi_device_array[devno->number].lun);
			}

			sprintf (path_to_device, "/dev/scsi/host%d/bus%d/target%d/lun%d", 
				scsi_device_array[devno->number].host,
				scsi_device_array[devno->number].bus,
				scsi_device_array[devno->number].id,
				scsi_device_array[devno->number].lun);

			dir = opendir (path_to_device);
			part_count = 0;
			do {
				dirent = readdir (dir);
				if (dirent) {
					if (strncmp (dirent->d_name, "part", 4) == 0) {
						part = atoi (&dirent->d_name[4]);
						scsi_device_array[devno->number].partmap |= (1 << part - 1);
						part_count++;
					}
				}
			} while (dirent);
			closedir (dir);
			if (print_mp_list) {
				printf ("[1 disc, %d partitions]\n", part_count);
			}
		}

		printf ("\n");
	}

	for (i = 0; i < next_loc; i++) {
		configure_path (&mp_table[i]);
	}
}

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Philip R. Auld]

Hi,

Rumor has it that on Fri, Oct 24, 2003 at 02:33:05PM -0700 Steven Dake said:
> 
> On Tue, 2003-10-21 at 16:58, Patrick Mansfield wrote:
> > Attached is version 0.1 of scsi_id, a program to generate a SCSI unique
> > identifier for a given SCSI device.
> > 
> > It is primarily for use with udev callout config entries. It could also be
> > used for automatic multi-path configuration.
> > 
> Patrick,
> Here is a quick hack I wrote to do automatic multipath configuration
> some time ago.  It works with devfs only but could be modified by
> someone interested to work with other device names.
> 
> It also uses the extended inquiry page 83 to retrieve a IEEE id.
> 

In my experience code page 0x83 by itself is not always enough. There 
are high-end devices that don't return the results correctly. This leads 
to false negatives (which are safer than false positives, of course, but 
make multipath useless). I think in all of these auto-mp detection schemes 
there needs to be some mechanism for dealing with the quirks of different 
machine types. In userspace it should not be hard to have a table of some 
kind to tell such programs how to compare the results. This can also depend 
on how the system is configured as well so that adds another level of 
complexity.

Code page 0x80 does work for this array, modulo the FA port number which 
can be exposed as part of the serial number, making them look "too" unique.

I haven't gotten to try either of these programs. (Our systems have neither
devfs nor kernel 2.6). However, I've had to develop a home-grown automatic 
multipath driver and have had to deal with all of these issues. I'd very 
much like to be able to use the native Linux multipathing in the future.
So, to that end I thought I'd jump in here and offer my 2 cents.

Cheers,

Phil


> Cheers
> -steve
> 
> > It generates and uses a temporary dev entry based on the values found in
> > sysfs dev attributes. This means it does not support SCSI drivers that do
> > are not currently creating dev entries (st or sg). In addition, for this
> > to function with st (assuming you have a tape drive that supports page 0x80
> > or page 0x83) st would have to support SG_IO.
> > 
> > It uses the SG_IO ioctl to send SCSI INQUIRY page 0x80 or page 0x83
> > commands to the SCSI device.
> > 
> > Requires:
> > 
> > - Linux kernel 2.6
> > 
> > - libsysfs 
> > 
> > No man page yet.
> > 
> > libsysfs 0_2_0 was not installing libsysfs.h or dlist.h, manually copy
> > those files to /usr/include/sys before compiling.
> > 
> > Build via make and make install.
> > 
> > To use with udev, in short:
> > 
> > Run scsi_id to dump a value, for example, for sda, run:
> > 
> > 	scsi_id  -s /block/sda
> > 
> > Take the resulting value (including white space) and use it as the ID in a
> > udev CALLOUT entry, an exmample /etc/udev/namedev.config entry for one of
> > my disk drives:
> > 
> > CALLOUT, PROGRAM="/sbin/scsi_id" BUS="scsi", ID="SIBM OEM DCHS09X 68078621" NAME="disk-1"
> > 
> > I have not tried using scsi_id (or udev) via initramfs or initrd.
> > 
> > Please send me any questions, comments or patches.
> > 
> > Thanks!
> > 
> > -- Patrick Mansfield



-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Patrick Mansfield]

Philip -

On Mon, Oct 27, 2003 at 09:16:55AM -0500, Philip R. Auld wrote:

> In my experience code page 0x83 by itself is not always enough. There 
> are high-end devices that don't return the results correctly. This leads 
> to false negatives (which are safer than false positives, of course, but 
> make multipath useless). I think in all of these auto-mp detection schemes 
> there needs to be some mechanism for dealing with the quirks of different 
> machine types. In userspace it should not be hard to have a table of some 
> kind to tell such programs how to compare the results. This can also depend 
> on how the system is configured as well so that adds another level of 
> complexity.

The above generally applies even without multi-path (i.e. for use with
udev).

The scsi_id program is setup to have a callout program, I did not complete
coding it, mainly because I do not have any devices that require a
callout.

And, It is not clear if the specific code called should be a separate
program or a new function. A separate program can be released independent
of scsi_id, but that means we will need common or duplicated code: mainly
for the sg_io usage, and decoding of the result, especially the sense
data.

There is a /etc/scsi_id.config file, where devices can be optionally black
or white listed, and callout programs can be specified. This is all done
based on the vendor and optionally model (product) of the scsi device.

The config file can also be used to set global options.

-- Patrick Mansfield

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Philip R. Auld]

Rumor has it that on Mon, Oct 27, 2003 at 07:27:33AM -0800 Patrick Mansfield said:
> Philip -
> 
> On Mon, Oct 27, 2003 at 09:16:55AM -0500, Philip R. Auld wrote:
> 
> > In my experience code page 0x83 by itself is not always enough. There 
> > are high-end devices that don't return the results correctly. This leads 
> > to false negatives (which are safer than false positives, of course, but 
> > make multipath useless). I think in all of these auto-mp detection schemes 
> > there needs to be some mechanism for dealing with the quirks of different 
> > machine types. In userspace it should not be hard to have a table of some 
> > kind to tell such programs how to compare the results. This can also depend 
> > on how the system is configured as well so that adds another level of 
> > complexity.
> 
> The above generally applies even without multi-path (i.e. for use with
> udev).

I haven't gotten to play with 2.6 yet, so I'm not sure exactly what udev does. 
However, as long as scsi_id generated the same value for udev it shouldn't 
be an issue for that. It's just got to match what it found last time 
it booted to make sure it names the device node the same way, right?

Which leads to a question about how this works with udev. If it gets the same 
value for multiple paths to a devive won't udev them make a single device node?

> 
> The scsi_id program is setup to have a callout program, I did not complete
> coding it, mainly because I do not have any devices that require a
> callout.
> 
> And, It is not clear if the specific code called should be a separate
> program or a new function. A separate program can be released independent
> of scsi_id, but that means we will need common or duplicated code: mainly
> for the sg_io usage, and decoding of the result, especially the sense
> data.
> 

A separate program that is called based on the config file makes sense to me. 
It could then be independent as you say. A small general purpose dynamic sg_io 
library could remove the code duplication. 


> There is a /etc/scsi_id.config file, where devices can be optionally black
> or white listed, and callout programs can be specified. This is all done
> based on the vendor and optionally model (product) of the scsi device.
> 

That sounds good.

Cheers,

Phil


-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Patrick Mansfield]

On Mon, Oct 27, 2003 at 12:06:31PM -0500, Philip R. Auld wrote:
> Rumor has it that on Mon, Oct 27, 2003 at 07:27:33AM -0800 Patrick Mansfield said:
> I haven't gotten to play with 2.6 yet, so I'm not sure exactly what udev does. 
udev is a device naming or dynamic dev program, pretty much a replacement
for devfs. See:

http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

> However, as long as scsi_id generated the same value for udev it shouldn't 
> be an issue for that. It's just got to match what it found last time 
> it booted to make sure it names the device node the same way, right?

Yes. But broken or devices not fully supporting page 0x80 or 0x83 might
give the same id for different devices.

> Which leads to a question about how this works with udev. If it gets the same 
> value for multiple paths to a devive won't udev them make a single device node?

I'm not sure what it will do now, or how to integrate it (or not integrate
it) with multi-path. For dm/md multipath, as long as we have a way to
persistently name its block devices there is no issue. But, each of the
underlying devices should still be made available - that is, udev should
still create a separate dev entry for each path, even if the devices all
have the same identifying information.

> > And, It is not clear if the specific code called should be a separate
> > program or a new function. A separate program can be released independent
> > of scsi_id, but that means we will need common or duplicated code: mainly
> > for the sg_io usage, and decoding of the result, especially the sense
> > data.
> > 
> 
> A separate program that is called based on the config file makes sense to me. 
> It could then be independent as you say. A small general purpose dynamic sg_io 
> library could remove the code duplication. 

That is possible, but more work, and again I don't have any such devices.

AFAIK dynamic libraries won't work for initramfs or initrd. I have not
tried scsi_id with them, I don't know what the plan is for udev. But we
can use whatever solution udev comes up with ;-)

-- Patrick Mansfield

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Philip R. Auld]

Hi Patrick,

Rumor has it that on Mon, Oct 27, 2003 at 09:31:16AM -0800 Patrick Mansfield said:
> On Mon, Oct 27, 2003 at 12:06:31PM -0500, Philip R. Auld wrote:
> > Rumor has it that on Mon, Oct 27, 2003 at 07:27:33AM -0800 Patrick Mansfield said:
> > I haven't gotten to play with 2.6 yet, so I'm not sure exactly what udev does. 
> udev is a device naming or dynamic dev program, pretty much a replacement
> for devfs. See:
> 
> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
> 

That's excellent. Thanks for the pointer. (reads...)

> > However, as long as scsi_id generated the same value for udev it shouldn't 
> > be an issue for that. It's just got to match what it found last time 
> > it booted to make sure it names the device node the same way, right?
> 
> Yes. But broken or devices not fully supporting page 0x80 or 0x83 might
> give the same id for different devices.

Of course, yes, sorry. 

> 
> > Which leads to a question about how this works with udev. If it gets the same 
> > value for multiple paths to a devive won't udev them make a single device node?
> 
> I'm not sure what it will do now, or how to integrate it (or not integrate
> it) with multi-path. For dm/md multipath, as long as we have a way to
> persistently name its block devices there is no issue. But, each of the
> underlying devices should still be made available - that is, udev should
> still create a separate dev entry for each path, even if the devices all
> have the same identifying information.
> 

>From what I read about it that doesn't make sense. Udev will use the callout 
to scsi_id, get the id and use the name "disk-1" if it matches (in your 
example). What it does when it finds that it has already created "disk-1" 
I guess is the issue. It could just remake it and you'd end up only having 
a udev device for the last one found. I could be misunderstanding udev 
still though :) 

It may be that the way this is used best is to use it as a call out in udev 
if you're not doing multi-path. Then if you are using MP, configure udev to 
use scsi bus based names and have the MP detection script call out to scsi_id.
That's at least how I think I would set it up.

I like the idea of having a single place (with it's own callout or what not) that 
that generates these unique scsi device values. I think scsi_id has the promise 
to do that. 



> 
> AFAIK dynamic libraries won't work for initramfs or initrd. 

They can, but, at least for initrd, it's a little more work. Some of the more
fully funtional initrds (e.g. for NFSroot) do this. I suspect 
initramfs probably will -- it uses udev and hence libsysfs. 

>I have not
> tried scsi_id with them, I don't know what the plan is for udev. But we
> can use whatever solution udev comes up with ;-)
> 

Sounds like a plan. 


> -- Patrick Mansfield



-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Patrick Mansfield]

On Tue, Oct 28, 2003 at 09:19:20AM -0500, Philip R. Auld wrote:

> From what I read about it that doesn't make sense. Udev will use the callout 
> to scsi_id, get the id and use the name "disk-1" if it matches (in your 
> example). What it does when it finds that it has already created "disk-1" 
> I guess is the issue. It could just remake it and you'd end up only having 
> a udev device for the last one found. I could be misunderstanding udev 
> still though :) 

udev needs to somehow handle duplicates, but unless we tell it a
device is multi-pathed, it can't tell an error case (tried to give the
same name to two separate devices) from the multi-path case.

> It may be that the way this is used best is to use it as a call out in udev 
> if you're not doing multi-path. Then if you are using MP, configure udev to 
> use scsi bus based names and have the MP detection script call out to scsi_id.
> That's at least how I think I would set it up.

That is one way to configure them. The current udev would need a lot of
entries to handle all possible names - if you wanted to be able to add
a new LUN or path and have it just show up with the path in its name.

Users might also want the name of the MP device to be similiar to the
names for the paths of the device. This means udev would need to be passed
information that these are multi-pathed devices (assuming it would
otherwise create only one entry).

-- Patrick Mansfield

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Philip R. Auld]

Rumor has it that on Tue, Oct 28, 2003 at 07:06:40AM -0800 Patrick Mansfield said:

> udev needs to somehow handle duplicates, but unless we tell it a
> device is multi-pathed, it can't tell an error case (tried to give the
> same name to two separate devices) from the multi-path case.
> 

Does udev need to care about multi-pathing? I'm not sure that it does - it doesn't 
do multi-pathing, it just makes device nodes, right?

It seems that if we want the underlying paths to show up as separate named devices 
we would need to use an ID key that is different from the one that the multipath 
detection code uses so that we do get the underlying paths. That's why I 
suggested the below. 
 
If it's the same ID key, we'd be relying on udev's duplicate handling behavior and
the results would likely be order dependent. 

> > It may be that the way this is used best is to use it as a call out in udev 
> > if you're not doing multi-path. Then if you are using MP, configure udev to 
> > use scsi bus based names and have the MP detection script call out to scsi_id.
> > That's at least how I think I would set it up.
> 
> That is one way to configure them. The current udev would need a lot of
> entries to handle all possible names - if you wanted to be able to add
> a new LUN or path and have it just show up with the path in its name.
>

I would have hoped for a setting to do that without having to configure each
individual possible entry. Something that made it work similar to the scsidev utility.

> Users might also want the name of the MP device to be similar to the
> names for the paths of the device. This means udev would need to be passed
> information that these are multi-pathed devices (assuming it would
> otherwise create only one entry).
> 

Do md/dm devices get created by udev? Then the problem shows up again. 
We'd get the md device named "disk-1" as well :)

Cheers,

Phil


-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [announce] scsi_id 0.1 - generate unique scsi id

[Patrick Mansfield]

On Tue, Oct 28, 2003 at 10:40:54AM -0500, Philip R. Auld wrote:

> Does udev need to care about multi-pathing? I'm not sure that it does - it doesn't 
> do multi-pathing, it just makes device nodes, right?

Right.

> It seems that if we want the underlying paths to show up as separate named devices 
> we would need to use an ID key that is different from the one that the multipath 
> detection code uses so that we do get the underlying paths. That's why I 
> suggested the below. 


> Do md/dm devices get created by udev? Then the problem shows up again. 
> We'd get the md device named "disk-1" as well :)

They are on different busses, so udev should (but does not now) use the
bus plus the callout value to figure out the name. This is needed
independent of scsi (though only a scsi callout exists today).

-- Patrick Mansfield