This is regression issue on how ada/da device ID should be enumerated. FreeBSD has kept using a fixed device ID for disk drives (ad#) for a historical reason because dynamic disk device enumeration require amount work to make it right; basically using drive serial number to maintain device ID initialized at installation time for proper mounting. 10.1-BATE2 (I only noticed now and may already be in 10-R) has changed SATA device from fixed ad# to dynamic ada#, which works fine for single or ordered disk drive installation (home use), but breaks the random disk drive installation that required by servers. In order to keep a system drive bootable, this drive must keep its device ID originally assigned at installation time. No matter what the ID was, and no matter how many disk drives are installed in any SATA or USB port with random order, already installed disk drive(s) MUST keep its / their assigned IDs when those drives were partitioned and mounted. During adding disk drive to 10.1-BETA2 system, it enumerates drive(s) dynamically to assign ID to ada node (similar issue to da node). Kernel clearly knows which drive is ad1, 2, 3, ..., but it does not assigned proper ID to existing drive(s) for ada and da nodes. That is, ad note IDs are still correct, but ada and da node IDs are dynamically changing when a new drive is inserted at lower SATA port(s). This causes boot fail and/or non boot drive unable to mount. The dynamic enumeration is likely used for moving a boot drive from on system to another or from one bus to another without manually modifying fstab entries. This is desired feature, but need to be implemented correctly. That is, this mechanism wants to ensure no matter where this drive is plugged in, already mounted drive(s) should be always enumerated to the ID installation assigned to. How to ensure this? For boot drive, this is relatively easy -- the boot drive is always this first one in general, so this drive should always enumerated as ada0 or da0. If ID assigned to boot drive is not 0 at installation, then generic enumeration apply. Generic enumeration is drive serial number (S#) based enumeration mechanism, which has been used for at least two decades. For example, if two drives installed and their S# are AAAA (mounted for /workingSpace) and XXXXX (boot drive), regardless what SATA port they resides at -- drive AAAA at ad9 and XXXXX at ad5 for example, We knew installation will likely name drive XXXXX as ada0 and AAAA as ada1. In fixed fashion, drive XXXXX is ad5 and AAAA is ad9, when a new drive is inserted as ad0, we knew drive XXXXX will be still ad5 and boot should not fail. But in current 10.1-BETA2, the new drive is likely will be ada0, drive XXXXX will be ada1, and AAAA will be ada2, then boot will fail. In case if new drive is inserted as ad8, drive XXXXX will remain as ada0 but AAAA will be ada2. Even though boot will succeed in this case, but mounting drive AAAA will fail. The S#-based enumeration will record the S# (unique to every drive) for corresponding device ID in a boot configuration file for dynamic enumeration, which is used in boot time to determine what device ID should be assigned to each drive. After existing drive ID has been enumerated, any new drive(s) will be given a unused ID sequentially. This ensures that existing drive(s) will always get device ID originally assigned to, so the disk mounting operation will never fail no matter where a disk drive (has FreeBSD already installed) is plugged in. Without ensuring this enumeration correctness, IT will have big headache in maintaining a large amount of disk sets for servers.
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Alexander, could you provide some input on this?
The new device naming scheme was introduced several years ago simply because previous one was not working for more complicated configurations with port multipliers, etc. People for whom old device<->port binding was critical can still manage it via loader tunables, as described in cam(4). Though better way to handle this is via using some kinds of on-disk metadata, such as partition labels, etc. There are GEOM providers with disk serial numbers, if you wish to go that way and mount file systems via disk serial numbers, though I personally don't like that. Requested wiring of boot device to ada0 is problematic, since there is no any relations between boot device numbering in BIOS and one detected by system. While it is odd, technically it is possible to boot from one device, while mount root from another. People in embedded environments do this sometimes. Wiring of device number to serial number is currently not supported, though it probably can be implemented. At this point FreeBSD has no any cross-reboot persistent database to store device mapping (is not count loader tunables). You may say that it is bad, but there are other opinions -- for example, that properly configured system will work fine independently of hardware it is booting on.
Given Alexander's feedback, closing this, classified as a non-issue.