mftovey

My SSD is Silicon Power and I am having some doubts about them. I think I will look around for some better options. It took me a while to work out how to make that work. The "Warning disk temperature threshold" field was initially greyed out and uneditable on my system. I finally found out about smart-one.cfg, but it had not changed on my system since 2021 and it had only three disks in it (my system has six) and two of those were swapped out long ago. I finally found out that the format of the file had changed a few years back, but somehow it did not get updated on my system at that time. I created a new file, manually added the disks to it, then added 'hotTemp = "49"' to the SDD entry. That translates to "120" in the GUI, and that somehow translates to a cool/warm threshold of 106 in parity.check.tuning.php. That is greater than the "104" that the SDD is always displaying and so now the parity check can run to completion (with cool down pauses). After deeper analysis of the code, I see that this piece of the code does nothing to the functionality of the parity check. It just spits out a warning message and then breaks out. So waiting a little longer might reduce the number of messages that are output but nothing more. So, I have a working solution. My next task will be to figure out how to get better cooling for the drives. Thanks for your help! -Mark

So, I have a new problem to look into. I recently upgraded my disk controller to SAS to try to get better throughput to the disk drives. That worked very well. However, I was unable to perform a parity check after that due to the increased duty cycle on the drives caused them to overheat during parity checks, and that caused the parity check to pause. No problem, you say, because the parity check should automatically resume after the drives cooled down. But it didn't. After 30 minutes, the parity check would stop because the drives had not all cooled down sufficiently to allow the parity check to automatically resume, and manually resuming the check was required to get it going again. So I reasoned that I just needed to have it wait for a longer time before requiring a manual resume, but I could not locate any such parameter in the GUI. I dug through the parity.check.tuning.php code and found that there is a parameter in the configuration that would allow me to change the wait time: "parityTuningHeatTooLong". It just isn't available in the GUI. I moved it up to 45 minutes, then 60, and finally 90 minutes, but still I could not get it to automatically resume, even though the drives were all cooled down. Except for one. That drive is a SSD, and it always displays a temperature of 104 F. Always. I dug through the parity.check.tuning.php code some more and found that in order to automatically resume the parity check, ALL drives must be in a cool state, and a disk in a warm state will prevent automatic resume. 104 F is considered warm for that drive, and so no automatic resume. Now I do not know why that drive always shows 104 F. It is the first and only SSD I have ever used and I do not know if this is normal for SSDs or if there is a problem with temperature monitoring on this one drive, but regardless that is preventing automatic resume. I commented out the section of code in parity.check.tuning.php that looks for warm drives, and after that I can now get a parity check to run to completion (with cooling pauses) without having to constantly resume the check. However, I am not comfortable with leaving this code commented out. It is there for a reason and I agree with it. But at the moment, this is the only way I can get through a parity check. So does anyone have any thoughts on this? Do I just have a defective drive that does not properly report its temperature, or is this going to be a continual issue? -Mark

As a matter of fact, there are. I am using an old Lenovo S20 tower and it does have card reader slots built into it. I never used them and so I never paid any attention to them. The physical labels on the slots match what appears in the unRAID screen, so that verifies the source of the displayed information. But these only started to appear just recently, and they appeared one at a time with a long delay between each one showing up (days, weeks?). Perhaps the last update to UD caused these to start appearing? But why the delay between each line appearing? If that is all it is, I can live with them being displayed. I was just uncomfortable with not knowing what this was about. Thanks for solving the mystery. Mark

Actually, all USB ports are empty except for the one that holds the unRAID jump drive. There is no card reader attached. This started out displaying only one of these Generic drives, then a second one appeared, later the third appeared, and now there are four. I suspect these are artifacts left over from attaching and removing a jump drive, There must be a way of removing them from memory but I can't find a way yet.

I see several disk devices with names similar to "Generic-_SD_MMC_20060413092100000-0:2" (see image below) in Unassigned Devices. The "MOUNT" button is greyed out so I am unable to do anything with them. I believe that they may be related with attaching and removing USB devices. I have rebooted unRAID several times, but that does not seem to help. I even tried uninstalling and reinstalling UD, but the devices always reappear. Can anyone explain to me what they are and how to remove them? I am running unRAID 6.12.8. Thanks, -Mark