Disk mapping broken on DXP6800 Pro #9
Comments
|
Can you check that whether Regarding the script, it is unfortunate to hear that the hctl mapping does not work on your model. For the If the issue lies in the problem mentioned above, a workaround could be adding a udev rule to restart the systemd service / the script when a disk removal or insertion event occurs. |
|
maybe mapping by |
|
@miskcoo the kernel modules itself works. Disk6 doenst work only with |
That seems work and is equivalent to HTCL in my model. How about yours? Would it be stable? I guess using the alphabetical order of these paths would be a possible solution. |
|
For the disk6 issue in the serial mapping mode, can you apply this patch and run the script diff --git a/scripts/ugreen-diskiomon b/scripts/ugreen-diskiomon
index 1c00117..76152ec 100755
--- a/scripts/ugreen-diskiomon
+++ b/scripts/ugreen-diskiomon
@@ -43,6 +43,7 @@ done <<< "$(lsblk -S -o name,${mapping_method} | tail -n +2)"
for i in "${!led_map[@]}"; do
led=${led_map[i]}
if [[ -d /sys/class/leds/$led ]]; then
+ echo "set ${led} to the oneshot mode"
echo oneshot > /sys/class/leds/$led/trigger
echo 1 > /sys/class/leds/$led/invert
echo 100 > /sys/class/leds/$led/delay_on
@@ -57,6 +58,7 @@ for i in "${!led_map[@]}"; do
devices[$led]=${dev}
else
# turn off the led if no disk installed on this slot
+ echo "${dev} not found, turn off ${led}"
echo 0 > /sys/class/leds/$led/brightness
echo none > /sys/class/leds/$led/trigger
fi
|
|
|
It seems they are also the same? |
|
not sure, if i understand the arch wiki correct I have some spare time later, I can give it a try |
|
I do not see anything that has not been said before. The mapping of sdX to physical devices (as denoted by /dev/disk/by-path or HCTL) is indeed random - that is why we do not rely on sdX enumeration for locating the disks. In your cited example, we have: So what is wrong, actually with using HCTL for location? What I care more about is what happens when you remove a disk in the middle, say, disk4. |
|
Your serial of disk 6 seems 1 letter longer than other disks. Is that a typo in your post or in your script? |
u are right... |
Disk6 is actual sda at the moment. serial seems to work now |
|
As I said: sdX is random with every reboot - what would be more interesting is if the slot numbers did not correlate with the HCTL order or are - as you claim - random, too (which I doubt). Iff that is the case, we would have to reorder the HCTL values in hctl_map to fix it - BUT I have just verified for my DXP8800, the HCTL order does in fact correlate with the order of the disk slots and the by-path correlates with HCTL: As you can see, sdb and sdc are out of order (i.e. they can be random), but HCTL is not - plus, I have verified the slot order by looking at each serial. I think @miskcoo did the same for his DXP4800. In order to check if the DXP6800 is special, please show that HCTL order does not fit your slot order by showing us the output of "lsblk -S -x hctl -o name,hctl,serial" (we assume that the verified slot order of your serial numbers in the initial post is 1-6). |
|
@miskcoo: You should probably change the comment:
to:
Otherwise, people will just execute that and list the serial numbers in the random sdX order (which will be wrong in almost all cases). |
|
I am fine with the serial implementation at the moment. Also taking an eye on Thanks for your work and support! :) |
|
I can check hctl after a fresh reboot. Running badblocks at the moment (24h left) |
|
hctl seems to work, maybe the readme should include a step to configure the mapping? Correct order is Think we can close this issue. |
|
O.K., so HCTL is predictable, but in the case of your DXP6800, the mapping between HCTL and slots is: 0:0:0:0 -> disk5 Which is unexpected and makes HCTL mapping for that device useless as-is. Whereas with the DXP4800 it is (expected): 0:0:0:0 -> disk1 and with the DXP8800 it is: 0:0:0:0 -> disk1 So, the issue can be closed, but:
|
|
Maybe, my dropbear-initramfs mess this up (my root volume is encrypted). |
|
Nope, most probably not. This has to do with how the SATA controllers are connected to the PCIe bus and then to the disk slots. There are up to 4 SATA channels on each controller chip, but yours is not in this configuration: first controller -> disk1-4 but: first controller -> disk5-6 which results in the HCTL order we see. For the DXP8800, the configuration is: first controller -> disk1-4 |
|
Interesting. I think I should mention this in the document or script. |
I tried the
hctlandserialmapping methodshctl: changes by everytime I reboot or add/remove a disk
serial: Disk6 is off all the time, and I think there is bug when one disk is missing. I test it more later.
running on Debian 12, Linux 6.1.0-21 using dkms
The text was updated successfully, but these errors were encountered: