guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 02/02: gnu: next: Compress the executable.


From: Maxim Cournoyer
Subject: Re: 02/02: gnu: next: Compress the executable.
Date: Tue, 08 Oct 2019 16:05:46 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hello again,

Efraim Flashner <address@hidden> writes:

> On Thu, Oct 03, 2019 at 12:01:43AM +0900, Maxim Cournoyer wrote:
>> Hello Pierre!
>> 
>> Pierre Neidhardt <address@hidden> 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?
> <snip>
>> 
>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]