Shared folder performance on vagrant

performance

(Ted Lilley) #1

I just want to pull this topic out of the earlier topic. On the Mac, you can use NFS sharing to get over the poor performance of shared folders with the vagrant box. On Windows, though, I’m stuck.

The best workaround I’ve got so far is to rsync my changes in and out of the vm so I can work in a local folder in the vm. That’s performant, but it’s annoying and seriously error-prone.

I’ve searched google quite a bit and come up short as to any better solution. If someone finds one, I’d love to see it posted here. This is a daily thorn in my side.

Edit: I tried to use discourse’s Reply in New Thread feature to link to the earlier topic on slow development performance, but apparently I failed. It said I had a post in progress from an earlier Reply in New Thread (which I had finished and posted). Clearing it out and doing this post failed to establish the link I guess.


Super slow loading on Windows using Vagrant (Ubuntu VM)
Development mode super slow
(hamburglar) #2

Did you happen to try samba? I hate setting it up and it is unfortunate that it’s necessary, but I bet it will be a lot faster.


(Charles Roper) #3

Not sure if they’re be fast enough for you but ExpanDrive or SFTP Net Drive are options.

I generally use Sublime Text with the SFTP package set to upload on save. When used on a local VM or even on a VM on the same LAN, upload times are near instantaneous. I also hook-up WinSCP to Keep Remote Directory Up-to-date which can be scripted and configured in some details.

I like the SSH/SFTP workflow because it allows me to run a number of VMs at home on my LAN but also, through use of an Apache reverse proxy, connect to them from remote locations. So I get the flexibility of a remote server, plus the speed of local when I’m, well, local. And SSH/SFTP is always so much easier to setup than Samba.


(Ted Lilley) #4

No I haven’t, but the reports I’ve read said that it’s not as reliable as NFS for this purpose, so I’m loath to go to the effort of setting it up just to be disappointed. I’m pretty uncomfortable with what I’ve got though, so I may break down at some point. Some positive experiences from others would go a long way.


(Ted Lilley) #5

I think I’ll break down and go with dropbox in the vm. I have a small dropbox account set up just for projects that I want on my vms, so it’s not too bad to download the whole bunch, and I share the folder into my regular dropbox account for my desktop.

Dropbox has good instructions on how to load it up and there’s even an upstart script to load the daemon during bootup.

The usually annoying thing with signing up for another dropbox account is having to do so from another email address, but they actually let you use a gmail trick that still goes to your same email account. You can add “+” and any arbitrary text after your email name (before the @) and it will go to your regular mailbox. You can use the same trick to register with various web sites (add their name after the +) so you know when a site has lost or sold your email address.


(Charles Roper) #6

Dropbox is slow too. It takes a few seconds for the local client to register and upload the changes and a few seconds more for the VM to then bring those changes in. There’s not a massive delay over a LAN, but it’s there and it’s frustrating. That’s why I use SSH. I also use LiveReload, so updates need to be near instant in my case - if you’re happy with a couple of seconds delay for Dropbox to do its thing, then that may be better for you. It still sounds more of a pain to set up than simply using SFTP Net Drive though, which is free and easy to install on the Windows side.


(Charles Roper) #7

I took some timings of various scenarios. Note, this isn’t Discourse source, but it’s a large-ish project with plenty of files in, so should give some ideas.

So that suggests there’s a big tax on going through Samba. Shared folders have a significant lag. Windows native, even on an SSD, is also a bit slower than the crisp performance on native Linux (even in a VM hosted on a non-SSD machine).


(Ted Lilley) #8

I’m curious, have you tried Swish on Windows? I’m interested in how it compares with the Netdrive you mentioned.

Thanks for the tips.


(Charles Roper) #9

No, I haven’t. Their one and only FAQ item kind of put me off, so I never tried it. Have you? SFTP Net Drive allows you to map a network drive. To be honest, though, I’ve not found either ExpanDrive or SFTP Net Drive satisfactory. The former I can’t get working through a proxy or SSH tunnel, while the latter feels brittle, slow and opaque when used remotely. Even when on a reasonably fast connection, file access feels like molasses and because there is no feedback on-screen, you never know if it’s hung or whatever. Plus, Sublime scans the whole directory structure when opening a project, so that’s a real slowdown too. I’ve not tried it using a local VM. Might do that later.


(Charles Roper) #10

I’ve just tried using SFTP Net Drive to connect to my local VM (i.e. running on the same machine) and I’m impressed. It’s seamless. Fast and robust(-ish) as far as I can tell. In use it feels no different from a normal local drive. Sublime was able to open the Discourse project and make use of its fuzzy search without any noticeable difference from a local project. I’m pretty amazed by that actually. Git operations on the drive are slow ~10 secs for a git status vs ~0.3 sec within the VM, but that’s no big deal - just do the file intensive stuff in the VM.

And you don’t get the shared folder tax.

Some tips for getting it setup:

Make a copy of the /vagrant folder into your home drive:

$ cp -R /vagrant ~/vagrant

SFTP Net Drive setup (note the key file):

image


Development mode super slow
(Ted Lilley) #11

Thanks again for all of the helpful tips.

I think I may have a winner for the model I’m going to use. SFTP looks like a real solution. For my purposes, I’m going to combine it with Dropbox and rsync/lsyncd, shared folders and sftp net drive. I wish there were something more elegant, but there you go.

So when I need to develop, for the most part I do it in the vm. Git shell support is better, I’m using vim which feels as good in ssh as it does local, and sometimes I’m remote on a Chromebook so I have to do it in ssh there, it’s not a choice. Making the vm the center of operations in my day-to-day is fine then. If I’m working with a repo, I don’t even need to start off with it on the host and copy it in, I can just clone it straight into the vm.

However, I have multiple machines that I’m usually working with the code from. I don’t like using git to sync partly-done work, so Dropbox is my solution there. On a sidenote, there are definitely some things you have to do to get a vagrant project working correctly when shared via dropbox, but I won’t get into that here. In order for Dropbox to sync my wip (work in progress), it has to make it out of the vm. This is the part that I want automated, I don’t want to have to remember to sync work in and out.

So when I’m working in the vm, I’m going to try using lsyncd to sync my changes out to the shared folder. This looks great because it’s a background process and it’s efficient. It uses inotify to know when to run, it batches up changes every 20 seconds and it only feeds rsync the list of changed files, so rsync doesn’t have to compare the whole directory tree (which is very intensive on the cpu).

Dropbox will pick up those changes and sync them to my other machines. This may be slow, but doesn’t matter since it’s not in the development process, it’s just so the files are there when I relocate to another machine.

However, these files do need to make it inside the vm on the other machine, which is where this falls down hardest. I’m thinking of using sftp net drive with a file sync program like winmerge or freefilesync to get the files in. I’m a bit concerned about this kind of intensive filesystem usage, but we’ll see how it goes. It’s ok with me that it’s manual since lsyncd will keep things in sync once it’s in the vm. The combination of lsyncd and dropbox gives me a canonical shared copy of my project that can always be trusted when I switch machines, which is what I care most about.

If I have problems with winmerge/sftp net drive, I’m pretty sure that winscp will do the job too.

The only other thing is that I wish to be able to use windows apps to work on the files occasionally. Since I have lsyncd making the vm the locus of work, I need to make those files available to my applications (not the host’s shared folder copy). That’s where sftp net drive comes in, as I’ve mentioned. That’s also why I’m looking at sftp net drive rather than winscp, since I can’t work on the files remotely to the vm with winscp. If I care to run a specialized windows tool like my xml editor, winmerge or a text editor other than vim, I can edit the file through sftp net drive and lsync will pick up the change and push it back to the shared folder.

It’s a little byzantine, and I wish that shared folders didn’t have these performance issues, but this is the best thing I can think of to solve it.

Here’s my lsyncd config and an upstart script for it:

Edit: I’ve since determined that in my usage model, where I’m periodically using an rsync command to bring changes into the vm (when I do work on the outside, in the shared folder), it doesn’t make sense to have lsyncd be started in the vm automatically. So I’ve switched to a manual start for lsyncd, still using the upstart script but starting it with the command line sudo start lsyncd. I usually shut down the machine when I’m finished, but if I don’t, I have to shut down lsyncd manually before I rsync my changes from the outside into the vm. I’ve changed the upstart script below to reflect this manual mode of starting.

Why? So here’s my model again: Develop in a vagrant vm at work. I use a local folder in the vm for speed. Any changes get synced out to the shared folder automatically by lsyncd, but not in the other direction.

Then, stop working at work (usually shut the machine down) and go home. The shared folder, which has my latest work exported from the work vm by lsyncd, is synced to my home machine by Dropbox. At home, I have another vagrant vm that is not yet started, in which I want to continue my work. If lsyncd on that machine starts automatically with the system, it does an “initialization sync” where it takes the contents of the local folder as canonical and syncs it out to the shared folder, the one that has my changes from work. If this were successful, it would overwrite my work which would then be lost. Obviously, moving from home to work presents the same issue in the reverse direction.

Fortunately I haven’t lost any work in this manner because so far, lsyncd has tried to come up before the shared folder is actually made available by vagrant, but that’s just a problem waiting to happen. So the right answer is to not bring up lsyncd automatically (nor even leave it running once I’m finished with the vm for a while) . I have to bring the vm up, rsync my changes from the shared folder into the local folder with rsync, then bring up lsyncd.

Ay caramba, it’s a pain in the tukhus, to mix ethnic colloquialisms. But it’s better than the sllloooowww performance of shared folders.

~/lsyncd.lua:

settings = {
  logfile = "/home/vagrant/lsyncd.log",
  statusFile = "/home/vagrant/lsyncd-status.log",
}
sync {
  default.rsync,
  source = "/home/vagrant/vagrant",
  target = "/vagrant",
}

An upstart config from this article.

/etc/init/lsyncd.conf:

description "lsyncd file syncronizer"

# start on (starting network-interface
# or starting network-manager
# or starting networking)
 
stop on runlevel [!2345]
 
expect fork
 
respawn
respawn limit 10 5

exec /usr/bin/lsyncd /home/vagrant/lsyncd.lua

(Charles Roper) #12

Nice. I’ve been wondering whether there was something like lsyncd for doing just what you describe. You’ve just saved me a bunch of work - thanks!


(Ted Lilley) #13

Much like the hokey-pokey, that’s what it’s all about. :wink:


(Ted Lilley) #14

Two other issues with syncing to the shared folders (in addition to my edits above).

The first is line endings. When I happen to do something with my files on a Windows box, then in my linux vm git thinks the files have been modified if they have Windows line endings.

You can just checkout a fresh copy of the files (git checkout -- .), but only if they’re unmodified in other ways, i.e. you haven’t done any work which you want to keep. If you do have work in their with the line endings, you’ll lose it this way, which is bad.

So usually I just make sure that I’m committing my work if I’m changing platforms. Git handles the line-ending conversion by default and everything is happy. I can use git checkout -- . on whatever platform I’m on if the changes are in the repo. You just have to remember to do the commit first. I’m fairly sure you can even do this on linux with the Windows line endings since it should know to strip them out there as well, but I’m less sure of this since I haven’t tested it.

The other issue is file modes. For whatever reason, the shared folder seems to always expose the Windows files with mode 777. Thus if I rsync them into the vm, they all change mode and that shows up as a git change.

I wish I knew how to modify this virtualbox/vagrant behavior, but I’ve made do by telling git to ignore file mode changes with core.filemode=false. Unfortunately, this gets set to true automatically whenever you use a filesystem which supports chmod, which is always the case unless you’re on FAT. So you have to go into .git/config in your repos and set it to false on every repo. C’est la vie.

This way, even if the file mode on the file changes due to an rsync, it at least won’t register as a change to a tracked file in git, so the mode will never be modified even if the file contents change. However, you have to be careful adding new files, since their mode will be tracked when you add them. If the file mode is wrong then, you have to set filemode back to true and change the mode manually.

Sigh.


(Ted Lilley) #15

After rereading this all again, I think I’ve come to the realization that the small, secondary dropbox account just for syncing vagrant projects is the way to go. It handles all of these concerns except the line-endings. There’s a slight redundancy of copying all of my projects into each project vm when one project would do. However, that’s amply paid for by the convenience of dropbox compared to the solution I’ve just laid out above.

Vagrant shared folders between a windows host and linux vm just don’t work for me.

Of course, it’s less than optimal if you’re trying to work in the windows folder and have your changes immediately get reflected in the web app running from the dropbox folder in your vm, but that’s not how I work. I’m always in the vm, so dropbox’s speed only matters when I first fire up my home vm after leaving work. I can deal with that initial sync time since it’s not ongoing while I work.


(James P) #16

I use vagrant for non-Discourse things, and I just installed the GUI and do all of my development using SublimeText 2 inside of the VM. There was really no real reason for me to use Windows, as I wasn’t overly attached to my IDE and was thinking about ST2 anyhow.

VM runs fullscream on my 24" monitor, and I use my smaller, 20" monitor on the side for Windows stuff as I need.

These vagrant shared folder problems are widespread with no real solution (other than use vmware)


(Ted Lilley) #17

I actually work inside the vm as well, but want Dropbox to sync between home and work. Windows was my mechanism for doing so, but now I’m using Dropbox in the vm with a small, dedicated Dropbox account.


(Wojciech Zawistowski) #18

Has anybody tried using a 3rd party NFS server like e.g. FreeNFS on Windows? It looked like a promising solution, but I can’t make it work. I don’t know if Vagrant doesn’t support NFS on Windows at all, or do I configure something incorrectly…


(Sam Saffron) #19

What is the problem with doing the reverse setup, you keep your source on your linux VM and then create an SMB share back to your windows box. It works perfectly for me, can not think of any issues.


(Wojciech Zawistowski) #20

I see 3 issues with reverse approach:

  1. I like to use external, graphical Git tools like TortoiseGit or gitk to check diffs or commit graphs - their performance is very poor over smb
  2. With reverse approach source files are on VM instead of host, so there is a small chance to lose work in progress when I accidentally destroy VM or if e.g. VirtualBox crashes
  3. This is not a “canonical” solution. When you install according to your official installation guide, you just git clone / vagrant up and you’re done. But with such reverse approach you have to manually copy source folder from host to VM, configure samba etc. Also, when you update your vagrant box in future, so it’ll have to be rebuilt, these manual changes will have to be reapplied again.

None of above issues are critical, so probably I’ll give it a try, but canonical NFS solution is straightforward and works like a charm out of the box - the only problem with it is that NFS in unavailable on Windows. So when I found out that there are 3rd party solutions that enable NFS on windows, I thought that this is the best and most obvious way to go.

Unfortunately, I can’t make it work, so I was curious if anybody alse tried this approach - and if I’m misconfiguring something or if such 3rd party tools just don’t play well with Vagrant.