[RFC,v2] scsi: scan: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT

[RFC,v2] scsi: scan: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT

[Andrey Melnikov]

Hello.

This patch break exposing individual RAID disks from adaptec raid
controller. I need access to this disc's for S.M.A.R.T monitoring.

Please find other way to workaround bugs in IBM/2145 controller.

Re: [RFC,v2] scsi: scan: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT

[Zhong Li]

> On Aug 29, 2019, at 11:49 PM, Andrey Melnikov <temnota.am@gmail.com> wrote:
> 
> Hello.
> 
> This patch break exposing individual RAID disks from adaptec raid
> controller. I need access to this disc's for S.M.A.R.T monitoring.

Hello Andrey, 

Do you have any more details about how/why it is broken? 

Thanks, Zhong 

> 
> Please find other way to workaround bugs in IBM/2145 controller.

Re: [RFC,v2] scsi: scan: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT

[Andrey Melnikov]

чт, 12 сент. 2019 г. в 07:56, Zhong Li <lizhongfs@gmail.com>:
>
>
> > On Aug 29, 2019, at 11:49 PM, Andrey Melnikov <temnota.am@gmail.com> wrote:
> >
> > Hello.
> >
> > This patch break exposing individual RAID disks from adaptec raid
> > controller. I need access to this disc's for S.M.A.R.T monitoring.
>
> Hello Andrey,
>
> Do you have any more details about how/why it is broken?

adaptec report hidden luns with PQ=1, PDT=0 - now it skipped.

[   32.609143] scsi host6: aacraid
[   32.609566] scsi 6:0:0:0: Direct-Access     Adaptec  srv
  V1.0 PQ: 0 ANSI: 2
[   32.609881] scsi 6:0:1:0: Direct-Access     Adaptec  zbx
  V1.0 PQ: 0 ANSI: 2
[   32.639942] scsi 6:1:4:0: Direct-Access     ATA      WDC
WD2003FZEX-0 01.0 PQ: 1 ANSI: 5
[   32.640810] scsi 6:1:5:0: Direct-Access     ATA      WDC
WD2003FZEX-0 01.0 PQ: 1 ANSI: 5
[   32.641559] scsi 6:1:6:0: Direct-Access     ATA      WDC
WD2003FZEX-0 01.0 PQ: 1 ANSI: 5
[   32.642266] scsi 6:1:7:0: Direct-Access     ATA      WDC
WD2003FZEX-0 01.0 PQ: 1 ANSI: 5


> > Please find other way to workaround bugs in IBM/2145 controller.
>

Re: [RFC,v2] scsi: scan: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT

[Li Zhong]

On Thu, Sep 12, 2019 at 8:37 PM Andrey Melnikov <temnota.am@gmail.com> wrote:
>
> чт, 12 сент. 2019 г. в 07:56, Zhong Li <lizhongfs@gmail.com>:
> >
> >
> > > On Aug 29, 2019, at 11:49 PM, Andrey Melnikov <temnota.am@gmail.com> wrote:
> > >
> > > Hello.
> > >
> > > This patch break exposing individual RAID disks from adaptec raid
> > > controller. I need access to this disc's for S.M.A.R.T monitoring.
> >
> > Hello Andrey,
> >
> > Do you have any more details about how/why it is broken?
>
> adaptec report hidden luns with PQ=1, PDT=0 - now it skipped.

It seems to expose these "hidden" disks, we have to revert this patch.
Don't have such raid controller, do these "hidden" disks have any differences
from the normal ones?

However, from the spec,
Qualifier 001b
An addressed logical unit having the indicated device type is not accessible,
at this time, to the task router (see SAM-5) contained in the SCSI target port
that received this INQUIRY command.
However, the task router is capable of accessing the addressed logical unit
from this SCSI target port.

I still think it makes more sense to skip adding the device at the
time of the scan.

And for disks behind the RAID controller, does it make more sense to access
their information through the controller, than exposing it directly to the OS?

Thanks, Zhong

>
> [   32.609143] scsi host6: aacraid
> [   32.609566] scsi 6:0:0:0: Direct-Access     Adaptec  srv
>   V1.0 PQ: 0 ANSI: 2
> [   32.609881] scsi 6:0:1:0: Direct-Access     Adaptec  zbx
>   V1.0 PQ: 0 ANSI: 2
> [   32.639942] scsi 6:1:4:0: Direct-Access     ATA      WDC
> WD2003FZEX-0 01.0 PQ: 1 ANSI: 5
> [   32.640810] scsi 6:1:5:0: Direct-Access     ATA      WDC
> WD2003FZEX-0 01.0 PQ: 1 ANSI: 5
> [   32.641559] scsi 6:1:6:0: Direct-Access     ATA      WDC
> WD2003FZEX-0 01.0 PQ: 1 ANSI: 5
> [   32.642266] scsi 6:1:7:0: Direct-Access     ATA      WDC
> WD2003FZEX-0 01.0 PQ: 1 ANSI: 5
>
>
> > > Please find other way to workaround bugs in IBM/2145 controller.
> >

Re: [RFC,v2] scsi: scan: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT

[Martin K. Petersen]

Andrey,

>> > This patch break exposing individual RAID disks from adaptec raid
>> > controller. I need access to this disc's for S.M.A.R.T monitoring.
>
> adaptec report hidden luns with PQ=1, PDT=0 - now it skipped.

>> > Please find other way to workaround bugs in IBM/2145 controller.

Spent some time on this today and I'm in agreement with Zhong's
interpretation of the SCSI spec.

What puzzles me is that aacraid already supports the no_uld_attach
feature so I'm not sure why it also sets PQ=1 for physical devices?

We could either have a SCSI host flag to override the behavior or
consider masking PQ in the driver. Unfortunately, I don't have any
aacraid controllers I can test with in my test setup so I'd have to
synthesize a setup with scsi_debug.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [RFC,v2] scsi: scan: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT

[Hannes Reinecke]

On 9/27/19 1:26 AM, Martin K. Petersen wrote:
> 
> Andrey,
> 
>>>> This patch break exposing individual RAID disks from adaptec raid
>>>> controller. I need access to this disc's for S.M.A.R.T monitoring.
>>
>> adaptec report hidden luns with PQ=1, PDT=0 - now it skipped.
> 
>>>> Please find other way to workaround bugs in IBM/2145 controller.
> 
> Spent some time on this today and I'm in agreement with Zhong's
> interpretation of the SCSI spec.
> 
> What puzzles me is that aacraid already supports the no_uld_attach
> feature so I'm not sure why it also sets PQ=1 for physical devices?
> 
> We could either have a SCSI host flag to override the behavior or
> consider masking PQ in the driver. Unfortunately, I don't have any
> aacraid controllers I can test with in my test setup so I'd have to
> synthesize a setup with scsi_debug.
> 
Well, the aacraid _is_ a strange beast.
Depending on the hardware it might even run fully emulated, with no SCSI
commands being handled at all by the firmware.
(But who am I to complain, the mylex one was even worse ...)
Additionally it has two pecularities:
1) all underlying devices are exported to the OS; of course they have to
be properly masked etc to avoid udev to latch on those devices. I also
was under the impression that the 'no_uld_attach' should be sufficient
here, but then that only avoids the 'sd' driver to become attached to
it. The actual SCSI device is still visible, so one _might_ be tempted
to use the 'sg' device and export it to things like qemu. Which of
course should be avoided.
And my guess here is that setting the PQ flag here is precisely for this
kind of things.
2) all RAID devices have the 'removable' flag set. This was done to
support online resize of the RAID device, but then I'm not sure if it's
still required. I for once would be happy to see that go.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      Teamlead Storage & Networking
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 247165 (AG München), GF: Felix Imendörffer

Re: [RFC,v2] scsi: scan: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT

[Martin K. Petersen]

Hannes,

> 1) all underlying devices are exported to the OS; of course they have
> to be properly masked etc to avoid udev to latch on those devices. I
> also was under the impression that the 'no_uld_attach' should be
> sufficient here, but then that only avoids the 'sd' driver to become
> attached to it. The actual SCSI device is still visible, so one
> _might_ be tempted to use the 'sg' device and export it to things like
> qemu. Which of course should be avoided.

Well, yes. But in this case the bug report was that sg devices were no
longer available for smartmontools to monitor.

-- 
Martin K. Petersen	Oracle Linux Engineering