doron

Community Developer
  • Content Count

    460
  • Joined

  • Last visited

  • Days Won

    3

doron last won the day on September 20 2020

doron had the most liked content!

Community Reputation

65 Good

2 Followers

About doron

  • Rank
    Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for reporting. Just to make sure you're seeing an instance of the recently reported 6.9.2 issue (you probably are; see above for more details): In your system log, do you see the "SAS Assist" spindown messages, immediately followed by a "Read SMART" message for same drive?
  2. I'd check the CMOS battery. From the manual of your mobo: Losing the System's Setup Configuration 1. Make sure that you are using a high-quality power supply. A poor-quality power supply may cause the system to lose the CMOS setup information. Refer to Chapter 2 for details on recommended power supplies. 2. The battery on your motherboard may be old. Check to verify that it still supplies ~3VDC. If it does not, replace it with a new one. 3. If the above steps do not fix the setup configuration problem, contact your vendor for repairs.
  3. @bonienlfyi - this is still the case - probably worth moving from "prereleases" to proper bug reports?
  4. It kind-of works (if you use with --no-verify, since gpg isn't available) but it will downgrade your db to 7.0 rather than upgrade to the latest... I guess it can be tweaked to do the right thing. Or, you can use the above.
  5. To update drivedb.h you can add something like this to your go script: wget https://raw.githubusercontent.com/smartmontools/smartmontools/master/smartmontools/drivedb.h -O /usr/share/smartmontools/drivedb.h This will install the latest smartmontools drive database. Whether it will cover a given drive is a different question 🙂
  6. Hang on. I may be missing something. Do you have SAS hard drives in your system? (or have you connected your SATA drives to the new LSI HBA - in which case, the plugin is not really applicable, although it has been known to help in some corner cases.) On a related note - which Unraid version are you running? If it's 6.9.2 (latest when writing this), there's an open issue on SATA drives not spinning down (or, actually, spinning back up immediately) in this particular version. Not applicable to any other version. The fact that you're not seeing anything in the log
  7. Definitely not the intended behavior... "Should" work with the Spindown timers. Can you elaborate on what you're seeing? - which SAS drives do you have? - what have you configured as Spindown times? - what do you see on syslog when the timer expires? (I presume you aren't seeing the green ball turning grey when the timer expires.)
  8. Thanks for going through the trouble! For some reason I deduced from your previous post that you're seeing the new issue happening on a SATA drive. My purpose with the test is to figure out whether there are circumstances, with the 6.9.2 kernel, in which the plugin would cause a spun-down SATA drive to spin up. There's a single point where the plugin interacts with a SATA drive, which is with this sdparm command (used to reliably determine whether a drive is SAS or not). BTW the reason all SAS drives immediately spin up with the plugin removed is that vanilla Unraid iss
  9. @SimonF, are you seeing the same behavior (with your SATA drives) if you remove the plugin? If NOT (i.e. removing the plugin makes the issue go away), can you please test something for me -- 1. Remove the plugin 2. Manually spin down one of the SATA drives on which you've seen the problem. 3. Issue this command against this SATA drive: sdparm -ip di_target /dev/sdX 4. Check whether this command caused (a) the drive to spin up (b) message "read SMART /dev/sdX" to be logged. Thanks! (Un)fortunately I can't reproduce this issue locally.
  10. Thanks. That's expected. Are you getting a similar "read SMART" messages when the drives spin back up spontaneously (the issue at hand)?
  11. When the drives spin back up, are you guys seeing a correlating "read SMART" message in syslog?
  12. Data point: Both my parity drives (SAS HGST) spin down upon request, no issue. HDD is HGST, ctrl is onboard SM (LSI).
  13. I have just migrated to 6.9.2 and SAS Spindown works perfectly for me (same as it did in 6.9.0 and 6.9.1). Do you have a distinctly different experience than you had in 6.9.1?
  14. Yes, you've hit one of the main sources of grief with this entire "SAS Spin Down" journey. In brief, spindown is not well defined in the SCSI / SAS standards, and therefore it's implemented differently on different drives. For a slightly broader explanation: SAS drives have several power states. Two of those are of interest here: Idle (2) and Standby (3). In the standard, those states are defined rather loosely and abstractly; each of them is supposed to be a deeper "power saving" mode, in which the power draw is yet lower and the distance from the Active state is yet larger than the