GNU bug report logs - #40236
[PATCH] doc: Suggest Btrfs with compression instead of ext4 for root partition.

Previous Next

Full log

Message #67 received at 40236 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Pierre Neidhardt <mail <at> ambrevar.xyz>
Cc: 40236 <at> debbugs.gnu.org,
 Ludovic Courtès <ludo <at> gnu.org>,
 Efraim Flashner <efraim <at> flashner.co.il>,
 Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Subject: Re: [bug#40236] [PATCH] doc: Suggest Btrfs with compression instead
 of ext4 for root partition.
Date: Mon, 13 Apr 2020 22:20:53 -0400

Hi!

Pierre Neidhardt <mail <at> ambrevar.xyz> writes:

> Efraim Flashner <efraim <at> flashner.co.il> writes:
>
>> On Fri, Apr 10, 2020 at 09:39:18AM +0200, Pierre Neidhardt wrote:
>>> > So compression saves me 26% ([69-51]/69), and deduplication saves me
>>> > 62% ([180-69]/180).
>>> 
>>> Thanks for sharing!
>>> zstd might give better results.  Any reason you chose lzo over zstd?
>>> 
>>
>> My machine is about 10 years old so I was more concerned than normal
>> about the CPU usage. If lz4 was an option I would've gone with that, but
>> according to the Arch wiki or some other locations lzo was basically the
>> fastest option.
>
> I've tried zstd on an AMD Athlon II X4 635 (2010): it's perfectly
> smooth, can't notice any performance drop.  In fact, I wonder if it's
> not even faster than before, but it's hard to measure.

I've also tried zstd (default level, 3) on a Intel Q6700 desktop (2007).
I don't see any CPU spike caused by the compression.  It's operating
quite smoothly actually, and gives me the following space savings:

--8<---------------cut here---------------start------------->8---
sudo compsize -x /gnu/store
Processed 1613194 files, 402674 regular extents (1163093 refs), 665696 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       60%       15G          25G          63G
none       100%       10G          10G          28G
zstd        33%      5.1G          15G          34G
--8<---------------cut here---------------end--------------->8---

Recently on the #btrfs channel someone suggested to use the Btrfs option
compress-force=zstd rather than compress=zstd, the reason being that
zstd has its own algorithm to determine if it should compress a file or
not, and that this is faster than what Btrfs does on its own when trying
to test for compressibility.

Another suggestion was to use space_cache=v2 (it defaults to v1).  This
is supposedly more efficient at managing the free space pool on large
drives (TB and up).

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.