prl_disp_service calls up my external hard disk!

J

JayLeeves

Bit poster
When i installed up parallels desktop 7, my unmounted external hard disks wake up in and out of season.

I killed "prl_disp_service" in activity monitor and this phenomenon was gone.

Why parallels 7 deteriorate than 6?

Why parallels.com makes all users beta tester?

Please makes solution for this annoying.

Thanks.
 
prl_disp_service wakes disks every few minutes

Hi,

I experience the same behaviour which I find quite annoying.

Checking with fs_usage I find that prl_disp_service seems to poll every second on this file:

10:46:34.085803 stat ..../Documents/Virtual Machines.localized/Windows 7.pvm/config.pvs 0.000022 prl_disp_service.1099

and every few minutes it wakes all disks with an acces like this:

10:49:33.078079 pread F=68 B=0x200 O=0x00000200 0.000006 prl_disp_service.1242
10:49:33.078463 RdMeta D=0x00000008 B=0x1000 /dev/disk1 0.000378 W prl_disp_servic.1242
10:49:33.078470 RdMeta[async] D=0x00000010 B=0x1000 /dev/disk1 0.000367 W prl_disp_servic.1242
10:49:33.078656 RdMeta[async] D=0x00000018 B=0x1000 /dev/disk1 0.000104 W prl_disp_servic.1242
10:49:33.078807 RdMeta[async] D=0x00000020 B=0x1000 /dev/disk1 0.000104 W prl_disp_servic.1242
10:49:33.078860 pread F=68 B=0x4000 O=0x00000400 0.000779 W prl_disp_service.1242
10:49:33.078908 RdMeta[async] D=0x00000028 B=0x1000 /dev/disk1 0.000064 W prl_disp_servic.1242
10:49:33.078934 close F=68 0.000059 W prl_disp_service.1242
10:49:33.079232 open F=68 (R_____) /dev/disk0 0.000034 prl_disp_service.1242
10:49:33.079239 ioctl F=68 <CMD=0x40046448> 0.000007 prl_disp_service.1242
10:49:33.079247 close F=68 0.000008 prl_disp_service.1242
10:49:33.079265 readlink [ 22] /dev/disk0 0.000005 prl_disp_service.1242
10:49:33.079271 stat /dev/disk0 0.000005 prl_disp_service.1242
10:49:33.079283 open F=68 (R_____) /dev/disk0 0.000012 prl_disp_service.1242
10:49:33.079285 fstat F=68 0.000002 prl_disp_service.1242
10:49:33.080492 fcntl F=68 <CACHING ON> 0.000002 prl_disp_service.1242
10:49:33.082769 RdMeta D=0x00000000 B=0x1000 /dev/disk0 0.002274 W prl_disp_servic.1242
10:49:33.082855 pread F=68 B=0x200 O=0x00000000 0.002363 W prl_disp_service.1242
10:49:33.082862 pread F=68 B=0x200 O=0x00000200 0.000003 prl_disp_service.1242
10:49:33.083140 RdMeta D=0x00000008 B=0x1000 /dev/disk0 0.000273 W prl_disp_servic.1242
10:49:33.083246 RdMeta[async] D=0x00000010 B=0x1000 /dev/disk0 0.000367 W prl_disp_servic.1242
10:49:33.083370 RdMeta[async] D=0x00000018 B=0x1000 /dev/disk0 0.000119 W prl_disp_servic.1242
10:49:33.083513 RdMeta[async] D=0x00000020 B=0x1000 /dev/disk0 0.000081 W prl_disp_servic.1242
10:49:33.083573 pread F=68 B=0x4000 O=0x00000400 0.000709 W prl_disp_service.1242
10:49:33.083629 RdMeta[async] D=0x00000028 B=0x1000 /dev/disk0 0.000070 W prl_disp_servic.1242
10



Please fix. Thanks!
 
Same issue on my system (OS X 10.8.0), the prl_disp_service scans the .pvs files of each of my 9 VMs every other second and is eating a constant 0.7 % cpu on my 2.4 Ghz 15" late 2008 Unibody MacBook Pro. It may look like a non-problem, but I have 144 processes running, if each takes 0.7%, that's 100% cpu. Also, why draining my battery for no reason ? The process should sleep most of the time, and not endlessly scan the same definition files again and again.
Also, in Mountain Lion, prl_disp_service doesn't go down gracefully during shutdown (while it responds okay to a launchctl stop command when I try it), and causes my shutdown time to extend to 45 secs. If I kill it before shutting down, shutdown time is under 5 sec.
Parallels Support, should I open a ticket for this ?
 
I have 10+ external hard drives and prl_disp_service keeps waking them up day and night while my VM is running. It is generating unbearable noise and also wear on the disks. prl_disp_service keeps calling fsgetpath and getattrlist on all the disks, as confirmed with fs_usage -w

Is there any way to prevent this from happening? This is becoming a dealbreaker for me and ruins my experience with an otherwise excellent product.
 
You must log in or register to reply here.
Back
Top