`nix copy` displays outrageously big numbers

dtomvan · February 22, 2025, 5:35pm

I know for a fact that this is not true, as it’s a ~14G closure that I’m copying…

Did someone forget to divide by 1024???

> nix --version                               
nix (Nix) 2.24.12

polygon · February 22, 2025, 5:58pm

Yep, I know that one. On top of that, it’s also excruciatingly slow, often getting only around 20-30MBit/s on a wired GBit network.

NobbZ · February 23, 2025, 9:56am

A well known issue since 2.15 (or even longer).

github.com/NixOS/nix

`nix copy` progress report is off by magnitudes

opened 02:27PM - 26 Mar 23 UTC

NobbZ

bug

**Describe the bug** Progress information of transferred/to transfer bytes is… "off" by magnitutes. The problems seems to multiplay with the amount of paths to transfer. ![image](https://user-images.githubusercontent.com/58951/227781541-16aec267-f2a3-4083-be8a-9f5cd23dd70c.png) The copy that is ongoing here is transfering 2 paths, which have 4.6 and 2.9 GiB recursive closure size, though It can be assumed that they actually share parts of the recursive closure. So the real size to transfer is probably more in the range of 5.5 to 6.5 GiB. While the progress currently reports more than 250 GiB! The target store only has a volume size of 100 GiB. **Steps To Reproduce** 1. `nix copy --to ssh://$user@$host $someSystemConfig` (anything with a large input graph would actually do, though system configs seem to fullfil this variant easily by their nature) 2. Watch how the transfered/to transfer bytes report diverges from reality more and more as paths get transfered **Expected behavior** The "to transfer" display is correctly representing the estimate (eg. ~6GiB here in my example) from the first transfered byte. As we already know how many and which paths will be transfered and how large they would be in sum. **`nix-env --version` output** ``` $ nix-env --version nix-env (Nix) 2.15.0pre20230324_e00abd3 ``` Though I definitely have seen this on earlier versions and releases as well, though now it becomes much more visible to me as I use `nix copy` more regularly now. **Additional context** Add any other context about the problem here. **Priorities** Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).

PR #12336 is meant to fix this as far as I understand. It will not land before nix 2.28 though.

waffle8946 · February 23, 2025, 9:59am

The PR was backported, so I don’t see why it couldn’t get fixed earlier (in the next point release of 2.24).

NobbZ · February 23, 2025, 10:01am

Oh, indeed, though I only find a backport to 2.26.

waffle8946 · February 23, 2025, 10:01am

libstore: Fix progress bars (backport #12336) by mergify[bot] · Pull Request #12344 · NixOS/nix · GitHub appears to be the 2.24 backport.

dtomvan · February 23, 2025, 11:08am

Ah, that makes sense. Thank you for the explanation. I’ll just mark you as solution because otherwise this thread will keep unsolved

dtomvan · February 23, 2025, 11:13am

So I guess you can prematurely fix this by using unstable and then in NixOS specifying nix.package = pkgs.nixVersions.latest;?

waffle8946 · February 23, 2025, 11:37am

No, you’d use nixVersions.nix_2_26 (latest is older.)
But nix 2.26 has a lot of breaking changes, so it seems like absolute overkill just to fix a visual bug.