Disk don't always spin down

  • I've got an odd little OMV setup, with four HDD's.
    Primarily, I've got an SSD, on which OMV lives, as well as the main download folders and such.
    Next to that, I've got three HDD's, with different use cases. One is used perhaps twice a day, one is used once every couple of days, one is updated once a week (Friday backups).


    The SSD is set to stay active at all times, but I'm not sure if this has any effect (it's an SSD, after all). All others are set to spin down after fifteen minutes, with the acoustic setting set to 'quiet, low performance'.


    I've no problems with performance; everything works as intended. However, the disks don't always spin down. Right now, all three are active, and I do not know why. Sometimes all three are inactive, sometimes one starts up in the middle of the night and won't go back to sleep.


    Is there another way to check if there are processes blocking them from spinning down?
    Ideally, I would also love a logfile stating WHY disks spin up, but I'll settle for something that tells me why they don't spin down.


    UPDATE:
    What I've found out and messed with so far)

    • Flipped acoustic power management to 'disabled'. Not sure what this does, exactly, but the sound seems the same, and power usage is either the same, or not different enough to be measured accurately.
    • I've set commit to 60 in fstab. The audible click every five seconds is down to every minute or so, but the disks still don't spin down.
    • I've addeed noatime to fstab. No effect.
    • changed /etc/init.d/samba to work from ram, and not from a location on the hard drive in question.
    • Got inotify-tools, and tried to use inotifywatch to figure out what happens. Not seeing a lot of actual activity, though.
    • iotop tells me transmission jumps on the SSD during download, and a whole lot of other processes. It would seem the journaling process is active and doing IO, albeit a very small amount. Might this block spin down? I've got EXT4 for all drives, and there have been issues with the journaling blocking spin down...
    • Used lsof | grep sd# (# as the hard drive identification), which tells me on all disks there are three commands running: all three named jbd2/sd#. They look like this:


    Is this indeed due to the EXT4 journaling, or should I keep looking?
    If yes: is there some form of fix, aside from moving everything over to XFS?
    If no: how do I keep looking? I've not enough knowledge to know further steps :(

  • Okay, I've also disabled system monitoring, rsyslog, cron, ntp, and rsync. No effect.
    I also changed a hard drive (a 1TB Seagate piece of excrement to a 3TB WD Red), which I formatted as XFS. Initally, I set it to spin down, to see if it made a difference. It did indeed spin down, but since WD Red are designed to keep active all the time, I set it to 'happily spinning all the time'. I'm slowly copying stuff to the WD Red to free up another drive, so I can format that one as XFS.

  • Perhaps this is only as a reference, and not a real thread, but still; I've got some progress.


    Yesterday, I reformatted another drive as XFS, which spun down exactly ten minutes after I stopped messing with it. And it stayed down!


    So, I repeated the process, and moved the third drive to XFS this morning. It also spun down after ten minutes!
    And then I accessed it through windows, copied a handful of files, and waited ten minutes. Still spinning. About an hour later, it finally spun down, so it would seem I only found one issue.


    Luckily, I had one more thing to try; set the sharing to go through NFS, instead of SMB. My reasoning was that SMB might not be properly aware of disconnects, and therefore keep the drive active (no idea how I got there, though)
    I'd read NFS was considered superior anyways, and android (including the media centre) natively support it, so why not?


    And now, FINALLY, everything spins down properly. The last EXT4 drive (not the OS drive) still seems to have some issues going down and staying down (two issues), but I'll move that one to XFS later. SMB also seemed to interfere somehow, so NFS is a bit more desired (detail: I'm also seeing about 20% increase in transfer speeds on LAN after switching to NFS).

  • Something like that, yes. If I understand correctly, samba stores some data about the share on the drive itself which causes almost continuous access, preventing spindown under certain circumstances. I'd have to check what I changed exactly, but it comes down to that.

  • I'd love to implement this as well if you can point me in the right direction. I did some preliminary searching on Google, but it didn't immediately connect me with what you are talking about.


    I have 8GB of memory, only 2% of which is utilized, so it sounds like a great use for my system resources.

  • I liked the guide. It has a few tips I hadn't seen yet. I was thinking of using a RAM drive for some of the items that use the cache directory (including the Samba cache), but I hadn't seen anyone else doing it and was therefore cautious.


    Thanks for the information!

  • I've been experiencing similar problems. I have a server with an SSD where the OS lives and a HDD for all the other stuff. I used the system mainly when I get home after work, and I probably use it 1 hour a day at most, and on weekends for backups. That means, for me it makes more sense to keep the drives in standby the whole day. However, they don't spin down despite all my efforts to make them stop.


    In my case, however, there is Plex , Couchpotato and Owncload running in the background, so I am starting to think that one of them (or all) are the ones causing the problem. But you just gave me an idea:


    Used lsof | grep sd# (# as the hard drive identification), which tells me on all disks there are three commands running: all three named jbd2/sd#


    I'll check that when I get home. Perhaps I can find who is accessing the drives constantly. In the other hand, putting samba to work from ram is actually a good idea. I have only one Windows client that does not run daily, therefore I could take some advantage of that.

    Custom mini-ITX build
    Coolcube Mini, Intel Desktop Board DQ77KB, Intel Core i7-3770S, 8 GB DDR3 Ram, 64 GB Trascend mSata SSD (OS), X3 1TB HDD pooled + parity

    Dell Optiplex 960 sff (deprecated) - link


    Dell Optiplex FX160 (repurposed) - link


    "If you can't find it in Google, it simply doesn't exist!" - The Internetz


  • Couchpotato shouldn't be an issue; it periodically checks the servers, and only checks the disks on invervals if it's expecting something (I think it even monitors downloads, but I'm not sure).

  • I'll take a look at Plex configuration. The data in the drives does not change often, therefore there is no need for Plex to be scanning constantly.

    Custom mini-ITX build
    Coolcube Mini, Intel Desktop Board DQ77KB, Intel Core i7-3770S, 8 GB DDR3 Ram, 64 GB Trascend mSata SSD (OS), X3 1TB HDD pooled + parity

    Dell Optiplex 960 sff (deprecated) - link


    Dell Optiplex FX160 (repurposed) - link


    "If you can't find it in Google, it simply doesn't exist!" - The Internetz


  • I put the Samba cache in memory along with Plex (big offender - it updates logs every 30 minutes just to say it is doing nothing), Couchpotato, Sickbeard, SMART and a few others I'm probably forgetting.


    You can use this method to detect what is accessing the disk:
    My Guide to Debugging Disk Spin-ups


    I used this method to put them in memory:
    My Guide to using a RAM Drive for the Plex Log Directory


    Although I've gone beyond this method in that I'm writing a new program to automatically manage these ram drives. Similar to folder2ram but I'm adding in more advanced features such as the ability to automatically stop and then restart services that are using the directory so you can create the ram drive without the possibility that it gets accessed by the service.

  • Sweet! Something to try during the weekend. However, I have to ask: when you get a Plex update, do the changes you made keep working or do you have to do it again?

    Custom mini-ITX build
    Coolcube Mini, Intel Desktop Board DQ77KB, Intel Core i7-3770S, 8 GB DDR3 Ram, 64 GB Trascend mSata SSD (OS), X3 1TB HDD pooled + parity

    Dell Optiplex 960 sff (deprecated) - link


    Dell Optiplex FX160 (repurposed) - link


    "If you can't find it in Google, it simply doesn't exist!" - The Internetz


  • So, as per the suggestion from @Reed, I moved the init.d/samba to work from the RAM and deactivated Plex to see if that solved my problem (before making the changes you suggested, I decided to try deactivating the Plex Plugin). Unfortunately, it didn't. I have exactly the same 3 processes that @vomov showed in the first post accessing my HDD. I've set the spin down time to 30 minutes (for testing purposes, it should be around 1 to 2 hours), but still the drives are not going down. There are only 2 clients accessing OMV, and both are off. But still, today in the morning the HDD was spinning. SMART is also set to Standby, with a check interval of 30 minutes.

    Custom mini-ITX build
    Coolcube Mini, Intel Desktop Board DQ77KB, Intel Core i7-3770S, 8 GB DDR3 Ram, 64 GB Trascend mSata SSD (OS), X3 1TB HDD pooled + parity

    Dell Optiplex 960 sff (deprecated) - link


    Dell Optiplex FX160 (repurposed) - link


    "If you can't find it in Google, it simply doesn't exist!" - The Internetz


  • I am on EXT4, but my system has only 2 GB of RAM, and AFAIK XFS uses huge amounts of RAM. I could eventually upgrade to 4 (limited by my system). So, are you saying that the EXT4 journaling is the one keeping the HDDs spinning?

    Custom mini-ITX build
    Coolcube Mini, Intel Desktop Board DQ77KB, Intel Core i7-3770S, 8 GB DDR3 Ram, 64 GB Trascend mSata SSD (OS), X3 1TB HDD pooled + parity

    Dell Optiplex 960 sff (deprecated) - link


    Dell Optiplex FX160 (repurposed) - link


    "If you can't find it in Google, it simply doesn't exist!" - The Internetz


  • I've got 8GB, and I'm seeing RAM sitting on 4% idle, and occacional jumps to 12% on access, so I *guess* it should be okay for my usage pattern to go to 2GB RAM. I've no idea how XFS behaves under different usage patterns, and no idea how it behaves under low free memory conditions, though. Other than simply trying it out, I'm not sure how to figure out what the result will be.


    The jbd in the offending processes stands for 'Journaling Block Device', and it is something associated with EXT4. just Google 'jbd2', and the first page will be dominated by the issue we're experiencing.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!