On 2004-10-27T01:27:57, christophe varoqui <christophe.varoqui@xxxxxxx> wrote:
Hi christophe, let's see when I can flush this answer out of my e-mail
cache - German trains really need WLAN hotspots ;-)
> 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?
> Now when I want to map a multipath target over those two paths, the
> device-mapper faithfully rejects saying /dev/sdw is too small for a
> 213338334 blocks devmap.
>
> So what is the correct way to treat this situation ?
>
> 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.
Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company
