doron

Community Developer
  • Posts

    518
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by doron

  1. You are very welcome - thanks for reporting success.
  2. Do you see a "SAS Assist" message about spinning the drive down, and then immediately thereafter a message about reading SMART? There was an issue that started in 6.9.2 (vs. 6.9.1), where some drives are spinning down and immediately back up. It seems to be a kernel issue, I'm not sure it's been resolved yet. It was reported against both SAS and SATA drives.
  3. If you get the i/o errors mentioned above on an array drive, the drive will need a reboot to resume operation (the message is not a warning). So, no. Sent from my tracking device using Tapatalk
  4. Indeed, @madejackson and @francishefeng59, unfortunately some SAS drives (mostly reported with Seagates but with some others as well) do not respond as expected to the spin-down (aka STANDBY) command and require an explicit wake-up call, which is not really applicable in the Unraid realm (expected behavior: Spin up automatically upon next i/o). The result is typically an i/o error with sense 0x2 and ASC/ASCQ 0x4/0x11, recoverable only upon a reboot. I've made some attempts to map the bad actors (seems to be drive+controller related) and exclude them, but can't say it was an overwhelming success. So this is where we stand right now.
  5. Just installed and everything is looking perfect - thanks again @StevenD! This is awesome.
  6. The latter might be related to different work profiles (e.g. often-written files or folders on this sdg drive, etc.). To eliminate that I'd swap cables / ports with the other ones and see whether issue stays with dev (i.e. sdg) or with drive (i.e. S/N / Unraid slot).
  7. And nothing else has changed?
  8. It appears as though your drive misbehaves per the spin down process. "LU not ready, intervention required" means it is spun down and does not spin up automatically when an i/o is directed at it. This piece is kind of vaguely defined in the SAS protocols and different drive/ctrl/firmware combos provide different results. Your downgrading to p16 might have something to do with that.
  9. Your unassigned drives will probably find themselves listed in /var/local/emhttp/devs.ini in a similar manner. Good luck!
  10. If you can parse /var/local/emhttp/disks.ini you should be on the right track.
  11. Understood. Thanks for all your good work on this.
  12. 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.
  13. 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?
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. @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
  21. 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?
  22. 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
  23. Wait. What?!? Not what I'd expect. Please paste output of: sdparm -ip di_target /dev/sdf
  24. 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"?