Errors in HA logs regarding disks #37

ond000 · 2024-12-29T16:41:02Z

Describe the bug
From last update I've got some errors in HA log regarding disks (one note, from error is not clear from which device is that error):

Regarding Spindowns, for all disks I have set Default delay.

Logger: custom_components.unraid.diagnostics.parity
Zdroj: custom_components/unraid/diagnostics/parity.py:98
integrace: UNRAID ([dokumentace](https://github.com/domalab/ha-unraid/wiki), [problémy](https://github.com/domalab/ha-unraid/issues))
První výskyt: 16:59:55 (1 výskyty)
Naposledy logováno: 16:59:55

Error getting spin down delay for parity disk: 1 is not a valid SpinDownDelay. Using default.

From error above I'm not sure which server it's, at one server is Default spindown delay set to Never (because there are only SSD drives) and at second I have set as Default delay one hour.

Logger: custom_components.unraid.diagnostics.disk
Zdroj: custom_components/unraid/diagnostics/disk.py:95
integrace: UNRAID ([dokumentace](https://github.com/domalab/ha-unraid/wiki), [problémy](https://github.com/domalab/ha-unraid/issues))
První výskyt: 16:59:55 (10 výskyty)
Naposledy logováno: 16:59:55

Error getting spin down delay for disk5: 1 is not a valid SpinDownDelay. Using default Never.
Error getting spin down delay for disk6: 1 is not a valid SpinDownDelay. Using default Never.
Error getting spin down delay for disk7: 1 is not a valid SpinDownDelay. Using default Never.
Error getting spin down delay for disk8: 1 is not a valid SpinDownDelay. Using default Never.
Error getting spin down delay for disk9: 1 is not a valid SpinDownDelay. Using default Never.

Error above is surely from second server where is Default spindow set to one hour.

Logger: custom_components.unraid.diagnostics.pool
Zdroj: custom_components/unraid/diagnostics/pool.py:96
integrace: UNRAID ([dokumentace](https://github.com/domalab/ha-unraid/wiki), [problémy](https://github.com/domalab/ha-unraid/issues))
První výskyt: 16:59:55 (1 výskyty)
Naposledy logováno: 16:59:55

Error getting spin down delay for pool cache: 1 is not a valid SpinDownDelay. Using default Never.

Error above, again as in first case, I`m not sure which server, one have one hour default spindown and second never.

Logger: custom_components.unraid.binary_sensor
Zdroj: custom_components/unraid/binary_sensor.py:160
integrace: UNRAID (dokumentace, problémy)
První výskyt: 16:59:55 (1 výskyty)
Naposledy logováno: 16:59:55

Skipping invalid pool disk temp: Invalid pool name: temp

Error above it's pool disk with name "temp".

This behavior start from update of integration to version 2024.12.28.

Expected behavior

Screenshots

Unraid (please complete the following information):

Versions 6.12.13 and 6.2.14

Home Assistant (please complete the following information):

Version 2024.12.5

Home Assistant installation type (please complete the following information):

Docker / Container
Virtual Machine
Raspberry Pi

Priority of Request

High
Medium
Low

Additional context

The text was updated successfully, but these errors were encountered:

domalab · 2024-12-29T20:08:51Z

Would you mind sharing your unraid server configurations like what disks are you using in your array (HDD/SSD)?
Are they SATA or SCSI disks?
Do you have Parity disks configured?

Are you using Pool Devices? SSD/NVME?

Which disks have spin down delay configured? HDD or SSD

Enabled Debug Logging and reload integration and then view logs for errors or warnings. Search for Unraid and share the output if you can

ond000 · 2024-12-30T19:23:40Z

Ok, so my Unraid configuration.

As I found from debug logs all error are only from one server (Ok-usstr in logs):

in Array I have 2 parity HDD (one is currently disconnected) and 10 data HDD (one is currently in rebuild state), all disks in array are SATA, for that drives spin down delay is set to Default and Default configuration is 1 hour
in Pool devices I have two NVME drives, one for cache and second is my custom pool device named "temp", that drives have set spin down delay to Never

Attached log from debug logging:
home-assistant_unraid_2024-12-30T19-19-25.942Z.log

ond000 · 2025-01-02T17:00:46Z

Regarding that SpinDownDelay error, I did some investigation, and problem is in file const.py in class SpinDownDelay, issue is in definition of HOURS_* values, Unraid for hour spindown don't use definition in minutes, like for MINUTES_* values, but in hours.

I fount it in disks.cfg:

# Generated settings:
startArray="yes"
spindownDelay="1"
queueDepth="auto"
spinupGroups="yes"
defaultFsType="xfs"
shutdownTimeout="90"
luksKeyfile="/root/keyfile"
poll_attributes="1800"
nr_requests="Auto"
md_scheduler="auto"
md_num_stripes="1280"
md_queue_limit="80"
md_sync_limit="5"
md_write_method="auto"

Value spindownDelay is set to 1 , and I have set default value of spindown in Unrad settings to 1 hour (if I set that configuration to 15 minutes, value is 15, but for one hour it's 1)

So when I changed line 78 in const.py from:

HOUR_1 = 60

to

HOUR_1 = 1

And error in HA log disappear.

So probably will be needed to change all hour values in that files from definition in minutes to definition in hours 😊 This is little mess from Unraid, I'm wondering why they define one value partially in minutes and partially in hours...

ond000 · 2025-01-02T17:42:32Z

same for disks.ini

15 minutes:

["disk1"]
idx="1"
name="disk1"
device="sdc"
id="ST3000DM007-1WY10G_ZFN1N2C2"
transport="ata"
size="2930266532"
status="DISK_OK"
format="GPT: 4KiB-aligned"
rotational="1"
discard="0"
removable="0"
spundown="0"
temp="31"
numReads="748559918"
numWrites="1218275"
numErrors="0"
type="Data"
color="green-on"
spindownDelay="15"
spinupGroup=""
idSb="ST3000DM007-1WY10G_ZFN1N2C2"
sizeSb="2930266532"
deviceSb="md1p1"
luksState="0"
comment=""
exportable="no"
fsType="xfs"
fsStatus="Mounted"
fsColor="green-on"
fsSize="2928835740"
fsFree="494657100"
fsUsed="2434178640"
autotrim="off"
compression="off"
warning=""
critical=""
fsProfile=""
fsWidth="0"
fsGroups="0"
missing="0"

1 hour:

["disk1"]
idx="1"
name="disk1"
device="sdc"
id="ST3000DM007-1WY10G_ZFN1N2C2"
transport="ata"
size="2930266532"
status="DISK_OK"
format="GPT: 4KiB-aligned"
rotational="1"
discard="0"
removable="0"
spundown="0"
temp="31"
numReads="748559918"
numWrites="1218275"
numErrors="0"
type="Data"
color="green-on"
spindownDelay="1"
spinupGroup=""
idSb="ST3000DM007-1WY10G_ZFN1N2C2"
sizeSb="2930266532"
deviceSb="md1p1"
luksState="0"
comment=""
exportable="no"
fsType="xfs"
fsStatus="Mounted"
fsColor="green-on"
fsSize="2928835740"
fsFree="494657100"
fsUsed="2434178640"
autotrim="off"
compression="off"
warning=""
critical=""
fsProfile=""
fsWidth="0"
fsGroups="0"
missing="0"

ond000 · 2025-01-02T17:52:30Z

Regarding that issue with pool name "temp" I found this in code:

File pool.py from row 38.

        # Skip system paths and known special names
        invalid_names = {"parity", "flash", "boot", "temp", "user"}
        if disk_name.lower() in invalid_names:
            raise ValueError(f"Invalid pool name: {disk_name}")

So for this issue is problem caused by my naming of pool devices, I'm not sure if Unraid use somewhere else device name "temp" so I'll probably change that pool device name...

fix for issue domalab#37 from original repository (regarding SpinDownDelay issue)

Fix for issue #37 regarding SpinDownDelay error from HA logs

domalab · 2025-01-02T21:33:21Z

@ond000 Thanks for helping out and casting your eyes over the code. Appreciate it.

domalab · 2025-01-02T21:35:38Z

Regarding that issue with pool name "temp" I found this in code:

File pool.py from row 38.
        # Skip system paths and known special names
        invalid_names = {"parity", "flash", "boot", "temp", "user"}
        if disk_name.lower() in invalid_names:
            raise ValueError(f"Invalid pool name: {disk_name}")
So for this issue is problem caused by my naming of pool devices, I'm not sure if Unraid use somewhere else device name "temp" so I'll probably change that pool device name...

I modified the code to exclude temp but haven't uploaded the changes yet. Will do it later

domalab · 2025-01-03T02:48:50Z

Regarding that issue with pool name "temp" I found this in code:

File pool.py from row 38.
        # Skip system paths and known special names
        invalid_names = {"parity", "flash", "boot", "temp", "user"}
        if disk_name.lower() in invalid_names:
            raise ValueError(f"Invalid pool name: {disk_name}")
So for this issue is problem caused by my naming of pool devices, I'm not sure if Unraid use somewhere else device name "temp" so I'll probably change that pool device name...

I have excluded the name temp for pool devices.

Feel free to download the latest source code and test it in your environment.

ond000 · 2025-01-03T10:09:58Z

Thanks for that, it helps, error regarding pool device name temp disappear.

ond000 added the bug Something isn't working label Dec 29, 2024

ond000 added a commit to ond000/ha-unraid-fix-fork that referenced this issue Jan 2, 2025

Update const.py

b6ebf81

fix for issue domalab#37 from original repository (regarding SpinDownDelay issue)

This was referenced Jan 2, 2025

Update const.py ond000/ha-unraid-fix-fork#1

Merged

Fix for issue #37 regarding SpinDownDelay error from HA logs #47

Merged

domalab added a commit that referenced this issue Jan 2, 2025

Merge pull request #47 from ond000/main

b128899

Fix for issue #37 regarding SpinDownDelay error from HA logs

domalab closed this as completed Jan 6, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Errors in HA logs regarding disks #37

Errors in HA logs regarding disks #37

ond000 commented Dec 29, 2024 •

edited

Loading

domalab commented Dec 29, 2024

ond000 commented Dec 30, 2024 •

edited

Loading

ond000 commented Jan 2, 2025

ond000 commented Jan 2, 2025

ond000 commented Jan 2, 2025

domalab commented Jan 2, 2025

domalab commented Jan 2, 2025

domalab commented Jan 3, 2025

ond000 commented Jan 3, 2025

Errors in HA logs regarding disks #37

Errors in HA logs regarding disks #37

Comments

ond000 commented Dec 29, 2024 • edited Loading

domalab commented Dec 29, 2024

ond000 commented Dec 30, 2024 • edited Loading

ond000 commented Jan 2, 2025

ond000 commented Jan 2, 2025

ond000 commented Jan 2, 2025

domalab commented Jan 2, 2025

domalab commented Jan 2, 2025

domalab commented Jan 3, 2025

ond000 commented Jan 3, 2025

ond000 commented Dec 29, 2024 •

edited

Loading

ond000 commented Dec 30, 2024 •

edited

Loading