doron

Your unassigned drives will probably find themselves listed in /var/local/emhttp/devs.ini in a similar manner. Good luck!

If you can parse /var/local/emhttp/disks.ini you should be on the right track.

Understood. Thanks for all your good work on this.

Any news re this?

If I understand your question correctly, I'd probably try -- Resize the RAID6 array on OMV to ~30TB (need to resize the fs or lv etc. and then the array itself via mdadm - perhaps OMV provides a nice UI for that?) Take 3 of the drives released from the md array plus the spare and build an Unraid array with 1 parity and 3 data drives. Copy the data. Once you're happy with the state of your Unraid server and data, dismiss the OMV system and add the rest of the drives to Unraid. If you specifically want to use 2+1 drives, then you can create an Unraid array with no parity and perform the copy. The downside is, of course, that without a parity drive, your data is not protected.

As I assume you know, the plugin handles SAS drives. I see that some of your drives are SAS and some are SATA. Can you indicate which of your drives you are having an issue with?

Thanks! Turns out things messed up further with all the back and forth and now I can't get the HD channels on either the PCI or the USB tuners. I'm beginning to suspect something is going on with the DVB-T2 provider(!). They have a reputation of malfunctions... will keep working on that.

Hi @alturismo, thanks for responding! The tvheadend log shows nothing... Two standard messages: "tuning on TurboSight TBS 6281SE DVB-T/T2/C #1..." and "HTTP subscribing on channel...", and then it sort-of works but low traffic and no A/V rendered.

I'm trying to figure out an issue, and I thought the cumulative wisdom on this thread may point me at the right direction. Basic issue is: Can't get DVB-T2 streams from a TBS6281SE card with the TBS-OS drivers. Detailed description: I have a DVB-T/T2 USB dongle. I used it with the libreelec driver package of this plugin. Works well, receives both DVB-T and DVB-T2 streams (I need both). Decided to swap it for a PCIe tuner card (stability, etc.), got a TBS6281SE (dual tuner, based on Si2168/57). The libreelec driver package does not seem to support the card, so I moved to the TBS OS. Card recognized, drivers loaded, so far so good(*). I have a tvheadend setup to use the DVB adapters. Using the exact same network/mux/channel setup that works successfully on the USB dongle, I can properly get all the DVB-T streams (SD), but no DVB-T2 (HD) stream. When I try to start a DVB-T2 stream, the tuner seems to accept the tuning just fine, and start "streaming". However, no audio/video is rendered by the client (vlc, or emby, or tvhclient). When I look at the tvh status/stream page, I can see that the input bandwidth reported is extremely low (for comparison, if the proper DVB-T2 stream that I'm looking for reports a bw of ~5000-7000, here I see it dwindling around ~150). Has anyone seen something like that? Is there maybe a setting that affects the TBS6281SE that I may be missing? Could the driver or fw be at fault? Asking another way - do people with TBS8261SE manage to get DVB-T2 streams (as opposed to DVB-T) from this card? Is the libreelec driver package supposed to work with this card? Lotsa questions. Thanks in advance for any insight/pointer/advice. (*) Incidentally and unrelated, with the TBS OS package, the USB dongle is only partially recognized - the Realtek chip is recognized and comes up, the Sony chips are not.

Right. If in fact the issue is as I guessed above, this exercise should go without issues - as the SAS drive(s) will simply not spin down, hence not invoking this phenomena (unable to automatically wake up from a spin down). Let's discuss this for a moment. The adapter you pointed at is a physical connector adapter; it can connect a SAS drive to SAS-capable(!!) ports having SATA form factor, such as those found e.g. on some Supermicro motherboards. Those ports are not SATA ports; they are SAS ports (in fact, SAS-SATA ports, because they can "speak" SATA protocol as well). No adapter can connect a SAS drive to a SATA-only port. Now, I have been assuming that you use this adapter to connect your SAS drive to a SAS controller that has SATA-style ports. Can you re-confirm that this is indeed the case. Assuming we are indeed talking about SAS ports, you can (a) Stop the array (so as not to cause yet another parity panic) (b) Identify the SAS drive. Let's assume it's /dev/sdX (c) Issue these commands from a command line: sdparm -C sense /dev/sdX sg_start -rp3 /dev/sdX sleep 2 # just in case you are copy/pasting the entire sequence sdparm -C sense /dev/sdX dd if=/dev/sdX of=/dev/null bs=1M count=1 sdparm -C sense /dev/sdX # In case the above command(s) hang,... sg_start -rp1 /dev/sdX sdparm -C sense /dev/sdX Paste the results, and the accompanying syslog lines. If there's anything except smooth run of these commands, suggest you reboot before restarting the array.

You're right. If spinning down your /dev/sdd would trigger a similar issue again, then we'd have to conclude that your drive model - HUS72403CLAR3000 - is one of those which do not properly support the STANDBY command, and, sadly, it will need to be added to the list of "excluded" drive models in the plugin. Net-net it would mean that the plugin will not be of value to you. If you want, you can test for this issue, when the array is quiesced so as not to trigger another parity check. Let me know if you want to try that.

That's fine, it's just that I saw v0.85 in your logs and wanted to point you to the latest update. Either with latest or without the plugin is fine 🙂 What do you mean by "SAS to SATA"? Is this a physical adapter? Can you perhaps point to a similar product page? At any rate, the next thing I'd check, in parallel with this thread, is the cabling of the drives - SAS and SATA - start with sdd and sdk but would probably go over all of them, just to be safe.

@Necron, please (a) upgrade the SAS Spindown plugin to latest version (b) post diagnostics © share a bit more about the setup - which drives are connected to what controller, what exactly are you passing through to your VM etc. I suspect this doesn't have much to do with the plugin, but let's take a closer look. Sent from my FP3 using Tapatalk

Thanks. Nope, not SAS protocol (admittedly it'd have been weird if it were). So SAS Spindown plugin won't help. Still, does: sg_start -rp3 /dev/sdf sdparm -C sense /dev/sdf Do anything helpful?

Yes, seems like this controller may be presenting SATA drives as SAS protocol. @chris0583, please paste the result of the sdparm command I mentioned above, which will determine it clearly: sdparm -ip di_target /dev/sdf

Wait. What?!? Not what I'd expect. Please paste output of: sdparm -ip di_target /dev/sdf

Sorry for the previous misfire, too many sub-threads in here. Yes, it seems like we have narrowed this issue down to SATA drives on SAS controllers (as opposed to onboard native SATA ports). That's interesting, I'm not sure we've seen this (bad/missing sense) with "hdparm -y" before. This might be an indicator for @limetech. Is there anything extra in the syslog at the time you issue the "hdparm -y"?

I assume you have the SAS Spindown plugin installed. Have you updated to version 0.86? Scratch that; your drives are SATA, so the above doesn't apply. Seems like you're hitting the core problem of 6.9.2/6.10.0 with Seagate drives.

That's standard behavior of the UI (when you spin down a drive using CLI, the UI doesn't immediately "notice" as it's not aware this was done under the hood). The fact that you keep getting a "2" or "standby" with these commands basically means that your drive is indeed spun down. I would guess that if, instead of using these CLI commands, you'd spin the disk down from the UI by clicking the green button, it will turn grey.

Your drives are SATA. The SAS Spindown plugin will not do anything for you, unfortunately (will do no harm either) - it deals exclusively with SAS drives. I'm assuming the screenshots you attached are from a 6.10.0-rc1 system? Please correct me if I'm wrong, this is an important data point. If the assumption above is correct, then (a) This seems to be the exact same issue that started at 6.9.2; apparently it remains in 6.10.0-rc1 (b) Apparently this does not have to do with the mpt2sas module (its version in 6.9.1 and 6.9.2 is the same, while in 6.10.0-rc1 there's a newer version. Problem did not exist in 6.9.1). (c) Need to look for another change that happened between kernels 5.10.21 and 5.10.28. Meanwhile, would you mind selecting one of the drives that does not have any activity against it, and on an Unraid command shell, issue these commands (replace /dev/sdX with the drive you selected): hdparm -y /dev/sdX hdparm -C /dev/sdX sleep 1 hdparm -C /dev/sdX (yes, the last two hdparm commands are identical) and post the output?

What drives do you have (those that are not spinning down)? When you look at the log, are you seeing "spinning down" and immediately thereafter "read SMART" for these drives?

Thanks. Okay, this looks a bit different from the issue that was reported by others (aka the wild goose 🙂 ). Generally speaking, your drives seem to spin back up "a while" after being spun down, rather than "immediately". So while e.g. sdq spins up only 4 seconds after being put to sleep, sdm takes 7 minutes, sdp takes 3.5 minutes and sdi also sleep for 7 minutes before waking up. In this case, I'd look for real disk activity that's happening. Look at the i/o counters, check whether they increase when the disk spins back up, and figure out what activity is taking place. My current guess is that you have something going on that actually reads/writes to your array.

In the "problematic" server, do all of the drives demonstrate this phenomena? Both the Seagates and the WDCs? If you try to spin down one of the WDCs, do you also see a "spinning down" and an immediate "read SMART /dev/sdX" in syslog? Also: from the diag you posted (unless I'm mistaken) it appears as some of the drives on that server are connected via onboard SATA (e.g. sdb). Do these also demonstrate the same problem in the same way?

Just to be crystal clear: The server that demonstrates the issue is the one with the two 92xx controller(s), whereas the one that doesn't uses onboard SATA?

Do you see any messages on the Unraid syslog that may indicate issues with initializing the P420i, etc.?