Welcome to ProjFS-Managed-API Discussions!

[cgallred]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[FeralSquid]

Hello,

I work at a very large video game development company in the Seattle area and am using ProjFS to build a virtual file system solution that sources files from perforce and networked fileshares to drastically reduce local storage footprint and improve sync times for our employees.

A given branch for us is typically around 1-3TB of perforce+fileshare data, and then another ~1TB of local artifacts depending on workflows, but users rarely actually need anywhere near all of that ... it is just too complex to try and build clientspecs to whittle that down further (this has been our solution in the past, and is why it ranges from 1-3TB instead of always ~4TB, but that involves extremely complex perforce clientspecs, which has other negatives).

Most users have one primary branch, but often need at least one other that they can reasonably quickly jump to for fixes. Also, that one primary branch tends to change every few months, which incurs large costs with a traditional "up-front sync" setup.

With ProjFS the local branch footprint falls dramatically, and typically even more so for the types of users that end up need to "hop" between many branches more often.

This has been a major problem with work-from-home, as it can take people all night to 5+ days to sync to a new branch, depending on their internet.

Using ProjFS, though, that new branch sync time is generally less than 10 minutes (mostly just updating p4 #have state), even with a horrible internet connection. While there is some cost paid to first time on-demand fetching, many of our tools are doing enough crunching anyway that the fetching can be parallelized and much of it hidden such that it doesn't end up impacting users too noticeably in most workflows.

The smaller footprint also means that we are likely able to replace our traditional 8TB spinner(s) with smaller NVMe drives, which will speed things up even more for our users, and is also important in our work-from-home situation as it can be difficult to squeeze large amounts of storage into a laptop (and, it turns out, usb hdds love to corrupt files/not flush when heavily used, leading to all kinds of other fun problems).

Our system built on ProjFS is in internal "open beta" with over 200 users now and many great testimonials. It is functionally complete, with me mostly noodling on optimizations and inspection/quality-of-life improvements at this point. We're mostly just letting it "soak" and waiting for more people to try it out on our many, many workflows before calling it fully released.

ProjFS has been a solid platform to build on top of, and was quick to get up and running. I'm very happy with it (though I'd love a little more official access to the locally cached placeholder state, which I've worked around at this point ;).

[cgallred]

Thank you for describing how you've been taking advantage of ProjFS. As I was reading through this I kept expecting to hit the problem description, until it finally dawned on me that this was a testimonial. Guess I've been conditioned not to expect that kind of thing online. ;-)

A targeted feature like ProjFS doesn't often get much feedback on the experience of developing for it and using it. Telemetry can tell us only so much, and can't provide the "color commentary" of a post like this. I've passed this on to my managers as an example of how investment in this feature is benefiting our customers.