From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Cournoyer Subject: Re: 02/02: gnu: next: Compress the executable. Date: Tue, 08 Oct 2019 16:05:46 +0900 Message-ID: <871rvnyawl.fsf@gmail.com> References: <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> <87eezv9oo8.fsf@gmail.com> <20191003070930.GA17163@E5400> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:46817) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iHjZA-0003qQ-J1 for guix-devel@gnu.org; Tue, 08 Oct 2019 03:05:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iHjZ8-0005lU-0q for guix-devel@gnu.org; Tue, 08 Oct 2019 03:05:51 -0400 Received: from mail-qt1-x831.google.com ([2607:f8b0:4864:20::831]:41570) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iHjZ7-0005lC-TR for guix-devel@gnu.org; Tue, 08 Oct 2019 03:05:49 -0400 Received: by mail-qt1-x831.google.com with SMTP id v52so913354qtb.8 for ; Tue, 08 Oct 2019 00:05:49 -0700 (PDT) In-Reply-To: <20191003070930.GA17163@E5400> (Efraim Flashner's message of "Thu, 3 Oct 2019 10:09:30 +0300") 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 Hello again, Efraim Flashner writes: > 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'm just using the 'compress=lzo' option. Here's the output of 'compsize' on my system: --8<---------------cut here---------------start------------->8--- time sudo compsize /gnu/store Processed 2039520 files, 446555 regular extents (1329746 refs), 925862 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 90% 49G 54G 128G none 100% 44G 44G 96G lzo 49% 5.2G 10G 31G real 1m18.454s user 0m6.375s sys 0m52.852sn --8<---------------cut here---------------end--------------->8--- So my total compression rate would be 10%, which is not as good as the 30% I had on mind. I think that 30% I had on mind was based on sending an uncompressed root file system to a compressed backup drive (using Btrfs' lzo compression). But it appears most of my /gnu/store content is not using compression at all, perhaps because Btrfs will not compress files it knows wouldn't compress well (e.g. already compressed archives). HTH, Maxim