DeviceKit-disks-009-3.fc12 is the latest build intended for F12 GA, can you test that and reproduce?

Yes 

rpm -qa | grep Device
DeviceKit-003-2.x86_64
DeviceKit-power-012-2.fc12.x86_64
DeviceKit-disks-009-3.fc12.x86_64

And unless I manually run --inhibit-polling   CD keeps spinning
(At least on my T61 rawhide installation)

(In reply to comment #0)
> I can stop polling of currently inserted drive by:
> devkit-disks --inhibit-polling /dev/sr0
> 
> 
> However this is not a permanent solution - morever it wait for Ctrl+C in shell.
> Thus I'm looking for a better solution.

I don't know what you mean by "permanent" - this command does inhibit polling the drive. It might not work the way you want it to work though (there are very good reasons that it waits for Ctrl+C to finish).

Your request sounds like a feature request - the ability to edit a config file or something to turn off polling. I've filed it upstream here. Closing this bug as UPSTREAM

https://bugs.freedesktop.org/show_bug.cgi?id=24944

> palimpsest from gnome-disk-utility also doesn't give any options
> for disabling polling of cdrom.

That's because it's not really meaningful to export low-level details like this in the user interface. The fact that we need to poll a drive to detect media changes is more a bug in the transport protocol (see below re SATA AN which is one solution to this problem) - it is inherently uninteresting from a "manage disks" point of view.

And if we wanted to do something like this, it should go into the power manager preferences as a higher level thing - just like we already do for putting disks to sleep when idle:

 http://people.freedesktop.org/~david/gpm-preferences-on-battery.png

E.g. we'd add a

 [x] Don't check drives for media changes

and (maybe) check in by default in the "On Battery Power" tab. But even that is... questionable... most people would probably not understand what it means or make the connection that this saves power.

My view is very simple here: the 1W or so you save by polling drive is not worth it given the hit the user experience takes.

(but I recognize that some users wants full control - hence the upstream bug I filed so you can tweak it.)

> Also I'm quiet interested why there is any disk polling when the
> mechanics knows disk is inserted and none ejected it meanwhile.

I'm not sure I understand this. Two things

 1. Unless we poll the drive, we *don't* know if the media has been
    removed. Yes, it's that bad.

 2. The long term solution here is to use SATA AN (for optical drives)
    and SD (e.g. not USB) for flash media. DeviceKit-disks already
    handles these cases correctly with no polling. Unfortunately SATA AN
    drives are not very common yet.

(In reply to comment #3)
> (In reply to comment #0)
> > I can stop polling of currently inserted drive by:
> > devkit-disks --inhibit-polling /dev/sr0
> > 
> > 
> > However this is not a permanent solution - morever it wait for Ctrl+C in shell.
> > Thus I'm looking for a better solution.
> 
> I don't know what you mean by "permanent" - this command does inhibit polling
> the drive. It might not work the way you want it to work though (there are very
> good reasons that it waits for Ctrl+C to finish).
> 
> Your request sounds like a feature request - the ability to edit a config file
> or something to turn off polling. I've filed it upstream here. Closing this bug
> as UPSTREAM
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=24944

Yes this solution sounds reasonable.
Though how do you want to reinsert new rule for udev when there is mounted driver at the moment of preference changes?
Would not be just some internal persistent devkit flag enough ?

My point is - that current solution for this issue is quite ugly, combined with the fact that old hal daemon is waken every 2 seconds to see that polling is disabled - and then devkit does the same thing but ignores this setting and does not provide replacement option for now.

> 
> > palimpsest from gnome-disk-utility also doesn't give any options
> > for disabling polling of cdrom.
> 
> That's because it's not really meaningful to export low-level details like this

Well it's been just an idea - where I've been look for such flag.
(as quite frankly I'm starting to get lost with options spread everywhere...)



> And if we wanted to do something like this, it should go into the power manager
> preferences as a higher level thing - just like we already do for putting disks
> to sleep when idle:
> 
>  http://people.freedesktop.org/~david/gpm-preferences-on-battery.png
> 
> E.g. we'd add a
> 
>  [x] Don't check drives for media changes
> 
> and (maybe) check in by default in the "On Battery Power" tab. But even that
> is... questionable... most people would probably not understand what it means
> or make the connection that this saves power.
> 
> My view is very simple here: the 1W or so you save by polling drive is not
> worth it given the hit the user experience takes.

My main concern is not the lost 1W (though a lot of kernel developers are happy when they are able to save couple mW) - as I'm running AC mostly, but the noise created by not mounted DVD/CD left in drive - sure I could take it away, or inhibit polling manually - but IMHO its annoying.

>  1. Unless we poll the drive, we *don't* know if the media has been
>     removed. Yes, it's that bad.

Hmm I've thought there is some drive status which could remember that disk is still inside if there was no eject - I've been probably wrong - not being an cdrom expert myself :(

Anyway - the flag for inhibiting drive checking would be just good enough.

There could be also something I'd have call 'lazy evaluation check':
devkit-disks would be polling for disk - once it detects there is one - it would stop polling - when the user tries to mount disk - it will either mount something - or it will fail (user managed to eject disk meanwhile) - in this moment devkit starts polling again - with the assumption the drive is now empty, so no noise from spinning motors would be generated.

Though there is still probably an issue - when some unreadable DVD/CD is inserted - it would most probably keep spinning in this case....

(In reply to comment #4)
> > https://bugs.freedesktop.org/show_bug.cgi?id=24944
> 
> Yes this solution sounds reasonable.
> Though how do you want to reinsert new rule for udev when there is mounted
> driver at the moment of preference changes?

We can't stop polling just because the drive is mounted. This is because unlock the door so the user can press the eject button - even when mounted.

> Would not be just some internal persistent devkit flag enough ?

The problem with this is it won't work well with buggy apps. Suppose there's an app that wants to inhibits polling. It does so by invoking the D-Bus method. What happens if that app crashes or is otherwise prematurely terminated? Well, polling would still be inhibited. That wouldn't be good.

That's why it's implemented the way it is - if the app is terminated then the system message bus daemon notices (since the app is using the system bus) and emits the NameOwnerChanged signal. devkit-disks-daemon notices this and removes the inhibit-polling request. Which means (unless there are other inhibitors) that inhibiting will be stopped and we start polling again.

> My point is - that current solution for this issue is quite ugly, combined with
> the fact that old hal daemon is waken every 2 seconds to see that polling is
> disabled - and then devkit does the same thing but ignores this setting and
> does not provide replacement option for now.

Yeah, right now we're in a transition period where both hald and devkit-disks-daemon polls the drive. Maybe for F13 hald isn't part of the default install and this problem goes away.

> My main concern is not the lost 1W (though a lot of kernel developers are happy
> when they are able to save couple mW) - as I'm running AC mostly, but the noise
> created by not mounted DVD/CD left in drive - sure I could take it away, or
> inhibit polling manually - but IMHO its annoying.

Oh, that sounds weird. Drives *shouldn't* be making noise when polled. If they do it's a weird hardware (or driver) bug.

Are you by any chance using the old IDE drivers instead of libata? If so, there's another fix for it...

(please attach the output of 'devkit-disks --dump')

> >  1. Unless we poll the drive, we *don't* know if the media has been
> >     removed. Yes, it's that bad.
> 
> Hmm I've thought there is some drive status which could remember that disk is
> still inside if there was no eject - I've been probably wrong - not being an
> cdrom expert myself :(
> 
> Anyway - the flag for inhibiting drive checking would be just good enough.
> 
> There could be also something I'd have call 'lazy evaluation check':
> devkit-disks would be polling for disk - once it detects there is one - it
> would stop polling - when the user tries to mount disk - it will either mount
> something - or it will fail (user managed to eject disk meanwhile) - in this
> moment devkit starts polling again - with the assumption the drive is now
> empty, so no noise from spinning motors would be generated.

This won't work because people can just yank the media even when we have mounted bits of it.

> Though there is still probably an issue - when some unreadable DVD/CD is
> inserted - it would most probably keep spinning in this case....  

Or Blank and Audio CDs. The latter is usually not driven by a kernel driver, instead user-space stuff is driving it (such as GVfs's cdda:// backend).

(In reply to comment #5)
> (In reply to comment #4)
> > > https://bugs.freedesktop.org/show_bug.cgi?id=24944
> > 
> > Yes this solution sounds reasonable.
> > Though how do you want to reinsert new rule for udev when there is mounted
> > driver at the moment of preference changes?
> 
> We can't stop polling just because the drive is mounted. This is because unlock
> the door so the user can press the eject button - even when mounted.
> 
> > Would not be just some internal persistent devkit flag enough ?
> 
> The problem with this is it won't work well with buggy apps. Suppose there's an
> app that wants to inhibits polling. It does so by invoking the D-Bus method.
> What happens if that app crashes or is otherwise prematurely terminated? Well,
> polling would still be inhibited. That wouldn't be good.


But if the user wants to inhibit it forever - it would be actually expected...


> > My main concern is not the lost 1W (though a lot of kernel developers are happy
> > when they are able to save couple mW) - as I'm running AC mostly, but the noise
> > created by not mounted DVD/CD left in drive - sure I could take it away, or
> > inhibit polling manually - but IMHO its annoying.
> 
> Oh, that sounds weird. Drives *shouldn't* be making noise when polled. If they
> do it's a weird hardware (or driver) bug.
> 
> Are you by any chance using the old IDE drivers instead of libata? If so,
> there's another fix for it...
> 
> (please attach the output of 'devkit-disks --dump')
> 

Attaching with and without inserted CD.

HW is quite common T61 hw with internal GSA-U10N

> This won't work because people can just yank the media even when we have
> mounted bits of it.

Well if someone does intentionally wrong things to the system, he shouldn't
be expecting that system will provide always valid info.

i.e. you might detect disk - and report it to the system and user will remove disk at this moment - so at the moment GUI will show mountable drive - it will not reflect reality - you have there already those collisions anyway.

BTW as I've observed similar behavior on Toshiba laptop thus I believe it's not T61 specific issue.

Created attachment 367827 [details]
dump with CD in

Created attachment 367828 [details]
dump without CD

(In reply to comment #6)
> But if the user wants to inhibit it forever - it would be
> actually expected...

That's why we should add a way for the user to write an udev rule, hence the upstream bug report.

Since this is the uncommon case, it's fine to require the user to read the udev(7) and DeviceKit-disks(7) man pages and to learn how to write udev rules.


> HW is quite common T61 hw with internal GSA-U10N

> BTW as I've observed similar behavior on Toshiba laptop thus I believe
> it's not T61 specific issue.  

This is weird. Please file a separate bug for this (against DeviceKit-disks) - and also include the 'devkit-disks --dump' info for the Toshiba laptop (if it's available). In that bug, please specify exactly what the sound is and how often it occurs (my guess is every two seconds) - and also whether it happens when only hald is polling the drive. Thanks.

> > This won't work because people can just yank the media even when we have
> > mounted bits of it.
> 
> Well if someone does intentionally wrong things to the system, he shouldn't
> be expecting that system will provide always valid info.
> 
> i.e. you might detect disk - and report it to the system and user will remove
> disk at this moment - so at the moment GUI will show mountable drive - it will
> not reflect reality - you have there already those collisions anyway.

Most users don't really know better (nor should they) - they just yank media be it CD-ROM drives, USB drives, whatever. And as long as they're not using the media, this really should be OK (hence why vfat driver gained the 'flush' option) - if they're pulling media when it's being written to they get what they bargained for (e.g. half-written files or, for CD-R, a coaster). So we really need to properly cope with situations like this.

FWIW, Windows and OS X also polls the drives.

The main problem here is that your drive is noisy when being polled. This suggests we are doing something wrong when polling the drive.

Btw, HAL has this rule that links to bug 138148 which may be related - at least it also concerns HL-DT-ST drives.... Anyway, let's work on that in a new bug (as requested in comment 9).

    <!-- Handle weird Dell Laptops that slow down the system if the optical
        drive is polled (RH Bug #138148) -->
    <match key="storage.bus" string="ide">
      <match key="storage.model" string="HL-DT-STCD-RW/DVD-ROM GCC-4240N">
       <match key="block.device" string="/dev/hdb">
          <merge key="storage.media_check_enabled" type="bool">false</merge>
       </match>
       <match key="block.device" string="/dev/hdd">
          <merge key="storage.media_check_enabled" type="bool">false</merge>
       </match>
      </match>
    </match>