guix-patches
[Top][All Lists]
Advanced

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

[bug#40236] [PATCH] doc: Suggest Btrfs with compression instead of ext4


From: Maxim Cournoyer
Subject: [bug#40236] [PATCH] doc: Suggest Btrfs with compression instead of ext4 for root partition.
Date: Mon, 13 Apr 2020 22:20:53 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi!

Pierre Neidhardt <address@hidden> writes:

> Efraim Flashner <address@hidden> 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





reply via email to

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