From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Cournoyer Subject: Re: 02/02: gnu: next: Compress the executable. Date: Thu, 03 Oct 2019 00:01:43 +0900 Message-ID: <87eezv9oo8.fsf@gmail.com> References: <20190905095602.15524.75425@vcs0.savannah.gnu.org> <20190905095603.AC57A209A5@vcs0.savannah.gnu.org> <874l1qgc1j.fsf@elephly.net> <871rwuc3es.fsf@ambrevar.xyz> <87blvu32qm.fsf@gnu.org> <878sqxq4ga.fsf@ambrevar.xyz> <875zm0co0t.fsf@ambrevar.xyz> <87h85ipo14.fsf@gnu.org> <87muf9n8sc.fsf@ambrevar.xyz> <8736gw6xrh.fsf@gnu.org> <87y2yonng4.fsf@ambrevar.xyz> <87k19tg63u.fsf@ambrevar.xyz> <87v9tcm8ws.fsf@gnu.org> <87d0fjb5hi.fsf@gmail.com> <87a7an8bfy.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:44778) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFg8a-0003Nr-HR for guix-devel@gnu.org; Wed, 02 Oct 2019 11:01:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iFg8V-0006gT-Js for guix-devel@gnu.org; Wed, 02 Oct 2019 11:01:56 -0400 In-Reply-To: <87a7an8bfy.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Sun, 29 Sep 2019 15:43:45 +0200") 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" To: Pierre Neidhardt Cc: guix-devel@gnu.org Hello Pierre! Pierre Neidhardt writes: > True. > > I've been using Btrfs for my data for a little while and I'm very happy > with it. > > I wonder how Btrfs fares for a Guix system. In many ways, Guix > supersedes many of the features of Btrfs (snapshots and deduplication in > particular). So I wonder if it's not redundant and possibly incurs a > waste of energy. > > What's your experience, Maxim? I like that Btrfs allows to set different namespaces (think of LVM logical volumes) on the fly as subvolumes. I use snapshots as a mean of backups, (using the btrfs send/receive mechanism to backup the snapshots (differentially) to external storage). I haven't noticed much slow down (if at all?), and the 'lzo' compression keeps the /gnu/store size 30% smaller or so. That sums it for now, I think. HTH! Maxim