Un-remove aacraid devices

Hi Mark,

for some weird reason the aacraid driver insists on presenting all disks as 'removable' devices. This is gross hackery and causes userspace tools to not identify these devices as fixed disks, which most evidently they are.

Please apply.

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)

Make aacraid devices fixed

For some reason the aacraid driver insists on making all devices removable. This causes userspace tools to not identifying aacraid disks as fixed disks.

index 1e82c69..24275d8 100644
@@ -1843,9 +1843,6 @@ int aac_scsi_cmd(struct scsi_cmnd * scsi
 			} while ((offset += len) < scsicmd->cmnd[13]);
 		}
 
-		/* Do not cache partition table for arrays */
-		scsicmd->device->removable = 1;
-
 		scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8 | SAM_STAT_GOOD;
 		scsicmd->scsi_done(scsicmd);
 

NAK

This will break all our management applications, and will not allow us to manipulate the array configurations from within Linux. This will also break online expansion of capacity.

This flag has been set from the beginning to allow partition tables, capacity and device locking to be changed without requiring an intervening reboot or needing the device to be taken offline. Fixed disk result in these pieces of information being cached.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Hannes Reinecke
Sent: Wednesday, May 23, 2007 8:51 AM
To: Salyzyn, Mark
Cc: SCSI Mailing List
Subject: [PATCH] Un-remove aacraid devices

Hi Mark,

for some weird reason the aacraid driver insists on presenting all disks as 'removable' devices. This is gross hackery and causes userspace tools to not identify these devices as fixed disks, which most evidently they are.

Please apply.

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)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I thought this problem had been solved since at least 2000 (when LifeKeeper ran into the same issue) by sending the BLKRRPART ioctl to the device ... whether removable or not, this forces a reread of all the vital information (always providing nothing has the nodes open, of course, we can't physically yank the information out of applications using it).

If there's something BLKRRPART isn't doing we can probably fix it ... that's certainly better than lying to the kernel about the devices.

James

I think I've seen this very discussion before.

It looks like kernel needs to distinguish things like removable media (truely removable - CDRoms etc) and some "dynamic" things like in this case (like with any raid array really), with iSCSI devices and so on.

Currently, 'removable' is handy at detecting devices which should be handed to 'cdrom' or 'floppy' group (i think it was the cause of previous incarnation of this discussion).

Right now, both ways are causing problems here or there. "Removable" is bad because it confuses "regular" linux tools, while !removable breaks configurability of arrays.

/mjt

The applications may issue the start of an expansion, but then disappear. The Firmware is responsible for completing the job with the help of the driver. We issue a scsi_rescan_device when the job is completed, removable bit set turns off the capacity & partition table caching.

We would need a similar exported kernel interface for the aacraid driver to call after we receive the scan requests via the event (AIF) stream from the Firmware. I can not propose adding a flag to scsi_rescan_device, as that would change an interface, so a new call scsi_rescan_device_blkrrpart?

We have external RAID enclosures that report they are removable devices so that they may also transition through expansion. It is merely half a lie; it does indicate that the media can change ;-}

-- Mark

-----Original Message-----
From: James Bottomley [mailto:[email protected]]
Sent: Wednesday, May 23, 2007 1:07 PM
To: Salyzyn, Mark
Cc: Hannes Reinecke; SCSI Mailing List
Subject: RE: [PATCH] Un-remove aacraid devices

to manipulate the array configurations from within Linux. This will also break online expansion of capacity.

capacity and device locking to be changed without requiring an intervening reboot or needing the device to be taken offline. Fixed disk result in these pieces of information being cached.

I thought this problem had been solved since at least 2000 (when LifeKeeper ran into the same issue) by sending the BLKRRPART ioctl to the device ... whether removable or not, this forces a reread of all the vital information (always providing nothing has the nodes open, of course, we can't physically yank the information out of applications using it).

If there's something BLKRRPART isn't doing we can probably fix it ... that's certainly better than lying to the kernel about the devices.

James

Another note, the old old aacraid driver used to report removable device in the inquiry. We found we could mitigate the devices report somewhat by reporting a fixed dfisk inquiry, but turning on the removable bit for the scsi device after the scan but before attachment by setting this in the read capacity call. This hack showed the applications that we were a fixed disk, but the OS responded as if we were a removable.

Hannes, which user space tools are having troubles with the removable device designation?

-- Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Salyzyn, Mark
Sent: Wednesday, May 23, 2007 1:17 PM
To: James Bottomley
Cc: Hannes Reinecke; SCSI Mailing List
Subject: RE: [PATCH] Un-remove aacraid devices

The applications may issue the start of an expansion, but then disappear. The Firmware is responsible for completing the job with the help of the driver. We issue a scsi_rescan_device when the job is completed, removable bit set turns off the capacity & partition table caching.

We would need a similar exported kernel interface for the aacraid driver to call after we receive the scan requests via the event (AIF) stream from the Firmware. I can not propose adding a flag to scsi_rescan_device, as that would change an interface, so a new call scsi_rescan_device_blkrrpart?

We have external RAID enclosures that report they are removable devices so that they may also transition through expansion. It is merely half a lie; it does indicate that the media can change ;-}

-- Mark

-----Original Message-----
From: James Bottomley [mailto:[email protected]]
Sent: Wednesday, May 23, 2007 1:07 PM
To: Salyzyn, Mark
Cc: Hannes Reinecke; SCSI Mailing List
Subject: RE: [PATCH] Un-remove aacraid devices

to manipulate the array configurations from within Linux. This will also break online expansion of capacity.

capacity and device locking to be changed without requiring an intervening reboot or needing the device to be taken offline. Fixed disk result in these pieces of information being cached.

I thought this problem had been solved since at least 2000 (when LifeKeeper ran into the same issue) by sending the BLKRRPART ioctl to the device ... whether removable or not, this forces a reread of all the vital information (always providing nothing has the nodes open, of course, we can't physically yank the information out of applications using it).

If there's something BLKRRPART isn't doing we can probably fix it ... that's certainly better than lying to the kernel about the devices.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html