Project

General

Profile

Bug #8792

Drives not showing in physical order

Added by Adam Lockington over 5 years ago. Updated about 3 years ago.

Status:
Closed: Not To Be Fixed
Priority:
Nice to have
Assignee:
Xin Li
Category:
GUI (new)
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

I have an array of 8 drives in a SAS bay connected to an M1015 SAS card.

When I go into the SAS controller while booting, I can see that all the disks are in the order of their appropriate slots.
Under the disk configuration of FreeNAS, the disk order is all mixed up, and does not corrospond to the slot that the drives are in.

See the attached pictures.

The order of the disks in FreeNAS appears to change with every boot as well.
Is there any way to get FreeNAS to order the disks correctly?

Reason being that if a disk fails, I'd like to know which one it is straight away, rather than having to cross reference a serial number to a spreadsheet and figure out which slot it is

SAS disks.JPG (59.4 KB) SAS disks.JPG Disks in SAS controller Adam Lockington, 03/21/2015 08:39 PM
FreeNAS drives.PNG (16.5 KB) FreeNAS drives.PNG Disks in FreeNAS Adam Lockington, 03/21/2015 08:39 PM
2519
2520

History

#1 Updated by Jordan Hubbard over 5 years ago

  • Category set to 2
  • Assignee set to William Grzybowski
  • Target version set to Unspecified

#2 Updated by William Grzybowski over 5 years ago

  • Assignee changed from William Grzybowski to Xin Li

This is not a GUI problem. I'm not even sure this can be considered a problem.

#3 Updated by Xin Li over 5 years ago

  • Status changed from Unscreened to Closed: Not To Be Fixed

Adam Lockington wrote:

The order of the disks in FreeNAS appears to change with every boot as well.
Is there any way to get FreeNAS to order the disks correctly?

There is a way to wire the device names down to their buses, but practically it's too much work for very little gain, as everyone's hardware is unique and these has to be manually done to match the reality. The device numbering on FreeBSD, by default, is the order they appear on their bus unless specifically configured otherwise. For instance, if the first mps(4) device, mps0 showed up first on probe, it would become scbus0. Then, if the OS sees two SAS hard drive devices on scbus0, they become da0 and da1. A longer SCSI probe delay time may be helpful to stabilize the results, by the way.

If you really want to do the hard wire down, the way it works is:

1) Look for lines in dmesg output in the form like:
da0 at mps0 bus 0 target 0 lun 0

2) Then write rules for each drive and each bus, like:

hint.scbus.0.at="mps0" # Wire scbus0 to mps0
hint.da.0.at="scbus0"
hint.da.0.target="0" # da0 is scbus 0 target 0

See https://www.freebsd.org/cgi/man.cgi?query=device.hints%285%29&sektion= for additional details.

Reason being that if a disk fails, I'd like to know which one it is straight away, rather than having to cross reference a serial number to a spreadsheet and figure out which slot it is

Well, a "straignt" way is never your labeling. In real world it's quite easy for remote hands to confuse the numbers on the drive labels and the outcome could be quite bad.

In order to find e.g. a faulted drive, usually the way it works is to utilize the enclosure LEDs on your SAS enclosure, i.e. a fault indication LED. It's open source but not included in the default FreeNAS build, and you can build them from TrueOS's share/examples/ses and get two tools: getencstat and setencstat. The two tools can be used to get enclosure LED and daX's mapping relationship, and set the state of LEDs when needed.

This way, you can easily light up a LED on your enclosure and ask your remote hand to, for instance, "replace that hard drive with the orange light blinking". However, to properly light up the LEDs, we must have knowledge of the specific enclosure (e.g. which bit means a blinking orange), and that's a manual procedure (setencstat some magic numbers, observe the enclosure reaction, etc.) and our current implementation is bound to the hardware platform we sell and not suitable for general consumption (at least, not yet if nobody work on it).

A quick workaround in the absent of either solution is to scrub your pool (which will generate work on all hard drives) and see which slot's LED didn't blink and replace that drive.

Hope this helps.

#4 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Target version changed from Unspecified to N/A

Also available in: Atom PDF