2008-07-23 15:50:21

by scameron

[permalink] [raw]
Subject: Re: HP (Compaq) Smart Array 5xxx controller SCSI driver


Fujita Tomonori wrote:
> I created symbolic links (neat udev rules can do automatically).
>
> clover:/home/fujita# ls -l /dev/cciss/
> total 0
> lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d0 -> /dev/sde
> lrwxrwxrwx 1 root root 9 2008-07-23 21:39 c0d0p1 -> /dev/sde1
> lrwxrwxrwx 1 root root 9 2008-07-23 21:39 c0d0p2 -> /dev/sde2
> lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d1 -> /dev/sdf
> lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d2 -> /dev/sdg
> lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d3 -> /dev/sdh
>
> The symbolic links enable users to mount the device as before.
>
> hpacucli seems to work (I didn't try all the commands but the point is
> that we can provide the ioctl compatibility):

That's pretty neat, I'm surprised that works. Obviously
you've got the needed ioctls already done.

I bet if you deleted all the logical drives it wouldn't work
anymore (because /dev/cciss/c0d0 -> /dev/sde would disappear.)

A way around that would be to present a device to the linux
kernel with 8-byte LUN address of all zeroes mapped to some
bus/target/lun. When the SCSI scan happens and the inquiry
is sent down to this address, the RAID controller will respond.
Then let sg bind to that, and get ACU to use the sg device.
(I hope it's clear what I'm saying.)

I don't know if the udev rules can be made smart enough to
point /dev/cciss/c0d0 at the sg device if there are no
logical drives, and at the first logical drive if there
is at least one. In the longer term, ACU would have to
be changed to use that sg device always rather than using
/dev/cciss/c0d0.

In the cciss driver, we always present /dev/cciss/c0d0
whether there are any logical drives or not for this reason,
a rather clunky solution.

-- steve


2008-07-24 01:37:31

by FUJITA Tomonori

[permalink] [raw]
Subject: Re: HP (Compaq) Smart Array 5xxx controller SCSI driver

CC'ed linux-scsi.

On Wed, 23 Jul 2008 10:50:05 -0500
[email protected] wrote:

>
> Fujita Tomonori wrote:
> > I created symbolic links (neat udev rules can do automatically).
> >
> > clover:/home/fujita# ls -l /dev/cciss/
> > total 0
> > lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d0 -> /dev/sde
> > lrwxrwxrwx 1 root root 9 2008-07-23 21:39 c0d0p1 -> /dev/sde1
> > lrwxrwxrwx 1 root root 9 2008-07-23 21:39 c0d0p2 -> /dev/sde2
> > lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d1 -> /dev/sdf
> > lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d2 -> /dev/sdg
> > lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d3 -> /dev/sdh
> >
> > The symbolic links enable users to mount the device as before.
> >
> > hpacucli seems to work (I didn't try all the commands but the point is
> > that we can provide the ioctl compatibility):
>
> That's pretty neat, I'm surprised that works. Obviously
> you've got the needed ioctls already done.

I've not finished ioctls but my driver supports it partly.


> I bet if you deleted all the logical drives it wouldn't work
> anymore (because /dev/cciss/c0d0 -> /dev/sde would disappear.)

Yeah, right. As you know, cciss doesn't have a global character device
for it so the tools don't work if no logical device exists.


> A way around that would be to present a device to the linux
> kernel with 8-byte LUN address of all zeroes mapped to some
> bus/target/lun. When the SCSI scan happens and the inquiry
> is sent down to this address, the RAID controller will respond.
> Then let sg bind to that, and get ACU to use the sg device.
> (I hope it's clear what I'm saying.)
>
> I don't know if the udev rules can be made smart enough to
> point /dev/cciss/c0d0 at the sg device if there are no

udev rules can execute external programs. So you can make udev rules
do whatever you want.


> logical drives, and at the first logical drive if there
> is at least one. In the longer term, ACU would have to
> be changed to use that sg device always rather than using
> /dev/cciss/c0d0.
>
> In the cciss driver, we always present /dev/cciss/c0d0
> whether there are any logical drives or not for this reason,
> a rather clunky solution.

Ideally, I think that the best solution is exporting a RAID device so
that the management tools can access to hardware via it (as other SCSI
drivers do). But we need the compatibility here. So I'm not sure. I'll
follow Mike's decision.