Christophe, Unfortunately it does not appear that the TP9700 is working using the multipath device settings you provided. Our configuration is such where the host (a Sun X4600 running RHEL 5.2) is connected to the TP9700 using two Fibrechannel connections: <img src=cid:_2_0A07001C02B0A068001A7D6E85257474> No FC switches are used, just simple direct HBA to SP connectivity with two HBAs and two Storage Processors. LUNs on the RAID are distributed to be owned by either SPA or SPB to distribute the workload between the SPs and the fibrechannel connections. The TP9700 can be configured to present the storage to a host by setting the "Storage Array Host Type" (Linux, SGIRDAC, SGIAVT, Windows, etc). For my tests, I've been experimenting with Linux and SGIRDAC. I have been unsuccessful in determining what the storage array host type "Linux"s failover method is, but I thought I had come across an article that said the Linux type is basic AVT. I could be mistaken. Setting the TP9700 Host Type to "Linux" , I then setup /etc/multipath.conf to mimic the defaults for the TP9500: <tt> device {</tt> <tt> vendor "SGI"</tt> <tt> product "TP9[457]00"</tt> <tt> getuid_callout "/sbin/scsi_id -g -u -s /block/%n"</tt> <tt> prio_callout "/sbin/mpath_prio_tpc /dev/%n"</tt> <tt> features "0"</tt> <tt> hardware_handler "0"</tt> <tt> path_grouping_policy group_by_prio</tt> <tt> failback immediate</tt> <tt> rr_weight uniform</tt> <tt> rr_min_io 1000</tt> <tt> path_checker tur</tt> <tt> }</tt> This configuration ran OK for a while, then began to log multipath failures, and eventually I/O buffer errors. All LUNs on one SP trespassed to the other SP, and I had to manually place each trespassed LUN back to its primary path. Changing the TP9700 host type to SGIRDAC, then trying the configuration you provided me caused the host to not see the ghost path. Effectively I ended up with a single path. Disconnecting a FC connection resulted in the inability to see any of the LUNs assigned to the associated SP. I modified the multipath.conf a little: <tt> device {</tt> <tt> vendor "SGI"</tt> <tt> product "TP9700"</tt> <tt> path_grouping_policy failover</tt> <tt> getuid_callout "/sbin/scsi_id -g -u -s /block/%n"</tt> <tt> features "1 queue_if_no_path"</tt> <tt> path_checker rdac</tt> <tt> prio_callout "/sbin/mpath_prio_tpc /dev/%n"</tt> <tt> hardware_handler "1 rdac"</tt> <tt> prio rdac</tt> <tt> failback immediate</tt> <tt> }</tt> <tt>This worked ok, but I see lots of scsi sense key errors:</tt> <tt>Jun 23 12:16:42 p4dbl03 kernel: sdbk: Current: sense key: Recovered Error</tt> <tt>Jun 23 12:16:42 p4dbl03 kernel: <<vendor>> ASC=0x95 ASCQ=0x1ASC=0x95 ASCQ=0x1</tt> <tt>Jun 23 12:16:42 p4dbl03 kernel:</tt> <tt>I see those error regardless of how I configured the RAID and multipath.conf, which is worrisome.</tt> <tt>I especially see those errors if I run 'fdisk -l'. </tt> <tt>Disconnecting a FC cable on one HBA caused the associated volumes to trespass to the other SP, however, during this process, I noticed buffer I/O errors. Also, I noticed that the trespassed LUNs did not failback to their original SP when the FC cable was reconnected. Am I to assume that RDAC or other multipath software will not tell the storage to failback trepassed LUNs?</tt> <tt>Your assistance is appreciated,</tt> <tt>- Kevin</tt>