Slow Disk Write Speed vs Expanding Disk Option

M

MatthewS9

Junior Member
Observed on my machine that disk write performance in Windows 10 1709 (particularly when saving files), consistently had up to a 1/2 minute delay before actually writing to disk.

After changing the disk from Static/non-expanding to expanding, the lag time is no longer noticeable. Is this expected behavior? I thought it would be less efficient.

Host:
MBP13 Late 2016

VM:
Windows 10 CE 1709
Ram: 3,072
Disk: 80GB

Thanks
 
Arun, yes the problem noticed exists when saving a file from Windows to Windows, and from Windows to a MacOS shared folder. Can also be duplicated by running/loading a file from a MacOS shared folder.

Note: Trim is enabled on the Windows 10 storage volume.

Thanks
 
I currently have 190GB free out of 500GB Total space on the built in MacBook Pro SSD.

MacOS High Sierra 10.13.2
 
-- Edit --
I apologize, needed to do more testing to define the problem accurately. Had a page file stored on a shared macOS folder that Windows 10 was accessing. The problem is not related to Expanding Disk or Static Disk size but the network interface between Host and Guest sharing folders - specifically to and from MacOS High Sierra and Windows 10 1709 Base.

My problem is with the the lag time in initializing a read or write operation via a shared Host and Guest OS folder.

Can duplicate the problem by sharing a folder from macOS to Windows 10 (and then accessing that folder via Windows 10 to duplicate initial R/W lag). Also I can duplicate the R/W lag by accessing a Windows 10 shared volumes via macOS.
 
Last edited:
MatthewS9, I have a similar issue with laggy read/write from Windows 10 (1709) running on PD13 (latest build). The Windows is unusable.
It often pops up with a message "Waiting for network \\Mac\Home" when I save something to the shared mac folder.

Do you have any solution for this?

I have the Latest MacBook Pro 15'' with Touch Bar, with FileVault enabled.
 
Perhaps one of the more experienced guys can jump in here to explain how Parallels works with Mac <--> Windows 10 CE.

A couple of settings I messed around with to try and resolve my problem were, the network adapter and type, and adaptive hypervisor.

1) Shared Network to -> Default Adapter (it was my thought that Parallels may communicate shared OS folders via network protocol), and Adapter Type: Intel Pro/1000 MT
2) Turned off Adaptive Hypervisor

It seems either the sum or one of these settings may have lowered the initial R/W delay when accessing the other OS files/folders.
Have not had much time to experiment, so these are all still hypothesis being tested at this time. If you find out anything please keep me posted.
Main problem was with programs accessing config files stored on the other OS shared folder.
The best solution/workaround I have found at this time, is to not store files that will be accessed frequently in the opposing OS.

Hope this helps, as I have not heard anything back from Parallels support regarding this matter.
 
Last edited:
Note: Extensively tested FileVault enable/disable ~ minor performance decrease with it on, but no change in initial R/W lag time issue mentioned.
 
Hi. Just to make, that we are on the same page, the issue, that you are reporting, refers to different IO performance for a file residing on a Virtual HDD of VM, and a file residing in MacOS, which is made accessible to guest VM via the Parallels Desktop shared folders feature? If it so, it is expected to an extent due to the fact, that shared files are exposed via a networking file system, which implies harsher synchronization requirements. AFAIR, the particularly expensive operations are reading the directory contents or file attributes, since those are always performed from the scratch. However, could you please clarify the tentative size of the lag, that you are experiencing?
 
Thanks Arno1. You are correct we are on the same page, the issue is the difference in IO performance for a file residing on a virtual HDD of a VM and one residing in the MacOS - accessed by Parallels. Thank you for clarifying that well. If I understand correctly, this is standard operating behavior. As for the 'lag' time, I have yet to quantify the delay (I have not had the time pun maybe/not intended). The two most noticeable lag times are perceived when installing an application on Windows 10 from a shared MacOS "Downloads" folder. The second one is when running a Windows 10 disk cleanup - when compared to other VM platforms (w/ cloned HDD for VM instances).

It seems that for a Windows application that calls a json config file often from a shared MacOS directory, the delay can be long enough to crash the windows application. The app checks the config file every 10sec.
 
Last edited:
I have checked the first scenario, that you have described (launching an installer, which size is 600Mb): it takes 2-3 seconds from launch to UAC prompt and yet another 2-3 seconds till the installer window appears. Tentatively the same time is taken on a clean Windows 1709 installation regardless from where it is launched. Perhaps, the behavior might be different for a non self-extracting installer, which consists of a handful of files.

If you have any antivirus software installed in Windows or OS X, it might impact access times by performing the realtime checks.

With regards to the delay, that can be long enough to crash the windows application, it does not sound right. Suggest generating a Problem Report/Send Technical data (http://kb.parallels.com/en/9058) after such crash, submit it and post its ID in this thread. I believe, that it is worth to be checked. However, I am not sure, that it would be possible to factor out an issue right away.
 
Arno, thanks for the information. still checking,... after the most recent upgrade 13.3.0 (43321) I have not be able to duplicate the 'R/W delay with the json config file residing on MacOS and the program residing on Windows10, Windows 10 disk cleanup runs quickly vs previous upwards to 30min delay, also installing an application to Windows 10 from a shared MacOS 'downloads' folder is no longer present.

Parallels Desktop Pro Version 13.3.0 (43321)
 
You must log in or register to reply here.
Back
Top