doron

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

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

Folks, I have just posted a new version (0.86) of the plugin. This version works around an issue introduced with Unraid 6.10-rc1, where some SAS drives would spin back up immediately after being spun down. Other drives (including all of mine...) do not exhibit this behavior. Turns out those drives suddenly became sensitive to a specific "sdparm" query call (get VPD), which should not (and did not in the past) affect the drive's spin status in any way. Chances are this is a result of newer drivers bundled with the Unraid OS. At any rate, the SAS drive detection logic of the plugin was rewritten in order to work around that phenomena. Enjoy. Please let me know of any issues or funny stuff.

One thing for sure - do not hold your breath waiting for 6.9.3 🙂 (The next stable version is going to be 6.10.0.) More seriously: Did the spindown work for your SAS drives on 6.9.1? Can you attach a snippet of your syslog at the time of the expected spindown?

Hi @StevenD, any plans to produce a 6.10.0-rc1 compatible version? Thanks so much!

Thanks @ich777! (I looked at the wrong repository "waiting" for the update...)

Hi @ich777, any plans to make a 6.10.0-rc1 kernel compatible version of the plugin / drivers? Thanks so much for all your work!

The Nerdpack plugin code has an issue with Unraid versions with a minor version number higher than 9. It parses the version string wrongly. Version 6.10 triggers this issue 😞 I opened an issue on Github several days ago, here (did not submit a pull req so far).

Oops - missed Simon's post... 🤦‍♂️

You guys do mean 27/28 not 37/38 I presume.

ijqk kfwt dvya ugcv qmlr

What Simon said. Basically, as of 6.9.2, some SAS drives (mainly Seagates) and also some SATA drives have an issue with spindown. Essentially they appear to spin down but then immediately spin back up. Not sure yet re the source of this issue, might be kernel/driver related, probably not related to the plugin (as (a) it happens with SATA drives as well and (b) some SAS drives spin down and up perfectly under 6.9.2).

jefcpdcavmmqn.

Hi, thanks for posting. Sure, they're generally decent drives. But you will probably need to live with them spinning 24x7 😞 Basically, there's conflicting data as to their behavior. I started with excluding them, then started a mini-project of collecting data points from users. Since I did receive a couple of positive data points for these drives, I commented the exclusion out, "for now". My controller is based on the same chip. I use HGST drives. They spin down/up without a hitch. So it could be a combination of the controller/HDDs, or just the latter. I tend to believe it's the latter (the HDDs), but the jury's still out. At any rate, these drives have given much more thumbs-down data points than thumbs up. As I said I started collecting this data. Whatever seemed conclusive is in the exclusions file. Perhaps compiling it to a list of "what works" may indeed be a good idea, time permitting. Not as far as I'm aware, but that's up to Limetech to answer authoritatively.

Either the BP will not physically accept SAS drives to begin with (as noted by @JorgeB above) due to the connectors being SATA only, or the controller will see a SAS drive(*). Neither the cables nor the BP will change the protocol spoken by the drive from SAS (essentially, SCSI) to SATA (essentially, ATA). (*) In some cases, speed might be negotiated down (e.g. 6Gb/s SAS instead of 12Gb/s SAS).

Yes, it does. That's why you would opt for New Config - which will have Unraid see the new IDs. The important thing is that the data on the drives, as seen by Unraid, will be bit-identical, and with the presumption above holding, it should be. And of course, you'd need to make very sure the drives maintain their Unraid slots - Or Else 🙂

I'm not overly familiar with Proxmox specifically, but assuming its HDD passthrough passes the entire physical drive to the VM, you should be fine with the process you described (also check the "parity is valid" checkbox). If the drive seen by Unraid is block/sector-wise identical to what it was seeing previously, this should work. The remaining question would be whether you would actually be able to pass the SATA controller. Not all on-board controllers can be passed through; this would be mobo-dependent. But you'll figure that one out pretty quickly 🙂