actually, I think that’s a good thing. Regular services shouldn’t try to readdir() /nix/store, and if an interactive shell hangs because it’s listing a huge directory, that’s a bug that also slows down that shell in large directories…
Large directories are completely avoidable, there are many convenient things that require enumerating some directory (not just Nix store), Tab-completing a Nix store path by the first 2 to 4 characters of its hash is sometimes convenient, and it is supposed to be possible to readdir() /nix/store as evidenced by Nix explicitly asserting that store has permissions that allow enumeration.
1 Like
Hmmm still not convinced…
- On my servers and laptop I seem to have some several thousand files, which tab-completes quickly
- On hydra storage, I would assume that if you’re looking for a certain hash it’s a quick copy and paste away
- If you want to quickly access one of several
perlpackages, there could be an additional directory with a directory for each name in the store, filled with symlinks to the actual packages. So you’d visit/nix/links/perl/<tab><tab>to see all the ones you want; the symlinks could even have embedded data like the install date in their name
OTOH, if we switch to a multi-layer store, all packages need rebuilding, there will be lots of almost empty directories. On one of my servers, looking at the distribution with 2 letters by running
(cd /nix/store; ls | cut -c1-2) | sort | uniq -c | sort -n
gives me 998 buckets, with the biggest having 12 items, and 76 directories with a single item.
Your nix store auto completes fast? Which shell do you use?
Just plain bash, but I use SSD everywhere. On macOS I’ve been forced onto zsh apparently.
Ah, SSD. That makes sense. I guess my drives will keep spinning every time I hit tab in that folder for now…
Hmmm still not convinced…
- On my servers and laptop I seem to have some several thousand files, which tab-completes quickly
So you want to say that not only NixOS is now SSD-only (via completely garbage journalctl behaviour in some cases), but Nix is intended to be so, too?
OTOH, if we switch to a multi-layer store, all packages need rebuilding,
We have a stdenv rebuild multiple times per NixOS release, look at the staging-next merges
there will be lots of almost empty directories. On one of my servers, looking at the distribution with 2 letters by running
(cd /nix/store; ls | cut -c1-2) | sort | uniq -c | sort -ngives me 998 buckets, with the biggest having 12 items, and 76 directories with a single item.
We have so many symlinks, inode consumption by directories will not be that bad in comparison
2 Likes
Since everything accesses the store all the time, I’d expect the hot parts of the tree to be in memory.
Besides that, you can make a hybrid drive very cheaply with bcachefs.
My concern is not really with inode consumption, but mostly with making the hot lookups more inefficient. Maybe that’s fairly academic though.
Since everything accesses the store all the time, I’d expect the hot parts of the tree to be in memory.
No, not enough stuff will be cached even for a simple readdir()
Besides that, you can make a hybrid drive very cheaply with bcachefs.
Hybrid drive? This assumes having a slot for an extra drive, right?
My concern is not really with inode consumption, but mostly with making the hot lookups more inefficient. Maybe that’s fairly academic though.
Hm, I operated under assumptions that for hot lookups all inodes and the relevant subset of directory contents will be in cache, and single-cached-directory traversal is negligible compared with a full syscall (and our stdenv could indeed be improved re: number of syscalls per dlopen). But yes, thanks for clarification, I have not actually checked this and I can be wrong here.
Well - neither am I sure. I can imagine it going both ways for various layouts and filesystems. It would be worthwhile to try a few layouts in a very memory-constrained system.
I have a fusion drive on this computer and tab-completing /nix/store/foo in fish took maybe 2 seconds to give me the 336 results (and upon retry it’s about half a second). And of course Fish is doing a substring match here so it’s definitely reading the whole directory. Heck, printf '%s\n' /nix/store/* | wc -l only took half a second either and gave me 58798 results (though obviously this was a warm test).
My guess is the filesystem metadata is stored on the SSD part of the fusion drive, but I can’t tell you for sure. I’ve got a 121.3GB SSD coupled with a 2TB HDD.
1 Like
click click, search search …
reference 11 is this sentence
but …
today, nix offended me with the illegal number 666. where is my cookie? :’ (
this path will be fetched (6.66 MiB download, 30.87 MiB unpacked):
/nix/store/l1l9w6n4yczk2w9y42rdplwfbmj3s04f-wxwidgets-3.1.4
Here’s a derivation whose output path is /nix/store/wankgschb1mjvaxkj6d6x3ak1wbk4pb2-wank! Appropriately containing inappropriate jokes about sex from fortune!
(import (fetchTarball "https://github.com/NixOS/nixpkgs/tarball/e4501868fb33a78bcb2dd15c9893720a460d22ed") {}).writeText "wank" ''
Documentation is like sex: when it is good, it is very, very good; and
when it is bad, it is better than nothing.
-- Dick Brandon
=========================================
Confucious say:
man who lay girl on hill, not on level.
=========================================
10 greatest lies of all time:
(1) I love you.
(2) This won't hurt a bit.
(3) The Mercedes is paid for.
(4) The check is in the mail.
(5) I was just going to call you.
(6) I've always worn cowboy boots.
(7) I swear I won't come in your mouth.
(8) Of course I'll respect you in the morning.
(9) We have a really challenging assignment for you.
(10) I'm from the government, and I'm here to help you.''
$ nix-build
/nix/store/wankgschb1mjvaxkj6d6x3ak1wbk4pb2-wank
17 Likes
I think reduce is the operative word here.
That being said, can I just mention @Infinisil, that your post is probably my all time favourite on this forum!
2 Likes
Ok I have to know, did you stumble across it or did you do an exhaustive search?
1 Like
Would be pretty weird to stumble upon such a derivation! So yeah I did a brute-force search, took about 10 hours and 800000 derivations 
7 Likes
More details please 
how did you vary the text? Very cool 
Looking at the text file, I see the chosen subset of the fortunes and the number of = signs in the separator (or does it even have to be =?) as natural tunables… And there are quite a few fortunes marked as offensive in the fortune package.
Hehe alright, here’s the code, I didn’t want to post it originally because it’s a bit ugly, but I cleaned it up a bit!
6 Likes
For anyone reading this in the future; the related part is at page 89, or pdf-page 97, at the bottom part.