News for hackers. Stuff that matters.
Re:The largest Git repo by ATsch on Wednesday May 24, 2017 @01:42PM (#14411889)
What are your thoughts on implementing something more general like linux's FUSE[1] instead? A general Virtual Filesystem driver in Windows could be used for a wide range of things and means you don't just have a single-purpose driver sitting around.

[1] https://en.m.wikipedia.org/wiki/Filesystem_in_Userspace

Re:The largest Git repo by wilatmsft on Wednesday May 24, 2017 @02:02PM (#14412083)
A general FUSE-like API would be very useful to have, but unfortunately it can't meet our performance requirements.

The first internal version of GVFS was actually based on a 3rd party driver that looks a lot like FUSE. But because it is general purpose, and requires all IO to context switch from the kernel to user mode, we just couldn't make it fast enough.

Remember that our file system isn't going to be used just for git operations, but also to run builds. Once a file has been downloaded, we need to make sure that it can be read as fast as any local file would be, or dev productivity would tank.

With GvFlt, we're able to virtualize directory enumeration and first-time file reads, but after that get completely out of the way because the file becomes a normal NTFS file from that point on.

Re:The largest Git repo by WorldMaker on Thursday May 25, 2017 @11:08AM (#14417769)
I'm curious what the cross-over between GvFlt may be and the return of virtual files for OneDrive in the Fall Creators Update? Is the work being coordinated between the efforts?

From your description it sounds like there could be usefulness in coordinating such efforts.

Re:The largest Git repo by zmj on Wednesday May 24, 2017 @05:02PM (#14413438)
For use cases that fit that limited virtualization, is GvFlt something to consider? Or is that a bad idea?