Major performance (I/O?) issue in /mnt/* and in ~ (home)

[Mika56]

A brief description

As a Symfony developer, it's always been hard to get a stable/fast development environment. My current setup is a Ubuntu running under VirtualBox (using vagrant). While page generation is fast, my IDE accesses my PHP files through SMB, which is really (sometimes horribly) slow.
I'm now trying to use WSL to improve all of this. However, I'm having a major performance issue when using /mnt/* folders.
If I set up a Symfony project under /mnt/c, it is really slow. If I set it up under /home/mikael, it is very fast.

Expected results

Drives mounted under /mnt should be as fast a any other folder.

Actual results

With a new Symfony 3.1.3 project, under /home/mikael takes between 100ms and 130ms to generate the home page.
The same project under /mnt/c/ takes between 1200ms and 1500ms.

Your Windows build number

10.0.14393.51

Steps / commands required to reproduce the error

# Install PHP5
$ sudo apt-get install -y php5 php5-json

# Download Symfony installer
$ sudo curl -LsS https://symfony.com/installer -o /usr/local/bin/symfony
$ sudo chmod a+x /usr/local/bin/symfony

# Download Symfony
cd
symfony new symfony_test

# Start Symfony
cd symfony_test
php bin/console server:run

Open your browser and go to http://127.0.0.1:8000/.
Once the page is loaded, refresh it (on first request, Symfony had to generate its cache).
Generation time is displayed on the bottom left

You can then do the same under /mnt/c/

cd /mnt/c/
symfony new symfony_test
cd symfony_test
php bin/console server:run

Additional information

I've added my dev folders as excluded folders in Windows Defender, as well as %LOCALAPPDATA%\lxss.
I've tried having my project in ~ and pointing my IDE to %LOCALAPPDATA%\lxss\home\mikael\ but as I've later read, there is no supported way of editing WSL files.
WSL is installed in its default location under C (no strange junction or symlink), which is a healthy SSD.
My computer is attached to a domain, if this might have any influence.

[fcicq]

with the current design of DrvFs, I guess this problem is hard to resolve. I recommend you to run a ssh server inside WSL and do the edit via ssh to bypass some other issues.

from https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/
"DrvFs also disables directory entry caching to ensure it always presents the correct, up-to-date information even if a Windows process has modified the contents of a directory."

[fpqc]

Also @Mika56 the devs have said they are working on improving performance by redesigning parts of how file I/O works. That's probably why they haven't documented exactly how it works yet, since it is very much in flux at the moment.

[ajaykagrawal]

there is no supported way of editing WSL files

I wonder how difficult it would be for popular IDE and text editors to become WSL aware and preserve the attribute of WSL files (the security model may have some inconsistencies but I might be ok with it)

[fpqc]

@ajaykagrawal Some text-editors have an ability to save in-place rather than overwrite. I heard someone say that they enabled that setting in one or another text editor and it worked.

[ajaykagrawal]

Thanks @fpqc. I don't quite know what save in-place means but I hope more editors are updated to have this ability

[Mika56]

@fcicq I'm using an IDE for a reason :) I need my IDE, and mounting a folder through SSH, FTP, SMB or whatever would be no improvement on my current environment

[fpqc]

@ajaykagrawal Basically instead of writing a new file and saving over it, the text editor has a delta and applies it to the file, at least that's my guess.

[aseering]

In the old days, whenever you hit "save", text editors saved into your existing file. This was simple and efficient, but if your editor crashes or was killed mid-save, or if you run out of disk space, or if anything eelse weird happens, you might end up with a corrupt garbled mess that's half the old file and half the new file. Or it might just be completely empty / wipe out all of your data entirely, if your app implemented "save" with an initial truncate, which is easy to do by default on Linux at least.

These days, text editors almost always "save" by creating a temporary file in the same directory, writing the entire new file contents to the temporary file, and then moving the temporary file on top of the old file, overwriting the old file in the process. "Move" within a directory is guaranteed in most cases to be strictly atomic -- even if your computer loses power mid-Move, you'll always be left with either the new file or the old file; not a corrupted intermediate.

Clever, right? Saves lots of "I lost my data!" headaches. Thing is, if an application creates an arbitrary new file, there's no way for the OS to know that it's supposed to have the same magic permissions as some other existing file. That's what's breaking WSL.

Some editors let you go back to the old-style behavior. Has more risk, but avoids issues in some situations.

[fpqc]

@aseering it looks like Windows move preserves those attribs, or at least robocopy does?

[aseering]

Read more carefully: It does an excellent job of preserving the attributes of the wrong file :-)

[EDIT] I can't speak for robocopy, just regular move, but what you want in this scenario is the opposite of what you want in most scenarios.

[fpqc]

@aseering yep I am aware. I just thought that Windows commandline tools preserve even hidden ntfs attributes (moving is different from editing a file, since the atomic operation is done at the filesystem level, I think) like robocopy does.

[aseering]

@fpqc -- ah, I see what you're getting at. Yeah, applications can copy extended attributes, if they're programmed to do so correctly.

[Adraesh]

Exactly the same "issue" detailed above, as I am as well a Symfony dev.

My SF projects are all located into /mnt/d/.... my apache2 server (running on ubuntu bash) root folder is linked using a symlink and the perfs are aweful ...

This also lead to some issue with Symfony cache system btw.