Announcement

Collapse
No announcement yet.

hdparm not work and my hard drivers support hdparm

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    hdparm not work and my hard drivers support hdparm

    Hello,
    It is a subject that drives me "crazy" these last days.
    I have changed my mechanical hard drives, before I used hd-idle because my old mechanical hard drives did not support hdparm, but the new ones do.
    Proof of this is:
    Code:
    ~$ sudo hdparm -B /dev/sda
    
    /dev/sda:
    APM_level      = 254
    Ok, I have configured the hdparm.conf file as follows at the end of file:
    Code:
    /dev/sda {
    spindown_time = 24
    }
    And also with:
    Code:
    command_line {
    hdparm -S 24 /dev/sda
    }
    And the fact is that they never go to standby mode and after much searching, reading and testing, I can't ...

    With hd-idle it works, but my idea is to use hdparm because the new versions of hd-idle don't work very well and the one I use, sometimes when I suspend the computer, also stops working.

    And the strangest thing is that, there are 3 mechanical hard drives, I have progressively changed them, and doing tests, when I had a new one and two old ones, I configured the new one in hdparm and it worked, now it doesn't ...
    I can't find any explanation ...

    Can you think of something?

    Thanks in advance.

    #2
    (I have a WD black (I think it's black) and it seems to be strongly coupled acoustically to the floor the PC is on, and the droning noise I find quite oppressive. )

    I use sudo hdparm -y to spin down the hard drives in my system, and IIUC hd-idle does too. hdparm -S doesn't work.

    My /etc/default/hd-idle has
    Code:
    HD_IDLE_OPTS="-i 180 -l /var/log/hd-idle.log"
    IIRC in my last Kubuntu reinstall of 20.04 the default install properly integrated with systemd.

    That 180 means 3 minutes, and the noise is so annoying sometimes I can't wait that long, so I've got a widget that runs a script that does sudo hdparm -y. That only works if the sudo doesn't need a password. (If I make the time shorter the drives spin down while I'm using them.)
    Regards, John Little

    Comment


      #3
      It seems to me that the problem with hdparm is with WD hard drives, mine are also WD and although hdparm, from the tests, indicates that it should work, the reality is that hdparm -S does not work for me, neither in hdparm.conf nor in konsole with sudo hdparm -S 24 / dev / sdx

      And I have 3 WD hard drives ...

      Sure enough, the noise is very annoying, as I use them only for data, I have changed them to 2.5 and the noise has dropped a lot, but I always thought that hdparm would work.

      Indeed, I have to use hd-idle and I also have them in 180 seconds, which I am going to lower them to 120 because I only use them for data storage.

      Luckily they will lend me a Seagate also 2.5 and I will see if hdparm works with the Seagate, but as I comment, after much reading I have seen that many people do not work with hdparm has WD. But I thought that being new, if it would work, as the test above shows that I get the value of 254, that means that it is supported by hdparm but the reality is different ...

      I was already going crazy with different settings in hdparm ...

      That if, IIRC when you name it, I do not know exactly what it is (or now I do not fall ...).

      Thanks!

      Comment


        #4
        Confirmed:

        hdparm does not work with WD mechanical hard drives, on the other hand, with a Seagate if it works ...

        I have always thought that WD is more reliable and / or durable than a Seagate, the Seagate they brought me, I premiered it, it lasted 20 minutes, then totally inaccessible, hehehe.

        I should point out that they are both 2.5 ".

        That this is a great "off topic", I have always had the thought that for data storage (not you) 3.5 hard drives were better, and lately I have read that 2.5 "hard drives are more durable and reliable ... generated a great doubt ...

        I only want the mechanics for data storage, that's why I spindown them, because for 2 or 3 times that I access one of them a day ... and now I don't know where to go, 2.5 "or 3.5"? WD or Seagate?

        With hd-idle I can configure the WD to spindown but .... it does not work 100%, sometimes, after resuming from suspension the hd-idle service stops working, instead hdparm does not have that problem, but it does not work with WD ...

        Comment


          #5
          When you say "hdparm does not work", isn't it the setting of hdparm -S that doesn't work? And there, it's the drive honouring the setting that's the issue? You usage implies that the hdparm command is at fault, and doesn't work at all. The -S setting is a small part of hdparm. hdparm -y still works to spin down the drives, doesn't it?

          The man page for hdparm suggests that the -S setting is "peculiar" and that some drives "may have very different interpretations" of the value set by hdparm -S. In principle, another programme could be used to change the setting, or you could write your own.

          I think your issue with hd-idle not working "100%" is likely to be caused by some process accessing the drives involved, causing them to spin up.
          Regards, John Little

          Comment


            #6
            Hello.
            I answer in parts, and first of all, sorry, my English is not very good and I think I did not express myself very well
            Originally posted by jlittle View Post
            When you say "hdparm does not work", isn't it the setting of hdparm -S that doesn't work? And there, it's the drive honouring the setting that's the issue? You usage implies that the hdparm command is at fault, and doesn't work at all. The -S setting is a small part of hdparm. hdparm -y still works to spin down the drives, doesn't it?
            Indeed, when I indicate hdparm does not work I mean hdparm -S (on the WD hard drives that I have), I have tried to configure hdmparm.conf as I indicated in the first post, the hard drives never pass to spindown, also executed with sudo in konsole , I put the value of 24 which is 2 minutes, this does not apply ... they do not pass to spindown.
            I have done the same steps with the Seagate and indeed, if it applies and they go to spindown after 2 minutes.
            Indeed, hdparm -y if it works on all hard drives, including WDs, but this is not what I'm looking for, this command passes the hard drives to spindown when executed, my intention is that they go to spindown after x time of inactivity .

            I am one of those who has the pc on and I do not turn off (shutdown) but if I suspend, and then resume, as I use mechanical hard drives very little, the idea is that they are always in spindown until I access them, and after 2 minutes no access, go back to spindown.

            The man page for hdparm suggests that the -S setting is "peculiar" and that some drives "may have very different interpretations" of the value set by hdparm -S. In principle, another programme could be used to change the setting, or you could write your own.
            Indeed in recent days I have read about it, the -S command is "peculiar" with respect to some units.
            Using another program to change the settings is beyond my knowledge ... and even more so, writing my own ...

            I think your issue with hd-idle not working "100%" is likely to be caused by some process accessing the drives involved, causing them to spin up.
            Regarding the comment that hd-idle does not work 100% for me ... this is where I think I did not explain myself well. Run always works, and it always puts me in spindown, what I meant is that; Sometimes after resuming pc from sleep, hd-idle service dies, disappears and I have to restart it by hand.
            In fact, hd-idle by default does not work well if you suspend and resume, on a website that talked about this issue, they published a patch to work after hibernation, suspension ... and it is the one I use together with hd-idle.
            The version that comes by default in the kubuntu repositories, which is the latest, never works for me, I have to use the penultimate version, it works fine for me, and force synpatic to use this version and not update it.
            Since you have that little "problem" that after resuming from suspend sometimes the hd-idle service disappears / dies, I always thought it would be better to use hdparm ...

            Comment


              #7
              Originally posted by wonder View Post
              I am one of those who has the pc on and I do not turn off (shutdown) but if I suspend, and then resume, ...
              Resuming from suspend always spins up hard drives on my desktop. It used to annoy me, so I've got this in /lib/systemd/system-sleep/spindown:
              Code:
              #!/bin/bash
              
              case $1 in
                post)
                  # output goes to the journal...
                  echo spinning down stuff
                  /sbin/hdparm -y /dev/disk/by-label/stuff
                  echo spinning down the old drive with pics
                  /sbin/hdparm -y /dev/disk/by-label/pics
                  ;;
              esac
              (I previously had the /dev/sdX names, but after a cabling shuffle the Xs changed, so now I use the label of one of the partitions on the drives, which I ensure are unique. In /dev/disk there's several alternatives for identifying storage devices.)
              The drives still spin up for a second or two.

              ... hd-idle ... Sometimes after resuming pc from sleep, hd-idle service dies, disappears and I have to restart it by hand.
              I'll watch out for that. Because the spindown script above works after suspend/resume, if hd-idle stopped I wouldn't notice. I started using hd-idle before it reached the Ubuntu repositories, building it from source, and it was a little flaky. Since then it appears to have been rewritten and the project is active; on 20.04 I think you've got the same version as I got on 21.10, 1.05 and it's up to 1.16.

              While typing this post, and seeing all the activity on https://github.com/adelolmo/hd-idle, and that it is up to 1.16, I thought I'd get the latest. I cloned it, built, and installed the new version using the instructions. All I had to do was install these packages:

              golang dh-golang dh-make-golang

              (I'm not sure the last was necessary, it seemed a good idea.)

              I've never (knowingly) built a go package before, but it was quick and painless, other than guessing "golang" and installing dh-golang after I got "error: Unmet build dependencies: dh-golang". Took about 5 minutes.

              I'll keep an eye on it, spin up some drives and see if they spin down.
              Regards, John Little

              Comment


                #8
                Originally posted by jlittle View Post
                Resuming from suspend always spins up hard drives on my desktop. It used to annoy me, so I've got this in /lib/systemd/system-sleep/spindown:
                Code:
                #!/bin/bash
                
                case $1 in
                post)
                # output goes to the journal...
                echo spinning down stuff
                /sbin/hdparm -y /dev/disk/by-label/stuff
                echo spinning down the old drive with pics
                /sbin/hdparm -y /dev/disk/by-label/pics
                ;;
                esac
                (I previously had the /dev/sdX names, but after a cabling shuffle the Xs changed, so now I use the label of one of the partitions on the drives, which I ensure are unique. In /dev/disk there's several alternatives for identifying storage devices.)
                The drives still spin up for a second or two.
                Interestingly, after resuming from sleep, the hard drives, with this code, return to spindown after 2 or 3 seconds, but does hd-idle work in its normal mode? I mean: You access the hard drive, it gets up, and after x scheduled time of inactivity, it goes back to spindown?


                I'll watch out for that. Because the spindown script above works after suspend/resume, if hd-idle stopped I wouldn't notice. I started using hd-idle before it reached the Ubuntu repositories, building it from source, and it was a little flaky. Since then it appears to have been rewritten and the project is active; on 20.04 I think you've got the same version as I got on 21.10, 1.05 and it's up to 1.16.

                While typing this post, and seeing all the activity on https://github.com/adelolmo/hd-idle, and that it is up to 1.16, I thought I'd get the latest. I cloned it, built, and installed the new version using the instructions. All I had to do was install these packages:

                golang dh-golang dh-make-golang

                (I'm not sure the last was necessary, it seemed a good idea.)

                I've never (knowingly) built a go package before, but it was quick and painless, other than guessing "golang" and installing dh-golang after I got "error: Unmet build dependencies: dh-golang". Took about 5 minutes.

                I'll keep an eye on it, spin up some drives and see if they spin down.
                Thanks for your message and link.
                In my case, indeed, I use kubuntu 20.04 and the repository version is 1.05 + ds-2 (focal) but this one does not work well for me.
                I have it forced in version 1.05.

                And as far as I thought, I thought the project was stopped.
                My reference url on hd-idle is: https://salsa.debian.org/debian/hd-idle
                As you can see, a version very much earlier than yours.

                So I have uninstalled my version and I have used your url that has version 1.16, indeed, I also had to install golang dh-golang dh-make-golang but it is fast, in my case I confirm, the last one, I needed to install it.
                I installed the first one first and still, I couldn't compile hd-idle so I had to install the last one too, after that it compiled, generated the necessary .deb and then installed it.

                I was completely unaware of the url with the 1.16 that you indicated, thank you!

                But it still has the same "problem", it is not that the hd-idle service stops working after resuming from suspension or hibernation, when you resume from suspension, you can see how the hd-idle service is still running, but no longer has any hard drive programmed to spin down.
                This is due (and I say it from memory after reading a long time ago) to the fact that the programmed account fails after resuming from suspension and that is why it no longer spindown ...

                I found information about it about it here:
                https://forum.openmediavault.org/index.php?thread/17101-guide-how-to-setup-hd-idle-a-hdd-spin-down-sw-together-with-the-omv-plugin-autos/&pageNo=2

                And the solution to make it work after resuming from suspension I found in previous thread referring to this patch:
                https://sourceforge.net/p/hd-idle/patches/2/

                We need created a new systemd-unit that restarts the hd-idle service, / etc / systemd / system /
                and must be activated with the command:
                systemctl enable hd-idle-restart-resume.service
                The content of the file:
                Code:
                [Unit]
                Description=Restart hd-idle
                After=suspend.target
                After=hibernate.target
                After=hybrid-sleep.target
                
                [Service]
                Type=simple
                ExecStart=/bin/systemctl --no-block restart hd-idle
                
                [Install]
                WantedBy=suspend.target
                WantedBy=hibernate.target
                WantedBy=hybrid-sleep.target
                With this, I get it to work after resuming from sleep.

                I hope it can be integrated, or continue the development of hd-idle for those who, in our case, hdparm -S does not work for us.
                I have confirmed that on WD hard drives it does not work and on Seagate it does, but for personal reasons, the WDs give me more confidence regarding reliability and above all, durability (although this like everything, it will be as you like, everyone will have one )

                Again, thanks for your answer and link to the latest version 1.16, I was unaware of it and thought it was no longer in development.

                Comment


                  #9
                  Since my post on the 27th, I have noticed that the hard drives are spinning down after I've accessed them and they've spun up. So hd-idle is working.

                  I think I haven't had the problem of hd-idle noticing that the drives have spun up after a resume because my spin down script has left them in the state that hd-idle thinks they're in. I think I like the hd-idle-restart-resume.service approach is better than mine because it puts the responsibility for spinning down in one place.

                  I'm going to disable my spindown script to see what happens.
                  [Edit] the drives don't spin down. I'll try the systemd service, though I don't understand how it works.
                  Last edited by jlittle; Dec 07, 2021, 02:44 AM.
                  Regards, John Little

                  Comment


                    #10
                    It took me a long time to get to that script where hd-idle and its account resume so that the hard drives spin down after resuming after suspension (or hibernation) although I never hibernate but I always suspend.
                    Reading, searching and searching, in the end I found that thread / post where they indicated it.

                    In your tests, I understand (and I say I understand because my knowledge in scripting is not very high) you do not have that problem because you have it configured to spin down after a few seconds.
                    If so, it is possible for you to go through it.

                    I have been using hd-idle for a few years, not many, and from the first moment I noticed that, it puts the hard drives in spin down, you access the hard drive, it gets up, and when you stop accessing the hard drive after the time that you have it programmed, they return to spin down, so far fine but .... if you suspend the computer, hd-idle as a service continues to work (it can be seen in KSysGuard) but it no longer takes the hard drives to spin down.

                    As I read it is because the account or internal timer (to put it simply and with my bad memory) fails after suspension.
                    The solution to go through the mentioned patch, it works well for me.

                    As I mentioned, I just hope that hd-idle is still in development and that patch continues to work, in recent weeks I have changed my mechanical hard drives and I have opted for WD, they give me more confidence regarding durability and reliability, more than Seagate (and Seagate supports hdparm -S).

                    Originally posted by jlittle View Post
                    ....
                    [Edit] the drives don't spin down. I'll try the systemd service, though I don't understand how it works.
                    Regarding this, I have not finished understanding, you disabled your script and installed the commented patch and it does not work for you?

                    Comment


                      #11
                      Originally posted by wonder View Post
                      Regarding this, I have not finished understanding, you disabled your script and installed the commented patch and it does not work for you?
                      It does work. I don't understand why restarting the service has the desired effect, though. It looked in /proc before, restarts and looks in /proc again, where nothing has changed. Maybe on a restart it makes different assumptions on starting.

                      However, I don't like that I have to wait 3 minutes for the drives to spin down after a resume, so I'm going to reinstate the script in /lib/systemd/system-sleep.
                      Regards, John Little

                      Comment

                      Working...
                      X