Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tarball cache pathologically slow if ~/.cache is on NFS #11998

Open
srd424 opened this issue Dec 1, 2024 · 4 comments
Open

tarball cache pathologically slow if ~/.cache is on NFS #11998

srd424 opened this issue Dec 1, 2024 · 4 comments
Labels
bug good first issue Quick win for first-time contributors performance

Comments

@srd424
Copy link

srd424 commented Dec 1, 2024

Describe the bug

This might be considered not to be a perf regression worth worrying about, but I upgraded an environment yesterday to 24.11, which pulled in nix 2.24.10 (was previously 2.18.) I then used npins to update a shell environment, and then ran nix-shell to enter it.

At that point I got the new unpacking 'https://releases.nixos.org/nixos/24.11/nixos-24.11.xxxxxxx.yyyyyyyyyyyy/nixexprs.tar.xz' into the Git cache... message .. and then the command took a further 30-40 minutes to complete.

A bit of investigation with strace etc and it appears that the problem was that my home directory was on NFS, which included (at that point) ~/.cache. Moving the cache directory to a VM-local ext4 filesystem resulted in the fetch/unpack taking only a few seconds, as expected.

@roberth
Copy link
Member

roberth commented Dec 2, 2024

Having a .cache on a network file system seems like a more general problem to solve.

It'd be good to have a check and warning when the cache directory is on a known network file system.

@roberth roberth added the good first issue Quick win for first-time contributors label Dec 2, 2024
@edolstra
Copy link
Member

edolstra commented Dec 2, 2024

Can you try Nix >= 2.25? The tarball cache should be faster thanks to #11330.

@srd424
Copy link
Author

srd424 commented Dec 2, 2024

Having a .cache on a network file system seems like a more general problem to solve.

Very arguably, yes, though "cache" in this context possibly has two variations of meanings. I tend to think of it as "bulk-ish data that can be recreated after deletion", not necessarily implying high-intensity file ops on lots of small files (as I think is the issue here.) borgbackup, for example, keeps its chunks cache in ~/.cache, but I've not noticed it suffer from performance problems when that's on NFS.

For "fast" temporary storage I'd tend to think of /tmp (or $TMPDIR), but obviously that's not necessarily very persistent or able to store large amounts of data. I assume it's not possible for git to store packed v unpacked objects in different locations?

Anyway, as I said, definitely low priority - I mostly reported so anyone else who experiences this knows they're not alone! I guess it's possible there are other odd but non-network filesystems that might struggle too.

@srd424
Copy link
Author

srd424 commented Dec 2, 2024

Can you try Nix >= 2.25? The tarball cache should be faster thanks to #11330.

Oh, that looks like a PR I should have found, read and tried, yes! I did try various issue and other searches but obviously didn't hit the right keywords :( Will report back if/when domestic chores permit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug good first issue Quick win for first-time contributors performance
Projects
None yet
Development

No branches or pull requests

3 participants