Announcement

Collapse
No announcement yet.

UDisks 2.7 Released, Migrates To Libblockdev

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by RickXy View Post
    I hope liblockdev is scoped beyond Anaconda.
    It definitely is, to UDisks2. One of the reasons why libblockdev was created was to make things it implements less installer-specific. But feel free to judge it yourself -- http://rhinstaller.github.io/libblockdev/

    Comment


    • #12
      Originally posted by andreano View Post
      Udisks2 is kind enough to let them stay spun down once they are. The problem is only that they never spin down if you set a longer spindown timeout (e.g. hdparm -S 240 /dev/sdx for 20 minutes) than Udisks2's irritatingly short poll interval (something like 10 or 15 minutes IIRC). What is it polling for anyway? I want to patch it to infinite – I have no use for you whatsoever thankyouverymuch Udisks2!
      Hmm, my drives in the enclosures have no issues in spinning down after 10 mins, they are Seagate 1.5 TB drives, of the first or second gen, (they are high, many platters) and heat like a campfire. They need to stay in a special enclosure with active fan or they heat-kill themselves.

      You can disable the SMART checking and change other udisks-related behavior (like spindown timeout) from gnome-disks. Select the drive, click on the hamburger button (three horizontal lines) on top right on the bar, click "SMART data and self-tests", and then there is a big switch on the top right of the new window.
      Spindown timeout and other stuff is available through "drive settings" which is found under the option "SMART data and self tests"

      Also on OpenSUSE there are global settings for SMART polling through smartd in Yast. Look in the sysconfig editor Hardware -> SMART (seems to be set for 30 mins so it might not be the culprit)

      Comment


      • #13
        Originally posted by starshipeleven View Post
        Hmm, my drives in the enclosures have no issues in spinning down after 10 mins, they are Seagate 1.5 TB drives, of the first or second gen, (they are high, many platters) and heat like a campfire. They need to stay in a special enclosure with active fan or they heat-kill themselves.
        You will not see the problem because 1.5TB seagate first and second gen don't class checking smart as disc activity as ATA design specification states. Reducing freq of checking smart increased the odds that smart issues will not be detected early. Udisk actions at times results checks smart to see if drive is a sleep or awake. Specification for make drives say you are meant to check that way. Modern to standard drives should not show the issue.

        Comment


        • #14
          Originally posted by oiaohm View Post
          Reducing freq of checking smart increased the odds that smart issues will not be detected early.
          I know.
          I just posted how to change settings so he could work around his problem by disabling SMART checks on the problematic drives (gnome disks allows to disable udisks SMART checking on specific drives).

          Comment


          • #15
            Originally posted by starshipeleven View Post
            Also on OpenSUSE there are global settings for SMART polling through smartd in Yast. Look in the sysconfig editor Hardware -> SMART (seems to be set for 30 mins so it might not be the culprit)
            Indeed, mine is also 30 mins, so that doesn't explain why my disks won't spin down with a 20 min spindown timeout.

            Originally posted by starshipeleven View Post
            click "SMART data and self-tests", and then there is a big switch
            That unfortunately disables SMART altogether.

            Comment


            • #16
              Originally posted by oiaohm View Post
              Pure misunderstanding of what udisks2 does. Udisk2 does not poll the hard drive any more—the kernel does. When udisk2 requests current smart data, the kernel goes and gets it.
              (I fixed your English, man. Pure misunderstanding of English. It's not my first language either.)

              Kernel does the polling? That's not consistent with my empirical results.

              How do you then explain that my disks spin down after their designated timeout if I:
              * Don't install Udisks2
              * Stop/kill the Udisks2 daemon
              * Freeze the Udisks2 daemon (sudo pkill -SIGSTOP udisksd)

              The third is actually a usable workaround, as they don't spin up again when you unfreeze the Udisks2 daemon (sudo pkill -SIGCONT udisksd), unlike restarting it. It's just impractical having to unfreeze it so often—all open/save dialogs in KDE, as well as the KDE startup, will mysteriously hang, waiting for you to unfreeze udisksd.

              Testing this again, I noticed that my newest SATA harddisk actually spun down while udisksd was running, while my 2 IDE harddisks didn't. I used to have another 4 harddisks with this problem: One IDE harddisk I threw away because it was old, and 3 SATA harddisks that are now semi-dead. …No wonder why I trust older harddisks more.

              Congratulations Udisks2, for finally working as advertised, for 1 out of 7 harddisks have/have had. You're still making paperweights out of most of them. I have no reason to doubt they are out of spec, but that seems to have been the norm until a few years ago.
              Last edited by andreano; 06-18-2017, 10:02 AM.

              Comment


              • #17
                Originally posted by andreano View Post

                (I fixed your English, man. Pure misunderstanding of English. It's not my first language either.)

                Kernel does the polling? That's not consistent with my empirical results.

                How do you then explain that my disks spin down after their designated timeout if I:
                * Don't install Udisks2
                * Stop/kill the Udisks2 daemon
                * Freeze the Udisks2 daemon (sudo pkill -SIGSTOP udisksd)

                The third is actually a usable workaround, as they don't spin up again when you unfreeze the Udisks2 daemon (sudo pkill -SIGCONT udisksd), unlike restarting it. It's just impractical having to unfreeze it so often—all open/save dialogs in KDE, as well as the KDE startup, will mysteriously hang, waiting for you to unfreeze udisksd.

                Testing this again, I noticed that my newest SATA harddisk actually spun down while udisksd was running, while my 2 IDE harddisks didn't. I used to have another 4 harddisks with this problem: One IDE harddisk I threw away because it was old, and 3 SATA harddisks that are now semi-dead. …No wonder why I trust older harddisks more.

                Congratulations Udisks2, for finally working as advertised, for 1 out of 7 harddisks have/have had. You're still making paperweights out of most of them. I have no reason to doubt they are out of spec, but that seems to have been the norm until a few years ago.
                The first specification of smart stated that requesting smart information should not register in the drive as actively. So drive should spin down any that don't in fact don't have smart implemented correctly and you have to wonder what else in firmware is wrong. So IDE and Sata drives should power down has hardware instructed no matter if smart information requests are put to them.

                Udisks2 is checking sections smart status that should not keep a drive spinning. So only 1 out of the 7 drives you have in fact work to specification. Also there is a nightmare in first generation drives with smart the OS is required to check smart regularly because drive was not mandated to store a log of issues this is why checking smart should not effect drive power down.

                So the issue is there is not an effective way to blacklist devices with defective smart implementations. You can not go by age because first generation you need to poll every 10 mins or their in memory log can overflow.

                Here is the most stupid thing about this. The value smart value udisks2 is checking regularly is sk_disk_check_sleep_mode. Yes how you formally question a drive if it asleep or not. So andreano checking if a drive is a sleep or not should not result in drive staying awake longer. Worst part about this is about this is sk_disk_check_sleep_mode should work if smart is enabled or disabled. Some of the bad drives work fine in smart disabled mode even that udisk2 is still checking sk_disk_check_sleep_mode every 10 or so mins.

                So like it or not this problem is broken hardware. Broken hardware should have functional blacklisting in kernel so that nothing user space can cause hardware with faults like this to play up. Yes udev rules have smart on smart off and but not smart don't check if the drive is a sleep because this drive is an idiot.
                ID_ATA_FEATURE_SET_SMART and ID_ATA_FEATURE_SET_SMART_ENABLED neither effects if drives sleep state will be probed by smart. Please note you go to suspend system the Linux kernel will check sk_disk_check_sleep_mode to make sure drive is asleep before going to sleep itself. Now the bug you hardware has can be causes of suspend hang as well..

                Comment


                • #18
                  Originally posted by bkor View Post

                  You'd want the flush option, not sync/nosync.
                  that's correct. in my defense- it was a while since i've mounted anything manually.

                  vpodzime :
                  if I remember correctly, when I've reported this bug in ubuntu's bugzilla, I was directed to udisk. or, more correctly, it was the thing blamed for it.
                  i cannot seem to find the exact bug report (it was few years back), but it still happens (i.e. that bug) in both gnome and kde.

                  Comment


                  • #19
                    Originally posted by vpodzime View Post
                    It's updating the SMART data so that any potential signs of failure are caught early. The interval should be configurable I think. Could you please create a GitHub issue for this at https://github.com/storaged-project/udisks/issues ? Thanks!
                    Thanks for pointing me in the right direction! Just to check that I haven't "completely misunderstood" this, I am experimenting with adjusting the "housekeeping_timeout", which indeed is hardcoded to 10min. The good news is … I got my disks to spin down. Myth confirmed. The bad news is that it takes more time than I expect, so there appears to be more to it than my current understanding.
                    Last edited by andreano; 06-24-2017, 06:01 PM.

                    Comment


                    • #20
                      Originally posted by vpodzime View Post
                      Could you please create a GitHub issue for this at https://github.com/storaged-project/udisks/issues ? Thanks!
                      Finally I did! Thanks for the link ;-)
                      https://github.com/storaged-project/udisks/issues/407

                      Comment

                      Working...
                      X