Petric Frank <pfr...@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 >
