how to debug hydration?
See original GitHub issueWe’re considering switching to GIT/GVFS in a very large project. As we try any operation requiring hydration of many files (build, or just opening a big solution), not just the command but the whole operation system hangs, needing a hard reset to restore operation. The hang we think is windows explorer/filesystem-related, some of the processes stay more or less operable, but we cannot browse files, cannot type, or start new programs.
Hydration of a single file (e.g. opening a text file in the repo) works as expected.
We found out that while this command always works in our repo:
gvfs prefetch --files '*',
this command always hangs:
gvfs prefetch --files '*' --hydrate
I’ve attached logs of the latter, started in verbose mode. The logs are of 2 separate runs. Please excuse me for the quality, but we weren’t able to save the log or do a printscreen with the computer hanging, so the log was photographed. In both cases, the hang was experienced between the last 2 lines, a lot before the last line appeared.
We’re willing to try debug the issue, but we’re not experienced in debugging filter drivers. If there’s any way we could provide more information than this, we’ll try to help.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
Hi @canahari. Sorry that you’re having issues. Thanks for bringing this to our attention. The
gvfs prefetch --files '*' --hydrate
command spins up several worker threads, and you are seeing the message that the “find the blobs we need to download” is finishing, but the “actually download the blobs” is not reporting success. Further, with 547,000 missing objects and a batch size of 4,000, you should be seeing over 136 “DownloadObjects” lines. This means that the download thread is not able to finish. But you could also be correct that the filesystem interactions are causing a halt that prevents that thread from continuing.Here are some basic questions:
Our usual way to diagnose these issues is to have the user run
gvfs diagnose
and put the resulting.zip
file in a network share. If the.zip
isn’t too big for your repo, perhaps you could email it to gvfsdogfood@service.microsoft.com.Alternatively, you could place the
.zip
file in a private GitHub repo and give me access to read it. I’m just trying to make sure we can support you while also not making any potentially sensitive information completely public.Finally, since you are hydrating the entire working directory, and it seems to have “only” 550 thousand files, perhaps you would have a better time trying Scalar? Here is a blog post describing some of the differences between VFS for Git and Scalar.
To do debugging, you are better off building from source and then working from there. Please see the instructions in the README. The tricky part is getting all of the dependencies installed, then running your built installer.