Hoopster

Yes, this is correct. For permanently attached storage, cache pools are easier to deal with than Unassigned Devices and provide more flexibility. UD still has several good uses especially with USB and other storage that is not always connected to the server. If you are looking for speed, of course SSDs are better than HDDs as cache devices. A cache "pool" can be a single device or multiple devices. You can assign your HDD as a cache device and designate share(s) as cache only or cache prefer using this HDD cache "pool." The only difference is what happens when the cache drive is full. Prefer causes data to spill over to the array; cache only does not. Nothing on this cache drive would be parity protected and therefore would write to the HDD at the speed of the drive.

You may also want to setup a syslog server mirrored temporarily to your flash drive. That way everything written to the syslog is captured even across reboots.

That will not necessarily solve any issues. What you should do is post your server diagnostics (Tools- --> Diagnostics in the GUI). Otherwise all anybody can do is guess what the problem may be.

That drive is also CMR. The DM004 model is SMR. There could be some other issue with the drives, but SMR is not at the root of the problem.

This article indicates the HUS726T6TALE6L4 model is CMR/PMR and is not SMR.

Does the PC from which you are trying to flash the card have a UEFI motherboard? If so, you need to follow the procedures at the bottom of those instructions about flashing from the UEFI shell. I flashed my H310 from a PC with an older motherboard so everything worked in BIOS/DOS. Sometimes you can get out of the UEFI shell and to a DOS prompt by just typing "exit" from the shell prompt. I am not sure if that is possible in your case.

Now that you have eliminated potentially problematic plugins, you can try upgrading to 6.9.2 again. First backup your flash drive. As you know, there are two ways to upgrade; 1. Tools --> Upgrade OS (the automated way) in the GUI or 2. download the latest version from unraid.net, unzip the files and copy all the bz* files to your flash drive (the manual method). I don't know if it was ever fully determined what caused all your problems after the first upgrade attempt but the old unraid-Nvidia plugin still being installed would have caused some issues. It also appears that some things got messed up on your flash drive. Hopefully, the path to 6.9.x will be smoother this time.

Oops! Here you go.

You need the new Nvidia driver plugin to do this with unRAID 6.9.x.

@thejellydude The 3.3v problem to which Frank1940 refers is very often an issue with drives shucked form external enclosures. They work fine when used in many disk cages that are powered by Molex, Molex to SATA power adapters, etc. When direct connected to SATA power, they go into a reset state and are not recognized in the BIOS or by unRAID. If your drives are shucked, this could be an issue. If they were sold as bare or OEM desktop of server drives, this is usually not a problem. However, even in those cases, some drives could still have the issue even if they were not shucked drives. It depends on the drive model. The solution is to cover pin 3 of the drive SATA connector with Kapton tape. I have needed to do this on a couple of shucked drives.

Here is one guide: https://tylermade.net/2017/06/27/how-to-crossflash-perc-h310-to-it-mode-lsi-9211-8i-firmware-hba-for-freenas-unraid/ Here is another: https://techmattr.wordpress.com/2016/04/11/updated-sas-hba-crossflashing-or-flashing-to-it-mode-dell-perc-h200-and-h310/ And here is a reddit thread from someone who tried both tutorials and ran into a problems which were solved with the help of others: https://techmattr.wordpress.com/2016/04/11/updated-sas-hba-crossflashing-or-flashing-to-it-mode-dell-perc-h200-and-h310/ There are many threads about cross-flashing a RAID controller to IT mode in the unRAID forums. Here is a very long one on the subject:

OK. When other issues are resolved, you really should consider cross-flashing that H310 with IT firmware version 20.0.7.0 (the latest). It will make your life a lot easier.

Correct. Should not affect drives attached directly to the motherboard. However, if they do not show up in the motherboard BIOS/UEFI, they will not show up in unRAID. Go into your BIOS and see if the drives show up there.

Has your Dell H310 always been in RAID mode? If so, the only way to get drives to show up with the Megaraid driver is if each drive is configured as a separate RAID 0 or in JBOD mode if that is supported. Drives attached to a controller in RAID mode do not generally show up in unRAID. Megaraid driver and unRAID is usually a problematic combination. This is your controller (note it is using the MegaRAID driver): 01:00.0 RAID bus controller [0104]: Broadcom / LSI MegaRAID SAS 2008 [Falcon] [1000:0073] (rev 03) Subsystem: Dell PERC H310 [1028:1f78] Kernel driver in use: megaraid_sas Kernel modules: megaraid_sas Whatever mode your card is in, loading the MegaRAID driver only shows one drive recognized: ASBOX kernel: megaraid_sas 0000:01:00.0: pci id : (0x1000)/(0x0073)/(0x1028)/(0x1f78) Apr 8 14:33:25 NASBOX kernel: megaraid_sas 0000:01:00.0: unevenspan support : no Apr 8 14:33:25 NASBOX kernel: megaraid_sas 0000:01:00.0: firmware crash dump : no Apr 8 14:33:25 NASBOX kernel: megaraid_sas 0000:01:00.0: JBOD sequence map : disabled Apr 8 14:33:25 NASBOX kernel: scsi host1: Avago SAS based MegaRAID driver Apr 8 14:33:25 NASBOX kernel: i2c i2c-0: Successfully instantiated SPD at 0x50 Apr 8 14:33:25 NASBOX kernel: RAPL PMU: hw unit of domain package 2^-14 Joules Apr 8 14:33:25 NASBOX kernel: RAPL PMU: hw unit of domain dram 2^-14 Joules Apr 8 14:33:25 NASBOX kernel: RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules Apr 8 14:33:25 NASBOX kernel: scsi 1:0:7:0: Direct-Access ATA WDC WD80EFAX-68L 0A83 PQ: 0 ANSI: 5 I happen to have the same card in my server but I have it cross-flashed to IT mode where it becomes a pure HBA (no RAID support) that passes through each disk to unRAID without issues. Note that in IT mode is is loading the mpt3sas driver. For the record, I am also running the latest version of unRAID; 6.9.2 Here are my controller details also for a Dell H310: 02:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03) DeviceName: Onboard SAS Subsystem: Dell 6Gbps SAS HBA Adapter [1028:1f1c] Kernel driver in use: mpt3sas Kernel modules: mpt3sas Upgrading unRAID should have had no effect upon the firmware on your Dell H310, but, it is possible that Linux kernel changes between versions have affected how the driver behaves.

For support on the Plexinc Docker container, you need to post your questions in the Plex forums. That container is not supported by anyone in these forums. Although the Plex Media Server itself is the same regardless of which container is used, only the container author or those experienced with it can address container issues. Unless someone in these forums has the same container and the same issue, you may not get any responses here.

Well, there you go. Having no SAS drives, I did not even know that existed. 😁

Disk 10 is a SAS drive. All your other HDDs are SATA drives. Until recently, there were issues in unRAID with spinning down SAS drives. Limetech made some changes that were supposed to resolve this in unRAID 6.9.0 but those changes introduced some other issues which were fixed in 6.9.1. It is possible that in all this back and forth, there are again issues with SAS drives. All of my drives are SATA so I cannot test it. Perhaps you should first try the newly released version 6.9.2 and if the problem is still there, create a bug report about your SAS drive not spinning down.

This card has a MegaRaid LSI chip which cannot be flashed with IT mode firmware. It is not a good choice for unRAID. The card in the 2nd link will work well. Are you planning to connect SATA drives directly to the controller? If so, you need an SFF-8087 to 4 SATA forward breakout cable like this one. Make sure you get a forward breakout cable and not reverse. The direction matters. To connect 8 drives to the second controller listed, you would need two cables.

What do you mean by networked storage? The unRAID array? An Unassigned Devices (UD) location? Beginning with unRAID 6.9.0, multiple cache pools are supported. Whereas with prior versions it might have been desirable to have appdata on UD, those devices can now be designated as a cache pool (a pool can be just one drive). Each share can have a different cache pool assigned to it or multiple shares can use the same cache pool (or none at all). You can still designate an array drive or drives for appdata if you want it there, but an SSD is a much better choice. There is still a "hack" way of getting appdata on an Unassigned Device but multiple cache pools is the preferred way.

Nope. I have 7 helium filled drives in two servers and they all spin down just fine. The fact that it is helium filled and others that spin down are not is likely coincidental. You should post your diagnostics (Tools --> Diagnostics). There is likely something else that is keeping the drive active.

Safe mode starts unRAID without loading any plugins. The fact that you can boot in safe mode is a pretty good indication that a plugin is causing the problem. In the GUI, of course you just go to the Plugins screen, select the checkbox next to the plugin and click the Remove button. If that is not available in Safe Mode or you can't get to the GUI you can put the flash drive back in your Windows PC and: delete the appropriate .plg from /config/plugins and reboot.

Because the bug in unRAID was that changes to smartctl made it so drives would not spin down when smartctl is called as it is in the telegraf.conf file. Telegraf is an integral part of the UUD setup. If you disable UUD, you remove Telegraf and its calls to smrtctrl so you no longer see the problem. Alternatively, you could keep UUD active and just comment out this line in telegraf.conf. [[inputs.smart]] # ## Optionally specify the path to the smartctl executable path = "/usr/sbin/smartctl" However, as far as I know, that issue was fixed in unRAID 6.9.1? Perhaps someone else can confirm this.

Probably because Marvell based controllers have not been recommended for at least 2 years and in a lot of cases there was no solution that made them work. The only possible solution a few years ago was to modify the bzroot line in syslinux.cfg to this: append iommu=pt initrd=/bzroot

Updated to 6.9.2 easily with no issue so far. A couple of posts were made earlier about 6.9.2 containing a kernel patch which would potentially address the macvlan/broadcast call traces on br0 networks when docker containers are assigned a specific IP address. Creating a VLAN for docker containers solved the problem for me three years ago when I first came across the problem. I am curious to know what patch that is and what it addresses to resolve the problem (assuming it has been solved).

Marvell controllers have not been recommended with UnRAID 6 for quite some time. Recent Linux kernels and Marvell drivers are a problematic combination, especially if you have virtualization enabled in the CPU. Some can get them to work with kernel boot parameters or with virtualization disabled, but even if the controller/disks are recognized in UnRAID, they could randomly drop out at any time. Sorry, I am on mobile and cannot provide more information but a search of these forums for Marvell controller problems should yield some Info. Certain controllers with LSI, ASmedia or JMicron chips are the recommended controllers. Sent from my iPhone using Tapatalk