dlandon

The disk is in a very funny state. It is not detected as mounted at '/mnt/disks', but '/dev/sdk' appears to be mounted. I think your best option at this point is a reboot.

Isn't the disk temperature going up that high? As I explained before, Unraid polls the disk temperature and will only alarm if the disk is high at that time it polls (every 30 seconds by default). It would have to hit in the 3 seconds time when it is high to cause an alarm. Three seconds out of 30 minutes is not a very high probablility that Unraid would hit it. A couple times a month explains that. You need to raise the temperature threshold.

Linux does not think the disk is mounted, so I don't quite get what is happening. One last request. Post a screen shot of the UD page. Is this a USB disk? Next response I'll have some ideas for you to solve this.

That would be a good granularity.

Post diagnostics so I can have a look. Normally that is from the situation I described to you. Also show me the output from the 'mount' command from the command line.

Uninstalling and re-installing UD doesn't do anything. I see users try this all the time and it never works to fix problems. Most likely what you've done is to try a copy when the disk wasn't mounted and you created a mount point folder. Get into a command line and do this command 'ls /mnt/disks/' and see if the '/mnt/disks/MN1240FA14K9LD' folder is there. If it is there, run this command 'rm -R /mnt/disks/MN1240FA14K9LD'. Then you should be able to mount the disk,

I've had my nvme disk set at 80 deg for a long time because I was also getting the warnings. This will be interesting to see. How often does netdata get the temperature?

OK. So that is a special case. In my case I have all those entries removed and use the /dev/dri for Plex and some other docker containers and it works fine. For this issue, we should stay with the generic situation like I use. Once we have that, we can move to the special cases.

Temperatures are polled by Unraid on an interval set by the 'Tunable (poll_attributes)' setting in Settings->Disk Settings. The default is 1800 seconds, or 30 minutes. Nvme disks being solid state can spike to a high temperature and depending on the when the poll hits, a high temperature could be detected that will go down quickly when the device is not heavily used. Because the update occurs at a 30 minute interval, you see the same temperature on the display for a half an hour. There are several things you can do depending on the result you'd like to see: Reduce the polling interval. Be careful with this because each poll interogates all the disks and there could be a performance hit. Increase the temperature thresholds above 84 degrees so you don't get the warning. Provide some cooling in the case so the nvme drive doesn't get so hot.

I'm not sure I understand. The i915 entry in modprobe.d will now blacklist the driver.

With the latest UD you can assign an alias disk name and use this command in your script to unmount the disk: /usr/local/sbin/rc.unassigned umount name=diskname Also, one of the things I do is to put some sounds in the script to let you know when a disk is mounted, unmounted, etc. Look at the first post of UD for some ideas. The sample script has some 'beep' commands that do that. You of course need a speaker in your server. EDIT: You should also do a file sysem check on that disk.

Ok. Here's the situation. You unplugged that disk before it was unmounted: ### Disk was removed before it was unmounted. Originally mounted as /dev/sde Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 771681, lost async page write Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 771682, lost async page write Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 771683, lost async page write Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 771684, lost async page write Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 809369, lost async page write Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 733102712, lost async page write Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 737636525, lost async page write Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 737636526, lost async page write Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 737636527, lost async page write Jan 10 01:00:30 Tower kernel: Buffer I/O error on dev sde2, logical block 737636528, lost async page write ### Disk was re-inserted and assigned to /dev/sdf Jan 21 08:21:30 Tower unassigned.devices: Successfully mounted 'sdf2' on '/mnt/disks/Unraid_Backup'. Jan 21 08:21:30 Tower unassigned.devices: Mount warning: The disk contains an unclean file system (0, 1). The file system wasn't safely closed on Windows. Fixing. . Because the device is now /dev/sdf, Unraid thinks it's still /dev/sde and does not assign it a 'devX' assignment. In this case UD assumes the disk dropped out of the array. The disk is not tagged as a USB device, so UD marks it as 'Array'. Bottom line, remove the disk and reboot. The disk is currently unmounted.

I need to see two files. Post the results of the following commands: cat /usr/local/emhttp/state/devs.ini cat /var/state/unassigned.devices/unassigned.devices.ini The second one will be fairly large. It would be best to zip them and post the zip file.

When rc3 is released do the following before rebooting: Remove any references to i915 from your go file. Remove any i915 files from the /flash/modprobe.d folder. The driver is loaded by Unraid without you having to do anything. I wanted to give you a heads up because you would probably upgrade before I could post here.

That is not supposed to happen on USB devices. Please post diagnostics and I will run a few tests to see if I can find out what's going on.

Thanks for letting me know. It was literally a two line fix of a rather simple problem once I found it.

Unfortunately, I have no information about the release of rc3.

This feature was just added a few releases ago. Unraid tracks serial numbers to know where a disk is installed. UD tracks serial numbers so you can attach certain settings and operations to a UD disk. This issue has nothing to do with tracking a serial number. UD requests Unraid through an API call to present a list of the disks Unraid does not have assigned to the array, or a pool. These are Unassigned Disks and Unraid assigns a 'devX' designation to the disk. Because of a bug, there are times when Unraid doesn't get the list of Unassigned Devices correct. The 'Array' designation has nothing to do with a partition being there or a file system on the partition. UD sees the disk and when Unraid does not assign a 'devX' designation, assumes the disk dropped from the array. This has happened to users with cabling and controller issues. If the disk is not marked 'Array' and the user tries to do anything with the disk, they risk losing data or invalidating parity. Neither of which is good.

I didn't think the refresh would do anything, but thought it would be worth a try. There isn't a previous version of UD to roll back to. Maybe you should consider planned maintenance during a quiet time so you can handle these situations. If you're running 24/7, you're running a data center operation. Unraid wasn't really meant for that.

Understood. Once 6.10rc3 is released, you can upgrade and this should not be a problem. You might try clicking on the double arrows in the upper right hand corner of the UD page. There's a slight chance that might fix it.

i'm thinking we could work on this again when rc3 is released.

The 'Array' indication on the 'Mount' button is from Unraid not assigning a 'devX' device to the disk. Notice the device shows as 'sdb' and not 'Dev X'. The idea behind this is to give you a heads up that the disk dropped out of the array. Unfortunately there is a bug that creates this situation in certain cases of the order when UD devices are hot plugged. It is fixed in 6.10rc3 (not yet released). There are several ways to fix this: Stop the array and then restart the array. The 'devX' designations will be reset. Reboot the array.

I've just released a fix for the disks not showing in UD and the blank device.

Yes, the help does provide a lot of information.

The best way to do this is to assign an alias disk name and add commands to your script to mount, unmount, and spin down the disk: # Mount a disk /usr/local/sbin/rc.unassigned mount name=diskname # Unmount a disk /usr/local/sbin/rc.unassigned umount name=diskname # Spindown a disk /usr/local/sbin/rc.unassigned spindown name=diskname