RE: aacraid driver question

RE: aacraid driver question

[Salyzyn, Mark]

It may have been a fools overture for me to do the one driver for all
kernels, but my build system for providing test and release products is
currently not geared to multiple sources and this worked for me. So far not
a problem since we are only releasing to Distribution Kernels ...

Setting removable true is to force the SCSI subsystem to re-read the
capacity and partition table on every fresh open since it may have changed
through an array morph. We used to present the arrays as removable DASD's,
and recently changed that to present them as Fixed DASD's, to deal with many
gripes, and setting the removable bit instead when a change occurred.

A scsi_rescan_device cool, but we have arrays coming, and arrays going. When
an array goes, I was supposed to mark it offline, the rescan I do right now
actually hurts under *very* heavy load and takes some time to report the
deleted array (we managed to stall the report for almost half an hour under
load, but new devices came online almost instantly). So if I was to make a
wish list, I would like to make the driver code more robust and also have an
entry to something like scsi_device_offline (remove single).

I know I am supposed to be monitoring the linux scsi list ...

Sincerely -- Mark Salyzyn

-----Original Message-----
From: 'Christoph Hellwig' [mailto:hch@infradead.org]
Sent: Monday, August 25, 2003 2:42 PM
To: Salyzyn, Mark
Cc: 'Mark Haverkamp'; linux-scsi@vger.kernel.org
Subject: Re: aacraid driver question


[adding linux-scsi to the Cc-list - it's becoming more a generic scsi issue]


On Mon, Aug 25, 2003 at 02:24:30PM -0400, Salyzyn, Mark wrote:
> Not having the procfs is no issue, the driver will then not have Plug and
> Play; I certainly need to add the ifdef for the CONFIG option though. I
had
> requested in the past having the scan_scsis made available to driver
modules
> (back in the dpt_i2o driver days), but the only workaround was to access
the
> public procfs.

Well, we can export scan_host_selected as in Mark Haverkamp 2.6 patch, but
I need to undesrtand those issues first and we need to fix the locking
in that area.  Even better move large parts into a helper in the scsi
core.

That's not going to mix with the one driver for all kernels crap, though.

> I am certainly interested in how we can improve the locking, what do you
> have in mind? This operation is carried out in a separate kernel thread
and
> not in an interrupt or command context, I may have been naive in my
> expectations though. However, experimentally this has been working fine
> (high speed SMP systems should have turned up some difficulties, but even
> heavily loaded found no problems in the 2.4.* streams), but I am not
always
> convinced ...

Plain 2.4 isn't much of an issue because it's mostly serialized by
io_request_lock and there's no real hotplugging support.  2.6 has
very finegrained locking and fully supports hotplugging.

Locking issues in aac_handle_aif:

 - drivers won't be allowed to look at shost->my_devices anymore very
   soon, but there will be locked and refcounted accessorcs be provided.
 - don't check sdev->access_count for business - you can always mark a
   scsi_device offline in 2.5 and it will go away once the last reference
   goes away.  What's the point of setting .removable to true?

but all this isn't nice yet.  You want to change the representation of a
lun, right?  What do you need in addition to scsi_rescan_device() ?
 
> I would appreciate being kept apprised of any changes or improvements that
> Mark Haverkamp makes so that I may merge them into my code base for
release.

Well, he's posting to linux-scsi - a list a driver maintainer probably
should be subscribed to..

Re: aacraid driver question

['Christoph Hellwig']

On Mon, Aug 25, 2003 at 02:58:01PM -0400, Salyzyn, Mark wrote:
> It may have been a fools overture for me to do the one driver for all
> kernels, but my build system for providing test and release products is
> currently not geared to multiple sources and this worked for me. So far not
> a problem since we are only releasing to Distribution Kernels ...

Well, if Adaptec doesn't care for mainline we'll better mark
Mark Haverkamp official maintainer.  He does a very good job at keeping
the driver uptodate and clean - something that can't be said for
other drivers for adaptec hardware...

> Setting removable true is to force the SCSI subsystem to re-read the
> capacity and partition table on every fresh open since it may have changed
> through an array morph. We used to present the arrays as removable DASD's,
> and recently changed that to present them as Fixed DASD's, to deal with many
> gripes, and setting the removable bit instead when a change occurred.

Well, that's exactly what scsi_rescan_device is for.  Mark (H.), could you
try to use it in your 2.6 driver instead?

> A scsi_rescan_device cool, but we have arrays coming, and arrays going. When
> an array goes, I was supposed to mark it offline, the rescan I do right now
> actually hurts under *very* heavy load and takes some time to report the
> deleted array (we managed to stall the report for almost half an hour under
> load, but new devices came online almost instantly). So if I was to make a
> wish list, I would like to make the driver code more robust and also have an
> entry to something like scsi_device_offline (remove single).

That would be scsi_set_device_offline.  So what are you doing exactly
in aac_handle_aif?  I'll guess now and you correct me, okay?

 - AifDenVolumeExtendComplete:  a lun has changed size
   In 2.6 we'd like to call scsi_rescan_device for this.
 - AifDenMorphComplete: some attribute change??
   If that's true scsi_rescan_device would be the way to go
   aswell.
 - AifEnContainerChange: a volume got added or deleted??
   If that's the case _and_ we know the channel, id, lun
   we can call scsi_add_device / scsi_remove_device

Re: aacraid driver question

[Mark Haverkamp]

On Mon, 2003-08-25 at 12:21, 'Christoph Hellwig' wrote:

> Well, that's exactly what scsi_rescan_device is for.  Mark (H.), could you
> try to use it in your 2.6 driver instead?
> 
I'll take a look into doing this.

Mark.
-- 
Mark Haverkamp <markh@osdl.org>

RE: aacraid driver question

[Salyzyn, Mark]

I managed to merge in the code that is in the Windoze variant of this driver
to permit differentiating CHANGE, ADD or DELETE of an array. The driver will
monitor sequences of events to generate the differentiation. Should resolve
the Yikes felt earlier :-)

I will be out on vacation for the later part of the week, so unit testing of
these changes may take some time. Mark H, contact me if you want a drop
prior to unit testing ...

Setting online for existing device references sounds fine!

Sincerely -- Mark Salyzyn

-----Original Message-----
From: 'Christoph Hellwig' [mailto:hch@infradead.org]
Sent: Tuesday, August 26, 2003 12:50 PM
To: Salyzyn, Mark
Cc: 'Mark Haverkamp'; linux-scsi@vger.kernel.org
Subject: Re: aacraid driver question


On Mon, Aug 25, 2003 at 04:50:31PM -0400, Salyzyn, Mark wrote:
> Hope this following helps the Yikes a bit (!)
> 
> Container deletions have a Container Delete AIF, and a container change
AIF.
> The array goes offline and is no longer accessible. We could monitor the
> Container Delete AIF event to trigger a scsi_remove_device for this.

Yup.

> The
> container change AIF could be used to call *something* with a null effect.

Now that we have the Container Delete AIF we can always handle a
container change AIF as 'lookup the struct scsi_device and try
scsi_rescan_device' - it we removed the device in the Container Delete AIF
just before the lookup won't find it.

> Creating an array has a Container Add AIF and a container change AIF. This
> is a totally new array. We could monitor the Container Add AIF event to
> trigger a scsi_add_device for this.

Yupp.

> The container change AIF could be used
> to call *something* with a null effect.

Again we'd do the lookup & scsi_rescan_device - it would succeed but not
change anything as we just did the scanning.

> Now I get `sticky' ...
> 
> Upon completion of a zero, we get just a container change AIF.

Also fine, the scsi_rescan_device shouldn be the right thing in this
case, too.

> But the array
> had gone offline when the Zero started, no events, except periodic generic
> percentage progress report AIFs, any I/O to the ID could return offline
> errors while clearing.

Okay, that's bad.

> We want the container change AIF to get the SCSI
> subsystem to re-activate this array. The ID did not really go away, it is
> just write protected while zeroing. We may be able to report the I/O error
> differently so that the SCSI subsystem does not take it permanently
offline,
> just temporarily inactive? If we altered the error report so that the
device
> information remained, could a triggered scsi_rescan_device be used to
import
> the zero'd partition table and have the side effect of bringing the device
> active again? Would this have the null effect desired above?

We don't remove the device either on I/O errors, just the online flag
is cleared.  scsi_rescan_device will not set it online again, but you
can do it manually before calling it.

RE: aacraid driver question

[Mark Haverkamp]

On Tue, 2003-08-26 at 10:05, Salyzyn, Mark wrote:
> I managed to merge in the code that is in the Windoze variant of this driver
> to permit differentiating CHANGE, ADD or DELETE of an array. The driver will
> monitor sequences of events to generate the differentiation. Should resolve
> the Yikes felt earlier :-)
> 
> I will be out on vacation for the later part of the week, so unit testing of
> these changes may take some time. Mark H, contact me if you want a drop
> prior to unit testing ...

Please send a copy. I'll be out starting next week for a week and a
half, but I could try it out this week.

Thanks,
Mark.
-- 
Mark Haverkamp <markh@osdl.org>

RE: aacraid driver question

[Salyzyn, Mark]

A Volume is a sequential addition of drives, not like a striped array where
the new capacity is distributed rather than added to the end. Yes, from the
driver perspective, they are the same ...

Hope this following helps the Yikes a bit (!)

Container deletions have a Container Delete AIF, and a container change AIF.
The array goes offline and is no longer accessible. We could monitor the
Container Delete AIF event to trigger a scsi_remove_device for this. The
container change AIF could be used to call *something* with a null effect.

Creating an array has a Container Add AIF and a container change AIF. This
is a totally new array. We could monitor the Container Add AIF event to
trigger a scsi_add_device for this. The container change AIF could be used
to call *something* with a null effect.

Now I get `sticky' ...

Upon completion of a zero, we get just a container change AIF. But the array
had gone offline when the Zero started, no events, except periodic generic
percentage progress report AIFs, any I/O to the ID could return offline
errors while clearing. We want the container change AIF to get the SCSI
subsystem to re-activate this array. The ID did not really go away, it is
just write protected while zeroing. We may be able to report the I/O error
differently so that the SCSI subsystem does not take it permanently offline,
just temporarily inactive? If we altered the error report so that the device
information remained, could a triggered scsi_rescan_device be used to import
the zero'd partition table and have the side effect of bringing the device
active again? Would this have the null effect desired above?

The above issue was not a problem under Windoze, for instance, because the
SCSI Port would not take a device that reported offline status to requests
permanently offline. Simply running the Disk Administrator would rediscover
the array once the zero had completed. No event monitoring to speak of.

Yes, I will look into further refinements and details, the Windoze driver is
currently being refined to reduce the `event noise' so that the new Store
Port driver does not have a fit. The results of that study should help us
here.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: 'Christoph Hellwig' [mailto:hch@infradead.org]
Sent: Monday, August 25, 2003 4:09 PM
To: Salyzyn, Mark
Cc: 'Christoph Hellwig'; 'Mark Haverkamp'; linux-scsi@vger.kernel.org
Subject: Re: aacraid driver question


On Mon, Aug 25, 2003 at 03:56:27PM -0400, Salyzyn, Mark wrote:
> AifDenMorphComplete is issued after a Morph (ie, adding new driver to an
> existing array to expand it's capacity) has completed. Capacity reduction
is
> not typically a side effect, but redundancy can change (RAID-5 to RAID-0).

You managed to get me really confused :)

So AifDenMorphComplete and AifDenVolumeExtendComplete are the same from
the drivers perspective?

Anyway, for those two scsi_rescan_device is thw way to go.  I'll
export it in 2.6.

> A Zero of an array has the side effect of also clearing out the first
block
> of the array, and thus the partition table. The management applications
make
> this function available, and we must live with it's consequences.

Okay...

> Ok, looks like you've up'd my priority on finding out how to differentiate
> online/offline/clear; sadly AifEnContainerChange was a `catchall' for most
> changes to an array of all sorts. Even more sad is that there are no
details
> contained within the FIB and I am otherwise quite nervous issuing commands
> to the adapter to probe the cause. Yes, this makes a case for a user,
> instead of a kernel, daemon to perform this task. I will find a way.

Yikes!

> Are we truly painted in a corner here? The `proc_write' call to the
classic
> kernels I did had the side effects of bringing online/offline/changed
device
> status up to date; albeit, we had a performance issue when devices went
> offline. A compromise is that offline `will just happen' when someone
tries
> to communicate to the ID of the device. What will scsi_add_device do to us
> if the device was there and is no longer accessible? Could we make the
pair
> of calls (scsi_add_device + scsi_rescan_device) in the interim?

Well, we could keep the semantics without the proc_write mess by
exporting scsi_scan_host_selected as Mark H. did in the patch that
triggered this thread, but I'd be very unhappy to do that.  We have
the exported scsi_add_device and scsi_remove_device functions to
add/remove a selected lun and if possible at all I'd prefer to use those.

scsi_add_device will return an error it it's not actually present,
but we don't have a way to remove an existing volume going that route
unless we find out whether we really meant offlining it.

Re: aacraid driver question

['Christoph Hellwig']

On Mon, Aug 25, 2003 at 04:50:31PM -0400, Salyzyn, Mark wrote:
> Hope this following helps the Yikes a bit (!)
> 
> Container deletions have a Container Delete AIF, and a container change AIF.
> The array goes offline and is no longer accessible. We could monitor the
> Container Delete AIF event to trigger a scsi_remove_device for this.

Yup.

> The
> container change AIF could be used to call *something* with a null effect.

Now that we have the Container Delete AIF we can always handle a
container change AIF as 'lookup the struct scsi_device and try
scsi_rescan_device' - it we removed the device in the Container Delete AIF
just before the lookup won't find it.

> Creating an array has a Container Add AIF and a container change AIF. This
> is a totally new array. We could monitor the Container Add AIF event to
> trigger a scsi_add_device for this.

Yupp.

> The container change AIF could be used
> to call *something* with a null effect.

Again we'd do the lookup & scsi_rescan_device - it would succeed but not
change anything as we just did the scanning.

> Now I get `sticky' ...
> 
> Upon completion of a zero, we get just a container change AIF.

Also fine, the scsi_rescan_device shouldn be the right thing in this
case, too.

> But the array
> had gone offline when the Zero started, no events, except periodic generic
> percentage progress report AIFs, any I/O to the ID could return offline
> errors while clearing.

Okay, that's bad.

> We want the container change AIF to get the SCSI
> subsystem to re-activate this array. The ID did not really go away, it is
> just write protected while zeroing. We may be able to report the I/O error
> differently so that the SCSI subsystem does not take it permanently offline,
> just temporarily inactive? If we altered the error report so that the device
> information remained, could a triggered scsi_rescan_device be used to import
> the zero'd partition table and have the side effect of bringing the device
> active again? Would this have the null effect desired above?

We don't remove the device either on I/O errors, just the online flag
is cleared.  scsi_rescan_device will not set it online again, but you
can do it manually before calling it.

RE: aacraid driver question

[Salyzyn, Mark]

Not sure if there is public documentation, heck just finding out about
AifDenMorphComplete internally required me to look at Firmware Code ...

AifDenMorphComplete is issued after a Morph (ie, adding new driver to an
existing array to expand it's capacity) has completed. Capacity reduction is
not typically a side effect, but redundancy can change (RAID-5 to RAID-0).

A Zero of an array has the side effect of also clearing out the first block
of the array, and thus the partition table. The management applications make
this function available, and we must live with it's consequences.

Ok, looks like you've up'd my priority on finding out how to differentiate
online/offline/clear; sadly AifEnContainerChange was a `catchall' for most
changes to an array of all sorts. Even more sad is that there are no details
contained within the FIB and I am otherwise quite nervous issuing commands
to the adapter to probe the cause. Yes, this makes a case for a user,
instead of a kernel, daemon to perform this task. I will find a way.

I will pow-wow with the Firmware engineers and see what they have to say
about this. I expect the workaround will not go easy, but will keep Mark
Haverkamp apprised.

Are we truly painted in a corner here? The `proc_write' call to the classic
kernels I did had the side effects of bringing online/offline/changed device
status up to date; albeit, we had a performance issue when devices went
offline. A compromise is that offline `will just happen' when someone tries
to communicate to the ID of the device. What will scsi_add_device do to us
if the device was there and is no longer accessible? Could we make the pair
of calls (scsi_add_device + scsi_rescan_device) in the interim?

Thanks -- Mark Salyzyn

-----Original Message-----
From: 'Christoph Hellwig' [mailto:hch@infradead.org]
Sent: Monday, August 25, 2003 3:41 PM
To: Salyzyn, Mark
Cc: 'Mark Haverkamp'; linux-scsi@vger.kernel.org
Subject: Re: aacraid driver question


On Mon, Aug 25, 2003 at 03:32:32PM -0400, Salyzyn, Mark wrote:
> Your assessment at the bottom is mainly correct, the AifEnContainerChange
> can mean more than just online/offline, it also include when an array has
> completed a clear operation so that the partition table needs to be reread
> (and thus updated). I have yet to work out the mechanism to detect the
> difference of online/offline/clear to mitigate the calls. I would expect
> that scsi_rescan_device will work in the interim?

No, scsi_rescan_device won't work of bringing a new device online or
an old one offline.  It's just when attributes on an existing device
change.  So to get this sorted out nicely we'd really need to know
whether AifEnContainerChange means online/offline/clear.  BTW, why/how
does the hardware interact with partitioning on aacraid?

And what's the exact meaning of AifDenMorphComplete?  Is there some
hardware documentation on adaptec's website?

Re: aacraid driver question

['Christoph Hellwig']

On Mon, Aug 25, 2003 at 03:56:27PM -0400, Salyzyn, Mark wrote:
> AifDenMorphComplete is issued after a Morph (ie, adding new driver to an
> existing array to expand it's capacity) has completed. Capacity reduction is
> not typically a side effect, but redundancy can change (RAID-5 to RAID-0).

You managed to get me really confused :)

So AifDenMorphComplete and AifDenVolumeExtendComplete are the same from
the drivers perspective?

Anyway, for those two scsi_rescan_device is thw way to go.  I'll
export it in 2.6.

> A Zero of an array has the side effect of also clearing out the first block
> of the array, and thus the partition table. The management applications make
> this function available, and we must live with it's consequences.

Okay...

> Ok, looks like you've up'd my priority on finding out how to differentiate
> online/offline/clear; sadly AifEnContainerChange was a `catchall' for most
> changes to an array of all sorts. Even more sad is that there are no details
> contained within the FIB and I am otherwise quite nervous issuing commands
> to the adapter to probe the cause. Yes, this makes a case for a user,
> instead of a kernel, daemon to perform this task. I will find a way.

Yikes!

> Are we truly painted in a corner here? The `proc_write' call to the classic
> kernels I did had the side effects of bringing online/offline/changed device
> status up to date; albeit, we had a performance issue when devices went
> offline. A compromise is that offline `will just happen' when someone tries
> to communicate to the ID of the device. What will scsi_add_device do to us
> if the device was there and is no longer accessible? Could we make the pair
> of calls (scsi_add_device + scsi_rescan_device) in the interim?

Well, we could keep the semantics without the proc_write mess by
exporting scsi_scan_host_selected as Mark H. did in the patch that
triggered this thread, but I'd be very unhappy to do that.  We have
the exported scsi_add_device and scsi_remove_device functions to
add/remove a selected lun and if possible at all I'd prefer to use those.

scsi_add_device will return an error it it's not actually present,
but we don't have a way to remove an existing volume going that route
unless we find out whether we really meant offlining it.

Re: aacraid driver question

[Mark Haverkamp]

On Mon, 2003-08-25 at 13:08, 'Christoph Hellwig' wrote:

> Well, we could keep the semantics without the proc_write mess by
> exporting scsi_scan_host_selected as Mark H. did in the patch that
> triggered this thread, but I'd be very unhappy to do that.  We have
> the exported scsi_add_device and scsi_remove_device functions to
> add/remove a selected lun and if possible at all I'd prefer to use those.
> 
> scsi_add_device will return an error it it's not actually present,
> but we don't have a way to remove an existing volume going that route
> unless we find out whether we really meant offlining it.

Correct me if I'm wrong, scsi_rescan_device will not do what we want. 
We need to know whether a device is coming or going and then call either
add or remove device, assuming that it can be determined?

Mark
-- 
Mark Haverkamp <markh@osdl.org>

Re: aacraid driver question

['Christoph Hellwig']

On Mon, Aug 25, 2003 at 01:25:38PM -0700, Mark Haverkamp wrote:
> > unless we find out whether we really meant offlining it.
> 
> Correct me if I'm wrong, scsi_rescan_device will not do what we want. 
> We need to know whether a device is coming or going and then call either
> add or remove device, assuming that it can be determined?

Yes.  Or keep it as in your patch (at least for the AifEnContainerChange),
but I'd rather avoid that.

Re: aacraid driver question

[Mark Haverkamp]

On Mon, 2003-08-25 at 13:31, 'Christoph Hellwig' wrote:
> On Mon, Aug 25, 2003 at 01:25:38PM -0700, Mark Haverkamp wrote:
> > > unless we find out whether we really meant offlining it.
> > 
> > Correct me if I'm wrong, scsi_rescan_device will not do what we want. 
> > We need to know whether a device is coming or going and then call either
> > add or remove device, assuming that it can be determined?
> 
> Yes.  Or keep it as in your patch (at least for the AifEnContainerChange),
> but I'd rather avoid that.

I ran a test where I used afacli to reconfigure a container to make it
larger.  When it was done, linux still thought that it was 33g instead
of the 100g that it was now configured.   I am re-running this test with
some more debug turned on to see what is happening in handle_aif.  It
takes quite a while for a reconfigure to complete.

Mark.
-- 
Mark Haverkamp <markh@osdl.org>

RE: aacraid driver question

[Salyzyn, Mark]

Thems fighting words, Christoph ;-}

Adaptec Cares, it is a priority, as witnessed by the fact I *have* been
watching the 2.6.0 kernels with interest and merging those changes back into
our source trees. I have no problem working with Mark Haverkamp if that
smooths things out, threats to glory and title mean nothing.

Mark Haverkamp, once you have those changes, I would be pleased to push the
change into our test departments to bang around a bit. We have a few testers
that are interested in working with latest kernels.

Your assessment at the bottom is mainly correct, the AifEnContainerChange
can mean more than just online/offline, it also include when an array has
completed a clear operation so that the partition table needs to be reread
(and thus updated). I have yet to work out the mechanism to detect the
difference of online/offline/clear to mitigate the calls. I would expect
that scsi_rescan_device will work in the interim?

Sincerely -- Mark Salyzyn

-----Original Message-----
From: 'Christoph Hellwig' [mailto:hch@infradead.org]
Sent: Monday, August 25, 2003 3:22 PM
To: Salyzyn, Mark
Cc: 'Christoph Hellwig'; 'Mark Haverkamp'; linux-scsi@vger.kernel.org
Subject: Re: aacraid driver question


On Mon, Aug 25, 2003 at 02:58:01PM -0400, Salyzyn, Mark wrote:
> It may have been a fools overture for me to do the one driver for all
> kernels, but my build system for providing test and release products is
> currently not geared to multiple sources and this worked for me. So far
not
> a problem since we are only releasing to Distribution Kernels ...

Well, if Adaptec doesn't care for mainline we'll better mark
Mark Haverkamp official maintainer.  He does a very good job at keeping
the driver uptodate and clean - something that can't be said for
other drivers for adaptec hardware...

> Setting removable true is to force the SCSI subsystem to re-read the
> capacity and partition table on every fresh open since it may have changed
> through an array morph. We used to present the arrays as removable DASD's,
> and recently changed that to present them as Fixed DASD's, to deal with
many
> gripes, and setting the removable bit instead when a change occurred.

Well, that's exactly what scsi_rescan_device is for.  Mark (H.), could you
try to use it in your 2.6 driver instead?

> A scsi_rescan_device cool, but we have arrays coming, and arrays going.
When
> an array goes, I was supposed to mark it offline, the rescan I do right
now
> actually hurts under *very* heavy load and takes some time to report the
> deleted array (we managed to stall the report for almost half an hour
under
> load, but new devices came online almost instantly). So if I was to make a
> wish list, I would like to make the driver code more robust and also have
an
> entry to something like scsi_device_offline (remove single).

That would be scsi_set_device_offline.  So what are you doing exactly
in aac_handle_aif?  I'll guess now and you correct me, okay?

 - AifDenVolumeExtendComplete:  a lun has changed size
   In 2.6 we'd like to call scsi_rescan_device for this.
 - AifDenMorphComplete: some attribute change??
   If that's true scsi_rescan_device would be the way to go
   aswell.
 - AifEnContainerChange: a volume got added or deleted??
   If that's the case _and_ we know the channel, id, lun
   we can call scsi_add_device / scsi_remove_device

Re: aacraid driver question

['Christoph Hellwig']

On Mon, Aug 25, 2003 at 03:32:32PM -0400, Salyzyn, Mark wrote:
> Your assessment at the bottom is mainly correct, the AifEnContainerChange
> can mean more than just online/offline, it also include when an array has
> completed a clear operation so that the partition table needs to be reread
> (and thus updated). I have yet to work out the mechanism to detect the
> difference of online/offline/clear to mitigate the calls. I would expect
> that scsi_rescan_device will work in the interim?

No, scsi_rescan_device won't work of bringing a new device online or
an old one offline.  It's just when attributes on an existing device
change.  So to get this sorted out nicely we'd really need to know
whether AifEnContainerChange means online/offline/clear.  BTW, why/how
does the hardware interact with partitioning on aacraid?

And what's the exact meaning of AifDenMorphComplete?  Is there some
hardware documentation on adaptec's website?

Re: aacraid driver question

['Christoph Hellwig']

[adding linux-scsi to the Cc-list - it's becoming more a generic scsi issue]


On Mon, Aug 25, 2003 at 02:24:30PM -0400, Salyzyn, Mark wrote:
> Not having the procfs is no issue, the driver will then not have Plug and
> Play; I certainly need to add the ifdef for the CONFIG option though. I had
> requested in the past having the scan_scsis made available to driver modules
> (back in the dpt_i2o driver days), but the only workaround was to access the
> public procfs.

Well, we can export scan_host_selected as in Mark Haverkamp 2.6 patch, but
I need to undesrtand those issues first and we need to fix the locking
in that area.  Even better move large parts into a helper in the scsi
core.

That's not going to mix with the one driver for all kernels crap, though.

> I am certainly interested in how we can improve the locking, what do you
> have in mind? This operation is carried out in a separate kernel thread and
> not in an interrupt or command context, I may have been naive in my
> expectations though. However, experimentally this has been working fine
> (high speed SMP systems should have turned up some difficulties, but even
> heavily loaded found no problems in the 2.4.* streams), but I am not always
> convinced ...

Plain 2.4 isn't much of an issue because it's mostly serialized by
io_request_lock and there's no real hotplugging support.  2.6 has
very finegrained locking and fully supports hotplugging.

Locking issues in aac_handle_aif:

 - drivers won't be allowed to look at shost->my_devices anymore very
   soon, but there will be locked and refcounted accessorcs be provided.
 - don't check sdev->access_count for business - you can always mark a
   scsi_device offline in 2.5 and it will go away once the last reference
   goes away.  What's the point of setting .removable to true?

but all this isn't nice yet.  You want to change the representation of a
lun, right?  What do you need in addition to scsi_rescan_device() ?
 
> I would appreciate being kept apprised of any changes or improvements that
> Mark Haverkamp makes so that I may merge them into my code base for release.

Well, he's posting to linux-scsi - a list a driver maintainer probably
should be subscribed to..