[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



Let me present an interesting problem :

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 :

Attached scsi generic sg29 at scsi2, channel 0, id 3, lun 0,  type 12
  Vendor: DEC       Model: HSG80             Rev: V86S
  Type:   Direct-Access                      ANSI SCSI revision: 02
sdw : READ CAPACITY failed.
sdw : status=0, message=00, host=0, driver=08 
Current sd: sense key Not Ready
Additional sense: Logical unit not ready, initializing cmd. required
sdw: asking for cache data failed
sdw: assuming drive cache: write through
 /dev/scsi/host2/bus0/target3/lun1:<6>Device sdw not ready.
end_request: I/O error, dev sdw, sector 0
Buffer I/O error on device sdw, logical block 0
Device sdw not ready.
end_request: I/O error, dev sdw, sector 0
Buffer I/O error on device sdw, logical block 0
 unable to read partition table
Attached scsi disk sdw at scsi2, channel 0, id 3, lun 1


Somehow the sysfs attribute gets set to a random value :

# cat /sys/block/sdw/size
2097152

Say /dev/sdq is valid path to the same LUN. Its size is rightly reported
as 213338334 512-byte blocks.

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

Other ideas ? Can someone provide help and kernel coding skills ?

regards,
-- 
christophe varoqui <christophe varoqui free fr>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]