Date: Thu, 11 Feb 2016 15:23:31 +0000 From: David Ford <david.ford@ouce.ox.ac.uk> To: "'freebsd-questions@freebsd.org'" <freebsd-questions@freebsd.org> Subject: multi-homed drive SATA drive affiliations Message-ID: <D64F8B312592434E801895942B9101163F9C5898@MBX01.ad.oak.ox.ac.uk>
next in thread | raw e-mail | index | archive | help
Hello,
I suspect I'm missing something obvious here, but I can't quite think what.=
I have a set of SAS disk shelves which are each dual homed to a pair of Fr=
eeBSD 10.1 systems. These shelves contain a bunch of SAS drives, which as e=
xpected work fine in this configuration, and can be accessed from whichever=
host wishes to use them - the end workload is ZFS, so each disk will be as=
signed to a single host, and the second host is for failover purposes.
The problem is that for SATA drives (the idea is the use SSDs for L2ARC/ZIL=
) SATA affiliations don't appear to be having the desired effect, the disks=
get assigned to one host when they are attached, and whilst I can clear th=
e affiliations on that host, there seems no way to make the second host see=
the drive once the affiliations have been cleared.
On the host where the drive appears:
[root@backup-san1 ~]# camcontrol devlist
<IBM-ESXS HUS723030ALS64 J210> at scbus0 target 9 lun 0 (pass0,da0)
<IBM-ESXS HUS723030ALS64 J3K7> at scbus0 target 10 lun 0 (pass1,da1)
<IBM-ESXS ST33000650SS BC36> at scbus0 target 11 lun 0 (pass2,da2)
<IBM-ESXS EXP3512 0366> at scbus0 target 12 lun 0 (pass3,ses0)
<ATA ST1000DM003-1ER1 CC45> at scbus0 target 13 lun 0 (da33,pass36)
The last line is the ATA drive in question,
On the other host:
root@backup-san-02:~ # camcontrol devlist
<IBM-ESXS EXP3512 0366> at scbus0 target 9 lun 0 (pass0,ses0)
<IBM-ESXS ST33000650SS BC36> at scbus0 target 10 lun 0 (pass1,da0)
<IBM-ESXS HUS723030ALS64 J210> at scbus0 target 11 lun 0 (pass2,da1)
<IBM-ESXS HUS723030ALS64 J3K7> at scbus0 target 12 lun 0 (pass3,da2)
I have tried using both:
camcontrol --phy=3D2 --op=3Dca /dev/ses0
smp_phy_control --phy=3D2 --op=3Dca /dev/ses0
on the working host, to clear the affiliation, and smp_rep_phy_sata implies=
this has had the desired effect:
[root@backup-san1 ~]# smp_rep_phy_sata --phy=3D2 /dev/ses0
Report phy SATA response:
expander change count: 71
phy identifier: 2
STP I_T nexus loss occurred: 0
affiliations supported: 1
affiliation valid: 0
STP SAS address: 0x50080e53c2b8f002
register device to host FIS:
34 00 50 01 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
affiliated STP initiator SAS address: 0x0
STP I_T nexus loss SAS address: 0x0
affiliation context: 0
current affiliation contexts: 0
However, nothing I've tried on the second host then allows it to see it:
root@backup-san-02:~ # smp_phy_control --phy=3D2 --op=3Dtspss /dev/ses0
root@backup-san-02:~ # smp_rep_phy_sata --phy=3D2 /dev/ses0
Report phy SATA result: Phy does not support SATA
root@backup-san-02:~ # smp_phy_control --phy=3D2 --op=3Dlr /dev/ses0
root@backup-san-02:~ # camcontrol reset
root@backup-san-02:~ # camcontrol rescan
root@backup-san-02:~ # smp_rep_phy_sata --phy=3D2 /dev/ses0
Report phy SATA result: Phy does not support SATA
I've even tried disabling the device from the first host, but it still beha=
ves in an identical fashion.
Does anyone happen to know what I've done wrong?
Thanks
David
--=20
David Ford
IT Manager, School of Geography and the Environment
For general IT Support queries please contact itsupport@ouce.ox.ac.uk
Telephone: +44 1865 285089
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D64F8B312592434E801895942B9101163F9C5898>