No delays. It was so fast that my script didn't succeed to attach strace to the newly started udisks-daemon before all interesting
operations were already completed.
Also nautilus no longer spawns a mount command, which used to hang around for 18 minutes.
Boot / first login appear quicker to me. But I have never measured or traced them, so I can't tell for sure.
Overall, it looks good to me.
udisks --dump reports now
> has media: 0
> detects change: 0
So probably somebody who has a fd drive needs to test whether the fd can still be mounted.
> I uploaded the patch to lucid-proposed,
I can't see it in lucid-proposed.
> now needs to be ack'ed by another member of the SRU team.
until it gets visible in lucid-proposed or until it moves from lucid-proposed to lucid-updates??
Anyway, I tested the version from Martin's PPA.
I tested this case from comment #98
> Likewise, it's interesting to check whether a mere
>
> sudo killall udisks-daemon
> udisks --dump
>
> triggers floppy access.
Before:
21:02:08.497792 open("/dev/fd0", O_RDONLY| O_LARGEFILE) = 12 O_LARGEFILE) = 12
21:02:21.577944 close(12) = 0
...
21:02:21.659020 open("/dev/fd0", O_RDONLY|
21:02:34.722302 close(12) = 0
I.e. 13 + 13 secs of delay
After:
No delays. It was so fast that my script didn't succeed to attach strace to the newly started udisks-daemon before all interesting
operations were already completed.
Also nautilus no longer spawns a mount command, which used to hang around for 18 minutes.
Boot / first login appear quicker to me. But I have never measured or traced them, so I can't tell for sure.
Overall, it looks good to me.
udisks --dump reports now
> has media: 0
> detects change: 0
So probably somebody who has a fd drive needs to test whether the fd can still be mounted.