svn commit: r308217 - in head/sys/dev: mpr mps
Harry Schmalzbauer
freebsd at omnilan.de
Fri Nov 4 09:18:04 UTC 2016
Bezüglich Scott Long's Nachricht vom 02.11.2016 16:13 (localtime):
> Author: scottl
> Date: Wed Nov 2 15:13:25 2016
> New Revision: 308217
> URL: https://svnweb.freebsd.org/changeset/base/308217
>
> Log:
> Add a fallback to the device mapper logic. We've seen systems in the field
> that are apparently misconfigured by the manufacturer and cause the mapping
> logic to fail. The fallback allows drive numbers to be assigned based on the
> PHY number that they're attached to. Add sysctls and tunables to overrid
> this new behavior, but they should be considered only necessary for debugging.
Thanks a lot, this is welcome not only for debugging!
I had a hard time finding out how to get rid of static
driveserial-targetID assigning.
And more surprising, this affects only IT-fw. When using the same
controller in IR-mode, mapping is done (correctly) slot-based.
In IT-mode, every drive got a consecutive target ID which was static,
and even persistent over firmware updates. There's only one possibility
with LSIUtil(1.71) to erase /"persitent non-manufacturing config pages/".
But I guess this hard drive-targetID assigning is triggered by the
driver, namely the mps(4) in FreeBSD.
I did quick tests on windows and IT-mode, where I think I saw slot (or
Phy?) based assigning.
If it's really mps(4) who decides to store driveserial-targetID
numbering in the /"persitent non-manufacturing config pages/" of the
controller, mpsutil(8) should be able to reset. Otherwise replacing
failed drives, or - even mor confusing - rearranging drive/zpool layouts
is very unsatisfying.
Maybe "-1" should be mentioned with sysctl decription, otherwise this is
another very hard to find/influence behaviour.
Thanks,
-harry
More information about the svn-src-all
mailing list