hd numbering in 9.0beta1

Hi everybody,

I would point out a problem related with the new way, coming in 9.0, to 
hard disks numbering.

As far I remember (5.0 ?), hardware detection  of H.D.'s at O.S. boot-up 
numbered every channel potentially able to attach a disk to, and tagged 
the disks really attached with the number of his control channel; the 
sequence (from lowers to highers numbers) begins with scsi or scsi-like 
(e-sata, usb, fire-wire,...) controllers and ends with the controllers 
directly depending from the chipset (sata at this time).

Such strategy allows to attach easily a new mass-storage device without 
modifying the disks numbering and thus the relevant fstab files.

9.0beta1 use a different numbering strategy,(with a similar sequence in 
harware detection) tagging succesively detected disks with adjacent numbers.

Please, let me show an example from my computer:

lines relevant to hard disks from /var/log/messages (recently installed 
FreeBSD-9.0beta1):
-----------
Aug 26 09:21:30 P5E-WS kernel: pci2: <ACPI PCI bus> on pcib8
Aug 26 09:21:30 P5E-WS kernel: siis0: <SiI3132 SATA controller> port 
0xac00-0xac7f mem 0xfe6ffc00-0xfe6ffc7f,0xfe6f8000-0xfe6fbfff irq 17 at 
device 0.0 on pci2
Aug 26 09:21:30 P5E-WS kernel: siisch0: <SIIS channel> at channel 0 on siis0
Aug 26 09:21:30 P5E-WS kernel: siisch1: <SIIS channel> at channel 1 on siis0
------------
Aug 26 09:21:30 P5E-WS kernel: ada0 at siisch1 bus 0 scbus6 target 0 lun 0
Aug 26 09:21:30 P5E-WS kernel: ada0: <WDC WD20EARS-00MVWB0 51.0AB51> 
ATA-8 SATA 2.x device
Aug 26 09:21:30 P5E-WS kernel: ada0: 300.000MB/s transfers (SATA 2.x, 
UDMA6, PIO 8192bytes)
Aug 26 09:21:30 P5E-WS kernel: ada0: Command Queueing enabled
Aug 26 09:21:30 P5E-WS kernel: ada0: 1907729MB (3907029168 512 byte 
sectors: 16H 63S/T 16383C)
Aug 26 09:21:30 P5E-WS kernel: ada0: Previously was known as ad16
Aug 26 09:21:30 P5E-WS kernel: ada1 at ata3 bus 0 scbus9 target 0 lun 0
Aug 26 09:21:30 P5E-WS kernel: ada1: <WDC WD3200AAKS-00B3A0 01.03A01> 
ATA-8 SATA 2.x device
Aug 26 09:21:30 P5E-WS kernel: ada1: 300.000MB/s transfers (SATA 2.x, 
UDMA5, PIO 8192bytes)
Aug 26 09:21:30 P5E-WS kernel: ada1: 305245MB (625142448 512 byte 
sectors: 16H 63S/T 16383C)
Aug 26 09:21:30 P5E-WS kernel: ada1: Previously was known as ad18
Aug 26 09:21:30 P5E-WS kernel: ada2 at ata4 bus 0 scbus10 target 0 lun 0
Aug 26 09:21:30 P5E-WS kernel: ada2: <Maxtor 6V160E0 VA111630> ATA-7 
SATA 2.x device
Aug 26 09:21:30 P5E-WS kernel: ada2: 300.000MB/s transfers (SATA 2.x, 
UDMA5, PIO 8192bytes)
Aug 26 09:21:30 P5E-WS kernel: ada2: 152627MB (312581808 512 byte 
sectors: 16H 63S/T 16383C)
Aug 26 09:21:30 P5E-WS kernel: ada2: Previously was known as ad20
Aug 26 09:21:30 P5E-WS kernel: ada3 at ata5 bus 0 scbus11 target 0 lun 0
Aug 26 09:21:30 P5E-WS kernel: ada3: <SAMSUNG HD502IJ 1AA01110> ATA-7 
SATA 2.x device
Aug 26 09:21:30 P5E-WS kernel: ada3: 300.000MB/s transfers (SATA 2.x, 
UDMA5, PIO 8192bytes)
Aug 26 09:21:30 P5E-WS kernel: ada3: 476940MB (976773168 512 byte 
sectors: 16H 63S/T 16383C)
Aug 26 09:21:30 P5E-WS kernel: ada3: Previously was known as ad22
-------------

Well, the system remembers the previous numbering (in my example, 
numbering from 8.2 release, as "production" release installed on a 
different slice), avoiding confusion.

But the "funny" things are that :
1- AMI Bios (MBR style) in my Asus M.B.(3 years old) shows, in the POST 
table relevant to disks, only the 3 first ones, i.e does not show the 
disk controlled by the SiI3132 pci-card; ami-bios don't list this disk 
as bootable in the "disk-boot-order" selection menu, and it's impossible 
to select it as a bootable disks. (but this disk appears correctly 
detected by the pci-card internal bios.); and I suppose the ami-bios 
detects and records the scsi-like disk, but hide it to the user.
2- Grub detects as hd0,hd1,hd2,hd3 the disks appearing in 9.0 as ada1, 
ada2, ada3, ada0 (i.e. Grub numbers with the scsi-like ones at the end 
and the chipset-controlled ones at the beginning).(Grub is said to 
extract the info from bios).

At this point, no real problem, as Bsd users warn carefully in the 
management of their disks between different releases of the O.S.

But adding a new hard disk will shift one, more, or all the previous 
numbers, (depênding from the channel the new disk is attached to), 
making the /etc/fstab files irrelevant, and leading kernel in panic at 
boot-up.

Well, I could, after adding a new disk, boot-up from a rescue disk to 
update files, (or "rootmount" manually, log as single, edit the proper 
config files, ...) but really the "old" numbering strategy was less 
painfull ! And I would panic if I have to explain that process to a newbee.

Perhaps I miss some important new feature introduced in 9.0 to work 
around that problem ?

Moreover, 9.0beta1 installs very easily and works fine; I am near to 
agree with the recently stated opinion that 9.1 release will never be 
necessary !!

Congratulations to the team

Roger

As frenchie, I apologize for my poor english.