This is a SCSI driver for HP (Compaq) Smart Array 5xxx controllers.
SCSI people can skip the following two paragraphs.
Currently, a driver for HP (Compaq) Smart Array 5xxx controllers is
implemented as a block device driver, block/cciss.c (aka, cciss). But
the controller interface is SCSI-3 compatible. The specification says,
"A controller that supports CISS is considered to be a SCSI storage
array controller". A scsi driver for the controllers was discussed
several times.
I think that a SCSI cciss driver can be much simpler (and
maintainable) than the block cciss driver (the majority of the code
forging SCSI command can go away, we have the proper sysfs entries for
free, we can handle scsi tape drives easily etc). It would be helpful
for distributions too since they don't need stuff specific to cciss
(such as udev rules).
There isn't any easy migration path for users. So I think that we need
to keep the block and scsi drivers for cciss for some time (say two
years).
My scsi driver is still in an early stage (I tried to keep the changes
minimum). I can detect logical units, mount a file system, do lots of
I/Os, however, there are lots of TODOs in the management features.
If I can get an ACK from HP about the long-term migration of cciss to
SCSI, I'm happy to keep working on the SCSI cciss driver and maintain
it until HP takes over the driver.
The patch is available at:
http://www.kernel.org/pub/linux/kernel/people/tomo/ciss/0001-add-HP-Compaq-Smart-Array-5xxx-controller-SCSI-dri.patch
clover:/home/fujita# insmod ciss.ko
clover:/home/fujita# lsscsi
(snip)
[1:0:0:0] disk HP LOGICAL VOLUME 1.66 /dev/sde
[1:0:0:1] disk HP LOGICAL VOLUME 1.66 /dev/sdf
[1:0:0:2] disk HP LOGICAL VOLUME 1.66 /dev/sdg
[1:0:0:3] disk HP LOGICAL VOLUME 1.66 /dev/sdh
Yeah, it just works as SCSI disk, the dmesg says:
sd 1:0:0:0: [sde] Attached SCSI disk
sd 1:0:0:1: [sdf] 143305920 512-byte hardware sectors (73373 MB)
sd 1:0:0:1: [sdf] Write Protect is off
sd 1:0:0:1: [sdf] Mode Sense: 5b 00 00 08
sd 1:0:0:1: [sdf] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
I needed a different name and just stole 'ciss' from *BSD. But any
names (like hpciss) works for me.
Thanks,
Hi Tomo,
FUJITA Tomonori wrote:
> This is a SCSI driver for HP (Compaq) Smart Array 5xxx controllers.
>
YES! Finally!
> SCSI people can skip the following two paragraphs.
>
> Currently, a driver for HP (Compaq) Smart Array 5xxx controllers is
> implemented as a block device driver, block/cciss.c (aka, cciss). But
> the controller interface is SCSI-3 compatible. The specification says,
> "A controller that supports CISS is considered to be a SCSI storage
> array controller". A scsi driver for the controllers was discussed
> several times.
>
> I think that a SCSI cciss driver can be much simpler (and
> maintainable) than the block cciss driver (the majority of the code
> forging SCSI command can go away, we have the proper sysfs entries for
> free, we can handle scsi tape drives easily etc). It would be helpful
> for distributions too since they don't need stuff specific to cciss
> (such as udev rules).
>
Yes.
>
> There isn't any easy migration path for users. So I think that we need
> to keep the block and scsi drivers for cciss for some time (say two
> years).
>
> My scsi driver is still in an early stage (I tried to keep the changes
> minimum). I can detect logical units, mount a file system, do lots of
> I/Os, however, there are lots of TODOs in the management features.
>
> If I can get an ACK from HP about the long-term migration of cciss to
> SCSI, I'm happy to keep working on the SCSI cciss driver and maintain
> it until HP takes over the driver.
>
First of all, thanks, Tomo, for doing this.
It's been on my to-do list for about as long as I started looking on
the cciss code. However, some thoughts:
- Having cciss using the SCSI infrastructure is indeed far more logical.
Although it looks as if it doesn't support the SCSI spec in full
(ie no conformity claimed in the INQUIRY data) it certainly implements
quite a large subset.
- The error handling in the SCSI infrastructure is far better structured
as that one in the existing cciss driver, so the SCSI driver would
benefit from this.
- Nevertheless, the cciss driver and the corresponding sysfs / device node
layout has become the de-facto standard over the years and it will be
_hard_ to change that.
- However, given that the sysfs information from the cciss driver is quite
rudimentary I doubt if anyone will indeed notice if the _internal_ driver
is a SCSI or a block level driver, as long as the _external_ interface
(ioctl, device-node layout etc) stays the same.
Having said that I think this is the direction it should take:
- Split the existing cciss driver in two parts, one part for the
block-level interface and one for the lower-level device handling bits.
- Redo the patch based on that, so that existing code can be shared
(and fixes there would be included in both drivers).
- Add some hooks/safeguards so that only _one_ interface driver can
be loaded.
This way we would be able keep the existing functionality and allow
users to play around with the new driver.
Long-term we can start moving the driver itself to SCSI, and keeping
the existing cciss block interface only as a wrapper which adjusts
the major:minor numbers; the device-node layout can be handled by udev.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[email protected] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Markus Rex, HRB 16746 (AG N?rnberg)
> -----Original Message-----
> From: FUJITA Tomonori [mailto:[email protected]]
> Sent: Saturday, July 19, 2008 5:52 AM
> To: Miller, Mike (OS Dev)
> Cc: [email protected];
> [email protected]; [email protected];
> [email protected]
> Subject: [RFC PATCH] HP (Compaq) Smart Array 5xxx controller
> SCSI driver
>
> This is a SCSI driver for HP (Compaq) Smart Array 5xxx controllers.
>
> SCSI people can skip the following two paragraphs.
>
> Currently, a driver for HP (Compaq) Smart Array 5xxx
> controllers is implemented as a block device driver,
> block/cciss.c (aka, cciss). But the controller interface is
> SCSI-3 compatible. The specification says, "A controller that
> supports CISS is considered to be a SCSI storage array
> controller". A scsi driver for the controllers was discussed
Not really. The only resemblance we have to a SCSI controller is the fact that we hang SCSI, SAS, and SATA drives off the backend. Our implementation of the SCSI spec is cherry picked for what we need. That, of course, could be changed.
> several times.
>
> I think that a SCSI cciss driver can be much simpler (and
> maintainable) than the block cciss driver (the majority of
> the code forging SCSI command can go away, we have the proper
> sysfs entries for free, we can handle scsi tape drives easily
We already handle tape drives quite easily and one of these days I hope to satisfy Andrew to the point where he will accept my sysfs changes.
> etc). It would be helpful for distributions too since they
> don't need stuff specific to cciss (such as udev rules).
>
>
> There isn't any easy migration path for users. So I think
> that we need to keep the block and scsi drivers for cciss for
> some time (say two years).
Precisely why I am luke warm to this proposal. Who's going to help customers decide which driver to use? What if a number of customers are happy with the block driver? Who will decide for them when to switch? What if a customer is using the block driver and unknowingly upgrades to the SCSI driver? He's dead the water at best, lost his data at worst.
> My scsi driver is still in an early stage (I tried to keep
> the changes minimum). I can detect logical units, mount a
> file system, do lots of I/Os, however, there are lots of
> TODOs in the management features.
Have you taken into consideration any of the HP utilities and management agents? Those must work, period.
>
> If I can get an ACK from HP about the long-term migration of
> cciss to SCSI, I'm happy to keep working on the SCSI cciss
> driver and maintain it until HP takes over the driver.
We already have a SCSI port of the driver that is at least as functional as you decribe. But I am against it's release for the reasons stated above. If we ever decide to release the SCSI port it should be developed by HP so we can be assured that the utils and agents work as expected. That doesn't mean we wouldn't leverage some of your work. ;)
If cciss is ever released as a SCSI driver it would be best if the work was done at HP. Thank you for your efforts, Tomo. I hope you understand my position.
-- mikem
>
>
> The patch is available at:
>
> http://www.kernel.org/pub/linux/kernel/people/tomo/ciss/0001-a
> dd-HP-Compaq-Smart-Array-5xxx-controller-SCSI-dri.patch
>
> clover:/home/fujita# insmod ciss.ko
> clover:/home/fujita# lsscsi
> (snip)
> [1:0:0:0] disk HP LOGICAL VOLUME 1.66 /dev/sde
> [1:0:0:1] disk HP LOGICAL VOLUME 1.66 /dev/sdf
> [1:0:0:2] disk HP LOGICAL VOLUME 1.66 /dev/sdg
> [1:0:0:3] disk HP LOGICAL VOLUME 1.66 /dev/sdh
>
> Yeah, it just works as SCSI disk, the dmesg says:
>
> sd 1:0:0:0: [sde] Attached SCSI disk
> sd 1:0:0:1: [sdf] 143305920 512-byte hardware sectors (73373
> MB) sd 1:0:0:1: [sdf] Write Protect is off sd 1:0:0:1: [sdf]
> Mode Sense: 5b 00 00 08 sd 1:0:0:1: [sdf] Write cache:
> disabled, read cache: enabled, doesn't support DPO or FUA
>
> I needed a different name and just stole 'ciss' from *BSD.
> But any names (like hpciss) works for me.
>
>
> Thanks,
>
On Sat, 2008-07-19 at 19:52 +0900, FUJITA Tomonori wrote:
> This is a SCSI driver for HP (Compaq) Smart Array 5xxx controllers.
>
> SCSI people can skip the following two paragraphs.
>
> Currently, a driver for HP (Compaq) Smart Array 5xxx controllers is
> implemented as a block device driver, block/cciss.c (aka, cciss). But
> the controller interface is SCSI-3 compatible. The specification says,
> "A controller that supports CISS is considered to be a SCSI storage
> array controller". A scsi driver for the controllers was discussed
> several times.
>
> I think that a SCSI cciss driver can be much simpler (and
> maintainable) than the block cciss driver (the majority of the code
> forging SCSI command can go away, we have the proper sysfs entries for
> free, we can handle scsi tape drives easily etc). It would be helpful
> for distributions too since they don't need stuff specific to cciss
> (such as udev rules).
>
>
> There isn't any easy migration path for users. So I think that we need
> to keep the block and scsi drivers for cciss for some time (say two
> years).
Actually, I think we can make one (which is really required ... it's a
lot of pain to move device nodes, just look at libata). It should be
child's play to come up with a udev rule that simply does extra symbolic
links from /dev/cciss<n>c<n>p<n> to whatever the sd device is. That
should hide a lot of the problem.
The other issue is plugging the management ioctl in, but that can be
done via scsi_host->ioctl.
James
On Tue, 22 Jul 2008 09:02:41 +0200
Hannes Reinecke <[email protected]> wrote:
> > There isn't any easy migration path for users. So I think that we need
> > to keep the block and scsi drivers for cciss for some time (say two
> > years).
> >
> > My scsi driver is still in an early stage (I tried to keep the changes
> > minimum). I can detect logical units, mount a file system, do lots of
> > I/Os, however, there are lots of TODOs in the management features.
> >
> > If I can get an ACK from HP about the long-term migration of cciss to
> > SCSI, I'm happy to keep working on the SCSI cciss driver and maintain
> > it until HP takes over the driver.
> >
> First of all, thanks, Tomo, for doing this.
> It's been on my to-do list for about as long as I started looking on
> the cciss code. However, some thoughts:
>
> - Having cciss using the SCSI infrastructure is indeed far more logical.
> Although it looks as if it doesn't support the SCSI spec in full
> (ie no conformity claimed in the INQUIRY data) it certainly implements
> quite a large subset.
I'm not sure about this. The ciss spec says that the controllers
support mandatory SCSI commands. About INQUIRY data, at least, debian
udev rules nicely created symbolic links under /dev/disk/by-id/.
> - The error handling in the SCSI infrastructure is far better structured
> as that one in the existing cciss driver, so the SCSI driver would
> benefit from this.
Agreed, this is an area that we can improve greatly with the scsi
infrastructure, I think.
> - Nevertheless, the cciss driver and the corresponding sysfs / device node
> layout has become the de-facto standard over the years and it will be
> _hard_ to change that.
>
> - However, given that the sysfs information from the cciss driver is quite
> rudimentary I doubt if anyone will indeed notice if the _internal_ driver
> is a SCSI or a block level driver, as long as the _external_ interface
> (ioctl, device-node layout etc) stays the same.
>
> Having said that I think this is the direction it should take:
>
> - Split the existing cciss driver in two parts, one part for the
> block-level interface and one for the lower-level device handling bits.
> - Redo the patch based on that, so that existing code can be shared
> (and fixes there would be included in both drivers).
> - Add some hooks/safeguards so that only _one_ interface driver can
> be loaded.
>
> This way we would be able keep the existing functionality and allow
> users to play around with the new driver.
> Long-term we can start moving the driver itself to SCSI, and keeping
> the existing cciss block interface only as a wrapper which adjusts
> the major:minor numbers; the device-node layout can be handled by udev.
Agreed about keeping the existing interfaces (changing only the
internal implementation, which users don't care about). I thought
about the similar things (tricks like ide-scsi does) during writing a
patch but also thought that udev rules can do the similar jobs, as
James pointed out. And seems that udev rules nicely works.
On Tue, 22 Jul 2008 14:19:22 +0000
"Miller, Mike (OS Dev)" <[email protected]> wrote:
> > -----Original Message-----
> > From: FUJITA Tomonori [mailto:[email protected]]
> > Sent: Saturday, July 19, 2008 5:52 AM
> > To: Miller, Mike (OS Dev)
> > Cc: [email protected];
> > [email protected]; [email protected];
> > [email protected]
> > Subject: [RFC PATCH] HP (Compaq) Smart Array 5xxx controller
> > SCSI driver
> >
> > This is a SCSI driver for HP (Compaq) Smart Array 5xxx controllers.
> >
> > SCSI people can skip the following two paragraphs.
> >
> > Currently, a driver for HP (Compaq) Smart Array 5xxx
> > controllers is implemented as a block device driver,
> > block/cciss.c (aka, cciss). But the controller interface is
> > SCSI-3 compatible. The specification says, "A controller that
> > supports CISS is considered to be a SCSI storage array
> > controller". A scsi driver for the controllers was discussed
>
> Not really. The only resemblance we have to a SCSI controller is the
> fact that we hang SCSI, SAS, and SATA drives off the backend. Our
> implementation of the SCSI spec is cherry picked for what we
> need. That, of course, could be changed.
The controllers support mandatory commands at least, as the spec says?
> > several times.
> >
> > I think that a SCSI cciss driver can be much simpler (and
> > maintainable) than the block cciss driver (the majority of
> > the code forging SCSI command can go away, we have the proper
> > sysfs entries for free, we can handle scsi tape drives easily
>
> We already handle tape drives quite easily and one of these days I
> hope to satisfy Andrew to the point where he will accept my sysfs
> changes.
I think that there are other areas that we can improve with a SCSI
driver, such as error handling, queue depth management, etc.
> > etc). It would be helpful for distributions too since they
> > don't need stuff specific to cciss (such as udev rules).
> >
> >
> > There isn't any easy migration path for users. So I think
> > that we need to keep the block and scsi drivers for cciss for
> > some time (say two years).
>
> Precisely why I am luke warm to this proposal. Who's going to help
> customers decide which driver to use?
I guess that distributions (with HP) can, as they could with libata
vs. ide.
> What if a number of customers are happy with the block driver? Who
> will decide for them when to switch? What if a customer is using the
> block driver and unknowingly upgrades to the SCSI driver? He's dead
> the water at best, lost his data at worst.
I think that customers don't care about how the driver is
implemented. My point is that the SCSI cciss driver could be better
than the block one.
As James pointed out, we could provide a migration path; we can change
only the driver internal without changing the user-space interfaces:
With my SCSI driver (I uploaded a new one), I got the following
devices connected with my CCISS adapter:
clover:/home/fujita# lsscsi
(snip)
[3:0:0:0] disk HP LOGICAL VOLUME 1.66 /dev/sde
[3:0:0:1] disk HP LOGICAL VOLUME 1.66 /dev/sdf
[3:0:0:2] disk HP LOGICAL VOLUME 1.66 /dev/sdg
[3:0:0:3] disk HP LOGICAL VOLUME 1.66 /dev/sdh
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):
clover:/home/fujita# hpacucli
HP Array Configuration Utility CLI 7.80-3.0
Detecting Controllers...Done.
Type "help" for a list of supported commands.
Type "exit" to close the console.
=> ctrl all show config
Smart Array E200 in Slot 3 (sn: PA6C90L9SV90L0)
array A (SAS, Unused Space: 0 MB)
logicaldrive 1 (68.3 GB, RAID 0, OK)
physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 72 GB, OK)
array B (SAS, Unused Space: 0 MB)
logicaldrive 2 (68.3 GB, RAID 0, OK)
physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 72 GB, OK)
array C (SAS, Unused Space: 0 MB)
logicaldrive 3 (68.3 GB, RAID 0, OK)
physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 72 GB, OK)
array D (SAS, Unused Space: 0 MB)
logicaldrive 4 (68.3 GB, RAID 0, OK)
physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 72 GB, OK)
When HP and distributions think that the scsi driver is ready,
they can modify their udev rules for cciss and enable the SCSI driver
module instead of the block driver.
> > My scsi driver is still in an early stage (I tried to keep
> > the changes minimum). I can detect logical units, mount a
> > file system, do lots of I/Os, however, there are lots of
> > TODOs in the management features.
>
> Have you taken into consideration any of the HP utilities and management agents? Those must work, period.
Yes, I understand that. We will need lots of tests.
As I explained, we can provide the compatibility of ioctl and device
names. We could avoid breaking the existing tools?
Even though we need lots of tests, I still think that migrating to the
SCSI subsystem is the right thing for CCISS in the long term
perspective.
> > If I can get an ACK from HP about the long-term migration of
> > cciss to SCSI, I'm happy to keep working on the SCSI cciss
> > driver and maintain it until HP takes over the driver.
>
> We already have a SCSI port of the driver that is at least as
> functional as you decribe. But I am against it's release for the
> reasons stated above. If we ever decide to release the SCSI port it
> should be developed by HP so we can be assured that the utils and
> agents work as expected. That doesn't mean we wouldn't leverage some
> of your work. ;)
If HP releases its SCSI driver, I'm happy to throw my driver away and
work on HP SCSI driver. I like to see a driver in development rather
than a finished driver; development in mainline rather than private
development at a vendor. Everyone can see the progress and try it.
Thanks,
> -----Original Message-----
> From: fujita [mailto:[email protected]] On Behalf Of FUJITA Tomonori
> Sent: Wednesday, July 23, 2008 8:47 AM
> To: Miller, Mike (OS Dev)
> Cc: [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: RE: [RFC PATCH] HP (Compaq) Smart Array 5xxx
> controller SCSI driver
>
> On Tue, 22 Jul 2008 14:19:22 +0000
> "Miller, Mike (OS Dev)" <[email protected]> wrote:
>
> > > -----Original Message-----
> > > From: FUJITA Tomonori [mailto:[email protected]]
> > > Sent: Saturday, July 19, 2008 5:52 AM
> > > To: Miller, Mike (OS Dev)
> > > Cc: [email protected];
> > > [email protected]; [email protected];
> > > [email protected]
> > > Subject: [RFC PATCH] HP (Compaq) Smart Array 5xxx controller SCSI
> > > driver
> > >
> > > This is a SCSI driver for HP (Compaq) Smart Array 5xxx
> controllers.
> > >
> > > SCSI people can skip the following two paragraphs.
> > >
> > > Currently, a driver for HP (Compaq) Smart Array 5xxx
> controllers is
> > > implemented as a block device driver, block/cciss.c (aka, cciss).
> > > But the controller interface is
> > > SCSI-3 compatible. The specification says, "A controller that
> > > supports CISS is considered to be a SCSI storage array
> controller".
> > > A scsi driver for the controllers was discussed
> >
> > Not really. The only resemblance we have to a SCSI
> controller is the
> > fact that we hang SCSI, SAS, and SATA drives off the backend. Our
> > implementation of the SCSI spec is cherry picked for what we need.
> > That, of course, could be changed.
>
> The controllers support mandatory commands at least, as the spec says?
As of today our inquiry data doesn't neccesarily match the SCSI-3 spec. But that can be changed.
>
>
> > > several times.
> > >
> > > I think that a SCSI cciss driver can be much simpler (and
> > > maintainable) than the block cciss driver (the majority
> of the code
> > > forging SCSI command can go away, we have the proper
> sysfs entries
> > > for free, we can handle scsi tape drives easily
> >
> > We already handle tape drives quite easily and one of these days I
> > hope to satisfy Andrew to the point where he will accept my sysfs
> > changes.
>
> I think that there are other areas that we can improve with a
> SCSI driver, such as error handling, queue depth management, etc.
True.
>
>
> > > etc). It would be helpful for distributions too since they don't
> > > need stuff specific to cciss (such as udev rules).
> > >
> > >
> > > There isn't any easy migration path for users. So I think that we
> > > need to keep the block and scsi drivers for cciss for
> some time (say
> > > two years).
> >
> > Precisely why I am luke warm to this proposal. Who's going to help
> > customers decide which driver to use?
>
> I guess that distributions (with HP) can, as they could with
> libata vs. ide.
I've had discussions with our partners. They are open to the concept of porting to SCSI. There will be some period of time where there are 2 drivers, however. And as James stated the udev rules can create the /dev/cciss links so hopefully there will be minimal impact to users.
>
>
> > What if a number of customers are happy with the block driver? Who
> > will decide for them when to switch? What if a customer is
> using the
> > block driver and unknowingly upgrades to the SCSI driver? He's dead
> > the water at best, lost his data at worst.
>
> I think that customers don't care about how the driver is
> implemented. My point is that the SCSI cciss driver could be
> better than the block one.
You're probably right here, also.
>
> As James pointed out, we could provide a migration path; we
> can change only the driver internal without changing the
> user-space interfaces:
>
> With my SCSI driver (I uploaded a new one), I got the
> following devices connected with my CCISS adapter:
>
> clover:/home/fujita# lsscsi
> (snip)
> [3:0:0:0] disk HP LOGICAL VOLUME 1.66 /dev/sde
> [3:0:0:1] disk HP LOGICAL VOLUME 1.66 /dev/sdf
> [3:0:0:2] disk HP LOGICAL VOLUME 1.66 /dev/sdg
> [3:0:0:3] disk HP LOGICAL VOLUME 1.66 /dev/sdh
>
> 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):
Very good. I don't believe most people would have taken the utils into consideration.
>
> clover:/home/fujita# hpacucli
> HP Array Configuration Utility CLI 7.80-3.0 Detecting
> Controllers...Done.
> Type "help" for a list of supported commands.
> Type "exit" to close the console.
>
> => ctrl all show config
>
> Smart Array E200 in Slot 3 (sn: PA6C90L9SV90L0)
>
> array A (SAS, Unused Space: 0 MB)
>
> logicaldrive 1 (68.3 GB, RAID 0, OK)
>
> physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 72 GB, OK)
>
> array B (SAS, Unused Space: 0 MB)
>
> logicaldrive 2 (68.3 GB, RAID 0, OK)
>
> physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 72 GB, OK)
>
> array C (SAS, Unused Space: 0 MB)
>
> logicaldrive 3 (68.3 GB, RAID 0, OK)
>
> physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 72 GB, OK)
>
> array D (SAS, Unused Space: 0 MB)
>
> logicaldrive 4 (68.3 GB, RAID 0, OK)
>
> physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 72 GB, OK)
>
>
> When HP and distributions think that the scsi driver is
> ready, they can modify their udev rules for cciss and enable
> the SCSI driver module instead of the block driver.
>
>
> > > My scsi driver is still in an early stage (I tried to keep the
> > > changes minimum). I can detect logical units, mount a
> file system,
> > > do lots of I/Os, however, there are lots of TODOs in the
> management
> > > features.
> >
> > Have you taken into consideration any of the HP utilities
> and management agents? Those must work, period.
>
> Yes, I understand that. We will need lots of tests.
>
> As I explained, we can provide the compatibility of ioctl and
> device names. We could avoid breaking the existing tools?
Correct.
>
> Even though we need lots of tests, I still think that
> migrating to the SCSI subsystem is the right thing for CCISS
> in the long term perspective.
I'm afraid I have to agree with you. I've been a steadfast opponent of a SCSI port but in the long run perhaps it is the best thing to do.
>
>
> > > If I can get an ACK from HP about the long-term migration
> of cciss
> > > to SCSI, I'm happy to keep working on the SCSI cciss driver and
> > > maintain it until HP takes over the driver.
> >
> > We already have a SCSI port of the driver that is at least as
> > functional as you decribe. But I am against it's release for the
> > reasons stated above. If we ever decide to release the SCSI port it
> > should be developed by HP so we can be assured that the utils and
> > agents work as expected. That doesn't mean we wouldn't
> leverage some
> > of your work. ;)
>
> If HP releases its SCSI driver, I'm happy to throw my driver
> away and work on HP SCSI driver. I like to see a driver in
> development rather than a finished driver; development in
> mainline rather than private development at a vendor.
> Everyone can see the progress and try it.
We'll post something sooner rather than later. I've been hesitant to submit unfinished work but I guess having the community provide input along the way is the best way to go.
OK, Tomo, you win! :)
-- mikem
>
>
> Thanks,
>
On Wed, 23 Jul 2008 14:07:39 +0000
"Miller, Mike (OS Dev)" <[email protected]> wrote:
> > > > If I can get an ACK from HP about the long-term migration
> > of cciss
> > > > to SCSI, I'm happy to keep working on the SCSI cciss driver and
> > > > maintain it until HP takes over the driver.
> > >
> > > We already have a SCSI port of the driver that is at least as
> > > functional as you decribe. But I am against it's release for the
> > > reasons stated above. If we ever decide to release the SCSI port it
> > > should be developed by HP so we can be assured that the utils and
> > > agents work as expected. That doesn't mean we wouldn't
> > leverage some
> > > of your work. ;)
> >
> > If HP releases its SCSI driver, I'm happy to throw my driver
> > away and work on HP SCSI driver. I like to see a driver in
> > development rather than a finished driver; development in
> > mainline rather than private development at a vendor.
> > Everyone can see the progress and try it.
>
> We'll post something sooner rather than later.
Nice! When are you likely to release the driver?
One thing that I'm interested in is how you map CCISS logical and
physical units to SCSI logical unit numbers. During writing a patch,
I've been thinking about what's the best way for users.
> I've been hesitant to submit unfinished work but I guess having the
> community provide input along the way is the best way to go.
Yeah, I'm happy to polish the driver even if I can't compile it.
> OK, Tomo, you win! :)
Thanks a lot for agreeing to move the CCISS driver to SCSI!
I know that there are several other people who are really pleased with
the decision.
Tomo wrote:
>
> My scsi driver is still in an early stage (I tried to keep
> the changes minimum). I can detect logical units, mount a
> file system, do lots of I/Os, however, there are lots of
> TODOs in the management features.
>
> If I can get an ACK from HP about the long-term migration of
> cciss to SCSI, I'm happy to keep working on the SCSI cciss
> driver and maintain it until HP takes over the driver.
Just a brief update. HP has developed a scsi version of cciss. It was originally done for another environment but we have decided to use it as the base for Linux. It was authored by Tom Lawler of HP. We are currently in the process of getting the Open Source Review Board approval to release the code to the community.
It's unclear right now as to who will be the maintainer.
-- mikem
>
>
> The patch is available at:
>
> http://www.kernel.org/pub/linux/kernel/people/tomo/ciss/0001-a
> dd-HP-Compaq-Smart-Array-5xxx-controller-SCSI-dri.patch
>
> clover:/home/fujita# insmod ciss.ko
> clover:/home/fujita# lsscsi
> (snip)
> [1:0:0:0] disk HP LOGICAL VOLUME 1.66 /dev/sde
> [1:0:0:1] disk HP LOGICAL VOLUME 1.66 /dev/sdf
> [1:0:0:2] disk HP LOGICAL VOLUME 1.66 /dev/sdg
> [1:0:0:3] disk HP LOGICAL VOLUME 1.66 /dev/sdh
>
> Yeah, it just works as SCSI disk, the dmesg says:
>
> sd 1:0:0:0: [sde] Attached SCSI disk
> sd 1:0:0:1: [sdf] 143305920 512-byte hardware sectors (73373
> MB) sd 1:0:0:1: [sdf] Write Protect is off sd 1:0:0:1: [sdf]
> Mode Sense: 5b 00 00 08 sd 1:0:0:1: [sdf] Write cache:
> disabled, read cache: enabled, doesn't support DPO or FUA
>
> I needed a different name and just stole 'ciss' from *BSD.
> But any names (like hpciss) works for me.
>
>
> Thanks,
>
Miller, Mike (OS Dev) wrote:
> Tomo wrote:
>
>> My scsi driver is still in an early stage (I tried to keep
>> the changes minimum). I can detect logical units, mount a
>> file system, do lots of I/Os, however, there are lots of
>> TODOs in the management features.
>>
>> If I can get an ACK from HP about the long-term migration of
>> cciss to SCSI, I'm happy to keep working on the SCSI cciss
>> driver and maintain it until HP takes over the driver.
>
> Just a brief update. HP has developed a scsi version of cciss. It was originally done for another environment but we have decided to use it as the base for Linux. It was authored by Tom Lawler of HP. We are currently in the process of getting the Open Source Review Board approval to release the code to the community.
>
> It's unclear right now as to who will be the maintainer.
>
> -- mikem
>
>>
>> The patch is available at:
>>
>> http://www.kernel.org/pub/linux/kernel/people/tomo/ciss/0001-a
>> dd-HP-Compaq-Smart-Array-5xxx-controller-SCSI-dri.patch
>>
>> clover:/home/fujita# insmod ciss.ko
>> clover:/home/fujita# lsscsi
>> (snip)
>> [1:0:0:0] disk HP LOGICAL VOLUME 1.66 /dev/sde
>> [1:0:0:1] disk HP LOGICAL VOLUME 1.66 /dev/sdf
>> [1:0:0:2] disk HP LOGICAL VOLUME 1.66 /dev/sdg
>> [1:0:0:3] disk HP LOGICAL VOLUME 1.66 /dev/sdh
>>
>> Yeah, it just works as SCSI disk, the dmesg says:
>>
>> sd 1:0:0:0: [sde] Attached SCSI disk
>> sd 1:0:0:1: [sdf] 143305920 512-byte hardware sectors (73373
>> MB) sd 1:0:0:1: [sdf] Write Protect is off sd 1:0:0:1: [sdf]
>> Mode Sense: 5b 00 00 08 sd 1:0:0:1: [sdf] Write cache:
>> disabled, read cache: enabled, doesn't support DPO or FUA
>>
>> I needed a different name and just stole 'ciss' from *BSD.
>> But any names (like hpciss) works for me.
My interest in SAS/SATA RAID controllers (e.g. cciss and megaraid)
is to get to the physical drives and let smartmontools query
them. The first difficulty is addressing physical drives within
the logical drive presented to the OS. Then there are SATA drives:
I have yet to see a SAT implementation good enough to fetch
useful SMART data using "pure" SCSI commands; that leaves the
SAT ATA PASS-THROUGH commands.
Testing I did today on a HP E200 controller with version 1.80
firmware and the cciss driver in lk 2.6.27 showed this command
failed (as it has in the past):
smartctl -a -d cciss,0 /dev/cciss/c0d0
when c0d0 was a SATA disk.
Yes, I know the documentation says it won't work and I've been told
not to hold my breadth.
So if a true SCSI cciss driver might appear, could SAT with
ATA pass-through support be added to the wish list?
BTW We now have the equivalent working on megaraid controllers.
Whether to let "SCSI" commands through that alter the state
of a SATA disk is an interesting dilemma for the driver.
WRITEs are obviously a no-no but the current megaraid/smartctl
code ignored my attempts to do a self-test.
Doug Gilbert
On Fri, 24 Oct 2008 15:10:57 +0000
"Miller, Mike (OS Dev)" <[email protected]> wrote:
> Tomo wrote:
>
> >
> > My scsi driver is still in an early stage (I tried to keep
> > the changes minimum). I can detect logical units, mount a
> > file system, do lots of I/Os, however, there are lots of
> > TODOs in the management features.
> >
> > If I can get an ACK from HP about the long-term migration of
> > cciss to SCSI, I'm happy to keep working on the SCSI cciss
> > driver and maintain it until HP takes over the driver.
>
> Just a brief update. HP has developed a scsi version of cciss. It was originally done for another environment but we have decided to use it as the base for Linux. It was authored by Tom Lawler of HP. We are currently in the process of getting the Open Source Review Board approval to release the code to the community.
>
> It's unclear right now as to who will be the maintainer.
Awesome, I'm really looking forward to the release.
Thanks!