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

[Bengt Richter]

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 <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 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