Re: Looking for some help understanding error handling

[John Garry]

On 05/10/2018 16:51, chris.mo...@microchip.com wrote:
Thanks Hannes,
After some pointers from Shane Seymour I found that the FC and SRP transport 
layers
have a devloss timer, so that when a device disappears they hold on to the 
target
information for a time waiting to see if it comes back.  The SAS transport layer
doesn't have that feature.

The options for me then would be to modify scsi_transport_sas.c to implement
the devloss timeout, or to put that functionality into my LLDD.

I'm willing to put the work into the SAS transport and libsas, but I suspect 
there's
not a universal need for it.  And since my LLDD is for internal use at our 
company and
won't be upstreamed, I'll probably just do the work there.  If anyone feels 
that this
is a feature that more people would want then I'll look into doing that.

Hello,

This feature sounds interesting for libsas. I however have a question on 
feasibility of devloss here (note: I'm not familiar with the 
concept/realization for other standards): if a device is deattached and 
re-attached, how can we confirm the same device? For SAS device it's ok 
as a disk has the WWN, but what about SATA?

Thanks,
John


Thanks,
Chris

-----Original Message-----
From: Hannes Reinecke [mailto:h...@suse.de]
Sent: Friday, October 5, 2018 8:01 AM
To: Chris Moore - C33997 <chris.mo...@microchip.com>; linux-
s...@vger.kernel.org
Subject: Re: Looking for some help understanding error handling

On 10/2/18 11:04 PM, chris.mo...@microchip.com wrote:
I'm working on LLDD for a SAS/SATA host adapter, and trying to understand
how the system handles link loss and recovery.

Say I have a device that gets recognized and attached as sd 12:0:4:0, at
/dev/sdb.
The drive goes offline temporarily, then comes back online.
When it does, it comes back as sd 12:0:5:0, and maybe /dev/sdb, maybe
/dev/sdc.

I'm not sure how the Id gets assigned.  Since this is the same drive,
is there some way my driver can tell libsas and/or SCSI core that it's the
same drive coming back?
Or is there no way to control that?

Not really. The target device is getting destroyed once the device
disconnects, and when it reconnects a new structure is allocated. But as the
target number is a simple counter it gets increased up each allocation.

I looked into /dev/disk/by-id, but that also didn't quite do what I
expected.  If I open /dev/disk/by-id/some_identifier, that's a symlink to,
say, /dev/sdb.

Yes.

 /dev/sdb goes away, comes back as /dev/sdc, but my process doesn't
know that, it still has /dev/disk/by-id/some_identifier opened and so it will
never recover without closing and reopening the file.

Simply don't keep hold of the symlink; once you have opened you'll miss any
updates to the symlink itself.
So better to open the symlink, check the device, do whatever needs to be
done, and _close the symlink_ again.
Then you can listen for udev events telling you when a device appears or
vanishes.

Cheers,

Hannes
--
Dr. Hannes Reinecke                Teamlead Storage & Networking
h...@suse.de                                   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284
(AG Nürnberg)