Jeremy Chadwick schreef:
On Mon, Feb 13, 2012 at 03:49:41AM -0800, Jeremy Chadwick wrote:
On Mon, Feb 13, 2012 at 12:11:30PM +0100, Johan Hendriks wrote:
Ok so it is not the mps driver who does the naming but cam, and that
also has changed on 9.0 Stable.
Well i use gpart labels for the pool, so i can use the gpart labels
to yank the right disk.
But it would be nicer if there was some kind of logic in the
numbering of the devices.
"Wire them down" in FreeBSD using loader.conf variables and this issue
will cease to be a problem. Example is below, despite being for SATA
with AHCI -- really doesn't matter, just change the appropriate bits and
it should be fine for you.
# "Wire down" device names (ada[0-5]) to each individual port
# on the SATA/AHCI controller. This ensures that if we reboot
# with a disk missing, the device names stay the same, and stay
# attached to the same SATA/AHCI controller.
# http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html
#
hint.scbus.0.at="ahcich0"
hint.scbus.1.at="ahcich1"
hint.scbus.2.at="ahcich2"
hint.scbus.3.at="ahcich3"
hint.scbus.4.at="ahcich4"
hint.scbus.5.at="ahcich5"
hint.ada.0.at="scbus0"
hint.ada.1.at="scbus1"
hint.ada.2.at="scbus2"
hint.ada.3.at="scbus3"
hint.ada.4.at="scbus4"
hint.ada.5.at="scbus5"
To be more specific: please see the CAM(4) man page and look at some of
the example hint settings shown there. In your case I believe you'd
want the below (which is a static map that matches your provided dmesg
in the previous mail). If you want different device names tied to the
different targets, it should be pretty obvious what to change.
hint.scbus.0.at="mps0"
hint.da.0.at="scbus0"
hint.da.0.target="8"
hint.da.0.unit="0"
hint.da.1.at="scbus0"
hint.da.1.target="9"
hint.da.1.unit="0"
hint.da.2.at="scbus0"
hint.da.2.target="10"
hint.da.2.unit="0"
hint.da.3.at="scbus0"
hint.da.3.target="11"
hint.da.3.unit="0"
hint.da.4.at="scbus0"
hint.da.4.target="12"
hint.da.4.unit="0"
hint.da.5.at="scbus0"
hint.da.5.target="13"
hint.da.5.unit="0"
hint.da.8.at="scbus0"
hint.da.8.target="19"
hint.da.8.unit="0"
hint.da.9.at="scbus0"
hint.da.9.target="20"
hint.da.9.unit="0"
hint.da.11.at="scbus0"
hint.da.11.target="22"
hint.da.11.unit="0"
hint.da.12.at="scbus0"
hint.da.12.target="23"
hint.da.12.unit="0"
hint.da.13.at="scbus0"
hint.da.13.target="24"
hint.da.13.unit="0"
hint.da.14.at="scbus0"
hint.da.14.target="27"
hint.da.14.unit="0"
hint.da.15.at="scbus0"
hint.da.15.target="28"
hint.da.15.unit="0"
Naturally you can do the same for your AHCI controller bits too, though
understand that each channel/port on the controller there matches to a
separate scbusX unit, so you may want to start the numbering higher (in
the case the LSI controller could ever have more scbusX entries added;
e.g. LVMs or similar -- not sure how those are implemented there, but
it doesn't matter, you get my drift I hope).
Thanks i will look into this, and the enclosure slot mapping.
Thank you all for your time.
And sorry for using this topic as it was not related.
regards
Johan
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
