From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: Re: 02/02: gnu: next: Compress the executable. Date: Thu, 3 Oct 2019 11:28:12 -0700 Message-ID: <20191003182812.GA52459@PhantoNv4ArchGx.localdomain> References: <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> <87eezv9oo8.fsf@gmail.com> <20191003070930.GA17163@E5400> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56520) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iG9iG-0004eR-Ex for guix-devel@gnu.org; Thu, 03 Oct 2019 18:36:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iG9iE-00032P-54 for guix-devel@gnu.org; Thu, 03 Oct 2019 18:36:43 -0400 Received: from imta-36.everyone.net ([216.200.145.36]:42152 helo=imta-38.everyone.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iG9iA-0002xY-Co for guix-devel@gnu.org; Thu, 03 Oct 2019 18:36:40 -0400 Content-Disposition: inline In-Reply-To: <20191003070930.GA17163@E5400> 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: Efraim Flashner Cc: guix-devel@gnu.org, Maxim Cournoyer On +2019-10-03 10:09:30 +0300, Efraim Flashner wrote: > On Thu, Oct 03, 2019 at 12:01:43AM +0900, Maxim Cournoyer wrote: > > 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 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. > > > > What mount options do you have? I realized i have compression enabled > but 'sudo compsize /gnu/store' doesn't show any compression happening. > > (file-system > (device (file-system-label "root")) > (mount-point "/") > (type "btrfs") > (options "autodefrag,compress=lzo,discard,ssd_spread")) > I am wondering if there is some low level losetup size ambivalence involved. I.e., isn't e.g. ext4 smart enough to defer actual allocation of physical page blocks when blocks are pure zero, and just store the fact of their existence in inode metadata? If that's right, then it would seem that it would be possible to access both the full physical size and alternatively just the sum on non-zero blocks' sizes. One would think that someone has taken advantage of this to let losetup over-book physical backing blocks in a mounted loopback device. Is there a version of df that has an option to output both sizes of a sparsely non-zero file? HTH trigger some useful thought sussing out that 30% :-) -- Regards, Bengt Richter