There appear to be sufficient people in favor of this feature. Time for a RFC?
2017-06-19 11:28 GMT+02:00 Adrien Devresse <a...@adev.name>: > 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> 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 >> https://mailman.science.uu.nl/mailman/listinfo/nix-dev >> > > > _______________________________________________ > nix-dev mailing > listnix-...@lists.science.uu.nlhttps://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 > >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev