• 6.9.2 RC2 "Read SMART" spins up the same 2 disks throughout the day


    cholzer
    • Closed

    The same 2 disks (sdb is the parity disk) seem to get spun up to read SMART (?) throughout the day.

    Time is AM, everyone was asleep during that time, no one accessed the NAS.
    There are no VM's and no dockers in Unraid, I use it as a "simple" NAS.

    Fusion-MPT 12GSAS SAS3008 PCI-Express in IT Mode

    The following plugins are installed:

    • CA User Scripts
    • Community Applications
    • Dynamix Cache Dirs
    • Dynamix Schedules
    • Dynamix SSD Trim
    • openVMTools_compiled
    • Recycle Bin
    • Tips and Tweaks
    • Unassigned Devices
    • Unassigned Devices Plus (Addon)
    Jan 12 03:02:13 NAS emhttpd: read SMART /dev/sde
    Jan 12 03:02:32 NAS emhttpd: read SMART /dev/sdd
    Jan 12 04:01:19 NAS emhttpd: spinning down /dev/sdd
    Jan 12 04:01:21 NAS emhttpd: spinning down /dev/sde
    Jan 12 04:07:29 NAS emhttpd: read SMART /dev/sde
    Jan 12 04:27:05 NAS emhttpd: read SMART /dev/sdd
    Jan 12 05:31:27 NAS emhttpd: spinning down /dev/sdd
    Jan 12 05:31:27 NAS emhttpd: spinning down /dev/sde

     



    User Feedback

    Recommended Comments



    I had to replace my LSI 3008 HBA with an LSI 2008 HBA because I suspected that the 3008 was failing.

    Since I did that I can nolonger reproduce this issue.
    Disks remain spun down now!

    Link to comment
    Share on other sites

    Since you can't reproduce I'm going to close this for now, please re-open or create a new report in the future if necessary.

    Link to comment
    Share on other sites

    I just happened to stumble onto this thread...

    ..I've been having this problem forever!  Admittedly, I never dug into it much, but was always annoyed that my disks were always spun up. Even if i forced to spin down, they always seemed to come back up.  I finally checked logs today and I'm seeing it frequently always reading SMART on all drives.  Trying to figure out what is triggering the reading of the SMART stats though.

     

    I will say though, I am using LSI 2008 HBA for my controllers.

     

    EDIT:  I also am on RC2.  I can't say specifically if this is unique to RC2 or not, however I am on that currently, and currently see logs showing this.  I cannot speak to why i previously had issues with disks always spun up. (prior to RC2).

    Edited by mdoom
    Link to comment
    Share on other sites
    On 1/19/2021 at 10:59 PM, mdoom said:

    I just happened to stumble onto this thread...

    ..I've been having this problem forever!  Admittedly, I never dug into it much, but was always annoyed that my disks were always spun up. Even if i forced to spin down, they always seemed to come back up.  I finally checked logs today and I'm seeing it frequently always reading SMART on all drives.  Trying to figure out what is triggering the reading of the SMART stats though.

     

    I will say though, I am using LSI 2008 HBA for my controllers.

     

    EDIT:  I also am on RC2.  I can't say specifically if this is unique to RC2 or not, however I am on that currently, and currently see logs showing this.  I cannot speak to why i previously had issues with disks always spun up. (prior to RC2).

    In my case it was caused by the LSI 3008 controller which began to act up in other ways as well. This issue was in my case just one more symptom of the HBA failing.

    If you use plugins, VM's or dockers then you should try to disable all of them and see if the disks stay spun down.

    Link to comment
    Share on other sites
    4 hours ago, cholzer said:

    In my case it was caused by the LSI 3008 controller which began to act up in other ways as well. This issue was in my case just one more symptom of the HBA failing.

    If you use plugins, VM's or dockers then you should try to disable all of them and see if the disks stay spun down.

     

    Thanks.  Yeah already been going down that path disabling nearly everything.  Haven't figured out the culprit yet!  Will keep messing with it.

    The interesting thing, is if i force a spin-down of all disks, its always shortly after I do that that they all wake up with that READ SMART message.

    Link to comment
    Share on other sites

    Since I don't use any such controller and have only experienced this with the RC2, this is software related.

    Link to comment
    Share on other sites
    4 hours ago, mdoom said:

    The interesting thing, is if i force a spin-down of all disks, its always shortly after I do that that they all wake up with that READ SMART message.

     

    Yep. Although I have to say it doesn't happen for all disks. Sometimes it's disk1, sometimes (like today) it's disk 4. And the worst thing about this is: The spindown routine does not work with this kind of spinup, ie the drive keeps going until I spin it down manually.

    Edited by Pillendreher
    Link to comment
    Share on other sites
    2 hours ago, Pillendreher said:

    Since I don't use any such controller and have only experienced this with the RC2, this is software related.

    If the issue goes away when you downgrade to the latest stable, then yeah - it would appear that RC2 is the problem.

    But just because you don't use the same HBA as I do does not mean that it is software related. In my case the HBA began to die, that is what caused my issue. Your onboard SATA controller can malfunction just as my HBA did.

    So unless downgrading Unraid to the latest stable fixes your issue, you can not rule out a hardware fault. In my case the issue started after the upgrade, which is why I first also thought that RC2 was to blame, while it was the HBA.

    Edited by cholzer
    Link to comment
    Share on other sites
    18 hours ago, cholzer said:

    If the issue goes away when you downgrade to the latest stable, then yeah - it would appear that RC2 is the problem.

    But just because you don't use the same HBA as I do does not mean that it is software related. In my case the HBA began to die, that is what caused my issue. Your onboard SATA controller can malfunction just as my HBA did.

    So unless downgrading Unraid to the latest stable fixes your issue, you can not rule out a hardware fault. In my case the issue started after the upgrade, which is why I first also thought that RC2 was to blame, while it was the HBA.

     

    Well sure, faulty hardware is always a possibility, but since my hardware is barely more than a month old, the issues started the minute I upgrade to RC2 and multiple posters have mentioned this issue over the last couple of weeks, I'm still fairly certain that this is a software issue. Going from Beta35 to RC2, something changed about the way hard drives are handled.

    Link to comment
    Share on other sites

    FYR, I use SAS3008 HBA and have't disk spin issue on RC2, it also a simple setup without Docker and VM in disable state ..... BTW, the actual cause still not certain, so someone have and someone have't such problem.

     

    My advice was make Unraid as simple as you can and check does any network peer would spin up the network share.

    Edited by Vr2Io
    Link to comment
    Share on other sites
    21 hours ago, Pillendreher said:

     

    but since my hardware is barely more than a month old

     

    My HBA is 7 months old, and it started to fail shortly after I upgraded to RC2. So just because your hardware is new does not mean that it is okay. ;)
    The only way how you can make sure that RC2 is to blame is by downgrading.

    Link to comment
    Share on other sites
    20 hours ago, Vr2Io said:

    I use SAS3008 HBA and have't disk spin issue on RC2

    Yeah mine was broken, I even got random disconnects of entire disks later on. RMA in progress.
    In the meantime the SAS2008 is working fine and no more issues. :)

    Link to comment
    Share on other sites

    I have these random smart spinups on RC2 too. I went from stable to RC2 because stable verson did not have drivers for newer intel nics. I do not remember this being a thing on stable. I cannot confirm since the stable was running on different mobo (B450 before, H410 now). I do not run any HBA controllers, just plain mobo sata. The hardware is in its 3rd day so I wouldnt say its dying (faking hopefully right :D)

     

     

    2021-01-24 08_57_21-System Log - Brave.jpg

    Link to comment
    Share on other sites

     

    4 hours ago, Ver7o said:

    random smart spinups

     

    What is the value of md_write method in disk settings?  As I dont see the mdcmd messages on my system, are you using CA Auto turbo? If you are using CA Auto Turbo have you tried disabling to see if that changes anything?

    Link to comment
    Share on other sites

    I do use CA TurboWrite and its write mode is set to Normal (Read/Modify/Write).

     

    Under disk setting I have md_write_method set to auto. 

     

    I have not thought of disabling turbo plugin until now. Disabled it now. Will report back later, if anything changes.

    Link to comment
    Share on other sites

    TurboWrite doesn't seem to be the reason for this. Spin ups still happen without it.

     

    Jan 25 20:53:42 Tower emhttpd: spinning down /dev/sdb
    Jan 25 20:53:42 Tower emhttpd: spinning down /dev/sdc
    Jan 25 20:53:42 Tower emhttpd: spinning down /dev/sdd
    Jan 25 21:24:30 Tower emhttpd: read SMART /dev/sdc
    Jan 25 21:39:32 Tower emhttpd: spinning down /dev/sdc
    Jan 25 21:51:53 Tower emhttpd: read SMART /dev/sdd
    Jan 25 22:06:55 Tower emhttpd: spinning down /dev/sdd
    Jan 25 22:53:12 Tower emhttpd: read SMART /dev/sdc
    Jan 25 23:05:09 Tower emhttpd: read SMART /dev/sdd
    Jan 25 23:05:19 Tower emhttpd: read SMART /dev/sdb
    Jan 25 23:20:11 Tower emhttpd: spinning down /dev/sdd
    Jan 25 23:22:21 Tower emhttpd: spinning down /dev/sdb
    Jan 25 23:22:21 Tower emhttpd: spinning down /dev/sdc
    Jan 25 23:37:59 Tower emhttpd: read SMART /dev/sdc
    Jan 26 00:00:13 Tower emhttpd: read SMART /dev/sdb
    Jan 26 00:01:55 Tower emhttpd: read SMART /dev/sdd
    Jan 26 00:30:19 Tower emhttpd: spinning down /dev/sdb
    Jan 26 00:33:24 Tower emhttpd: spinning down /dev/sdc
    Jan 26 00:33:47 Tower emhttpd: spinning down /dev/sdd
    Jan 26 02:01:55 Tower emhttpd: read SMART /dev/sdd
    Jan 26 02:01:55 Tower emhttpd: read SMART /dev/sdc
    Jan 26 02:18:14 Tower emhttpd: spinning down /dev/sdd
    Jan 26 02:18:16 Tower emhttpd: spinning down /dev/sdc
    Jan 26 09:35:11 Tower emhttpd: read SMART /dev/sdd
    Jan 26 09:50:13 Tower emhttpd: spinning down /dev/sdd
    Jan 26 14:13:46 Tower emhttpd: read SMART /dev/sdc

    Link to comment
    Share on other sites
    6 minutes ago, Ver7o said:

    TurboWrite doesn't seem to be the reason for this. Spin ups still happen without it.

     

    Tired to unplug the network cable over night and then in the morning reconnect and check the log if spin ups occurred?
    That way you can rule out devices on your network causing the drives to wake up.

    Just for the record, since I replaced my failing HBA my drives have stopped to spin up randomly.

    Link to comment
    Share on other sites

    Unless you are certain none of your dockers or VMs have files open on the array look into that. Make sure appdata, domains, or system shares have no files on the array. You can see how much of each disk each share is using by clicking Compute... for the share. 

    Link to comment
    Share on other sites
    On 1/23/2021 at 1:53 PM, cholzer said:

     

    My HBA is 7 months old, and it started to fail shortly after I upgraded to RC2. So just because your hardware is new does not mean that it is okay. ;)
    The only way how you can make sure that RC2 is to blame is by downgrading.

     

    Went back to Beta35 - not a single unwarranted spin-up in two full days. Meanwhile not a day went by without multiple random spin-ups of my drives.

    • Thanks 1
    Link to comment
    Share on other sites

    I'm experiencing something similar.  The past while, I'm getting a bunch of reads and writes on media disks used by Plex.  I've ensured it's not set to scan for changes as I do this manually but I'm getting disk reads around 2am and 5am daily:

     

    unraid.thumb.png.506bd962abce1aaba06133baad1967bc.png

     

    I did have md_write_method set ro reconstruct write and changed it to AUTO.  Will see what happens.

     

    Logs simply show:
     

    Quote

    Jan 27 00:00:06 BlackBox root: /etc/libvirt: 125.7 MiB (131846144 bytes) trimmed on /dev/loop3
    Jan 27 00:00:06 BlackBox root: /var/lib/docker: 1.7 GiB (1846099968 bytes) trimmed on /dev/loop2
    Jan 27 00:00:06 BlackBox root: /mnt/cache: 26.6 GiB (28603330560 bytes) trimmed on /dev/nvme0n1p1
    Jan 27 00:10:06 BlackBox sSMTP[7342]: Creating SSL connection to host
    Jan 27 00:10:06 BlackBox sSMTP[7342]: SSL connection using TLS_AES_256_GCM_SHA384
    Jan 27 00:10:08 BlackBox sSMTP[7342]: Sent mail for email@removed.com (221 2.0.0 closing connection z16sm660013qtb.73 - gsmtp) uid=0 username=xxx outbytes=717
    Jan 27 00:10:08 BlackBox sSMTP[7350]: Creating SSL connection to host
    Jan 27 00:10:08 BlackBox sSMTP[7350]: SSL connection using TLS_AES_256_GCM_SHA384
    Jan 27 00:10:11 BlackBox sSMTP[7350]: Sent mail for email@removed.com (221 2.0.0 closing connection s6sm631124qtx.63 - gsmtp) uid=0 username=xxx outbytes=707
    Jan 27 00:12:15 BlackBox webGUI: Successful login user root from 192.168.7.119
    Jan 27 00:12:40 BlackBox kernel: veth1ab266d: renamed from eth0
    Jan 27 00:12:40 BlackBox kernel: br-c990ed414cd6: port 1(vethbce39e1) entered disabled state
    Jan 27 00:12:40 BlackBox avahi-daemon[8286]: Interface vethbce39e1.IPv6 no longer relevant for mDNS.
    Jan 27 00:12:40 BlackBox avahi-daemon[8286]: Leaving mDNS multicast group on interface vethbce39e1.IPv6 with address fe80::dc7f:19ff:fe1e:30a5.
    Jan 27 00:12:40 BlackBox kernel: br-c990ed414cd6: port 1(vethbce39e1) entered disabled state
    Jan 27 00:12:40 BlackBox kernel: device vethbce39e1 left promiscuous mode
    Jan 27 00:12:40 BlackBox kernel: br-c990ed414cd6: port 1(vethbce39e1) entered disabled state
    Jan 27 00:12:40 BlackBox avahi-daemon[8286]: Withdrawing address record for fe80::dc7f:19ff:fe1e:30a5 on vethbce39e1.
    Jan 27 00:12:40 BlackBox kernel: br-c990ed414cd6: port 1(veth8cbcc85) entered blocking state
    Jan 27 00:12:40 BlackBox kernel: br-c990ed414cd6: port 1(veth8cbcc85) entered disabled state
    Jan 27 00:12:40 BlackBox kernel: device veth8cbcc85 entered promiscuous mode
    Jan 27 00:12:40 BlackBox kernel: br-c990ed414cd6: port 1(veth8cbcc85) entered blocking state
    Jan 27 00:12:40 BlackBox kernel: br-c990ed414cd6: port 1(veth8cbcc85) entered forwarding state
    Jan 27 00:12:40 BlackBox kernel: eth0: renamed from veth0392fbe
    Jan 27 00:12:40 BlackBox kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth8cbcc85: link becomes ready
    Jan 27 00:12:42 BlackBox avahi-daemon[8286]: Joining mDNS multicast group on interface veth8cbcc85.IPv6 with address fe80::8462:73ff:fe87:3e56.
    Jan 27 00:12:42 BlackBox avahi-daemon[8286]: New relevant interface veth8cbcc85.IPv6 for mDNS.
    Jan 27 00:12:42 BlackBox avahi-daemon[8286]: Registering new address record for fe80::8462:73ff:fe87:3e56 on veth8cbcc85.*.
    Jan 27 02:03:45 BlackBox emhttpd: read SMART /dev/sdc
    Jan 27 02:04:53 BlackBox emhttpd: read SMART /dev/sdd
    Jan 27 02:12:15 BlackBox emhttpd: read SMART /dev/sdg
    Jan 27 02:45:52 BlackBox emhttpd: read SMART /dev/sdb
    Jan 27 03:40:16 BlackBox crond[2030]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null
    Jan 27 03:45:41 BlackBox emhttpd: spinning down /dev/sdg
    Jan 27 04:45:23 BlackBox emhttpd: read SMART /dev/sdg
    Jan 27 05:31:43 BlackBox emhttpd: spinning down /dev/sdb
    Jan 27 05:33:53 BlackBox emhttpd: spinning down /dev/sdd
    Jan 27 05:45:11 BlackBox emhttpd: spinning down /dev/sdc
    Jan 27 06:03:15 BlackBox emhttpd: spinning down /dev/sdg

    --break--

    Jan 28 00:00:07 BlackBox root: /etc/libvirt: 125.7 MiB (131846144 bytes) trimmed on /dev/loop3
    Jan 28 00:00:07 BlackBox root: /var/lib/docker: 1.7 GiB (1788416000 bytes) trimmed on /dev/loop2
    Jan 28 00:00:07 BlackBox root: /mnt/cache: 26.8 GiB (28778823680 bytes) trimmed on /dev/nvme0n1p1
    Jan 28 00:10:05 BlackBox sSMTP[1125]: Creating SSL connection to host
    Jan 28 00:10:05 BlackBox sSMTP[1125]: SSL connection using TLS_AES_256_GCM_SHA384
    Jan 28 00:10:07 BlackBox sSMTP[1169]: Creating SSL connection to host
    Jan 28 00:10:07 BlackBox sSMTP[1169]: SSL connection using TLS_AES_256_GCM_SHA384
    Jan 28 00:10:08 BlackBox sSMTP[1125]: Sent mail for email@removed.com (221 2.0.0 closing connection r17sm2669666qta.78 - gsmtp) uid=0 username=xxx outbytes=737
    Jan 28 00:10:09 BlackBox sSMTP[1169]: Sent mail for email@removed.com (221 2.0.0 closing connection d48sm2897765qta.50 - gsmtp) uid=0 username=xxx outbytes=707
    Jan 28 00:10:09 BlackBox sSMTP[1191]: Creating SSL connection to host
    Jan 28 00:10:10 BlackBox sSMTP[1191]: SSL connection using TLS_AES_256_GCM_SHA384
    Jan 28 00:10:12 BlackBox sSMTP[1191]: Sent mail for email@removed.com (221 2.0.0 closing connection r4sm86471qkf.112 - gsmtp) uid=0 username=xxx outbytes=707
    Jan 28 02:03:43 BlackBox emhttpd: read SMART /dev/sdg
    Jan 28 02:07:02 BlackBox emhttpd: read SMART /dev/sdc
    Jan 28 02:07:43 BlackBox emhttpd: read SMART /dev/sdb
    Jan 28 02:13:47 BlackBox emhttpd: read SMART /dev/sdd
    Jan 28 03:31:33 BlackBox emhttpd: spinning down /dev/sdg
    Jan 28 03:40:16 BlackBox crond[2030]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null
    Jan 28 05:49:50 BlackBox emhttpd: spinning down /dev/sdc
    Jan 28 06:02:16 BlackBox emhttpd: spinning down /dev/sdd
    Jan 28 06:03:17 BlackBox emhttpd: spinning down /dev/sdb
    Jan 28 12:22:44 BlackBox webGUI: Successful login 
    Jan 28 12:25:06 BlackBox emhttpd: read SMART /dev/sde
    Jan 28 12:25:19 BlackBox emhttpd: read SMART /dev/sdd
    Jan 28 12:25:32 BlackBox emhttpd: read SMART /dev/sdc
    Jan 28 12:25:45 BlackBox emhttpd: read SMART /dev/sdb
    Jan 28 12:25:58 BlackBox emhttpd: read SMART /dev/sdf
    Jan 28 12:26:10 BlackBox emhttpd: read SMART /dev/sdg
    Jan 28 12:29:22 BlackBox webGUI: Successful login

    Will update tomorrow.

    unraid.png

    Edited by AdrianF
    Link to comment
    Share on other sites
    10 minutes ago, AdrianF said:

    I'm experiencing something similar.  The past while, I'm getting a bunch of reads and writes on media disks used by Plex.  I've ensured it's not set to scan for changes as I do this manually but I'm getting disk reads around 2am and 5am daily:

     

    I did have md_write_method set ro reconstruct write and changed it to AUTO.  Will see what happens.

     

    Logs simply show:
     

    Will update tomorrow.

     


    Just to add, I also had md_write_method se to reconstruct.  After switching to auto, that helped.  Now not every disk spins up when any write occurs, but I still am dealing with the constant SMART reads.  I have had some issues with plex hanging on scans before, but I've experienced this SMART issue with all my dockers stopped too.  

    Link to comment
    Share on other sites
    8 hours ago, AdrianF said:

    I'm getting a bunch of reads and writes on media disks used by Plex.  I've ensured it's not set to scan for changes as I do this manually but I'm getting disk reads around 2am and 5am daily:

     

    Plex does all kinds of maintenance tasks during the night, some of which involve accessing the media files. https://support.plex.tv/articles/201553286-scheduled-tasks/

     

    • Thanks 1
    Link to comment
    Share on other sites

    I did a clean install over the weekend. Apparently a smart read happened twice while I was asleep:

     

    Jan 31 01:24:53 Tower emhttpd: read SMART /dev/sdb
    Jan 31 01:39:55 Tower emhttpd: spinning down /dev/sdb
    ...
    Jan 31 08:31:35 Tower emhttpd: read SMART /dev/sdc
    Jan 31 08:46:42 Tower emhttpd: spinning down /dev/sdc

     

    At least the 15 min spindown worked I guess...

    Link to comment
    Share on other sites



    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.