Date: Wed, 01 Oct 2014 18:17:00 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 194077] New: Improper enumerate ada (da) device ID in 10.1-R Message-ID: <bug-194077-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194077 Bug ID: 194077 Summary: Improper enumerate ada (da) device ID in 10.1-R Product: Base System Version: 10.1-BETA2 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: jguojun@sbcglobal.net 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. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-194077-8>