c220g5-110423's HDD and SSD assigned to sda/sdb in unconventional order

[Wentao Zhang]

Hi,

Running

$ lsblk -d -o NAME,VENDOR,MODEL,SERIAL,SIZE,TRAN

c220g5-110423 gives:

NAME VENDOR   MODEL                SERIAL                 SIZE TRAN
sda  SEAGATE  ST1200MM0088         Z4028YV40000C811574P   1.1T sas
sdb  ATA      INTEL SSDSC2BB480G7K PHDV724404UG480BGN   447.1G sas

Most other c220g5 nodes give, e.g.:

NAME VENDOR   MODEL            SERIAL                 SIZE TRAN
sda ATA      INTEL SSDSC2BB48 PHDV7241061B480BGN   447.1G sas
sdb SEAGATE  ST1200MM0088     Z4028YJK0000C810EBZF   1.1T sas

Will this assignment be permanent or not deterministic?

Thanks,

Wentao

[David M Johnson]

The Linux kernel does not guarantee deterministic block device naming.
The devices could be physically connected differently; or the devices or
I/O controller could have differences in driver probe/init timings.
It's best to write your setup scripts using lsblk, blkid, or sysfs
(/sys/...) to make sure you're targeting the drive you want.

> Wentao

David

[David M Johnson]

On 8/11/26 07:55, Wentao Zhang wrote:

Hi Wentao, (please keep the list cc'd, thanks),

> Thanks for your note! Is there a way of securing particular hosts (say,
> this very c220g5-110423 again) when creating an experiment? Or is it
> purely by chance? (I keep an informal record myself and I've been
> assigned to it twice and observed the same order in both experiments.)

Yes, if you wanted to do this, you would add the following to your
geni-lib profile (or make it a profile parameter), assuming the node is
bound to the `node` Python variable:

node.component_id =
"urn:publicid:IDN+wisc.cloudlab.us+node+c220g5-110423"
node.component_manager_id = "urn:publicid:IDN+wisc.cloudlab.us+authority+cm"

> Thanks,
> Wentao

David

[Wentao Zhang]

On 2026-08-11 22:03, David M Johnson wrote:
> On 8/11/26 07:55, Wentao Zhang wrote:
>
> Hi Wentao, (please keep the list cc'd, thanks),

Sorry my email client's reply all didn't include that and I didn't
check. Hope this one works.

Cool great to know!

Thanks,
Wentao

>
>> Thanks,
>> Wentao
>
> David

[Mike Hibler]

Everything David says about deterministic naming is true, but in the case of
these nodes it is generally deterministic but the disk boot order may just be
wrong. I can attempt to fix it in the BIOS.

On Tue, Aug 11, 2026 at 10:10:01PM +0800, Wentao Zhang wrote:
> On 2026-08-11 22:03, David M Johnson wrote:
> > On 8/11/26 07:55, Wentao Zhang wrote:
> >
> > Hi Wentao, (please keep the list cc'd, thanks),
>
> Sorry my email client's reply all didn't include that and I didn't
> check. Hope this one works.
>
> >
> >> On 2026-08-11 21:39, David M Johnson wrote:
> >>> On 8/10/26 20:37, Wentao Zhang wrote:
> >>>> Hi,
> >>>>
> >>>> Running
> >>>>
> >>>> $ lsblk -d -o NAME,VENDOR,MODEL,SERIAL,SIZE,TRAN
> >>>>
> >>>> c220g5-110423 gives:
> >>>>

> >>>> NAME VENDOR ?? MODEL ?? ?? ?? ?? ?? ?? ?? ??SERIAL ?? ?? ?? ?? ?? ?? ?? ?? SIZE TRAN
> >>>> sda ??SEAGATE ??ST1200MM0088 ?? ?? ?? ?? Z4028YV40000C811574P ?? 1.1T sas
> >>>> sdb ??ATA ?? ?? ??INTEL SSDSC2BB480G7K PHDV724404UG480BGN ?? 447.1G sas

> >>>>
> >>>> Most other c220g5 nodes give, e.g.:
> >>>>

> >>>> NAME VENDOR ?? MODEL ?? ?? ?? ?? ?? ??SERIAL ?? ?? ?? ?? ?? ?? ?? ?? SIZE TRAN
> >>>> sda ATA ?? ?? ??INTEL SSDSC2BB48 PHDV7241061B480BGN ?? 447.1G sas
> >>>> sdb SEAGATE ??ST1200MM0088 ?? ?? Z4028YJK0000C810EBZF ?? 1.1T sas

> >>>>
> >>>> Will this assignment be permanent or not deterministic?
> >>>
> >>> The Linux kernel does not guarantee deterministic block device naming.
> >>> The devices could be physically connected differently; or the devices or
> >>> I/O controller could have differences in driver probe/init timings. It's
> >>> best to write your setup scripts using lsblk, blkid, or sysfs (/sys/...)
> >>> to make sure you're targeting the drive you want.
> >>
> >> Thanks for your note! Is there a way of securing particular hosts (say,
> >> this very c220g5-110423 again) when creating an experiment? Or is it
> >> purely by chance? (I keep an informal record myself and I've been
> >> assigned to it twice and observed the same order in both experiments.)
> >
> > Yes, if you wanted to do this, you would add the following to your geni-
> > lib profile (or make it a profile parameter), assuming the node is bound
> > to the `node` Python variable:
> >
> > node.component_id =
> > "urn:publicid:IDN+wisc.cloudlab.us+node+c220g5-110423"
> > node.component_manager_id =
> > "urn:publicid:IDN+wisc.cloudlab.us+authority+cm"
>
> Cool great to know!
>
> Thanks,
> Wentao
>
> >
> >> Thanks,
> >> Wentao
> >
> > David
>

> --
> You received this message because you are subscribed to the Google Groups "cloudlab-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cloudlab-user...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/cloudlab-users/87de6975-7aa9-4a49-8f15-d3abe86e9dd3%40illinois.edu.

[Wentao Zhang]

On 2026-08-12 06:36, Mike Hibler wrote:
> Everything David says about deterministic naming is true, but in the case of
> these nodes it is generally deterministic but the disk boot order may just be
> wrong. I can attempt to fix it in the BIOS.

Thanks for looking into it!

Wentao

>> To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/cloudlab-users/87de6975-7aa9-4a49-8f15-d3abe86e9dd3*40illinois.edu__;JQ!!DZ3fjg!9BBbojZUe8KWbhNPwpBYtUGWOKWQe5mGXsRVYkjAEXT94j3hnrSoWdagEusZNOTRpnyEBBg01NXHVjRaOCWqa1I$ .
>

[Zhang, Wentao]

Hi,

c220g5-110907 seems to also have an inverse sda/sdb assignment (the
original post was about c220g5-110423).

$ lsblk -d -o NAME,VENDOR,MODEL,SIZE
NAME VENDOR MODEL SIZE
sda SEAGATE ST1200MM0088 1.1T
sdb ATA INTEL SSDSC2BB480G7K 447.1G

Thanks,
Wentao