Forum: >>> Magnum BBS <<<

Re: map mainboard sata connector to device name

From tomas@tuxteam.de@21:1/5 to Petric Frank on Wed Apr 9 11:40:04 2025

On Wed, Apr 09, 2025 at 11:32:31AM +0200, Petric Frank wrote:

Hello,

i want to map the sata hardware connections to fixed device names. This be done even the hdd on the cable is changed.

So - when i connect a hdd to sata port 4 i want to get (for example) /dev/sdd created even /dev/sda to /dev/sdc (respective no hdd connected to sata 1 ... sata 3 port).

Any idea on how to configure this.

Does /dev/disk/by-path fulfil your needs?

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ/Y/WQAKCRAFyCz1etHa Rir2AJ4pm8n9eYQJOltKKOsOcPoPlj82hQCeKqink1FE5/7QIb+4u5QieOsLYzM=
=4V1w
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Petric Frank@21:1/5 to All on Wed Apr 9 11:40:04 2025

This is a multi-part message in MIME format.

Hello,

i want to map the sata hardware connections to fixed device names. This be
done even the hdd on the cable is changed.

So - when i connect a hdd to sata port 4 i want to get (for example) /dev/sdd created even /dev/sda to /dev/sdc (respective no hdd connected to sata 1 ... sata 3 port).

Any idea on how to configure this.

kind regards
Petric

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>Hello,
 i want to map the sata hardware connections to fixed device names. This be done even the hdd on the cable is changed.
 So - when i connect a hdd to sata port 4 i want to get (for example) /dev/sdd created even /dev/sda to /dev/sdc (respective no hdd connected to sata 1 ... sata 3 port).
 Any idea on how to configure this.
 kind regards
  Petric
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Dan Purgert@21:1/5 to Petric Frank on Wed Apr 9 12:50:01 2025

On Apr 09, 2025, Petric Frank wrote:

Hello,

i want to map the sata hardware connections to fixed device names. This be done even the hdd on the cable is changed.

So - when i connect a hdd to sata port 4 i want to get (for example)
/dev/sdd created even /dev/sda to /dev/sdc (respective no hdd
connected to sata 1 ... sata 3 port).

You don't. The first harddrive detected is always /dev/sda.

This is why we use UUIDs ;)

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmf2TzgACgkQbWVw5Uzn KGAt2RAAkCxMMi497k4SoJ0VvSjmc6mm//EVlrIeM0Zl2s86uLUZ1A0ykENLhRM8 wUpj5YQN9ZCAts1qRc42eaeoPqLI+5xneGuPl9Y/7Nbu5PjDUazrhUc81uLhGiVK X2xAb0Z/G+H/Bk1jOPHBkgJLeK+Cu2OtycB2s5S2JaM/qpZqM3vtHVVczws+rpHf 3c5Zdsapr66JhR6p2Azw59lCTB42rDqMiYhbEVxj3OsUsilqBkyNocS7I3nXkqHf tzmKQ2I7oJF0HCZMrbEvAXYFqZQhAQVN32EqUMJ5wsBMP6FwLL6+SWQxk38Yf6bx NdIG0hp0RLvUcXTqpaWHSQL8zViGkNe94B9cX8sFjgmsYWESogjkB3yzZr26+ieH UZWSOnUNiiub8OeA68/INCCrDDploxD+O1BqZ9g3FylcS3KCE0zS+HxdZBjsUESB eTWgstRBPKf2Uxs/XJS9geb8cUCYWqQvuOun13omWc2Y+PJUlsOc2Ld8i4Nr05k2 thyvXOMfJ1j1OOGhGfhz4eZMsGIbp1Jw6vc5OvlfnPW+MecYwCL3zbG1Lb+Hyzyc ufwab8oE284/iozRb+d4ic4gDJpJuPq5zGKPFJU9ipOuK8yJGhG2ebZQp8GY2wme cR7pUr6V9/pCIN7g62Vvrnj9pGF4u5nzUbc69Ozax2nL5x+RwaQ=
=B67n
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

From Petric Frank@21:1/5 to All on Wed Apr 9 13:50:01 2025

This is a multi-part message in MIME format.

Hello,

Am Mittwoch, 9. April 2025, 11:35:27 CEST schrieb tomas@tuxteam.de:

On Wed, Apr 09, 2025 at 11:32:31AM +0200, Petric Frank wrote:

Hello,

i want to map the sata hardware connections to fixed device names. This be done even the hdd on the cable is changed.

So - when i connect a hdd to sata port 4 i want to get (for example) /dev/sdd created even /dev/sda to /dev/sdc (respective no hdd connected
to sata 1 ... sata 3 port).

Any idea on how to configure this.

Does /dev/disk/by-path fulfil your needs?

Not exactly. The names are like pci-0000-0b:00:0-ata-4 and pci-0000-0d:00:0-ata-1.

Can i simply match *ata-<number> and take the "<number>" as connector id on the mainboard ?

Remark: The mainboard under test has 2 different sata controllers - one in the cpu and
one in the chipset.

regards
Petric

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>Hello,
 Am Mittwoch, 9. April 2025, 11:35:27 CEST schrieb tomas@tuxteam.de:
> On Wed, Apr 09, 2025 at 11:32:31AM +0200, Petric Frank wrote:
> > Hello,
> > 
> > i want to map the sata hardware connections to fixed device names. This be
> > done even the hdd on the cable is changed.
> > 
> > So - when i connect a hdd to sata port 4 i want to get (for example)
> > /dev/sdd created even /dev/sda to /dev/sdc (respective no hdd connected
> > to sata 1 ... sata 3 port).
> > 
> > Any idea on how to configure this.
> > Does /dev/disk/by-path fulfil your needs?
 Not exactly. The names are like pci-0000-0b:00:0-ata-4 and pci-0000-0d:00:0-ata-1.
 Can i simply match *ata-<number> and take the "<number>" as connector id on the mainboard ?
 Remark: The mainboard under test has 2 different sata controllers - one in the cpu and one in the chipset.
 regards
  Petric
 </body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From tomas@tuxteam.de@21:1/5 to Petric Frank on Wed Apr 9 14:00:01 2025

On Wed, Apr 09, 2025 at 01:41:21PM +0200, Petric Frank wrote:

Hello,

Am Mittwoch, 9. April 2025, 11:35:27 CEST schrieb tomas@tuxteam.de:

On Wed, Apr 09, 2025 at 11:32:31AM +0200, Petric Frank wrote:

Hello,

i want to map the sata hardware connections to fixed device names. This be
done even the hdd on the cable is changed.

So - when i connect a hdd to sata port 4 i want to get (for example) /dev/sdd created even /dev/sda to /dev/sdc (respective no hdd connected to sata 1 ... sata 3 port).

Any idea on how to configure this.

Does /dev/disk/by-path fulfil your needs?

Not exactly. The names are like pci-0000-0b:00:0-ata-4 and pci-0000-0d:00:0-ata-1.

Can i simply match *ata-<number> and take the "<number>" as connector id on the
mainboard ?

Possibly. I don't know. That will depend on how your hardware
exposes this info, how the kernel (drivers) pick it up and
how it passes it to udev, who is ultimately responsible of
creating these device nodes.

See e.g. here for the entry to this rabbit hole :)

https://unix.stackexchange.com/questions/86764/understanding-dev-disk-by-folders

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ/ZezwAKCRAFyCz1etHa RhnTAJ9evYdBFruUpL1MgNxFOo1oeW4z+wCbBFyhFNZQvkSMLN83mV84ngNzI0E=
=F4r0
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Michael Stone@21:1/5 to Petric Frank on Wed Apr 9 15:40:01 2025

On Wed, Apr 09, 2025 at 01:41:21PM +0200, Petric Frank wrote:

Am Mittwoch, 9. April 2025, 11:35:27 CEST schrieb tomas@tuxteam.de:

Does /dev/disk/by-path fulfil your needs?

Not exactly. The names are like pci-0000-0b:00:0-ata-4 and >pci-0000-0d:00:0-ata-1.

Yes, that's necessary to account for multiple sata controllers.

Can i simply match *ata-<number> and take the "<number>" as connector id on the
mainboard ?

No. The number is the sata device number on a particular controller.
They can overlap between controllers. E.g.:

pci-0000:2b:00.0-ata-1
pci-0000:2b:00.0-ata-2
pci-0000:2b:00.0-ata-3
pci-0000:2b:00.0-ata-4
pci-0000:2c:00.0-ata-1
pci-0000:2c:00.0-ata-6

That's from a server with 6 sata connectors and 2 m.2 sata slots. The 6
devices listed are all on sata connectors, and you can see that on the
second controller one is device 1 and one is device 6, with the 2 unused connectors and the m.2 slots using some combination of 2,3,4,5--they are clearly not numbered sequentially. On the motherboard they're labeled SATA_[01234567] and M2_[12]. There's no particular relationship between
how things are laid out on the motherboard and what they're connected to internally.

As someone else suggested, it's typically more useful to stick with
filesystem UUIDs and such rather than trying to map things physically.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Michael Stone@21:1/5 to Michael Stone on Wed Apr 9 15:40:02 2025

On Wed, Apr 09, 2025 at 09:36:11AM -0400, Michael Stone wrote:

On Wed, Apr 09, 2025 at 01:41:21PM +0200, Petric Frank wrote:

Am Mittwoch, 9. April 2025, 11:35:27 CEST schrieb tomas@tuxteam.de:

Does /dev/disk/by-path fulfil your needs?

Not exactly. The names are like pci-0000-0b:00:0-ata-4 and >>pci-0000-0d:00:0-ata-1.

Yes, that's necessary to account for multiple sata controllers.

Can i simply match *ata-<number> and take the "<number>" as connector id on the
mainboard ?

No. The number is the sata device number on a particular controller.
They can overlap between controllers. E.g.:

pci-0000:2b:00.0-ata-1
pci-0000:2b:00.0-ata-2
pci-0000:2b:00.0-ata-3
pci-0000:2b:00.0-ata-4
pci-0000:2c:00.0-ata-1
pci-0000:2c:00.0-ata-6

That's from a server with 6 sata connectors and 2 m.2 sata slots. The

that should be *8* sata connectors, with which the math makes sense

6 devices listed are all on sata connectors, and you can see that on
the second controller one is device 1 and one is device 6, with the 2
unused connectors and the m.2 slots using some combination of
2,3,4,5--they are clearly not numbered sequentially. On the
motherboard they're labeled SATA_[01234567] and M2_[12]. There's no >particular relationship between how things are laid out on the
motherboard and what they're connected to internally.

As someone else suggested, it's typically more useful to stick with >filesystem UUIDs and such rather than trying to map things physically.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Petric Frank@21:1/5 to All on Wed Apr 9 17:50:01 2025

This is a multi-part message in MIME format.

Hello,

Am Mittwoch, 9. April 2025, 15:36:11 CEST schrieb Michael Stone:

On Wed, Apr 09, 2025 at 01:41:21PM +0200, Petric Frank wrote:

Am Mittwoch, 9. April 2025, 11:35:27 CEST schrieb tomas@tuxteam.de:

Does /dev/disk/by-path fulfil your needs?

Not exactly. The names are like pci-0000-0b:00:0-ata-4 and >pci-0000-0d:00:0-ata-1.

Yes, that's necessary to account for multiple sata controllers.

Can i simply match *ata-<number> and take the "<number>" as connector id on >the mainboard ?

No. The number is the sata device number on a particular controller.
They can overlap between controllers. E.g.:

pci-0000:2b:00.0-ata-1
pci-0000:2b:00.0-ata-2
pci-0000:2b:00.0-ata-3
pci-0000:2b:00.0-ata-4
pci-0000:2c:00.0-ata-1
pci-0000:2c:00.0-ata-6

That's from a server with 6 sata connectors and 2 m.2 sata slots. The 6 devices listed are all on sata connectors, and you can see that on the
second controller one is device 1 and one is device 6, with the 2 unused connectors and the m.2 slots using some combination of 2,3,4,5--they are clearly not numbered sequentially. On the motherboard they're labeled SATA_[01234567] and M2_[12]. There's no particular relationship between
how things are laid out on the motherboard and what they're connected to internally.

In this case i have to manually create a mapping from pci-id (of the controller) together
with the "ata-x" to the sata connection number printed on the motherboard. Based on the mapping udev rules are to be created to get device entries driven by the
cable ids.

Due i am not firm with udev rules - any hint on these ?

regards
Petric

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>Hello,
 Am Mittwoch, 9. April 2025, 15:36:11 CEST schrieb Michael Stone:
> On Wed, Apr 09, 2025 at 01:41:21PM +0200, Petric Frank wrote:
> >Am Mittwoch, 9. April 2025, 11:35:27 CEST schrieb tomas@tuxteam.de:
> >> Does /dev/disk/by-path fulfil your needs?
> >
> >Not exactly. The names are like pci-0000-0b:00:0-ata-4 and
> >pci-0000-0d:00:0-ata-1.
> > Yes, that's necessary to account for multiple sata controllers.
> > >Can i simply match *ata-<number> and take the "<number>" as connector id on
> >the mainboard ?
> > No. The number is the sata device number on a particular controller.
> They can overlap between controllers. E.g.:
> > pci-0000:2b:00.0-ata-1
> pci-0000:2b:00.0-ata-2
> pci-0000:2b:00.0-ata-3
> pci-0000:2b:00.0-ata-4
> pci-0000:2c:00.0-ata-1
> pci-0000:2c:00.0-ata-6
> > That's from a server with 6 sata connectors and 2 m.2 sata slots. The 6
> devices listed are all on sata connectors, and you can see that on the
> second controller one is device 1 and one is device 6, with the 2 unused
> connectors and the m.2 slots using some combination of 2,3,4,5--they are
> clearly not numbered sequentially. On the motherboard they're labeled
> SATA_[01234567] and M2_[12]. There's no particular relationship between
> how things are laid out on the motherboard and what they're connected to
> internally.
 In this case i have to manually create a mapping from pci-id (of the controller) together with the "ata-x" to the sata connection number printed on the motherboard.
Based on the mapping udev rules are to be created to get device entries driven by the cable ids.
 Due i am not firm with udev rules - any hint on these ?
 regards
 Petric
 </body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Andy Smith@21:1/5 to Petric Frank on Thu Apr 10 00:20:02 2025

Hi,

On Wed, Apr 09, 2025 at 05:46:32PM +0200, Petric Frank wrote:

In this case i have to manually create a mapping from pci-id (of the controller) together with the "ata-x" to the sata connection number
printed on the motherboard. Based on the mapping udev rules are to be
created to get device entries driven by the cable ids.

Due i am not firm with udev rules - any hint on these ?

You have yet to explain why block device serial numbers
(/dev/disk/by-id/) and filesystem UUIDs (/dev/disk/by-uuid/) are not
sufficient for your use case.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Felix Miata@21:1/5 to All on Thu Apr 10 01:40:01 2025

Petric Frank composed on 2025-04-09 11:32 (UTC+0200):

i want to map the sata hardware connections to fixed device names. This be done even the hdd on the cable is changed.

So - when i connect a hdd to sata port 4 i want to get (for example) /dev/sdd created even /dev/sda to /dev/sdc (respective no hdd connected to sata 1 ... sata 3 port).

Any idea on how to configure this.

Nothing I know of. Why? You have other options at the ready:
# ls -1 /dev/disk/
by-diskseq
by-id
by-label
by-partlabel
by-partuuid
by-path
by-uuid
# egrep 'swap|fat|ext' /etc/fstab | wc -l
23
# grep UUID /etc/fstab | wc -l

0
# grep LABEL /etc/fstab | wc -l
23
#

Just as seen in any recent OEM /etc/fstab, a filesystem's UUID= contains an as unique identifier as anyone should need. I use an alternate, LABEL=, here, easier
to remember strings shorter than the 36 characters of UUIDs, unique enough for the
task, and totally under admin creation and control.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Petric Frank@21:1/5 to All on Thu Apr 10 05:50:01 2025

This is a multi-part message in MIME format.

Hello,

Am Donnerstag, 10. April 2025, 00:13:10 CEST schrieb Andy Smith:

Hi,

On Wed, Apr 09, 2025 at 05:46:32PM +0200, Petric Frank wrote:

In this case i have to manually create a mapping from pci-id (of the controller) together with the "ata-x" to the sata connection number
printed on the motherboard. Based on the mapping udev rules are to be created to get device entries driven by the cable ids.

Due i am not firm with udev rules - any hint on these ?

You have yet to explain why block device serial numbers
(/dev/disk/by-id/) and filesystem UUIDs (/dev/disk/by-uuid/) are not sufficient for your use case.

Ok. Lets take an example - a NAS using screwless hdd hotplug trays.

Each hdd has a slot to be accessed external (bay 1...6). If a hdd fails how do you know in
which bay you find the hdd which failed ?

Due the dynamic mapping of sata cable to device name is not fixed you can't. You have
(for example) to evaluate the other drives serial number and match them with the ones
on the hdds itself. The one which is missing will be the one to be replaced.

But if you have a fixed relationship from /dev/sd[x] to the connector on the mainboard
(and as result on the hdd tray) this will be an easy task.

regards
Petric

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>Hello,
 Am Donnerstag, 10. April 2025, 00:13:10 CEST schrieb Andy Smith:
> Hi,
> > On Wed, Apr 09, 2025 at 05:46:32PM +0200, Petric Frank wrote:
> > In this case i have to manually create a mapping from pci-id (of the
> > controller) together with the "ata-x" to the sata connection number
> > printed on the motherboard. Based on the mapping udev rules are to be
> > created to get device entries driven by the cable ids.
> > 
> > Due i am not firm with udev rules - any hint on these ?
> > You have yet to explain why block device serial numbers
> (/dev/disk/by-id/) and filesystem UUIDs (/dev/disk/by-uuid/) are not
> sufficient for your use case.
 Ok. Lets take an example - a NAS using screwless hdd hotplug trays.
 Each hdd has a slot to be accessed external (bay 1...6). If a hdd fails how do you know in which bay you find the hdd which failed ?
 Due the dynamic mapping of sata cable to device name is not fixed you can't. You have (for example) to evaluate the other drives serial number and match them with the ones on the
hdds itself. The one which is missing will be the one to be replaced.
 But if you have a fixed relationship from /dev/sd[x] to the connector on the mainboard (and as result on the hdd tray) this will be an easy task.
 regards
  Petric
 </body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Titus Newswanger@21:1/5 to Petric Frank on Thu Apr 10 06:50:01 2025

This is a multi-part message in MIME format.
On 4/9/25 22:42, Petric Frank wrote:

Hello,

Am Donnerstag, 10. April 2025, 00:13:10 CEST schrieb Andy Smith:

Hi,

On Wed, Apr 09, 2025 at 05:46:32PM +0200, Petric Frank wrote:

In this case i have to manually create a mapping from pci-id (of the

controller) together with the "ata-x" to the sata connection number

printed on the motherboard. Based on the mapping udev rules are to be

created to get device entries driven by the cable ids.

Due i am not firm with udev rules - any hint on these ?

You have yet to explain why block device serial numbers

(/dev/disk/by-id/) and filesystem UUIDs (/dev/disk/by-uuid/) are not

sufficient for your use case.

Ok. Lets take an example - a NAS using screwless hdd hotplug trays.

Each hdd has a slot to be accessed external (bay 1...6). If a hdd
fails how do you know in which bay you find the hdd which failed ?

Due the dynamic mapping of sata cable to device name is not fixed you
can't. You have (for example) to evaluate the other drives serial
number and match them with the ones on the hdds itself. The one which
is missing will be the one to be replaced.

I had the same problem. Here is what worked for me:

First, during scheduled down-time, I pulled each HDD one at a time and
noted its serial number and position (slot number) on a chart. Now I can
use smartctl to view the relation of /dev/sdx - to - serial number.
Another thing I sometimes do is label the front of the HDD caddy with
HDD serial number, if it is possible to do so without blocking airflow
with the labels.

You can list the drives:

me@srv1:~$ smartctl --scan

/dev/sda -d scsi # /dev/sda, SCSI device
/dev/sdb -d scsi # /dev/sdb, SCSI device
/dev/sdc -d scsi # /dev/sdc, SCSI device
/dev/sdd -d scsi # /dev/sdd, SCSI device
/dev/sde -d scsi # /dev/sde, SCSI device
/dev/sdf -d scsi # /dev/sdf, SCSI device
/dev/sdg -d scsi # /dev/sdg, SCSI device
/dev/sdh -d scsi # /dev/sdh, SCSI device
/dev/sdi -d scsi # /dev/sdi, SCSI device
/dev/sdj -d scsi # /dev/sdj, SCSI device
/dev/sdk -d scsi # /dev/sdk, SCSI device
/dev/sdl -d scsi # /dev/sdl, SCSI device
/dev/sdm -d scsi # /dev/sdm, SCSI device

If your RAID monitoring notices disc /dev/sda is broken, run the
following command to view among other things, serial number of sda. Then
I can confidently pull the HDD I previously marked with the same s.n. In
my case sda is currently this server's only boot disc...

Also check out man smartctl, you can get a wealth of info from drives.

me@srv1:~$ sudo smartctl -i /dev/sda

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.2.0-31-generic] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model: LK0200GEYMR
Serial Number: BTHC549304ZT200TGN
LU WWN Device Id: 5 5cd2e4 04c1623ca
Firmware Version: 4IWTHPG1
User Capacity: 200,049,647,616 bytes [200 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
TRIM Command: Available, deterministic, zeroed
Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2 T13/2015-D revision 3
SATA Version is: SATA 2.6, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Wed Apr 9 23:12:12 2025 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

A SAS disk in my pool....

me@srv1:~$ sudo smartctl -i /dev/sdb
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.2.0-31-generic] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor: SEAGATE
Product: ST4000NM0023 Revision: GS15
Compliance: SPC-4
User Capacity: 4,000,787,030,016 bytes [4.00 TB]
Logical block size: 512 bytes
LU is fully provisioned
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Logical Unit id: 0x5000c500842f46db
Serial number: Z1Z9KGRF
Device type: disk
Transport protocol: SAS (SPL-3)
Local Time is: Wed Apr 9 23:12:18 2025 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning: Disabled or Not Supported

Umm... just now thought of it, this server is still on Ubuntu, I hardly
ever look at it it and tend to forget it didn't get Debian at the same
time everything else around here did., however I just now checked,
smartctl will work with the same commands on Debian Bookworm.

If you don't have smartctl, install the smartmontools package.

But if you have a fixed relationship from /dev/sd[x] to the connector
on the mainboard (and as result on the hdd tray) this will be an easy
task.

regards

Petric

--

Titus Newswanger
Curtiss WI

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 4/9/25 22:42, Petric Frank wrote: 
</div>
<blockquote type="cite" cite="mid:2853397.BEx9A2HvPv@main">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hello,
 
Am
Donnerstag, 10. April 2025, 00:13:10 CEST schrieb Andy Smith:
>
Hi,
>

>
On Wed, Apr 09, 2025 at 05:46:32PM +0200, Petric Frank wrote:
>
> In this case i have to manually create a mapping from
pci-id (of the
>
> controller) together with the "ata-x" to the sata
connection number
>
> printed on the motherboard. Based on the mapping udev rules
are to be
>
> created to get device entries driven by the cable ids.
>
> 
>
> Due i am not firm with udev rules - any hint on these ?
>

>
You have yet to explain why block device serial numbers
>
(/dev/disk/by-id/) and filesystem UUIDs (/dev/disk/by-uuid/) are
not
>
sufficient for your use case.
 
Ok.
Lets take an example - a NAS using screwless hdd hotplug trays.
 
Each
hdd has a slot to be accessed external (bay 1...6). If a hdd
fails how do you know in which bay you find the hdd which failed
?
 
Due
the dynamic mapping of sata cable to device name is not fixed
you can't. You have (for example) to evaluate the other drives
serial number and match them with the ones on the hdds itself.
The one which is missing will be the one to be replaced.
 
</blockquote>
I had the same problem. Here is what worked for me:
First, during scheduled down-time, I pulled each HDD one at a
time and noted its serial number and position (slot number) on a
chart. Now I can use smartctl to view the relation of /dev/sdx -
to - serial number. Another thing I sometimes do is label the
front of the HDD caddy with HDD serial number, if it is possible
to do so without blocking airflow with the labels.
You can list the drives:
me@srv1:~$ smartctl --scan 

/dev/sda -d scsi # /dev/sda, SCSI device 
/dev/sdb -d scsi # /dev/sdb, SCSI device 
/dev/sdc -d scsi # /dev/sdc, SCSI device 
/dev/sdd -d scsi # /dev/sdd, SCSI device 
/dev/sde -d scsi # /dev/sde, SCSI device 
/dev/sdf -d scsi # /dev/sdf, SCSI device 
/dev/sdg -d scsi # /dev/sdg, SCSI device 
/dev/sdh -d scsi # /dev/sdh, SCSI device 
/dev/sdi -d scsi # /dev/sdi, SCSI device 
/dev/sdj -d scsi # /dev/sdj, SCSI device 
/dev/sdk -d scsi # /dev/sdk, SCSI device 
/dev/sdl -d scsi # /dev/sdl, SCSI device 
/dev/sdm -d scsi # /dev/sdm, SCSI device
 

If your RAID monitoring notices disc /dev/sda is broken, run the
following command to view among other things, serial number of
sda. Then I can confidently pull the HDD I previously marked with
the same s.n. In my case sda is currently this server's only boot
disc...
Also check out man smartctl, you can get a wealth of info from
drives.
 

me@srv1:~$ sudo smartctl -i /dev/sda 

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.2.0-31-generic]
(local build) 
Copyright (C) 2002-20, Bruce Allen, Christian Franke,
<a class="moz-txt-link-abbreviated" href="http://www.smartmontools.org">www.smartmontools.org</a> 
 
=== START OF INFORMATION SECTION === 
Device Model: LK0200GEYMR 
Serial Number: BTHC549304ZT200TGN 
LU WWN Device Id: 5 5cd2e4 04c1623ca 
Firmware Version: 4IWTHPG1 
User Capacity: 200,049,647,616 bytes [200 GB] 
Sector Sizes: 512 bytes logical, 4096 bytes physical 
Rotation Rate: Solid State Device 
Form Factor: 2.5 inches 
TRIM Command: Available, deterministic, zeroed 
Device is: Not in smartctl database [for details use: -P
showall] 
ATA Version is: ACS-2 T13/2015-D revision 3 
SATA Version is: SATA 2.6, 6.0 Gb/s (current: 6.0 Gb/s) 
Local Time is: Wed Apr 9 23:12:12 2025 CDT 
SMART support is: Available - device has SMART capability. 
SMART support is: Enabled 

 

A SAS disk in my pool.... 

me@srv1:~$ sudo smartctl -i /dev/sdb 
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.2.0-31-generic]
(local build) 
Copyright (C) 2002-20, Bruce Allen, Christian Franke,
<a class="moz-txt-link-abbreviated" href="http://www.smartmontools.org">www.smartmontools.org</a> 
 
=== START OF INFORMATION SECTION === 
Vendor: SEAGATE 
Product: ST4000NM0023 
Revision: GS15 
Compliance: SPC-4 
User Capacity: 4,000,787,030,016 bytes [4.00 TB] 
Logical block size: 512 bytes 
LU is fully provisioned 
Rotation Rate: 7200 rpm 
Form Factor: 3.5 inches 
Logical Unit id: 0x5000c500842f46db 
Serial number: Z1Z9KGRF 
Device type: disk 
Transport protocol: SAS (SPL-3) 
Local Time is: Wed Apr 9 23:12:18 2025 CDT 
SMART support is: Available - device has SMART capability. 
SMART support is: Enabled 
Temperature Warning: Disabled or Not Supported
Umm... just now thought of it, this server is still on Ubuntu, I
hardly ever look at it it and tend to forget it didn't get Debian
at the same time everything else around here did., however I just
now checked, smartctl will work with the same commands on Debian
Bookworm.
If you don't have smartctl, install the smartmontools package. 

<blockquote type="cite" cite="mid:2853397.BEx9A2HvPv@main">
But
if you have a fixed relationship from /dev/sd[x] to the
connector on the mainboard (and as result on the hdd tray) this
will be an easy task.
 
regards

Petric
 
</blockquote>
<pre class="moz-signature" cols="72">--

Titus Newswanger
Curtiss WI</pre>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Petric Frank@21:1/5 to All on Thu Apr 10 08:50:02 2025

This is a multi-part message in MIME format.

Hello,

Am Donnerstag, 10. April 2025, 06:47:13 CEST schrieb Titus Newswanger:

On 4/9/25 22:42, Petric Frank wrote:

Hello,

Am Donnerstag, 10. April 2025, 00:13:10 CEST schrieb Andy Smith:

Hi,

On Wed, Apr 09, 2025 at 05:46:32PM +0200, Petric Frank wrote:

In this case i have to manually create a mapping from pci-id (of the

controller) together with the "ata-x" to the sata connection number

printed on the motherboard. Based on the mapping udev rules are to be

created to get device entries driven by the cable ids.

Due i am not firm with udev rules - any hint on these ?

You have yet to explain why block device serial numbers

(/dev/disk/by-id/) and filesystem UUIDs (/dev/disk/by-uuid/) are not

sufficient for your use case.

Ok. Lets take an example - a NAS using screwless hdd hotplug trays.

Each hdd has a slot to be accessed external (bay 1...6). If a hdd
fails how do you know in which bay you find the hdd which failed ?

Due the dynamic mapping of sata cable to device name is not fixed you can't. You have (for example) to evaluate the other drives serial
number and match them with the ones on the hdds itself. The one which
is missing will be the one to be replaced.

I had the same problem. Here is what worked for me:

First, during scheduled down-time, I pulled each HDD one at a time and
noted its serial number and position (slot number) on a chart. Now I can
use smartctl to view the relation of /dev/sdx - to - serial number.
Another thing I sometimes do is label the front of the HDD caddy with
HDD serial number, if it is possible to do so without blocking airflow
with the labels.

You can list the drives:

me@srv1:~$ smartctl --scan

/dev/sda -d scsi # /dev/sda, SCSI device
/dev/sdb -d scsi # /dev/sdb, SCSI device
/dev/sdc -d scsi # /dev/sdc, SCSI device
/dev/sdd -d scsi # /dev/sdd, SCSI device
/dev/sde -d scsi # /dev/sde, SCSI device
/dev/sdf -d scsi # /dev/sdf, SCSI device
/dev/sdg -d scsi # /dev/sdg, SCSI device
/dev/sdh -d scsi # /dev/sdh, SCSI device
/dev/sdi -d scsi # /dev/sdi, SCSI device
/dev/sdj -d scsi # /dev/sdj, SCSI device
/dev/sdk -d scsi # /dev/sdk, SCSI device
/dev/sdl -d scsi # /dev/sdl, SCSI device
/dev/sdm -d scsi # /dev/sdm, SCSI device

If your RAID monitoring notices disc /dev/sda is broken, run the
following command to view among other things, serial number of sda. Then
I can confidently pull the HDD I previously marked with the same s.n. In
my case sda is currently this server's only boot disc...

Similar thing i did up to now - document the serial number to map the drive.

But too often i lost this docs and had to fall back to the manual steps.

So if the sata connection directly maps to the device name i never have to keep this info
again. Also this would be easier for technical "noobs" to identify and replace the drive.

regards
Petric

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>Hello,
 Am Donnerstag, 10. April 2025, 06:47:13 CEST schrieb Titus Newswanger:
> On 4/9/25 22:42, Petric Frank wrote:
> > Hello,
> > 
> > Am Donnerstag, 10. April 2025, 00:13:10 CEST schrieb Andy Smith:
> > > Hi,
> > > 
> > > On Wed, Apr 09, 2025 at 05:46:32PM +0200, Petric Frank wrote:
> > > > In this case i have to manually create a mapping from pci-id (of the
> > > > 
> > > > controller) together with the "ata-x" to the sata connection number
> > > > 
> > > > printed on the motherboard. Based on the mapping udev rules are to be
> > > > 
> > > > created to get device entries driven by the cable ids.
> > > > 
> > > > 
> > > > 
> > > > Due i am not firm with udev rules - any hint on these ?
> > > 
> > > You have yet to explain why block device serial numbers
> > > 
> > > (/dev/disk/by-id/) and filesystem UUIDs (/dev/disk/by-uuid/) are not
> > > 
> > > sufficient for your use case.
> > 
> > Ok. Lets take an example - a NAS using screwless hdd hotplug trays.
> > 
> > 
> > Each hdd has a slot to be accessed external (bay 1...6). If a hdd
> > fails how do you know in which bay you find the hdd which failed ?
> > 
> > 
> > Due the dynamic mapping of sata cable to device name is not fixed you
> > can't. You have (for example) to evaluate the other drives serial
> > number and match them with the ones on the hdds itself. The one which
> > is missing will be the one to be replaced.
> > I had the same problem. Here is what worked for me:
> > First, during scheduled down-time, I pulled each HDD one at a time and
> noted its serial number and position (slot number) on a chart. Now I can
> use smartctl to view the relation of /dev/sdx - to - serial number.
> Another thing I sometimes do is label the front of the HDD caddy with
> HDD serial number, if it is possible to do so without blocking airflow
> with the labels.
> > You can list the drives:
> > me@srv1:~$ smartctl --scan
> > /dev/sda -d scsi # /dev/sda, SCSI device
> /dev/sdb -d scsi # /dev/sdb, SCSI device
> /dev/sdc -d scsi # /dev/sdc, SCSI device
> /dev/sdd -d scsi # /dev/sdd, SCSI device
> /dev/sde -d scsi # /dev/sde, SCSI device
> /dev/sdf -d scsi # /dev/sdf, SCSI device
> /dev/sdg -d scsi # /dev/sdg, SCSI device
> /dev/sdh -d scsi # /dev/sdh, SCSI device
> /dev/sdi -d scsi # /dev/sdi, SCSI device
> /dev/sdj -d scsi # /dev/sdj, SCSI device
> /dev/sdk -d scsi # /dev/sdk, SCSI device
> /dev/sdl -d scsi # /dev/sdl, SCSI device
> /dev/sdm -d scsi # /dev/sdm, SCSI device
> > > If your RAID monitoring notices disc /dev/sda is broken, run the
> following command to view among other things, serial number of sda. Then
> I can confidently pull the HDD I previously marked with the same s.n. In
> my case sda is currently this server's only boot disc...
 Similar thing i did up to now - document the serial number to map the drive.
 But too often i lost this docs and had to fall back to the manual steps.
 So if the sata connection directly maps to the device name i never have to keep this info again. Also this would be easier for technical "noobs" to identify and replace
the drive.
 regards
  Petric
 </body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From debian-user@howorth.org.uk@21:1/5 to Petric Frank on Thu Apr 10 11:20:02 2025

Petric Frank <pfrank@gmx.de> wrote:

Hello,

Am Donnerstag, 10. April 2025, 06:47:13 CEST schrieb Titus Newswanger:

On 4/9/25 22:42, Petric Frank wrote:

Hello,

Am Donnerstag, 10. April 2025, 00:13:10 CEST schrieb Andy Smith:

Hi,

On Wed, Apr 09, 2025 at 05:46:32PM +0200, Petric Frank wrote:

In this case i have to manually create a mapping from pci-id
(of the

controller) together with the "ata-x" to the sata connection
number

printed on the motherboard. Based on the mapping udev rules
are to be

created to get device entries driven by the cable ids.

Due i am not firm with udev rules - any hint on these ?

You have yet to explain why block device serial numbers

(/dev/disk/by-id/) and filesystem UUIDs (/dev/disk/by-uuid/)
are not

sufficient for your use case.

Ok. Lets take an example - a NAS using screwless hdd hotplug
trays.

Each hdd has a slot to be accessed external (bay 1...6). If a hdd
fails how do you know in which bay you find the hdd which failed ?

Due the dynamic mapping of sata cable to device name is not fixed
you can't. You have (for example) to evaluate the other drives
serial number and match them with the ones on the hdds itself.
The one which is missing will be the one to be replaced.

I had the same problem. Here is what worked for me:

First, during scheduled down-time, I pulled each HDD one at a time
and noted its serial number and position (slot number) on a chart.
Now I can use smartctl to view the relation of /dev/sdx - to -
serial number. Another thing I sometimes do is label the front of
the HDD caddy with HDD serial number, if it is possible to do so
without blocking airflow with the labels.

You can list the drives:

me@srv1:~$ smartctl --scan

/dev/sda -d scsi # /dev/sda, SCSI device
/dev/sdb -d scsi # /dev/sdb, SCSI device
/dev/sdc -d scsi # /dev/sdc, SCSI device
/dev/sdd -d scsi # /dev/sdd, SCSI device
/dev/sde -d scsi # /dev/sde, SCSI device
/dev/sdf -d scsi # /dev/sdf, SCSI device
/dev/sdg -d scsi # /dev/sdg, SCSI device
/dev/sdh -d scsi # /dev/sdh, SCSI device
/dev/sdi -d scsi # /dev/sdi, SCSI device
/dev/sdj -d scsi # /dev/sdj, SCSI device
/dev/sdk -d scsi # /dev/sdk, SCSI device
/dev/sdl -d scsi # /dev/sdl, SCSI device
/dev/sdm -d scsi # /dev/sdm, SCSI device

If your RAID monitoring notices disc /dev/sda is broken, run the
following command to view among other things, serial number of sda.
Then I can confidently pull the HDD I previously marked with the
same s.n. In my case sda is currently this server's only boot
disc...

Similar thing i did up to now - document the serial number to map the
drive.

But too often i lost this docs and had to fall back to the manual
steps.

So if the sata connection directly maps to the device name i never
have to keep this info again. Also this would be easier for technical
"noobs" to identify and replace the drive.

Serious disk enclosures have lights that can be turned on to indicate
which disk has failed.

regards
Petric

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Anssi Saari@21:1/5 to debian-user@howorth.org.uk on Thu Apr 10 14:10:02 2025

debian-user@howorth.org.uk writes:

Serious disk enclosures have lights that can be turned on to indicate
which disk has failed.

Yes. I take it the actual question is, is there a DIY version of that?
This sort of thing is why I mostly do just mirroring.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Dan Ritter@21:1/5 to Anssi Saari on Thu Apr 10 15:40:02 2025

Anssi Saari wrote:

debian-user@howorth.org.uk writes:

Serious disk enclosures have lights that can be turned on to indicate
which disk has failed.

Yes. I take it the actual question is, is there a DIY version of that?
This sort of thing is why I mostly do just mirroring.

If each disk has an activity LED but not an addressable fault
LED, you can run

dd if=/dev/sdX of=/dev/null

to keep the activity LED lit for a while.

Addressable fault LEDs usually have a manufacturer-specific tool
to turn them on and off; this is generally controlled by a RAID
controller utility or an enclosure-specific utility.

-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Andy Smith@21:1/5 to Petric Frank on Fri Apr 11 13:30:02 2025

Hi,

On Thu, Apr 10, 2025 at 05:42:43AM +0200, Petric Frank wrote:

Am Donnerstag, 10. April 2025, 00:13:10 CEST schrieb Andy Smith:

You have yet to explain why block device serial numbers
(/dev/disk/by-id/) and filesystem UUIDs (/dev/disk/by-uuid/) are not sufficient for your use case.

Ok. Lets take an example - a NAS using screwless hdd hotplug trays.

Each hdd has a slot to be accessed external (bay 1...6). If a hdd
fails how do you know in which bay you find the hdd which failed ?

This is a problem which anyone with multiple drives in cheap enclosures
has faced. There is a reason why so few of those people try to do what
you are doing.

Myself, if the enclosure does not have an identity LED for each drive
(i.e. it's cheap) then I label the tray with the drive serial number at
the point where the drive is put in to it to begin with. As you have
noted, this requires some discipline. I don't think you can avoid this.
It's going to be required anyway.

If you have a fixed relationship from /dev/sd[x] to the connector on
the mainboard (and as result on the hdd tray) this will be an easy
task.

Thing is, I think the risk of the motherboard-port-to-drive-bay mappings re-ordering themselves at some point in the future is so high that I
would never bother to make my whole process rely upon that. Printing a
label for each drive is so simple and foolproof that it's simply the
best way to go, if you don't have drive identity LEDs. It has worked for
me for more than 25 years.

But, I can see you are keen to do this and there is also the saying
about people telling you that something is impossible until you do it,
so, good luck!

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Who's Online
Recent Visitors
- Plume
  Sun Sep 14 09:34:52 2025
  from Uk via Raw
- Gretchiie
  Sun Sep 14 06:07:30 2025
  from Derry, Nh via Telnet
- Thlc
  Sat Sep 13 17:11:34 2025
  from Rognac, France via Telnet
- Thlc
  Sat Sep 13 17:04:03 2025
  from Rognac, France via Telnet
- Thlc
  Sat Sep 13 16:32:19 2025
  from Rognac, France via SSH
- Thlc
  Sat Sep 13 15:41:11 2025
  from Rognac, France via SSH
- Thlc
  Sat Sep 13 07:56:03 2025
  from Rognac, France via SSH
- Gretchiie
  Sat Sep 13 07:22:10 2025
  from Derry, Nh via Telnet

System Info

Sysop:	Keyop
Location:	Huddersfield, West Yorkshire, UK
Users:	546
Nodes:	16 (0 / 16)
Uptime:	162:21:15
Calls:	10,385
Calls today:	2
Files:	14,057
Messages:	6,416,501

Re: map mainboard sata connector to device name

Who's Online

Recent Visitors

System Info