Google Drive File Stream creates a local, virtual/mounted drive dubbed “G” which is mostly indistinguishable to the user from an actual local drive or a network share. The root of G has just “My Drive” for the user’s Google Drive files and “Team Drives” for the user’s Team Drives. Unlike Google Drive, files are not necessarily synced to the local computer, but are streamed on demand when users open them, with a healthy level of local caching to speed the process.
The on-demand access is designed to be transparent to users, who see what looks like a mapped network drive. That interface is an ideal way for IT organizations to deploy Team Drives as a replacement for traditional network shares, as access to Team Drives are now nearly indistinguishable from a traditional network share.
I’ve spent the better part of three months using Drive File Stream myself and I’ve seen it deployed for multiple users in our domain. This documents our successes, as well as some of the issues we’ve run into.
But how fast is it?
I knew Drive File Stream keeps a local cache of files, but I was skeptical that files not yet cached would really download fast enough to compete with the speeds of a traditional network share.
To test, immediately after install I copied to my Desktop a 1.18 GB MySQL dump file I had archived on a Team Drive. Windows measured the transfer at around 10 megabytes per second, which are about what I could expect from a network share given the environment I was in.
It’s relevant that we maintain a 100/Mbps fiber line with an enterprise SLA. Your mileage with traditional copper and/or less dependable ISPs may vary.
I also haven’t noticed a speed issue when working out of the G drive for my regular non-browser work, which involves most of the traditional Office Suite and plenty of scripting, from PowerShell to Python.
The day of my first install I did see very slight lags on folder listings with more than a dozen items, but I haven’t had that performance issue since.
While I haven’t seen many noticeable delays, some applications have. Chrome Browser plugins I’m developing – and instructing Chrome to load from my G drive on open – do not always load properly.
What about intensive I/O applications?
Drive File Stream is “only” an application that mediates access between a local cache and off-site storage while presenting a transparent network drive interface to the user. Since all file read/write requests go through Drive File Stream before being processed, I wondered about the practical limits of the application. I don’t think any IT administrator expects to store a VM’s virtual hard disk on their G drive, but we ought to be able to run applications that require modest read/write operations more frequently than during standard “Save” events.
I experimented with the limits of Drive Files Stream using resource-intensive applications often found in an office environment, Microsoft OneNote, Microsoft Access and WinRar.
I found Drive File Stream falls down on the job a bit when you require heavy numbers of read/write operations. Practically speaking, this means applications that constantly write multiple files to a file system to operate, won’t work properly.
The best example is Microsoft OneNote. I maintain a particularly large OneNote binder -around 3 GB – and while I had no problem using the binder from my G drive initially, OneNote’s performance is spotty. Sections frequently fail to load and notes are reported as corrupted frequently.
Microsoft actually recommends against storing OneNote on Google Drive to begin with, so I’m not sure what I expected, but it sets a good standard.
My other tests were more successful. I have managed multiple MS Access databases on the G drive, of varying sizes up to 1GB, without issue. I have not tested multi-user MS Access Databases, but it sounds like a recipe for database corruption.
Large (100MB – 250MB) .rar or .zip files expand without issue when loaded from and expanded onto the G drive.
Shared Files & Concurrent Access
What happens when two users attempt to open the same file? This is largely dependent on the design of the application, and deserves its own post. I recommend reviewing my post on Drive File Stream & Concurrent Access.
When Drive File Stream first launched, we had a problem with users getting signed out occasionally. That has since been solved (November 15 Release Notes)
If users already have a G drive, Drive File Stream will select another letter. This means you do not have to worry about conflicts with legacy network shares, however consider doing what you can to ensure your users access Drive File Stream via a G drive uniformly. This provides you with some interesting advantages:
- Marketing. It’s easier to point users to a new team drive when everyone uses the same drive letter.
- Administration. Drive file Stream makes it possible to script installs or configuration changes for offsite / roaming users without access to the network. If everyone is on G, then everyon’s path to “G:\Team Drives\IT Read Only Install Files\update.msi” is the same.