[Nix-dev] Please test Nix store auto-optimise

[Wout Mertens]

You're correct, there's only one inode consumed per set of hardlinked
files. So it uses less inodes.

What can happen though is that if you have a filesystem that inlines small
files into the directory entry, this will remove the inlining and instead
cause more seeks. Likewise, files that were grouped together will now be
spread out a bit more. So if you don't have an SSD this might slow down
initial loading of files.

However, you don't have to keep two copies of the same file in cache so
there's more cache available. (Only in the case when two versions of a
package are used simultaneously)

So it's hard to say what the effect is generally, but the disk space saving
is definitely there. If you are worried about seek times, you might want to
turn on filesystem compression and run some sort of defragmentation if
available. /nix/store should compress quite well and that improves I/O
times for reading. The compression overhead should not be noticeable.

E.g. for nix store on btrfs "noatime,autodefrag,compress=lzo,space_cache"
are nice flags, and add "discard,ssd" for SSD drives.

Wout.

On Thu Feb 12 2015 at 11:04:14 PM Vladimír Čunát <vcunat at gmail.com> wrote:

> On 02/12/2015 07:38 PM, John Wiegley wrote:
> > The reason why I don't like this optimization is that it doubles
> > i-node consumption on my main volume
>
> Oh, I thought each set of hardlinked files share the single i-node. Is
> it not so?
>
> Vladimir
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150213/ab705ff6/attachment.html