From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: Self-contained Guix tarball Date: Tue, 21 Apr 2015 09:03:57 +0200 Message-ID: <20150421070357.GB15795@thebird.nl> References: <20150410084651.GA23353@thebird.nl> <873848p5kd.fsf@gnu.org> <20150410131420.GB24509@thebird.nl> <87a8ydt8k8.fsf_-_@gnu.org> <871tjlxen6.fsf@gnu.org> <20150416053355.GD21015@thebird.nl> <87k2x9b061.fsf@gnu.org> <87h9sci6n7.fsf@taylan.uni.cx> <87pp6ywmny.fsf@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkSEc-0003Qc-9S for guix-devel@gnu.org; Tue, 21 Apr 2015 03:04:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkSEX-0005T0-Af for guix-devel@gnu.org; Tue, 21 Apr 2015 03:04:42 -0400 Received: from mail.thebird.nl ([95.154.246.10]:56098) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkSEX-0005Rz-63 for guix-devel@gnu.org; Tue, 21 Apr 2015 03:04:37 -0400 Content-Disposition: inline In-Reply-To: <87pp6ywmny.fsf@inria.fr> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org > What do you mean by ???rebuild should not be necessary???? If you > remove files from the store manually? When you administrate a large amount of servers things can go wrong due to system failures, failed backup recoveries, hacking attempts and adminstrators trying to be clever ;). Murphy's law dictates that the store and the sqlitedb meta information will go out of sync. For production setups it is necessary to be able to recover from backups, but as an intermediate recovery step it would be really nice if Guix could recover its meta information from an existing store - assuming only the DB is corrupt (google for sqlite corrupted databases). It is especially nice when your backups are out of sync too. guix archive looks good, but for speedy deployment it can happen an=20 adminstrator would have a simple use case of: - Copying 2 stores to 1 machine - Rebuild database to do it quick and dirty. Since all software packages are isolated this would make a really good use case even if (with some trouble) you could use guix archive for that. I prefer quick and dirty. I am not pushing for this functionality directly, but I would certainly like to have it when I need it :) Maybe I am being pathetic (a lot of people won't appreciate the problem), but under time pressure which huge deployments - this is what is going to be wanted. On Mon, Apr 20, 2015 at 10:49:05PM +0200, Ludovic Court=E8s wrote: > taylanbayirli@gmail.com (Taylan Ulrich "Bay??rl??/Kammer") skribis: >=20 > > Would it be possible to bundle meta-data files together with store > > items? > > > > I guess one could in principle make each store item a directory with = any > > number of meta-data files plus the actual content of the store item (= a > > file or directory), but I suppose it would be too big an overhaul of = the > > design to make this worthwhile. >=20 > I suspect this would make GC inefficient (lots of disk seeks to > determine references/referrers compared to queries of the SQLite > database.) Yes, Nix switched to using sqlitedb because of the GC. It is also useful to search current versions of installed packages quickly. Even so, I think it should be viewed as an index. The state of the machine is what is *sitting* in the store. That would be the correct design. Meta information can go out of sync. Therefore we should not assume they are in sync. And it is simple to achieve. Just allow for database rebuilds. > Another (opposite :-)) option is to make /gnu/store a read-only bind > mount on GuixSD. Commit 3392ce5 does that. This will prevent > accidental modifications of the store. That is a good solution for end-users. Not for administrators. So adminstrators will circumvent it. Remember Guix is a hackable system. That is true for the store too. Pj.