SCSI layer a stumbling block for true SATA hotplug

SCSI layer a stumbling block for true SATA hotplug

[Lukasz Kosewski]

Hello all,

I'm currently working on a project to get a true disk-hotplug subsystem 
working in libata, experimenting with Promise SATA150 Tx2 Plus and 
SATAII150 Tx2 Plus controllers.

I am very near a 'beta' release of my patches to this mailing list, 
however, I have hit a stumbling block in the SCSI layer, which I'm 
hoping someone can give me good suggestions for resolving.

The situation is as follows:
-> I unplug a disk from my controller.
-> An interrupt fires off telling me I've unplugged a disk.
-> I acknowledge the interrupt, add an entry to my workqueue to handle 
the bottom half.
-> Bottom half kicks in, I need to call "scsi_remove_device" in order to 
purge the information about this disk from the system.

HOWEVER, "scsi_remove_device", through a chain of functions, ends up 
calling sd_shutdown, which attempts to synchronize the SCSI cache for my 
disk.  Well... bad plan, I've just unplugged the disk, it's gone.

So the system gets dazed and confused and locks up, timing out waiting 
for the disk which isn't there.

If anyone has a suggestion as to a good (ie. acceptable by all parties) 
solution to this problem, I'd love to hear it.

Thanks in advance,

Luke Kosewski

Re: SCSI layer a stumbling block for true SATA hotplug

[Joe Scsi]

How does hot unplugging work  now for fibre channel?

It seems this must already be a solved problem.

Re: SCSI layer a stumbling block for true SATA hotplug

[Tejun Heo]

  Hi, Lukasz.

Lukasz Kosewski wrote:
> Hello all,
> 
> I'm currently working on a project to get a true disk-hotplug subsystem 
> working in libata, experimenting with Promise SATA150 Tx2 Plus and 
> SATAII150 Tx2 Plus controllers.
> 
> I am very near a 'beta' release of my patches to this mailing list, 
> however, I have hit a stumbling block in the SCSI layer, which I'm 
> hoping someone can give me good suggestions for resolving.
> 
> The situation is as follows:
> -> I unplug a disk from my controller.
> -> An interrupt fires off telling me I've unplugged a disk.
> -> I acknowledge the interrupt, add an entry to my workqueue to handle 
> the bottom half.
> -> Bottom half kicks in, I need to call "scsi_remove_device" in order to 
> purge the information about this disk from the system.
> 
> HOWEVER, "scsi_remove_device", through a chain of functions, ends up 
> calling sd_shutdown, which attempts to synchronize the SCSI cache for my 
> disk.  Well... bad plan, I've just unplugged the disk, it's gone.
> 
> So the system gets dazed and confused and locks up, timing out waiting 
> for the disk which isn't there.
> 
> If anyone has a suggestion as to a good (ie. acceptable by all parties) 
> solution to this problem, I'd love to hear it.

  AFAIK, lldd (libata in this case) should be ready to handle/fail 
requests until the removal is complete.  As device hot-unplugging can be 
initiated from different layers, upper layer currently depends on lldd 
to handle such cases.  On detecting device removal, mark the device gone 
inside libata and fail all commands afterward until actual removal is 
complete.  That should do and, IIRC, what other drivers do.

-- 
tejun