Some CD-ROM devices still wreak havoc when being polled for media changes (see http://bugzilla.kernel.org/show_bug.cgi?id=13783). We do not currently have a way to blacklist particular drives from being polled (the inhibit feature could be abused for this, but isn't particularly well suited for this). We could introduce a new udev property "UDISKS_DISABLE_POLLING" which gets evaluated in info_media_detection() in src/device.c, then we could add something like SUBSYSTEM=="block", ENV{ID_VENDOR}=="Optiarc*", ENV{ID_MODEL}=="*AD-7640S*", ENV{UDISKS_DISABLE_POLLING}="1" David, do you think it's acceptable to introduce this blacklisting feature, even if we don't ship rules by default (so that people can at least locally install them)? I'm happy to work on that change.
Created attachment 33307 [details] [review] Add support for "disable polling" udev property This patch implements this. I tested it with my own CD-ROM (Optiarc DVD+-RW AD-5560A) with a rule like above (also in the git patch changelog), and now I correctly get root 17267 0.0 0.0 46640 876 pts/2 S+ 11:00 0:00 udisks-daemon: not polling any devices OK to commit?
(In reply to comment #1) > Created an attachment (id=33307) [details] > Add support for "disable polling" udev property > > This patch implements this. I tested it with my own CD-ROM (Optiarc DVD+-RW > AD-5560A) with a rule like above (also in the git patch changelog), and now I > correctly get > > root 17267 0.0 0.0 46640 876 pts/2 S+ 11:00 0:00 udisks-daemon: > not polling any devices > > OK to commit? Sure, it's OK if you also update the udisks(7) man page. Thanks! Cheers, David
Hmm, also, it should probably be called ID_DRIVE_DISABLE_POLLING to be in line with the other properties that we use. Thoughts?
Good point, I updated the manpage as well, and actually check the boolean value as well. http://cgit.freedesktop.org/udisks/commit/?id=fb86ef144bad470b3d8ed761c7bdbe94886e5edd
Great, thanks. Also, related to comment 3, I think we should rename all the ID_DRIVE_* properties to UDISKS_*. I don't think it's used outside 80-udisks.rules so shouldn't break too much. Thoughts?
I was going to ask you about the two remaining DKD_PRESENTATION_NAME and DKD_PRESENTATION_ICON_NAME, since those caught my eye when doing the patch. media-player-info does not use them, and I don't see anything else using them either: $ grep -r DKD /lib/udev/rules.d /lib/udev/rules.d/80-udisks.rules:ENV{DKD_PARTITION_SCHEME}=="apm", \ /lib/udev/rules.d/80-udisks.rules: ENV{DKD_PRESENTATION_HIDE}="1" Should be a simple patch, let me know if you want me to just commit that. As for ID_DRIVE_* I don't have a strong opinion. Right now they could potentially be moved into an udev helper. Renaming properties always bears the "breaks backwards compat" issue (for local site rules, anyway), and they have a reasonably generic naming scheme, so they didn't strike me as being urgent to rename.
Support for the UDISKS_DISABLE_POLLING property was lost in udisks2.
(In reply to comment #7) > Support for the UDISKS_DISABLE_POLLING property was lost in udisks2. udisks2 is not concerned with polling at all, we moved that into the kernel (where it belongs). The default udev rules will enable polling.
Previously users could use UDISKS_DISABLE_POLLING to inhibit SMART data updates for hard drives which had a longer spindown timeout than the SMART polling interval (which seems to be 10 minutes). Is there a new mechanism to disable SMART data updates by device?
(In reply to comment #9) > Previously users could use UDISKS_DISABLE_POLLING to inhibit SMART data updates > for hard drives which had a longer spindown timeout than the SMART polling > interval (which seems to be 10 minutes). Is there a new mechanism to disable > SMART data updates by device? Not apart from either turning SMART off (using e.g. hdparm(8)) such that e.g. ID_ATA_FEATURE_SET_SMART_ENABLED will be set to 0 in the udev database.... (a udev rule to set this on the device should work too - that way you won't have to turn SMART off). But even with SMART enabled, udisks reading SMART data should not wake up the disk - in fact, we check if the disk is asleep and avoid reading SMART data if this is so.... if this in turn causes the disk to never go to sleep, I think it may be a problem with the disk sleep timer in question (changing the disk sleep timeout to < 10 min or forcing it to go to sleep could fix it).
Hi, sorry for reopening such an old bug, but I found it via Google searching for my problem and the information in here was very helpful. So I thought it would be a good idea to put this related information here. The problem: The solution explained here is not working for me. I set both variables I found to "disabled": # udevadm info -q all -n /dev/sda |grep SMART E: ID_ATA_FEATURE_SET_SMART=0 E: ID_ATA_FEATURE_SET_SMART_ENABLED=0 But the drive is still polled. I verified it using # udisksctl monitor Distribution is openSUSE 13.1 and udisks2 version is 2.1.1. Any hints what is wrong here? I have a some machines with SSDs for OS and additional Western Digital drives that would be in standby most of the time if udisks wouldn't poll them. Standby timeout cannot be set low enough for the drives. With udisks1 disabling polling was working as described in this bug and I was able to use smartd to check the SMART status, because it is possible to - adjustable polling time and - polling is working on drives in standby without waking them up. cheers, Jochen
Closing again. Polling drives does not apply to udisks2 as for a few years now this is done by the kernel itself. Can I kindly ask you to report a new bug for unrelated issues like SMART updates? Thanks!
It is udisksd reporting 'Error performing housekeeping for drive' 'Error updating SMART data: sk_disk_check_sleep_mode: Operation not supported (udisks-error-quark, 0)' How does the Kernel's polling work? Shouldn't udisks be able to tell the Kernel not to poll a drive then? If that is possible it's probably just a feature request instead of a bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.