Date: Wed, 28 Jun 2017 01:03:36 +0000 From: spellberg_robert <emailrob@emailrob.com> To: Luciano Mannucci <luciano@vespaperitivo.it>, freebsd_questions <freebsd-questions@freebsd.org> Subject: Re: Shift ada device numbers? Message-ID: <59530068.2060407@emailrob.com> In-Reply-To: <3wxF144QMTzRRqQ@baobab.bilink.it> References: <3wxF144QMTzRRqQ@baobab.bilink.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/26/17 16:31, Luciano Mannucci wrote:
>
> Hello all,
>
> I have a FreeBSD 10.3 RELEASE machine whith root on zfs on two discs
> and a "standalone" SSD holding database data. I noticed that if I move
> the SSD disk to another SATA controller it becomes ada0 and the members
> of the zfs are shifted to ada1 and ada2, and the system doesn't work:
> in fact it stops at boot because I've put the swap on the ssd and it
> can't find it anymore.
>
> Is there a way to control whichnumbers are assigned to the disks at
> boot time?
>
> Many thanks,
>
> Luciano.
>
2017_jun_27_tue 25.04.--.utc
dear luciano ---
i have never tried "zfs" , so i do not know if this idea is fs_independent .
however , on my x86_64 10.3 gpt ufs box , this works .
make this inquiry :
ls -l /dev/ad*
do you see sym_links that look like :
/dev/ad* -> /dev/ada*
if not , then the rest of this post may not help you ; if so , then read
on .
as you are painfully aware , the "ada" entries behave according to
that highly_regarded and much_loved import from "big redmond" ,
which i call "drive_letter lottery" .
on the other hand , the "ad" entries are attached to the mobo
drive_cable sockets
in a --fixed-- fashion that is --tbd-- .
currently , all of my new moboes [ skylake cpu , 100_series chipset ]
have 6 "sata" sockets [ and others , of course ] .
when i build a new box [ currently , 4 ; 2 more , soon ] , i install 3
sata_drives ,
having --different-- capacities or model_numbers or some_such ,
noting the mobo_written socket_names as i go .
all of my boxen have , at least , 3 sata_drives [ no ssd , as yet ] .
later , to the 3 , i can add more , as needed .
after the os_install is complete , i inspect the boot_messages [
scroll_lock , "/var/run/dmesg.boot" , et_c ] .
i note the drive_related messages for later inclusion into a
revised_and_extended "/etc/fstab" .
here are the relevant lines from "/var/run/dmesg.boot" on one box :
[ snip from bof ]
acpi0: <ALASKA A M I > on motherboard
[ snip ]
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
[ snip ]
ahci0: <AHCI SATA controller> port
0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem
0xf7228000-0xf7229fff,0xf722c000-0xf722c0ff,0xf722b000-0xf722b7ff irq 16
at device 23.0 on pci0
ahci0: AHCI v1.31 with 6 6Gbps ports, Port Multiplier not supported
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich2: <AHCI channel> at channel 2 on ahci0
ahcich3: <AHCI channel> at channel 3 on ahci0
ahcich4: <AHCI channel> at channel 4 on ahci0
ahcich5: <AHCI channel> at channel 5 on ahci0
[ snip ]
[ i have added some blank lines to this next set to emphasize grouping ;
i did not change the line_order ]
[ this is the important group ]
[ note that , because they are different , each drive can be identified
with certainty ]
[ also , the "cd0" tray is not empty ]
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
cd0 at ahcich1 bus 0 scbus1 target 0 lun 0
cd0: <ASUS DRW-24B1ST j 1.00> Removable CD-ROM SCSI device
cd0: Serial Number G1D0CL016003
cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes)
cd0: 4421MB (2263638 2048 byte sectors)
ada0: <ST4000NM0033-9ZM170 SN04> ACS-2 ATA SATA 3.x device
ada0: Serial Number Z1ZAJ3DY
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 3815447MB (7814037168 512 byte sectors)
ada0: Previously was known as ad4
ada1 at ahcich3 bus 0 scbus3 target 0 lun 0
ada1: <ST1000NM0033-9ZM173 SN04> ACS-2 ATA SATA 3.x device
ada1: Serial Number Z1W4L2KA
ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 953869MB (1953525168 512 byte sectors)
ada1: Previously was known as ad10
ada2 at ahcich5 bus 0 scbus5 target 0 lun 0
ada2: <ST2000NM0033-9ZM175 SN04> ACS-2 ATA SATA 3.x device
ada2: Serial Number Z1X63F5R
ada2: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada2: Command Queueing enabled
ada2: 1907729MB (3907029168 512 byte sectors)
ada2: Previously was known as ad14
[ snip to eof ]
next , i add a comment_section to the "fstab" that summarizes the above
[ save the old version , of course ] .
note that cables are attached to the un_used connectors ; this is more
"finger_friendly" .
the mobo_socket names are "sata6G_*" , for this mobo .
here are the relevant lines from "/etc/fstab" on the same box .
[ note that i like long lines , for easy "grep"ping ]
[ snip from bof ]
#.
#srl sym_link device asus z170_k size mount cable .
#.
#srl /dev/ad4 -> /dev/ada0 sata6G_1 ahci ch 0 bus 0 scbus 0 target
0 lun 0 4_000_GB /+8_arch black__straight .
#srl /dev/cd0 sata6G_2 ahci ch 1 bus 0 scbus 1 target 0 lun 0
/cdrom black__right_angle .
#srl /dev/ad^ -> /dev/ada^ sata6G_3 ahci ch ^ bus ^ scbus ^ target
^ lun ^ blue .
#srl /dev/ad10 -> /dev/ada1 sata6G_4 ahci ch 3 bus 0 scbus 3
target 0 lun 0 1_000_GB system , data red .
#srl /dev/ad^^ -> /dev/ada^ sata6G_5 ahci ch ^ bus ^ scbus ^
target ^ lun ^ blue .
#srl /dev/ad14 -> /dev/ada2 sata6G_6 ahci ch 5 bus 0 scbus 5
target 0 lun 0 2_000_GB /+9_arch red .
#.
#.
#.
# Device Mountpoint FStype Options Dump Pass#
#.
/dev/ad10p2 none swap sw 0 0
#.
/dev/ad10p3 / ufs rw 1 1
#.
/dev/ad10p4 /var ufs rw 2 2
#.
/dev/ad10p5 /usr ufs rw 2 2
/dev/ad10p6 /usr/local ufs rw 2 2
/dev/ad10p7 /usr/ports ufs rw 2 2
#.
/dev/ad10p8 /+0_gp ufs rw 2 2
/dev/ad10p9 /+1_dnld ufs rw 2 2
/dev/ad10p10 /+2_cache ufs rw 2 2
/dev/ad10p11 /+3_lib ufs rw 2 2
/dev/ad10p12 /+4_spare ufs rw 2 2
#.
#.
#.
/dev/ad4p1 /+8_arch ufs rw 2 2
#.
/dev/ad14p1 /+9_arch ufs rw 2 2
#.
#.
#.
/dev/cd0 /cdrom cd9660 rw,noauto 0 0
#.
[ snip ]
[ note that , also , i include the original version , for easy reference ]
#.
#... #srl this is the installed version ; here , it is
commented out .
#.
# Device Mountpoint FStype Options Dump Pass#
# /dev/ada1p2 none swap sw 0 0
# /dev/ada1p3 / ufs rw 1 1
# /dev/ada1p4 /var ufs rw 2 2
# /dev/ada1p5 /usr ufs rw 2 2
# /dev/ada1p6 /usr/local ufs rw 2 2
# /dev/ada1p7 /usr/ports ufs rw 2 2
# /dev/ada1p8 /+0_gp ufs rw 2 2
# /dev/ada1p9 /+1_dnld ufs rw 2 2
# /dev/ada1p10 /+2_cache ufs rw 2 2
# /dev/ada1p11 /+3_lib ufs rw 2 2
# /dev/ada1p12 /+4_spare ufs rw 2 2
# /dev/ada2p1 /+9_arch ufs rw 2 2
# /dev/ada0p1 /+8_arch ufs rw 2 2
#.
[ snip to eof ]
>----> the revised "fstab" uses the --"ad"-- names , not the --"ada"-- names .
that is the whole point of the effort .
to answer your specific question , sir ,
> is there a way to control which numbers are assigned to the disks at boot time ?
the answer is "yes" .
once you have a map of which "/dev/ad*" name is attached to which
connector , you may select which one you want to use for which device .
then , no matter how you plug_in other devices to other connectors , the
fixed names will not move , no matter how the variable names dance .
what you need to do is to decide upon those devices which are to be
installed permanently or semi_permanently and those devices whose
installations are to be more temporary in nature .
other_wise , you will need to have multipla versions of "/etc/fstab" ; i
am not certain that you want to travel that route .
at the very least , one --must-- decide where the root_fs is going to
reside .
finally , i seem to recall that there is another way to get at
connector_specific device_names ; however , i do not know this for certain .
consequently , the above may_or_may_not be "the best of all possible
worlds" [ thank you , pangloss ] .
the important thing is that it works .
there_fore , if there is another way and it proves to be more involved
or difficult , then the above can be implemented quickly and be in_use ,
while other approaches are evaluated .
of course , if there is --not-- another way , then the above --still--
works and pangloss is over_joyed .
what i --do-- know is that , when i leap_frogged from 8.4 to 9.3 ,
"drive_letter lottery" suddenly appeared .
seeing the sym_links in "/dev" , the above work_around was obvious ; i
tried it , it worked ; so , i leave it alone .
i have never understood why it is "a good thing" to break a working
system as a consequence of attaching a temporary device .
ciao ,
rob
-------------------------------------------------------------------
ps [ specifically , to the fbsd_project decision_makers ] ---
"labelling" may solve some problem for some people , perhaps for many .
it is not my objective to deny others their joy .
however , i have never done this ; i can not imagine why i would want to
begin doing so .
probably , i am not doing the kinds of things that those other people
are doing .
so , i do not see why others should deny me mine .
i am a hardware_oriented fellow .
i write leaves in assembly , still ; to me , "avx-512" means --registers-- .
frequently , i swap "stuff" , from this box to that , from this cable to
that , et_c .
especially , this is true of hard_drives .
"drive_letter lottery" gets in my way .
this is the one thing that really angered me about "ms_dos" , when
writing "dot_bat" scripts , some 20_odd years ago .
for fbsd , i was --thrilled-- to discover that "/dev" names were
immutable to drive_cable sockets .
so , here is what i want .
for each combination of mobo and os_revision , there should be a fixed
name in/under "/dev" for each mobo_socket .
that way , once a given mobo has a given os_revision installed , i may
plug/mount and umount/un_plug with impunity .
of course , different moboes and/or different os_revisions may cause the
names to be different .
no problem .
for each combination , i have to make the determination --once-- , only .
if the fixed names are present , then i do not care how many variable
names are present , also , for the benefit of those who want them .
here is a proposed solution .
i suspect that both approaches can exist together , selected according
to taste .
perhaps , the default could be selected with the "install" script .
perhaps , it could be specified in "rc.conf" or some_such .
using the present sym_link method , the selected_default would determine
which is the "real" name and which is the "sym_link" name , in "/dev" .
different people look at the world in different ways .
i call this "freedom of choice" ; i hope that you do , also .
rob
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59530068.2060407>