Re: [dm-devel] [multipath] SCSI device capacity mess

[Philip R Auld <pauld@egenera.com>]

Rumor has it that on Wed, Oct 27, 2004 at 09:02:39PM +0200 christophe varoqui said:
> 
> > > Some SAN hardware present for a same LUN a bunch of valid paths and  a
> > > bunch ghost paths. In my case, the ghosts responds to standard INQUIRY
> > > (EVPD 0x83, 0x80, ...) but the READ_CAPACITY fails :
> > 
> > As a note, this is one mode the EMC CLARiiON arrays can also operate in.
> > Even worse, they won't present the block device at all, just the SCSI
> > generic mode. However, for the CLARiiONs, they can be configured to
> > behave sanely and reply to a READ_CAPACITY too (just all I/O will be
> > errored), if setting the failovermode to 1.
> > 
> > I wonder whether your system can also be configured as such?
> > 
> Yes it could, but it's a controler wide setting.
> 

So is the CLARiiON setting. 

> Compatibility with other OS sharing the same controlers might impose
> this mode though. So I'd like to straight this situation up.
> 

I suspect anything else doing failover on this device would already require 
that setting. And if not doing failover probably won't see the passive 
controller due to cabling/zoning setup.

I don't see anything wrong with asking for specific array settings if they are
needed for multipathing. Some arrays don't return meaningful LU IDs if not 
configured for it. 


> > > 
> > > 1) make the /sys/block/*/size attribute writable
> > > 2) resurrect a BLKSETSIZE ioctl
> > > 3) make device-mapper less strict, and hope we can fix the size by a
> > > device rescan when it get activated
> > > 4) sell the culprit hardware
> > 
> > Personally I would opt for 4), but 3) is the likely path to solve this.
> > 
> > Using the new priority group initialization code (where we sent magic
> > commands down to activate the newly switched-to PG) which Alasdair and I
> > are currently doing for the CLARiiON pampering and which provides a
> > plugin-architecture to the dm-mpath system, you should be able to plug
> > in a hardware-specific handler for your system too.
> > 
> > However, "relaxing" this check should likely also be a property of the
> > hardware plugin loaded; I'd not wish to have it relaxed in all
> > scenarios.
> > 
> I wonder if it's not simpler just to remove the NOSTARTONADD flag on
> this devices in scsi_devinfo.c. I tested that and all the READ CAPACITY
> succeed as expected (DEC HSG80 / COMPAQ HSV*).
> 

Doesnt that just failover the LUN with the START? I think you'd end up 
with all LUNs active on which ever controller you scanned last. This may 
not be ideal.

And that wouldn't work for a (misconfigured) CLARiiON anyway, I think.


> Wasn't this flag in part motivated by the lack of multipath support
> anyway ?
> 
> Even in a cluster context, I don't really buy the annoyance of
> occasional LUN ping-pong.
> 

This is very possible. You can bring many active/passive arrays to their 
knees if you flip it back and forth under load. Although, I don't see that 
this is specifc to the READ_CAPACITY issue.  


Cheers,

Phil

> regards,
> -- 
> christophe varoqui <christophe.varoqui@free.fr>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752