Hello again, Efraim Flashner <efr...@flashner.co.il> writes:
> On Thu, Oct 03, 2019 at 12:01:43AM +0900, Maxim Cournoyer wrote: >> Hello Pierre! >> >> Pierre Neidhardt <m...@ambrevar.xyz> 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
