0

I have a (data) repository with ~50GB of data, split into <10 subdirs with files of 100 to 1000MB each. The repository is saved on a SSD, the workstation has 16 CPU Cores and 64GB of RAM.

All files are stored via git lfs.

Sometimes, when I cd into this repository, I have lots of git lfs filter-process workers blocking the terminal for >=60 seconds.

  1. Why is that, given that I just cd into the repository? git lfs filter-process converts between pointers and actual data -> when I cd into the repository I should not trigger converting since I did not do a git lfs pull or something?

  2. Even if it needs to check some pointers and convert, what could cause this process to take >=60 seconds? The system's M2 NVMe SSD is fine (benchmarked reading/writing speed -> above 3GB/s).

  • Which shell? Do you have a git prompt setup? Is cd an alias or function for something more than cd? – muru Nov 11 '19 at 7:24
  • I am using zsh, I will test later on with bash and fish as well. cd is not an alias. – daniel451 Nov 11 '19 at 7:26
  • However, good point @muru, most probably zsh is triggering git lfs then, right? – daniel451 Nov 11 '19 at 7:27
  • If you have a prompt that shows git status, probably. – muru Nov 11 '19 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.