> Note, sharing /nix is already not really possible because the metadata
> is stored in sqlite and its locking does not play nice with nfs. (*)

Sharing is possible if you use a distributed file system that handle
consistency correctly, like GPFS, Lustre or similar.

We use Nix in shared model in production everyday in my organization.


> Another issue is that right now, nix does not /require/ the daemon to
> work, and this proposal would change that.

It is not really an issue. It could be done the same way it is done
currently. The client does the GC management if configured in single
user mode, or does it through the daemon if configure in multi user mode.

The strong point here is that only ONE user should write to /nix :
- Yourself in single user mode
- The nix-daemon in multi user mode.

This is not the case currently.

>
> The features that come to mind:
> - Allows later implementing policy about GC roots/space consumption
> - Allows avoiding complicated locking around doing GC
> - Allows /nix to be put on network storage transparently
> - Allows /nix to be shared between containers transparently
>
> The network-storage-/nix use case may be the most important, since there
> seems to be a lot of people who want to put /nix on NFS.
>
> Thoughts? Has this been considered?

I strongly support your idea.

The roots / profile implementation is currently hacky, not really
reliable, and potentially a security issue.


Regards,
Adev


Le 18. 06. 17 à 07:43, Wout Mertens a écrit :
>
> Note, sharing /nix is already not really possible because the metadata
> is stored in sqlite and its locking does not play nice with nfs. (*)
>
> Another issue is that right now, nix does not /require/ the daemon to
> work, and this proposal would change that.
>
> However, you can totally share /nix between multiple hosts, you just
> have to pinkie-promise not to write to it from multiple hosts at the
> same time.
>
> Wout.
>
> (*): the reason is that fnctl() locking is broken on many
> implementations. If this testing
> project https://sourceforge.net/projects/locktests/files/?source=navbar says
> it's not broken, you can totally use nix on nfs.
>
> On Sun, 18 Jun 2017, 5:10 AM , <sba...@catern.com
> <mailto:sba...@catern.com>> wrote:
>
>
>     My understanding is that currently GC roots (symlinks in
>     profiles/gcroots) are created and deleted directly by the various Nix
>     tools, even in multi-user configurations. (whether on NixOS or on
>     another Linux distribution)
>
>     It seems to me that it would be useful for the daemon to handle making
>     GC roots, and forbid users to directly create GC roots.
>
>     The features that come to mind:
>     - Allows later implementing policy about GC roots/space consumption
>     - Allows avoiding complicated locking around doing GC
>     - Allows /nix to be put on network storage transparently
>     - Allows /nix to be shared between containers transparently
>
>     The network-storage-/nix use case may be the most important, since
>     there
>     seems to be a lot of people who want to put /nix on NFS.
>
>     Thoughts? Has this been considered?
>
>     Thanks for Nix!
>
>     _______________________________________________
>     nix-dev mailing list
>     nix-dev@lists.science.uu.nl <mailto:nix-dev@lists.science.uu.nl>
>     https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Reply via email to